1 / 24

Collaboration Diagrams

Collaboration Diagrams. Represent Object roles in a scenario of interactions Are synonymous to sequence diagrams Use the same message formats Used to understand the structure of a scenario Used to concentrate on what happens to each instance as a whole. Can be converted to sequence scenarios.

ulric-logan
Download Presentation

Collaboration Diagrams

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. Collaboration Diagrams • Represent Object roles in a scenario of interactions • Are synonymous to sequence diagrams • Use the same message formats • Used to understand the structure of a scenario • Used to concentrate on what happens to each instance as a whole. • Can be converted to sequence scenarios

  2. Collaboration Diagrams

  3. Contracts are documents that describe system behavior. • Contracts may be defined for system operations. • Operations that the system (as a black box) offers in its public interface to handle incoming system events. • The entire set of system operations across all use cases, defines the publicsystem interface. Contracts

  4. SSD for BuyItem use case

  5. In the UML the system as a whole can be represented as a class. • Contracts are written for each system operation to describe its behavior. System Operations and the System Interface

  6. Guidelines for Contracts

  7. A use case realization describes how a use case is realized in terms of collaborating objects. • UML interaction diagrams are used to illustrate use case realizations. • Recall Process Sale: from main scenario we identified a number of system events (operations). • Each system event was then described by a contract. Use Case Realizations

  8. A contract is a document that describes what an operation commits to achieve. • Emphasizing what will happen rather than how it will be achieved. • Contracts can be expressed by pre- and post- conditions. Contracts

  9. A Conceptual Model is a visual representation of conceptual classes or real-world objects in a domain of interest. • Contracts describe detailed system behavior in term of state changes to objects in the Domain Model, after a system operation has executed. Conceptual Model and Contracts

  10. To make contracts you have to use the conceptual model. • We added the conceptual model from previous slides to assist the comprehension of post conditions in the contracts. Utilize Conceptual Model

  11. Domain Model

  12. Contract CO2: AddLineItem Operation: addLineItem (itemID: ItemID, quantity: integer) Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway. Post-conditions: • A SalesLineItem instance sliwas created. (instance creation) • sliwas associated with the current Sale. (association formed) • sli.quantitywas set to quantity. (attribute modification) • sliwas associated with a ProductSpecification, based on itemID match. (association formed) Example: AddLineItem Contract

  13. Preconditions are assumptions about the state of the system before execution of the operation. • A Postcondition is an assumption that refers to the state of the system after completion of the operation. • The postconditions are not actions to be performed during the operation. • Describe changes in the state of the objects in the Domain Model (instances created, associations are being formed or broken, and attributes are changed). Pre- & Post- Conditions

  14. Identify system operations from the system sequence diagrams. • For each system operation, construct a contract. • Write the preconditions section. • Write the postconditions section describing the state changes that occur to concepts in the conceptual model. Postconditon categories: • Instance creation and deletion. • Attribute modification. • Associations formed and broken. How to Make a Contract

  15. After the itemID and quantity of an item have been entered by the cashier, what new objects should have been created? • A SaleLineItem instance sli was created. AddLineItemPostconditionsInstance Creation and Deletion

  16. After the itemID and quantity of an item have been entered by the cashier, what attributes of new or existing objects should have been modified? • sli.quantity was set to quantity. AddLineItemPostconditionsAttribute Modification

  17. AddLineItemPostconditionsAssociations Formed and Broken • After the itemID and quantity of an item have been entered by the cashier, what associations of new or existing objects should have been formed or broken? • sli was associated with the current Sale. • sli was associated with a ProductSpecification, based on itemID match.

  18. Assume a new sale is started, we will create a new object from the conceptual class Sale, with an ID=5. • If this sale started on the register number 3, then we have to create an association between the sale number 5 with the register number 3 (associations are established by updating foreign keys). Make New Sale Enumeration Example

  19. It is also common to discover the need to record new concepts, attributes or associations in the Domain Model. • For example: • If in one of the postconditions, you wanted to create an instance to store some values in it, and it was not presented by any Concept in the domain model. • Then you should go back and correct your domain model by adding this concept. Writing Contracts leads to Domain Model Updates

  20. The most common problem in creating contracts is forgetting to include the forming of associations. Particularly, when new instances are created, it is very likely that associations to several objects need be established. • Don’t forget to include all the associations formed and broken. The most common mistake in creating contract

  21. Contract: EndSale Operation: EndSale () Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway and all items have been entered. Post-conditions: • Sale.isComplete became true. (attribute modification) Example 1: End Sale Contract

  22. Contract: MakePayment Operation: MakePayment (amount: Number or Quantity) Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway and all items have been entered. Post-conditions: • A Payment instance p was created. (instance creation) • p.amountTendered was set to amount. (attribute modification) • p was associated with the current Sale. (association formed) • The current Sale was associated with the Store; to add it to the historical log of completed sales. (association formed) Example 2: Make Payment Contract

  23. Contract: StartUp Operation: StartUp () Cross References: Use Cases: Process Sale. Pre-conditions: None. Post-conditions: • A Store, POST, ProductCatalog and ProductSpecifications have been created. (instance creation) • ProductCatalog was associated with ProductSpecifications. (association formed) • Store was associated with ProductCatalog. (association formed) • Store was associated with POST. (association formed) • POST was associated with ProductCatalog. (association formed) Example 3: Start Up Contract

  24. Contracts describe detailed system behavior in terms of state changes to objects in the Conceptual model after a system operation. • Contracts have sections of Operations, Cross references, Preconditions and Postconditions. Postconditions are the most important section. • Postconditions describe changes in the state of objects in the Conceptual model. Summary

More Related