Guidelines: Communicate-Association
communicate-association |
A communicate-association models that actor instances interact with use-case instances. |
Topics
- Explanation
- Roles
- Multiplicity
- Navigability
- Communication from actor to use case
- Communication from use case to actor
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 the direction of the communication. It is indicated by an open arrow, which is placed on the end of the association line next to the target type (the one being communicated with). For a communication that involves a response (return of values) from the receiving instance, you need a communicate-association only in the direction of the transmission. You do not need navigability in the opposite direction. The default value of the navigability property is true.
Note that arrows are usually suppressed for communicate-associations with navigability in both directions, because this is the default; instead, arrows are shown only for associations with one-way navigability. In this case the two-way navigability cannot be distinguished from no-way navigation, but in practice the latter case is nonexistent.
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.
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.
