UML Use Case Modeling Explained
Uploaded by
ScribdTranslationsUML Use Case Modeling Explained
Uploaded by
ScribdTranslationsObject modeling with
UML
Pr. Badraddine AGHOUTANE
Study of needs
With UML, we model the requirements using diagrams ofuse case.
Use casesexperiences an external and functional perspective of the system.
System mockups(non-operational user interfaces) can help to
describe and formulate needs by involving users.
Software allows the production of static screens: Microsoft Visio, Axure Pro,
Pencil Project, ...
Use case diagrams
Modeling of needs
Before developing a system, it is necessary to know precisely howWHAT will he have to serve?
i.e. the needs it will have to meet.
Modeling the needs enables:
1. Take inventory of the expected features;
2. Take inventory of the system actors
3. Organize the needs among themselves, and the stakeholders to make them visible.
desrelations (possible reuse, ...).
Ivar Jacobsonintroduced this concept (use case) in the OOSE method
Object-Oriented Software Engineering
Example of a use case diagram
Actors and use cases
An actor is aexternal entity to the modeled system, and which interacts
directly with him.
A use case is afunctionality extended to an actor, it requires a
series of more elementary actions.
It is an expression of a service carried out from start to finish, with a
triggering, unfolding and an end, for the actor who initiates it.
Actors and use cases
A Client actor can:
1. Place an order (UC1)
2. Add an item to the cart (UC2)
3. Track an order (UC3)
Actor-use case relationships
The actors involved in a use case are linked to it by a
association.
An actor can useseveral times the same use case.
Actor-Use Case Relations
Actor-Use Case Relations
Relations between use cases
1. Inclusion: case A includes case B (B is a mandatory part of A).
2. Extension: case B extends case A (B is an optional part of A).
3. Generalization: case A is a generalization of case B (B is a type)
of A).
Use case: Extension
An extension is an optional use case that does everything the feature does.
from base and more.
The actor of the extension is necessarily involved in the base case since
the extension depends on it.
The actor of the base case can execute the extension but it is not mandatory.
Extension - Example
Use case: Inclusion
Use case Inclusion is a part of another use case that:
is not generally useful in itself (i.e., without the containing case);
peut être partagé entre divers cas contenants;
is necessary for the proper functioning of the containing case.
The actor is necessarily involved in the sub-part.
Inclusion - Example
The sub-case can have its own associations.
Reusability with inclusions
The relationships between use cases allow for the reusability of cases (for example, the
case authenticate
it would be useless to develop an authentication module several times (principle of
code reuse).
Decomposition through inclusions
When a case is too complex (involving too many actions
elementary), we can proceed to its decomposition in simpler cases.
Inclusion and extension dependencies
Attention
Inclusions and extensions are both dependencies.
When case A includes case B, A depends on B.
When a case B depends on A, B also depends on A.
A dependency is always indicated by a dashed arrow B ---> Aquise reads B
depends on A.
The includes and the extends are stereotypes (in quotes) of relationships
dependencies.
When an element B depends on an element A, any modification of A will be
susceptible of having an impact on B.
Generalization/Specialization
A transfer is a particular case of payment.
A transfer is a type of payment.
The arrow points to the general element.
This relationship of generalization/specialization is present in most of
UML diagrams correspond to the concept of inheritance in object-oriented languages.
Relations between actors
Only one possible relationship: generalization.
Identification of the actors
The main actors are the users of the system. In addition, the actors
may be:
• Peripherals controlled by the system (printers...) ;
Dessoftware already available to integrate into the project;
•ofexternal computer systems to the system but that interact with it, etc.
Attention :
An actor corresponds to a role, not to a physical person.
2. A single individual can be represented by several actors if they have
multiple roles.
If several people play the same role in relation to the system, they will be
represented by a single actor.
Main and secondary actors
The actor is primarily when he is the initiator of the necessary exchanges for
carry out the use case, which allows to meet one's needs.
2. The secondary actors are solicited by the system to perform the functionality.
requested.
3. The secondary actors are most often other computer systems with
to which the developed system is interconnected. Or where are the administrators
of the system.
Review the use cases
There is no mechanical and completely objective way to identify
the use cases.
1. Il fautse placer du point de vue de chaque acteur: pour déterminer comment il
uses the system, in what cases it uses it, and what functionalities it must have
to have access.
2. One must avoid redundancies and limit the number of cases by being at the right level.
level of abstraction (for example, not reducing a case to a single action).
3. The details of the use cases should not be revealed, but it is necessary to remain at
level of the major functions of the system.
Description of use cases
The use case diagram describes thegreat functions of a system from the point of
view of the actors, but does not detail the dialogue between the actors and the
use case.
Asimple name(verb + noun) is quite insufficient
to describe a use case.
So, each use case must be documented so that there is no ambiguity.
concernant son déroulement et ce qu'il recouvre précisément:
1. Textual description
2. Graphic description (sequence diagram)
Textual description of a UC
Identification :
•Nom du cas : Paiement CB
Objective: Detail the steps for the customer to pay by credit card
•Acteurs : Client, Banque (secondaire)
•Date : 18/09
•Responsables : Toto
•Version : 1.0
Textual description of a UC
Sequencings
The use case begins when a customer requests payment by card.
banking
Pre-conditions
The customer has validated their order
Nominal chaining
The client enters their credit card information
The system checks that the credit card number is correct
The system checks the card with the banking system
4. The system requests the banking system to debit the client.
5. The system notifies the customer of the smooth progress of the transaction
Textual description of a UC
Alternative sequences
In (2): if the number is incorrect, the customer is warned of the error and invited to
start again
If the information is incorrect, it is requested again from the client.
Post-conditions
The order is confirmed.
The company's account is credited
Textual description of a UC
Optional sections
Non-functional constraints:
Reliability:access must be secured
Confidentialitythe information regarding the client must not be
divulged
Constraints related to the human-machine interface:
Always request validation of banking transactions
