Que faut-il garder d'UML ? Quelles seraient les évolutions nécessaires ? Va-t-on vers un reboot d'UML ? Quelles alternatives à UML ?

Sur les 14 diagrammes, seuls 4 sont réellement utilisés et encore, souvent d'une manière simplifiée et en ne respectant pas forcément toutes les subtilités de la norme. Que faudrait-il ajouter pour qu'UML tienne compte des avancées de l'IT, comme l'agilité, l'architectures micro-services, les IA génératives ? Quels langages ou notations de modélisation peuvent remplacer avantageusement UML ?

Des dessins suffisent-ils à modéliser une application ? (Illustration réalisée par DALL·E)

Cas d’utilisation, classes, états, séquence, that's all folks

Dans notre article précédent "NoSQL, NoCode et NoUML ? Faut-il encore modéliser avec UML ? Défauts et qualités de cette norme de l’OMG vieillissante", nous avons énoncé avec ChatGPT les faiblesses d'UML.

En étant pragmatique et en tenant compte des retours d'expérience, voici les diagrammes pertinents pour les architectes logiciels et les concepteurs-développeurs d'applications.

4 diagrammes suffisent à couvrir les aspects fonctionnels, structurels et comportementaux d'une application (voir nos articles en annexe dans la catégorie UML).

Diagramme de cas d'utilisation

Exemple de diagramme UML de cas d'utilisation, montrant les domaines métier (package), les rôles (actor) et les activités (use case) qu'ils sont autorisés à déclencher (réalisé avec Visual Paradigm).

Un cas d'utilisation représente un bloc fonctionnel bien identifié, adapté à la "granularité" de la description souhaitée par le concepteur (voir notre article Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?).

La définition du champ d'action d'un cas d'utilisation est un art en soi.

En plus de la règle des "10 ; 10" énoncée dans l'article mentionné précédemment, une autre consiste à se demander si l'utilisateur peut "aller déjeuner" lorsqu'un cas d'utilisation est terminé, ce qui signifie qu'une action d'envergure suffisante a été déclenchée par un acteur.

Par exemple "Ajouter un article dans le panier" n'est pas le plus vaste des objectifs d'un utilisateur, alors que "Acheter un article" est une action consistante pour lui, incluant ajouter, supprimer, rechercher, différer, payer…

Les cas d'utilisation ont été essentiellement conçus comme des outils de communication permettant de décrire des fonctionnalités, si bien que leurs champs d'action peuvent varier en fonction de l'audience visée et de l'objectif de la modélisation.

Par exemple, un diagramme de cas d'utilisation peut être un excellent moyen de préciser les rôles et leurs autorisations dans la future application.

On voit bien ici qu'UML n'est pas une méthode : un diagramme de cas d'utilisation efficient dépendra grandement de l'expérience du modélisateur.

Diagramme de classes

Exemple de diagramme de classes représentant les vols d'une compagnie aérienne,
avec ses propriétés et ses relations (Visual Paradigm).

Un diagramme de classes sert autant à la MOA, pour concevoir une ontologie des entités métier, qu'à la MOE, pour la mise en œuvre des design patterns et des postulats objet. Son principal inconvénient est qu'il est très structurant et nécessite que les informations soient bien définies et hiérarchisées.

Il peut être utilisé pour représenter des schémas de base de données et des schémas XSD pour des messages XML. Cependant, les concepteurs de bases de données et de DSL ont émis des réserves sur l'emploi du diagramme de classes, car trop générique, chacun des deux domaines possédant ses propres outils spécifiques.

Diagramme d'états

Modélisation des états d'un livre dans le contexte d'une bibliothèque
et les évènements susceptibles de faire transiter d'un état à un autre (Visual Paradigm).

Un diagramme de machine à états est indispensable pour représenter les transitions métier pouvant survenir sur une entité métier en modifiant ses propriétés et son comportement.

Il est aussi utilisé pour décrire le comportement d'un système temps réel.

Là encore, le même diagramme très générique peut servir à modéliser l'état d'une commande d'un site de e-commerce ou à une liaison entre la terre et un robot sur Mars.

Diagramme de séquence

Diagramme de séquence modélisant les échanges chronologiques lors d'un retrait à un distributeur de billets. A noter les références à 2 autres diagrammes de séquence (Visual Paradigm).

UML a introduit le diagramme de séquence, qui est un diagramme d'interaction, pour permettre de décrire les modalités de communication entre les objets, et non la manipulation des données impliquées dans une transaction.

Il se focalise sur les messages spécifiques échangés par les objets et sur la façon dont ces messages concourent à la réalisation de fonctionnalités. Il permet de représenter l'aspect dynamique d'un système, et vient en complément du diagramme de classes, qui a trait à l'aspect statique, et qui a pour but de montrer comment l'association de plusieurs objets permet d'assurer une fonctionnalité.

Comme pour les autres diagrammes, il peut aussi bien être utilisé par la MOA, pour représenter des scénarios de cas d'utilisation, usuellement appelés diagrammes système, ou par la MOE et plus particulièrement les concepteurs-développeurs pour leurs algorithmes.

Quelles seraient les évolutions nécessaires d'UML ?

L’amélioration de la qualité du code passe par des éléments comme l'intégration continue CI/CD, les révisions de code, les guides de style, les tests unitaires, les tests d’intégration, les tests fonctionnels et la documentation, plutôt que de nombreux modèles UML non mis à jour.

La dernière version 2.5.1 d'UML date de 2017 : aucune évolution depuis presque 6 ans.

Une hypothétique nouvelle version d’UML 3.0 pourrait :

prendre en compte l’architecture micro-services.
Elle pourrait fournir des outils de modélisation pour aider les développeurs à concevoir des systèmes basés sur des micro-services.
intégrer tous les types d’IA (IA génératives, apprentissage supervisé et renforcé, etc.).
Elle pourrait intégrer ces technologies en fournissant des modèles de modélisation spécifiques pour aider les développeurs à concevoir des systèmes d'IA.
améliorer l'interopérabilité avec d'autres langages de modélisation.
Elle pourrait s'interfacer avec d’autres langages de modélisation, pour représenter différents aspects d'un même système.
simplifier les parties complexes.
Elle pourrait inclure des outils pour simplifier la complexité, telle que des modèles de modélisation plus simples ou des assistants de modélisation.

Vers un UML agile

Les modèles ne sont qu'éphémères, le seul modèle qui fait foi à la fin du projet, c'est le code !

(Craig Larman)

Dans un premier temps, il faut se poser les questions métaphysiques suivantes :

Ce modèle est-il utile ? À qui ?
Pour combien de temps ?
Quelle est sa valeur ajoutée ?

Fini la modélisation UML extensive, vive la modélisation agile. Les modèles facilitent la compréhension et ne doivent pas être considérés comme une documentation obligatoire.

Au début de chaque itération, pendant des sessions de modélisation collaborative, il faut modéliser au tableau ou sur des Post-it, le strict minimum, juste les points essentiels. Un modèle métier lors de la réunion de planification en début de Sprint améliore la discussion sur les « User Stories ».

Les cas d'utilisation UML peuvent référencer plusieurs "User Stories" Scrum. La future version 3.0 d'UML pourrait intégrer les "User Stories" et les relier par une relation de composition à un Cas d'Utilisation. Une annotation pourrait agréger un cas d'utilisation, une exigence et une règle de gestion. Ces 2 derniers concepts seraient eux aussi ajoutés dans le nouveau reboot d'UML. Ceci simplifierait grandement l'analyse d'impacts à chaque changement, principe fondamental de l'agilité.

Les modèles ne sont pas forcément à conserver et à maintenir. Une fois qu'ils ont atteint leur but, on peut en jeter la plupart !

Enrichissez les modèles par de petits incréments et de manière collaborative, n'essayez pas de concevoir une vue globale de l'ensemble du système. Utilisez des notations simples afin que le contenu de vos modèles soit facile à valider, avec les outils les plus simples. Focalisez-vous uniquement sur les aspects que vous devez modéliser et n'essayez pas de créer à tout prix un modèle très détaillé.

Cette nouvelle mouture d'UML devrait présenter 2 niveaux, le premier pour un usage pragmatique offrant 3 ou 4 diagrammes simplifiés parmi les 14 existants et un deuxième niveau dit avancé permettant par exemple une cartographie métier exhaustive en amont.

Les maquettes IHM étant souvent plus importantes que les modèles, des artefacts de modélisation devraient faire partie des demandes d'évolution de la norme.

En attendant un reboot d'UML

La méthode Graal modélise les aspects statiques et dynamiques des exigences et même les IHM qui vont avec.

De plus en plus d'utilisateurs et d'éditeurs n'ont pas attendu pour intégrer les besoins cités précédemment.
Un reboot pourrait venir de la méthode Graal de l'éditeur français Obeo basée sur un UML agile, ultra simplifié et pragmatique, qu'ils qualifient de NoUML. La plupart des évolutions précédentes sont déjà implémentées, comme le diagramme de tâches composant les cas d'utilisation et les modèles d'écrans. Cette méthode est utilisée dans l'outil Information System Designer (ISD) auquel nous consacrerons une série d'articles.

Quelles alternatives à UML ?

Comme nous venons de l’aborder précédemment, UML est un langage de modélisation générique avec lequel on peut tout modéliser, à condition de bien maîtriser ses concepts et ses techniques d'extension.

Devant la difficulté à les utiliser, l’OMG et d’autres organisations ont développé des langages spécialisés dans certains domaines techniques ou métier, souvent basés sur les profils UML et qui pallient aux faiblesses d’UML.

BPMN (Business Process Model and Notation)

Diagramme BPMN réalisé avec GenMyModel, représentant les tâches d'un processus pour créer un contrat d'assurance. Remarquez la rule task "Etudier l'adhésion" pouvant être modélisée avec DMN.

La modélisation des processus métier avec UML avec le diagramme d'activité a toujours été rejetée par les MOA, trouvant UML trop technique et réservé à une élite d'informaticiens.

L’OMG y a remédié en créant BPMN, une notation plus concrète, spécialement conçue pour les experts métier, afin qu'ils puissent représenter leurs processus métier avec la terminologie qu'ils connaissent.

Un des objectifs est de faciliter la communication entre tous les acteurs impliqués dans un projet informatique, tant au niveau cartographie des processus métier qu'au niveau de la modélisation des besoins d'une application (voir nos articles en annexe dans la catégorie BPMN).

DMN (Decision Model and Notation)

Diagramme DMN réalisé avec GenMyModel, représentant la tâche métier vue dans le diagramme BPMN précédent. Elle est constituée par les données en entrée (Application), les décisions (Analyse des risques, Eligibilité et Etudier l'adhésion), auxquelles sont associées les connaissances métier (Valorisation des risques, Matrice de facteurs de risques et Table de décision).

Le but principal de DMN, norme de l'OMG, est de fournir une notation commune, qui est aisément compréhensible par la MOA et la MOE.

Les experts métier créent des règles métier, des tables de décision, intègrent des règlements, des lois, etc., puis affinent ces règles pour les livrer aux développeurs responsables de leur implémentation dans les processus métier et finalement, aux utilisateurs qui les gèrent et les contrôlent.

La notation DMN est conçue pour être utilisable avec la norme de modélisation des processus métier BPMN.

Dans la vraie vie, c'est le pragmatisme qui règne. Lors de mes missions dans le domaine assurantiel, j’ai eu l’occasion d’intégrer dans les systèmes d’information des moteurs de règles métier, comme l'open source Drools (voir nos articles en annexe dans la catégorie Moteur de règles). Les règles ont été formalisées suivant un pseudo-code en français et répertoriées… dans des tableaux Excel.

DMN (voir nos articles en annexe dans la catégorie DMN) est à mettre dans le panier des nombreuses normes qui sont des flops comme CMMN, BMM, etc.

CMMN (Case Management Model and Notation), en voie de disparition,
appartenait au trio BPMN+DMN+CMMN

Diagramme CMMN d'un dossier de suspicion de fraude à la mutuelle
réalisé avec Enterprise Architect de Sparx Systems

BPMN a été adoptée comme norme de modélisation des processus métier, qui sont décrits comme des séquences prédéfinies d'activités avec décisions (passerelles) pour diriger la séquence le long de chemins alternatifs ou pour des itérations. Ces modèles sont efficaces pour des processus métier prédéfinis, entièrement spécifiés et reproductibles (voir nos articles dans la catégorie BPMN). Comme vu précédemment, DMN est liée à BPMN avec les "Rule Tasks".

Qu’en est-il de la modélisation d’activités qui ne sont pas prédéfinies et reproductibles, mais qui dépendent plutôt de l'évolution des circonstances et des décisions ad hoc des experts métier, concernant une situation particulière ?

C’est en partant de ce manque dans les normes de modélisation que l’OMG a créé CMMN.

Les applications sont nombreuses, on peut citer par exemple : les traitements antifraude, la gestion des réclamations dans les assurances, les diagnostics médicaux…

Malgré cela, cette norme n'a pratiquement jamais été utilisée et a été retirée de la plupart des outils de modélisation (voir nos articles en annexe dans la catégorie CMMN).

SysML (Systems Modeling Language) pour l'industrie, mais pas que !

Diagramme d'exigences SysML pour un lecteur audio portable étanche et blindé
(Enterprise Architect de Sparx Systems).

SysML, c'est comme UML, mais en mieux (voir nos articles en annexe dans la catégorie SysML) !

UML ne permet pas directement de modéliser les exigences et d'assurer la traçabilité vers leurs réalisations par les autres éléments de conception. UML ne prévoit rien pour représenter des éléments non logiciels. Et enfin, UML utilise la terminologie orientée objet qui, si elle convient bien aux méthodes et langages de programmation objet, n'est pas celle adoptée par l'ingénierie système.

L’OMG a donc créé sur la base d’UML, SysML qui est un profil UML (package de stéréotypes, tags/values et contraintes OCL). SysML est très utilisé dans de multiples secteurs de l'industrie, comme Airbus ou EDF.

Grâce à mes retours d'expérience chez Airbus, j'ai eu l'occasion d'évangéliser des administrations et des entreprises dans le domaine assurantiel, afin d'intégrer des modèles d'exigences SysML dans leurs cartographies. Cela a permis de mettre en œuvre un continuum dans le référentiel, des outils assurant la traçabilité de tous les artefacts de modélisation.

BMM (Business Motivation Model), une langue morte

Les composants BMM exprimés à l'aide des éléments de stratégie (marron clair)
et de motivation (violet) ArchiMate (Visual Paradigm).

Encore un flop de l’OMG et pourtant, cette norme avait tout pour plaire. Pour les architectes d’entreprise, un modèle de motivation métier va faciliter leur compréhension des stratégies afin qu'ils déterminent le SI cible le plus apte à s’aligner sur cette stratégie et à mieux servir les processus métier.

BMM devait être utilisé pour la traçabilité et le support de modélisation :

en aval, pour les impacts des diverses influences externes et internes sur les spécifications de processus métier, règles métier et responsabilités d'organisation.
en amont, pour une entreprise, pour expliquer pourquoi elle a choisi ses manières de procéder.

Ces 2 derniers points sont importants pour la gouvernance et pour la conformité réglementaire.

Un effort a été consenti dans la conception de BMM, de manière à être le plus simple possible.

Malgré cela, BMM est resté une norme morte, jamais utilisée, entraînant le fait qu'aucun outil ne soit réalisé pour supporter cette norme (voir nos articles en annexe dans la catégorie BMM). Seul Visual Paradigm propose un template, réalisé à l'aide du langage ArchiMate, qui représente les artefacts de modélisation BMM.

ArchiMate

Pattern adaptable ArchiMate, avec les liens entre les différentes couches d'architecture
(Visual Paradigm).

ArchiMate, publié par l’Open Group, est un langage de modélisation entièrement dédié à l’architecture d’entreprise et dont les concepts correspondent exactement à ceux du cadre TOGAF (The Open Group Architecture Framework).

Contrairement à UML, ArchiMate se destine à ceux qui ne s'embarrassent pas de détails techniques et qui désirent un formalisme synthétique pour modéliser directement, en appliquant les recommandations TOGAF à moindre effort et à moindre coût.

Il fournit des modèles de modélisation pour représenter les aspects de la stratégie, du métier, des applications, des technologies, des motivations, des implémentations et migrations.

Pour les couches applications et technologies, l’architecte applicatif préfère utiliser ArchiMate, au détriment des diagrammes de composants et de déploiement UML, qui sont plus abstraits.

L’architecte d’entreprise, quant à lui, peut intégrer des diagrammes de classes et d’états UML pour cartographier les entités métier saillantes, en complément des vues ArchiMate (voir nos articles en annexe dans la catégorie ArchiMate).

Modèle C4, l'approche facile qui explose

Le modèle C4 (Context/Software System, Containers, Components, and Code)
est une approche facile à apprendre et conviviale (C4 model).

Le modèle C4 (Context, Containers, Components, and Code) s’adresse aux concepteurs-développeurs d’applications et aux architectes logiciels. Un ensemble de 4 types de diagrammes hiérarchiques - contexte système, conteneurs, composants et code - constitue le modèle C4.

Un diagramme de contexte système montre une vue d'ensemble du paysage du système ; un conteneur est une unité exécutable-déployable, composée d'un certain nombre de "composants", avec des responsabilités et des technologies de mise en œuvre.

Facultativement, vous pouvez zoomer sur chaque composant pour montrer comment il est implémenté en tant que code, à l'aide de diagrammes de classes UML, de diagrammes de relations d'entités ou similaires. Ce niveau de détail n'est recommandé que pour les composants les plus importants ou les plus complexes.

L'éditeur français UNCIA propose une solution SaaS basée sur la méthode “C4 model” et destinée aux architectes et autres acteurs de l’IT participant à des projets couvrant les niveaux métier, sécurité, infrastructure, data, etc. La solution Uncia permet de conceptualiser et gérer le cycle de vie des référentiels techniques.

UML et le “Big Upfront Design”

UML fonctionne mieux dans une approche de “grande conception initiale” (Big Upfront Design), où les exigences et la conception de la solution sont définies avant le début du projet.

Il est idéal pour communiquer des idées aux développeurs, mais rien de plus. Une fois qu'un système est construit et livré, il est rarement synchronisé avec le système réel. Il a rendu un service inestimable en capturant la conception, en découvrant les problèmes potentiels et en expliquant aux développeurs comment construire la solution. Souvent, ces modèles dépréciés sont rangés au fond d’un placard et sont oubliés.

Conclusion

Au cours de mes missions, lors d’ateliers pour trouver des solutions à des problèmes de tous ordres, j’ai souvent vu des ingénieurs dessiner au tableau, des semblants de modèles UML en totale non-conformité avec cette norme, mais qui exprimaient parfaitement bien leurs pensées.

Avec les innovations disruptives des IA génératives, capables de créer des modèles et du code aussi bien que celui des concepteurs-développeurs (voir notre article : ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?), il est donc fort possible que l’on s’en tienne à des schémas servant la créativité, l'innovation, les réels besoins des utilisateurs, et non la technicité.

N'étant pas une méthode, mais juste un formalisme, l'usage d'UML tend donc à se simplifier, tout en s'éloignant de la norme. C’est ce que l’on constate avec des notations orientées dessins, comme le modèle C4 ou de l'UML agile et pragmatique comme dans la méthode Graal d'Obeo et son outil Information System Designer.

UML reste cependant un excellent moyen pédagogique pour enseigner l'art de la modélisation.

Laissons le mot de la fin à Craig Larman "Tout modèle est faux ! Et c'est OK".