Guidelines: Communicate-Association
Topics
- Explanation
- Roles
- Multiplicity
- Navigability
- Communication from actor to use case
- Communication from use case to actor
- Optional conventions
Explanation 
Use cases and actors interact by sending signals to one another. To indicate such interactions we use a communicate-association between use-case and actor. A use-case has at most one communicate-association to a specific actor, and an actor has at most one communicate-association to a specific use-case, no matter how many signal transmissions there are. The complete network of such associations is a static picture of the communication between the system and its environment.
Communicate-associations are not given names. Because there can be only one communicate-association between a use-case and an actor, you need only specify the start and end points to identify a particular communicate-association.
A line or arrow between an actor and a use case indicates they interact by sending signals to one another.
Roles
Each end of a communicate-association is a role specifying the face that a use case or actor plays in the association. The roles are used to specify multiplicities and directions of the association (see below).
Multiplicity
Each role of a communicate-association indicates the multiplicity of its type, that is, how many instances of that actor or use case can be associated with one instance of the other use case or actor. Multiplicity is indicated by a text expression on the role. The expression is a comma-separated list of integer ranges. A range is indicated by an integer (the lower value), two dots, and an integer (the upper value); a single integer is a valid range, and the symbol '*' indicates "many", that is, an unlimited number of objects. The symbol '*' by itself is equivalent to '0..*', that is, any number including none; this is the default value. An optional scalar role has the multiplicity 0..1.
The multiplicity may be augmented with a time unit constraint. This is done to state how many instances that may be associated, possibly by different instances, during the time unit. This information is useful since it can tell us if the use case is performed often, and also how often each actor instance employs the use case.
Example:
The Conduct Transactions use case is used 400,000 times per day by Customers. Each Customer employs the use case two times per month.
Navigability
Each role of a communicate-association has a navigability property, indicating who initiates communication in the interaction. Navigability is shown by an open arrowhead. If the arrowhead points to a use case, the actor at the other end of the association initiates the interaction with the system. If the arrowhead points to an actor, the system initiates the interaction with the actor. Two-way navigability is shown by a line with no arrow-heads (two arrow-heads tends to clutter diagrams).
The communication arrow defines the actor that initiated the use case. For each communication arrow the return message is assumed. A line with no arrow heads assumes two-way communication.
Do not confuse navigability with data flow; it is used to show initiation of communication only. For example, a customer request for data is shown by an arrow to the use case representing the system, even though most of the data flows from the system to the customer.
Communication from Actor to
Use Case
Actors communicate with the system by sending signals. To fully understand the role of the actor, you must know which use cases the actor is involved in. This is shown by communicate-associations between the actor and the use cases.
The multiplicity of the association shows how many instances of a use case one instance of an actor can communicate with at the same time.
Example:
In the Recycling Machine System, each time an instance of the actor Customer hands in a deposit item, he sends a signal to the associated instance of the use case Recycle Items. When the actor is finished, the use case prints out a receipt. A Customer can communicate with only one instance of Recycle Items. Thus, the multiplicity of the association is 1. The receipt returned from the system is considered here as a response from the use-case instance; thus, the communicate-association needs no navigability in the other direction.
A Customer who wants to return deposit items into a recycling machine will communicate with the use case Recycle Items.
An actor communicates with use cases for many reasons, including:
- To invoke a use case. An actor instance always invokes a use-case instance.
- To ask for some data stored in the system, which the use case then fetches and presents to the actor.
- To change the data stored in the system by means of a dialog with the system.
- To report that something special has happened in the system's surroundings that the system should take care of.
Communication from Use Case
to Actor
One actor initiates a use case. However, once it has started, the use case can communicate with several actors. You can use communicate-associations between the use case and the actors to show which actors the use case communicates with. The association's multiplicity shows how many instances of an actor one instance of a use case can communicate with at the same time.
Use cases communicate with actors for many reasons, including:
- If something special has taken place in the system, an actor might need to know.
- A use case may need to ask an actor for help in making a decision if several options are available.
It is common, but not always true, that the use case waits for an answer when it has sent a signal to an actor. This should be explicitly described in the use case.
Optional Conventions
The following are common optional conventions which make it clear which actor initiates the use case.
- The initiating actor-to-use-case arrowhead is always shown, even if the use case later initiates communication to the initiating actor. This is also the only actor-to-use-case arrowhead shown.
- Arrowheads from use case to actors may be omitted, or may be included for clarity.
Conventions such as these, if adopted by your project, should be documented in your Artifact: Project Specific Guidelines.
