Use case diagram for the Sokoban game

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).

The UML actor symbol: a stick figure labelled «Actor»

Actor hierarchy: User, with Administrator and Client below, and Manager under Administrator

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:

A UML use case: an oval labelled «Matricular Estudiant»

Representation of a specialization/generalization:

Generalisation between use cases: «Matricular Membre Familiar» inherits from «Matricular Estudiant»

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

Include and extend relationships between the enrolment use cases

We can create appropriate associations between actors and use cases.

The complete enrolment diagram, with the Student and International Student actors

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:

Use cases of an accounting system, with the Accountant and Head of Accounting actors

ATM example:

Use cases of an ATM: session, transaction, deposit, transfer and balance check

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

Use cases of a video rental shop, with the Customer and Till Supervisor actors

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:

A game of Windows Minesweeper in progress

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.

Use case diagram for Minesweeper: start a game, uncover a cell and flag a cell

  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.

Sokoban use cases with the include and extend relationships between them