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

Domain model vs. Design Class Diagram – differences?

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

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; }

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

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

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

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

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

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

What does dependency add to this DCD?

Composition (whole-part) relations

Association classes —model association with attributes & operations

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