Class diagram during system analysis and design

Question

Can someone explain me the difference between class diagram during analysis and design?

So far, I understand that the class diagram of design would be the real class diagram, with all methods and attributes (ready to become code), but what about analysis? Do I have to do a class diagram for every sequence diagram? Do I have to add methods and attributes at the design stage already ? Or only connection?

Answer 1

We have 3 major types of class diagram in Object Oriented Methodologies.

1. Class Diagrams in Requirement (Domain Modeling)
2. Analysis Class Diagrams
3. Design Class Diagrams

Main difference of these class diagrams is their Abstraction.

1. In Domain Modeling, we use Class Diagrams. BUT, we do not use any Inheritance or any Interfaces, or any preforming analysis on the classes. We just write so little attributes of classes (about 3 attributes). we don't write any methods of classes. WHY? because of Abstraction. Main goal of Domain Modeling is modeling the domain. And detect Which classes should be in problem domain of system.

2. In Analysis modeling, we use class diagram. Classes in analysis is more detailed than classes in Domain. But it is not the final specification.

In Analysis, we determine Analysis Classes. We can use Inheritance between them. We can write their attributes and methods in detail. BUT, this phase is done by System Analysts. (Not System Designers or Programmer). Their profession is both knowing the Business Logics and Software Techniques. So they can write analysis classes in more detailed than Domain. However, they can not write very detailed as System Designers can.

In the other hand, we can use some analysis patterns to determine our Analysis Classes. For example RUP introduce Boundary/Control/Entity pattern. If we decided to use an existing analysis pattern, we can use the guidelines exist in the pattern documentations.

The guideline of Boundary/Control/Entity about the abstraction of classes are in this reference. In this pattern we should write only attributes for Entity classes and write only methods for Control classes and write attributes and methods for Boundary classes.

However, In my idea, we can follow the guideline or not. We can write more attributes and methods for analysis classes. What is happening? If our System Analyst try to write more detailed attributes or methods, what's happening:

I think that 1) our system analyst is not system analyst. maybe system designer. 2) we don't need their details. It is just time consuming for analysis phase. 3) ONLY if our analysis and design team are the same, or we combine analysis and design (like Agile Methodologies) the details in Analysis can be logical and useable.

3. In Design modeling, we use class diagram, this type of class diagram should be the final specification and should contain all attributes and methods. This classes are not conceptual. we can use all OOD technologies, Design Pattern and etc.

Answer 2

The UML class model is produced and refined iteratively as the understanding of the system increases. There's only one model for your system, although different diagrams may outline different aspects and level of details of this model.

Typically you would start with the domain model based on the requirements (e.g. use cases, user stories, statement of work, user interviews, etc.):

• Top priority is to get an overview. So the first sketch would identify the domain classes and how they relate to each other.
• You would then enrich this initial understanding by outlining in the diagram the key properties and methods that are essential to the understanding of the domain.

You would then enrich the model with more detailed design diagrams as you design your solution. So you would add any classes required for the implementation (e.g.user interface classes, application controllers, persistence layers, etc.).

Design diagrams are used to get a shared understanding about the software structure within the development team. So they should be easy to understand (i.e.focus on important aspects and not necessarily be cluttered with too many details that would anyhow have to be implemented in code and quickly be outdated if you don't have an army of analysts to update the model).

If you'd use an UML tool able to generate code or if you are contractually obliged to provide all the details in UML form, you would further refine the model with a fully detailed implementation diagram. Attention: for scholar work it is frequent that the teacher asks for a design diagram but expects in reality an implementation diagram.