SWEN 5135 Configuration Management
communicate-association
|
A
communicate-association is an association between an actor
class and a use case class, indicating that their instances interact. |
Topics
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.
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).
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.
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.
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.
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.
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: Use-Case Modeling
Guidelines.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Artifacts >
Requirements Artifact Set >
Use-Case Model... >
Use-Case Model >
Guidelines >
