Bài Giảng Phân tích thiết kế hướng đối tượng (phần 4) potx

Contracts and Contracts and UML interaction diagrams UML interaction diagrams Lecture 4 Lecture 4 Hoa Sen University 1 Agenda Agenda  System sequence diagram  Operation Contract  On to Object design – Interaction diagrams  Sequence diagrams  Communication diagrams Hoa Sen University 2 System Sequence Diagram System Sequence Diagram Hoa Sen University 3 Operation: enterItem(…) Post-conditions: - . . . Operation Contracts Sale date . . . Sales LineItem quantity 1 * 1 . . . . . . Domain Model Use-Case Model Design Model : Register enterItem (itemID, quantity) : ProductCatalog spec = getProductSpec( itemID ) addLineItem( spec, quantity ) : Sale Require- ments Business Modeling Design Sample UP Artifact Relationships : System enterItem (id, quantity) Use Case Text System Sequence Diagrams make NewSale() system events Cashier Process Sale : Cashier use case names system operations Use Case Diagram Vision Supplementary Specification Glossary parameters and return value details starting events to design for Process Sale 1. Customer arrives 2. Cashier makes new sale. 3. What is System Sequence Diagram What is System Sequence Diagram  A diagram that shows, for ONE particular scenario of a use case, the events that external actors generate, their order, and INTER-system events. (not detailed method calls between objects)  Describe what a system does without explaining why Hoa Sen University 4 System sequence diagram System sequence diagram Hoa Sen University 5 enterItem(itemID, quantity) :System : Cashier endSale makePayment(amount) a UML loop interaction frame, with a boolean guard expression external actor to system 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 a message with parameters it is an abstraction representing the system event of entering the payment data by some mechanism description, total return value(s) associated with the previous message an abstraction that ignores presentation and medium the return line is optional if nothing is returned total with taxes change due, receipt makeNewSale [ more items ] loop Use Cases and SSDs Use Cases and SSDs Hoa Sen University 6 : Cashier :System Simple cash-only Process Sale scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays and System handles payment. enterItem(itemID, quantity) endSale makePayment(amount) description, total total with taxes change due, receipt makeNewSale [ more items ] loop Process Sale Scenario Choosing events and operation name Choosing events and operation name  System events should be expressed at the abstract level of intention rather than in terms of the physical input device Hoa Sen University 7 enterItem(itemID, quantity) scan(itemID, quantity) : Cashier worse name better name :System Iterative and Evolutionary SSDs Iterative and Evolutionary SSDs  Do not create SSDs for all scenarios (remember agile style)  SSDs are part of the Use-Case Model – Visualization of the interactions implied in the use cases scenarios Hoa Sen University 8 Operation Contract Operation Contract Hoa Sen University 9 Operation: enterItem(…) Post-conditions: - . . . Operation Contracts Sale date . . . Sales LineItem quantity 1 * 1 . . . . . . Domain Model Use-Case Model Design Model : Register enterItem (itemID, quantity) : ProductCatalog spec = getProductSpec( itemID ) addLineItem( spec, quantity ) : Sale Require- ments Business Modeling Design Sample UP Artifact Relationships : System enterItem (id, quantity) Use Case Text System Sequence Diagrams make NewSale() system events Cashier Process Sale : Cashier use case names system operations Use Case Diagram Vision Supplementary Specification Glossary starting events to design for, and more detailed requirements that must be satisfied by the software Process Sale 1. Customer arrives 2. 3. Cashier enters item identifier. the domain objects, attributes, and associations that undergo changes requirements that must be satisfied by the software ideas for the post- conditions Example Contract Example Contract  Contract CO2: enterItem  Operation: enterItem(itemID: ItemID, quantity: integer)  Cross References: Use Cases: Process Sale  Preconditions: There is a sale underway.  Postconditions: – A SalesLineItem instance sli was created (instance creation). – sli was associated with the current Sale (association formed). – sli.quantity became quantity (attribute modification). – sli was associated with a ProductDescription, based on itemID match (association formed). Hoa Sen University 10