UML collaboration/communication diagrams like UML sequence diagrams, are used to explore the dynamic nature of your software.   Collaboration diagrams show the message flow between objects in an OO application, and also imply the basic associations (relationships) between classes.  Collaboration diagrams 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 Collaboration 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 Your 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 Collaboration 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 collaboration diagram.

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

1. Indicate a Return Value Only When It Isn抰 Clear
2. Indicate Parameters Only When They Aren抰 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 Collaboration diagram represent instances of the relationships ?including associations, aggregations, compositions, and dependencies ?between classifiers.

Figure 4. A Specification-Level UML Collaboration diagram.

1. Model 揃are?Links On Instance-Level Collaboration 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

4.Recommended Resources

• Are You Ready For the MDA?
• Be Realistic About the UML
• Examining The Model Driven Architecture (MDA)
• Introduction to the Diagrams of UML 2
• Introduction to Object Orientation (OO) and UML
• Introduction to UML Collaboration/Communication Diagrams
• Modeling Style Guidelines
• Pavel Hruby's UML 2.0 Stencil for Visio
• Roadmap for Agile MDA
• Why Extend the UML Beyond Object and Component Technology?
• XP and the UML?

		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles 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 a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.
		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 techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as 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 refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.