Collaborations
Concepts
A UML collaboration consists of a set of roles and a set of interactions between objects playing the roles.
Role properties include name and type. The type of a role is usually an existing class in the model.
An interaction consists of lifelines, messages and fragments. A sequence diagram is a graphical representation (i.e., a view) of an interaction.
A lifeline represents the life of some object. Lifeline properties include name and role.
A message is sent from one lifeline to another at a particular point in time.
Example: A Simple Client-Server Collaboration (view tutorial)
The following class diagram shows the structure of a simple client-server model:
The following sequence diagram shows two lifelines. Lifeline1 is the lifeline of an object that plays Role1 of type Client and Lifeline2 is the lifeline of an object that plays Role2 of type Server. Time runs downward along the lifelines.
The diagram shows Lifeline1 invoking the serviceA method of Lifeline2. An activation box on Lifeline2 shows the period of time that the method is running. Near the end, Lifeline2 sends the result as a reply message back to Lifeline1:
Alternatively, we can specify the variable where the returned value should be stored:
We would expect to see the following line of code inside some Client method:
result = server.ServiceA(arg);
Of course an object can call one of its own methods:
Message Types
There are six types of messages objects can send:
Messages and signals are both examples of UML events (as are state changes and timing events).
Events can be internal (caused from within the system) or external (caused by an external actor).
Events can be synchronous (happen predictably) or asynchronous (happen unpredictably). (A different—and common-- interpretation is that synchronous, messages cause the sender to block waiting for a reply, while an asynchronous message or signal simply passes information to the recipient without waiting for a reply.)
Messages correspond to method invocations. An example of an asynchronous message might be a method invoked by an external actor that can happen at any time. A synchronous message is usually a method invoked by another object inside the system.
The difference between signals and messages is that the sender knows the recipient of a message, but not of a signal. Examples of signals include throwing an exception or broadcasting a state change or timing event. Signals are usually asynchronous.
Calling a constructor is an example of a create message while calling a destructor in C++ is an example of a delete message:
Server *server = new Server();
//...
delete server;
Combined Fragments
A combined fragment allows us to describe a limited amount of control logic: iteration (loop), 1-way conditional (alt), multi-way conditional (opt), parallel (par), etc.
A combined fragment may contain several operands (boxes separated by dashed lines) showing alternate interactions. Operands usually have guard conditions that determine which operand gets executed.
The generated (by me) code looks like this:
class Server {
private boolean isValid(String arg) {
return true; // for now
}
public String serviceA(String arg) {
if (isValid(arg)) {
// compute result
return result;
} else {
return "error";
}
}
// etc.
}
Here's an example of a combined loop fragment. Loop fragments generally have a single operand guarded by the loop condition:
The generated code in some client method might look like this:
do {
result = server.serviceA(arg);
} while(result == "busy")
Guards & Iteration
Starting with version 2.4 of StarUML 2 it appears iterated messages are back:
The generated code might look like this:
if (authorized) server.service1();
while (busy) server.service2();
Example
Client-Proxy-Server Collaboration
Applications
Collaborations implement components.
Design patterns are recurring collaborations.
Lectures
A collaboration model consists of a class diagram and a sequence diagram.