Uml 2 Cas d`utilisation

Claude Belleil
Université de Nantes
Le langage UML 2.0
Diagramme de Cas d'Utilisation
1
Introduction
Les cas d'utilisation décrivent sous la forme d'actions et de réactions le comportement d'un système
du point de vue d'un utilisateur. Ils permettent de définir :
les limites du système en fonction des utilisateurs.
la frontière entre le système est le monde extérieur formé par les utilisateurs ou les autres systèmes
amenés à interagir avec lui.
Un cas d'utilisation est une manière spécifique d'utiliser le système. Le système est complètement
défini fonctionnellement quand on a dressé la liste de tous ses cas d'utilisation.
Les cas d'utilisation se déterminent en observant et en précisant, acteur par acteur, les scénarios
(séquences d'interactions) d'utilisation du système, étape par étape. Une famille de scénarios,
regroupée suivant un critère fonctionnel, forme un cas d'utilisation. Ainsi, un cas d'utilisation est une
sorte de classe dont l'instance serait le scénario.
2
Les Cas d’utilisation
Le formalisme des cas d'utilisation -- basé sur la description de scénarios en langage naturel -- est
accessible pour les utilisateurs, qui peuvent ainsi exprimer leurs attentes et leurs besoins en
communiquant facilement avec les experts du domaine et les informaticiens. La terminologie
employée dans la rédaction des scénarios est celle employée par les utilisateurs dans leur vie de tous
les jours, de sorte que l'expression des besoins s'en trouve grandement facilitée.
Les cas d'utilisation permettent aux utilisateurs de structurer et d'articuler leurs demandes ; ils les
obligent à définir la manière dont ils voudraient interagir avec le système, à préciser quelles
informations ils entendent échanger et à décrire ce qui doit être fait pour obtenir le résultat escompté.
Les cas d'utilisation concrétisent le futur système dans une formalisation proche de l'utilisateur ; ils
favorisent la définition d'un cahier des charges qui reflète réellement les besoins, même en l'absence
d'un système à critiquer.
2.1
flots d’événements
Chaque cas d'Utilisation est décrit par un flot d'évènements. Il s’agit de la suite des évènements qui
permettent d'accomplir la fonctionnalité requise par le cas d'utilisation. Celle-ci est réalisée dans le
langage du domaine en faisant référence aux objets du domaine. En phase d’analyse, c’est une
démarche efficace pour faire apparaître les objets du domaine.
Le langage du domaine est le langage du Client ou du spécialiste avec lequel on décrit le modèle des
besoins. Il est en général nécessaire de créer un Glossaire des termes utilisés, ce glossaire définit le
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
1
langage du domaine.
Les Objets du domaine sont les entités réelles ou conceptuelles que manipule le client et le système.
Ils sont utilisés à la fois pour écrire le modèle des besoins mais constituent également un bon point de
départ pour faire émerger les classes du système.
Les Flots d'évènements décrivent ce que le système doit faire et non pas comment il le fait.
Les flots d'évènements doivent intégrer :
•
•
•
•
•
Quand et comment le cas d'utilisation commence et se termine
Les interactions du cas d'utilisation et des acteurs
Les données nécessaires au cas d'utilisation
La séquence normale d'évènements
La description de tous les flots d'événements alternatifs ou exceptionnels (erreurs).
La description du flot d'évènements est une opération importante qui doit être menée de façon
itérative avec le client.
Une première itération consiste à décrire brièvement les étapes nécessaires pour réaliser le scénario
standard du cas d'utilisation (ce qui est fourni par le cas d'utilisation).
Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le
cas d'utilisation. Les scénarios traversent le cas d'utilisation, en suivant le chemin nominal des
chemins alternatifs et exceptionnels. L'explosion combinatoire fait qu'il est bien souvent impossible de
dérouler tous les scénarios (toutes les combinaison du chemin principal avec les chemins alternatifs et
exceptionnels).
Avec la progression de l'analyse, les différentes étapes sont raffinées. Finalement les scénarios de
gestion d'exceptions sont créés.
Un projet doit définir un modèle de création de flots d'évènements qui possède la structure suivante :
1.
2.
3.
4.
5.
6.
2.2
Flot d'évènement pour le cas d'utilisation <<nom du cas>>
Pré conditions
Flot Principal
Flots Alternatif (si nécessaire)
Flots d'exceptions
Post conditions
Formalisme de représentation
Le modèle des cas d'utilisation comprend au moins quatre éléments :
1.
2.
3.
4.
les acteurs
le système
le ou les cas d'utilisation par eux-mêmes.
les liens entre ces différents éléments
Ainsi, les fonctionnalités d'un système sont déterminées en examinant les besoins fonctionnels de
chaque acteur, exprimés sous la forme de familles d'interactions dans les cas d'utilisation.
============================================================================
«Le Diagramme de Cas d’utilisation1»
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure2»
Contexte :
Les
cas
d’utilisation
sont
un
moyen
de
spécifier
les
usages
1
Les paragraphes avec ce style (Courier New 8) sont des traductions d’extraits du document officiel de définition
du langage UML 2 dont vous trouverez la référence web ci-dessous.
2
http://www.omg.org/technology/documents/formal/uml.htm
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
2
attendus d’un système. Typiquement ils sont utilisés pour cerner les
exigences fonctionnelles d’un système, c’est-à-dire les fonctionnalités que
le système doit remplir. Les concepts clés d’un tel diagramme sont les cas
d’utilisation eux-mêmes, les acteurs et les sujets (subject en anglais). Le
sujet est le système considéré sur lequel les cas d’utilisation s’appliquent.
Les utilisateurs et autres systèmes qui interagissent avec le sujet sont
représentés comme des acteurs.
Les diagrammes des cas d’utilisation sont une spécialisation des diagrammes
de classes dans lesquels les seuls classificateurs qui apparaissent sont
soit des acteurs soit des cas d’utilisation.
Règles :
• Les noeuds graphiques qui peuvent apparaître dans un diagramme des cas
d’utilisation sont : [p.523]3
des acteurs
des points d’extension
des cas d’utilisation
Remarque :
Il est également possible de représenter le sujet ou contexte des cas
d’utilisation comme un rectangle qui entoure tous les cas d’utilisation.
Remarque :
Les cas d’utilisation peuvent apparaître dans d’autres diagrammes afin de
montrer à quel classificateur un cas d’utilisation appartient.
• Les chemins graphiques qui peuvent apparaître dans un diagramme des cas
d’utilisation sont : [p.523]
des relations d’extension
des relations d’inclusion
des associations binaires
des relations de généralisation.
============================================================================
2.2.1
Les Acteurs
Les acteurs sont des entités en interaction avec le système. Ils sont représentés sous la forme de
petits personnages qui déclenchent les cas d'utilisation ceux-ci étant représentés par des ellipses
contenues par le système.
============================================================================
« Acteur »
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure4»
Contexte : Un acteur (actor en anglais) représente un ensemble cohérent de
rôles
que
peuvent
jouer
des
utilisateurs
d’un
système
lorsqu’ils
interagissent avec les cas d’utilisation.
Règles
:
• Un acteur ne peut avoir d’associations qu’avec
des
des
des
des
cas d’utilisation
sous-systèmes
composants
classes. [p.513]
• Les associations mettant en jeu un acteur doivent être binaires. [p.513]
• Un acteur doit avoir un nom. [p.513]
• Un acteur ne doit pas être contenu par un autre classificateur. [Règle
dérivée du méta-modèle]
============================================================================
3
4
Numéro de la page dans le document «UML2SuperStructure»
http://www.omg.org/technology/documents/formal/uml.htm
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
3
Figure 1 : Représentation des acteurs
Le niveau de détail de présentation d'un cas d'utilisation correspond à la visibilité que l'acteur a du
système.
On doit distinguer entre les acteurs principaux et les acteurs secondaires. Les fonctionnalités
principales du système ont été définies pour les acteurs principaux. Afin d'atteindre cet objectif, il est
en général nécessaire de réaliser des opérations en amont et en aval de ces fonctions principales.
C'est le rôle des acteurs secondaires . Cela peut être par exemple la gestion des droits utilisateurs, la
sauvegarde de la base de données, etc. Dans bien des cas, cette classification s'avère suffisante,
toute fois certains professionnels proposent de l'affiner :
Un acteur peut être humain ou purement informatique, hardware ou software. Il peut avoir de multiples
"personnalités", jouer plusieurs rôles dans un ou plusieurs cas d'utilisation; on en identifie quatre :
1. Initiateur : Rôle joué par un acteur qui déclenche le cas, qui met en mouvement le système.
2. Serveur : Rôle joué par un acteur lorsqu'il aide le système à assumer ses responsabilités.
3. Receveur : Rôle joué par un acteur lorsqu'il reçoit des informations du système (par exemple
un SGBD ou un système de backup ).
4. Facilitateur : Rôle joué par un acteur lorsqu'il réalise une action pour le bénéfice d'un autre
(un guichetier pour un client par exemple).
Les acteurs se déterminent en observant les utilisateurs directs du système, ceux qui sont
responsables de son exploitation ou de sa maintenance, ainsi que les autres systèmes qui
interagissent avec le système en question.
Un acteur étant défini par son rôle dans l'interaction avec le scénario d'utilisation, il peut être constitué
par un autre sous-système interne et donc modélisé par un autre scénario d'utilisation.
Les acteurs potentiels se recrutent parmi les utilisateurs, les partenaires, les autres systèmes, c’est à
dire, les personnes et les éléments extérieurs à un système qui interagissent avec lui en échangeant
de l'information.
Un diagramme de cas d’utilisation ne se construit pas en une seule fois. La détermination des acteurs
permet de préciser les limites du système de manière progressive : floues au départ, elles se
précisent au fur et à mesure de l'élaboration des différents cas d'utilisation.
Cette activité de délimitation est extrêmement importante car elle sert de base contractuelle où est
signalé ce qui doit être fait, ce qui fait partie du système à développer et ce qui n'en fait pas partie.
Elle précise également les éléments intangibles, que l'équipe de développement ne peut pas modifier.
Il existe quatre grandes catégories d'acteurs :
•
•
•
•
2.2.2
Les acteurs principaux qui regroupent les personnes utilisant les fonctions principales du
système.
Les acteurs secondaires qui regroupent les personnes réalisant des tâches nécessaires au
fonctionnement du système, mais n’étant pas à l’origine de son activation
Les autres systèmes regroupant les systèmes avec lesquels le système doit interagir.
Le matériel externe. Il ne s’agit pas de l’ordinateur sur lequel s’exécute l’application, mais des
autres dispositifs matériels.
Les Cas d’utilisation
Un cas d'utilisation regroupe une famille de scénarios d'utilisation selon un critère fonctionnel. Les cas
d'utilisation sont des abstractions du dialogue entre les acteurs et le système : ils décrivent des
interactions potentielles, sans entrer dans les détails de chaque scénario. Ils peuvent être vus comme
des classes dont les instances sont les scénarios.
_____________________________________________________________________________
4
Le Langage UML 2.0
Claude Belleil
Université de Nantes
Figure 2: Un Cas d’Utilisation se représente sous la forme d’un ovale
============================================================================
« Cas d’utilisation »
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure5»
Contexte : Un cas d’utilisation (use case en anglais) est un classificateur
qui représente une unité cohérente de fonctionnalités fournies par un
système, un sous-système ou une classe.
Règles
:
• Un cas d’utilisation doit avoir un nom. [p.520]
• Les cas d’utilisation ne doivent participer qu’à des associations
binaires.[p.520]
• Un cas d’utilisation ne doit pas avoir d’associations avec d’autres cas
d’utilisation qui spécifient le même système. [p.520]
============================================================================
2.2.3
Notion de scénario
Un scénario est une séquence d’événements se déroulant dans le temps. C’est une instance d’un cas
d’utilisation du système. En général, un cas d’utilisation comporte plusieurs scénarios.
Figure 3: Représentation symbolique de scénarios alternatifs d'un cas d'utilisation6
Un événement est une transmission d’information, une communication soit entre un acteur et un objet,
entre un objet et un autre objet, ou encore entre un objet et lui-même.
En général on formalise un scénario par une liste numérotée d’actions7. Bien que ne faisant pas partie
directement du formalisme UML, les scénarios ont fait l’objet d’une normalisation, sous la forme de
fiche standardisées.
2.3
Les relations dans les cas d’utilisation
UML prédéfinit quatre types particuliers8 de relations dans un diagramme de cas d'utilisation.
A ce sujet, Thierry Cros note :
« Les relations entre cas d'
utilisation sont en fait des relations entre ensembles
5
http://www.omg.org/technology/documents/formal/uml.htm
D’après : http://grand.patrice.free.fr
7
Voir en annexe un exemple de fiche de description d’un scénario
8
Ils sont définis comme étant des « stereotypes »
6
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
5
d'
interactions et ne représentent pas une décomposition fonctionnelle. Elles
permettent d'
organiser les interactions, alors que les paquetages permettront
d'
organiser les cas - en tant que fonctionnalités - eux-mêmes par acteur ou
priorité ou tout autre critère logique choisi par le modeleur.
Lorsque la description textuelle fait apparaître des interactions communes à
plusieurs cas, la relation <<include>> (qui remplace le stéréotype <<uses>>)
permet d'
éviter la réécriture
Lorsque dans un diagramme, un cas A dépend d'
un cas B au travers d'
une
relation <<include>>, cela ne signifie donc pas que B est une fonction qui sera
appelée par A. Cela indique simplement que les interactions décrites dans B sont
à injecter dans les interactions décrites dans A. Plus tard, ces interactions seront
de la responsabilité de plusieurs objets du système. En fait, à une interaction (par
exemple : le système affiche le total H.T.), correpondra très probablement une
collection d'
opérations dans plusieurs objets. Chacun des objets collaborants
sera peut-être impliqué dans plusieurs scénarii de plusieurs cas. La relation
<<include>> est inconditionnelle. A partir du moment où elle est modélisée entre
deux cas, l'
inclusion des interactions est systématique. Il est aussi possible de
créer ces descriptions d'
interactions incluses simplement pour alléger la
description de cas principaux ou secondaires particulièrement importants.9»
Voici, à titre d’exemple, un ensemble de cas d’utilisation d’un système que l’on appelle « Magasin10 ».
Dans une première phase d’analyse, les différents cas sont définis, sans que l’on puisse détecter de
façon certaine les relations qui peuvent exister entre eux.
Ce sont les scénarios, illustrés par des diagrammes de séquence d’objets qui permettront de mettre
en évidence ces relations particulières, grâce à des séquences communes ou optionnelles.
Figure 4 : Les différents cas d'utilisation du système « Magasin»
9
Thierry Cros
Inspiré de Pascal André et Alain Vailly « Génie Logiciel » Editions Ellipses
10
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
6
L’analyse des diagrammes de séquence d’objet correspondant à chacun des cas fait apparaître les
relations suivantes :
Figure 5 : Les mêmes cas raffinés et reliés
2.3.1 La relation <<Association>>
C'est la seule relation autorisée entre un acteur et un cas d’utilisation. C’est une relation de
communication. La participation de l'acteur est signalée par un trait ou une flèche entre l'acteur et le
cas d'utilisation. Elle peut porter des cardinalités. A ce sujet Thierry Cros11 écrit :
« UML définit une relation entre acteurs et système: l'
association. Cette relation
correspond plus précisément à un potentiel de communication entre acteurs et
système (techniquement, la relation d'
association est stéréotypée en
<<communication>>. (….) De même qu'
une association dans un diagramme de
classes représente une relation permanente, un potentiel de liens, de même la
relation de communication entre acteurs et cas. Il est quelquefois judicieux
d'
indiquer les informations (qui deviendront des objets dans le développement)
échangées entre acteurs et système, par rapport au cas. Il est alors possible
d'
utiliser des mécanismes communs tels que étiquettes, contraintes ou notes. La
communication étant la relation permanente entre acteur et système, un label
devrait éviter toute ambiguïté avec une modélisation dynamique. En dernière
analyse, les diagrammes d'
interactions 12 permettent de spécifier les échanges
entre acteurs et système. Ils modélisent des scénarii et sont donc tout à fait
adaptés à la représentation des échanges, d'
un point de vue dynamique. Ils sont
très complémentaires des diagrammes de cas d'
utilisation. »
11
12
séquence ou collaboration
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
7
Figure 6: Relations stéréotypées «association »
2.3.2
La relation <<Extend>>
Une relation d'extension entre cas d'utilisation signifie que le cas d'utilisation source étend le
comportement du cas d'utilisation destination. C'est une relation entre deux instances de scénarios
telle que A étend B signifie que le comportement d'un scénario B peut être complété par le
développement d'un scénario A. Par exemple dans la figure 6 ci-dessous, le cas d’utilisation «Obtenir
une réduction» étend le cas d’utilisation « Commander un produit». Ainsi, « Obtenir une réduction»
correspond à un ensemble d’opérations qui doivent s’ajouter aux opérations de « Commander un
produit ». Ces opérations supplémentaires n’ont de sens que si les opérations de « Commander un
produit » sont réalisées.
La relation <<Extend>> doit spécifier à la fois :
•
•
la condition de l'extension
le point d'extension, c’est à dire l'endroit où l'extension doit être faite dans le cas d’utilisation
général.
La relation <<Extend>> spécifie donc une possibilité, une option.
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
8
Figure 7: Relations stéréotypées "extend"
Figure 8 : Exemple d’extension à partir d’un scénario nominal13
============================================================================
« Extension »
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure14»
Contexte : Une relation d’extension (extend relationship en anglais) met en
relation un cas d’utilisation < étendant > et un cas d’utilisation < étendu
> et spécifie comment et quand le comportement du cas d’utilisation <
étendant > peut être inséré dans le comportement du cas d’utilisation <
étendu >.
Il est possible de préciser via une note, la condition qui déterminera si le
cas d’utilisation est étendu ou non par le cas d’utilisation cible. La note
peut également faire apparaître le nom du point d’extension à laquelle se
réfère la condition
13
D’après : http://grand.patrice.free.fr
14
http://www.omg.org/technology/documents/formal/uml.htm
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
9
!
#
$
"
Figure 9: Exemple de relation d’extension avec spécification du nom du point d’extension
Règles :
• Une relation d’extension a comme source un (et un seul) cas
d’utilisation.[Règle dérivée du méta-modèle]
•
Une
relation
d’extension
a
comme
cible
un
(et
un
seul)
cas
d’utilisation.[Règle dérivée du méta-modèle]
• Le point d’extension qui est référencé par la relation d’extension doit
appartenir au cas d’utilisation < étendu.> [p.515]
• La condition (si présente dans la note) est une contrainte et doit donc
répondre aux règles de contraintes [p.55]
Relations
Remarque : Les cas d’utilisation étant généralement utilisés pendant la
phase d’analyse, il est souvent difficile d’exprimer la contrainte autrement
qu’en langage naturel, ce qui limite la capacité d’analyse statique.
============================================================================
2.3.3
La relation <<Include>>
Une relation <<include>> entre cas d'utilisation signifie qu'une instance du cas d'utilisation « source »
comprend également le comportement décrit par le cas d'utilisation « destination ». C'est une relation
entre deux instances de scénarios d'utilisations, telle que la réalisation de la fonction de l'un nécessite
la réalisation de la fonction de l'autre. Elle signifie donc qu’une instance du cas d’utilisation « source »
comprend (inclut) également le comportement décrit par le cas d’utilisation de destination. Dans la
figure 10, le cas d’utilisation « Régler la Facture» inclut le cas d’utilisation « Payer ».
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
10
Figure 10 : Relations stéréotypées "Include"
Figure 11 : Exemple d'inclusion dans un scénario nominal15
============================================================================
« Inclusion »
Règles de cohérence extraites du document de l’OMG « UML2SuperStructure16»
Contexte : Une relation d’inclusion (include relationship en anglais) entre
deux cas d’utilisation implique que le comportement du cas d’utilisation qui
est inclus est inséré dans le comportement du cas d’utilisation < incluant >.
Le cas d’utilisation cible de la relation est inclus dans la cas
d’utilisation source de
la relation.
Règles :
• Une relation d’inclusion a comme source
d’utilisation.[Règle dérivée du méta-modèle]
•
Une
relation
d’inclusion
a
comme
cible
d’utilisation.[Règle dérivée du méta-modèle]
15
D’après : http://grand.patrice.free.fr
16
http://www.omg.org/technology/documents/formal/uml.htm
un
(et
un
seul)
cas
un
(et
un
seul)
cas
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
11
• Les relations d’inclusion ne doivent pas former de circuit. [Nouvelle
règle]
============================================================================
2.3.4
La relation <<Generalize>>
Elle exprime la relation de « généralisation spécialisation » qui sera présentée en détail lors de l’étude
du diagramme de classes. Elle est souvent désignée par le concept "est une sorte de". A l’inverse
des précédentes, il s'agit d'une relation entre deux cas d’utilisation et non entre des instances17 de
ceux-ci.
Figure 12 : Relation stéréotypées "Généralize"
La portée des cas d'utilisation dépasse largement la définition des seuls besoins du système. En effet,
les cas d'utilisation interviennent tout au long du cycle de vie, depuis le cahier des charges jusqu'aux
tests, en passant par l'analyse, la conception, la réalisation et la rédaction de la documentation pour
l'utilisateur. De ce point de vue, il est possible de naviguer vers les classes et les objets qui
collaborent pour satisfaire un besoin, puis vers les tests qui vérifient que le système s'acquitte
correctement de sa tâche.
2.4
2.4.1
Construction des Cas d’utilisation
Les Scénarios
Comme nous l’avons déjà vu, un cas d’utilisation correspond à un ensemble de scénarios, chacun
d’entre eux étant formalisé par un diagramme de séquence d’objet ou un diagramme de collaboration.
Bien qu'UML ne préconise pas explicitement un cycle de développement particulier, les cas
d’utilisation induisent un enchaînement particulier dans l’utilisation des diagrammes. Cet
enchaînement consiste à regarder le système à construire de l'extérieur, du point de vue de
l'utilisateur et des fonctionnalités qu'il en attend. Chaque cas d’utilisation consiste en un ensemble de
« scénarios possibles ». C’est leur étude qui permettra de mettre en évidence des factorisations
17
scénarios
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
12
possibles dans le cas des <<include>>, des options dans le cas des <<extend>> et des
généralisations spécialisations.
Un scénario peut être employé de deux manières :
- comme une spécification de ce qu'il sera possible de demander de l'extérieur à l'entité ainsi
représentée
- comme une spécification de la fonctionnalité offerte par cette même entité (déjà réalisée).
D'un point de vue méthodologique, le scénario décrit un ensemble cohérent de fonctions pour
l'utilisateur.
2.4.2
Processus d’élaboration des Cas d’Utilisation
Au moment la construction des cas d'utilisation, il faut se demander :
•
•
•
•
quelles sont les responsabilités de l'acteur vis à vis du système?
quelles sont les informations qu’il devra créer, sauvegarder, modifier, détruire ou simplement
lire ?
devra-t-il informer le système des changements externes ?
le système devra-t-il informer l'acteur de l’évolution interne du système ?
Les cas d'utilisation peuvent être présentés aux travers de vues multiples :
•
•
un acteur avec tous ses cas d'utilisation
un cas d'utilisation avec tous ses acteurs
Les cas d'utilisation peuvent également être groupés selon leurs séquences de déclenchement types,
c'est-à-dire en fonction de leurs enchaînements, ou encore en fonction des différents points de vue,
souvent corrélés aux grandes catégories d'acteurs (client, fournisseur, maintenance...).
L'étape suivante consiste à classer les cas d'utilisation selon leur
2.4.3
Règles de mise en œuvre
Un cas d'utilisation décrit non seulement une fonctionnalité ou une motivation, mais aussi une
interaction entre un acteur et un système sous la forme d'un flot d'événements. La description de
l'interaction se concentre sur ce qui doit être fait dans le cas d'utilisation, pas sur la manière de le faire.
Un cas d'utilisation doit rester simple et compréhensible par le donneur d’ordre qui n’est pas
obligatoirement un spécialiste de la modélisation conceptuelle.
La description d'un cas d'utilisation comprend les éléments suivants :
•
•
•
•
•
•
•
le début du cas d'utilisation, c’est à dire l'événement qui le déclenche. Il doit être clairement
exprimé avec une assertion du type : « Le cas débute quand l’événement X se produit. » ;
de façon symétrique, la fin de celui-ci, c’est à dire l'événement qui cause l'arrêt du cas
d'utilisation. Lui aussi doit être clairement identifié et documenté par une assertion du type : «
Quand l’événement Y se produit, le cas d'utilisation est terminé. » ;
l'interaction entre le cas d'utilisation et les acteurs qui décrit clairement les limites du système ;
les échanges d'informations entre le système et les acteurs. Une formulation en langage
naturel est préférable à toute autre, par exemple : « Le Client demande des renseignements
concernant les compositions florales au vendeur» ;
la chronologie et l'origine des informations qui décrivent quand le système a besoin
d'informations internes ou externes et quand il les enregistre à l'intérieur ou à l'extérieur ;
les comportements répétitifs
les situations optionnelles qui doivent apparaître clairement à l’aide de formulations du type
de: «L'acteur choisit l'un des éléments suivants, éventuellement plusieurs fois de suite »
Ces points ne suffisent pas pour obtenir un bon cas d'utilisation. Il est également primordial de trouver
_____________________________________________________________________________ 13
Le Langage UML 2.0
Claude Belleil
Université de Nantes
le bon niveau de granularité, c'est-à-dire la quantité de détails qui doivent apparaître, et de faire la
distinction entre un cas d'utilisation qui est obligatoirement conceptuel et un scénario qui est
nécessairement contingent. Il n’existe pas de méthodologie apportant une aide dans ce domaine.
L'appréciation du niveau de granularité repose essentiellement sur l'expérience.
2.4.4
Cas d’Utilisation : un processus d'élaboration itératif et contractuel18
La modélisation par les Cas d’Utilisation est une technique imprécise, assez difficile à mettre en
œuvre. Néanmoins, elle apparaît comme un document contractuel sur lequel le donneur d'ordre et
l'exécutant peuvent travailler.
Elle permet de vérifier qualitativement la conformité du produit avec les spécifications. Ce « mal
nécessaire » vient du fait que le donneur d'ordre ignore la façon dont le produit sera conçu et que le
donneur d'ordre pense essentiellement aux « fonctionnalités » du futur système.
La modélisation par Cas d’Utilisation adopte un formalisme assez simpliste, ce qui facilite la
compréhension par tout le monde, surtout aux non initiés aux pratiques objet.
Ce n'est pas une technique OBJET en soi. L’analyste profite du flou relatif sur la modélisation par les
Cas d’Utilisation pour laisser le champ libre à sa conception future du produit
L'exécutant a besoin des Cas d’Utilisation pour faire l'évaluation de l'ampleur du projet et établir le
coût et les autres paramètres.
Une bonne modélisation par les Cas d’Utilisation doit répondre à la question : que fait le système à un
haut niveau et jamais comment il le fait (WHAT et NOT HOW) ?
Doit-on décomposer les Cas d’Utilisation et partir dans les techniques de réduction de complexité ?
Réponses:
•
•
NON lorsqu’on est capable, avec les Cas d’Utilisation en place, d’estimer l’ampleur du projet.
OUI en considérant les sous-systèmes comme des systèmes « indépendants » en soi. Avec
cette démarche, on s’assure que la décomposition respecte le principe d’indépendance des
sous systèmes. On s’assurera que les sous-systèmes peuvent être considérés comme des
objets à part entière.
Quelques recettes pour établir les cas d’utilisation
Étape 1: Identifiez les « usagers » du système. Ce sont les acteurs avec le stéréotype « acteur ».
Lorsqu’un système est subdivisé en sous-systèmes plus élémentaires, un sous-système peut devenir
un acteur pour un autre sous système et n’a rien d’humain. Dans ce cas, servez-vous du stéréotype
« classe » pour l’acteur si le sous-système qui agit en tant qu’acteur s’apparente à un objet.
Étape 2: Différenciez les acteurs si la nature du problème l’exige. Cherchez les propriétés communes
de ces acteurs. Factorisez éventuellement un acteur commun et dérivez (si possible) les autres
acteurs à partir de cet acteur commun
Étape 3: Choisissez l'acteur type ou l'acteur le plus important. Cherchez ce que cet acteur peut faire
avec votre système et identifiez les premiers Cas d’Utilisation de base
Étapes 4: Étudiez chaque Cas d’Utilisation de base. S'il a l'air complexe et ne vous permet pas
d'estimer l'ampleur du projet, identifiez les Cas d’Utilisation sous-jacents les plus importants sans
caractériser à cette étape-ci les relations entre les Cas d’Utilisation (include, extend, etc.)
Étape 5: Décrivez en détail chaque Cas d’Utilisation, aussi bien des Cas d’Utilisation de base que les
Cas d’Utilisation sous-jacents. C'est une étape importante car elle permet de clarifier ce que vous
voulez confier comme tâches à votre système. Cette description est consultée, d'un côté, par le
donneur d'ordre, de l'autre, par les développeurs.
Bien que la description soit TEXTUELLE, restez PRÉCIS, CONCIS
Ne pas faire mention de l'interface usager dans cette description car ce faisant, vous ligotez les bras
du développeur.
18
d’après Bui Minh Duc, Ingénieur INSA de Lyon
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
14
Étape 6: Trouvez maintenant les traitements communs dans les descriptions et cherchez les
possibilités de factorisation. Dégagez si possible les Cas d’Utilisation « factorisés »
Étape 7: Établissez maintenant les liens stéréotypés pour préciser la sémantique de votre analyse un
peu plus technique de la spécification.
Étape 8: Vous devez recommencer les étapes 4 à 7 pour tous les Cas d’Utilisation de base.
Étape 9: Identifiez les acteurs secondaires (par exemple, les acteurs de maintenance) et
recommencez les étapes de 2 à 8 pour les acteurs secondaires.
3
Conclusion
Ce document est une première présentation de l’articulation entre les trois éléments qui constituent
toujours une première approche d’un processus d’analyse « objet » utilisant les digrammes UML :
•
•
•
•
Cas d’utilisation (généraliste)
Scénarios correspondants
Pour chacun des scénarios, diagramme de séquence d’objets
Pour synthétiser plusieurs scénarios, diagramme d’activités
L’observation des diagrammes de séquences va nous amener à considérer qu’il existe parfois des
séquences de messages entre objets qui se retrouvent d’un diagramme à l’autre. Il faut alors
envisager un regroupement de ces séquences en une séquence unique qui constituera un « sous-cas
d’utilisation » relié au cas principal par un <<include>>.
A l’opposé, il peut se trouver une sous séquence particulière renvoyant plutôt à une option possible.
Ce sera alors un sous cas d’utilisation correspondant à une extension du cas principal. Il sera relié par
une relation <<extend>>.
Tout cela n’est possible que par une approche itérative entre les trois composants déjà cités (Cas
d’utilisation, scénarios, diagrammes de séquences). L’objectif est de raffiner le cas d’utilisation jusqu’à
obtenir un niveau de décomposition et de granularité pertinents au regard de l’analyse que nous
conduisons. Un prochain polycopié sera consacré à ce processus itératif, en présentant de façon plus
détaillée les diagrammes de séquences.
Enfin, une dernière précision qui peut paraître évidente pour tout le monde, mais l’expérience montre
qu’il est souvent nécessaire de la reformuler. Dans un premier temps, les scénarios et les
diagrammes de séquence représentent l’activité des objets « métier » . Ce n’est que dans un second
temps qu’ils donneront naissance à des objets informatiques. Garder cela présent à l’esprit, c’est
garantir que le futur système sera une image fidèle (aussi fidèle que possible !) de la réalité
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
15
Index du Texte
1
2
Introduction....................................................................................................................................... 1
Les Cas d’utilisation ......................................................................................................................... 1
2.1 flots d’événements...................................................................................................................... 1
2.2 Formalisme de représentation.................................................................................................... 2
2.2.1
Les Acteurs ........................................................................................................................ 3
2.2.2
Les Cas d’utilisation........................................................................................................... 4
2.2.3
Notion de scénario............................................................................................................. 5
2.3 Les relations dans les cas d’utilisation ....................................................................................... 5
2.3.1
La relation <<Association>> .............................................................................................. 7
2.3.2
La relation <<Extend>> ..................................................................................................... 8
2.3.3
La relation <<Include>> ................................................................................................... 10
2.3.4
La relation <<Generalize>> ............................................................................................. 12
2.4 Construction des Cas d’utilisation ............................................................................................ 12
2.4.1
Les Scénarios .................................................................................................................. 12
2.4.2
Processus d’élaboration des Cas d’Utilisation................................................................. 13
2.4.3
Règles de mise en œuvre................................................................................................ 13
2.4.4
Cas d’Utilisation : un processus d'élaboration itératif et contractuel ............................... 14
3 Conclusion...................................................................................................................................... 15
Index des Figures
Figure 1 : Représentation des acteurs .................................................................................................... 4
Figure 2: Un Cas d’Utilisation se représente sous la forme d’un ovale .................................................. 5
Figure 3: Représentation symbolique de scénarios alternatifs d'un cas d'utilisation .............................. 5
Figure 4 : Les différents cas d'utilisation du système « Magasin» .......................................................... 6
Figure 5 : Les mêmes cas raffinés et reliés............................................................................................. 7
Figure 6: Relations stéréotypées «association » .................................................................................... 8
Figure 7: Relations stéréotypées "extend" .............................................................................................. 9
Figure 8 : Exemple d’extension à partir d’un scénario nominal............................................................... 9
Figure 9: Exemple de relation d’extension avec spécification du nom du point d’extension ................ 10
Figure 10 : Relations stéréotypées "Include" ........................................................................................ 11
Figure 11 : Exemple d'inclusion dans un scénario nominal ................................................................. 11
Figure 12 : Relation stéréotypées "Généralize" .................................................................................... 12
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
16
Annexe 1
Fiche de description d’un scénario de cas d’utilisation
Préparation à la formalisation d’un diagramme de séquence d’objets (scénario nominal) ou d’un
diagramme d’activités (scénarios nomimal et alternatifs)
Numéro et Nom du Cas
Objectif
Date de création :
Date de la dernière mise à jour
Acteur principal
Acteur secondaire
Pré - conditions
Post – conditions
Déclencheur
Scénario nominal
Scénarios Alternatifs
Extensions
Cas d’utilisation inclus
Cas d’utilisation optionnels
Exigences spéciales
Alternatives
et
technologiques
contraintes
Problèmes ouverts :
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
17
Annexe 2
Historique des Cas d’utilisation
C’est à Ivar Jacobson, auteur de la méthode Objectory que l’on doit les premières formulations. Cette
méthode a ensuite été complétée notamment par les Use case pour devenir OOSE : Object-Oriented
Software Engineering.
La définition de Jacobson en 1995 est la suivante:
« A use case is a sequence of transactions in a system whose task is to yield a
measurable value to an individual actor of the system."
Jacobson fait des cas d'utilisation un guide pour l'analyse des besoins et l'architecture complète d'un
système logiciel. Il en souligne deux avantages essentiels. :
"Lorsque nous souhaitons modifier le comportement d'
un système, nous
refaisons le modèle de l'
acteur concerné et le cas d'
utilisation. L'
architecture de
tout le système dépendra de ce que les utilisateurs veulent en faire (...) Le
modèle des besoins est facile à comprendre et à formuler du point de vue de
l'
utilisateur, de sorte que nous pouvons facilement parler avec les utilisateurs et
vérifier que nous construisons bien le système correct qui répond à leurs
besoins"
Les cas d'utilisation recentrent l'expression des besoins sur les utilisateurs, en partant du point de vue
qu'un système est construit pour eux. La structuration de la démarche s'effectue par rapport aux
interactions d'une seule catégorie d'utilisateurs à la fois ; cette partition de l'ensemble des besoins
réduit considérablement la complexité de la détermination des besoins.
Laurent Piechocki de la société Valtech note sur le site internet qu’il consacre à la présentation d’UML
(http://uml.free.fr) :
« Le modèle conceptuel est le type de diagramme UML qui possède la notation
la plus simple ; mais paradoxalement c'
est aussi celui qui est le plus mal compris!
Au début des années 90, Ivar Jacobson (inventeur de OOSE, une des méthodes
fondatrices d'
UML) a été nommé chef d'
un énorme projet informatique chez
Ericsson. Le hic, c'
est que ce projet était rapidement devenu ingérable, les
ingénieurs d'
Ericsson avaient accouché d'
un monstre. Personne ne savait
vraiment quelles étaient les fonctionnalités du produit, ni comment elles étaient
assurées, ni comment les faire évoluer...
Classique lorsque les commerciaux promettent monts et merveilles à tous les
clients qu'
ils démarchent, sans se soucier des contraintes techniques, que les
clients ne savent pas exprimer leurs besoins et que les ingénieurs n'
ont pas les
ressources pour développer le mouton à cinq pattes qui résulte de ce chaos.
Pour éviter de foncer droit dans un mur et mener à bien ce projet critique pour
Ericsson, Jacobson a eu une idée. Plutôt que de continuer à construire une tour
de Babel, pourquoi ne pas remettre à plat les objectifs réels du projet ? En
d'
autres termes : quels sont les besoins réels des clients, ceux qui
conditionneront la réussite du projet ? Ces besoins critiques, une fois identifiés et
structurés, permettront enfin de cerner ce qui est important pour la réussite du
projet.
Le bénéfice de cette démarche simplificatrice est double. D'
une part, tous les
acteurs du projet ont une meilleure compréhension du système à développer,
d'
autre part, les besoins des utilisateurs, une fois clarifiés, serviront de fil rouge,
tout au long du cycle de développement.
A chaque itération de la phase d'
analyse, on clarifie, affine et valide les besoins
des utilisateurs ; à chaque itération de la phase de conception et de réalisation,
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
18
on veille à la prise en compte des besoins des utilisateurs et à chaque itération
de la phase de test, on vérifie que les besoins des utilisateurs sont satisfaits.
Simple mais génial. Pour la petite histoire, sachez que grâce à cette démarche
initiée par Jacobson, Ericsson a réussi à mener à bien son projet et a gagné une
notoriété internationale dans le marché de la commutation.
Morale de cette histoire :
La détermination et la compréhension des besoins sont souvent difficiles car les
intervenants sont noyés sous de trop grandes quantités d'
informations. Or,
comment mener à bien un projet si l'
on ne sait pas où l'
on va ?
Conclusion : il faut clarifier et organiser les besoins des clients (les modéliser).
Jacobson identifie les caractéristiques suivantes pour les modèles :
Un modèle est une simplification de la réalité.
Il permet de mieux comprendre le système qu'
on doit développer.
Les meilleurs modèles sont proches de la réalité.
Les use cases, permettent de modéliser les besoins des clients d'
un système et
doivent aussi posséder ces caractéristiques.
Ils ne doivent pas chercher l'
exhaustivité, mais clarifier, filtrer et organiser les
besoins!
Une fois identifiés et structurés, ces besoins :
définissent le contour du système à modéliser (ils précisent le but à
atteindre),
permettent d'
identifier les fonctionnalités principales (critiques) du système.
Les use cases ne doivent donc en aucun cas décrire des solutions
d'
implémentation. Leur but est justement d'
éviter de tomber dans la dérive d'
une
approche fonctionnelle, où l'
on liste une litanie de fonctions que le système doit
réaliser.
Bien entendu, rien n'
interdit de gérer à l'
aide d'
outils (Doors, Requisite Pro, etc...)
les exigences systèmes à un niveau plus fin et d'
en assurer la traçabilité, bien au
contraire.
Mais un modèle conceptuel qui identifie les besoins avec un plus grand niveau
d'
abstraction reste indispensable. Avec des systèmes complexes, filtrer
l'
information, la simplifier et mieux l'
organiser, c'
est rendre l'
information
exploitable. Produisez de l'
information éphémère, complexe et confuse, vous
obtiendrez un joyeux "désordre" (pour rester poli).
Dernière remarque :
Utilisez les use cases tels qu'
ils ont été pensés par leurs créateurs ! UML est issu
du terrain. Si vous utilisez les use cases sans avoir en tête la démarche sousjacente, vous n'
en tirerez aucun bénéfice ».
_____________________________________________________________________________
Le Langage UML 2.0
Claude Belleil
Université de Nantes
19