Use cases in UML

Introduction

 

Use case modeling (use case diagrams) describes what a system does or what is the functionality provided by the system to benefit the users. Use case modeling was created by Ivar Jacobson.

 

More than any other diagrams in UML, use case diagrams allow us to quickly gather the requirements of the software system. The primary components of a use case model are use cases, actors or roles and the system being modeled also known as the subject.

 

The primary purpose of use cases are:

1. To describe the functional requirements of the system, resulting in an agreement between the stakeholders and the software developers who are developing the system.
2. To give a clear and consistent description of what the system should do.
3. To provide a basis for conducting system tests to verify whether the system works appropriately or not.
4. To provide the ability to transform functional requirements into classes and operations in the system.

 

Use Case

 

A use case represents the functionality provided by the system to the user. A use case is defined as “a set of actions performed by the system, which produces an observable result that is, typically, of some value to one or more actors or other stakeholders of the system”.

 

The actions can include communicating with other actors or systems as well as performing calculations inside the system. The characteristics of a use case are:

1. A use case is always initiated by an actor.
2. A use case provides value to an actor.
3. A use case is complete.

 

Use cases are connected to actors through associations, which are sometimes referred to as communication associations. Associations represent which actors the use case is communicating with. The association should always be binary, implying a dialog between the actor and system.

 

A use case is a classifier, not an instance. A use case represents the functionality as a whole with possible alternatives, errors and exceptions that can occur during the execution of the use case. An instance of the use case is known as a scenario, which represents a specific execution path through the system.

 

Example: Consider a online shopping system

 

Use case: Purchase Product

 

Scenario: A user named surya purchases a product, gaming console by using debit card payment option.

 

The graphical representation of a use case is a solid ellipse with the use case name specified inside the ellipse. A use case generally placed inside the system boundary and is always connected to an actor using an association relationship.

 

The name of the use case is generally a phrase rather a one word label. The name can be a simple name or a path name as shown in the below example:

 

 

Actors

 

An actor is one which interacts or uses the system (subject). An actor sends or receives messages from the system. Actor can be either a person or another system (computer or application).

 

An actor is a classifier, not an instance. An actor represents a role, not an individual user of the system. For example, in an online shopping system, if ramesh wants to purchase a product, his role will be buyer.

 

An actor has a name, and the name should reflect the actor’s role. The name should not represent an instance of the actor or the functionality of an actor. A use case is always initiated by an actor that sends a message to it. This message is also known as stimulus.

 

Actors may be of two types: active actors and passive actors. Active actors or those which initiates a use case and passive actors are those which participate in a use case but never initiate it.

 

Actor can be represented with a class symbol stereotyped as <<actor>>. Actor has a standard stereotype icon known as the “stickman”. An actor can have both attributes and behavior.

 

 

Flow of Events

 

A use case describes what a system does but it does not specify how it does that. We can specify the behavior of a use case by describing the flow of events in text clearly enough for an outsider to understand it easily.

 

When we write the flow of events, we must specify when the use case starts and ends, what objects are exchanged between the system and the actor, the basic/main flow and alternate flows of events. For example in an ATM system, we can describe the use case “Validate User” in the following way:

 

Main flow of events:

 

The use case starts when the system prompts the customer for a PIN number. The customer can now enter a PIN number via the keypad. The customer commits the entry by pressing the Enter button. The system then checks this PIN number to see if its valid or not. If the PIN is valid, the system acknowledges the entry, thus ending the use case.

 

Exceptional flow of events:

 

Customer can cancel the transaction at any point by pressing the Cancel button thereby restarting the use case. No changes are made to the customer’s state.

 

Exceptional flow of events:

 

Customer can clear the PIN number anytime before confirming it and reenter a new PIN number again.

 

Exceptional flow of events:

 

If the Customer enters an invalid PIN number, the use case restarts. If this happens, three times in a row, the system cancels the transaction, preventing the Customer from interacting with the ATM for 60 seconds.

 

Scenarios

 

A scenario is a specific sequence of actions that illustrates behavior. Scenario is an instance of an use case like objects are instances of classes. For example, in an online shopping system consider the use case “Purchase Product”.

 

For this use case, a scenario can be: user Ramesh purchases a laptop. Another scenario can be user Mahesh purchases a washing machine etc..

 

Collaborations

 

A use case specifies what the system does but does not specify how it is implemented. A use case is implemented by creating a collection of classes and other elements that work together to achieve the behavior of the use case. This collection of elements, including both its static and dynamic structure, is modeled in UML as collaboration.

 

 

Organizing Use Cases

 

We can organize the use cases by grouping them in packages in the same manner in which we can organize classes. We can also organize use cases by specifying generalization, include and extend relationships. We apply these relationships in order to factor common behavior and in order to factor variants (alternatives).

 

Generalization among use case represents that the child use case inherits the behavior from the parent use case. For example in an ATM system, the behavior of the use case “Validate User” is to check whether the user is a valid user or not.

 

To implement this, system might ask for a PIN number or might ask for a retinal scan of the eye or may ask for finger scan. All these three, PIN validation, Retinal scan and Finger scan are specialized ways of checking the validity of a user and can be applied at any place where the “Validate User” use case appears.

 

An include relationship between use cases means that the base use case explicitly incorporates the behavior of the included use case. Such relationship is represented as a dependency stereotyped with include. In an include relationship, the included use case cannot exist without the base use case. The include relationship is used to separate the common behavior.

 

 

An extend relationship between use cases means that the extending use case extends the behavior of the base use case. Such relationship is graphically represented as dependency stereotyped with exclude.

 

In a extend relationship, the base use case may exist on its own but at certain points its behavior may be extended by the behavior of another use case. The extend relationship is used to separate the optional behavior.

 

 

Consider the following which illustrates the use of generalization, include and extend relationships between use cases:

 

 

Common Modeling Techniques

 

Modeling the behavior of an element

 

To model the behavior of an element:

1. Identify the actors that interact with the element.
2. Organize the actors by identifying the general and more specialized roles.
3. For each actor, consider the primary ways in which the actor interacts with the element.
4. Consider also the alternative ways in which the actor interacts with the element.
5. Organize these behaviors as use cases, applying include and extend relationships to factor common behavior and distinguish exceptional behavior.