After completing this experiment you will be able to:
- How to identify different actors and use cases from a given problem statement
- How to associate use cases with different types of relationships
- How to draw a use-case diagram
Around 3.00 hours
Use case diagrams
A use case diagram is a behaviourial diagram, which aims to present a graphical overview of the functionalities provided by the system. It consists of a set of actions (use cases) that the concerned system can perform, one or more actors, and dependencies among them.
An actor can be defined as  an object or set of objects, external to the system, but interacts directly with the system to get some meaningful work done. Actors could be human, devices, or even other systems.
For example, consider the case where a customer withdraws cash from an ATM. Here, customer is a human actor. However, before any transaction can proceed, the ATM must authenticate the customer by verifying in his PIN. Here, the "ATM authentication service" is a non-human actor.
Actors can be classified as below  [i]:
Primary actor: Primary actors fulfill their goal by using some service from the system. For example, a customer uses an ATM to withdraw cash when he needs it. So, customer is the primary actor here.
Supporting actor: They provide some service to the system. "ATM authentication service" is such an example.
In a use case diagram primary actors are usually drawn on the top left side of the diagram.
A use case can be defined as  a functionality that a system can provide by interacting with the actor(s).
Continuing with the example of the ATM, withdraw cash is a functonality that the ATM provides. Therefore, this is a use case. Other possible use cases includes ,check balance, change PIN, and so on.
Use cases include both successful and unsuccessful scenarios of user interactions with the system. For example, authentication of a customer by the ATM would fail if he enters wrong PIN. In such case, an error message is displayed on the screen of the ATM.
Subject can be defined as [iii] the system under consideration to which the use cases apply.
An actor is represented by a stick figure and name of the actor is written below it. A use case is depicted by an ellipse and label of the use case is written inside it. The subject could be shown by drawing a rectangle. Label for the system could be put inside it either at the top or near the bottom. Use cases are enclosed inside the rectangle and actors are drawn outside the rectangle, as shown in figure - 01.
Figure - 01: A use case diagram for a book store
Association between Actors and Use Cases
A use case describes a specific functionality that the system provides to its users. The functionality is triggered by actor. Actors are connected to use cases through binary associations. The association indicates that the actor and use case communicates through message passing.
An actor must be associated with atleast one use case. Similarly, a given use case must be associated with atleast one actor. However, when a use case is associated with multiple actors, it might not be clear who triggers the functionality. No association among the actors are shown.
Use Case Relationships
Three types of relationships exist among use cases:
- Include relationship
- Extend relationship
- Use case generalization
Include relationships are used to depict similar behaviour that are shared by multiple use cases without replicating the common behaviour in each of those use cases.
For example, consider an email application. A user can send a new mail, reply to an email he has received, or forward an email. However, in each of these three cases, the user must be logged in to perform those actions. Thus, we could have a login use case, which is included by compose mail, reply, and forward email use cases. The relationship is shown in figure - 02.
Figure - 02: Include relationship between use cases
Include relationship is analogus to functions in terms of programming languages. There we define functions to contain the tasks that have to executed repeatedly. Such a function would be called from different points within the program.
Include relationship is depicted by a dashed arrow with a <<include>> stereotype from the including use case to the included use case.
A use case extends a base use case to obtain the properties and behaviour of the base use case as well as add some new features. This is often the case when the extended use case could not be modified to accomodate additional functionalities, or there are multiple use cases having behaviour and propertiessimilar to the base use case.
Let's consider the online banking facility provided by XYZ Bank. To use the online banking facilites, customer has to login to the website. He can then check his balance, pay bills and so on. However, for doing third party transfers (transferring funds to another account), he must authenticate himself for "third party transfer services" by providing his login password (again) and another security code. Thus, authenticate for third party transfer use case derives the behaviour of authenticate user use case, and adds a new functionality. Figure - 03 depicts such relationship.
Extend relationship is depicted by a dashed arrow with a <<extend>> stereotype from the extending use case to the extended use case.
Generalization relationship exists between a base use case and a derived use case when the derived use case specializes some functionalities it has inherited from the base use case.
To illustrate this, consider a graphical application that allows users to draw polygons. We could have a use case draw polygon. Now, rectangle is a particular instance of polygon having four sides at right angles to each other. So, the use case draw rectangle inherits the properties of the use case draw polygon and overrides it's drawing method. This is an example of generalization relationship. Similarly, a generalization relationship exists between draw rectangle and draw square use cases. The relationship has been illustrated in figure - 04.
Generalization relationship is depicted by a solid arrow from the specialized (derived) use case to the more generalized (base) use case.
Given a problem statements, the actors could be identified by asking the following questions :
- Who gets most of the benefits from the system? (primary actor)
- Who are the people involved to keep the system working and running?
- Will the system interact with other software / hardware?
- Will the system take service from or provide service to any other system?
Identifying Use cases
Once the primary and secodary actors have been identified, their goals have to identified i.e. what are the functinalities they can obtain from the system. Any use case name should start with a verb like, "Withdraw Cash".
Guidelines for drawing Use Case diagrams
Following general guidelines could be kept in mind while trying to draw a use case diagram :
- Determine the system boundary
- Ensure that actors are focussed i.e. each actor should have a single, coherent purpose
- Use cases identified must provide value tot he actors
- Associate the actors and use cases
- Identify similar set of functinalities, if any, exhibited by multiple use cases. In that case, use include relationship.