FAQ UMLConsultez toutes les FAQ

Le diagramme de cas d'utilisation est souvent utilisé pour l'analyse de besoin. Il permet de modéliser les acteurs et les services attendus (ce que doit faire le système). Sa simplicité graphique est appréciée car il permet un dialogue facile avec les intervenants "métier" habituellement non formés aux techniques de modélisation.

La démarche de création des diagrammes est dépendante du process suivi (*UP, XP, ...). À vous d'identifier quel process convient le mieux à votre problématique de développement et ainsi l'ordre de réalisation des diagrammes. Notez cependant qu'on ne peut pas parler d'ordre au sens strict du terme. En effet, un modèle UML est très souvent réalisé de manière itérative.

Pour exemple, dans un process de développement en Y, les étapes suivantes (étapes qui sont sans doute adaptées suivant les projets, les entreprises...) peuvent être identifiées :

- Phase d'étude préliminaire (capture du besoin) :
Certains choisissent de réaliser cette étape au moyen d'un diagramme de collaboration haut niveau permettant de modéliser le contexte (système/acteurs et messages haut niveau). On place le système comme un objet central et les différents acteurs qui interagissent avec le système. On rajoute ensuite des liens représentant les messages entre le système et les acteurs (sans numéros).Les messages sont alors décrits textuellement.

- Phase d'étude fonctionnelle :
Identifier les cas d'utilisation qui représentent les services rendus à "l'utilisateur" du système. On indique sur ce diagramme ce que le futur système devra faire mais pas comment il le fera. Donc, inutile de préciser ce qui est de l'ordre de l'IHM ou de la gestion des erreurs sur ce diagramme. L'objectif est d'obtenir la couverture des exigences fonctionnelles : un cas d'utilisation = une fonction métier du futur système.
Attention ! un cas d'utilisation ne correspond pas à une fonction (au sens programmation) du système. Gardez en tête la notion de service.
Attention également à ne pas avoir un trop grand nombre de cas d'utilisation car c'est un signe d'enlisement : vous vous perdez dans les détails. De plus, il ne faut pas tomber dans le travers de vouloir réaliser une décomposition hiérarchique des cas d'utilisation. Certains préconisent donc de respecter une limite de 20 cas d'utilisation.
On conseille également de réaliser des fiches pour chaque cas d'utilisation afin d'indiquer un description textuelle, les préconditions et post-conditions. D'autres utilisent les diagrammes d'activité pour cela ou même des diagrammes d'états.
L'étape suivant concerne la description de la dynamique et des scenarii au moyen des diagrammes de séquence : ici, ce sont des diagrammes de haut niveau qui ne font intervenir que le système et les acteurs.

- Phase d'étude physique :
Il s'agit de prendre en compte les contraintes techniques (exple : les composants hardware imposés, les outils de développement, ...). On utilise alors les diagrammes de composants et de déploiement pour exprimer les contraintes matérielles (du type, tel serveur NT, tel serveur Unix, une passerelle, un cluster, ...).
C'est également à ce moment que l'on peut décider de l'architecture en couches du modèle : on exprime cela au moyen des packages qui vont par exemple ségréger les partie IHM, Traitement, Données.

- Affinage du modèle :
Affiner le modèle commence par l'affinage les diagrammes de séquence afin d'identifier les différents objets/classes nécessaires à la réalisation des services attendus du système.
Ces différentes classes seront sans doute réparties dans des packages plus "métier" afin d'obtenir une structuration de notre modèle.
Ensuite dans ces packages, on pourra développer des diagrammes de classes. Il s'agira alors d'affiner les classes, les associations entre-elles, de déterminer attributs et opérations pour chacune et éventuellement d'optimiser le modèle au moyen des concepts de généralisation/spécialisation.
Selon les cas, certains choisissent de commencer par le diagramme de classes et de réaliser ensuite les diagrammes de séquence. On peut dire je pense que les deux sont de toute manière fortement liés et que leur réalisation est itérative.
Après ces deux étapes, lorsque les scenarii sont stabilisés, on peut entamer la description des diagrammes d'états. Seules les classes actives, au comportement riche, méritent de bénéficier d'un diagramme d'états. Les diagrammes d'états permettent de représenter la vie d'un objet et les différentes situations/états possibles de cet objet. Attention, il faut que ces diagrammes restent cohérents avec les diagrammes de séquence ! Utiliser un outil qui propose la vérification de cohérence entre les diagrammes est alors un véritable gain de temps et une assurance incontestable d'avoir des diagrammes en cohérence. Egalement, pensez aux éventuelles modifications à réaliser sur les diagrammes statiques lors de la réalisation de vos diagrammes dynamiques (qui vont inévitablement vous amenez à rajouter des attributs ou des opérations à vos classes).

Voilà le début d'une démarche typique pour un process en Y. N'oubliez pas lors de la conception de prendre en compte ou de créer tous les mécanismes vous permettant d'obtenir une architecture génériques (design patterns, frameworks techniques, contraintes de réutilisation, prise en compte de contrainte dues à la génération de code automatique,...).