Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part V: Design The Design Workflow Design Classes Refining Analysis Relationships

Object Oriented Analysis & Design & UML (Unified Modeling Language) 2 Content The Design Workflow Design Classes Refining Analysis Relationships

The Design Workflow Object Oriented Analysis & Design & UML (Unified Modeling Language) 3

Unified Process - Overview Design is much more consentrated in Elaboration and Construction phases Object Oriented Analysis & Design & UML (Unified Modeling Language) 4

Design Model The design model contains exactly one design system that contains many design subsystems Object Oriented Analysis & Design & UML (Unified Modeling Language) 5

From Analysis to Design there is a simple one-to-one «trace» relationship between the analysis system and the design system the design model is based on the analysis model, can be considered to be just a refinement and elaboration of analysis model Object Oriented Analysis & Design & UML (Unified Modeling Language) 6

Design Workflow Artefacts Design subsystems Design classes Design Interfaces Use case realizations for design Object Oriented Analysis & Design & UML (Unified Modeling Language) 7

Analysis Class-Design Class An analysis class may be resolved into one or more interfaces or design classes. analysis classes are a high-level conceptual view of the classes in the system. In physical modeling (design): conceptual classes are implemented as one or more design classes and/or interfaces Object Oriented Analysis & Design & UML (Unified Modeling Language) 8

Tracing Analysis to Design Each analysis class can be traced to multiple design classes/interfaces Object Oriented Analysis & Design & UML (Unified Modeling Language) 9

10 The Design Classes

What are Design Classes? Classes with completed definition Detailed so that ready to implement Sources of design classes Problem domain via refinement of analysis classes Solution domain Utility classes Time, Date, String, collections, … Middleware Communications, database,.. Component frameworks DCOM, CORBA, Enterprise JavaBeans GUI Framework Window, Form, Button, Menu, … Object Oriented Analysis & Design & UML (Unified Modeling Language) 11

Translating Analysis Classes into Design Classes Refine analysis class into one or more design classes if classes become too large design level abstraction is more detailed add newly found attributes to make the class complete for implementation new implementation level attributes Broke large analysis classes into two or more classes Good design classes must be Small Self-contained Cohesive units Object Oriented Analysis & Design & UML (Unified Modeling Language) 12

Anatomy of Design Class Specify how the class will fulfill its responsibilities Complete list of attributes Fully specify with visibility, name, type, Default values (if there are any) Complete set of methods visibility, name, parameter list, type, return value Object Oriented Analysis & Design & UML (Unified Modeling Language) 13

Example: BankAccount Object Oriented Analysis & Design & UML (Unified Modeling Language) 14

15 Refining analysis relationships

Inheritance In analysis use inheritance to implement “is a” relationships In design use inheritance to reuse code as well Inheritance is Strongest for coupling Changes to parent classes have a large impact on classes in the hierarchy Encapsulation is weak in class hierarchy Child classes can access to base’s attributes! Inflexible Fixed at run-time You cannot change it as done in aggregation Object Oriented Analysis & Design & UML (Unified Modeling Language) 16

Aggregation instead of Inheritance (?) subclass always represents “is kind of” not “is role played by” Object Oriented Analysis & Design & UML (Unified Modeling Language) 17 john: changes the role by just changing link between role and :Programmer

Multiple Inheritance Some OO Languages do not allow Languages do not support: Java, C# Language supports : C++ Overlap between the classes causes unforeseen interactions “is kind of” and substitutability principles must apply common parents cause Multiple occurrence of the same features Object Oriented Analysis & Design & UML (Unified Modeling Language) 18

Aggregation Whole-part relationship A lose relationship Whole does not own the parts Parts Created and destructed any time are not dependent on the whole Example: Computer system and the peripherals Object Oriented Analysis & Design & UML (Unified Modeling Language) 19

Aggregation Rules The aggregate can exist independent from its parts The parts can exist independent from the aggregate The aggregate is incomplete If the parts are missing The same parts can be shared by multiple aggregates Object Oriented Analysis & Design & UML (Unified Modeling Language) 20

Composition A whole-part relationship Strong type of relationship The life cycle of the parts depend on the whole Parts can be created only after the whole is created destructed by default when the whole is destructed Example: Tree and its leaves Object Oriented Analysis & Design & UML (Unified Modeling Language) 21

Composition Rules The parts belong to only one composite cannot exist without the composite The composite creates and destroys the parts Object Oriented Analysis & Design & UML (Unified Modeling Language) 22

Aggregation vs Composition Aggregation a Computer may be attched to 0 or more Printers at any time a Printer is connected to 0 or more Computers over time a computer may use a given Printer the printer exist even if there are no Computers attached the Printer is independent from the Computer Object Oriented Analysis & Design & UML (Unified Modeling Language) 23 Composition a Tree might have 0 or many Leaves at a time over time a computer may use a given Printer Tree still exist even if it has no Leaves at all the Leaves cannot exist without the Tree the Leaves are dependent on the Tree

How to Refine Analysis Relationships? Add multiplicities and role names to associations if they were absent Decide which of the side is whole and which side is the part Look at the whole side If it is exactly 1: You may apply the composition Otherwise You must set it as aggregation Add navigability from the whole to the part Design associations must be unidirectional! Decide how to implement the multiplicities greater than 1 on both sides Object Oriented Analysis & Design & UML (Unified Modeling Language) 24

One-to-One Associations One-to-one associations become composition Object Oriented Analysis & Design & UML (Unified Modeling Language) 25

Many-to-one Associations Many on the whole side: Use aggregation You cannot use composition Reason: the whole cannot be shared in composition! Object Oriented Analysis & Design & UML (Unified Modeling Language) 26

One-to-Many Associations There are collection of objects on the parts side Use collections to implement If the language does not support collections Use arrays Implement collections Object Oriented Analysis & Design & UML (Unified Modeling Language) 27

Implementation of one-to-many If life-cycle of the parts is dependent on the whole Use aggregation Otherwise use composition Object Oriented Analysis & Design & UML (Unified Modeling Language) 28

Specification of Parts’ Semantics PropertySemantics {sorted}The collection is sorted to some key: {sorted by name} {indexed}Individual element is accessed via a key {set}Dublicates are not allowed in collection {lifo}Last In First Out characteristics {queue}A queue with the first element is placed to be taken off first Object Oriented Analysis & Design & UML (Unified Modeling Language) 29

Many-to-Many Relationships commonly used OO languages does not support Many-to-Many relationships Add new design class between Object Oriented Analysis & Design & UML (Unified Modeling Language) 30

Object Oriented Analysis & Design & UML (Unified Modeling Language)31 End of Chapter