Xem mẫu

  1. Contracts and UML interaction diagrams Lecture 4 Hoa Sen University 1
  2. Agenda  System sequence diagram  Operation Contract  On to Object design – Interaction diagrams  Sequence diagrams  Communication diagrams Hoa Sen University 2
  3. System Sequence Diagram Sample UP Artifact Relationships Domain Model Sale 1 1..* Sales Business ... LineItem Modeling date ... ... quantity Vision Use-Case Model Process Sale Process Sale use 1. Customer case arrives ... Cashier names 2. Cashier makes new sale. 3. ... Glossary parameters and Require- Use Case Diagram Use Case Text return value details ments system events : System Operation: : Cashier enterItem(…) make Supplementary system NewSale() Specification Post-conditions: operations enterItem -... (id, quantity) Operation Contracts System Sequence Diagrams starting events to design for Design Model : Register : ProductCatalog : Sale enterItem Design (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) Hoa Sen University 3
  4. 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
  5. System sequence diagram 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 external actor to Process Sale Scenario system : Cashier :System makeNewSale a UML loop loop [ more items ] interaction enterItem(itemID, quantity) frame, with a boolean guard expression description, total endSale a message with parameters return value(s) associated with the it is an abstraction previous message total with taxes representing the system event of an abstraction that entering the ignores presentation makePayment(amount) payment data by and medium some mechanism the return line is change due, receipt optional if nothing is returned Hoa Sen University 5
  6. Use Cases and SSDs Process Sale Scenario : Cashier :System makeNewSale Simple cash-only Process Sale scenario: loop [ more items ] 1. Customer arrives at a POS checkout enterItem(itemID, quantity) with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. description, total 4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done. endSale 5. System presents total with taxes calculated. 6. Cashier tells Customer the total, and total with taxes asks for payment. 7. Customer pays and System handles payment. makePayment(amount) ... change due, receipt Hoa Sen University 6
  7. 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 :System : Cashier better name enterItem(itemID, quantity) scan(itemID, quantity) worse name Hoa Sen University 7
  8. 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
  9. Operation Contract Sample UP Artifact Relationships Domain Model Sale 1 1..* Sales Business ... LineItem Modeling date ... ... quantity Vision Use-Case Model Process Sale Process Sale use 1. Customer case arrives ... Cashier names 2. ... 3. Cashier enters item identifier. Glossary Require- Use Case Diagram Use Case Text ments ideas for system the domain events requirements the post- objects, that must be conditions attributes, satisfied by : System and the software associations Operation: : Cashier that undergo enterItem(…) make Supplementary changes system NewSale() Specification Post-conditions: operations enterItem -... (id, quantity) Operation Contracts System Sequence Diagrams starting events to design for, and more detailed requirements that Design Model must be satisfied : Register : ProductCatalog : Sale by the software enterItem Design (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) Hoa Sen University 9
  10. 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
  11. Contract definition  A description of each section in a contract is shown in the following schema.  Operation: Name of operation, and parameters  Cross References: Use cases this operation can occur within  Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. These are non- trivial assumptions the reader should be told.  Postconditions: This is the most important section. The state of objects in the Domain Model after completion of the operation. Discussed in detail in a following section. Hoa Sen University 11
  12. Contract procedure  To make contract – Identify System Operations from SSD – For system operations that are complex or subtle in their results or are not clearly express in use cases, construct a contract – To describe the post conditions, use the following categories  Instance creation and deletion  Attribute change of value  Associations (to be precise, UML links) formed and broken Hoa Sen University 12
  13. System operations Process Sale Scenario :System : Cashier makeNewSale() loop [ more items ] enterItem(itemID, quantity) these input system events invoke system operations the system event enterItem description, total invokes a system operation called enterItem and so forth this is the same as in object- oriented programming when endSale() we say the message foo invokes the method (handling operation) foo total with taxes makePayment(amount) change due, receipt Hoa Sen University 13
  14. Process Sale: makeNewSale  Contract CO1: makeNewSale  Operation: makeNewSale()  Cross References: Use Cases: Process Sale  Preconditions: none  Postconditions: – A Sale instance s was created (instance creation). – s was associated with a Register (association formed). – Attributes of s were initialized. Hoa Sen University 14
  15. Object design introduction  How do developers design objects – Code – Design-while-coding – Draw, then code – Only draw  Agile modelling: reduce drawing overhead and model to understand and communicate – Modeling with others – Creating several models in parallel – Using an internal wiki (www.twiki.org )  How much time spent drawing UML before coding? – For a three-week timeboxed iteration, spend a few hours or at most one day near the start of the iteration drawing UML for the hard, creative parts of the detailed object design Hoa Sen University 15
  16. Static vs. dynamic modelling  Dynamic models help design the logic, the behavior of the code or the method bodies – Sequence diagram, communication diagram  Static models help design the definition of packages, class names, attributes, and method signatures – UML class diagram Hoa Sen University 16
  17. Use-Case Realization  “…describes how a particular use case is realized within the design model, in terms of collaborating objects” [RUP]  Individual scenarios are realized Use case -> System events -> System sequence diagram -> System operation contracts -> Interaction diagrams -> Design classes Hoa Sen University 17
  18. System operation makeNewSale, etc., are the system operations from the SSD each major interaction diagram starts with a system operation going into a domain layer controller object, such as Register makeNewSale 1: ??? :Register Window objects or GUI widget objects ... enterItem :Register 1: ??? or Web control objects endSale 1: ??? :Register makePayment :Register 1: ??? UI LAYER DOMAIN LAYER The system operations in the SSD are used as the start messages into the domain layer If communication diagrams are used, one per system operation Same for sequence diagram Hoa Sen University 18
  19. One diagram per system operation : Register makeNewSale create : Sale Window objects or GUI widget objects ... or Web control objects : Register : ProductCatalog enterItem(...) desc = getProductDesc( itemID ) ... UI LAYER DOMAIN LAYER Hoa Sen University 19
  20. Design makeNewSale  Choosing the controller class – A façade controller is satisfactory if there are only a few system operations – Use Register here.  Creating a new Sale – Register create Sale – Sale create a collection to store SalesLineItems Hoa Sen University 20