The use case diagram is a be­ha­vi­our­al diagram in the Unified Modeling Language (UML) which is used to depict object-oriented pro­gram­ming systems, and processes as well as business processes. UML is not a pro­gram­ming language but a modelling language. It is a stand­ard­ised method for de­scrib­ing a planned or es­tab­lished system. This method uses diagrams in which all objects involved are struc­tured and placed in relation to one another.

Cheap domain names – buy yours now
  • Free website pro­tec­tion with SSL Wildcard included
  • Free private re­gis­tra­tion for greater privacy
  • Free Domain Connect for easy DNS setup

The use case diagram: one of many UML diagrams

Since it would be too com­plic­ated and confusing to depict all objects, re­la­tion­ships, and processes in a single diagram, UML uses 14 different types of diagrams. They can be divided into cat­egor­ies: struc­tur­al diagrams, be­ha­vi­our­al diagrams, and in­ter­ac­tion diagrams with in­ter­ac­tion diagrams being a subset of be­ha­vi­our­al diagrams.

Struc­tur­al diagrams focus on depicting all elements in a system and their re­la­tion­ship to each other. A common example of this is the class diagram which can be used to group elements and visualise hier­arch­ies. In contrast, be­ha­vi­our­al diagrams do not focus on static struc­tures. Instead, they show the planned or actual flow of processes that can be expected when using the program or software. These are dynamic diagrams.

The use case diagram is a special case within this group, since it depicts what behaviour is expected from a system or software program in a specific use case. In com­par­is­on to other be­ha­vi­our­al diagrams in UML, the use case diagram is quite static as it can only be used to describe the action and goal but not the exact sequence of the various workflows and actions. Other UML diagram types are used for this purpose, such as activity diagrams used to chro­no­lo­gic­ally depict workflows and sequence diagrams used to show the exchange of messages between different elements in a system.

The use case diagram in practice

A use case diagram is used to depict a system’s functions from the user’s per­spect­ive (referred to as the 'actor' in UML). The actor does not ne­ces­sar­ily need to be a human user. This role can also be assigned to an external system which accesses another system. The use case diagram depicts the re­la­tion­ship between an actor and their re­quire­ments or ex­pect­a­tions of the system without de­scrib­ing the actions taking place or putting them in a logical order.

In practice, this structure is useful for clearly depicting the most important functions and/or goals of a system. Therefore, when de­vel­op­ing software or planning a new business process, one of the first steps is often to create a use case diagram. This diagram provides a simple and clear visu­al­isa­tion of which use cases should be con­sidered during de­vel­op­ment so that the actors (and more generally the users and clients) achieve their objective - this is initially con­sidered without regard to technical feas­ib­il­ity.

Building blocks and structure of the use case diagram

To ensure that everyone can im­me­di­ately un­der­stand a use case diagram, stand­ard­ised building blocks are used for the il­lus­tra­tion. There are three essential elements to this:

  • Actor: Actors, both persons and systems, are depicted as stick figures.
  • System: The system being addressed by the use case diagram is depicted as a rectangle.
  • Use case: A use case is depicted as an oval shape which usually contains a short phrase de­scrib­ing the process.
Image: Visualisation of the actor, system, and use case
Symbols depicting the actor, system, and use case

The re­la­tion­ships between these elements are described using lines to link them. These are called as­so­ci­ations. A solid line between an actor and a use case indicates that the actor and the use case described in the oval are related. Dashed lines are used for re­la­tion­ships between different use cases. Since there are two different types of as­so­ci­ations that can exist between use cases, the lines are expanded upon using a keyword referred to as a ste­reo­type in UML which is enclosed in double chevrons. An arrow is also used to indicate the de­pend­ency between the two use cases. There are two distinct ste­reo­types:

  • Include as­so­ci­ations: This type of as­so­ci­ation means that a base use case includes a second use case. This is indicated using a dashed line con­nect­ing the two use cases with an arrow pointing toward the second use case.
  • Extend as­so­ci­ations: This type of as­so­ci­ation has a dashed line with an arrow pointing in the opposite direction towards the base use case. This means that the second use case extends the base use case under certain con­di­tions, but it does not always happen.
Image: Visualisation of the relationships between the actor and the use case and between different use cases
The lines use arrows and ste­reo­types to clarify the re­la­tion­ships between in­di­vidu­al elements when needed.

So, while the as­so­ci­ations require that both use cases be executed, the second use case in the extend as­so­ci­ation is only executed under certain con­di­tions. These con­di­tions are specified in the UML use case diagram as extension points. This is il­lus­trated in two ways:

  • Extending the use case oval: Under the name of the use case, the possible extension points are named and briefly described.
  • Adding a note: The extended ste­reo­type is connected via a dashed line to a stylised note (i.e. a rectangle with a bent corner) which is labelled with 'con­di­tion' and 'ex­ten­sion point'. Next to 'con­di­tion' enclosed in curly brackets, you will find the condition which must be met for the second use case to be executed. Next to 'ex­ten­sion point', you will find the name of the use case oval so that the extension can be clearly iden­ti­fied.
Image: Visualisation of an extension point which is a condition for a possible use case
If the con­di­tions defined in the extension point are met, use case B will occur and change the process of use case A.

You now have all the building blocks required to create your own use case diagram.

An example of how to create a use case diagram

Up to this point, we have presented a lot of the­or­et­ic­al in­form­a­tion. To help you better un­der­stand the practical im­ple­ment­a­tion of a use case diagram, we are going to go over how to create one using a bank customer who wants to withdraw money from a cash machine as an example.

Note

Always ensure that your use case diagram does not become too confusing. This can happen quickly if you try to depict several use cases in the same diagram which are also connected by <<include>> and <<extend>> re­la­tion­ships. When in doubt, it is better to create a separate use case diagram for each use case.

In this example, the cash machine is the system and the bank customer is the actor intending to execute the 'withdraw money' use case. This use case is connected through de­pend­en­cies to two other ad­di­tion­al use cases: 'au­thentic­a­tion' and 'PIN and account veri­fic­a­tion'. If the au­then­tic­a­tion is not suc­cess­ful, the customer’s request cannot be executed. To prevent the customer from making an infinite number of attempts, the card should be blocked after the PIN has been in­cor­rectly entered three times. Therefore, an extension point is added to the 'au­thentic­a­tion' use case with the condition 'in­cor­rectly enter PIN three times'. If this condition is met, the 'block card' use case is executed which is connected to the 'au­thentic­a­tion' use case via an extend re­la­tion­ship. Here is what the use case diagram for this example looks like:

Image: Use case diagram example for the ‘withdraw money’ use case with the corresponding include and extend associations
In the use case diagram for the ‘withdraw money’ use case, you can see how the different use cases are related to each other.
Go to Main Menu