ObjectOriented Software Engineering An Agile Unified Methodology by

Object-Oriented Software Engineering: An Agile Unified Methodology by David Kung Chapter 11: Deriving a Design Class Diagram Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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. 11 -2 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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

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. 11 -4 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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. 11 -5 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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 11 -6 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Identify Classes Used in Sequence Diagrams classes used. <<singleton>> : Checkout GUI <<uid, cn. List>> : Checkout Controller msg: =checkout(uid, cn. List) Loop (for each cn in cn. List) : DBMgr l: Loan u: =get User(uid): User [u!=null] process(cn. List) d: =get Document(cn) d: Document Identify objects that send or receive messages, passed as parameters or return type. a: =is. Available() [a]create(u, d) [a]save(l) [a]set. Available(false) [a]save(d) <<msg>> 11 -7 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Classes Identified Checkout. GUI User Checkout. Controller DBMgr Loan Document 11 -8 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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. 11 -9 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Identify Methods : Checkout GUI <<uid, cn. List>> : Checkout Controller msg: =checkout(uid, cn. List) Loop (for each cn in cn. List) methods of Checkout. Controller : DBMgr l: Loan d: Document u: =get User(uid): User [u!=null] process(cn. List) d: =get Document(cn) a: =is. Available() [a]create(u, d) [a]save(l) [a]set. Available(false) [a]save(d) <<msg>> methods of Document 11 -10 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Fill In Identified Methods Checkout. GUI User Checkout. Controller checkout(uid, cn. List) process(cn: String[]) Loan <<singleton>> DBMgr get. User(uid) get. Document(call. No) save. Loan(loan) save. Document(book) Document create(u: User, d: Document) is. Available() : boolean set. Available(a: boolean) 11 -11 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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 get. X() and set. X(. . . ) methods. – Needed attributes may also be found in the domain model. 11 -12 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Identify Attributes : Checkout GUI <<uid, cn. List>> : Checkout Controller msg: =checkout(uid, cn. List) Loop (for each cn in cn. List) : DBMgr u: =get User(uid): User [u!=null] process(cn. List) l: Loan d: Document attribute of User d: =get Document(cn) attributes of Document a: =is. Available() [a]create(u, d) [a]save(l) [a]set. Available(false) [a]save(d) <<msg>> attribute value Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved. 11 -13

Fill In Attributes Checkout. GUI User uid : String display(msg: String) Checkout. Controller from domain model checkout(uid, cn. List) process(cn: String) Loan <<singleton>> DBMgr get. User(uid) get. Document(call. No) save. Loan(loan) save. Document(book) Document call. Num : String is. Available : boolean due. Date : Date create(u: User, d: Document) is. Available() : boolean set. Available(a: boolean) 11 -14 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

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. 11 -15 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Identify Relationships : Checkout GUI <<uid, cn. List>> call relationship : Checkout Controller msg: =checkout(uid, cn. List) Loop (for each cn in cn. List) : DBMgr u: =get User(uid): User [u!=null] process(cn. List) l: Loan d: Document Checkout. Controller and DBMgr use User. d: =get Document(cn) a: =is. Available() [a]create(u, d) association w/ an association class. [a]save(l) [a]set. Available(false) [a]save(d) <<msg>> 11 -16 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Fill In Relationships The dashed arrow lines denote uses or dependence relationships. Checkout. GUI display(msg: String) Checkout. Controller checkout(uid, cn. List) process(cn: String) <<create>> User uid : String Loan due. Date : Date create(u: User, d: Document) <<singleton>> DBMgr get. User(uid) get. Document(call. No) save. Loan(loan) save. Document(book) Document call. Num : String available : boolean is. Available() : boolean set. Available(a: boolean) 11 -17 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

From Sequence Diagram to Implementation : Checkout GUI Patron <<uid, cn. List>> <<msg>> Loop (for each cn in cn. List) : DBMgr u: = get. User(uid): User [u!=null] process(cn. List) l: Loan d: Document public class Checkout. GUI { DBMgr dbm=new DBMgr (); public void process(String[] cn. List) { for(int i=0; i<cn. List. length; i++) { Document d=dbm. get. Document(cn. List[i]); if (d. is. Available()) { Loan l=new Loan(u, d); dbm. save. Loan(l); d. set. Available(false); dbm. save. Document(d); } } d: =get Document(cn): Document a: =is. Available(): boolean [a]create(u, d) [a]save. Loan(l) [a]set. Available(false) [a]save. Document(d) 11 -18 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.

Applying Agile Principles 1. Value working software over comprehensive documentation. 2. Good enough is enough. 11 -19 Copyright {c} 2014 by the Mc. Graw-Hill Companies, Inc. All rights Reserved.