1. Chapter 11: Deriving a Design Class Diagram

2. Key Takeaway Points
A design class diagram (DCD) is a UML class diagram, derived from the behavioral models and the domain model.
It serves as a design blueprint for test-driven development, integration testing, and maintenance.
Package diagrams are useful for organizing and managing the classes of a large DCD.

3. Deriving DCD in the Methodology Context
Use case-iteration allocation matrix
Business goals
& needs
Current situation
Accommodating
Requirements Change
Customer
feedback
Acquiring
Requirements
(Domain Modeling)
Iteration use cases
Domain Modeling
Preliminary requirements
Domain model
Domain model
Deriving Use Cases
from Requirements
Actor-System Interaction Modeling
Abstract & high level use cases, use case diagrams
Expanded use cases & UI design
Allocating Use Cases & Subsystems
to Iterations
Behavior Modeling &
Responsibility Assignment
Behavior models
Use case-iteration allocation matrix
Deriving Design Class
Diagram
Producing an Architecture Design
Design class diagram
Software architecture
Test Driven Development, Integration, & Deployment
(a) Planning Phase
(b) Iterative Phase – activities during each iteration
control flow
data flow
control flow & data flow

4. Deriving Design Class Diagram
A design class diagram (DCD) is a structural diagram.
It shows the classes, their attributes and operations, and relationships between the classes. It may also show the design patterns used.
It is used as a basis for implementation, testing, and maintenance.
It should contain only classes appear in the sequence diagrams, and a few classes from the domain model.

5. Deriving Design Class Diagram
It is derived from the domain model (DM) and the sequence diagrams:
The domain model provides a few classes, the attributes and some relationships.
The sequence diagrams determines the classes, methods, some attributes, and dependence relationships.
DCD may contain design classes like controller, command, GUI classes. Domain model only contains application classes.
DCD must be carefully specified. DM is more liberal.

6. 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 types/values

7. Identify Classes Used in Sequence Diagrams
<<singleton>>
classes used.
:Checkout
GUI
:Checkout
Controller
:DBMgr
l:Loan
d:Document
<<uid,
cnList>>
msg:=check-
out(uid, cnList)
u:=get
User(uid):User
[u!=null]
process(cnList)
Identify objects that send or receive messages, passed as parameters or return type.
Loop
(for each cn in cnList)
d:=get
Document(cn)
a:=isAvailable()
[a]create(u,d)
[a]save(l)
[a]setAvailable(false)
[a]save(d)
<<msg>>

8. Classes Identified CheckoutGUI User CheckoutController DBMgr Loan
Document

9. 2) Identify methods belonging to each class and fill them in the DCD:
Steps for Deriving DCD
2) Identify methods belonging to each class and fill them in the DCD:
Methods are identified by looking for messages that label an incoming edge of the object.
The sequence diagram may also provide detailed information about the parameters, their types, and return types.

10. Identify Methods <<uid, cnList>> :DBMgr u:=get
:Checkout
GUI
<<uid,
cnList>>
:DBMgr
u:=get
User(uid):User
d:=get
Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
Controller
msg:=check-
out(uid, cnList)
[u!=null]
process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn in cnList)
methods of CheckoutController
methods of Document

11. Fill In Identified Methods
CheckoutGUI
User
CheckoutController
checkout(uid,cnList)
process(cn:String[])
Loan
<<singleton>>
Document
DBMgr
getUser(uid)
getDocument(callNo)
saveLoan(loan)
saveDocument(book)
create(u:User, d:Document)
isAvailable() : boolean
setAvailable(a:boolean)

12. Steps for Deriving DCD
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.

13. Identify Attributes :Checkout GUI <<uid, cnList>> :DBMgr
u:=get
User(uid):User
d:=get
Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
Controller
msg:=check-
out(uid, cnList)
[u!=null]
process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn in cnList)
attribute of User
attributes of Document
attribute value

14. Fill In Attributes CheckoutGUI User uid : String display(msg:String)
CheckoutController
from domain model
checkout(uid,cnList)
process(cn:String)
Loan
<<singleton>>
dueDate : Date
Document
DBMgr
callNum : String
isAvailable : boolean
create(u:User, d:Document)
getUser(uid)
getDocument(callNo)
saveLoan(loan)
saveDocument(book)
isAvailable() : boolean
setAvailable(a:boolean)

15. Steps for Deriving DCD
4) Identify and fill in relationships from sequence diagram and domain model:
An arrow from one object to another is a call and hence it indicates a dependence relationship.
An object passed as a parameter or return type/value indicates an association or uses relationship.
Two or more objects passed to a constructor may indicate an association and an association class.
The domain model may contain useful relationships as well.

16. Identify Relationships
:Checkout
GUI
<<uid,
cnList>>
:DBMgr
u:=get
User(uid):User
d:=get
Document(cn)
l:Loan
[a]create(u,d)
[a]save(l)
d:Document
[a]setAvailable(false)
[a]save(d)
Controller
msg:=check-
out(uid, cnList)
[u!=null]
process(cnList)
a:=isAvailable()
<<msg>>
Loop
(for each cn in cnList)
CheckoutController and DBMgr use User.
call relationship
association w/ an association class.

17. Fill In Relationships
The dashed arrow lines denote uses or dependence relationships.
CheckoutGUI
display(msg:String)
<<create>>
CheckoutController
checkout(uid,cnList)
process(cn:String)
User
uid : String
Loan
dueDate : Date
create(u:User, d:Document)
<<singleton>>
Document
DBMgr
callNum : String
available : boolean
getUser(uid)
getDocument(callNo)
saveLoan(loan)
saveDocument(book)
isAvailable() : boolean
setAvailable(a:boolean)

18. From Sequence Diagram to Implementation
:Checkout
GUI
:DBMgr
l:Loan
d: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); }
<<uid,cnList>>
u:=
getUser(uid):
User
Patron
<<msg>>
[u!=null]
process(cnList)
Loop
(for each cn in cnList)
d:=get
Document(cn):
Document
a:=isAvailable():boolean
[a]create(u,d)
[a]saveLoan(l)
[a]setAvailable(false)
[a]save-
Document(d)

19. Applying Agile Principles
Value working software over comprehensive documentation.
Good enough is enough.