UML Communication Diagram: Diagramming Guidelines

• Provide a birds-eye view of a collection of collaborating objects, particularly within a real-time environment.
• Allocate functionality to classes by exploring the behavioral aspects of a system.
• Model the logic of the implementation of a complex operation, particularly one that interacts with a large number of other objects.
• Explore the roles that objects take within a system, as well as the different relationships they are involved with when in those roles.

There are guidelines for:

1. General issues
2. Messages
3. Links

1. General

Figure 1. An Instance-Level UML Communication diagram.

1. Use Instance-Level Diagrams To Explore Object Design Issues. Instance-level UML Collaboration diagrams, such as the one shown in Figure 1, depict interactions between objects (instances). Instance-level diagrams are typically created to explore the internal design of object-oriented software.
2. Use Specification-Level Diagrams to Explore Roles. Specification-level UML Collaboration diagrams, such as the one shown in Figure 4, are used to analyze and explore the roles taken by domain classes within a system.
3. Collaboration Diagrams Do Not Model Process Flow.
4. When Sequence Is Important Use a Sequence Diagram.
5. Apply Sequence Diagram Guidelines To Instance-Level Collaboration Diagrams. Because UML Collaboration diagrams depict an alternate view of the same information as UML Sequence diagrams much of the same style advice applies. The following lists of guidelines, originally presented for UML Sequence diagrams, are applicable to collaboration diagrams:

• Name Objects When You Reference Them In Messages
• Name Objects When Several of the Same Type Exist
• Apply Textual Stereotypes Consistently
• Apply Visual Stereotypes Sparingly
• Focus on Critical Interactions
• Prefer Names Over Types for Parameters
• Indicate Types as Parameter Placeholders
• Do Not Model a Return Value When it is Obvious What is Being Returned
• Model a Return Value Only When You Need to Refer to it Elsewhere
• Model Return Values as Part of a Method Invocation
• Indicate Types as Return Value Placeholders

2. Messages

Figure 2 presents the notation for invoking messages on UML communication diagrams. For example in Figure 1 the message 1.2: orderTotal := calculateTotal() indicates a sequence number of 1.2, there is no loop occuring, a return value of orderTotal and an invoked method named calculateTotal().

Figure 2. The basic notation for invoking a message on a communication diagram.

Figure 3. A UML communication diagram depicting concurrent message invocations.

1. Indicate a Return Value Only When It Isn’t Clear
2. Indicate Parameters Only When They Aren’t Clear
3. Depict an Arrow For Each Message
4. Consolidate Getter Invocations. When you have several getters invoked in a row a good short cut is to model a single message such as getInfo() in Figure 1 to act as a placeholder.
5. Indicate Concurrent Threads With Letters. In Figure 3 you see that some messages are preceded by the letters A, B, C, and D indicating that those messages are being processed concurrently.

3. Links

The lines between the classifiers depicted on a UML communication diagram represent instances of the relationships – including associations, aggregations, compositions, and dependencies – between classifiers.

Figure 4. A Specification-Level UML communication diagram.

1. Model “Bare” Links On Instance-Level Communication Diagrams
2. Show Role-Pertinent Information on Specification-Level Diagrams. In Figure 4 you see that the roles taken by classes as well as the high-level multiplicities (either blank or an asterisk to represent many) are depicted.
3. Prefer Roles on Links Instead of Within Classes
4. Indicate Navigability Sparingly
5. Links Should Be Consistent Static Relationships