Home » Smartpedia » Use Case Diagram

Use Case Diagram

What is an Use Case Diagram, which elements are visualised with it and which advantages does it offer?

Use Case Diagram Definition

An Use Case Diagram is a representation that visualises the behaviour of a system from the user’s point of view. It is a graphical representation of use cases including their relationships to the environment and other use cases. Thus a use case diagram describes in a high abstraction which functions and services a system provides for a user.

However, an Use Case Diagram neither describes the system processes nor the sequence of functions or services. Other UML behavior diagrams such as activity diagrams, state diagrams, sequence diagrams or communication diagrams can be used to define a sequence of events. An Use Case Diagram merely visualises the relationships between a set of use cases and the actors involved. This makes it very suitable for requirements analysis, i.e. for determining or refining requirements.

Fields of Application

Use Case Diagrams are often used in the context of a requirements analysis or in the process of requirements engineering. They can be used to record requirements for a system – consisting of software and/or hardware. They are well suited for communication and analysis of system behavior because they can be used to define the functionality of the system from the user’s point of view. Implementation details, such as the system architecture or the programming language to be used, are not yet important in this phase and can be discussed in subsequent steps.

The system analysis determines what a system should achieve from the user’s point of view. The individual cases are recorded and visualised as use cases. A Use Case Diagram thus represents a sketch of the system, which indicates the purpose of the planned system including boundaries and interfaces. All modeled elements are documented in a specification, ideally also with alternative procedures and the behavior description in case of an error.

Use Case Diagram - an Example

Advantages of Use Case Diagrams

Use Case Diagrams display use cases of one or more actors and relationships between the use cases. The application offers a number of advantages:

  • Systems are consistently viewed and described from the user’s point of view, which promotes understanding and helps communication between users, system analysts and developers.
  • They offer an additional perspective on the system and on relationships between individual use cases; concrete requirements and test cases can be derived from this. The refinement of existing requirements is also supported.
  • They help to structure a system to be developed and to define the system boundaries. This is an essential factor for a successful development.

 

Elements in the Use Case Diagram

The following elements are presented in an Use Case Diagram: the system, the actor or actors, the use cases, the relationships between actors and use cases and between use cases and notes.

The System

The system itself is not a logical model element, but delimits the context. This system context is represented by a frame in the diagram in which the system provides its functions and services.

The Actor

The actor is outside the system. He is drawn as a stick figure and can be a concrete person or an abstract element such as a sensor. The refinement of actors can take place via UML profile. If an actor is defined, it must always be connected to at least one use case. If several actors are involved, this is expressed by the multiplicity. Without further specification, this is 1 by default.

The Use Cases

A use case is usually displayed as an ellipse, whereby its name can also be outside the ellipse. A diagram can contain several use cases. If a use case can only be executed by other use cases, it is referred to as abstract. Multiplicity can also be displayed for use cases; it provides information on how often the use case can be executed simultaneously.

The Relations

Actors and use cases are just as related to each other as use cases are to each other. Basically, four different relationships or relationship types can be used in a diagram: association, include, extend and generalisation. Relationships are modeled with dashed or solid lines and arrows. The direction of the relationship should not be understood as a data flow; it describes, for example, which use case extends another.

The Association Relationship

When an actor communicates with a use case, this is referred to as a communication relationship or association. The direction of the line describes which part is active and which part is passive. If the arrow flows from the actor to the use case, the actor is active and triggers the use case. If the arrow flows from the use case to the actor, the use case is active and prompts the actor to participate.

The Include Relationship

The include relationship links a primary or base use case with one or more secondary use cases. It is useful to model an include relationship if parts of use cases occur in several use cases. This avoids redundant descriptions. In practice, secondary use cases are often marked with the stereotype “secondary”, even if this is not provided for in UML. There are five aspects to include relationships:

An included use case is ALWAYS executed when the included use case is executed. However, the time of execution cannot be specified in the diagram; the specification is suitable for this.
An included use case can also be executed separately.
Primary and secondary use cases should be described at similar levels of abstraction. Detailing in included use cases should be avoided.
Descriptions can be used as often as desired by include relationships.
In contrast to generalisation, no properties are inherited.

The include relationship is represented in a use case diagram by a dashed arrow and the include caption. The arrow points to the included use case.

The Extend Relationship

If parts of an use case are only executed under defined conditions, it is advisable to apply the extend relationship. The extend relationship adds a function to the basis use case. Example: Each year you must declare your income using a tax return (basis use case) and from a defined income amount you must enclose documents (extension of the basis use case). The basic use case thus decides whether the extended use case – which does not necessarily have to involve an actor – is executed. Both cases can be executed separately. An extend relationship is shown by a dashed arrow labeled extend. The arrow always points to the basic use case. The extended use case can be described in detail by so-called extension points. This allows you to document the event or time at which the original behavior is extended. Conditions can also be defined; if a condition occurs, the extension is executed. A use case can have any number of extension points.

The Generalisation

There are two forms of generalisation in a utility diagram:

between actors and
between applications.

Imagine there are two players: a fruit seller and a salad seller. Since both have characteristics that they share, a general actor can be derived from them: a seller. The advantage of such generalisation lies in the general and abstract description of the new actor seller and in the combination of the use cases with other use cases, which only apply to the specialists (fruit or salad sellers). This is often referred to as specialisation. Just like actors, use cases can also be generalised. In the use case diagram, generalisation always points in the direction of the more general element, hence the term generalisation. This type of connection is also called a sort of relationship, since the more specific use cases and actors “inherit” everything from the more general element.

Notes

Notes can be used to add information to increase understanding. They are represented by a rectangle, the upper right corner of which is folded. A stitched line connects the note with the element to be explained.

Would you like to learn more about Use Cases?

Then take a look at the idea of Use Case 2.0 or the advantages of Misuse Cases.

Challenges for Companies

Style Guide

When designing Use Case Diagrams, it is advisable to observe some rules:

  • Even if actors are drawn in outside the system, they should never be displayed without a relationship to a use case. Isolated use cases should also be avoided.
  • Crossings between relationships should be avoided.
  • A Use Case Diagram should not include too many use cases, otherwise the display will quickly become confusing. Here it is recommended to distribute the contents over several diagrams.

 

Divide Use Cases into Multiple Charts

Use Case Diagrams provide a good view of a system. In them, companies can better put themselves in the position of their users and find solutions for these users by defining requirements and, as a result, test cases. The identification of topics and content is the first challenge for companies. The more employees are involved and the more comprehensive a system is, the more complex this step becomes.

If an Use Case Diagram becomes confusing due to a large number of use cases, it is advisable to distribute use cases across different diagrams. But is another form of presentation the solution to the problem, or is the system as such too extensive to divide the system into subsystems? Such a decision is not easy to make. Working with use cases, diagrams, use case 2.0 and misuse cases offers a comprehensive concept to understand systems not only in detail but as a whole. Companies “only” need to apply the concepts consistently and appropriately to the organisation.

We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the description of use cases and the collection, structuring and administration of requirements. We pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and take stakeholders, goals and constraints into account. And we plan and control your projects with these requirements on the basis of defined processes.

Find out more about software development here  »

More details and information ...