1 Dcu

Des diagrammes et des vues
Conception Orientée Objet en UML

Use Case Diagram
Pr. Salma Mouline
Pr. Salma Mouline C.O.O en UML - Use Case Diagram 1 Pr. Salma Mouline C.O.O en UML - Use Case Diagram 2
Diagramme des cas d’utilisation : définition Diagramme des cas d’utilisation : définition
Objectifs
Modélisation de la vue des utilisateurs
Objectifs Définition des fonctions du système et ses limites
Modélisation de la vue des utilisateurs Structuration des besoins à partir d’un cahier de charge
Définition des fonctions du système et ses limites
Notation très simple et compréhensible qui permet de répondre aux
Structuration des besoins à partir d’un cahier de charge questions :
1 Qu’est-ce qui est décrit ? (Le système.)
2 Qui interagit avec le système ? (Les acteurs.)
3 Que peuvent faire les acteurs (les cas d’utilisation) ?
Diagramme des cas d’utilisation : exemple Les concepts de base : Le cas d’utilisation
Définition
Les concepts de base : Le cas d’utilisation Les concepts de base : Le cas d’utilisation
Définition Définition
décrit la fonctionnalité attendue du système à développer décrit la fonctionnalité attendue du système à développer
englobe un certain nombre de fonctions qui sont exécutées lors de
l’utilisation de ce système
décrit la fonctionnalité attendue du système à développer décrit la fonctionnalité attendue du système à développer
englobe un certain nombre de fonctions qui sont exécutées lors de englobe un certain nombre de fonctions qui sont exécutées lors de
l’utilisation de ce système l’utilisation de ce système
communique avec un ou plusieurs utilisateurs communique avec un ou plusieurs utilisateurs
ne couvre pas la structure interne et l’implémentation réelle d’un cas
d’utilisation
Définition
décrit la fonctionnalité attendue du système à développer
englobe un certain nombre de fonctions qui sont exécutées lors de A partir des besoins du client
l’utilisation de ce système
Les cas d’utilisation sont déterminés à partir des souhaits des clients
communique avec un ou plusieurs utilisateurs exprimés en langage naturel.
ne couvre pas la structure interne et l’implémentation réelle d’un cas peuvent également être utilisés pour documenter les fonctionnalités
d’utilisation offertes par un système.
est déclenché soit par l’invocation d’un acteur, soit par un événement
déclencheur.
Par exemple s’il n’y a plus de billets dans le distributeur, le cas
d’utilisation Rajouter les billets doit être exécuté
Les concepts de base : Le cas d’utilisation Les concepts de base
A partir des besoins du client

Les cas d’utilisation sont déterminés à partir des souhaits des clients
exprimés en langage naturel.
peuvent également être utilisés pour documenter les fonctionnalités
offertes par un système.
Notation graphique
Les concepts de base : L’acteur Les concepts de base : L’acteur
Définition
Défini qui travaille et interagit avec le système.
Interagit toujours avec le système dans le contexte de ses cas
Définition d’utilisation
Défini qui travaille et interagit avec le système. peut être humain (un client ou un technicien) ou non humains (, un
Interagit toujours avec le système dans le contexte de ses cas serveur).
d’utilisation
peut être humain (un client ou un technicien) ou non humains (, un Notation graphique
serveur).
Différents types d’acteurs
Un acteur peut être Actif ou Passif
I Un acteur Actif interagit avec le système en utilisant le système :
l’acteur initie l’exécution des cas d’utilisation
Différents types d’acteurs I Un acteur Passif est utilisé par le système : l’acteur fournit une
Un acteur peut être Actif ou Passif fonctionnalité pour l’exécution des cas d’utilisation.
I Un acteur Actif interagit avec le système en utilisant le système : I Les deux types d’acteurs peuvent être nécessaires à l’exécution du cas
l’acteur initie l’exécution des cas d’utilisation d’utilisation
I Un acteur Passif est utilisé par le système : l’acteur fournit une
fonctionnalité pour l’exécution des cas d’utilisation. Notation graphique
I Les deux types d’acteurs peuvent être nécessaires à l’exécution du cas
d’utilisation

Différents types d’acteurs
Un acteur peut être Primaire ou Secondaire
I Un acteur primaire tire un avantage réel de l’exécution du cas
d’utilisation
Différents types d’acteurs I Un acteur secondaire bénificie moins du cas d’utilisation mais est
Un acteur peut être Primaire ou Secondaire nécessaire à son exécution.
I Un acteur primaire tire un avantage réel de l’exécution du cas I Un acteur secondaire n’est pas forcemment passif
d’utilisation
I Un acteur secondaire bénificie moins du cas d’utilisation mais est Notation graphique
nécessaire à son exécution.
I Un acteur secondaire n’est pas forcemment passif
Quelques remarques Quelques remarques
Un acteur est en dehors du système Un acteur est en dehors du système
Les données relatives à un acteur peuvent toutefois être disponibles
au sein du système et être représentées (une classe dans le diagramme
de classes)

Quelques remarques Quelques remarques
Un acteur est en dehors du système Un acteur est en dehors du système
Les données relatives à un acteur peuvent toutefois être disponibles Les données relatives à un acteur peuvent toutefois être disponibles
au sein du système et être représentées (une classe dans le diagramme au sein du système et être représentées (une classe dans le diagramme
de classes) de classes)
Il est parfois difficile de décider si un élément fait partie du système à Il est parfois difficile de décider si un élément fait partie du système à
mettre en œuvre ou sert d’acteur. mettre en œuvre ou sert d’acteur. Exemple
Les concepts de base : L’association Les concepts de base : L’association
Un acteur est relié aux cas d’utilisation par des associations qui Un acteur est relié aux cas d’utilisation par des associations qui
indiquent que l’acteur communique avec le système et utilise une indiquent que l’acteur communique avec le système et utilise une
certaine fonctionnalité. certaine fonctionnalité.
Chaque acteur doit communiquer avec au moins un cas d’utilisation.
Un acteur est relié aux cas d’utilisation par des associations qui Un acteur est relié aux cas d’utilisation par des associations qui
indiquent que l’acteur communique avec le système et utilise une indiquent que l’acteur communique avec le système et utilise une
certaine fonctionnalité. certaine fonctionnalité.
Chaque acteur doit communiquer avec au moins un cas d’utilisation. Chaque acteur doit communiquer avec au moins un cas d’utilisation.
Chaque cas d’utilisation doit être en relation avec au moins un acteur. Chaque cas d’utilisation doit être en relation avec au moins un acteur.
Une association est toujours binaire : un cas d’utilisation et un acteur.
Des multiplicités peuvent être spécifiées pour les extrémités de Des multiplicités peuvent être spécifiées pour les extrémités de
l’association : l’association :
I Côté acteur : si une multiplicité est supérieure à 1, cela signifie que
plus d’une instance d’un acteur est impliquée dans l’exécution du cas
d’utilisation. Par défaut la valeur est 1.
Exemple

Définition
Définition
Les acteurs ne représentent pas une personne spécifique, mais des
Des multiplicités peuvent être spécifiées pour les extrémités de
rôles que les utilisateurs peuvent jouer.
l’association :
I Côté acteur : si une multiplicité est supérieure à 1, cela signifie que
plus d’une instance d’un acteur est impliquée dans l’exécution du cas
d’utilisation. Par défaut la valeur est 1.
Exemple
I Côté cas d’utilisation : la multiplicité n’est généralement pas limitée et

n’est donc que rarement spécifiée explicitement.
Les acteurs ne représentent pas une personne spécifique, mais des Les acteurs ne représentent pas une personne spécifique, mais des
rôles que les utilisateurs peuvent jouer. rôles que les utilisateurs peuvent jouer.
Des utilisateurs spécifiques peuvent adopter plusieurs rôles Des utilisateurs spécifiques peuvent adopter plusieurs rôles
simultanément. Exemple simultanément. Exemple
Le concept de rôle est également utilisé dans d’autres diagrammes

UML, tels que le diagramme de classes, de séquence et d’activité.
Les concepts de base : Relation entre acteurs Les concepts de base : Relation entre acteurs
La généralisation La généralisation
En cas de propriétés communes entre acteurs ils sont reliés par une En cas de propriétés communes entre acteurs ils sont reliés par une
relation de généralisation relation de généralisation
Exemple 1
Dans le cas où les acteurs ne partagent pas exactement les mêmes Dans le cas où les acteurs ne partagent pas exactement les mêmes
CU. CU.
Exemple 2
Dans le cas où le super-acteur ’n’existe pas’ Dans le cas où le super-acteur ’n’existe pas’
Exemple 3
Différence entre le partage d’un cas d’utilisation et la collaboration Différence entre le partage d’un cas d’utilisation et la collaboration
dans un cas d’utilisation dans un cas d’utilisation
Exemple 3
Les concepts de base : Relations entre cas d’utilisation Les concepts de base : Relations entre cas d’utilisation
Trois types de relations Trois types de relations

L’inclusion L’inclusion
L’extension
L’inclusion
Si un cas d’utilisation A inclut un cas d’utilisation B le comportement
de B est intégré dans le comportement de A.
Trois types de relations
L’inclusion
L’extension
La généralisation
L’inclusion L’inclusion
Si un cas d’utilisation A inclut un cas d’utilisation B le comportement Si un cas d’utilisation A inclut un cas d’utilisation B le comportement
de B est intégré dans le comportement de A. de B est intégré dans le comportement de A.
Exemple Exemple
Le cas d’utilisation inclus peut être exécuté seul.
L’extension
L’inclusion Si un CU B est dans une relation d’extension avec un CU A, alors A
Si un cas d’utilisation A inclut un cas d’utilisation B le comportement peut utiliser le comportement de B mais n’y est pas obligé.
de B est intégré dans le comportement de A.
Exemple
Le cas d’utilisation inclus peut être exécuté seul.

Un cas d’utilisation peut également être inclus par plusieurs cas
d’utilisation différents.
L’extension L’extension
Si un CU B est dans une relation d’extension avec un CU A, alors A Si un CU B est dans une relation d’extension avec un CU A, alors A
peut utiliser le comportement de B mais n’y est pas obligé. peut utiliser le comportement de B mais n’y est pas obligé.
Exemple Exemple
Les deux cas d’utilisation peuvent également être exécutés

indépendamment l’un de l’autre.
L’extension
Si un CU B est dans une relation d’extension avec un CU A, alors A
peut utiliser le comportement de B mais n’y est pas obligé. La généralisation
Exemple
Si un CU A généralise un CU B, B hérite du comportement de A, que
B peut soit étendre, soit écraser.
Les deux cas d’utilisation peuvent également être exécutés

indépendamment l’un de l’autre.
Un cas d’utilisation peut également être l’extension de plusieurs CU
différents.
Si un CU A généralise un CU B, B hérite du comportement de A, que Si un CU A généralise un CU B, B hérite du comportement de A, que
B peut soit étendre, soit écraser. B peut soit étendre, soit écraser.
B hérite également de toutes les relations de A. B adopte ainsi la B hérite également de toutes les relations de A. B adopte ainsi la
fonctionnalité de base de A mais décide lui-même quelle partie de A fonctionnalité de base de A mais décide lui-même quelle partie de A
est exécutée ou modifiée. est exécutée ou modifiée.
Si un CU est étiqueté abstrait, il n’est pas exécutable ; seuls les CU

spécifiques qui héritent du CU abstrait sont exécutables.
Les concepts de base : Relations entre cas d’utilisation Création d’un diagramme de cas d’utilisation
Méthodologie
La généralisation 1 Identification des acteurs
Exemple
Création d’un diagramme de cas d’utilisation Création d’un diagramme de cas d’utilisation
Méthodologie Méthodologie
1 Identification des acteurs 1 Identification des acteurs
2 Identification des cas d’utilisation 2 Identification des cas d’utilisation
3 Description des cas d’utilisation
3 Description des cas d’utilisation 3 Description des cas d’utilisation
I Nom du CU I Nom du CU
I Brève description
I Brève description I Brève description
I Precondition : condition préalable à une exécution réussie I Precondition : condition préalable à une exécution réussie
I Postcondition : état du système après une exécution réussie
I Postcondition : état du système après une exécution réussie I Postcondition : état du système après une exécution réussie
I Situations d’erreur : erreurs possibles I Situations d’erreur : erreurs possibles
I État du système lors de l’apparition d’une erreur
I État du système lors de l’apparition d’une erreur I État du système lors de l’apparition d’une erreur
I Acteurs qui communiquent avec le cas d’utilisation I Acteurs qui communiquent avec le cas d’utilisation
I Déclencheur : événements qui initient/démarrent le cas d’utilisation.
I État du système lors de l’apparition d’une erreur I État du système lors de l’apparition d’une erreur
I Acteurs qui communiquent avec le cas d’utilisation I Acteurs qui communiquent avec le cas d’utilisation
I Déclencheur : événements qui initient/démarrent le cas d’utilisation. I Déclencheur : événements qui initient/démarrent le cas d’utilisation.
I Processus standard : étapes individuelles à suivre I Processus standard : étapes individuelles à suivre
I Processus alternatifs : les variants au processus standard
Création d’un diagramme de cas d’utilisation Erreurs à ne pas faire

Méthodologie
Exemple de description d’un CU :
Pas de chonologie
Un DCU ne modélise pas un processus. Les cas d’utilisation sont
indépendants : chacun sa fonctionalité.
Erreurs à ne pas faire Erreurs à ne pas faire
Limites du diagramme
Faire attention où tracer les limites du diagramme
Les acteurs sont toujours en dehors des limites du système : s’ils Ne pas mélanger les niveaux d’abstraction
doivent être situés dans le système, ils font partie du système et ne
doivent donc pas être modélisés en tant qu’acteurs.
Erreurs à ne pas faire Erreurs à ne pas faire

Attention à la décomposition fonctionnelle Attention à la décomposition fonctionnelle
Les cas d’utilisation - même les CU inclus ou étendus - peuvent Les cas d’utilisation - même les CU inclus ou étendus - peuvent
toujours être exécutés indépendamment. toujours être exécutés indépendamment.
Si un CU ne peut être exécuté que dans le cadre d’un autre cas
d’utilisation et non de manière indépendante, ils n’est pas un CU et
ne doit pas être décrit comme tel.
Sa fonctionnalité doit alors être couverte dans la description du cas
d’utilisation qui l’utilise.
Erreurs à ne pas faire
Attention à la décomposition fonctionnelle
Les cas d’utilisation - même les CU inclus ou étendus - peuvent
toujours être exécutés indépendamment.
Si un CU ne peut être exécuté que dans le cadre d’un autre cas
d’utilisation et non de manière indépendante, ils n’est pas un CU et
ne doit pas être décrit comme tel.
Sa fonctionnalité doit alors être couverte dans la description du cas
d’utilisation qui l’utilise.
Pr. Salma Mouline C.O.O en UML - Use Case Diagram 29

1 Dcu

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1 Dcu

Transféré par

Droits d'auteur :

Formats disponibles

Des diagrammes et des vues

Conception Orientée Objet en UML

Pr. Salma Mouline

A partir des besoins du client

Les concepts de base : L’acteur Les concepts de base : L’acteur

Les concepts de base : L’acteur Les concepts de base : L’acteur

Les concepts de base : L’acteur Les concepts de base : L’acteur

Les concepts de base : L’association Les concepts de base : L’association

Les concepts de base : L’association Les concepts de base : L’association

I Côté cas d’utilisation : la multiplicité n’est généralement pas limitée et

Le concept de rôle est également utilisé dans d’autres diagrammes

Trois types de relations Trois types de relations

Le cas d’utilisation inclus peut être exécuté seul.

Le cas d’utilisation inclus peut être exécuté seul.

Les deux cas d’utilisation peuvent également être exécutés

Les deux cas d’utilisation peuvent également être exécutés

Si un CU est étiqueté abstrait, il n’est pas exécutable ; seuls les CU

Création d’un diagramme de cas d’utilisation Erreurs à ne pas faire

Erreurs à ne pas faire Erreurs à ne pas faire

Pr. Salma Mouline C.O.O en UML - Use Case Diagram 29

Vous aimerez peut-être aussi