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.

• Delegation: 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.
• Stereotypes: 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.
  

  

1. Delegation: Delegation is a concept commonly represented in UML, particularly in class diagrams and collaboration/sequence diagrams. Here's how it's represented:
   • Class Diagrams: A delegation relationship between classes is shown with a dashed line with an open arrowhead pointing to the class responsible for handling the delegated task.
   • Collaboration/Sequence Diagrams: Delegation is illustrated when one object passes a message to another object to perform a task on its behalf.
2. Stereotypes: Stereotypes are a fundamental mechanism in UML to extend the existing modeling vocabulary. They allow you to add more specific meaning to elements like classes, associations, and operations. Here's the connection:
   • Stereotypes and Associations: You can use stereotypes to classify associations with more meaning. For example, you could stereotype an association as «delegate» to explicitly indicate a delegation relationship.

Important Note: While there isn't a standard, built-in «delegate» stereotype in UML, its flexibility allows you to define your own custom stereotypes to refine the meaning of your models.

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:

Multiplicity defines how many objects participate in a relationship.

1. Multiplicity is the number of instances of one class related to ONE instance of the other class
2. For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship
3. Although associations and aggregations are bi-directional by default, it is often desirable to restrict navigation to one direction
4. If navigation is restricted, an arrowhead is added to indicate the direction of the navigation

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 modeling efforts. 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.
In the next lesson, you will learn to build a use case diagram based on user interviews.

Click the Quiz link below to test your knowledge of the use case diagram notation.
Usecase Association - Quiz