1. Design Class Diagrams (DCDs)
During analysis, emphasize domain concepts
During design, shift to software artifacts
UML has no explicit notation for DCDs
Uniform UML notation supports smoother development from analysis to design

2. Domain model vs. Design Class Diagram – differences?

3. Developing a Domain Class Diagram: POS DCD
1) Identify software classes:
Register Sale ProductCatalog ProductSpecification Store SalesLineItem Payment
2) Begin drawing a class diagram
3) Include the attributes from the domain model

4. How to show attribute collections?
Sale software object holds a list of many SalesLineItem objects
public class Sale {
private DateTime time;
private List<SalesLineItems> lineItems; }

5. 4) Add method names from interaction digram
NB : model class & interaction diagrams in parallel

6. Parameters, return types optional? —readability vs. code generation

7. Method body pseudo-code also optional
Method body adds a dynamic behaviour to the static class diagram

8. 5) Add associations and navigability —Navigability implies visibility of attributes

9. 6) Adding dependency relationships
Indicates that one element A has knowledge of another element B
I.e., a change in specification of B may affect A that uses it, but not necessarily the reverse
Illustrated with dashed directed line
Typically non-attribute visibility between classes

10. Common kind of dependencies
Type A having an attribute of type B
A Sending a message to B , that is A call method of B
A receiving a parameter of B
B is a superclass or interface

11. What does dependency add to this DCD?

12. Composition (whole-part) relations

13. Association classes —model association with attributes & operations

14. Designing with interaction and class diagrams
Beginners often emphasize Class diagrams
Interaction diagrams deserve more attention
Some tools can help:
Convert between sequence and communication diagrams automatically
Reflect changes in class and interaction diagrams in parallel