UML Use Case Diagrams

Use Case Diagram

UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look of them.

UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. 

For exp : A Web site on which customers can order meals from local restaurants.

An actor (1) is a class of person, organization, device, or external software component that interacts with your system. Example actors are Customer, Restaurant, Temperature Sensor, Credit Card Authorizer.

A use case (2) represents the actions that are performed by one or more actors in the pursuit of a particular goal. Example use cases are Order Meal, Update Menu, Process Payment.

On a use case diagram, use cases are associated (3) with the actors that perform them.

Your system (4) is whatever you are developing. It might be a small software component, whose actors are just other software components; or it might be a complete application; or it might be a large distributed suite of applications deployed over many computers and devices. 

A use case diagram can show which use cases are supported by your system or its subsystems.

<<extends>>

When one use case adds behaviour to a base case
– used to model a part of a use case that the user may see as
optional system behavior;
– also models a separate sub-case which is executed conditionally.

<<uses>>

One use case invokes another (like a procedure call);

– used to avoid describing the same flow of events several times

– puts the common behavior in a use case of its own.

<< include >>

Use an Include relation to show that one use case describes some of the detail of another. In the illustration, Order a Meal includes Pay, Choose Menu, and Choose Menu Item. Each of the included, more detailed use cases is a step that the actor or actors might have to perform to achieve the overall goal of the including use case. The arrow should point at the more detailed, included use case.

The goal and scenarios of an included use case should make sense independently so that it can be included in use cases that are designed later.

Separating use cases into including and included parts is useful to achieve the following goals:

• Structure your use case descriptions into different layers of detail.
• Avoid repeating shared scenarios in different use cases.