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?

Register

...

endSale()enterItem(...)makePayment(...)

Sale

timeisComplete : Boolean/total

makeLineItem(...)

Register

...

Sale

timeisComplete : Boolean/total

Captures

1

11Domain Model

conceptual perspective

Design Model

DCD; software perspective

currentSale

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?

notice that an association end can optionally also have a property string such as {ordered, List}

Sale

time: DateTime

...

SalesLineItem

...

...

1..*lineItems

{ordered, List}

Sale

time: DateTimelineItems : SalesLineItem [1..*] orlineItems : SalesLineItem [1..*] {ordered}

...

SalesLineItem

...

...

Two ways to show a collection attribute

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

: Register : Sale

makePayment(cashTendered)

makePayment(cashTendered)

Register

...

makePayment(…)...

Sale

...

makePayment(…)...

1

currentSale

messages in interaction diagrams indicate operations in the class diagrams classes

identified in the interaction diagrams are declared in the class diagrams

NB : model class & interaction diagrams in parallel

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

Method body pseudo-code also optional

Register

...

endSale()enterItem(id, qty)makeNewSale()makePayment(cashTendered)

«method»// pseudo-code or a specific language is OKpublic void enterItem( id, qty ){ ProductDescription desc = catalog.getProductDescription(id); sale.makeLineItem(desc, qty);}

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?

SalesLineItem

...

...

ProductDescription

...

...

1..*lineItems

Sale

...

updatePriceFor( ProductDescription )...

the Sale has parameter visibility to a ProductDescription, and thus some kind of dependency

Composition (whole-part) relations

Finger0..7

Hand

composition

1

Square40

Board1

SalesLineItem1..*

Sale1

composition means -a part instance (Square) can only be part of one composite (Board) at a time

-the composite has sole responsibility for management of its parts, especially creation and deletion

Association classes—model association with attributes & operations

salarystartDate

Employment

EmploysCompany Person**

a person may have employment with several companies

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