Thierry Cros
Diagrammez vos modèles UML !
| Accueil | Extreme Programming | UML, Objet | Formation | Consulting | Liens | Contact |

 

Le Unified Modeling Language (UML) est, son nom l'indique clairement, un langage de modélisation. Il définit des concepts (objet, classe, message...) et des formalismes de représentation de ces concepts (un rectangle comportant un label souligné pour un objet, une flèche pour un message...). Ces formalismes — qui représentent des éléments de modélisation — sont groupés dans des diagrammes. Éléments de modélisation et diagrammes sont eux-mêmes organisés en paquetages.

Si la modélisation elle-même est une activité technique, son résultat apparaît sous forme de diagramme et cet article porte sur la qualité de cette mise en diagramme ou "diagrammisation" du modèle. Comment bien "diagrammer" ? Comment organiser les diagrammes dans les modèles, quels diagrammes prendre la peine de créer, modifier, via le modeleur UML ? Cet article présente quelques éléments de réflexion. Il est complémentaire de la profession de foi d'un diagramme UML.

Quelques définitions

Avant tout, il est nécessaire de bien comprendre ce que manipule l'UML. Concepts, éléments de modélisation, formalismes sont à la fois distincts et reliés. Vous pouvez passer ce chapitre si vous êtes familier de l'UML.
Modèle
Un modèle est une représentation d'un système selon un certain point de vue. Le système est existant ou à créer. Il est physique. Le point de vue peut être : expression de besoins, conception, etc. Il s'agit toujours du même système, un peu comme des plans d'un même bâtiment mettent en exergue l'électricité ou le gros oeuvre.
Concept
Objet, Message, Classe, Héritage... sont des concepts ; ce sont des filtres que l'on applique à une certaine réalité (actuelle ou à venir) pour la représenter en la simplifiant. Notons que le filtre impose graduellement sa "façon de voir", de même qu'un filtre coloré en photographie. Ainsi, un développeur, peu à peu, acquiert la pensée objet : il voit alors son programme sous forme d'objets qui collaborent.
Élément de modélisation
C'est le résultat du filtrage par les concepts, appliqué à votre modèle. Le concept d'objet, appliqué à un aéroport par exemple, fait apparaître des objets "avion" : l'avion immatriculé Echo Tango Alpha Whisky par exemple. Les objets échangent des messages et sont regroupés dans des classes. C'est la base même de la vision objet.
Formalisme
UML propose un formalisme graphique simple. Les rectangles, flèches, ellipses peuvent être dessinés sur le coin d'une table, un tableau, voire par un programme basique.
Diagramme
Si le modèle est l'unité de base dans UML, le diagramme est le moyen de communiquer le résultat de la modélisation. UML propose une dizaine (9 pour la version 1, 13 pour la version 2) de diagrammes sensés répondre aux besoins de visualisation des parties prenantes du projet. Notons que ces diagrammes sont parfois insuffisants et - surtout - limitent l'efficacité du langage. Ainsi, il est tout à fait possible en UML de modéliser la traçabilité entre éléments grâce à la relation de dépendance <<trace>> ; cela impose une mise en oeuvre relativement inhabituelle des diagrammes.
Paquetage
Un paquetage est aux éléments de modélisation ce qu'est un répertoire aux fichiers. C'est le moyen d'organiser les éléments dans le modèle de telle façon qu'il soit gérable et agréable à parcourir. Ainsi, la fenêtre "navigateur" de votre modeleur est certainement la plus importante et elle mérite toute votre attention.
Modeleur
Une mise en oeuvre possible de l'UML. Citons aussi :
  • crayon/gomme
  • tableau blanc, noir ou vert
  • paper board
  • nappe (papier)
  • post-it
  • ...

Refactoring de modèle

UML pour penser —  l'expression de besoins par les interactions ou bien une conception par les objets entr'autres — est bien plus efficace dans une mise en oeuvre collective, au tableau. Si les éléments de modélisation sont d'ores et déjà présents dans le modèle, l'amélioration de sa "diagrammisation" correspond d'une certaine manière à un refactoring.

^ ^  haut  ^ ^

Différents types de diagrammes

Détaillons ici les diagrammes proposés succinctement dans la profession de foi d'un diagramme UML.

Inter et Intra-paquetage

Supposons le modèle relativement abouti. Il est probablement organisé en paquetages, au moins un niveau. L'empaquetage dépend du modèle, de la culture des parties prenantes, etc. Il devrait toutefois préserver la facilité de maintenance : ce qui change ensemble est empaqueté ensemble. Alors, il est important de décrire le contenu de chaque paquetage mais aussi les relations entre éléments de paquetages différents. Prenons le cas d'un modèle d'expression de besoins par les cas d'utilisation. Ce modèle est organisé d'après un critère général d'empaquetage des acteurs et cas d'utilisation (les éléments de modélisation les plus importants dans ce modèle). Un critère pourrait être la priorité ou bien l'acteur déclenchant, ou encore une fonctionnalité de haut niveau du système. L'un des paquetages est destiné à recevoir les cas d'utilisation "crabe" et destination de relations de dépendance <<include>> par exemple (cas classique des interactions de Connexion/Déconnexion). Dans un tel modèle, nous trouverons les diagrammes "intra" ie intra-paquetages (à différents niveaux, voir le paragraphe suivant) et des diagrammes "inter" (inter-paquetages de cas d'utilisation) qui décrivent les relations <<include>> citées au-dessus, donc entre cas de différents paquetages.

Général et détaillé

Un modèle comporte des éléments de modélisation qui se situent à différents niveaux. Une classe et ses relations (association...) forment le niveau général ; les attributs, opérations, responsabilités forment le niveau détaillé.

Statique-Permanent et Dynamique

Une modélisation objet repose sur ces deux piliers. Le modèle sera d'autant plus pertinent qu'il sera visualisé par ces deux types fondamentaux de diagrammes, par exemple des diagrammes de collaboration et des diagrammes de classes. Nous sommes ici à la frontière entre la modélisation elle-même et sa diagrammisation.

^ ^  haut  ^ ^

Le modeleur : une problématique

Le modeleur est un outil incontournable dans la mesure où les résultats de la modélisation doivent être communiqués par électronique. Si cet outil automatise la production de diagrammes, tout en vérifiant des règles "métier" ie les règles sémantiques et syntaxiques de l'UML, il doit faire face à des scénarios d'utilisation générateurs d'ambiguïté. Précisons cet aspect des choses. Pour fixer les idées, quelques questions :
  • quid du copier/coller, dans un diagramme, dans le navigateur
  • que signifie supprimer un rectangle dans un diagramme de classes ?
  • faut-il stocker tous les éléments de modélisation dans le navigateur ?
  • ...
Vous remarquerez des différences sensibles de comportement entre les outils du marché. Dans un souci légitime de convivialité, certains outils deviennent non ergonomiques. Celui-ci permet de créer un élément de modélisation directement depuis un diagramme par glisser/déplacer de l'icône adéquate et supprime alors l'élément de modélisation parce que son formalisme est supprimé dans un diagramme. Celui-là gère des vues mais ne connaît pas la notion de modèle.

Il est donc très important de "tester" l'outil avant son utilisation en production de diagrammes. En particulier, reprendre les questions soulevées au-dessus pour mieux comprendre son fonctionnement.

Un autre aspect directement lié à l'outillage est la relation qu'il établit entre diagrammes, paquetages et éléments de modélisation. Comment sont-ils liés ? Comment retrouver un diagramme ? Son titre apparaît-il automatiquement lors d'une impression ? Est-il facile de naviguer entre diagrammes qui visualisent un même élément ? Autant de caractéristiques qui facilitent ou non la diagrammisation du modèle.

^ ^  haut  ^ ^

Bien diagrammer un modèle

Quelques principes

La mise en diagramme s'attache à faciliter la lecture du modèle, à différents niveaux. Pour cela, établissons quelques principes.
  1. Plusieurs diagrammes légers plutôt qu'un seul trop lourd
  2. Toujours préciser l'organisation du modèle avant son contenu
  3. Un diagramme traite un et un seul objectif
Les différents types de diagrammes proposés (inter-intra...) sont autant de pistes qui vous permettent de varier les visualisations du modèle. En particulier, commencer la présentation d'un paquetage par un diagramme général avant d'offrir les détails des éléments de modélisation est un bon moyen de conserver l'attention et la bienveillance du lecteur, face au "gros" diagramme type MCD, devenu parfaitement illisible après son "resize" du à l'imprimante ou au traitement de texte.

L'organisation du modèle repose sur des paquetages. Si UML v2 crée le diagramme de paquetages, celui-ci est tout simplement une modulation du diagramme structurel statique de la v1, à tort systématiquement réduit au "diagramme de classes". Notez que les relations entre paquetages sont essentiellement : la dépendance (typiquement <<import>> ou bien l'inclusion. Ainsi, un diagramme de paquetages en tout début offre une vue "top-down" souvent bienvenue.

Les recommandations proposées dans la profession de foi d'un diagramme UML s'appliquent naturellement à la diagrammisation. Notons que, comme pour tout principe, certaines exceptions surviennent parfois. Citons une équipe, qui souhaite absolument afficher l'ensemble des classes persistantes du modèle de conception.

Point trop n'en faut

Si un modèle précis et détaillé peut être une demande légitime en début de développement, la maintenance de cet artefact reste une question centrale. Plusieurs solutions ont été mises en oeuvre. De l'obsolescence programmée du modèle à la volonté de représenter uniquement les éléments les plus stables car de plus haut niveau, les équipes s'adaptent à cette situation. Une astuce consiste à reprendre la date dans le diagramme, ou bien à tracer les diagrammes depuis les spécifications par exemple. Un point à retenir est que tout développeur fera plus confiance au code officiel qu'au modèle UML. Cela revient à se poser la question de la modélisation et de sa documentation, pour qui, pourquoi.

Un exemple

Supposons un modèle de conception ou d'analyse, architecturé en trois paquetages . Supposons encore que chaque paquetage contient une quinzaine d'éléments de modélisation principaux (ici des classes). Par ailleurs, la conception s'inscrit dans un pilotage par les scénarios et les développeurs ont modélisés quelques collaborations dans deux paquetages (un par cas d'utilisation) d'une dizaine de collaboration.

Les aspects statique et dynamique sont traités dans les paquetages : collaboration pour la dynamique, classes pour le statique. Combien de diagrammes pour visualiser correctement ce modèle ? Une possibilité est :

  1. Un diagramme de paquetages qui présente les deux paquetages (un par cas) de collaboration et les trois paquetages (par exemple IHM, Reporting, Métier) qui présentent les classes de conception ; ce diagramme montre aussi les dépendances générales, les couplages, entre paquetages
  2. 2x10 diagrammes de collaboration (10 par paquetage)
  3. 3 diagrammes principaux de classes (classes et relations), un par paquetage de classes
  4. 2x3 diagrammes de détails (attributs, responsabilités...), soit 7 à 8 classes décrites en détail dans chaque diagramme, à partir d'un critère logique (par exemple dans le paquetage Reporting, les listes d'une part, les fiches d'autre part) de mise en diagramme
  5. 5 (par exemple) diagrammes inter-paquetage qui reprennent les scénarios typiques et donc montrent les classes qui participent à ces scénarios et en particulier les couplages précis entre paquetages.
Soit approximativement une trentaine de diagrammes qui offrent des vues générales ou détaillées du modèle en fonction du souhait du lecteur. Ces diagrammes, correctement stockés dans le modèle (en fonction de l'empaquetage) et surtout correctement nommés, sont alors une documentation efficace du travail de conception.

En conclusion...

Et vous, comment diagrammez-vous vos modèles UML ? Est-ce l'outil qui décide pour vous ? Quel feedback de la part de vos lecteurs ? Quel est le look général de vos diagrammes ? Agréables à l'oeil ? Envie de les étudier ?
Cet article se veut catalyseur de votre réflexion, le crayon est entre vos mains !

^ ^  haut  ^ ^

Révisions
12.02.05 Ajout paragraphe "refactoring de modèle"
22.01.05 Création

^ ^  haut  ^ ^        Retour page d'accueil        © Thierry Cros, 2005 - Contact