Introduction

UML use case diagrams serve to show the functions of a software system from the point of view of its interactions with the outside world, without going into the detailed implementation of the functions in question. These diagrams are used during requirements gathering and the analysis phase.

Actors

The purpose of software is to provide information to people, machines, or external devices in general. An actor is a set of roles played by an external entity in relation to the software system being considered. To be an actor, an external entity must meet two conditions:

  • Be autonomous with respect to the software (for example: an electric motor, but not a CPU).
  • Have a direct relationship with the software or with external entities that are subordinate to this software.

An actor is a classifier, but it is not a stereotype. If a set of external entities plays the same role, we will represent them with the same actor. Actors can have specialization or generalization relationships through inheritance (an actor A is a specialization of an actor B if it plays at least all the roles of B).

A use case represents an interaction between the software and one or more actors. The interaction must be an autonomous function within the software. Use cases are a particular type of classifier; they can have attributes and operations. Associations exist between use cases and actors that represent the role of the actor in relation to the use case, but they do not represent any data flow. The primary actor is the one requesting the software function. There are three types of relationships:

  • Extension relationship: Use case A is said to extend B if A is executed within B when a specific condition is met.
  • Inclusion relationship: A use case A is included in the use cases B, C..., if it is part of a process common to all of them. The use case is not autonomous, meaning it does not have a primary actor; therefore, it is always triggered from another use case. It enables reusability.
  • Generalization and specialization relationship: A use case A is a specialization of B if A does everything B does plus some specific process.

Basic representation:

Representation of a specialization/generalization:

Usually, classifier symbols are not used. The stereotypes extend and include are used for extension and inclusion relationships, respectively:

We can create appropriate associations between actors and use cases.

If convenient, and when representing all the use cases of a system, we can frame them either with a box and a title, or with an oval for the container system of the use cases, as shown below:

ATM example:

  1. This use case diagram represents the functionality of a movie rental application at an ATM.

a) Can it be deduced from the diagram that a person responsible for the ATM cannot rent movies?

No, they can also act in the customer role.

b) If the system is changed such that the way materials are added is different, would this affect people with the customer role?

No.

c) Improve the diagram taking into account that the use cases for adding DVDs and adding BRs have parts in common. Explain your decision.

d) Suppose the system is improved so that customers can recommend the DVDs they like best. This task can be carried out independently, but also when renting DVDs. Represent these new requirements in the diagram. e) Could the ATM be considered an actor?

Yes, it is an external system to the application.

  1. Taking into account the answers to the following questions about the famous Minesweeper game, specify the use case diagram:

Remember that we will need to ask ourselves questions to create the diagram... In this case, we can assume that these are all the use cases of the game. Typical questions to specify the use cases of a system would be: What use cases do we identify?

  • Start a new game.
  • Reveal a cell.
  • Flag a cell.

Who performs these use cases?

  • The player.

  1. At the company where you work, a new video game called Sokoban has been commissioned. As analysts, you are asked to specify the use case diagram for the game, taking into account the following functional requirements:
  • Sokoban is a multi-level game.
  • Each level is composed of a player, boxes, shelves, and walls.
  • The player's goal is to push all the boxes onto the shelves.
  • When this happens, the player advances to the next level.
  • To move a box, the player must stand next to it and push it. If the cell being pushed toward is empty, the box will move.
  • If the player gets stuck—that is, cannot complete the level—they can restart the level by losing a life.
  • When the player loses all lives, the game ends.