UML
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".
|
|
Rhona Maxwel @rhona_helena |
“Mes méthodes sont-elles malsaines ?
Je ne vois aucune méthode, mon colonel.”
Echange tiré du film culte Apocalypse Now, de Francis Ford Coppola
Annexes
Les 4 diagrammes UML à utiliser
Les bonnes pratiques pour modéliser les Cas d'Utilisation UML :
- Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (5)
- Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Diagramme de classes UML :
Les règles à appliquer pour un diagramme de classes valide :
Diagramme de séquence UML :
Les bonnes pratiques pour un diagramme de séquence valide :
Les règles à appliquer pour un diagramme d'états :
Proposition de méthode utilisant UML pour développer des applications
UML n'est pas une méthode : exemple de méthode à adapter pour la modélisation métier et les besoins :
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 3ème partie - Processus métiers - BPMN
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 4ème partie - Processus métiers - UML - Diag. Activité
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 5ème partie - Règles métier- UML - Profil spécifique
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 8ème partie - Etats métiers – UML – Diag. Etats
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 10ème partie - Liste des exigences – UML – Diag. Package
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 11ème partie - Exigences – UML – Profil spécifique
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 12ème partie - Contexte Statique – UML – Diag. Classe
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 13ème partie - Contexte Dynamique/Diag. Flux
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 14ème partie - Cas d’Utilisation – UML – Diag. Use Case
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 15ème partie - Regroupement par Domaines – UML – Diag. Package
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 16ème partie - Scénarios Cas d’Utilisation – UML – Diag. Séquence
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - Dernière partie - Traçabilité – UML – Relation de dépendance
Pour créer des modèles UML avec ChatGPT ou avec des outils gratuits
Les meilleurs logiciels de modélisation UML :
Création de modèles UML, BPMN et de cartographies ArchiMate avec ChatGPT :
C4 model, un UML pour simplement dessiner
La méthode “C4 model” (Context, Containers, Components, and Code) pour visualiser l’architecture logicielle propose une simplification extrême d’UML.
Pour les architectures métier, sécurité, infrastructure… la solution Saas UNCIA
La solution Uncia permet de conceptualiser et gérer le cycle de vie des référentiels techniques.
Un moteur de règles métier gratuit
DROOLS est un BRMS (Business Rules Management System) open source largement utilisé, par exemple dans les assurances :
Pour tout savoir sur BPMN
Retrouvez tous nos articles sur BPMN dans la catégorie :
Pour tout savoir sur DMN
Retrouvez tous nos articles sur DMN dans la catégorie :
Pour tout savoir sur CMMN
Retrouvez tous nos articles sur CMMN dans la catégorie :
Pour tout savoir sur SysML
Retrouvez tous nos articles sur SysML dans la catégorie :
Pour tout savoir sur BMM
Retrouvez tous nos articles sur BMM dans la catégorie :
Pour tout savoir sur ArchiMate
Retrouvez tous nos articles sur ArchiMate dans la catégorie :
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 @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
Annexe
Certification, validité, prototypage et vérification des modèles UML :
Les aspects structurels, fonctionnels et dynamiques d'UML :
Définir formellement les règles et trouver un algorithme qui permette de les vérifier :
Correspondances entre éléments de modélisation de niveaux (abstraction ou modèle) différents.
Les bonnes pratiques pour modéliser les Cas d'Utilisation UML :
- Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (5)
- Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Diagrammes de composants et de déploiement UML :
Diagramme de classes UML :
Les règles à appliquer pour un diagramme de classes valide :
Diagramme de séquence UML :
Les bonnes pratiques pour un diagramme de séquence valide :
Les règles à appliquer pour un diagramme d'états :
Les règles UML sont écrites en OCL :
- Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (12)
- Modélisation de système : UML n'est rien sans OCL !
- Modélisation de système : OCL ça se complique !
- Modélisation de système : OCL vous en redemandez ?
UML n'est pas une méthode : exemple de méthode à adapter pour la modélisation métier et les besoins :
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 2ème partie - Processus métiers - Profil UML Eriksson Penker
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 3ème partie - Processus métiers - BPMN
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 4ème partie - Processus métiers - UML - Diag. Activité
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 5ème partie - Règles métier- UML - Profil spécifique
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 8ème partie - Etats métiers – UML – Diag. Etats
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 10ème partie - Liste des exigences – UML – Diag. Package
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 11ème partie - Exigences – UML – Profil spécifique
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 12ème partie - Contexte Statique – UML – Diag. Classe
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 13ème partie - Contexte Dynamique/Diag. Flux
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 14ème partie - Cas d’Utilisation – UML – Diag. Use Case
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 15ème partie - Regroupement par Domaines – UML – Diag. Package
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 16ème partie - Scénarios Cas d’Utilisation – UML – Diag. Séquence
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - Dernière partie - Traçabilité – UML – Relation de dépendance
Pour tout savoir sur l'Ingénierie Dirigée par les Modèles :
Les meilleurs logiciels de modélisation UML :
Création de modéles UML, BPMN et de cartographies ArchiMate avec ChatGPT :
Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Un use case UML ( cas d'utilisation ) est une activité métier comme par exemple un acte de gestion exécuté par un acteur externe à l'application.
Un acteur au sens UML du terme, est un rôle qui correspond à son activité métier au moment ou il utilise le système.
Par exemple, un directeur commercial peut avoir plusieurs rôles au sein de l'application. Si celle-ci propose une fonctionnalité d'aide à la rédaction de propositions commerciales, lorsqu'il veut en rédiger une ( activité identifiée normalement dans la modélisation des processus métier ), il endosse le rôle de "rédacteur de proposition commerciale".
Pour la gestion des prospects son rôle est alors "ingénieur commercial" et lorsqu'il souhaite gérer les tableaux de bord de ses commerciaux, "directeur commercial".
Le rôle « directeur commercial » hérite de tous les rôles précédents.
Ces rôles sont des profils fonctionnels par rapport à l'exercice d'une activité composée d'une suite d'actions.
Les acteurs sont identifiées à partir des fonctions existantes dans l'entreprise et à partir des processus métiers de la vue modélisation métier de l'urbanisation du Système d'Information.
Un use case comporte un ou plusieurs scénarios composés de une ou plusieurs étapes.
Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.
La bonne pratique est de toujours commencer par analyser les scénarios nominaux puis les décrire jusqu'à obtenir une version stable.
Il est alors plus aisé d'identifier les scénarios alternatifs et exceptionnels à partir de la séquence normale des étapes des scénarios principaux.
Un scénario nominal conduit au résultat attendu, un scénario alternatif va mener à une fin normale mais en empruntant un autre chemin c'est à dire une autre suite d'étapes pour des conditions particulières, quand au scénario exceptionnel, il conduit toujours à une fin anormale correspondant à la génération d'une exception métier comme par exemple une donnée de paramétrage inexistante.
D'après l'ouvrage culte d'Alistair Cockburn "Writing effective use case", on peut définir 3 niveaux de use case qui sont pour reprendre son allégorie : le niveau nuage, le niveau de la mer et le fond de la mer.
Le niveau nuage correspond à des use case à fortes granularités, stratégiques comme par exemple "Gérer un prêt bancaire". Ces use case sont trop "gros", ils doivent être décomposés en use case du niveau de la mer.
Le niveau de la mer correspond bien à un use case utilisateur pour l'application cible, l'exemple précédent se décomposerait en 3 use case : "Gérer une demande de prêt bancaire", "Analyser une demande de prêt bancaire" et "Valider une demande de prêt bancaire".
Et le niveau fond de la mer, correspond à une fonction élémentaire simple non décomposable comme par exemple "Imprimer la demande de prêt bancaire". Ces use case correspondent à une simple étape d'un scénario.
Pour synthétiser, tout se résume à déterminer la bonne granularité d'un use case.
Alors comment faire pour trouver les bons use case, ni trop gros, ni trop fin ?
Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".
Un use case doit avoir en moyenne 10 scénarios composés chacun d'environ 10 étapes. De plus il doit être déclenché par un unique acteur ( rôle ), exécuté dans une limite de temps, être transactionnelle, avoir un début et une fin et pour terminer on doit avoir unicité de lieu.
Donc si ron eprend l'exemple du use case niveau nuage "Gérer un prêt bancaire", on voit qu'il faut d'abord faire une demande de prêt déclenchée par un chargé de clientèle, puis cette demande est analysée par un analyste financier et ensuite validée par le directeur d'agence.
Il y a donc 3 acteurs différents, intervenant à des moments différents dans des lieux éventuellement différents. Par conséquent, le use case doit être décomposé pour satisfaire la méthode des "10 ; 10".
Examinons cette décomposition.
La gestion de la demande exige environ une dizaine de scénarios ( utilisation, type de prêt, ... ) et pour chaque scénario on aurait approximativement une dizaine d'étapes ( situation de famille, recensement des revenus, existence d'autres prêts, même établissement, propositions de différentes solutions de remboursement, ... ).
Le use case "Gérer une demande de prêt bancaire" est déclenché par un seul acteur le chargé de clientèle, il débute quand celui décide de créer/modifier une nouvelle demande et se termine quand celle-ci est créée ou modifiée.
Le use case "Analyser un prêt bancaire" est déclenché par l'analyste, commence lorsqu'il décide d'analyser une demande en attente et se termine lorsqu'il a émis une recommandation. On peut identifier une dizaine de scénarios constitués d'une dizaine d'étapes.
Le même raisonnement s'applique pour "Valider un prêt bancaire" déclenché par le directeur d'agence.
Si un même use case doit être factorisé et exécuté systématiquement dans plusieurs autres, on utilise la relation de dépendance <<include>>, du use case inclus vers celui qui le contient. Typiquement c'est le cas de l'authentification qui doit être obligatoirement effectuée au début de chaque use case.
Un use case peut être le prolongement d'un autre, on dit qu'il étend un use case ( relation <<extend>> attention au sens de la flèche qui va de celui qui étend vers celui qui est prolongé ).
Par exemple, pour analyser une demande de prêt, il faut les rechercher et les consulter donc le use case "Analyser une demande de prêt" étend le use case "Rechercher et consulter une demande", sachant que l'on peut juste vouloir consulter sans faire d'analyse. L'appel au use case qui étend est donc facultatif.
On vérifie que toutes les exigences sont implémentées dans au moins un use case.
Si ce n'est pas le cas c'est qu'on n'a pas encore terminé le travail de recensement des use case ou bien que les exigences restantes sont en dehors du périmètre de l'application.
Cette traçabilité est assurée par des relations d'implémentation UML allant de l'exigence modélisée comme une classe vers le use case.
Chaque scénario doit être décrit de manière textuelle en adoptant un formalisme qui constitue le modèle de fiche de use case.
Les AGL offrent des modèles prêts à l'emploi.
L'avantage est que cette description textuelle est stockée directement dans le référentiel de l'AGL. La traçabilité est ainsi assurée, on peut générer automatiquement la documentation et faire des estimations avec les modules de points de use case.
La méthode empirique d'identification des use case dite des "10 ; 10" a toujours donné de bons résultats et surtout permet d'avoir un cadre pour se prémunir des pièges lorsqu'on débute dans la modélisation des exigences et obtient donc une note de 10/10.
Rhona Maxwel
@rhona_maxwel
"Dans le sommeil, ce voyage aventureux de tous les soirs, il y a quelque chose de positivement miraculeux c'est un miracle dont la ponctualité a émoussé le mystère."
Charles Baudelaire
Articles conseillés :
SysML : le diagramme de cas d'utilisation (use case diagram)
SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)
Partir du bon pied dans un projet informatique : la modélisation métier