Guideline: Communicate-Association
var backPath = './../../../';
var imgPath = './../../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_gpYSoAILEdq-_NKqZM1EhA", "_N13eYAINEdq-_NKqZM1EhA", "_KVkLoN7HEdm8G6yT7-Wdqw", "{9C66F2EC-EDEB-4369-9AFB-04B9E7CBCB8E}", "4.1665593852713E-305"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_EOvXUN7HEdm8G6yT7-Wdqw", "_KVkLoN7HEdm8G6yT7-Wdqw", "{9C66F2EC-EDEB-4369-9AFB-04B9E7CBCB8E}", "4.1665593852713E-305"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_jijhYAIaEdqEutyfYo0quQ", "_mTMIkN7REdmjRZts2c4ZjQ", "{9C66F2EC-EDEB-4369-9AFB-04B9E7CBCB8E}", "4.1665593852713E-305"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_2ClPcDIcEdqDs_9ORT1Rig", "4.1665593852713E-305"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);
Guideline: Communicate-Association
A Communicate-Association models how Use cases and actors interact by sending signals to one another. This guideline explains how to use this relationship.
Relationships
Related Elements
Find Actors and Use Cases
Use-Case Model
Main Description
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.
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
contentPage.onload();
Wyszukiwarka
Podobne podstrony:
07a?0 Information and CommunicationDOD Net Centric Data Strategy and Community of Interest (COI) Training Glossarycommunity member userRiordan J The Impact of Communism on SportFood 20 adjectives associationCommunio et progressio Instrukcja Duszpasterska o Środkach Społecznego Przekazu2008 06 Living Free Free Communications on the Freenet NetworkEns communecommunity member userunit communication10U COMMUNISMCommunicative competence and CLT[1]więcej podobnych podstron