UML Collaboration Diagrams

A major task of the design phase is creating the interaction diagrams for the system operations. Read this section to learn more about collaboration diagrams. As you review the examples, consider general principles in assigning responsibilities. Ask yourself, how do you determine the relationship between objects? How can you extract the classes? How do you determine whether a mentioned feature can be considered a class attribute? How would you determine class methods?

A Design of POST System

With "Buy Items with Cash" and "Start Up" use cases, we have identified four system operations enterItem, endSale, makePayment and startup as shown in Figure 3.13. According to our guidelines we should construct at least four collaboration diagrams. This activity will demonstrate only one operation and the remaining will be provided with the final collaboration diagrams. According to the Controller pattern, the POST class could be chosen as controller for handling these operations and hereby presented in Figure 4.16.

Figure 4.16: POST as a Controller Class

POST

enterItem()
endSales()
makepayment()
startUP()

We need to look at the contract of enterItem what POST needs to do to fulfill this responsibility (See Table 4.4).

Table 4.4: Post-Condition for "enterItem" Operation

Post-conditions: If a new sale, a Sale was created (instance creation).
If a new Sale, the Sale was associated with the POST (association formed).
A SalesLineItem was created (instance creation).
The SalesLineItem.quantity was set to quantity (attribute modification).
The SalesLineItem was associated with a ProductSpecification, based on UPC match (association formed).

Creating a New Sale: 

  • The post-conditions of enterItem indicate a responsibility for creation of an object Sale.
  • The Creator pattern suggests POST is a reasonable candidate creator of the Sale, as POST records the Sale. 
  • Having POST created the Sale; the POST can easily be associated with it over time. 
  • Creating a New SalesLineItem: 
  • When the Sale is created, it must create an empty collection to record all the future SaleLineItem that will be added. 
  • This collection will be maintained by the Sale instance, which implies by Creator that the Sale is a good candidate for creating it (SalesLineItem).

Figure 4.17 shows the creation of a new sale by the POST controller class and a new SalesLine Item by a Sale class. 

Figure 4.17 shows the creation of a new sale by the POST controller class and a new SalesLine Item by a Sale class.


Finding a ProductSpecification 

  • Newly created SalesLineItem is required to be associated with ProductSpecification that matches with upc 
  • This need the parameters to the makeLineItem message sent to the Sale include ProductSpecification instance denoted by sec, which matches upc 
  • We need to retrieve the ProductSpecification before the message makeItem(spec,qty) is sent to Sale
  • From Expert pattern, ProductCatalog contains all the productSpecification, hence good candidate for looking up the ProductSpecification

 

Visibility to a ProductCatalog 

  • From startUp() contract it shows POST was associated with the ProductCatalog 
  • POST is responsible in sending message to ProductCatalog denoted by specification
Hence the collaboration Diagram for enterItem will be as shown in Figure 4.18


Figure 4.18: Collaboration Diagram for enterItem Operation

Figure 4.18: Collaboration Diagram for enterItem Operation

Figure 4.20: Collaboration Diagram for makePayment Operation

Figure 4.20: Collaboration Diagram for makePayment Operation

Collaboration Diagram for Logging a complete sale will be as shown in Figure 4.21

Figure 4.21: Logging a Complete Sale Collaboration Diagram

Figure 4.21: Logging a Complete Sale Collaboration Diagram

Collaboration Diagram for StartUp will be as shown in Figure 4.22.

Figure 4.22: Collaboration Diagram for StartUp Operation

Figure 4.22: Collaboration Diagram for StartUp Operation