UML Collaboration Diagrams
Site: | Saylor Academy |
Course: | CS302: Software Engineering |
Book: | UML Collaboration Diagrams |
Printed by: | Guest user |
Date: | Friday, February 4, 2022, 6:13 PM |
Description
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 go through the examples, pay attention to 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 as a class attribute or not? How would you determine class methods?
Table of contents
- 1. Introduction
- 2. Types of Interactive Diagrams
- 3. Collaboration Diagrams
- 4. UML Notation for Collaboration Diagrams
- 5. Conclusion
- 6. Overview of Design Phase
- 7. Creation of Collaboration Diagrams
- 8. General Principles in Assigning Responsibilities
- 9. Conclusion
- 10. Application of Patterns in Design
- 11. A Design of POST System
- 12. Conclusion
1. 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 later (how) is specified by an interaction
diagrams in UML. A major task of the design phase is to create the interaction diagrams for the system operations.
Source: Ellen Ambakisye Kalinga, https://oer.avu.org/bitstream/handle/123456789/667/CSI%203104_EN%20Object%20Oriented%20Analysis%20and%20Design1.pdf?sequence=1&isAllowed=y
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
2. 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
Type | Strengths | Weaknesses |
Sequence Diagram | Clearly shows sequence or time ordering of messages Simple notation |
Forced to extend to the right when adding new objects; consumes horizontal space |
Collaboration Diagram | Space economy – flexibility to add new objects in two dimensions
Better to illustrate complex branching, iteration, and concurrent behaviour |
Difficult to see sequence of messages
More complex notation |
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
System Sequence Diagrams | Object Sequence Diagrams |
Illustrates the interaction between the whole system and external actors | Shows the interactions between objects of the system
|
Shows only system's external events and thus identifies system operations | Identifies operations of objects
|
Are created during the analysis phase | Are models created and used in the design phase |
3. 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
4. UML Notation for Collaboration Diagrams
Collaboration diagrams have basic notations as presented in Figure 4.1. Basic notations include:
- Instances: is the same object but the name is being underlined and it has to always preceded 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 message are sent.
- Parameter: Parameters are shown within parentheses following the message.
A collaboration diagram has more notations which can be used when need comes as follows:
Representing a return value
Some message sent to an object may require a returning 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 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
5. Conclusion
Collaboration diagrams are mainly used in 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 facilitate assigning responsibility to objects.
6. Overview of Design Phase
Introduction
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.
7. 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 creation a collaboration diagram and the collaboration diagram represents both of 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
8. General Principles in Assigning Responsibilities
Patterns are best principles for assigning responsibilities to objects. Patterns are guide 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 assignment of responsibilities. Expert class is that class that has information necessary to fulfill the responsible. 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. 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 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 few methods to a class and delegate parts of the work to fulfill the responsibility to other classes.
The following "liftController" class in Figure 4.12 is not well designed. A class does a lot of work.
LiftController | |
getFloor() moveLift() setTrip() emergencyProcedure() raiseAlarm() udateLed() openDoors() closeDoors() reset() startUP() shutDown() displayLog() |
Figure 4.12: The Lift Controller Class with Low CohesionNote that a class should represent one "thing" from the real would. 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 in 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 receive external input events, typically involving a GUI operated by a person.
Controller pattern takes the following form:
Table 4.3: Controller Pattern
Pattern Name | Controller |
Solution |
Assign the responsibility for handling a system (input) event to a class representing one of the following choices
|
Problem | Who should be responsible for handling a system input event? |
9. Conclusion
A pattern is a well used procedure in collaboration diagrams. It is a solution to a common occurring problem. Five basis patters 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.
10. Application of Patterns in Design
Introduction
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 diagram: The same guideline is summarized in Figure 4.15.
- Create a separate diagram for each system operation which has 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
11. 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: PPOST 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 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 show 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
Collaboration Diagram for endSale will be as shown in Figure 4.19.
Figure 4.19: Collaboration Diagram for endSale 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
12. 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 creating collaboration diagrams for a single system operation for the purpose of
assigning responsibilities to collaborating object while performing a functionality.