UML Collaboration Diagram

UML Collaboration diagrams (interaction diagrams) illustrate the relationship and interaction between software objects. They require use cases, system operation contracts, and domain model to already exist. The collaboration diagram illustrates messages being sent between classes and objects (instances). A diagram is created for each system operation that relates to the current development cycle (iteration). When creating collaboration diagrams, patterns are used to justify relationships. Patterns are best principles for assigning responsibilities to objects and are described further in the section on patterns. There are two main types of patterns used for assigning responsibilities which are evaluative patterns and driving patterns. Each system operation initiates a collaboration diagram. Therefore, there is a collaboration diagram for every system operation. An example diagram for purchasing a bus ticket.

The route and seat objects are multi objects which means they are a collection of objects. The message, "purchaseTicket(route, preference) is the initializing message which is generated by the initializing actor. All other messages are generated by the system between objects. The initializing message is not numbered. The first message after the initializing message is numbered. Messages that are dependent on previous messages are numbered based on the number of the message they are dependent on. Therefore the message, "r=findRoute(route)" is numbered "1.1" since it is dependent on the message "s=findSeat(route, preference)". Any message path that is mutually exclusive is numbered with an "a" or "b". In finding route and seat messages, if finding a route or a seat were mutually exclusive, the numbering would be 1.1a and 1.1b. Patterns used for the association are associated with the message using a note.

• Creation messages - "create(parameter)"
• Iteration - Designated with a message line like: "1* [i:=1..5]: message3()"
  • Grouped - Although on two separate lines connecting objects both messages use the same variable such as the following two messages:
    • 1* [i=1..5]: message3()
    • 2* [i=1..5]: message3()
  • Separate - Written on two seperate lines connecting objects each message uses a different variable name:
    • 1* [i=1..5]: message3()
    • 2* [j=1..5]: message3()
• Messages to self.
• Messages to multiobjects - The message is to the container, not the object in the container. (add, find, remove, next, size, contains)

The diagram should be split if it gets too large.