What is an Use Case Diagram?

Application Areas of Use Case Diagrams

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.

Elements in the Use Case Diagram

The following elements are visualised in a use case diagram:

• 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 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.
• An 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.
• Relationships exist between actors and use cases and between use cases.
• 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.

Relationships in the Use Case Diagram

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.

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.

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.

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.

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.

Rules in the Design of Use Case Diagrams

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.

Distribution of Use Cases on Different Diagrams

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.

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.

Notes:

Here you will find additional information from our Smartpedia section:

What does t2informatik actually do? One click and you'll know.