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

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

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

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

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

6. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 6

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

8. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 8

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

10. 10 The Design Classes

11. 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, … 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 11

12. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 12

13. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 13

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

15. 15 Refining analysis relationships

16. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 16

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

18. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 18

19. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 19

20. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 20

21. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 21

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

23. 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 09.10.2015Object 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

24. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 24

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

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

27. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 27

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

29. 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 09.10.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 29

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

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