The Agile Modeling (AM) Method

UML Communication Diagram: Diagramming Guidelines

UML communication diagrams like UML sequence diagrams, are used to explore the dynamic nature of your software. Communications diagrams show the message flow between objects in an OO application, and also imply the basic associations (relationships) between classes. Communication diagrams, formerly called collaboration diagrams in UML 1.x, are often used to:

  • 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.

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.

sequenceNumber loopIndicator: returnValue := methodName(parameters)

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 ABC, 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

Recommended Reading

Modeling style: Elements of UML 2.0 Style The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are sound, proven strategies that lead to diagrams that are easier to understand and work with. These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler. This book is oriented towards intermediate to advanced UML modelers. Although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer). The book is 188 pages long and is conveniently pocket-sized so it’s easy to carry around.
Choose Your WoW! 2nd Edition This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) – Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile® (DA™) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.
The Object Primer 3rd Edition: Agile Model Driven Development (AMDD) with UML 2 The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams. Furthermore, this book describes the fundamental programming and testing techniques for successful agile solution delivery. The book also shows how to move from your agile models to source code, how to succeed at implementation techniques such as refactoring and test-driven development(TDD). The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoringobject/relational mappinglegacy analysis, and database access coding) from my award-winning Agile Database Techniques book.