Mistake #3 – Improper Associations Between Use Cases
There are three associations between Use Cases according to the UML v2.2 Superstructure:
All three are considered “Directed Relationships”. This means that the direction of the relationship arrow has meaning in UML. The most common mistake in using these relationships in Use Case diagrams is usually when the Business Analyst draws the relationship in the wrong direction. Utilize the information below to make sure you don’t create improper relationships between use cases:
Use Case Generalization Relationship
Generalization is a way to depict the notion that there are general types of Use Cases (example: Perform ATM Transaction) and specific versions of that Use Case (example: Withdraw, Transfer Funds, Deposit Funds) that inherit the properties of the general type. The Generalization association is shown a solid line with an open arrowhead (or hollow triangle) that goes from the specific type of actor ending with the arrowhead pointing at the general type of actor.
Use Case Extend Relationship
This relationship specifies that the behavior of a use case (Login) may be extended by the behavior of another, usually supplementary, use case (Register for Online Banking). So you can think of this as Register for Online Banking extends Login. The normal functionality of Login implies that the user has the appropriate Login information. If the user does not have the Login information, Register for Online Banking extends Login by allowing the person to Register for Login information.
Since Extend is also a directed relationship, it is important to note that the extending use case (Register for Online Banking) is the source and the extended Use Case (Login) is the destination for the association arrow. The association is shown as a dashed line with an open arrow head going from the source to the destination, highlighted with the keyword <<extend>>.
Use Case Include Relationship
Include is a directed relationship between two Use Cases, implying that the behavior of the included Use Case (Card Identification) is inserted into the behavior of the including Use Case (Withdraw from ATM). The included Use Case is not optional. It’s behavior must be performed within the including Use Case. You can think of it in this manner: Withdraw from ATM (source) includes Card Identification (destination). The association is shown as a dashed line with an open arrow head going from the source to the destination, highlighted with the keyword<<include>>.