Use Case Diagrams: An Introduction

We will learn about such diagrams, as well as their elements and purpose, and look at the use case specification, which helps you understand system functionalities in a more complete way.

What is UML?

The abbreviation UML stands for Unified Modelling Language. Let us pause for a moment and think about the adjective “unified”, because it is often erroneously understood as synonymous with “universal”. 

Created at the turn of the 1970s and the 1980s, the UML language is used to visualise, document and create specifications of IT system elements. It also allows you to visualise the various points of view of the system and its context as diagrams. What are these points of view? You can focus on data (showing static information that does not change over time), behaviour (showing the lifecycle of business objects) or function (describing the transformation of input to output parameters). 

UML models represent a simplified reality. Constructed for a very specific, practical purpose, they are always focused on a selected aspect of the modelled system. 

UML diagrams can be divided into two types: 

• Structural diagrams, which describe the structure of the modelled system. These include: class, object, package, composite structure and deployment (component and distribution) diagrams;  
• Behavioural diagrams, or use case, activity, state machine, sequence, communication, timing and interaction overview diagrams. 

Use case diagrams: an example

Our main topic here is the use case diagram (UCD). To better understand the concept, let us build one such diagram from scratch, focusing on an ATM system.

By definition, a UCD is a diagram that shows the functionalities of the system along with its environment. Crucially, it shows how system properties are seen by users, i.e. from an outside perspective. A use case diagram is usually created at a very early stage of app development. Roughly speaking, it tells us what a given system is meant to do and consists of the basic elements we want it to include. This is why it is a good idea to create one when designing an MVP, for instance. 

Remember: UCDs do not document any other interactions between individual use cases.  

UCDs are a very cool way to build a common language between business people and developers, because they allow you to easily construct a dictionary and find out what business expects from the system. 

When it comes to modelling more complex elements that will be needed at a later stage of system development, you can, of course, fall back on other diagrams (such as activity diagrams or class diagrams). However, use case diagrams are ideal at the initial system modelling stage. 

What does the use case diagram consist of?

To begin with, we need to talk about the concepts of system boundary and context boundary. To understand your system requirements, you need to know their context, i.e. people, other active systems, processes, events and documents. 

The figure above illustrates these concepts. The “irrelevant environment” includes everything, i.e. all the different stakeholders, other systems, legal acts, etc. Out of this chaos emerges your specific context, along with the context boundary, i.e. the components that are connected to the system at hand. Moving even further, you reach the system boundary, or the aspects of the environment that will be covered by your system, as well as its use cases. The communication between the system and the context occurs via system interfaces. An example of a system context was the enforcement of PSD2 regulations in connection with the GDPR. Many systems had to be modified to meet the requirements concerning the presentation of personal data storage information or data storage requirements as such. In brief, the systems had to adapt to a new context. 

The grey zone of the context consists of the elements with regard to which you are not sure whether or not they are part of the context; the issue does not need to be settled at the requirement gathering stage. In contrast, the grey zone of the system always needs to be cleared during the requirement gathering and requirement engineering process. 

The notation (the components of your use case diagram) includes: the system boundary, which is optional; actors, or people or other systems; use cases, and different connections between these modelling elements. 

To wrap up this introduction, let us talk about syntax and semantics. Syntax determines the correct structure of the diagram: it tells you how to put the elements together so that it can then be read correctly. Semantics, on the other hand, determines your interpretation of the use case diagram.

The structure of a use case diagram: an ATM

Let us go back to our ATM example and build a use case diagram step by step. First of all, we need to delineate the system boundary, which will define the scope of our use cases; we will visualise it as a rectangle. This element is optional but you will find it very useful when visualising large systems. 

The system boundary helps you define the context of the system you want to model. It serves to separate the use cases that are part of the system from its environment, i.e. other actors and systems.

Next, we will add the actors. Actors always exist outside the system boundary; they are a role played by a person or a non-person that interacts with the system in any use-case scenario. Actors represent coherent sets of roles, played by use case users in interaction with any given case. The names of actors often overlap with business roles, but they can also give away certain information, e.g. about their permissions. Actors are divided into primary actors, i.e. those who initiate an action, and secondary actors, who are necessary for the action to be completed. 

In the figure below, we have indicated the ATM as our system boundary, the context that we will be modelling, the actors, i.e. the client, security officer, technical security officer and the bank. 

Use cases are the third and the most important element of any use case diagram. They are visually distinguished by being put in an ellipsis, with short names in the imperative. A use case is a set of scenarios connected by a shared user objective. It is a visual representation of the system’s functional requirements and defines the system’s behaviour without giving away any information on its internal structure or imposing any specific deployment methods. 

A complete set of use cases, i.e. all the use cases of the ATM, defines the system as a whole: these are the functionalities we will need. A single case defines a fragment of the system’s behaviour, i.e. some specific scenarios. 

When building use cases, we also need to consider different types of connections. Every use case must be directly or indirectly connected to at least one actor. 

• Use case diagrams are typically connected to actors via associations. An association connects an actor to a given use case. In our ATM scenario, we have a directed association, which indicates that the initiating element always knows the initiated element, but not vice versa (the client knows they can withdraw money, but money withdrawal does not know that there is a client). 

• An “extend” association indicates that our use case optionally extends the functionality of the baseline use case (once a certain condition is met). For instance, a use case such as “withdraw money” triggers an on-screen message: do you want to print a receipt? with two possible answers “yes” and “no” and the corresponding outcome. 
• An “include” association, which extends the functionality of the baseline use case by another use case behaviour. In our example, there is an “include” association between the “withdraw money” command and “authorise client”, which means that any money withdrawal will need to end with an authorisation. In addition, an authorisation will require the bank as an actor. 
• Actor generalisation is an association between a more general element (ancestor) and a detailed element (descendant), where the latter is fully consistent with the former and conveys additional information. For instance, our actor, a technical security officer, may perform the same actions as a security officer, plus their own specific actions (e.g. performing a check). 

Use case specification

Use case specification is a key step in building a use case diagram. It involves a detailed description of each use case, containing information such as its name, description, actors, pre-conditions, basic path, post-conditions, as well as possible extensions or alternative scenarios. Use case specifications help you to get a better understanding of system functionalities and determine which tasks and actions can be completed in each use case. 

• ID: 001
• Name: withdraw money
• Description: ATM money withdrawal
• Trigger: Client inserts card into ATM
• Actors: Client
• Pre-conditions: Client has a card; Client has a bank account; Account balance >== declared amount; Cash in ATM >== declared amount.
• Result: client gets the declared amount in cash
• Post-conditions: Card is ejected; Account balance is updated.

Why you should create use case diagrams

In sum, there are several reasons why you might want to create use case diagrams in your system analysis and design process: 

• To understand user needs; 
• To enable your team to communicate with stakeholders; 
• To understand the structure of the system and its features; 
• To improve system analysis and design; 
• To test and verify system objectives; 
• To ensure transparency and documentation.