The goal of a customer in relation to our money vending machine (ATM) is to withdraw money. So, we are adding Withdrawal use-case. Withdrawing money from the vending machine might involve a bank for the transactions to be made. So, we are also adding another actor – Bank. Both actors participating in the use-case should be connected to the use-case by association.
Money vending machine provides Withdrawal use-case for the customer and Bank actors.
Relationships between Actors and Use-Cases
Use-cases could be organized using following relationships −
Generalization between Use-Cases
There may be instances where actors are associated with similar use-cases. In such case a Child use-case inherits the properties and behavior of the parent use. Hence we need to generalize the actor to show the inheritance of functions. They are represented by a solid line with a large hollow triangle arrowhead.
Association between Use-Cases
Associations between actors and use-cases are indicated in use-case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use-case.
There are some functions that are triggered optionally. In such cases the extend relationship is used and the extension rule is attached to it. Thing to remember is that the base use-case should be able to perform a function on its own even if the extending usecase is not called.
Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use-case to the extended (base) use-case. The arrow is labeled with the keyword «extend».
It is used to extract use-case fragments that are duplicated in multiple use-cases. It is also used to simplify large use-case by splitting it into several use-cases and to extract common parts of the behaviors of two or more use-cases.
Include relationship between use-cases which is shown by a dashed arrow with an open arrowhead from the base use-case to the included use-case. The arrow is labeled with the keyword «include».
Use-cases deal only in the functional requirements for a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately.
The diagram shown below is an example of a simple use-case diagram with all the elements marked.
Basic Principles for Successful Application of Use-cases
● Keep it simple by telling stories
● Be productive without perfection
● Understand the big picture
● Identify reuse opportunity for use-cases
● Focus on value
● Build the system in slices
● Deliver the system in increments
● Adapt to meet the team’s needs