2019/4/14 Object-oriented Analysis and Design Object-oriented - PDF document

2019/4/14 Object-oriented Analysis and Design Object-oriented Analysis and Design Chapters Iteration 1 – basics 8. Applying UML and Patterns Domain models 9. 10. System sequence diagrams 11. Operation contracts An Introduction to 12. Requirements to design – iteratively Object-oriented Analysis 13. Logical architecture and UML package diagrams and Design 14. On to object design and Iterative Development 15. UML interaction diagrams 16. UML class diagrams Part III Elaboration Iteration I – Basic 1 17. GRASP: design objects with responsibilities 18. Object design examples with GRASP 19. Design for visibility 20. Mapping design to code 21. Test-driven development and refactoring Software Engineering Software Engineering 1 2 Object-oriented Analysis and Design Object-oriented Analysis and Design Iteration 1  Iteration 1 of the elaboration phase  Requirements and Emphasis: Core OOA/D Skills Chap 8  Architecture-centric and risk-driven. Iteration 1  In Iterative Development, Don't Implement All the Requirements at Once Basics  Incremental Development for the Same Use Case Across Iterations Software Engineering Software Engineering 3 4 Object-oriented Analysis and Design Object-oriented Analysis and Design Iteration 1 POS Iteration 1  Use case implementation may be spread across iterations  Requirements for iteration 1 of the POS application  Implement a basic, key scenario of the Process Sale use A use case or feature is case: entering items and receiving a cash payment. 1 2 3 . . . often too complex to complete in one short  Implement a Start Up use case as necessary to support the iteration. initialization needs of the iteration. Therefore, different parts  Nothing fancy or complex is handled, just a simple happy Use Case Use Case Use Case or scenarios must be path scenario, and the design and implementation to Process Sale Process Sale Process Sale allocated to different iterations. support it.  There is no collaboration with external services, such as a tax calculator or product database. Use Case  No complex pricing rules are applied. Process Rentals Feature:  The design and implementation of the supporting UI, Logging database, and so forth, would also be done Software Engineering Software Engineering 5 6 1

2019/4/14 Object-oriented Analysis and Design Object-oriented Analysis and Design Elaboration 1 Elaboration 2  Elaboration: Build the core architecture, resolve the high-  Executable architecture/Architectural baseline/ Architectural risk elements, define most requirements, and estimate the prototype overall schedule and resources.  to describe the partial system.  Elaboration is the initial series of iterations during project  a production subset of the final system.  the core, risky software architecture is programmed and  Some key ideas and best practices will manifest in tested elaboration:  the majority of requirements are discovered and stabilized  do short time boxed risk-driven iterations  the major risks are mitigated or retired  start programming early  Elaboration often consists of two or more iterations;  adaptively design, implement, and test the core and risky parts of the architecture  each iteration is recommended to be 2~6 weeks  test early, often, realistically  Elaboration is not a design phase or a phase when the models are fully developed in preparation for  adapt based on feedback from tests, users, developers  write most of the use cases and other requirements in detail, implementation. through a series of workshops, once per elaboration iteration Software Engineering Software Engineering 7 8 Object-oriented Analysis and Design Object-oriented Analysis and Design Elaboration 3 Planning the Next Iteration Artifact Comment  Organize requirements and iterations by risk, coverage, Domain Model This is a visualization of the domain concepts; it is similar to and criticality. a static information model of the domain entities.  Risk includes both technical complexity and other factors, Design Model This is the set of diagrams that describes the logical design. such as uncertainty of effort or usability. This includes software class diagrams, object interaction  Coverage implies that all major parts of the system are at diagrams, package diagrams, and so forth. least touched on in early iterations perhaps a "wide and Software A learning aid that summarizes the key architectural issues shallow" implementation across many components. Architecture and their resolution in the design. It is a summary of the  Criticality refers to functions the client considers of high Document outstanding design ideas and their motivation in the system. business value. Data Model This includes the database schemas, and the mapping strategies between object and non-object representations. Use-Case A description of the user interface, paths of navigation, Storyboards, usability models, and so forth. UI Prototypes Software Engineering Software Engineering 9 10 Object-oriented Analysis and Design Object-oriented Analysis and Design POS Risk List Requirement (Use Comment Rank Case or Feature) Chap 9 High Process Sale Scores high on all rankings. Domain Models Logging Pervasive. Hard to add late. … … Medium Maintain Users Affects security subdomain. … … Low … … Software Engineering Software Engineering 11 12 2

2019/4/14 ★ Object-oriented Analysis and Design Object-oriented Analysis and Design Introduction Sample UP artifact influence S a m p le U P A r tifa c t R e la tio n s h ip s  A domain model D o m a in M o d e l S a le 1 .. * S a le s B u s in e s s 1 . . .  the most important and classic model in OO analysis. L in e Ite m M o d e lin g d a te . . . . . . q u a n tity  be a visual representation of conceptual classes or real situation objects in a domain. th e d o m a in o b je c ts , e la b o ra tio n o f co n ce p tu a l c la s se s – so m e te rm s in te rm s , co n c e p ts a ttrib u te s , a n d a s s o cia tio n s th a t u n d e rg o s ta te c h a n g e s th e d o m a in a ttrib u te s , a ss o c ia tio n s  Also called conceptual models , domain object models , and m o d e l U s e -C a s e M o d e l analysis object models. co n ce p tu a l P ro c e s s S a le O p e ra tio n : e n te rIte m (… ) C a s h ie r: … cla s se s in Ite m ID : … 1 . C u sto m e r a rriv e s th e P o s t-co n d itio n s :  "focusing on explaining 'things' and products important to a ... ... d o m a in R e q u ire - - . . . 2 . ... in s p ire th e m e n ts n a m e s o f 3 . C a sh ie r e n te rs business domain“, such as POS related things. O p e ra tio n C o n tra c ts G lo s s a r y ite m id e n tifie r. so m e 4 .... so ftw a re cla s se s in  Guideline U s e C a s e T e x t th e d e s ig n  Avoid a waterfall-mindset big-modeling effort to make a D e s ig n M o d e l thorough or "correct" domain model : R e g is te r : P ro d u c tC a ta lo g : S a le  it won't ever be either, and such over-modeling efforts lead e n te rIte m (ite m ID , q u a n tity ) D e s ig n to analysis paralysis, with little or no return on the s p e c = g e tP ro d u c tS p e c ( ite m ID ) a d d L in e Ite m ( s p e c , q u a n tity ) investment. . . . Software Engineering Software Engineering 13 14 Object-oriented Analysis and Design ★★ Object-oriented Analysis and Design POS Domain Model Domain Model 1 Sales concept Item  It provides a conceptual perspective. or domain LineItem Records-sale-of object 1 0..1  domain objects or conceptual classes quantity * 1.. *  associations between conceptual classes Stocked-in  attributes of conceptual classes association Contained-in  Following elements are not suitable in a domain model 1 1  Software artifacts, such as a window or a database, unless Sale Store the domain being modeled is of software concepts, such as a attributes date address model of graphical user interfaces. time name 0..1 1  Responsibilities or methods. 1 Houses Paid-by 1.. * 1 Register Captured-on  Payment 1 amount Software Engineering Software Engineering 15 16 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ Domain Model 2 Domain Model 3  A domain model shows real-situation conceptual classes, not software  A conceptual class is an idea, thing, or object. classes visualization of a real-world concept in  Symbol words or images representing a conceptual class. Sale the domain of interest  Intension the definition of a conceptual class. dateTime it is a not a picture of a software class  Extension the set of examples to which the conceptual class applies  A domain model does not show software artifacts or classes SalesDatabase avoid software artifact; not part of domain model Sale avoid software class; not part date of domain model time print() Software Engineering Software Engineering 17 18 3