Use Case Diagrams
Mohammad Mousavi
Formal Systems Analysis (FSA) Model-Driven Software Engineering Department of Computer Science TU/Eindhoven
September 6, 2012
Use Case
Denition [Cockburn01]
Specication of a contract between the stakeholder of a system about its behavior.
Application
1 2 3 4
the rst step into the development process classifying user requirements guiding the rest of the development process base for test-cases
Use Cases
Common Mistakes
1 2
individual methods as use cases internal events as use cases
Use cases are usually large end-to-end processes comprising several (inter)actions
Use Cases
Running Example: A File System
In the le system, users can create new les, execute, display (on different output devices) and delete existing les. There is a special type of delete, which removes the le permanently from the le system. The le system makes use of an access right system which species who the owner of each le is and what operations are allowed by which users. The owner of each le may change the access rights to the le and give or take other peoples permissions to access the le. In addition to the person who creates the le, the administrator is considered the owner of all les.
Use Cases
File System: Raw Use Cases
Use Case Description
1 2 3
pre-condition: when a use case is available to its user, trigger: what interactions initiate the use case, guarantee (post-condition): what the use case achieves through this use case, scenarios:
1 2
main scenario: typical course of actions alternatives: re-consider each step, what can go wrong
Example: Change Access Rights
1 2
pre-condition: the user U is logged in trigger: the user issues a command to change the access right of a given le guarantee: the access rights of the le are changed as specied by the user scenarios:
1
main scenario:
1
2 3
4 2
the user issues a command to change the access right of le A for user U to AR the owner of the le O is retrieved if U=O or U=Admin, and the new access rights do not remove the access right of the owner or the admin, the change is made the user is notied about the successful outcome
alternatives:
3.1 if the le does not exists, an error is issued 3.2 if U is neither admin nor O, an error is issued 3.3 if the changes remove the access right of the owner or admin, an error is issued
Use Case Description
Sub-Scenarios
Extra scenarios that are repeated in several use-cases. Make abstract use-cases out of them. Reference them in use case descriptions (instead of repeating them).
Actor
Denition
A class of entities (human or computer), falling beyond the system boundaries, interacting with the system.
Running Example: A File System
In the le system, users can create new les, execute, ... The owner of each le may change the access rights to the le ... In addition to the person who creates the le, the administrator is considered the owner of all les.
File System: Actors
Extract Use Cases
1 2 3
Identify system-boundaries and actors What are the goals of each actor w.r.t. the system? What are the external events that the system should react to?
Association
Denition
An actor interacts with the system for the specied use cases.
File System: Some Associations
Generalization
Denition
A use case / actor is a special case of another one.
Substitutability Principle
A specialized class (use case, actor) can always replace the general one.
File System: Generalization Relations
Dependency (with <<include>> stereotype)
Denition
A use case depends on another use case for realizing its goal. The target use case is referenced by the source.
File System: Some Dependencies
Assemble It Into One Piece
