UML Collaboration Diagrams

Introduction

A contract for system operations describes what the system operation does, but it does not show a solution of how software objects are going to work collectively to fulfill the contract of the operation. The latter (how) is specified by an interaction diagram in UML. A major task of the design phase is to create the interaction diagrams for the system operations.

Source: Adapted from Ellen Ambakisye Kalinga
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

Types of Interactive Diagrams

As explained in activity 2.2: UML diagrams, the UML define two kinds of interaction diagrams: Collaboration diagrams and sequence diagrams, either of which can be used to express similar or identical messages interactions. 

Each type has strengths and weaknesses as shown as indicated in Table 4.1:

• When drawing diagrams to be published on pages of narrow width, collaboration diagrams have the advantage of allowing vertical expansion for new objects 
• Additional objects in a sequence diagram must extend to the right, which is limiting. 
• On the other hand, collaboration diagram examples make it harder to easily see the sequence of messages.

Table 4.1: Sequence Diagram Versus Collaboration Diagram

We have used system sequence diagrams in object oriented analysis, but now we are referring to another name object sequence diagram. Table 4.2 describes the difference between the system sequence diagram and object sequence diagram. You can note that the object sequence diagram is being used at design phase.

Table 4.2: Difference Between System Sequence Diagram and Object Sequence Diagram

Collaboration Diagrams

A collaboration diagram is a graphical representation which shows the linkage between a number of objects and the links between them. Collaboration diagrams show the messages that are passed from one object to another. Since both collaboration diagrams and object sequence diagrams can express similar constructs, we can opt to use one over the other. We shall mainly discuss and use collaboration diagrams. As an example, collaboration diagram for "makePayment(cashTendered)" operation for the POST system is shown in Figure 4.1

Figure 4.1: A Collaboration Diagram for makePayment(cashTendered) Operation

While in comparison with the object sequence diagram for "makePayment(cashTendered)" operation for the POST system we can have as shown in Figure 4.2.

Figure 4.2: A Object Sequence Diagram for makePayment(cashTendered) Operation

Both of the two diagrams represent the following pseudo program 

• POST accepts a call of it method makePayment() (from an Interface Object); 
• POST calls for the method makePayment() of :Sale; 
• Sale calls the constructor of class Payment to create a new:Payment

UML Notation for Collaboration Diagrams

Collaboration diagrams have basic notations, as presented in Figure 4.1. Basic notations include: 

• Instances: Represented the same as an object or class, but the name is underlined and always followed by a colon.
• Links: This is a connection path between two objects to show some form of navigation and visibility instances. 
• Message: messages are represented using an arrow on the link line. Messages are numbered to show the sequential order in which the messages are sent.
• Parameter: Parameters are shown within parentheses following the message.

A collaboration diagram has more notations that can be used when need comes as follows:

Representing a return value 

Some messages sent to an object may require a return message. A return value may be shown by preceding the message with a return value variable name and an assignment operator (':=') as shown in Figure 4.3. The standard syntax for messages is:

Figure 4.3: Return Values in Collaboration Diagram

Representing iteration 

An object may repeatedly send a message to another object a number of times. This is indicated by prefixing the message with a start ('*') as in Figure 4.4.

Figure 4.4: Representing Iteration in Collaboration Diagram Representing the creation of instances

The UML creation message is create, which is independent of programming languages, shown being sent to the instance being created. Optionally, the newly created instance may include a < > symbol as shown in Figure 4.5. A create message can optionally take parameters when some attributes of the object to be created need to be set an initial value

Figure 4.5: Creation of an Instance in Collaboration Diagram

Representing message number sequencing 

The order of messages is illustrated with sequence numbers, as shown in Figure. The numbering scheme is: 

i. The first message is not numbered. Thus, msg1() is unnumbered.

ii. The order and nesting of subsequent messages is shown with a legal numbering scheme in which nested messages have appended to them a number. Nesting is denoted by pre-pending the incoming message number to the outgoing message number.

Figure 4.6: Message Number Sequencing in Collaboration Diagram

Representing conditional messages 

Sometimes, a message may be guarded and can be sent from one object to another only when a condition holds. At a point during the execution of an object, a choice of several messages, guarded by different conditions, will be sent. In a sequential system, an object can send one message at a time and thus these conditions must be mutually exclusive. When we have mutually exclusive conditional messages, it is necessary to modify the sequence expressions with a conditional path letter.

Figure 4.7: Conditional Message in Collaboration Diagram

Note that: 

• Either 1a or 1b could execute after msg1() , depending on the conditions. 
• The sequence number for both is 1, and a and b represent the two paths. 
• This can be generalized to any number of mutually exclusive Conditional Messages.

Representing multiobjects 

We call a logical set of instances/objects as a multiobject. A multiobject is an instance of a container class; each instance of which is a set of instances of a given class (or type). E.g. SetOfSales is a class each instance of which is a set of sales. Each multiobject is usually implemented as a group of instances stored in a container or a collection object. In a collaboration diagram, a multiobject represents a set of objects at the "many" end of an association. In UML, a multiobject is represented as a stack icon as illustrated in Figure 4.8.

Figure 4.8: Multiobject and Message to Multiobject

Conclusion

Collaboration diagrams are mainly used during the object-oriented design phase. They are flexible to add new concepts in two dimensions, hence occupy less space.  In design phase, objects are supposed to be provided with operations to perform. Collaborations are easily used for this purpose with the help of a Pattern which facilitates assigning responsibility to objects.

Overview of Design Phase

Complex system operations must be decomposed into simpler internal operations which are assigned to (or carried out by) objects. The major task in the design is to create the collaboration diagrams for the system operations identified in the requirement analysis phase. The most important and difficult part in the generation of collaboration diagrams is the assignment of responsibilities to objects. This activity discusses the general principles for responsibility assignment, which are structured in a format called patterns.

Artifacts needed for creating collaboration diagrams: 

(a) Conceptual model: In this, software classes corresponding to concepts are defined. 

(b) System operations contracts: which deals with the identification of responsibilities and post conditions that the interaction diagrams must fulfill 

(c) Essential (or real) use cases: Involves collection of information about what tasks the interaction diagrams fulfill, in addition to what is in the contracts

GRASP: Patterns for Assigning Responsibilities 

Deciding what methods belong where and how objects should interact is terribly important and trivial. Assigning responsibility is a crucial/critical step in developing object-oriented systems. 

By definition; a responsibility is a contract or obligation of an object. Responsibilities are related to the obligations of objects in terms of their behaviour. The purpose is to help methodically apply fundamental principles for assigning responsibilities to objects. Within the UML artifacts, a common context where these responsibilities (implemented as methods) are considered is during the creation of interaction diagrams. Responsibilities can be grouped into two main types:

Doing responsibilities: These are about the actions that an object can perform including: doing something itself such as creating an object or doing a calculation, initiating an action or operation in other objects, controlling and coordinating activities in other objects 

Knowing responsibilities: These are about the knowledge an object maintains: knowing about private encapsulated data, knowing about related objects, knowing about things it can derive or calculate.

Creation of Collaboration Diagrams

When creating collaboration diagrams: 

• Start with the responsibilities which are identified from the use cases, conceptual model, and system operations' contracts. 
• Assign these responsibilities to objects, then: 
• Decide what the objects need to do to fulfill these responsibilities in order to identify further responsibilities which are again assigned to objects. 
• Repeat these steps until the identified responsibilities are fulfilled and a collaboration diagram is completed.

Responsibilities are assigned to classes of objects during object oriented design stage. Note that a responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities. Responsibilities of an object are implemented by using methods of the object which either act alone or collaborate with other methods and objects. For example, with reference to POST system:

• The Sale class might define a method that is performing printing of a Sale instance; say a method named print., 
• To fulfill that responsibility, the Sale instance may have to collaborate with other objects, such as sending a message to SalesLineItem objects asking them to print themselves.

Within UML, responsibilities are assigned to objects when creating a collaboration diagra.  The collaboration diagram represents both the assignment of responsibilities to objects and the collaboration between objects for their fulfillment. Example, as presented in Figure 4.9: 

Sale objects have been given a responsibility to print themselves, which is invoked with a print message. 

The fulfillment of this responsibility requires collaboration with SalesLineItem objects asking them to print.

Figure 4.9: Performing Print Operation on Each Object of a Multiobject

General Principles in Assigning Responsibilities

Patterns are best principles for assigning responsibilities to objects. Patterns are guides to the creation of software methods. They are best principles for assigning responsibilities to objects. They are solutions to common occurring problems. In view of this module the GRASP patterns: General Responsibility Assignment Software Patterns is going to be applied. GRASP pattern takes the following format: 

Pattern Name: The name given to the pattern 

Solution: Description of the solution of the problem 

Problem: Description of the problem that the pattern solves

Most simply, a pattern is a named problem/solution pair that can be applied to new context, with advice on how to apply it in novel situations. GRASP patterns include the following five basic patterns: 

1. Expert, 
2. Creator, 
3. High Cohesion 
4. Low Coupling and 
5. Controller.

GRASP 1: Expert 

This is a very simple pattern and is being used more than any other pattern in the assignment of responsibilities. Expert class is that class that has information necessary to fulfill the responsibilities. Experts do things relating to the information they know. Assign a responsibility to the information expert ­– the class that has the information necessary to fulfill the responsibility. Example is as shown in Figure 4.10.:

Figure 4.10: Collaboration Diagram for Getting the price of a product

GRASP 2: Creator 

The creation of objects is one of the most common activities in an OO system. It asks the question "who should be responsible for creating instances of a particular class?" Assign class B the responsibility to create an instance of class A if one of these is true:

• B contains A 
• B records A 
• B aggregates A 
• B closely uses A 
• B has the initializing data for A

For example in POST system, who should be responsible for creating a SalesLineIteM instance? By Creator pattern, we should look for a class that aggregates, contains SalesLineItem instances. Since Sale contains (aggregates) many SalesLine Item objects, the creator pattern suggests that Sale is the right candidate to have the responsibility of creating SalesLine Items instances as in Figure 4.11. This means "makeLineItem" method will be defined in Sale.

GRASP 3: High Cohesion 

Cohesion or coherence is the strength of dependencies within a subsystem. Cohesion is a measure of how strongly related and focused the responsibilities of a class are. It is the internal "glue" with which a subsystem is constructed. A component is cohesive if all its elements are directed towards a task and the elements are essential for performing the same task. If a subsystem contains unrelated objects, coherence is low. High cohesion is desirable. 

A class with high cohesion has highly related functional responsibilities, and does not do a tremendous amount of work. Such classes have a small number of methods with simple but highly related functionality. In a good object-oriented design, each class should not do too much work. Assign a few methods to a class and delegate parts of the work to fulfill the responsibility of other classes.

The following "liftController" class in Figure 4.12 is not well designed. A class does a lot of work.

Figure 4.12: The Lift Controller Class with Low Cohesion Note that a class should represent one "thing" from the real world.Key separate abstractions from liftController as shown in Figure 4.13 are:

• An Alarm
• Lift
• Doors and
• Logs

Figure 4.13: The Lift Controller Class Modelled as a Four Separate, More Cohesive Classes

GRASP 4: Low Coupling 

Coupling is a measure of how strongly one class is connected to; has knowledge of; or relies on other classes. A class with low (or weak) coupling is not dependent on too many other classes. When we assign a responsibility to a class, we would like to assign responsibilities in a way so that coupling between classes remains low. 

From the following example for "makePayment" use case and with the consideration of low coupling, the second design is preferable because it does not need an extra link formed between POST and Payment. This assignment of responsibility is also justifiable as it is reasonable to think that a Sale closely uses a Payment (Figure 4.14).

GRASP 5: Controller

 Who handles a system event? Assign the responsibility for handling a system event message to a class representing one of these choices:

• Represents the overall system, device, or a subsystem (facade controller). 
• Represents a use case scenario within which the system event occurs (use-case or session controller)

A controller is a non-user interface object responsible for handling a system input events, and the controller defines the method for the system operation corresponding to the system input event. One possible solution is to add/introduce a new class, and make it sit between the actor and the business classes. The name of this controller is usually called Handler. Handler reads the commands from the user and then decides which classes the messages should be directed to. The handler is the only class that will be allowed to read and display. The system receives external input events, typically involving a GUI operated by a person.

Controller pattern takes the following form:

Table 4.3: Controller Pattern

Conclusion

A pattern is a well used procedure in collaboration diagrams. It is a solution to a common occurring problem. Five basic patterns under GRASP patterns have been described, these are Expert, Creator, High Cohesion, Low Coupling and Controller. You need to be careful when using patterns so as to develop a modifiable and robust object-oriented design.

Application of Patterns in Design

This activity shows how to apply GRASP patterns to assign responsibilities to object. It does the actual application in a POST case project system. As done by Liu, the design is going to consider "Buy Item with Cash" and "Start Up" use cases.

From activity 4.2, the following can be highlighted as a guideline for making collaboration diagrams:The same guideline is summarized in Figure 4.15. 

• Create a separate diagram for each system operation which has been identified and whose contracts are defined.
• If the diagram gets complex, split it into smaller diagrams. 
• Using the contract responsibilities and post-conditions, and use case description as a starting point, design a system of interacting objects to fulfill the tasks. 
• Apply the GRASP to develop a good design.

Note that this areas if fully adopting the design made by Liu,

Figure 4.15: Guidelines for design

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

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

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.

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

Figure 4.18: Collaboration Diagram for enterItem 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

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

Figure 4.22: Collaboration Diagram for StartUp Operation

Conclusion

Application of a GRASP pattern has been demonstrated in this activity. The main input to this activity is the information from post condition of the system operation. We create collaboration diagrams for a single system operation, for the purpose of assigning responsibilities to collaborating objects while performing a functionality.