Modélisation UML d’applications logicielles

Pourquoi modéliser une application ?

Prenons l’analogie de la construction d’une maison. Aucun bâtiment d’habitation ne sortira de terre sans en avoir réalisé scrupuleusement plusieurs plans. Chaque plan est dédié à un corps de métier. Par exemple l’électricien pourra calculer au plus juste, commander et facturer la longueur de câble nécessaire à son fournisseur. La cohérence entre les différents plan est primordiale, ce qui garantit par exemple qu’aucun tuyau d’évacuation ne sorte du sol à l’endroit même du seuil de la porte d’entrée et cela permettra au menuisier de concevra ses portes et fenêtres selon des côtes calculées en cohérence avec les ouvertures réalisées par le gros oeuvre.

En génie logiciel, la vue logique, la vue des cas d’utilisation, la vue de composants, la vue de déploiement sont l’équivalent de ces différentes vues sur le système. Ces différentes vues doivent de la même façon être maintenues cohérentes entre elles. Le langage graphique UML est devenu le standard de facto pour représenter ces différentes vues.

UML – Unified Modeling Language

Voici une première définition :
UML est un langage standardisé pour la spécification, la visualisation, la construction et la documentation de tous les éléments d’un système logiciel.
Une notation créée en 1995 par les 3 amigos *.

Analyse orientée objet

L’objectif de cette section est de comprendre le rôle de chaque diagramme UML dans une démarche d’analyse orientée objet.

1. Analyser/comprendre le métier : le diagramme d’activités

Le diagramme d’activité représente un flux de contrôle permettant de réaliser une fonctionnalité du système. Il consiste en un enchaînement d’activités. Ce diagramme se veut simple à lire et à réaliser. La transition d’une activité à l’autre est automatique, dès que l’activité est terminée. Le point de départ (rond noir) indique le départ du flux d’activités. Et il peut éventuellement y avoir plusieurs points finaux (rond noir cerclé). Des barres de synchronisation permettent de paralléliser des flux d’activité. Enfin, les swimlanes (lignes de nage ?) distribuent les responsabilités des activités aux différents acteurs du système étudié. Une activité est un “états-actions”, ainsi elle peut être décomposée à son tour en actions successives.

Ce diagramme permet de modéliser les processus métier et remplace ainsi les diagrammes de flux ou de traitement de la méthode Merise. En schématisant les processus métier, ou des algorithmes complexes, ce diagramme en améliore la compréhension d’un métier et oblige à traiter toutes les alternatives qu’il est possible de prendre lors de prises de décisions.

2. Exprimer les besoins : le diagramme de cas d’utilisation

Le diagramme de cas d’utilisation est un schéma qui donne un aperçu du système, son environnement (les acteurs) et les fonctionnalités à implémenter à gros grains (les cas d’utilisation). Il permet de catégoriser les différents utilisateurs du système et de définir les fonctionnalités offertes à chacun de ces acteurs.

Pour définir le périmètre fonctionnel de l’application, l’analyste doit se poser les questions suivantes : Qui/quoi interagit avec le système ? Qu’est-ce qu’il veut faire en utilisant le système ? La notion d’acteur permet de représenter le contexte du système. Un acteur est quelque chose ou quelqu’un extérieur au système et qui interagit avec le système. Le cas d’utilisation représente une fonctionnalité du système qui apportent une valeur ajoutée à un acteur. Le cas d’utilisation se décline alors en une séquence de transactions entre un acteur et le système comme nous le verrons dans la suite.

Documentation des cas d’utilisation

L’acteur interagit donc avec le système dans le cadre d’un cas d’utilisation. Le cas d’utilisation est une fonctionnalité à gros grain, un objectif qu’a l’acteur lorsqu’il utilise le système. Chaque cas d’utilisation est décrit dans un document textuel, contenant des scénarios d’utilisation. Le scénario contient les étapes successives permettant à l’acteur d’atteindre ou non l’objectif défini par le cas d’utilisation. Divers formats de document existe, mais l’important est de bien donner le point de départ du cas d’utilisation, divers scénarios menant à la/les fins du cas d’utilisation. Il existe au moins un scénario normal (le cas où tout va bien) et des scénarios alternatifs décrivant des situations plus “embêtantes”.

Remarque : dans un scénario, il ne faut pas chercher ici à documenter de manière exhaustive l’ensemble des cas possibles : Et si … ? et si …? L’objectif de cette activité de documentation des cas d’utilisation est de relever les situations critiques et d’obtenir un accord du client sur les palliatifs à ces situations.

La réalisation de cas d’utilisation

L’activité de réalisation de cas d’utilisation consiste à concevoir le système qui répond au mieux aux besoins de ses futurs utilisateurs décrits dans les cas d’utilisation. C’est le “comment” du cas d’utilisation. Deux diagrammes peuvent être utile à ce niveau : le diagramme de séquences qui peut représenter graphiquement les scénarios ; le diagramme de classes qui est le plus connu des diagrammes UML. Il décrit les classes participantes au cas d’utilisation et leurs relations.

3. Modéliser les scénarios d’utilisation : le diagramme de séquences

Le diagramme de séquences représente des objets qui s’échangent des messages. Ils collaborent dans le but de réaliser un scénario d’utilisation. Un objet est représenté par une ligne de vie. Chacune de ces lignes de vie représente le cycle de vie d’un objet recevant et envoyant des messages ordonnés séquentiellement (de haut en bas). Les objets sont ajoutés au diagramme au fur et à mesure de l’analyse. L’objectif est de distribuer une fonctionnalité sur plusieurs objets. Au fur et à mesure de la réalisation d’un scénario, les objets se construisent et il peut être nécessaire d’en ajouter de nouveaux. Une fois catégorisés, ces objets sont définis (nom, attributs et méthodes) par des classes. Certains objets sont davantage spécialisés dans les interactions homme-machine, ou dans le stockage d’information. Nous y reviendrons dans un autre article sur les stéréotypes d’analyse.

Le diagramme de séquences permet ainsi de définir plus précisément les besoins, et raffiner les cas d’utilisation. Il aide à découvrir de nouveaux objets et nouvelles méthodes qui seront, du coup, répertoriés dans le diagramme de classe au fur et à mesure que l’on réalise des cas d’utilisation. Pour chaque cas d’utilisation, on conçoit un diagramme de séquence qui montre les objets du système impliqués dans le cas d’utilisation.

4. Décrire l’architecture logicielle : le diagramme de classes

Le diagramme de classes répertorie l’ensemble des classes des objets impliqués dans les diagrammes de séquences ou issus du domaine métier. On y trouve les classes, leur structure (attributs) et leur comportement (méthodes) ; les associations, agrégration, composition, dépendance, héritage, … ; les multiplicités et indications de navigation ; les noms de rôles sur les associations.

Comme nous l’avons vu en introduction de cet article, les diagrammes du système doivent être maintenus en cohérence. Les classes présentes dans ce diagramme doivent être utilisées dans les diagrammes de séquences. Si dans le diagramme de séquence un objet reçoit un message (une flèche pointe sur sa ligne de vie), sa classe doit comporter la méthode décrivant le comportement qu’il doit mettre en oeuvre à la réception de ce message. Dans l’exemple, le diagramme de séquences met en jeu des objets des classes Cours et FicheEtudiant. Ces deux classes sont bien présentes dans le diagramme de classes. Les attributs sont les informations nécessaires au traitement d’une méthode.

Réalisation des cas d’utilisation

La réalisation de chaque cas d’utilisation permet de concevoir le diagramme de classes :

  1. Trouver les associations entre classes nécessaires à chaque réalisation de cas d’utilisation
  2. Élaborer un diagramme de séquence pour chaque cas d’utilisation. Il contient les instances des acteurs, des objets de l’analyse métier, et relations. Il montre la séquence d’événements entre objets pour chaque cheminement dans un cas d’utilisation
  3. Compléter les classes et saisir les nouvelles classes dans le diagramme de classes d’analyse

À ce stade, il n’est qu’une ébauche. Il est ensuite affiné et enrichi afin de fournir une documentation exhaustive aux développeurs, voire de permettre une génération d’une partie du code source de l’application.

5. Modéliser les différents états d’un objet ou d’un système : le diagramme d’états-transitions

L’utilisation d’un diagramme d’état pour modéliser les changements d’état d’un objet est utile lorsque cet objet a un comportement complexe. On reconnait ce type d’objet s’il intervient dans de nombreux diagrammes de séquence, ou un objet qui reçoit ou envoye beaucoup de messages.

Le diagramme d’état peut décrire le cycle de vie d’un objet. Des événements déclenchent des transitions qui font passer l’objet d’un état à l’autre et les actions qui résultent de ce changement d’état.

6. Modéliser l’architecture physique : Les diagrammes de composants et de déploiement

Le diagramme de composants représente l’organisation et les dépendances entre les interfaces des composants logiciels (composants exécutables, librairies, services, …). Chaque composant propose une ou plusieurs interfaces à d’autres parties du système.

Le diagramme de déploiement montre les unités physiques du système. Il permet de représenter la distribution des composants sur les unités de calcul.

(Cette section est inspiré de l’article “Introduction to the Unified Modeling Language” de 2003 parTerry Quatrani de Rational Software.)

Sources et liens utiles

Les Three Amigos Fin des années 80, les systèmes informatiques se complexifient et on ne peut plus se passer ni de méthodes, ni de modèles pour concevoir ou faire évoluer les solutions logicielles. Dès lors, chacun y va de ses bonnes pratiques et utilise sa propre notation. Les échanges entre éditeurs, prestataires et même clients sont complexes, nécessitant la traduction des modèles d’une notation dans une autre.
Sous l’impulsion de société de conseil telle Rational ou de gros éditeurs logiciels, des consortiums réfléchissent à une méthode commune, voire une même notation utilisée par tous. De nombreuses discussions tournent autour de questions du type : qu’est-ce que représente ce rectangle ? et ce nuage ? … Trois initiateurs de cette réflexion se démarquent alors, ils seront appelés “the three amigos”. Jim Rumbaugh propose la méthodologie OMT. Cette méthodologie est orientée analyse des besoins, et ne couvre pas complément la conception d’application. Celle de Grady Booch est plus poussée en conception, c’est à dire, la production de modèles tenant compte de problématique technologique. Enfin l’expérience utilisateur est la priorité de la méthodologie Objectory de Ivar Jacobson déclinant une démarche basée sur les cas d’utilisation.
En 1995, dans une conférence réunissant les plus grands spécialistes du monde de l’orienté-objet, OOPSLA’95, Booch et Rumbaugh proposent une méthode unifiée qui est à la fois une méthode et une notation. Après la contribution de Jacobson, seule la notation semble mutualisable, laissant la méthode libre à chacun. Unified Modeling Language (UML) est proposé au consortium Object Management Group (OMG), chargé de standardiser tout ce qui tourne autour de l’orienté objet. Aujourd’hui encore, la notation UML évolue, se complexifie, chacun pouvant y contribuer. Les spécifications du langage sont disponibles sur le site de l’OMG.