NoSQL, NoCode et NoUML ? Faut-il encore modéliser avec UML ? Défauts et qualités de cette norme de l’OMG vieillissante

26 ans déjà ! UML (Unified Modeling Language) avec ses 14 diagrammes est un touche-à-tout et un expert de pas grand-chose.
Est-il toujours pertinent de l’utiliser dans le domaine de l’Architecture d’Entreprise, dans les projets IT, peut-il aider à modéliser des architectures micro-services, peut-il s'inscrire dans une approche Agile ?

Après NoSQL, NoCode, est-ce le tour de NoUML ?

UML doit-il prendre sa retraite ?

Depuis quelque temps, on voit apparaître de nouveaux outils comme Obeo Information System Designer, de nouvelles méthodes comme "C4 Model" (Context, Containers, Components, and Code) ou encore des solutions SaaS comme le propose l’éditeur français "Uncia", qui prennent leur distance avec UML et prônent des DSL (Domain Specific Language).

UML est allergique à l’Agile

La valeur des diagrammes UML dans un contexte d'agilité est limitée.

Dans un contexte d’agilité, les exigences et la conception sont élaborées au fur et à mesure que le projet progresse, les méthodes (Kanban, Scrum, Scrumban, XP...) en découlant sont devenues universellement répandues, afin de faire face à un niveau d'incertitude de plus en plus élevé dans l'environnement.

Pendant les premières itérations, il n'y a généralement pas suffisamment d'informations pour définir les exigences et une conception sophistiquée et, par conséquent, pour permettre d'élaborer des modèles UML pertinents, prouvant la solution et apportant de la valeur en termes de documentation.

Dans ce type d'approche, il est plus courant de s'appuyer sur la refactorisation de la conception en cours, plutôt que d'essayer de créer un modèle de conception complet avant le début du projet.

La valeur des diagrammes UML dans un tel contexte est limitée et l'effort nécessaire de mise à jour continuel au fur et à mesure que le projet progresse peut très rapidement devenir chronophage et grever le budget.

Près de 800 pages de spécifications !

La promesse d'UML version 2 était de normaliser la sérialisation textuelle des diagrammes en XML couplé avec une grammaire XSD, le tout nommé XMI (XML Metadata Interchange).

L’objectif était double : l’interopérabilité des outils et la transformation de modèles. Les rares outils proposant la génération XMI se sont heurtés au problème récurrent de gestion des versions. Une entreprise modélise avec l’outil A, puis fait le choix de changer pour un autre B, offrant plus de fonctionnalités, l’exporte en version x.y.z et au moment de l’importation vers l’outil B, elle fait face au message : “Impossible d’importer, la version x.y.z est non supportée, veuillez contacter votre fournisseur”.

UML dépend de son métamodèle le MOF qui dépend d'UML !

Quant à la transformation de modèles, elle est restée à l’état de rêve.

Le métamodèle MOF de l’OMG, en voulant être trop générique, n'a été que partiellement implémenté.

Le métamodèle MOF (Meta Object Facility) de l’OMG est presque aussi sibyllin que le cerveau humain. C’est la raison pour laquelle des organisations open source comme la fondation Eclipse ont développé leur propre métamodèle Ecore, le seul à avoir été véritablement utilisé (voir nos articles dans l’annexe).

Qu'est-ce qui est apparu en premier : le métamodèle ou le modèle ? (illustration générée par DALL-E)

Se pose aussi le problème métaphysique de la non-dépendance bidirectionnelle. En effet, UML devrait dépendre du métamodèle MOF et non l’inverse. Or, le MOF est modélisé en UML qui possède comme métamodèle le MOF !

Certains puristes pourraient rétorquer que le MOF n'est pas véritablement un métamodèle, mais un métamétamodèle réentrant, une pirouette intellectuelle pour arrêter le cycle.

Chaque type de diagramme représente en fait un espace conceptuel spécifique, qui aurait besoin de son propre modèle spécifique.
Une bien meilleure approche aurait été de définir des métamodèles distincts pour les quelques types de modèles réellement nécessaires, comme les diagrammes de cas d'utilisation, de classes, de machine à états et d’interactions.

Et puis, reste le sempiternel problème du type qui n’est pas distingué de la classe. La détermination de la conformité s’effectue sous forme de relation entre les types et non les classes. Les types sont des entités générées à partir de classes, ils spécifient la forme instanciable lors du runtime.

Vous n’êtes pas convaincu ? Alors je vous propose d’aller sur le site appelé validateur NIST (National Institute of Standards and Technology) et assurez-vous d’avoir une bonne provision d’aspirine à proximité.

UML exécutable, une utopie ?

L’INRIA et consorts ont développé un langage de transformation de modèles ATL
plus simple que celui de l'OMG (MOF-QVT).

Dans les années 90, les trois amigos (Booch, Rumbaugh, Jacobson) ont unifié leurs méthodes de modélisation Orientée-Objet, pour créer non pas une nouvelle méthode, mais uniquement un formalisme laissant la liberté à chacun de l’utiliser comme bon lui semble. Ce qui, plus d’un quart de siècle après, pose d’énormes difficultés aux néophytes qui sans guidance sont complètement désemparés devant des concepts abscons.

UML avait fait le buzz comme le font aujourd’hui DevOps, la conteneurisation, le CI/CD et l’architecture micro-services.
Puis rapidement, vinrent les idées folles sur la création de bases de code entières à partir de conceptions UML, à l'intérieur d'outils de modélisation.

Dans le cadre d’une refonte du SI d’une assurance santé, j’avais participé à la politique de mise en œuvre de génération de code bidirectionnelle (MDE roundtrip) avec les outils IBM Rational. Malgré la compétence des architectes logiciels, ces outils ont vite montré leurs limites. Le code généré devait être repris et optimisé. Le report automatique dans les modèles UML du refactoring par les concepteurs présentait de nombreux dysfonctionnements.
La promesse qu'il soit utilisé, au moins en partie, comme langage de programmation visuel - alias "UML exécutable" - et comme un moyen pour les développeurs de construire des systèmes complexes en les concevant avec UML, plutôt qu'en les écrivant avec du code, n'a jamais été tenue.
Cela n'a pas fonctionné. Il s'avère que les concepteurs et les modélisateurs, qui ne savent pas programmer, ne peuvent pas non plus programmer avec UML, et ceux qui savent programmer préfèrent coder directement.

MDA (Model Driven Architecture), pour que tout soit modèle. Jusqu’ici, tout va bien !

La tour de Babel de l'OMG pour son "UML exécutable".

Alors l’OMG (Object Management Group), l’organisation qui a normalisé UML, a créé MDA (Model Driven Architecture), pour que tout soit modèle.
Pour cela, elle a créé un métamodèle, le MOF (MetaObject Facility), un langage QVT (Query/View/Transformation) pour transformer les modèles en suivant les phases CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model), etc. Jusqu’ici, tout va bien. C’était sans compter la complexité qui s’est immiscée.

QVT est divisé en 3 langages : en mode impératif, QVTo (Query View Tranformation Operational) et en mode déclaratif, QVTr (Query View Tranformation Relational), langage de haut niveau et QVTc (Query View Tranformation Core), plus simple et de plus bas niveau que QVTr. En supplément, il faudra maîtriser OCL (Object Constraint Language), pour manipuler les règles UML.
Personne n’a été se perdre dans ces normes labyrinthiques, où les rares implémentations sont toujours en version bêta et qui finalement tomberont en désuétude.

L’INRIA et consorts avaient développé un langage plus simple ATL (Atlas Transformation Language) qui a, en son temps, a remporté un certain succès. (voir nos articles dans l’annexe).

"Pourquoi faire simple quand on peut faire compliqué ?"

UML n’est pas une méthode

Exemple d'étapes à suivre pour modéliser le métier
(voir nos articles sur ces méthodes en annexe).

Exemple d'étapes à suivre pour modéliser les besoins
(voir nos articles sur ces méthodes en annexe).

C’est bien là le problème. Le débutant dispose d’une boite à outils, mais dans quels cas utiliser un maillet plutôt qu’un marteau ?
Le projet d’adjoindre à UML une méthode formelle, comme la méthode B ou Eiffel de Bertrand Meyer, a été abandonné.
UML n’est qu’un mauvais cocktail où l’on essaye de mixer éléments visuels et conceptuels.

Personne n’a encore résolu l’énigme de l’association/attribut. Par exemple, si l'on modélise une association de la classe A vers B, alors des méta-objets d’association seront créés. Si un autre diagramme représente les propriétés de A, un attribut correspondant à l’association sera présent, mais l’association correspondante disparaîtra.

Les diagrammes produits à l'aide d'UML peuvent souvent être ambigus, en particulier s'ils ne sont pas annotés avec des informations supplémentaires ou si la notation n'est pas utilisée de manière cohérente.

Il n’y a pas que l’Orienté-Objet dans la vie

L'Orienté-Objet ne fait pas l'unanimité

S’il y a bien 2 paradigmes qui s’opposent totalement, ce sont bien l’Orienté-Objet et le paradigme fonctionnel. Les projets basés sur ce dernier sont pléthore de nos jours. Même des langages comme Java, Orienté-Objet donc, que tout oppose, ont intégré des concepts de programmation fonctionnelle.

Mais malheureusement pas UML, qui ne permet pas par exemple de modéliser les fonctions d'ordre supérieur. Une fonction est dite d'ordre supérieur lorsqu'elle peut prendre des fonctions comme arguments ou renvoyer une fonction comme résultat. On dit aussi que les fonctions sont des objets de première classe, ce qui signifie qu'elles sont manipulables aussi simplement que les types de base.

UML a été conçu pour être un langage de modélisation universelle. Pour se faire, l’OMG a choisi les concepts de l’Orienté-Objet, en pensant que ce paradigme allait tout solutionner.
Malheureusement, l'ingénierie système, l’informatique industrielle et scientifique ne l’utilise pas et sont même parfois totalement réfractaires à ce type de pensée.

D’autre part, 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, à moins de construire son propre profil personnalisé avec stéréotypes, tags-value et règles OCL.

UML ne prévoit rien pour représenter des éléments non-logiciels, des contraintes, des flux (énergie, fluide...), des allocations structurelles/comportementales, des équations mathématiques, des algorithmes de Machine Learning et autres APIs d’IA génératives.

L’OMG a corrigé le tir en créant le profil normalisé SysML, qui intègre un diagramme d’exigences et qui a rayé de sa terminologie toutes références aux classes, objets, attributs, méthodes, etc.

Just code it

De nombreux retours d'expérience montrent que les développeurs préfèrent coder directement.

UML met l'accent sur les abstractions (ce qui est bon pour la conception et l'architecture), mais parfois vous devez "Just code it", parce que le diable est dans les détails. De nombreux développeurs qui apprennent à utiliser UML ont à équilibrer l'effort entre les différents aspects d’une modélisation. Travailler à différents niveaux d'abstraction est en fait assez difficile. Ainsi, en raison des pressions du marché, de la difficulté de la tâche et du manque d'outils faciles à utiliser et abordables, la modélisation et la conception sont laissées de côté.

Pour la documentation, les professionnels de l’IT passent à quelque chose de plus vivant, comme l'utilisation d'OpenAPI, à l'aide de scripts Swagger.

Qu’en “pense” notre ami ChatGPT

Question posée : Quelles sont les faiblesses d'UML ?

Réponse de ChatGPT

Bien qu'UML soit un langage de modélisation largement utilisé et efficace, il présente certaines faiblesses. En voici quelques-unes :

Complexité : UML peut être complexe et difficile à apprendre pour les débutants. Le langage comprend un grand nombre de types de diagrammes et de symboles, ce qui peut être écrasant pour les nouveaux utilisateurs.
Frais généraux : UML peut parfois entraîner des frais généraux en termes de temps et d'efforts requis pour créer et maintenir les diagrammes. Cela peut être particulièrement vrai pour les grands systèmes où de nombreux diagrammes sont nécessaires.
Normalisation incomplète et incohérente : La norme UML a été critiquée pour être incomplète et incohérente, en particulier en ce qui concerne la prise en charge des outils. Bien que la norme fournisse un ensemble commun de concepts et de notations, il n'est pas toujours clair comment ceux-ci doivent être implémentés dans les outils logiciels.
Manque d'alignement avec les méthodologies Agile : UML est un langage de modélisation qui a été conçu pour être utilisé dans les processus de développement de logiciels traditionnels basés sur des plans. Bien qu'il puisse être utilisé dans le développement Agile, il peut ne pas être aussi bien aligné avec les méthodologies Agiles que certains autres langages de modélisation.
Ambiguïté : Les diagrammes produits à l'aide d'UML peuvent parfois être ambigus, en particulier s'ils ne sont pas annotés avec des informations supplémentaires ou si la notation n'est pas utilisée de manière cohérente.

Malgré ces faiblesses, UML reste un langage de modélisation largement utilisé et efficace pour le développement de logiciels. Ses forces et ses avantages l'emportent souvent sur ses faiblesses et il continue d'évoluer pour répondre aux besoins du développement de logiciels modernes.

Conclusion

Comme on l’a souligné au cours de cet article, UML est trop complexe, trop abstrait ; les promesses d’interopérabilité et de transformation de modèles, pour arriver à des modèles de code, n'ont pas abouties.

UML 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é, les modèles sont rarement synchronisés avec le système réel. Ils ont rendu un service inestimable en capturant la conception, en découvrant les problèmes potentiels et en expliquant aux développeurs comment construire le système. Souvent, ces modèles dépréciés sont rangés au fond d’un placard et sont oubliés.

Mes retours d’expérience de missions menées aussi bien auprès de startups férues de technologies que de grandes organisations traditionnelles (gouvernement, banques, finances, assurances, etc.) m’ont montré que dans le premier cas, UML est le cadet de leurs soucis, alors que dans le deuxième, UML est un outil appréciable.

Il aura fallu plus d'un quart de siècle pour s'apercevoir qu'un langage générique ne fait pas recette.

Rhona Maxwel

urbanisation-si.com

@rhona_helena

"Comparez ce à quoi ressemblait le monde il y a 15 ans (pas de smartphones), il y a 150 ans (pas de moteur à combustion, pas d'électricité domestique), il y a 1500 ans (pas de machines industrielles) et il y a 15 000 ans (pas d'agriculture). Le changement à venir sera centré sur la plus impressionnante de nos capacités: celle, phénoménale, de penser, de créer, de comprendre et de raisonner.

D'ici une décennie, les gains en productivité générés par cette incroyable révolution qu'est l'lA, permettront de verser généreusement et sans contrepartie 13 500 dollars par an à chaque habitant sur Terre."

Sam Altman, le père de ChatGPT