Après plus de 10 ans d’existence, où en est UML ? D’un côté, les tenants des méthodes agiles en vogue actuellement, telles que XP (eXtreme Programming) et Scrum, ne parlent quasiment pas de modélisation, ou semblent même s’en méfier. De l’autre, certaines entreprises ont engagé d’énormes investissements sur une approche dirigée par les modèles (Model-Driven Engineering) et prétendent générer presque 100 % de leur code applicatif automatiquement. Qu’en est-il vraiment ? Ces deux approches d’utilisation d’UML sont-elles vraiment inconciliables ?

À quoi bon modéliser ?

Le recours à la modélisation est depuis longtemps une bonne pratique du développement logiciel. Un modèle constitue en effet une représentation abstraite d’un système destiné à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre les différents intervenants au sein d’un projet. Le fait de tracer ou de lire des diagrammes implique de travailler plus visuellement et d’exploiter le pouvoir que possède notre cerveau de saisir rapidement des symboles et des relations exprimées (majoritairement sous la forme de cases et de lignes) dans un espace bidimensionnel. Chaque membre de l’équipe, des utilisateurs jusqu’aux développeurs, utilise et enrichit le modèle différemment. En outre, les systèmes devenant de plus en plus complexes, leur compréhension et leur maîtrise globale dépassent les capacités d’un seul individu. La construction d’un modèle apporte donc une réponse efficace.

Le modèle sert des objectifs différents suivant l’activité de développement, et sera construit progressivement avec des points de vue de plus en plus détaillés. En spécification des exigences, il convient de considérer le système comme un tout (une boîte noire) afin d’étudier sa place dans le système métier plus global qu’est l’entreprise. On développe pour cela un modèle de niveau contexte, afin de tracer précisément les frontières fonctionnelles du futur système. Lors de la phase d’analyse, le modèle commence à représenter le système vu de l’intérieur, mais sans référence à une solution technologique. Il se compose d’objets représentant une abstraction des concepts manipulés par les utilisateurs. Le modèle comprend par ailleurs deux points de vue, la structure statique et le comportement dynamique, qui aident à compléter la compréhension du système à développer. En phase de conception, le modèle décrit la solution informatique qui sera utilisée, en intégrant les choix des langages, des outils, et des plates-formes de développement. Un modèle suffisamment détaillé peut ici servir à générer automatiquement du code dans un langage de programmation objet, avec un outil approprié. Pour le déploiement enfin, le modèle permet de représenter les matériels et les logiciels à interconnecter.

UML : l’objet de tous les projets…

Le modèle en tant qu’abstraction d’un système s’accorde parfaitement avec les concepts orientés objet. Un objet peut en effet représenter l’abstraction d’une entité métier utilisée en analyse, puis d’un composant de solution logicielle en conception. La correspondance est encore plus flagrante lorsque les langages de développement sont eux-mêmes orientés objet. D’où le succès de la modélisation objet ces dernières années pour les projets de plus en plus nombreux utilisant C++, Java, C#, Python, etc.

Aujourd’hui, le standard industriel de modélisation objet est UML (Unified Modeling Language). Il est sous l’entière responsabilité de l’OMG (Object Management Group), un groupement d’industriels dont l’objectif est de standardiser autour des technologies objet, afin de garantir l’interopérabilité des développements. L’OMG comprend actuellement plus de 800 membres, dont les principaux acteurs de l’industrie informatique, mais aussi les plus grandes entreprises utilisatrices dans tous les secteurs d’activité (www.omg.org).

UML se définit comme un langage de modélisation graphique et textuelle destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une simple notation graphique, car les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un langage. UML 2 (officiellement adopté depuis mars 2005 par l’OMG) s’articule autour de 13 diagrammes différents, répartis en deux grands groupes :

• Six diagrammes structurels :

• - Diagramme de classes (montre les briques de base statiques : classes, associations, interfaces, attributs, opérations, généralisations, etc.)
  - Diagramme d’objets (montre les instances et leurs liens statiques)
  - Diagramme de packages (montre l’organisation logique du modèle)
  - Diagramme de structure composite (montre l’organisation interne d’un élément statique complexe)
  - Diagramme de composants (montre des structures complexes, avec leurs interfaces fournies et requises)
  - Diagramme de déploiement (montre le déploiement physique des « artefacts » sur les ressources matérielles)

• Sept diagrammes comportementaux :

• - Diagramme de cas d’utilisation (montre les interactions fonctionnelles entre les acteurs et le système à l’étude)
  - Diagramme d’activité (montre l’enchainement des actions et décisions au sein d’une activité)
  - Diagramme d’états (montre les différents états et transitions possibles des objets d’une classe)
  - Diagramme de séquence (montre la séquence verticale des messages passés entre objets au sein d’une interaction)
  - Diagramme de communication (montre la communication entre objets dans le plan au sein d’une interaction)
  - Diagramme de vue d’ensemble des interactions (fusionne les diagrammes d’activité et de séquence)
  - Diagramme de temps (fusionne les diagrammes d’états et de séquence)