1 / 31

Part V: Design

Understand the essential concepts and practices of object-oriented analysis and design using UML. Learn to refine analysis relationships, design classes, and translate analysis into design effectively. Explore design workflows and create well-structured designs.

josephjanderson
Download Presentation

Part V: Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  4. Unified Process - Overview • Design is muchmoreconsentrated in • ElaborationandConstructionphases Object Oriented Analysis & Design & UML (Unified Modeling Language)

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

  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 consideredto be • just a refinement and elaboration of analysis model Object Oriented Analysis & Design & UML (Unified Modeling Language)

  7. Design Workflow • Artefacts • Designsubsystems • Designclasses • DesignInterfaces • Usecaserealizationsfordesign Object Oriented Analysis & Design & UML (Unified Modeling Language)

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

  9. Tracing Analysis to Design • Eachanalysisclass • can be tracedto • multipledesignclasses/interfaces Object Oriented Analysis & Design & UML (Unified Modeling Language)

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

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

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

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

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

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

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

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

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

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

  22. 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)

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

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

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

  26. 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)

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

  28. 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)

  29. Specification of Parts’ Semantics Object Oriented Analysis & Design & UML (Unified Modeling Language)

  30. 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)

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

More Related