Define use case associations and association stereotypes
Use Case Associations
We have defined the system, actors, and use cases, but now we need to associate each user with the system features they need to perform their jobs.
Associations are represented by a line connecting an actor to a use case. In some tools an arrow is drawn from the actor to the use case to indicate that the actor initiates the use case. In the more recent use case manuals the association is simply a line to show that there is communication between the two elements. Just remember that the key is to identify what use cases the actors need to access.
These connections will form the basis for the interfaces of the system and subsequent modeling efforts.
Sometimes one use case may need to ask for help from another use case. For example, use cases titled Deposit Money and Withdraw Money might not actually update a bank account. They delegate the changes to an existing use case, Update Account.
When one use case delegates to another, the association is drawn as a dashed arrow from the "using" use case to the "used" use case and labeled with the <<Uses>> stereotype notation.
The stereotype notation is used throughout the UML, most commonly on use case associations and on classes. The standard notation is to enclose the word in guillemets << >> (French quote marks). Stereotypes provide a means to extend the UML without modifying it. A stereotype functions as a qualifier on a model element, providing more information about the role of the element without dictating its implementation.
To indicate that a use case is a special case of or a variation on another use case, draw the dashed arrow from the special case to the general case and label the line with the <<Extends>> stereotype notation.
Step through the process of adding associations and association stereotypes to the use case diagram:
Some tools, like Rational Rose, place a navigation arrow on one end of the association (depending on the direction you draw it). All of the details of the interaction between an actor and a use case are explained either in the use case description or in Sequence
diagrams. So the navigation arrow does not provide any additional information. Modeling tools typically provide the option to turn the navigation arrows on or off. The important thing to remember is to identify what use cases the actors need to access.
These connections will form the basis for the interfaces of the system and subsequent
Use case associations may also be adorned with multiplicity. Despite the many times I have seen multiplicity used in Use Case diagrams,
I have never seen a good explanation for why to use it or what it adds to the model. To reiterate, all of the details of the relationship between the actor and the use case are explained in either 1) the use case description, 2)a set of Sequence diagrams, or 3)collaborations modeled within Composite Structure diagrams.