Use-Case diagram

Use-case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does (for the user) rather than how. Use-cases help us focus on what is really important from the user's perspective and are therefore the primary diagram type for capturing top-level behavior requirements.

For every use-case there will be one or more scenarios where a scenario is an example of what happens when someone or something interacts with the system. Primary scenarios of a use-case describe a sequence of actions where everything goes according to plan. Secondary scenarios of a use-case deal with exceptional circumstances where things do NOT go according to plan. You can think of a scenario as an instance of a use-case in the same way that an object is an instance of a class.

The first step towards creating a use-case model is to select a use-case (i.e. something of value to the actor) and then write a short story describing a possible scenario. For example, here is a scenario associated with the use-case "Make Appointment" in the context of a medical clinic.

A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot.

An actor is who or what acts on the system to initiate the sequence of events involved in a scenario. Actors are simply roles that people or objects play. The actor in the use-case story above is a person in the role of a Patient. The connection between actor and use-case is a communication association.

Actors are illustrated as stick figures. Use-cases are ovals. Communications are lines that link actors to use-cases.

Hence, a use-case diagram is a collection of actors, use-cases, and associations. "Make Appointment" is part of a diagram with four actors and four use-cases. Notice that a single use-case can have multiple actors.

Use-case diagrams are helpful in three areas.

Determining features (requirements): New use-cases often generate new requirements as the system is analyzed and the design takes shape.
Communicating with clients: Their notational simplicity makes use-case diagrams a good way for developers to communicate with clients.
Generating test cases: The collection of scenarios for a use-case may suggest a suite of test cases for those scenarios.

A use-case diagram can be expanded with additional features to display more information as shown below.

A system boundary rectangle separates the clinic system from the external actors.

A use-case generalization shows that one use-case is simply a special kind of another. Pay Bill is a parent use-case and Bill Insurance is the child. A child can be substituted for its parent whenever necessary. Generalization appears as a line with a triangular arrow head toward the parent use-case.

Include relationships factor out functionality whose result is needed, but which can be included from an include case in order to keep the focus on the core purpose of the base case. Functionality factored out of a use-case can often be reused by other use-cases. Both "Make Appointment" and "Request Medication" include "Check Patient Record" as a subtask. In the diagram, include notation is a dotted line beginning at base use-case ending with an arrows pointing to the include use-case. The dotted line is labeled <<include>>.

An extend relationship shows a use-case extending the capabilities of the base use-case. It factors out nice to have, but not necessarily essential behavior in the base use-case. It specifies that the functionality of one use-case can be inserted into the functionality of another use-case as an option. The extend notation is a dotted line, labeled <<extend>> with an arrow toward the base case. The direction of the arrow indicates that the base use-case is not responsible for the behavior in the extended use-case. The extension point, which determines when the extended case is appropriate, is written inside the base case and represents a kind of switch that determines when the extended case is enabled or disabled. The extension point could be the Boolean expression in a switch statement such as

Switch (Treatment) {
case ADDITIONAL: deferBilling(); break;
case COMPLETED: processBill();
}