Deriving a Design Class Diagram Yonglei Tao 1. Responsibilities Doing do something itself initiate action in other objects control and coordinate

1

Deriving a Design Class Diagram

Yonglei Tao

2

Responsibilities Doing

do something itself initiate action in other objects control and coordinate activities in other

objects Knowing about

private data related objects things it can derive or calculate

3

Design Class Diagram (DCD) A structural diagram It shows the classes, their attributes and

operations, and relationships between the classes

It is used as a basis for implementation, testing, and maintenance

4

POS – Dynamic Modeling to Design

{ lineItems.add( new SalesLineItem(desc, qty) );}

2: makeLineItem(desc, qty)enterItem(id, qty)

2.1: create(desc, qty)

:Register :Sale

sl: SalesLineItemlineItems :

List<SalesLineItem>

2.2: add(sl)

5


SalesLineItem

quantity : Integer

getSubtotal()1..*

Sale

isComplete : Booleantime : DateTime

becomeComplete()makeLineItem()makePayment()getTtotal()

public class Sale{...

private List lineItems = new ArrayList();}

A collection class is necessary to maintain attribute visibility to all the SalesLineItems.

lineItems

6


ProductCatalog

...

getProductDesc(...)

Sale


becomeComplete()makeLineItem(...)makePayment(...)getTotal()

Register

...

endSale()enterItem(id: ItemID, qty : Integer)makeNewSale()makePayment(cashTendered : Money)

public class Register{private ProductCatalog catalog;private Sale currentSale;

public Register(ProductCatalog pc) {...}

public void endSale() {...}public void enterItem(ItemID id, int qty) {...}public void makeNewSale() {...}public void makePayment(Money cashTendered) {...}}

1

1

catalog

currentSale

7


public class SalesLineItem{private int quantity;

private ProductDescription description;

public SalesLineItem(ProductDescription desc, int qty) { ... }

public Money getSubtotal() { ... }

}

SalesLineItem

quantity : Integer

getSubtotal() : Money

ProductDescription

description : Textprice : MoneyitemID : ItemID

...

1

description

8

2: makeLineItem(desc, qty)enterItem(id, qty)

1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

lineItems : List<SalesLineItem>

: Map<ProductDescription>

2.2: add(sl)

SalesLineItem

quantity : Integer

...

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID: ItemID

...

1..*

1..*

Register

...

enterItem(...)...

Sale


makeLineItem(...)...1

1

1

catalog

currentSale

descriptions{Map}

lineItems{ordered}

description

9

A Design Class Diagram

SalesLineItem

quantity : Integer

getSubtotal()

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID: ItemID

...

Store

address : Addressname : Text

addCompleteSale(...)

Payment

amount : Money

...

1..*

1..*

Register

...

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

Sale


becomeComplete()makeLineItem(...)makePayment(...)getTotal()

1

1

1

1

1

1

*

catalog

catalog

register

currentSale

descriptions{Map}

lineItems{ordered}

payment

completedSales{ordered}

description

10

SalesLineItem

- quantity

+ getSubtotal()

ProductCatalog

...

+ getSpecification(...)

ProductSpecification

- description- price- item ID

...

S tore

- address- nam e

+ addSale(...)

Paym ent

- am ount

...

Register

...

+ endSale()+ enterItem (...)+ m akeNewSale()+ m akePaym ent(...) Sale

- date- isCom plete- tim e

+ becom eCom plete()+ m akeLineItem (...)+ m akePaym ent(...)+ getTotal()

Classes in Design

11

User Interface and Domain Objects

:Register

Cashier

:ProcessSaleJFrame

actionPerformed( actionEvent )

1: enterItem(id, qty)

2 [no sale] : s = getSale : Sale

UILayer

DomainLayer

s : Sale

3: t = getTotal

presses button

12

Deriving Design Class Diagram It is derived from the domain model and

the sequence diagrams DCD may contain design classes like

controller, command, GUI classes Domain model only contains application

classes DCD must be carefully specified

13

Steps for Deriving DCD

1) Identify all classes used in each of the sequence diagrams and put them down in the DCD: classes of objects that send or receive messages classes of objects that are passed as parameters

or return values

14

<<singleton>>

classes used.

:CheckoutGUI

<<uid, cnList>>

:DBMgr

u:=getUser(uid):User

d:=getDocument(cn)

l:Loan

[a]create(u,d)

[a]save(l)

d:Document

[a]setAvailable(false)[a]save(d)

:CheckoutController

msg:=check-out(uid, cnList) [u!=null]

process(cnList)

a:=isAvailable()

<<msg>>

Loop(for each cn in cnList)

Identify objects that send or receive messages, passed as parameters or return type.

15

Classes Identified

User

Document

Loan

CheckoutGUI

DBMgr

CheckoutController

16


2) Identify methods belonging to each class and fill them in the DCD: Methods are identified from incoming messages

of the object The sequence diagram may also provide

detailed info about the parameters, their types, and return types

17

Identify Methods:Checkout

GUI

<<uid, cnList>>

:DBMgr


d:=getDocument(cn)

l:Loan

[a]create(u,d)

[a]save(l)

d:Document

[a]setAvailable(false)[a]save(d)

:CheckoutController


process(cnList)

a:=isAvailable()

<<msg>>

Loop(for each cn in cnList)methods of

CheckoutController

methods of Document

18

Fill In Identified Methods

User

Document

Loan

CheckoutGUI

DBMgr

getUser(uid)getDocument(callNo)saveLoan(loan)saveDocument(book)

isAvailable() : booleansetAvailable(a:boolean)

<<singleton>>

CheckoutControllercheckout(uid,cnList)process(cn:String[])

create(u:User, d:Document)

19


3) Identify and fill in attributes from sequence diagrams and domain model: Attributes are not objects and have only scalar

types Attributes may be used to get objects Attributes may be identified from getX() and

setX(...) methods Needed attributes may also be found in the

domain model

20

:CheckoutGUI

<<uid, cnList>>

:DBMgr


d:=getDocument(cn)

l:Loan

[a]create(u,d)

[a]save(l)

d:Document

[a]setAvailable(false)

[a]save(d)

:CheckoutController


process(cnList)

a:=isAvailable()

<<msg>>


Identify Attributes

attribute of User

attribute value

attributes of Document

21

Fill In Attributes

display(msg:String)

User

Document

Loan

CheckoutGUI

DBMgr



<<singleton>>

CheckoutController

checkout(uid,cnList)process(cn:String)


uid : String

callNum : StringisAvailable : boolean

dueDate : Date

from domain model

22


4) Identify and fill in relationships from sequence diagram and domain model: An arrow from one object to another is a call and

indicates a dependence relationship An object passed as a parameter or return value

indicates a uses relationship Two or more objects passed to a constructor

may indicate an association and an association class

23

Identify Relationships:Checkout

GUI

<<uid, cnList>>

:DBMgr


d:=getDocument(cn)

l:Loan

[a]create(u,d)

[a]save(l)

d:Document


[a]save(d)

:CheckoutController


process(cnList)

a:=isAvailable()

<<msg>>


call relationshi

p

association w/ an association class.

CheckoutController and DBMgr use User.

24

Fill In Relationships

display(msg:String)

User

Document

Loan

CheckoutGUI

DBMgr



<<singleton>>

CheckoutController

checkout(uid,cnList)process(cn:String)


uid : String

callNum : Stringavailable : boolean

dueDate : Date

The dashed arrow lines denote uses or dependence relationships.

<<create>>

25

:CheckoutGUI

<<uid,cnList>>

:DBMgr l:Loan

[a]create(u,d)

[a]saveLoan(l)

d:Document


[a]save-Document(d)

[u!=null] process(cnList)

a:=isAvailable():boolean

<<msg>>


Patronu:=getUser(uid):User

d:=getDocument(cn):Document

public class CheckoutGUI { DBMgr dbm=new DBMgr (); public void process(String[] cnList) { for(int i=0; i<cnList.length; i++) { Document d=dbm.getDocument(cnList[i]); if (d.isAvailable()) { Loan l=new Loan(u, d); dbm.saveLoan(l); d.setAvailable(false); dbm.saveDocument(d); }}

Documents

Deriving a Design Class Diagram Yonglei Tao 1. Responsibilities Doing do something itself initiate action in other objects control and coordinate