2019/5/6 Object-oriented Analysis and Design Object-oriented - PDF document

2019/5/6 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 POS SSD: a Process Sale Scenario system as black box the name could be "NextGenPOS" but "System" keeps it simple the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML Chap 10 external actor to Process Sale Scenario system System Sequence Diagrams :System : Cashier makeNewSale a UML loop [ more items ] loop interaction enterItem(itemID, quantity) frame , with a boolean guard expression description, total a message with endSale parameters return value(s) associated with the it is an abstraction total with taxes previous message representing the system event of an abstraction that makePayment(amount) entering the ignores presentation payment data by and medium some mechanism the return line is change due, receipt optional if nothing is returned Software Engineering Software Engineering 3 4 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ System Sequence Diagram 1 System Sequence Diagram 2  System sequence diagram  SSDs are derived from use cases; they show one scenario.  a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order , and inter- Process Sale Scenario system events . :System : Cashier  All systems are treated as a black box ; the emphasis of the makeNewSale Simple cash-only Process Sale scenario: diagram is events that cross the system boundary from actors to loop [ more items ] 1. Customer arrives at a POS checkout enterItem(itemID, quantity) systems. with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier.  During interaction between system and actor, an actor generates description, total 4. System records sale line item and presents item description, price, and system events to a system, usually requesting some system running total. operation to handle the event. Cashier repeats steps 3-4 until indicates done. endSale  UML includes sequence diagrams as a notation that can 5. System presents total with taxes calculated. total with taxes illustrate actor interactions and the operations initiated by them. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles  Guideline: Draw an SSD for a main success scenario of each use makePayment(amount) payment. case, and frequent or complex alternative scenarios. ... change due, receipt Software Engineering Software Engineering 5 6 1

2019/5/6 Object-oriented Analysis and Design Object-oriented Analysis and Design System Sequence Diagram 3 System Sequence Diagram 4  System events should be expressed at the abstract level of intention  Guideline rather than in terms of the physical input device.  show details of SSD in the Glossary.  "enterItem" is better than "scan" (laser scan) because it captures the  The elements shown in SSDs (operation name, parameters, return abstract intent of the operation. data) are terse.  design choices about what interface is used to capture the system event (laser scanner, keyboard, voice input ..)  Iterative and Evolutionary SSDs - UP Phases  Inception phase: SSDs are not usually motivated in inception, unless you are doing rough estimating (don't expect inception estimating to :System : Cashier be reliable) - function points or COCOMO II. better name  Elaboration phase: Most SSDs are created during elaboration, when it enterItem(itemID, quantity) is useful to identify the details of the system events to clarify what major operations, write system operation contracts, and possibly to scan(itemID, quantity) support estimation. worse name Software Engineering Software Engineering 7 8 Object-oriented Analysis and Design Object-oriented Analysis and Design System Sequence Diagram - Buy-Item System as block box Actor Buy-Item-version 1 Chap 11 :System Operation Contracts Cashier Enteritem(UPC, quantity) Repeat until no more items endSale() makePayment(amount) Text which clarifies control, logic, iteration, etc. May be taken from System event the use case It triggers a system operation Software Engineering Software Engineering 9 10 Object-oriented Analysis and Design Object-oriented Analysis and Design ★ ★ POS Operation Contract Sections of a Contract  Contract CO2: enterItem  Operation: Name of operation, and parameters  Operation: enterItem(itemID: ItemID, quantity: integer)  Cross References: Use cases this operation can occur  Cross References: Use Cases: Process Sale within  Preconditions: There is a sale underway.  Preconditions: Noteworthy assumptions about the state  Postconditions: of the system or objects in the Domain Model before  A SalesLineItem instance sli was created (instance execution of the operation. creation).  Postconditions: The state of objects in the Domain  sli was associated with the current Sale (association Model after completion of the operation. formed).  sli.quantity became quantity (attribute modification).  sli was associated with a ProductDescription, based on itemID match (association formed). Software Engineering Software Engineering 11 12 2