Collaboration diagram UML

The main feature of the diagram of cooperation is the ability to graphically represent not only the sequence of interaction, but also all the structural relations between the objects participating in this interaction.

First of all, in the cooperation diagram, rectangular objects depict the objects participating in the interaction, containing the name of the object, its class and, possibly, attribute values. Further, as in the class diagram, the associations between the objects are indicated in the form of various connecting lines. In this case, you can explicitly specify the names of the associations and the roles played by the objects in the given association. Additionally, dynamic links — message flows — can be depicted. They are also represented in the form of connecting lines between the objects, above which is located an arrow indicating the direction, the name of the message and the sequence number in the overall sequence of message initialization.

In contrast to the sequence diagram, only relations between objects that play certain roles in the interaction are depicted in the cooperation diagram. This chart does not indicate time as a separate measurement. Therefore, the sequence of interactions and parallel threads can be determined using sequence numbers. Therefore, if it is necessary to explicitly specify the relationships between objects in real time, it is better to do this in the sequence diagram.

Cooperation

The concept of collaboration (collaboration) is one of the fundamental concepts in UML. It serves to designate the set of objects interacting with a specific goal in the general context of the simulated system. The goal of the cooperation itself is to specify the features of the implementation of individual most significant operations in the system. Cooperation defines the structure of the system behavior in terms of the interaction of participants in this cooperation.

Cooperation can be presented at two levels:

• specification level — shows the roles of classifiers and the role of associations in the interaction under consideration;
• example level - indicates instances and relationships that form separate roles in cooperation.

The specification level collaboration diagram shows the roles that the elements involved in the interaction play. The elements of cooperation at this level are classes and associations, which designate the separate roles of classifiers and associations between the participants of cooperation.

An example level cooperation diagram is represented by a collection of objects (instances of classes) and relationships (instances of associations). At the same time communications are supplemented with message arrows. At this level, only objects that are directly related to the implementation of the operation or classifier are shown. At the same time, it is not at all necessary to depict all properties or all associations, since only the roles of classifiers are present in the cooperation diagram, but not the classifiers themselves. Thus, while the classifier requires a complete description of all its instances, the role of the classifier requires the description of only those properties and associations that are necessary for participation in a separate cooperation.

This implies an important consequence. The same set of objects can participate in various cooperations. Depending on the cooperation in question, both the properties of individual objects and the relationships between them can change. This is what distinguishes the cooperation diagram from the class diagram in which all properties and associations between the elements of the diagram should be indicated.

The specification-level cooperation is depicted in the diagram as a dotted ellipse, inside which the name of this cooperation is recorded. This view of cooperation relates to a separate use case and details the features of its subsequent implementation. The symbol of the cooperation ellipse is connected by segments of the dotted line with each of the participants of this cooperation, which can be objects or classes. Each of these dashed lines is marked with a participant’s role. Roles correspond to the names of the elements in the context of the whole cooperation. These names are interpreted as parameters that limit the specification of elements for any appearance in separate model representations.

A simple class in a cooperation diagram is indicated by a class rectangle within which a line of text is written. This line of text is called the classifier role. The role of the classifier shows the peculiarity of using objects of this class. Usually only a section of the class name is shown in a rectangle, although the possibility of specifying sections of attributes and operations is not excluded.

A line of text in a rectangle should have the following format:

'/' ':'

[':' ] *

Here the classifier name, if necessary, may include the full path of all nested packages. In this case, one packet from the other is separated by a double colon " :: ". In some cases, it can be limited to indicating only the closest package to which this cooperation belongs. The symbol "*" is used to indicate the possibility of iteratively repeating the name of the classifier.

If cooperation allows a generalized representation, then the diagrams can indicate the generalization of the corresponding elements. This method can be used to identify individual cooperatives that are a special case or specialization of another cooperation. Such a situation is depicted by the usual generalization arrow, directed from the symbol of a subsidiary cooperation to the symbol of ancestral cooperation. The roles of subsidiary cooperatives may be specializations of the roles of ancestral cooperatives.

In some cases, it is necessary to clearly indicate the fact that cooperation is the implementation of a certain operation or classifier. This can be represented in one of two ways.

First, you can connect the cooperation symbol with a dashed line with an arrow of generalization with the class symbol, the operation of which is specified by this cooperation.

Secondly, you can simply portray the symbol of cooperation, within which you can specify all the necessary information recorded according to certain rules. These rules define the format of the name of the collaboration, followed by the colon and the name of the class. The class name is followed by a double colon and the name of the operation.

Such a general idea of ​​cooperation at the specification level is used in the initial design stages. In the following, each of the cooperatives is subject to detail at the level of examples, which reveals the content and structure of the interrelationships of its elements in a separate cooperation diagram. In this case, the elements of a cooperation diagram are objects and links, supplemented by messages.

Objects

As noted above, the object (object) is a separate instance of the class that is created at the stage of program execution. It can have its own name and specific attribute values. In relation to objects, the formatting string format is supplemented with the object name and takes the following form (the whole record is underlined):

[':' ] *

The name of a role can be omitted if there is only one role in cooperation that can be played by objects created on the basis of this class.

Thus, to designate the role of a classifier, it is sufficient to specify either the class name (along with a colon) or the name of the role (along with a slash). Otherwise, the rectangle will correspond to the normal class. If the role that the object should play is inherited from several classes, then all of them should be specified explicitly and separated by a comma and a colon.

Below are possible options for writing a string of text in the object's rectangle:

• : C is an anonymous object formed on the basis of class C;

• / R - an anonymous object that plays the role of R;

• / R: C - an anonymous object formed on the basis of class C and playing the role of R;

• O / R - an object named O, playing the role of R;

• O: C - an object with the name O, formed on the basis of the class C;

• O / R: C - an object with the name O, formed on the basis of class C and playing the role of R;

• O or - object with the name O;

• O: - “orphan object” with the name O;

• / R - the role named R;

• : C - anonymous role based on class C;

• / R: C - a role named R based on class C.

A multiobject is a multitude of objects at one of the ends of an association. In the cooperation diagram, a multi-object is used to show operations and signals that are addressed to the whole set of objects, and not just one. A multiobject is represented by two rectangles, one of which stands for the right top vertex of the other. The message arrow refers to the entire set of objects that denote this multi-object. The relationship chart can clearly indicate the composition relationship between a multi-object and an individual object from its set.

In the context of the UML language, all objects are divided into two categories: passive and active .

The passive object operates only with data and cannot initiate the activity of controlling other objects. However, passive objects can send signals during the execution of requests that they receive.

The active object has its own control thread and can initiate activities to control other objects. By thread here is meant some lightweight control flow that can run in parallel with other computational threads or control threads within one computational process or control process.

Active objects on canonical diagrams are indicated by a rectangle with wider borders. Sometimes the keyword {active} can be explicitly specified to highlight the active object in the diagram. Each active object can initiate a single thread or control process and represent the starting point of the control flow.

A composite object or a container object is intended to represent an object that has its own structure and internal threads (threads) of control. A composite object is an instance of a composite class (container class) that is related by an aggregation or composition relationship with its parts. Similar relationships link together the corresponding objects.

In the cooperation diagrams, the compound object is depicted as a normal object consisting of two sections: the top and bottom. In the upper section, the name of the composite object is recorded, and in the lower section, instead of a list of attributes, its components. It is also allowed to have other composite objects as components.

Connections

A link is an instance or example of an arbitrary association. Communication as an element of the UML language can take place between two or more objects. The binary connection in the cooperation diagram is represented by a straight line segment connecting two rectangles of objects. At each end of this line, the names of the roles of this association can be explicitly indicated. Next to the line in its middle part can be written the name of the corresponding association.

Relationships do not have proper names, since they are completely identical as instances of an association. In other words, all links in a cooperation diagram can only be anonymous and are written without a colon before the name of the association. For relationships, the multiplicity is also not indicated. However, other designations of special cases of association (aggregation, composition) may be present at individual ends of bonds.

A connection may have some stereotypes that are written next to one of its ends and indicate the peculiarity of the implementation of this connection. The following stereotypes can be used in UML for this purpose:

• “Association” is an association (assumed by default, therefore this stereotype can be omitted);
• “Parameter” is a method parameter. The corresponding object can only be a parameter of a certain method;
• "Local" is a local method variable. Its scope is limited to the neighboring object;
• “Global” is a global variable. Its scope extends to the whole diagram of cooperation;
• “Self” is a reflexive connection of an object with itself, which allows the object to transmit a message to itself. In the cooperation diagram, the reflexive relationship is represented by a loop in the upper part of the object's rectangle.

Messages

Messages , as elements of the UML language, have already been considered earlier when studying a sequence diagram. When building a cooperation diagram, they have some additional semantic features. The message on the collaboration diagram specifies the communication between two objects, one of which transmits some information to the other. In this case, the first object expects that after receiving the message by the second object, some action will follow. Thus, it is the message that is the cause or incentive for starting operations, sending signals, creating and destroying individual objects. The link provides a channel for the directed transfer of messages between objects from the source object to the recipient object.

UML messages also specify the roles that the sender and recipient objects play. Messages on the collaboration diagram are depicted with arrows labeled next (above or below) with the appropriate association or role of association. The direction of the arrow indicates the recipient of the message. The appearance of the message arrow has a definite meaning. The cooperation diagrams can use one of four types of arrows to indicate messages:

• A solid line with a triangular arrow indicates a call to a procedure or other nested control flow. It can also be used in conjunction with parallel active objects, when one of them transmits a signal and waits until some nested sequence of actions ends. Usually, all such messages are synchronous, that is, triggered upon the completion of a certain activity or upon the fulfillment of a certain condition;
• a solid line with a V-shaped arrow indicates a simple flow of control. Each such arrow represents one stage in the control flow sequence. Usually all such messages are asynchronous;
• a solid line with a half arrow is used to denote asynchronous control flow. Corresponding messages are formed at arbitrary, previously unknown moments of time, as a rule, by active objects. Typically, messages of this type are initial in a sequence of control flow and are most often initiated by actors;
• a dashed line with a V-shaped arrow indicates a return from the procedure call. Arrows of this type are often absent in the diagrams of cooperation, since they implicitly assume their existence after the end of the process of activating some activity.

Each message can be marked with a string of text that has the following format:

<[Watchdog Condition]>

Preceding messages are comma-separated message numbers written before a slash:

<message number,="" '="">' / '

If the list of message numbers is empty, then the entire entry, including the slash, is omitted. Each message number can be a sequence expression without recursive characters. The expression must determine the number of another message in the same sequence.

The meaning of the indication of the preceding messages is that this message cannot be transmitted until all the messages whose numbers are written in this list are not transmitted to their addressees.

Example of writing previous messages:

A3, B4 / C5: write error (sector).

The watchdog condition is a common Boolean expression and is intended to synchronize individual threads of a control flow. The watchdog condition is written in square brackets and can be omitted if this message does not have it. The semantics of the watchdog condition ensures that the message is transmitted only if this condition assumes the value “true”.

An example of the recording of guard conditions without the numbers of the preceding messages:

• [(x> = 0) & (x <= 255)] 1.2: display_on_screen_colour (x);
• [number of digits = 7] 3.1: dial_telephone_number ();

A sequence expression is a dots-separated list of individual sequence terms, after which a colon is written:

':'

Each of the terms represents a separate level of procedural nesting in the form of a complete iteration. The highest level corresponds to the leftmost term of the sequence. If all control threads are parallel, then nesting is absent. Each of the sequence terms has the following syntax:

[Integer number | Name] [Recurrence Symbol].

The integer indicates the sequence number of the message in the top-level procedural sequence. Messages, the numbers of which differ by one, follow one after another.

The name is used to specify parallel control threads. Messages that differ only in name are parallel at this nesting level. At one nesting level, all control threads are equivalent in terms of message passing priority.

The recurrence symbol is used to indicate conditional or iterative execution. The semantics of recurrence represents zero or more messages that must be fulfilled depending on the recorded condition. There are two possible cases of recording recurrence:

• '*' '[' Iteration clause ']' to record the iterative execution of the corresponding expression. Iteration represents a sequence of messages of the same nesting level. An iteration clause may be omitted if the iteration conditions are not specified. Most often, an iteration sentence is written in some pseudocode or programming language. In UML, the record format of this sentence is undefined. For example, "* [/: = / .. n]", which means the sequential transmission of a message with the / parameter, which changes from 1 to some integer n with step 1;
• '[' Suggestion condition Y ']' to record branching. This condition represents such a message, the transmission of which on this branch is possible only if this condition is true. Most often, the conditional clause is written in some pseudocode or programming language, since the format of this sentence is not defined in the UML language. For example, [x> y] means that a message on a certain branch will be transmitted only if the value of x is greater than the value of y.

. The return value is presented in the form of a list of names of the values ​​returned at the end of communication or interaction in a full iteration of this procedural sequence. These identifiers can act as arguments in subsequent messages. If the message does not return any value, then neither the value nor the assignment operator in the cooperation diagram is indicated.

For example, the message

1.2.3: p: = find_doc (document_datasheet)

It means sending an attached message with a request to search the database for the required document by its specification, and the found document should be returned to the message source.

The name of the message recorded in the signature after the return value means the name of the event, which is initiated by the recipient object of the message after it is received. Most often, such an event is a call to an object operation. This can be implemented in various ways, one of which is the invocation of an operation. Then the corresponding operation must be defined in the class to which the recipient object belongs.

The argument list is a comma-delimited, and in parentheses, the actual parameters of the operation whose call is initiated by the message. The argument list may be empty, but the parentheses are still written. Some pseudocode or programming language can also be used to write arguments.

So, in the above message example

1.2.3: p: = find_doc (document_datasheet)

the find_document argument is the name of the message, and the document_specification is a list of arguments consisting of the only valid parameter of the operation. The name of the message means referring to the operation to find_ a document that must be defined in the corresponding class of the receiving object.