' & $ %
3.3.1 Scénarios d’un cas d’utilisation *
La description d’un cas d’utilisation se fait par des scénarios qui définissent la suite logique des actions qui constituent ce cas
Il est possible de définir des scénarios simples ou des scénarios plus détaillés faisant intervenir les variantes, les cas d’erreurs, etc.
La description du scénario précise ce que fait l’acteur et ce que fait le système En plus de descriptions textuelles, le scénario peut être représenté en utilisant un
diagramme d’activité
Le diagramme d’activité permet de :
Présenter « l’algorithme », c’est-à-dire les étapes de la fonctionnalité Visualiser l’aspect temporel des interactions
Connaître le sens des interactions (acteur vers système ou inverse) Distinguer le cas nominal des variantes (p.ex. avec traitement des erreurs)
La description d’un scénario peut se faire de manière simple, par un texte compréhensible par les personnes du domaine de l’application. Elle peut aussi être détaillée pour préciser les contraintes de l’acteur et celles du système, les différentes étapes ou actions avec leurs enchaînements et leurs concurrences. Cette description détaillée est dans la suite modélisée dans des diagrammes d’activité.
Les diagrammes d’activité sont avec les diagrammes de cas d’utilisation les diagrammes les plus facilement compréhensibles des non-spécialistes du développement d’applications informatiques. En effet, l’aspect des diagrammes d’activité ressemble beaucoup à celui des ordinogrammes ; ils sont donc accessibles à une audience très large.
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité * # 29 ' & $ %
3.3.2 Actions et choix *
Les diagrammes d’activité visualisent les étapes des cas d’utilisation et plus particulièrement les enchaî- nements et les branchements. Une activité débute par un nœud initial représenté par un disque noir. Cette action marque le début de l’activité et est suivi d’arêtes représentant le passage à l’action suivante. À l’autre extrémité du diagramme, le nœud terminal ou final signifiant la fin de l’activité est représenté par un disque noir entouré d’un second disque. Entre les deux extrémités, les actions importantes du scénario sont reliées entre elles de façon à montrer le flot de l’activité : les enchaînements ou séquences et la concurrence (parallé- lisme). Le premier type de losange est appelée une décision et simule le début d’une instruction « si-alors ». Les conditions sont appelées des gardes. Le second type de losange signifie la fusion des branches à la fin du « si-alors ». Bien sûr, une attention particulière doit être apportée aux conditions pour qu’elles soient mutuellement exclusives et complètes. Le standard UML indique que si plusieurs gardes sont valides alors une seule branche est parcourue et le choix de la branche est aléatoire. Ce comportement ne correspond que très rarement au souhait de l’auteur du diagramme. En outre, les conditions doivent être complètes pour éviter que l’activité ne soit bloquée ou gelée indéfiniment parce qu’aucune des conditions n’est valide. Par analogie avec les instructions « switch » des langages de programmation, il est ainsi judicieux de penser à ajouter une garde « sinon » représentant le chemin par défaut à emprunter si aucune des autres gardes n’est vraie.
Cf. le glossaire pour la définition du terme « action ».
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité * # 30 ' & $ %
3.3.3 Concurrence *
Les actions qui se déroulent en même temps sont dites concurrentes. Elles sont modélisées entre deux traits épais comme des chemins parallèles, le premier de ces traits étant appelé « fork » et le second « join ». Les séquences d’actions en parallèle débutent en même temps, sont toutes exécutées, mais par définition ne finissent pas au même instant. La fin de l’action join intervient lorsque toutes les actions en parallèle se terminent ; join est donc un point de synchronisation.
3 Analyse, vues cas d’utilisation et processus 3.3 Diagrammes d’activité * # 31 ' & $ %
3.3.4 Autres notations du diagramme d’activité *
Le diagramme d’activité possède d’autres notations que nous citons pour information mais n’illustrons pas. Le diagramme d’activité permet d’exprimer le passage du temps avec le symbole du sablier. Il est ainsi possible de modéliser une activité qui s’exécute périodiquement en remplaçant l’action initiale par un sablier. Il est aussi possible, à partir d’une activité, d’appeler une autre activité et d’indiquer entre deux actions les informations transmises (montrant ainsi les flux d’informations en plus des flots d’actions).
Les interactions entre le système et les acteurs sont modélisées sous la forme de signaux émis et reçus. Enfin, le langage UML fournit d’autres notations que nous ne montrons pas : la fin d’un chemin, le partitionnement, les connecteurs, les expansion regions. Pour plus d’information, nous invitons les curieux à se référer à la bibliographie ou directement au standard.
Introduction au langage de modélisation UML 3 Analyse, vues cas d’utilisation et processus # 32 ' & $ %
QCM
1. Dans un diagramme de cas d’utilisation, est-il pertinent d’ajouter des cas d’utilisation ne faisant pas partie du système ?
2. Quelles entités peuvent être dessinées dans un diagramme de cas d’utilisation ? (a) système
(b) action (c) acteur
(d) généralisation spécialisation
3. Dans une généralisation spécialisation entre acteurs, l’acteur spécialisé a-t-il accès à toutes les fonctionnalités de l’acteur généralisé ?
Introduction au langage de modélisation UML # 33 ' & $ %
4 Analyse et conception, aspects statiques de la vue logique
4.1 Diagrammes communs à l’analyse et à la conception . . . 34