Définition
L'article UML: diagrammes de
classe nous a permis de comprendre comment traduire sous forme
de représentations accessibles à tous l'architecture
d'un programme orienté objet. Ces représentations
se bornaient à décrire les objets, les classes et
leurs interactions, mais pas les modes de réaction du
programme modélisé à des scénarios d'utilisation.
Or UML permet, par des diagrammes de cas d'utilisation, de
représenter comment le système modélisé
se comporte du point de vue de l'utilisateur, à savoir un
acteur externe. On décrit ainsi la participation d'un
acteur à un cas d'utilisation, lequel regroupe plusieurs
scénarios d'utilisation du système.
Notation
D'emblée, notons que le terme "cas d'utilisation"
(en anglais use case) désigne en fait un scénario
d'utilisation (par exemple un acteur "client" va "consulter
l'état d'une commande") et, par abus de langage, l'ensemble
des scénarios d'utilisation.
Le schéma ci-dessous va nous permettre de clarifier certains
concepts de la notation UML (attention: les inscriptions en bleu
ne font pas partie de cette notation). D'abord la notion de "paquetage":
les paquetages sont des regroupements destinés à clarifier
la manière dont un modèle est subdivisé; ils
peuvent contenir des sous-paquetages. Ensuite la "note",
qui est un simple commentaire placé en rapport à un
élément diagramme (auquel elle est attachée
par une ligne en pointillé). Puis la notion de "stéréotype":
un stéréotype qualifie un certain type d'information;
par exemple, si une note doit être considérée
comme un élément du modèle, et non un simple
commentaire (en d'autres termes, si la note véhicule du contenu
dans la sémantique du modèle), elle est une "contrainte".
Un stéréotype est noté entre les caractères
"<<" et ">>".
Mais revenons à nos cas d'utilisation: nous
retrouvons sur le diagramme (purement illustratif) un acteur
(il peut y en avoir plusieurs), un système (ce qui
est modélisé) et donc des cas d'utilisation.
Il existe des relations entre les acteurs et les cas d'utilisation
au sein d'un système. Par exemple la relation entre l'acteur
"client" et le cas d'utilisation "consulter l'état
d'une commande" peut être désignée par
"visualise".
Un cas d'utilisation peut-être en relation avec un autre de
deux manières: soit il "l'utilise" (includes),
soit il "l'étend" (extends). Ainsi
par exemple le cas d'utilisation "consulter l'état d'une
commande" utilisera peut-être les objectifs des cas d'utilisation
"retrouver la commande dans la base" et "afficher
l'état d'une commande"; tandis que le cas d'utilisation
"afficher une facture" étendra les cas d'utilisation
"afficher une facture en francs" et "afficher une
facture en euros".
Compléments
La représentation sous forme de diagrammes de cas
d'utilisation est bien distincte, dans ses objectifs, de la représentation
sous forme de diagrammes de classes. Ces derniers décrivent
l'architecture du système modélisé afin de
dégager la manière dont les données sont réparties,
regroupées, et collaborent, suivant une approche objet; les
premiers décrivent le système modélisé
tel qu'il se comporte vis à vis de l'utilisateur, afin de
dégager la manière dont les données réagissent
à une action et interagissent entre elles. On le voit, les
deux approches ne sont que deux points de vue différents
sur un même modèle, mais sont néanmoins complémentaires
car elles aboutissent à des représentations très
dissemblables. Ces deux approches sont statiques, dans le
sens où elles ne décrivent pas le système
en fonctionnement (c'est-à-dire tenant compte de la séquence
des activités) mais seulement ses possibilités de
fonctionnement. UML propose encore deux autres types de vues statiques:
les diagrammes de composants et les diagrammes de déploiement,
sur lesquels nous reviendrons.
|