urbanisation-si.com

La Documentation d'Architecture Technique (DAT) est un élément essentiel pour la réussite de vos projets informatiques. Elle vous permet de définir, de communiquer et de valider les choix techniques qui soutiennent vos services. Elle vous aide également à respecter les normes de sécurité, à optimiser les ressources et à anticiper les impacts.
Mais comment créer et maintenir une documentation d'architecture de manière efficiente, à jour et partagée par tous les acteurs de la DSI ? Comment éviter les documents Word, Excel et PowerPoint qui se perdent, se contredisent ou deviennent rapidement obsolètes ? Comment gagner du temps et de la productivité dans la gestion de vos projets ?

Dans le référentiel d'architecture du SI, il arrive parfois de trouver des photos de schémas
griffonnés à la main et que l'on a oublié de mettre au propre (source C4 model).

Vous reconnaissez-vous dans ce processus
de gestion de référentiel d’architecture ?

De nombreuses entreprises éprouvent des difficultés à mettre en place une documentation efficace en raison de problèmes de priorisation, de processus inadéquats, et du manque de cohérence dans la construction du DAT, qui est une pièce essentielle de la documentation.

Par exemple, elles vont utiliser : 

• Diagrams.net anciennement Draw.io (A lire > diagrams.net ou draw.io : outil en français gratuit pour dessiner des diagrammes ; mais quel est véritablement son spectre d’utilisation ? La réponse dans notre test.) ou PowerPoint pour les schémas applicatifs et techniques,
   
• Excel pour la cartographie des flux et des interfaces et le référentiel des matériels,
   
• Word pour le document de synthèse, la description de plus haut niveau des Web Services, les Use Cases et la volumétrie...

Les corrections et les améliorations se font fréquemment en urgence, ou bien il faut rapidement implémenter la solution et l’on verra plus tard pour la documentation.

Ce processus de tous les dangers adopté par la grande majorité, consistant à faire d'abord et à documenter ensuite, va entraîner une perte de contrôle et donner naissance à du shadow IT (partie de l’IT non maîtrisée ou inconnue), comme des flux ouverts alors qu’ils ne devraient pas, ou des machines sur lesquelles on ne sait pas ce qui est installé. En cas de crise, cette situation risque de devenir très problématique.

Lors d’une précédente mission d’un projet d’urbanisation du SI pour une grande administration, pendant l'audit visant à recenser les applications, à la question "quelles sont les applications hébergées par ce serveur ?", on nous a répondu "les personnes qui s’en occupaient sont parties, on ne sait plus à quoi il sert, mais comme il est connecté à notre SI, on n’ose pas l’arrêter, de peur des impacts, donc on le laisse tourner…".

Alors que faut-il faire ?

Un processus idéal implique de documenter avant de mettre en œuvre (source : Uncia).

Une documentation de qualité a plusieurs avantages : elle rassure les acteurs de la Direction du Système d'Information (DSI), structure les projets en fournissant un cadre de travail, et sert de base de partage d'informations. Sans documentation adéquate, il est difficile de s'assurer du respect des règles, tout comme il serait risqué de construire une maison sans plan.

La documentation d'architecture idéale est sans erreurs ni incohérences, lisible par tous les acteurs de la DSI, à jour, versionnée pour suivre les évolutions, et explique les décisions prises. Elle doit s'intégrer dans un écosystème permettant de cartographier l'ensemble du système d'information et de devenir la source de vérité pour les acteurs de la DSI.

Le DAT, qui est au cœur de la documentation, doit être structuré et interconnecté avec d'autres documents, tels que les schémas applicatifs, les cartographies des flux, les référentiels matériels, et les documents de synthèse. Il est crucial que les acteurs de la DSI aient accès à un référentiel documentaire partagé en mode collaboratif, centralisé, complet, versionné, regroupant les règles du SI, la cartographie, le DAT, et le catalogue des produits.

C4 model

Avant de présenter un outil particulier pour documenter l'architecture technique, intéressons-nous au C4 model.

Le C4 model, créé par Simon Brown et popularisé depuis 2018, permet de visualiser de manière simplifiée, mais rigoureuse, l’architecture logicielle, en se basant sur la décomposition structurelle en Conteneurs et en Composants. Comme on peut le deviner, les « C » sont en fait au nombre de 4, avec en amont le Contexte et en aval le Code.

Le C4 model permet de représenter les relations entre ces différents éléments, voire avec les utilisateurs, en proposant plusieurs points de vue (ou plutôt plusieurs niveaux de zoom). Le C4 model peut être utilisé pour la conception, de préférence collaborative, de systèmes logiciels, puis pour la documentation. L’intérêt d’une bonne documentation vient d'être rappelé plus haut.

Contexte, Conteneurs, Composants, Code

• Contexte (niveau 1) : périmètre et environnement du système logiciel ; relations avec les utilisateurs et avec les autres systèmes.
• Conteneurs (niveau 2) : décomposition du système logiciel en conteneurs qui peuvent être déployés et exécutés de manière indépendante (applications, bases de données).
• Composants (niveau 3) : décomposition des conteneurs en composants interdépendants –
  c.-à-d. non déployables indépendamment (high-level building blocks).
• Code (niveau 4) : dernier niveau de représentation de la conception avant le code source ; comment les composants sont implémentés : classes, interfaces, objets, fonctions, etc.

Les 4 "C" - niveaux - du C4 model (source : C4 model)

Les 3 premiers niveaux utilisent les 5 mêmes éléments de base dans les diagrammes :

• Les personnes, les systèmes logiciels, les conteneurs, les composants et les relations.

Les personnes peuvent être des acteurs, des rôles, des personnages (personas) et seront représentées par des bonshommes. Les systèmes, conteneurs et composants seront représentés sous forme de blocs rectangulaires imbriqués (sauf les bases de données). Pas de surprise : les relations seront représentées par des flèches, avec des descriptions correspondant au sens des flèches de préférence. Une description pertinente permettra de savoir si une flèche représente une dépendance ou un flux de données entre deux éléments.

Cette forme de représentation est tellement peu contraignante qu’il sera parfois difficile, de prime abord, de distinguer ces 3 niveaux de représentation. L’usage est d’utiliser une couleur différente pour chaque type d'éléments, bien qu’il n’y ait aucune obligation. On peut aussi arrondir les angles. Ajouter une légende sur chaque diagramme est fortement recommandé.

Exemple de légende des niveaux 3, 2 et 1 du C4 model

Quant au niveau 4, il n’y a pas de représentation particulière pour le Code : il est recommandé d’utiliser une notation standard existante, comme un diagramme de classes UML ou un Diagramme Entités-Relations.

Seuls les diagrammes de niveaux 1- Contexte et 2- Conteneurs sont recommandés dans tous les projets, car compréhensibles par un large public. Les diagrammes des niveaux 3- Composants et 4- Code sont optionnels, car ils s’adressent à un public d’informaticiens (architectes, analystes-concepteurs, développeurs).

L'éditeur français Uncia vous propose
une solution cousue main

Le C4 model n’impose pas d’outil particulier. Uncia est une solution innovante se présentant sous forme d’une plateforme web payante qui vous offre un cadre documentaire homogène pour tous vos projets. 

Avec Uncia, vous pouvez :

• Personnaliser votre environnement selon vos besoins et vos préférences,
   
• Éditer des schémas applicatifs interactifs et lisibles,
   
• Spécifier les ressources matérielles qui portent vos services,
   
• Éditer des documents de synthèse clairs et complets,
   
• Créer des synergies entre les équipes de la DSI avec le mode collaboratif,
   
• Exporter les données vers votre outil ITSM (IT Service Management software)
  pour gérer les ouvertures de flux et les approvisionnements,
   
• Cartographier très finement le SI et identifier les ressources critiques.

Comment fonctionne Uncia ?

L'effort en pourcentage à fournir pour réaliser les différentes parties d'un DAT (source : Uncia).

Uncia fonctionne selon un principe simple : vous saisissez les informations relatives à vos architectures techniques dans des formulaires adaptés, et Uncia se charge de générer automatiquement les documents correspondants.

Par exemple, si vous voulez créer un schéma applicatif, il vous suffit de renseigner le nom du projet, le périmètre fonctionnel, les applications impliquées, les flux échangés, etc. Uncia va alors produire un schéma clair et interactif au format C4 model, que vous pourrez modifier, annoter, partager ou exporter selon vos besoins.

De même, si vous voulez créer un document de synthèse, il vous suffit de sélectionner le projet concerné, et Uncia va extraire les informations pertinentes du référentiel pour rédiger un document complet et cohérent, qui contient le schéma applicatif, le schéma matériel, la liste des ressources, la politique de sécurité, etc.

Uncia vous permet également de réutiliser les données existantes pour créer de nouveaux documents. Par exemple, si vous avez déjà saisi les informations relatives à une application dans un projet, vous n'avez pas besoin de les ressaisir dans un autre projet. Uncia va automatiquement récupérer ces informations et les intégrer dans le document correspondant.

Quels sont les bénéfices d'Uncia ?

Diagramme d’application web réalisé avec l'outil Uncia au format C4 model.

Uncia vous apporte de nombreux bénéfices, tels que :

• Une uniformisation de la documentation d'architecture technique,
  qui facilite la communication et la compréhension entre les différents acteurs du projet,
   
• Une sécurisation du respect de la politique de sécurité de votre organisation,
  depuis la définition des architectures jusqu'à la préparation des mises en production,
   
• Une optimisation du temps et des ressources, grâce à l'automatisation des tâches répétitives et à la réutilisation des données existantes,
   
• Une intégration dans le workflow de votre DSI, grâce à une API ouverte
  qui permet de connecter Uncia à vos outils de gestion ITIL,
   
• Une meilleure maîtrise du SI, grâce à une vision globale et détaillée
  de vos architectures techniques et de leurs impacts,
   
• La gestion des règles d'urbanisme qui ne se limitent pas seulement à la structure physique d'un système, mais qui définissent également des règles de communication, de segmentation du réseau, et de gestion des flux. Cette approche globale garantit une meilleure gestion de la complexité du SI,
   
• Validation en temps réel des règles. Par exemple, si un architecte essaie d'établir un flux FTP entre deux composants, le système génère une notification instantanée pour l'informer que cette action enfreint une règle spécifique. Par contre, un flux SFTP (SSH) est autorisé (diagramme d'exemple ci-dessus). Cette approche proactive renforce la conformité et permet l'apprentissage des règles au sein de l'organisation,
   
• Interconnectivité des Documents de manière à ce que toute modification dans l'un puisse avoir un impact sur d'autres. Par exemple, si un schéma applicatif est modifié, cette modification peut automatiquement mettre à jour les informations relatives aux flux de données, garantissant ainsi la cohérence et la traçabilité des changements.
   
• Automatisation de la Matrice de Flux. Par exemple en automatisant la tâche de création, souvent fastidieuse, on va réduire les erreurs humaines et garantir que les informations sur les flux de données sont toujours à jour,
   
• Référentiel Centralisé. Il rassemble non seulement les données de base de la documentation, mais il intègre également des catalogues de produits, permettant aux architectes de savoir quels produits sont autorisés pour une utilisation spécifique. Cette approche centralisée offre une visibilité complète sur l'ensemble du SI,
   
• Intégration d'APIs. Uncia peut s'intégrer avec divers outils et services externes, tels que Draw.io, Excel, Word, Service Now, et AWS. Cela signifie que les données peuvent être extraites ou mises à jour automatiquement à partir de ces systèmes, ce qui facilite la synchronisation de la documentation avec les changements dans l'infrastructure et les applications. Uncia supporte tout type de cloud public et privé. Le cloisonnement 100 % étanche entre les bases de données de clients différents est garanti,
   
• Gestion des Services Requests pouvant être déclenchées en fonction des modifications apportées à la documentation. Par exemple, une modification dans la matrice de flux pourrait automatiquement déclencher une demande de modification dans un pare-feu pour refléter ces changements,
   
• Catalogue de Produits, aidant à garantir que seuls les produits autorisés sont utilisés
  dans le SI, ce qui renforce la sécurité et la conformité,
   
• Consommabilité via des APIs permettant des intégrations avancées,
   
• Automatisation des Workflows offrant des cycles de relecture, la gestion des commentaires, et le suivi des modifications. Cela accélère la validation des DAT et réduit les délais.

Conclusion

Le rôle de cet article est de redonner à la documentation d'architecture technique la juste place qu’elle mérite dans vos projets. Le C4 model permet une représentation visuelle simple, mais puissante, de cette architecture, en proposant 4 niveaux de zoom plus ou moins détaillés. Uncia, qui s'appuie sur le C4 model, est une solution innovante qui va au-delà de la simple documentation en offrant des fonctionnalités avancées : automatisation, interconnectivité et intégration avec d'autres outils, pour simplifier la gestion de l'architecture technique, renforcer la conformité, et améliorer la sécurité des systèmes d'information.

Merci pour vos commentaires qui seront les bienvenus, ainsi que vos retours d'expérience heureux ou malheureux, qui pourront profiter à nos lecteurs.

"Faute de valeur supérieure qui oriente l'action, on se dirigera dans le sens de l'efficacité immédiate. Rien n'étant vrai ni faux, bon ou mauvais, la règle sera de se montrer le plus efficace, c'est-à-dire le plus fort. Le monde alors ne sera plus partagé en justes et en injustes, mais en maîtres et en esclaves" 
Albert Camus

Si l'on demande à ChatGPT : “A quels défis sont confrontés aujourd'hui les architectes d'entreprise ?”, voici ce qu'il cite en premier : “L’un des principaux défis est de faire face à la complexité croissante des systèmes d’information et des technologies de l’information”. Puis, en deuxième : “Les architectes d’entreprise doivent être en mesure de communiquer efficacement avec les parties prenantes de l’entreprise, y compris les cadres supérieurs, les responsables informatiques et les utilisateurs finaux”.

Une meilleure communication pour une meilleure transformation numérique

Commençons par une évidence, que l’on trouve dans toutes les introductions dans cette catégorie d’articles que vous êtes en train de lire : les changements à fréquence effrénée impactent l’entreprise aux niveaux stratégie, processus métier, applications et infrastructure. Vous le savez, il n’y a que des solutions. Une parmi tant d’autres est que les parties prenantes aient accès à des informations qualifiées et de première fraîcheur.

Les problèmes de communication entre les acteurs sont un frein à la compréhension de l'organisation de l'entreprise, son système d'information et son architecture. La diversité des différents métiers ne doit pas empêcher les échanges et l'enrichissement du patrimoine de l’entreprise. Souvent, les outils hétérogènes de chaque métier ne sont pas interopérables.
Le recueil des données pour une transformation par la MOA, les architectes d’entreprise, les urbanistes du SI, les chefs de projets, les architectes logiciels… est une activité chronophage et devient vite obsolète dès que des changements interviennent.

Pour avoir un référentiel TOGAF rassemblant les autres référentiels (Stratégies, Finances, Applications, Architectures, Infrastructures…), faciliter la connaissance du SI et rendre plus efficientes les transformations de l’entreprise, la solution est de récupérer et agréger des informations issues de sources hétérogènes dans un référentiel centralisé. Concrètement, un ensemble de connecteurs récupère automatiquement et itérativement les données en fonction de règles préétablies à partir de n’importe quel type de fichiers. Dans le contexte de l’élaboration des trajectoires possibles, cette technique fait gagner beaucoup de temps à l'architecte d’entreprise qui peut se libérer de tâches manuelles fastidieuses et se concentrer sur l’étude des trajectoires les plus pertinentes, réaliser un plan de risques, entreprendre des projets à forte valeur ajoutée et participer à une meilleure gouvernance.

La solution est un outil collaboratif, avec un référentiel maître qui pourrait aller récupérer des données dans d’autres systèmes. C’est ce que propose Obeo SmartEA avec ses connecteurs.

La plateforme web sécurisée d’Obeo SmartEA
pour la collaboration

Loin des logiciels très chers (BOC Group ADOIT, MEGA HOPEX, LeanIX, Bizzdesign…) réservés aux grands groupes, nous avons mis à l’épreuve la plupart des outils d’AE open source ou à faible coût, avec comme objectif de cibler les organisations à budget restreint pour ce type d’outils ou encore le monde de l’éducation (voir nos tests en annexe). Nous avons constaté que :

-  soit il existe une véritable gestion d’un référentiel d’objets et d’artefacts accessible en local ou nécessitant une installation complexe pour le rendre partageable (Archimatetool),

- soit on nous propose une collaboration à la manière de Google (Visual Paradigm Online) pour dessiner des modèles, mais avec une absence totale de référentiel d’entreprise.

Déjà évoqué dans plusieurs de nos articles (voir annexe), seul Sparx Systems propose une déclinaison de son produit Enterprise Architect à prix modéré selon les fonctionnalités. Il offre toutes les fonctionnalités des produits bien plus onéreux, y compris la collaboration entre les acteurs de l’AE .

Après tout, ce ne sont que les enjeux basiques de l’AE, mais pour parvenir à ses fins, encore faut-il un outil qui s’appuie sur un référentiel partagé accessible, en fonction des profils utilisateurs, de manière concurrente et sécurisée et qui doit historiser les changements.

Vous voulez accentuer la collaboration entre tous les acteurs : utilisez une plateforme web sécurisée ! De plus, l’outil doit se conformer au standard en vigueur aujourd’hui, soit ArchiMate de l’Open Group, tout en étant personnalisable avec parcimonie en proposant des APIs ouvertes offrant la possibilité d’utiliser des notations plus spécifiques, comme BPMN pour les processus métier ou vos propres métamodèles.

Obeo, éditeur français, a bien compris les enjeux d’un tel type de logiciel et propose SmartEA, un outil sous licence commerciale intégrant ces fonctionnalités. Comme son concurrent direct Enterprise Architect de Sparx Systems, le référentiel est accessible via un client web permettant le partage des informations et un modeleur basé sur une plateforme Eclipse à installer localement pour peupler et manipuler les différents éléments du référentiel, en vue d'élaborer des scénarios et des trajectoires de transformation.

Ces pages web peuvent être transmises via des URL aux membres de l’organisation dûment habilités. Sinon, on peut les télécharger sous forme d’images haute résolution.

Un acteur dûment authentifié peut accéder via une URL au référentiel. Ses actions sont fonction des autorisations que lui a octroyées l’administrateur. Vue basée sur le pattern “Goal Realization Viewpoint” de la spécification ArchiMate. Les buts sont réalisés par un Résultat qui est réalisé par un Principe qui se comporte comme une exigence plus abstraite et plus large. Enfin le Principe est matérialisé par une Exigence indiquant des propriétés spécifiques que le système doit présenter.

Une granularité fine du verrouillage des artefacts
pour une résolution de conflits performante

Une base de données ou un moniteur de multithreading posent des verrous sur les objets modifiés : Obeo SmartEA va procéder de la même manière. La granularité des parties bloquées est très fine. Une fois les modifications sauvegardées, elles sont propagées automatiquement vers l’ensemble des utilisateurs qui seront libres d’apporter des mises à jour.

L'architecte d'entreprise vient de modifier un élément "Principe" de la vue "Motivation".
Un cadenas vert signalant le verrouillage apparaîtra tant que la sauvegarde ne sera pas effectuée.

Exemple d'un utilisateur voulant modifier un élément "Make" (Logiciel Système),
verrouillé par un autre utilisateur. 

Le tableau de bord de l’Architecte d’Entreprise

Si un transfert d’objets de modélisation dans le sens top-down était possible, on serait confronté aux problèmes du niveau de maturité et des pratiques des utilisateurs (niveau des macro-exigences, normalisation des noms, approche Domain-Driven Design…).

Seul un transfert bottom-up doit être autorisé. Sur demande, l’outil gérant le référentiel maître ira recueillir des informations éparpillées dans des systèmes hétérogènes, utilisés par exemple par les architectes applicatifs. L’architecte d’entreprise décidera de la suite à donner aux artefacts et actions remontées, par exemple doit-il les valider ou les rejeter.

Pour le suivi des états des objets composant la cartographie de l’entreprise, Obeo SmartEA met à la disposition de l’architecte des widgets graphiques personnalisables et regroupés dans un tableau de bord. L’enjeu est de disposer un outil de pilotage du projet avec la démarche TOGAF.

Exemple de tableau de bord montrant ce qui est à faire et ce qui est réalisé.
Ici, 4 applicatifs sont déjà validés et le modèle d’architecture ne comporte aucun lien interapplicatif.  

Importation des modèles d’Obeo ISD réalisés
par les architectes applicatifs dans Obeo SmartEA

Dans le cas où les architectes logiciels et techniques utiliseraient l’outil open source d’Obeo ISD (Information System Designer), les artefacts modélisés (voir nos articles en annexe) doivent être importés en vue de la consolidation du référentiel maître d’Obeo SmartEA. 

Concrètement, Obeo SmartEA possède un connecteur Java unidirectionnel et paramétrable qui gère les ajouts, les modifications et les suppressions de ISD vers son référentiel. 

Une fois lancé le connecteur, le référentiel centralisé et partageable d’Obeo SmartEA est mis à jour. L’architecte d’entreprise dispose d’une vue synoptique au travers de son tableau de bord.
ll devra étudier 146 applicatifs et 3 liens interapplicatifs, pour décider s’il les valide ou les rejette.

Mais Obeo SmartEA peut aussi récupérer des modèles réalisés par d’autres outils, comme celui de Sparx Systems

Obeo SmartEA fournit des APIs ouvertes pour créer des connecteurs vers des ressources externes et notamment vers son concurrent direct Sparx Systems Enterprise Architect.

Notez les connecteurs qui importent des données de fichiers Excel et de Sparx EA (Enterprise Architect)

Alimenter automatiquement le référentiel
à partir d’import de données

Exemple d’un fichier Excel fourni par l’équipe infrastructure, représentant les échanges entre les applications et les interfaces au travers desquelles elles communiquent. 

Pour analyser ce fichier et remonter les informations, Obeo a développé un connecteur que l’on peut lancer depuis la page des traitements (voir paragraphe précédent).

Le composant applicatif "Système suivi de satisfaction client" communique avec le composant "CRM" par l'intermédiaire de l'interface "Web Service CRM" comme spécifié dans le tableau Excel.
De même, un autre lien a été créé avec le composant "Système de fidélité" qui utilise l'interface
"Rapport XLS de suivi de satisfaction" du composant "Système suivi de satisfaction client".   

Conclusion

Voici un outil mettant en œuvre un référentiel centralisé et collaboratif TOGAF. Les éléments de modélisation font partie des standards du marché, à savoir ArchiMate et BPMN. Des APIs ouvertes permettent d’intégrer d’autres notations standards comme UML ou des DSL spécifiques.

Toutes les parties prenantes de l’entreprise peuvent accéder aux différentes vues d’architecture via un simple navigateur web. Le concept de prisme permet d’octroyer des authentifications et des autorisations en fonction des rôles des utilisateurs. Le système de gestion de conflits optimisé, pour ne verrouiller que la donnée en cours de modification, permet des accès rapides.

Enfin, des connecteurs offrent la possibilité de récupérer des données, en provenance par exemple des architectes logiciels utilisant Obeo ISD ou Sparx Systems Enterprise Architect ou de la MOA à partir de tableaux Excel.

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

"Qu'est-ce que je serais heureux, si j'étais heureux".

Woody Allen

Annexe : nos tests

• Quel outil ArchiMate pour modéliser vos architectures d’entreprise sources et cibles, évaluer les écarts, analyser les impacts et élaborer des trajectoires de transformation ? Obeo SmartEA S.1 Ep.1
    
• Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
    
• Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
    
• Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3
    
• Quelle solution pour concevoir la modélisation d’une architecture micro-services, l’intégrer dans une architecture d’entreprise et permettre une collaboration avec l’ensemble des acteurs projet ? Obeo ISD S.1 Ep.4
    
• Vous cherchez un outil pour gérer le mapping entre les objets métier et une base de données relationnelle, générer les scripts SQL et produire du code à partir de vos modèles ? Obeo ISD S.1 Ep.5
    
• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information
    
• Modelio
    
• Visual Paradigm (online)
    
• ADOIT : CE (BOC Group) et ADOIT : CE (compléments d’information)
    
• Archi (archimatetool)
    
• GenMyModel
    
• Camunda 
    
• Papyrus
    
• Eclipse Modeling Tools
    
• diagrams.net ou draw.io
    
• Texte vers UML et autres outils de "diagrammes en tant que code"
    
• Enterprise Architect
    
• WinDesign
    
• Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants
    
• Les meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont…

En phase E "Opportunités et Solutions" de l'ADM TOGAF, Aya Dupuis, architecte d’entreprise, doit générer la feuille de route d'architecture, avec une analyse des écarts entre l'architecture de base et les composants candidats de la cible. Une bonne manière d'étudier et de synchroniser différentes solutions est d'utiliser un système de gestion de branches : c'est ce que propose l'éditeur français Obeo avec son outil SmartEA. 

Un acteur dûment authentifié peut accéder, via une URL, aux artefacts du référentiel d'AE.
Ses actions sont fonction des autorisations (prisme dans la terminologie Obeo SmartEA)
qui lui sont octroyées. Ici, Raphaël David, le DSI, visualise les écarts entre une solution commerciale
et une solution interne sur mesure.

Intégration de l'IA : développement sur mesure ou
solution commerciale augmentée avec des modules d'IA ?

La DG de l'institution de prévoyance ABIP doit tenir compte des menaces des pure players intégrant d’emblée l’IA dans tous leurs processus métier. Pour ne pas se laisser distancer par la concurrence et maintenir des tarifs constants, elle doit diminuer ses coûts de développement et d’exploitation.

Pour contribuer à l’atteinte de ces objectifs, il a été décidé en comité de direction, d’intégrer l'IA générative. L'exigence retenue portera sur l'automatisation complète du processus de ranking des mails pour la Relation Client, qui a mauvaise presse et qui doit redorer son blason.

Deux solutions seront à l’étude : un développement sur mesure et une solution commerciale augmentée avec des modules d’IA.

Pour que les différents acteurs puissent collaborer à ces solutions en ayant accès au référentiel partagé d'entreprise, Aya Dupuis a mis en place l’outil Obeo SmartEA associé à Obeo Information System Designer (ISD), outil open source destiné aux architectes techniques et aux concepteurs-développeurs (voir en annexe nos articles sur ISD). 

Comment travailler sur différentes versions
d’une même architecture ?

Pour ne pas se faire disrupter, une entreprise est fréquemment obligée d'innover en adaptant ses processus métier. Pour conserver l’alignement avec le Système d’Information, les architectes doivent proposer différentes branches du référentiel d’Architecture d’Entreprise. La validation d’une transformation passera par la mesure des écarts et une étude d’impacts dus aux changements.

Le meilleur moyen de gérer différentes implémentations possibles d’un même système repose sur les technologies de gestion de branches, comme on en trouve dans le framework open source Git, très populaire dans le monde du développement.

Les normes et standards de modélisation graphiques ont prévu une équivalence textuelle (voir en annexe notre article consacré aux diagrammes en tant que code). Aujourd'hui, la grande majorité des outils stockent leurs modèles dans des fichiers texte utilisant des formats exploitables, comme XML ou JSON.

Ainsi, en intégrant un système basé sur un logiciel comme Git, différents acteurs comme l’architecte d'Entreprise, l’architecte Solutions, l'architecte technique, l’expert métier… pourront accéder aux différentes branches du référentiel.

Il est possible d'avoir plusieurs versions d'un même système
qui pourront converger vers la version courante si certaines conditions sont réunies. 

Obeo SmartEA, un outil branché !

Obeo SmartEA implémente un tel système et offre donc un mécanisme de branches permettant de gérer différentes évolutions de l'Architecture d'Entreprise à l'étude, mais pas encore validées, qui pourront être fusionnées ultérieurement dans la branche principale (master) du référentiel. 

Ainsi, chaque branche donne la possibilité de modifier une version donnée de l’architecture sans impacter les autres versions. Par exemple, la branche principale peut représenter l'état courant validé de l’architecture. Les autres branches, elles, peuvent servir à travailler sur des architectures cibles et, potentiellement, sur des architectures intermédiaires.

De cette façon, il est possible à tout moment de simuler puis de valider des transformations et des évolutions du référentiel, sans perturber la branche principale.

Créez une branche

Un conseil si vous envisagez différentes évolutions d’un modèle : essayez de prévoir, dans la branche source, une disposition de vos éléments qui permettra de mettre en valeur les changements. 

Pour créer une nouvelle branche, vous devez choisir une branche source. Dans notre exemple, il s'agit de partir de l'état courant du référentiel (branche master). 

Aperçu de la strate Motivation de la branche master du référentiel d'AE.

La procédure de création est immédiate : il faut indiquer la branche source et saisir le nom de la nouvelle branche cible.

Vous récupérez ainsi dans la nouvelle branche le référentiel complet de la branche source. Vous avez alors la possibilité d'apporter toutes les évolutions que vous souhaitez.

Nouvelle branche (IA-RPA-No Code), créée à partir de la branche master modélisant,
au centre, les principes d’utilisation de l'IA générative, du RPA et du No Code
avec l’exigence, à droite, “Prioriser les messages clients”.

Analysez les écarts

Obeo SmartEA vous permet très facilement de visualiser les écarts : il suffit de dérouler le menu "Branche", qui se trouve à côté des menus Projet et Prisme.

Lancez l'analyse en sélectionnant "Analyse d’écarts", puis indiquez les deux branches à comparer et cliquez sur "Analyser".

Il est possible de répercuter les différences de la cible sur la source en sélectionnant "Synchroniser".

On retrouve dans la vue Motivation de la version à l'étude (IA-RPA-No Code)
les 3 principes et l'exigence supplémentaires (+ vert) par rapport à la version courante. 

Zoom sur les différences entre la version à l'étude (à gauche) incluant l'IA, RPA et le No Code
et l'exigence "Prioriser les messages clients" et la version de base (à droite). 

Automatisation de la priorisation des messages
de la Relation Client : ChatGPT vs Salesforce

Le besoin est d'étudier les impacts d'un premier scénario consistant à réaliser l'exigence "Prioriser les messages clients" par un développement interne utilisant les API ChatGPT, le workflow No Code Make et la plateforme de développement No code HubSpot et un deuxième scénario utilisant des modules de la solution commerciale Salesforce intégrant de l'IA en environnement cloud. 

Aya Dupuis a créé deux nouvelles branches à partir de la branche IA (IA-RPA-No Code). Elles contiennent toutes les deux la même exigence à réaliser et se distinguent par leurs modèles ArchiMate représentant les diagrammes de mesure d'impacts des deux scénarios précédents.

Scénario #1 : l'association API ChatGPT avec le workflow No Code Make
et la plateforme de développent No Code HubSpot

Scénario 1 : création de la branche "chatgpt-make-hubspot".

Ici, un diagramme d'impacts montrant les composants applicatifs réalisant l'exigence.
Suivant les 3 principes liés à l'exigence (voir précédemment la branche IA), ils doivent utiliser
des logiciels No Code, du workflow (RPA) et de l'IA générative. Les technologies choisies sont :
la plateforme de développement No Code HubSpot pour les fonctionnalités sur mesure du CRM,
le workflow No Code Make et les appels aux API ChatGPT pour l'IA générative.

Scénario #2 : Salesforce Cloud 

Scénario 2 : création de la branche "Salesforce".

Ici, un diagramme d'impacts montrant le composant applicatif réalisant l'exigence.
Les modules "Commerce Cloud" et "Service Cloud" de la solution commerciale Salesforce remplissent
bien les principes d'intégrer de l'IA, de Robotic Process Automation et  sont bien évidemment No Code !

Pour contribuer à la réalisation de l'exigence, chaque intervenant pourra accéder par exemple aux différences entre les deux scénarios, en lançant une analyse d'écarts.

Exemple : liste des écarts entre la solution ChatGPT + Make + HubSpot en développement interne
et la solution commerciale Salesforce.

Exemple : zoom sur le diagramme d'impacts, à gauche, de la solution ChatGPT + Make + HubSpot
en développement interne et, à droite, de la solution commerciale Salesforce.

Et réciproquement.

Vue inverse : liste des écarts entre la solution commerciale Salesforce
et la solution ChatGPT, Make et HubSpot en développement interne.

Vue inverse : zoom sur le diagramme d'impacts, à gauche, de la solution commerciale Salesforce
et, à droite, la solution ChatGPT + Make + HubSpot en développement interne.

La vue technologique de l’automatisation
de la priorisation des messages client

Chaque branche va pouvoir se développer en fonction de la collaboration de chacun des intervenants. Par exemple, Ethan Dubois, l'architecte applicatif, a pu accéder à la branche solution interne (chatgpt-make-hubspot) et cartographier les échanges entre les applications. 

 
Pour diminuer les coûts de développement, l’outil No Code HubSpot a été sélectionné. Grâce à cette plateforme, un composant de CRM avec des fonctionnalités sur mesure pourra être développé à moindre frais.

Après récupération des mails clients dans ce composant CRM, l’outil No Code de workflow Make enverra une requête à l’API de ChatGPT avec un prompt. Conçu par un "prompt engineer", il contiendra à la fois le message et les critères de priorisation formalisés par les experts métier. Ainsi, ChatGPT analysera le message et le classera par degré de priorité.

Ensuite, l’outil d’automatisation de process Make viendra récupérer la réponse et y ajoutera des étiquettes pour le ranking, avant de retourner l’ensemble en utilisant le composant CRM.

Aperçu d'une vue ArchiMate appartenant à la branche solution interne
et montrant les flux entre les composants applicatifs.

Répercutez la solution validée
sur la banche master de l'architecture de base

Les branches vont se développer par l'apport des différents intervenants. Une analyse des risques de chaque branche et ensuite une analyse comparative des charges de travail et des coûts permettront au comité de direction de trancher. Aya Dupuis devra alors synchroniser la branche master avec les différences de la branche validée.

Les pictogrammes surlignés permettent de sélectionner finement
les changements (à droite) à répercuter ou non sur la branche master (à gauche).

Conclusion

La phase E "Opportunités et Solutions" de l'ADM TOGAF prend en compte l'ensemble des écarts entre les architectures cible et de base dans tous les domaines d'architecture et regroupe logiquement les modifications en lots de travaux. Il s'agit d'un effort visant à élaborer une feuille de route la mieux adaptée.

Pour pouvoir gérer efficacement les exigences des parties prenantes, les opportunités, les solutions et les contraintes de mise en œuvre identifiées, Obeo SmartEA propose un référentiel collaboratif supportant un système de gestion de branches emprunté aux logiciels de versioning.

Chaque acteur peut apporter sa pierre à l'édifice en mesurant les écarts et les impacts des différentes solutions.

Après validation d'une solution en comité de direction, l'architecte d'entreprise pourra mettre à jour l'architecture de base en synchronisant la branche correspondante avec celle du scénario validé. 

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

“Le vieux monde se meurt, le nouveau monde tarde à apparaître
et dans ce clair-obscur surgissent les monstres.”

Antonio Gramsci

L’atelier Entity d’Obeo Information System Designer (ISD) va vous permettre de modéliser vos entités métier. Avec l’autre atelier Database, vous pourrez modéliser votre base de données relationnelle, générer des scripts SQL, rétromodéliser des bases existantes, gérer des Modèles Logiques de Données (MLD) et des Modèles Physiques de Données (MPD).

Et grâce aux deux, vous serez assuré de la synchronisation efficiente entre vos objets métier et votre base SQL. ISD a plus d’un tour dans son sac avec ses nombreux frameworks qui vous permettront de générer une partie du code de votre application, à partir de vos modèles de conception et d'analyse.

Vous créez votre modèle d'entités persistantes, puis, à partir de ce modèle, ISD va générer le MLD ;
vous lui indiquez votre moteur SQL, ISD génère le MPD, puis les scripts correspondants
et enfin vous les exécutez directement dans ISD.

Résumé des épisodes précédents

Nos 4 précédents articles détaillent toutes les étapes, depuis l'analyse du besoin
jusqu'à la conception d'une architecture micro-services.

Les différents modeleurs et leurs fonctions

• Épisode 1 : présentation des fonctionnalités et installation d’ISD. 
   
  A lire > Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
   
• Épisode 2 : l’atelier Graal de modélisation des acteurs, des use cases, des tâches, des enchaînements d’actions, des diagrammes de séquence et de machine à états.
   
  A lire > Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
   
• Épisode 3 : l'atelier Graal de gestion des User Stories, l’atelier Requirement pour gérer le référentiel des exigences et leur traçabilité, l’atelier Cinematic pour la modélisation des maquettes et la cinématique des écrans 
   
  A lire > Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3
   
• Épisode 4 : l’atelier SOA pour modéliser des API (REST ou SOAP) avec leurs composants applicatifs micro-services ou Web Services, leurs interfaces de communications, leurs relations, leurs opérations avec les données échangées (DTO), pour générer des documents OpenAPI et pour rétromodéliser des interfaces REST.
   
  A lire > Quelle solution pour concevoir la modélisation d’une architecture micro-services, l’intégrer dans une architecture d’entreprise et permettre une collaboration avec l’ensemble des acteurs projet ? Obeo ISD S.1 Ep.4

Créez des entités persistantes

Jouez la partition

En préambule, quelques mises au point sur la terminologie d’ISD :

• les Domain classes représentent les entités métier définies par les experts métier et modélisées par les business analysts avec la méthode Graal,
   
• les Entities correspondent aux classes persistantes gérées par un ORM (Object Relational Mapping) offrant la dualité objet/relationnel SQL.
   
• les DTO, créés à partir des attributs des Entities, représentent les données échangées entre les services dans une SOA.

Un diagramme Entities Namespaces Hierarchy est créé dans le conteneur de l'Entity Model.
Le NoUML de modélisation d’Obeo ISD est en fait un DSL (Domain-Specific Language), dans lequel le package UML est renommé namespace, avec un nombre restreint de relations.

De manière similaire à la vue Domain Classes Namespaces Hierarchy du modèle Graal ou celle DTO Namespaces Hierarchy, il faut créer au préalable au moins un namespace : 

• File ou clic droit sur votre Modeling Project > New > Other > IS Designer > Entity Model

Les pictos en bas à droite des namespaces indiquent qu’en double-cliquant,
on peut accéder au diagramme d’entités.

Ce diagramme permet de modéliser les classes, qu'elles soient internes ou externes au namespace. S’il existe des relations entre des classes appartenant à des namespaces différents, alors ISD génère automatiquement les relations dans le diagramme des namespaces.

• Une fois le namespace créé, le sélectionner via le menu contextuel > New Representation > Entities Diagram

On retrouve exactement le même type de diagramme que les Domain Classes ou les DTO,
sauf que cette fois-ci les classes sont stéréotypées Entity.

ISD supporte les visions entités persistantes vers DTO ou bien l’inverse. Dans le diagramme d’entités, on a Entity from DTO et dans celui des DTO on a DTO from Entity.

Ce choix est judicieux, car il permet une souplesse de conception bidirectionnelle qui se présente souvent dans un contexte agile, où l’on doit ajouter des données, soit dans les entités persistantes et les répercuter dans les DTO, soit l’inverse.

Un bémol à la clé

Par contre, il est impossible de récupérer les classes métier (Domain Classes) modélisées dans le modèle Graal de l’analyse. Dommage, car en pratique la plupart des entités persistantes proviennent des classes participantes ou métier !
 
Il nous a été impossible de créer une relation entre une entité et une énumération, on a donc créé à la place un attribut du type énumération.

En choisissant de générer toutes les entités à partir de nos DTO, nous avons constaté que : 
Les liens d’héritage ne sont pas repris, bien que l’on ait sélectionné toutes les relations à importer, mais les attributs sont dupliqués dans l’entité héritière.
Les énumérations n'apparaissent pas, bien qu’un attribut d’une entité soit de type énumération.

Ajoutez à vos entités persistantes
les informations spécifiques à la base SQL 

Préparez la correspondance de vos entités persistantes
avec les noms des colonnes, type, taille, unicité, index...

La vue Entities Physical Names est un tableau qui reprend en lignes toutes les entités définies précédemment et permet dans les colonnes d’ajouter les informations spécifiques à la base de données, comme le nom physique d'une colonne, la taille, les contraintes de vérification, les contraintes d’unicité, la valeur par défaut, le choix des schémas pour les tables intermédiaires.

Par exemple, sur un attribut indexé, on peut mettre dans la colonne Unique ASC pour ascendant ou DESC pour descendant.
Pour une contrainte d’unicité portant sur plusieurs champs, on doit adopter un langage spécial (sur l’entité et non plus sur l’attribut, dans la colonne Unique, on doit saisir champ1:ASC,champ2,champ3,etc. avec éventuellement un | pour séparer des index différents).

Il est impossible de saisir dans les colonnes Name, etc. les attributs des entités créées à partir des DTO. Par contre, si nous ajoutons une nouvelle entité avec des attributs, elle se retrouve bien dans le tableau et nous pouvons bien saisir dans les colonnes des attributs.

Générez automatiquement le modèle logique
de données (MLD) à partir du modèle Entités

Construisez l'échafaudage de votre architecture :
le système de génération Scaffolding d'ISD

• Menu File ou clic droit sur votre Modeling Project > New > Other > IS Designer > Database Model > Laissez toutes les valeurs par défaut (Data Base, Logical Types et UTF-8)

Un diagramme de schéma logique de base de données, encore appelé MLD (Modèle Logique de Données) pour les nostalgiques de la méthode Merise, est créé, dans lequel on peut modéliser des tables, vues, colonnes, clés primaires et étrangères, des séquences, des index… 

Le système Scaffolding d’ISD permet de transformer des modèles, suivant les concepts MDA (Model Driven Architecture) de l’OMG. 

A lire > nos articles dans la catégorie : Ingénierie Dirigée par les Modèles (IDM)

Après avoir modélisé vos entités persistantes et défini les propriétés physiques (nom de table, taille…) avec l’atelier Entities, vous pouvez générer vos tables dans le diagramme de schéma pour une base de données relationnelle (MLD), pour l’instant vide, grâce au système Scaffolding Entity to Logical database d’ISD.

• Sélectionnez à la fois, en maintenant la touche Ctrl enfoncée, le conteneur (Entities) sous la vue (.entity) et le conteneur Data Base sous la vue (.database) > clic droit > IS Designer > Scaffolding > Entity to Logical database (remarque : on dispose aussi de l’option inverse) > les schémas générés à partir des namespaces du modèle Entities apparaissent : 

Dans le schéma logique de base PrevIT, 3 sous-namespaces sont créés correspondant
aux 3 contextes métier (Domain Driven Design) Prestation, Personne et Contrat.

Pour avoir le détail, double-cliquez sur un schéma : 

On retrouve les concepts des bases de données relationnelles, avec les clés primaires, étrangères,
les contraintes de check (triangle sur les tables), etc. Vous pouvez réorganiser les colonnes.

Le MLD est bien créé à partir du modèle entities. Des colonnes de pistes d'audit ont été ajoutées par le générateur d'ISD comme PRESTATION_XTOPSUP (Indicateur pour savoir si l'enregistrement est valide) et PRESTATION_XDMAJ (Date de mise à jour de la ligne). La table SURVENANCE est en relation avec la table PERSONNE dans le schéma PERSONNE et avec la table CONTRAT dans le schéma CONTRAT.

Pour la génération de l'héritage, l'échafaudage est bancal

Les bases de données relationnelles n'ont pas de moyen simple de mapper les hiérarchies de classes sur les tables de base de données. Pour résoudre ce problème, plusieurs stratégies existent :

• MappedSuperclass - les classes parentes ne peuvent pas être des entités,
   
• Table unique – Les entités de différentes classes ayant un ancêtre commun sont placées dans une seule table,
   
• Table jointe - Chaque classe a sa table, et interroger une entité de sous-classe nécessite de joindre les tables,
   
• Table par classe - Toutes les propriétés d'une classe sont dans sa table, donc aucune jointure n'est requise.

La stratégie d’héritage choisie est celle d’une table par classe. Cette stratégie mappe donc chaque entité à sa table, qui contient toutes les propriétés de l'entité, y compris celles héritées.

3 tables ont bien été générées. Seule la table PERSONNE_MORALE est correcte compte tenu des relations d'héritage modélisées dans le diagramme Entities. En effet, les colonnes NUMERO et COORDONNES héritées sont bien présentes, en plus du SIRET spécifique à la table.

Dans le modèle des entités persistantes (partie supérieure de l'illustration), PersonnePhysique et PersonneMorale héritent des attributs numero et coodonnees de Personne. Dans le schéma généré (partie inférieure de l'illustration), on constate que coordonnees n’apparaît pas dans la table PERSONNE, ni dans la table PERSONNE_PHYSIQUE, alors que bizarrement elle est bien présente dans la table PERSONNE_MORALE. Auparavant, nous avons bien pris soin de spécifier la colonne coordonnees dans le tableau Entities Physical Names du modèle Entities, avec une taille de 100.

Autre bizarrerie, la colonne NUMERO de la table PERSONNE et PERSONNE_MORALE apparait bien, conformément à la stratégie d’implémentation de l’héritage, mais pas dans la table PERSONNE_PHYSIQUE !

Dans le tableau Entities Physical Names du modèle Entities, permettant de configurer le MLD qui va être généré, à l'attribut coordonnees de la classe Personne, on a fait correspondre la colonne du même nom avec une taille 100, qui pourtant n'apparaît pas dans la table PERSONNE.

Gestion des modifications

Si l’on fait d’autres modifications, et que l’on refait l’opération de scaffolding, ISD propose de créer une nouvelle version ou d’écraser l’ancienne.

• Par exemple, on modifie le nom du schéma, il suffit de sélectionner le conteneur .scaffold sous le répertoire scaffold > IS Designer > Scaffold > Entity to Logical database. Un nouveau schéma EB apparaît, on crée un nouveau diagramme (New representation > nouveau nom Schema) et l’on retrouve un nouveau MLD avec en préfixe le nom du nouveau schéma.

Générez automatiquement
le Modèle Physique de Données (MPD)

Prenons MySQL comme RDBMS de test.

Créez tout d’abord un schéma (database) vide dans MySQL, par exemple previtDB_testISD, puis dans ISD, menu File > Import > Database > Import Database > saisissez les informations de connexion à votre database MySQL :

Remarque importante : dans le champ New model file, vous devez saisir
un modèle de database inexistant, par exemple Previt_MPD_MySQL8.database

Générez le MPD avec le système de scaffolding d’ISD, en procédant de la même manière que pour générer le MLD à partir des entités :

• Sélectionnez simultanément votre MLD (Data Base My) et votre MPD vide, que vous venez de créer (Data Base previtDB_testISD)

A partir de votre MLD généré précédemment, le système Scaffolding d'ISD va générer
votre MPD nouvellement créé et qui pointe sur votre database vide MySQL.

• Menu contextuel sur le MPD > IS Designer > Scaffolding > Logical database to Physical database (on dispose aussi du reverse engineering Physical database to Logical database).

Le MPD est créé avec les 4 schémas MySQL correspondants aux 4 namespaces : le namespace previtDB_testISD correspondant au namespace de base et PRESTATION, PERSONNE et CONTRAT correspondant aux 3 sous-namespaces.

Générez les scripts SQL

Sur le conteneur Previt_MPD_MySQL8.database, on peut générer les scripts SQL :  

• Menu contextuel > IS designer > Generate SQL Scripts, un répertoire sql est créé, comportant 4 scripts pour les créations de contraintes, de clés étrangères, d'index et de tables et un script complet rassemblant les 4 précédents.
  

On trouve les scripts SQL correspondant au MPD. Ces scripts SQL devront être exécutés manuellement.

Exécutez les scripts SQL directement dans la base

Le générateur Liquibase permet d’exécuter directement des scripts dans la base.

• Sur le conteneur MySQLtest2.database, on peut générer les scripts SQL :  
  Menu contextuel > IS designer > Generate Liquibase changelog

Un répertoire liquibase est créé, contenant un fichier de propriété, permettant de configurer les accès à la base de données, et un fichier XML contenant les propriétés sous forme de balises avec les instructions SQL qui seront envoyées à la base par liquibase.

Vous devez valoriser les variables du fichier liquidbase.properties (<hostname>…).

Au lieu de configurer le fichier de propriétés liquibase, il existe une manière plus facile en utilisant le fichier run.changelog.xml : 

• menu contextuel sur le fichier run.changelog.xml > Liquibase > Apply changing > saisir l’URL (jdbc:mysql://localhost:3306/previtDB_testISD), le user et le password 

A ce moment, liquibase va se connecter directement et exécuter le fichier XML.

Nous avons rencontré 2 types d’exceptions : 

• la 1re concernait l’impossibilité dans le fichier run.changelog.xml, de prendre en charge la propriété : column autoIncrement="true". Nous avons remplacé partout true par false,
   
• la 2e disait que les schémas (database) CONTRAT, PERSONNE et PRESTATION n’existaient pas. Effectivement, comme nous avions créé 3 sous-namespaces dans le namespace de base, 3 schémas ont été créés dans ISD, il faut donc naturellement les créer dans MySQL (dans notre cas MariaDB, compatible MySQL).

Extrait de la vérification de l'exécution des scripts SQL dans la console de la base de données.

Vous pouvez analyser les changements apportés grâce à l’historique : 

• Menu contextuel sur le conteneur MLD .database > Compare With > Local History 

Exemple d'utilisation de l'historique.

Rétromodélisation et intégration de l’existant

Capacité à se connecter au format OpenAPI, en import, mais aussi en export.
Liquibase permet de piloter les schémas d’une base de données
à partir d’un diagramme de classes de conception.

On peut exporter et générer des previews avec SwaggerUI. Voir les copies d’écran dans la documentation github.

Génération documentaire

M2Doc généré à partir d’un template variabilisé.
La valorisation se fait à partir des modèles créés dans ISD.

Le Graal de l’agilité : générer une application directement à partir des modèles et de manière bidirectionnelle

La génération de code est basée sur des templates. Voir un exemple de template Acceleo en annexe 1.

Avec ISD, le processus est simple : vous modélisez la conception, puis vous générez le code. Vous pouvez modifier le code que vous avez généré. Si vous modifiez la conception, votre code est conservé. Le concept de génération se fait en round-trip, c’est-à-dire que l’on peut intégrer les parties de codes réalisées par les concepteurs/développeurs. 

Plus on remonte dans les couches de l'architecture, moins on pourra générer de code. 

Ainsi, 80 % du code backend peuvent être générés. Par exemple, 100 % des entités seront générés et plus de 50 % pour le métier. La couche de persistance est entièrement créée par le générateur d’ISD, auquel Obeo a ajouté les tests unitaires, ce qui n’est pas le cas des ORM classiques.

Les 20 % restants concernent les écrans laissés aux spécialistes frontend et certaines parties métier, comme des règles métier ou les machines à états, car les développeurs séniors produiront un code plus efficient.

Toute la partie architecture est sécurisée, car elle est mise en place par le générateur.

ISD utilise plusieurs générateurs de code open source, comme Acceleo de la fondation Eclipse et PACMAN du Ministère des Armées de la France.

A lire > Les générateurs de codes Acceleo et PACMAN

La mise en œuvre de ces outils passera souvent par les services payants d'Obeo. 

Ne vous enthousiasmez pas trop vite, à moins d'avoir une connaissance approfondie des techniques de génération de code, l'utilisation efficiente de ces générateurs demandera l'aide d'experts.

Obeo vous propose toute une série de modeleurs gratuits pour la partie analyse et modélisation de votre application. Si la fourniture des générateurs de code l’est aussi, leur utilisation reste extrêmement complexe. Obeo peut alors vous proposer, moyennant finance, un accompagnement. Il en va de même pour la maintenance et le support d’ISD. 

Travail collaboratif avec l’extension payante
Obeo Designer Team

Pour le travail collaboratif, là encore il faudra mettre la main au porte-monnaie. En effet Obeo Designer Team est une extension commerciale, non-open source, permettant de partager des modèles, à la manière Google Doc.

Conclusion

Le couple de frameworks Sirius & Acceleo permet à ISD de produire
le code correspondant aux modèles de conception.

Les éloges

ISD d’Obeo est indubitablement un outil basé sur la collaboration de toutes les parties prenantes d’un projet de réalisation d’une application. 
Avec ses différents ateliers, ISD vous aidera dans l’élaboration de la phase d’analyse (atelier Graal). Le cadre apporté par la méthode Graal vous facilitera la formalisation des use cases, avec les enchaînements d’actions, l’intégration des user stories, le modèle métier de vos données et la mise en place du référentiel d’exigences. L’atelier Cinematic vous permettra de concrétiser les scénarios des use cases, en maquettant les écrans et en planifiant la navigation. L’atelier SOA vous permettra d’élaborer votre architecture distribuée à base de micro-services ou de services web. Avec l’atelier Entity, vous définirez, parmi vos classes métier et DTO, lesquels doivent être persistants.

Les déceptions

Après avoir fait du NoUML, il est étrange qu’ISD ne supporte pas le NoSQL, comme (MongoDB, Cassandra…). 

Nous regrettons aussi que le modeleur SOA Designer ne couvre que le type d’exposition REST. SOAP n’est disponible dans le studio qu’à titre indicatif, aucun outillage spécifique n’ayant été développé pour l’exploiter. Que vous utilisiez l'approche top-down, concevoir le contrat WSDL (Web Services Description Language), puis, à partir de celui-ci, faire générer le code ou l'approche inverse bottom-up, il vous faudra vous tourner vers les frameworks open source conventionnels du marché en fonction de votre langage de programmation. Autre solution, demander à Obeo, d'implémenter cette fonctionnalité, qui sera alors payante.

Open source oui, closed pour le reste.

A notre avis, l’atelier Database, qui génère les schémas logiques de base SQL, les scripts SQL et qui les exécute, ne présente que peu d'intérêt, car la plupart des technologies, Java, Python… possédant déjà des frameworks de synchronisation bidirectionnels entre les objets et le moyen de persistance, quelque soit son paradigme : SQL, NoSQL, voire XML.

Y a-t-il encore un intérêt pour les outils de génération de code
face à l'IA générative comme ChatGPT ?

La génération de code utilise des paradigmes comme MDA et des frameworks comme Acceleo, qui sont déjà anciens et qui semblent quelque peu désuets face à la puissance, la facilité et l’expansion phénoménale des nouvelles IA génératives (OpenAI ChatGPT, Microsoft Bing Chat, Google Bard ou encore Meta Llama, Anthropic Claude pour les plus connues). 

Quelles sont leurs places dans le domaine de l’Architecture d’Entreprise, de l’Architecture Logicielle et la modélisation de système ? C’est l’étude que nous allons effectuer et que nous vous livrerons dans nos articles à venir.

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

« Je me suis un peu amusée à tester ces nouveaux outils et ce que je trouve très intéressant, c’est que pour utiliser l’IA dans la phase de recherche et de documentation, il faut entrer des mots. Ça nous force quelque part à mettre des mots dès le départ sur une intention créative. C’est très utile pour formaliser et conceptualiser des idées. » 
Adèle Hennion

Obeo Information System Designer (ISD) offre aux architectes logiciel la possibilité de maîtriser leur architecture micro-services (composants, services, interfaces, flux, infrastructure, interdépendances...). Cet outil, interopérable avec SmartEA du même éditeur, permettra de s'assurer que les spécifications techniques sont correctement comprises et que les développements sont conformes à l'architecture d'entreprise. 

Le diagramme SOA (Service Oriented Architecture) montre une chorégraphie de composants,
par exemple les micro-services (DossierSinistre, Assure et Contrat), les services fournis (Provided interface en vert) et ceux qui les utilisent (Required interface en violet). Les liens orientés du consommateur vers le fournisseur illustrent les appels des services entre les micro-services.

A lire > Orchestration des micro-services avec BPMN

Que dit la bible TOGAF de l’Open Group
à propos de l’architecture micro-services ?

Extrait du TOGAF® Series Guide Microservices Architecture (MSA) montrant les interfaces où les entrées et les sorties du micro-service sont échangées avec d'autres couches architecturales qui doivent être identifiées. La gouvernance et la conduite du changement sont héritées de l'Architecture d'Entreprise globale.

Le guide TOGAF Series sur l’architecture des micro-services (MSA) publié par The Open Group fournit une définition complète de la MSA et présente la portée de l’architecture d’entreprise comme englobant toutes les activités et capacités commerciales de l’entreprise, les informations et la technologie qui composent l’ensemble de l’infrastructure et de la gouvernance de l’entreprise.

L’architecture des micro-services (MSA) est un style d’architecture dans lequel les systèmes ou applications logicielles sont composés d’un ou plusieurs services indépendants et autonomes. Ce n’est pas un produit, un cadre ou une plateforme. C’est une stratégie pour construire de grands systèmes distribués. Les micro-services sont faiblement couplés et déployés indépendamment les uns des autres.

A lire >

• Notre dossier complet : Architecture Micro-Services et Micro-Services études de cas
   
• Une définition pédagogique et les avantages des micro-services : L’Architecture Micro-Services expliquée à ma fille
   
• Leurs inconvénients : Inconvénients de l'Architecture Micro-Services
   
• La démonstration qu’une architecture micro-services est beaucoup plus simple qu’une architecture monolithique : Estimation de la complexité d’une Architecture Micro-Services

Résumé des épisodes précédents

Ça y est, l’analyse de votre application est bien avancée dans ISD, il est temps pour les architectes logiciel de passer à la modélisation de l’architecture micro-services (MSA).

ISD est un environnement open source, low code et NoUML pour l’analyse, la conception et la génération de code d’applications s’interfaçant avec l’outil d’Architecture d’Entreprise SmartEA du même éditeur. Jusqu’ici, nous avons vu des équivalents des cartographies métier, fonctionnelle, applicative avec la cinématique et les représentations des écrans.

Avec ISD, les acteurs, qu’ils soient business analyst, product owner, concepteur, développeur, testeur... embarquent dans un train et se laissent conduire. Chacun apporte sa pierre à l’édifice : le product owner conçoit les user stories, le testeur crée les exigences et les cas de tests à partir des cas d'utilisation, le concepteur modélise les interactions utilisateur et le business analyst les cas d'utilisation, le modèle conceptuel de données et les transitions d’état des entités métier.

Pour l'aspect dynamique du système, la démarche permet de modéliser les rôles des acteurs, puis les cas d'utilisation. Leur granularité étant toujours problématique, l'utilisateur sera aidé en ayant la possibilité de les décomposer suivant 2 niveaux de détails :

1. les scénarios (Tasks Graph),
    
2. les étapes (Actions Plan) d’un scénario.
    

Pour ceux qui le désirent, il est possible d'ajouter des diagrammes de séquence et d'états.

L'aspect statique se compose de diagrammes semblables à UML, mais expurgés des éléments rarement utilisés :

1. les domaines métier (Namespaces), équivalent du diagramme de package UML avec la complexité des relations en moins,
    
2. les entités métier et leurs relations (Domain Classes), correspondant à un diagramme de classes UML pragmatique.

Comme le montre notre étude de cas avec les matrices de traçabilité des exigences avec les use case, les tâches, les cinématiques et les maquettes des écrans, les liens sont bien tissés entre les besoins utilisateurs et les spécifications de l’application. Lors de changements, le contrôle de cohérence entre tous ces éléments et les études d’impact en seront grandement facilitées, principe cher aux méthodes agiles.

En couplant ISD avec l’outil SmartEA, vous obtiendrez des cartographies allant jusqu’à une granularité très fine et augmenterez le degré d’agilité de votre architecture d’entreprise.

A lire >

1. Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
    
2. Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2
    
3. Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

Comment réaliser la modélisation
d'une architecture micro-services

Orientée NoOMG

ISD permet, par l’intermédiaire de son SOA Designer, de modéliser la communication entre les composants d’une application. Cet outil cartographie leurs liens réalisés par des interfaces de services fournies ou requises. Tout y est : la définition des opérations que vos services peuvent effectuer avec leurs entrées/sorties et la gestion des exceptions.

Les protocoles standards SOAP (qui n'est plus un acronyme depuis la version 1.2) et REST (REpresentational State Transfer) sont supportés. La documentation technique ne fait pas état de GraphQL (Graph Query Language). Dommage, car ce langage offre de nombreux avantages par rapport à REST.

L’importation de services REST existants en format OpenAPI (Swagger) est supportée, ce qui rend possible la rétromodélisation. L’export au même format permet de générer la documentation.

Enfin, les données échangées DTO (Data Transfer Object) peuvent être modélisées en NoUML, à partir des entités persistantes (Entities). Dommage qu'ils ne peuvent l'être à partir des classes du domaine (classes métier) définies dans le modèle utilisant la méthode Graal, vue dans nos précédents articles.

Ici, pas de norme ésotérique ou rarement utilisée comme SoaML de l’OMG (Object Management Group), que du pragmatique, on pourrait dire du NoOMG.

Créer un SOA Model

File > New > Other > IS Designer > SOA Model

Après avoir vu Graal Model, Interaction Model, State Machine Model,
Requirement Model, Cinematic Model, examinons le SOA Model.

Les vues DTO Namespaces Hierarchy et SOA Diagram sont ouvertes afin de commencer la modélisation.

Commencer par les DTO (Data Transfert Object)

DTO, JSON, XML/XSD, REST, SOAP

Le pattern DTO d’architecture distribuée consiste à ne considérer que les données échangées et utiles pour le consommateur du service. L’architecte applicatif doit les sélectionner parmi les attributs des classes persistantes (Entities). En effet, transmettre des données non pertinentes pour l’utilisateur encombrerait la bande passante réseau pour rien et présenterait un risque potentiel de sécurité.

Une structure commune entre le fournisseur et le consommateur du service devra être choisie comme JSON (JavaScript Object Notation) pour les micro-services ou XML/XSD (eXtended Markup Language/Xml Schema Definition) pour les Web Services.

Un socle technologique implémentant un protocole commun de transport entre les 2 protagonistes devra être mis en œuvre comme REST (REpresentational State Transfer) pour les micro-services ou SOAP (qui n’est plus un acronyme dans sa nouvelle version) pour les Web Services.

Pour les opérations des interfaces du SOA Diagram, on aura besoin des structures des données échangées. Vous devez donc modéliser vos DTO.

Créer des namespaces pour organiser vos DTO

• Sélectionnez le SOA Model > cliquez sur la vue DTO Namespaces Hierarchy > créer un nouveau namespace de base à partir de la palette et éventuellement des sous-namespaces 

Création du namespace représentant le système de prévoyance contenant 3 sous-systèmes :
prestation, personne et contrat.

Modéliser vos données échangées en entrée/sortie en créant un diagramme DTO

Un diagramme DTO est un diagramme de classes UML simplifié où les classes seraient stéréotypées DTO. Certaines subtilités sont supprimées, comme les agrégations, les implémentations d’interface, les dépendances et évidemment les méthodes. Les DTO ne contiennent que des données, les opérations seront décrites dans les services des composants.

• Sélectionnez le namespace > double-cliquez pour ouvrir un diagramme ou clic droit > New > New DTO Diagram

Vu d'avion, ce diagramme a tout d'un diagramme de classe UML. À y regarder de plus près, pas d'affectation de méthodes dans les classes, pas de relation d'agrégation, de réalisation, de dépendance, pas d'interface, pas de classe abstraite, pas de classe paramétrée... :
on dirait bien du NoUML.

Certains choix peuvent dérouter quelque peu les experts UML, comme le fait qu’une relation de composition soit identifiée par un losange blanc du côté du composite, alors qu’en UML il est noir. Le losange blanc signifie un agrégat dans une relation d’agrégation UML.

Toujours quelques regrets sur l’ergonomie. Par exemple, pour les valeurs d’une énumération, on aurait aimé une saisie globale, plutôt que de ressortir chaque fois, de sélectionner le +, puis de saisir la nouvelle valeur.

La palette vous propose une fonctionnalité alléchante, qui est de créer des DTO à partir d'entités “DTO from Entity”. A noter qu’à l’inverse, il est possible de créer des entités à partir des DTO.

Dans ISD, les Entities correspondent aux classes persistantes gérées par un ORM (Object Relational Mapping) offrant la dualité objet/relationnel SQL. Notre prochain article sur ISD abordera la génération de code et plus particulièrement les Entities, les MLD (Modèle Logique de Données), les MPD (Modèle Physique de Données), la génération et l’exécution de script SQL.

S’il est possible de créer des DTO à partir des entités persistantes (Entities), il est par contre impossible de le faire à partir des classes participantes (Domain Classes), identifiées lors de l’étape d’analyse de la méthode Graal. L’outil SOA Designer semble complètement ignorer les éléments identifiés dans le module Graal. Dommage, car on pourrait aussi concevoir les DTO à partir des classes du domaine métier et pas seulement des classes persistantes.

Un autre inconvénient est que la traçabilité des classes du domaine n’est pas assurée vers les classes persistantes. Pourquoi ce choix ? Ce ne peut être une limitation technique, car par exemple, le SOA Designer accède bien au modèle d’exigences (Requirement Model) pour la traçabilité avec les composants, services et opérations.

Doit-on en conclure qu’il n’y a pas véritablement de référentiel transverse à tous les modules ? 

Cartographier les services (SOA Diagram)

L’objectif est de représenter les composants, leurs liens de communication par l’intermédiaire des interfaces fournies et requises, composées d’opérations avec leurs données en entrée/sorties et leurs traitements exceptionnels (fault).
 
On commence par une vue globale : il s’agit d’un diagramme de composants UML simplifié, où Obeo a gardé les concepts d’interfaces fournies et requises, ainsi que leurs liens, en modifiant leur représentation.

• Dans SOA Model > Components > double-cliquez sur SOA Diagram

Le composant applicatif DossierSinistre doit utiliser (Required interface) les services
du composant Assure et Contrat pour fournir les services qui gèrent la survenance et le dossier.
Notez le niveau de sécurité, ici OAuth 2.0 (Open Authorization).

Le picto clé jaune indique que le composant DossierSinistre est lié à des exigences à visualiser dans l’onglet Linked Requirements et l’autre à droite signifie qu’en double-cliquant sur le composant, on accède au diagramme Component Contract détaillant les opérations.

Contractualiser les opérations d’un service
et les traitements exceptionnels 

Une fois un composant créé avec les interfaces qu’il fournit (Provided) et celles qu’il utilise (Required), on va détailler leurs opérations avec leurs paramètres d'entrée/sorties et les exceptions (Fault) dans un nouveau diagramme.

• Double-cliquez sur le composant, ISD crée automatiquement un nouveau diagramme. On peut aussi passer par le menu contextuel sur le composant : clic droit > New Representation > Component Contract

Le service (Provided Interface) SurvenanceService possède 2 opérations : listerHistoriqueSurvenances avec le picto vert S pour SOAP et le picto paginé. Les paramètres en entrée sont indiqués par une icône bleue, en sortie par une icône verte et les messages d'erreurs en rouge.
L'autre opération possède un picto R pour REST.

Les interfaces apparaissent et, dans la palette, il suffit de faire des drag and drop pour les opérations avec leurs entrées/sorties et les exceptions.

Configurer une opération

Si le nombre d’occurrences retourné par une opération est trop important, vous pouvez décider de paginer le résultat :

• Sélectionnez une opération > onglet Properties > onglet Operation > cochez Paged
  Si ce nombre dépasse la limite métier maximale stipulée dans une exigence, alors vous pouvez renvoyer un message d’erreur (Fault). 

Pour choisir le protocole d'échange :

• Sélectionnez une opération > onglet Properties > onglet Operation > Exposition > choisir entre REST (picto roue verte R), SOAP (picto roue verte S) et NONE (roue grise pour les services internes).

Vous pouvez tout configurer. Par exemple, si vous avez sélectionné REST, l’onglet “Exposition” des propriétés permet de choisir l’URI (Uniform Resource Identifier) et les méthodes HTTP disponibles qui sont GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH et TRACE.

Pour configurer les données en entrée et en sortie :

• En cliquant sur un paramètre d’une opération, on a le détail et notamment le type, comme ContratDTO, en cliquant sur les 3 points horizontaux,
   
  
• Dans Exposition, on trouve aussi le détail des paramètres entrants, qui peuvent être transmis en : BODY, PATH, QUERY, COOKIE et HEADER et leurs noms Swagger pour la documentation et les tests unitaires,
   
• Pour les paramètres en sortie, on peut choisir un code HTML normalisé (200 : OK, 201 : Created…).

La sécurité n’est pas en reste avec l’API REST 

Les schémas de sécurité peuvent être mis au niveau du service ou d’une opération.

Sécurité d'un composant

Il faut d’abord définir les schémas de sécurité.

• Cliquez dans le diagramme Component Contract > Properties > Security Schemes > clic sur le picto + > vous pouvez alors sélectionner le type de sécurité : API_KEY ; HTTP ; OAUTH2 ; OPEN_ID_CONNECT. Il est possible d’en cumuler.

Création d'un système d'authentification et d'autorisation OAUTH2 (Open AUTHorization)
et par token JWT (JSON Web Token) pour le micro-service DossierSinistre.

Sécurité d’une opération ou d’un service

• Dans le diagramme Component Contract sélectionner une opération ou un service (toutes ses opérations seront sécurisées) > Properties > Security > + > sélectionner parmi les schémas de sécurité > Add

Ici, la sécurité est configurée sur l'opération creerSurvenance.

Une clé rouge indiquera que l’opération est sécurisée.

Traçabilité des exigences
avec les composants et leurs opérations

Contrairement aux DTO qu’on ne peut pas lier aux entités métier définies à l’extérieur du modèle SOA, vous avez la possibilité de lier vos services à des exigences définies dans le modèle Requirement Model. Les générateurs de code en tiendront compte.

• Sélectionner le composant (micro-service), un service (interface du composant) ou une opération de l’interface dans le diagramme Component Contract > onglet Linked Requirements > picto jaune Link Requirements with Selection > sélectionner des exigences dans la fenêtre Link Requirements.

Une clé jaune apparaîtra alors sur l’opération.

La clé jaune en bas du service SurvenanceService indique qu'il est lié à des exigences du Requirement Model. Pour les visualiser, il suffit de sélectionner le service et l'onglet Linked Requirements. 

Sur le conteneur, une clé grise apparaît lorsque toutes les opérations ne sont pas liées à des exigences, sinon une clé jaune sera visible. Ici, seule l'opération creerSurvenance est liée à des exigences.

A lire >

• Comment assurer la traçabilité des exigences avec les user stories, les use cases, les processus métier, la cinématique et les maquettes d'écrans ? Une solution dans notre test Obeo ISD S.1 Ep.3

Conclusion

Que ce soit une architecture micro-services ou Web Services, vous pourrez la modéliser simplement avec ISD qui, une fois de plus, a laissé de côté la complexité des normes comme UML pour laisser la place à l’efficience et au pragmatisme. 

En tant qu’architecte logiciel, vous y trouverez votre compte en créant des cartographies représentant les composants applicatifs, avec leurs échanges basés sur un système d’interfaces fournies et requises, indépendamment de leur implémentation technique. Vous pourrez documenter toutes les spécifications, comme le protocole de transfert, REST ou SOAP, le format d’échanges de données, JSON ou XML, les DTO, les opérations avec leurs paramètres d’entrée/sortie, les traitements exceptionnels, les politiques de sécurité, sans oublier la traçabilité avec les exigences.

Réaliser la modélisation détaillée des composants de votre architecture micro-services permet d’étudier précisément les impacts que des changements auraient sur le reste du système. Ensuite, il vous faudra prendre de la hauteur et la décrire de manière globale, afin de l'intégrer dans le SI et alimenter votre patrimoine existant. En effet, une fois cette modélisation finalisée avec ISD, vous pourrez l'importer dans SmartEA, l’outil d’architecture d’entreprise d’Obeo. La notation utilisée est ArchiMate, le standard de l’Open Group. Ce langage de modélisation est spécialisé dans la cartographie des applications d’un SI, mais également de l’infrastructure technique sur laquelle elles sont déployées (logiciels, serveurs, etc.). Il fournit aussi le moyen de modéliser plus largement l’entreprise (son organisation, sa stratégie, ses processus), de manière à décrire à quels besoins répond le SI et ainsi vérifier son alignement métier.

Cette interopérabilité offre une totale collaboration entre l’ensemble des acteurs d’un projet de réalisation d’une application, des experts métier jusqu’aux concepteurs/développeurs, en passant par les business analysts et les architectes logiciel.

Après avoir présenté Obeo ISD (S.1 Ep.1), abordé la méthode d’analyse Graal (S.1 Ep.2), la traçabilité des exigences avec les user stories, la cinématique et les maquettes d'écrans (S.1 Ep.3) et modélisé une architecture SOA micro-services ou Web Services (S.1 Ep.4), il nous restera, pour atteindre le Graal, à voir comment ISD peut générer le code de l’application. Nous verrons entre autres la modélisation des entités persistantes, les MLD (Modèle Logique de Données), les MPD (Modèle Physique de données), la génération et l’exécution de scripts SQL.

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

“ Ce n'est pas sa beauté, sa force et son esprit que j'aime chez une personne,
mais l'intelligence du lien qu'elle a su nouer avec la vie. “
Christian Bobin

Obeo a bien compris qu'en matière de développement d’applications, tout ce qui ne produit pas une fonctionnalité utilisable - dont la conduite de projet ou la modélisation - s’avère une activité parasite, aussi utile semble-t-elle être sur le moment.
N’en déplaise aux markéteurs d’Obeo, le Graal n’est peut-être pas complètement atteint, mais on s’y rapproche.

Notre exemple fictif d'une Institution de Prévoyance (ABIP) projetant de refondre son SI.

Recette pour réussir un outil d'architecture applicative

Débarrassez UML et BPMN de tout ce qui n’a jamais été utilisé, ajoutez un soupçon de diagramme d’activité nommé graphe de tâches, incorporez-y un doigt de diagramme de collaboration BPMN rebaptisé plan d’actions, mélangez avec un zeste de cas d’utilisation avec leurs acteurs. Laissez reposer, préparez le diagramme de classes participantes qui seront packagées. Il est possible, selon les goûts, de l'accompagner de User Stories. Pour finir, agrémentez le tout d’exigences, sans oublier de les lier aux tâches de votre graphe.

Il était une fois la refonte d'un SI...

Regroupement fusionnel

Pour donner un peu de consistance et un soupçon de réalisme à notre fil conducteur, nous avons choisi deux Institutions de Prévoyance AIP et BIP, qui viennent de fusionner et deviennent ABIP. L’architecte d’entreprise, en étroite collaboration avec la DG, a défini la vision de transformation qui soutient les objectifs stratégiques de ABIP. Malgré l’omniprésence d’une infrastructure mainframe IBM antédiluvienne, celle-ci sera conservée en partie, comme le font la plupart des grandes entreprises dans les domaines bancaire et assurantiel : les batches COBOL/CICS pour l’édition des relevés ou le calcul des rentes, sont non seulement maintenus, mais évoluent et sont intégrés dans une architecture orientée services (SOA). Comme dans “2001 : l'Odyssée de l'Espace", un monolithe est omniprésent sous la forme de l'application de prestations réalisée en technologies des années 90.

Une roadmap de migration en méthode agile, basée sur une architecture micro-services (PrevIT), a été validée. Toutes les technologies, outils, framework devront être basés sur l’écosystème Java qui s'interface nativement avec l'environnement mainframe IBM (MVS). La plateforme open source Java Eclipse a été choisie comme outil commun à toutes les parties prenantes. Développé sur ce socle, l’outil d’architecture d’entreprise Obeo SmartEA, remplacera MEGA, dont les coûts de licence obèrent le budget de la DSI. Pour les experts métier, les business analysts, les architectes logiciel et les concepteurs/développeurs, l’outil open source Information System designer (ISD) d'Obeo leur permettra de mieux communiquer. Etant donné les contrats existants avec IBM pour la maintenance des applications sur z/OS, il a été décidé la mise en œuvre d'IBM Cloud Pak for Integration et IBM® Robotic Process Automation, intégrant le moteur de règles métier IBM® Operational Decision Manager.

Le choix de l'ADM de TOGAF

Pour parvenir à ces objectifs, c’est-à-dire la transformation de l’architecture d’entreprise pour avoir une vision globale des aspects stratégiques, métier, organisationnels, et pour maîtriser l’alignement entre le métier et la technique, clé d’un Système d’Information agile, ABIP a choisi le cadre TOGAF. 

Dans un contexte de fusion et de refonte du SI, où l’on doit concevoir des solutions dans un laps de temps réduit, après la phase A Vision de l'Architecture, la 1ère itération de définition de l’ADM (Architecture Development Method) se composant des phases : B Métier, C Système d’Information et D Technique, se concentrera sur l’architecture cible et ensuite, dans la 2ème itération, insistera sur l’architecture existante.

Architecture Micro-Services prescrite par TOGAF

La mise en œuvre de l’architecture micro-services (MSA) suivra les préconisations du guide TOGAF : 

• TOGAF® Series Guide Microservices Architecture (MSA)

et la méthode de conception DDD (Domain Driven Design), voir nos articles :

• Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design)
   
  
• Architecture Hexagonale, exemple de mise en pratique de la méthode DDD Domain Driven Design

Le subtil mélange des concepts d'acteurs,
de Cas d'Utilisation (CU), de tâches et d'actions,
pour arriver à la panacée de l'analyse des besoins

UML n’est pas une méthode, Obeo a donc créé la sienne et l’a nommée Graal

En effet, UML ne donne aucune indication sur les niveaux de décomposition d’un cas d’utilisation, ce qui a toujours été problématique quand il s’agissait de régler le curseur sur la bonne granularité d’un artefact de modélisation, quel qu’il soit d’ailleurs. Voir nos articles : 

• NoSQL, NoCode et NoUML ? Faut-il encore modéliser avec UML ? Défauts et qualités de cette norme de l’OMG vieillissante
   
• Que faut-il garder d'UML ? Quelles seraient les évolutions nécessaires ? Va-t-on vers un reboot d'UML ? Quelles alternatives à UML ?
   

Dans un autre article, nous évoquions la méthode des 10 - 10 (voir notre article :

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?)
Le postulat est de considérer qu'un Use Case est constitué au maximum de 10 scénarios, qui se décomposent en 10 étapes élémentaires. Les scénarios peuvent se modéliser en diagramme de séquence, avec utilisation des fragments comme “opt” pour les options, “alt” pour les scénarios alternatifs, “loop” pour les itérations, etc.

La méthode Graal préconise de :

1. Représenter les acteurs dans un graphe d'acteurs,
    
2. Modéliser l'ensemble des CUs (Use Case Main View) sans les acteurs, qui apparaîtront une fois les Use Case Diagrams réalisés (voir ci-après). On y perd son UML !
    
3. Détailler les tâches (Use Case Diagram) effectuées par un acteur pour un cas d'utilisation,
    
4. Affiner une tâche en explicitant les types d'actions (Actions Plan), comme les évènements de l'application, ses traitements internes, les vues de l'utilisateur et ses actions, équivalent sans le nommer d'un modèle BPMN.

1- Graphe des acteurs (pour un système), sosie d'UML, mais sans les cas d'utilisation

Après avoir créé un modèle Graal (voir l'annexe 1), un point de vue Graal Methodology est activé.

Le service Gestion des Prestations Prévoyance est composé de 7 gestionnaires et d’un responsable.

Pour le système PrevIT, nous commençons par représenter, dans le cadre de la méthode Graal, le graphe des acteurs sosies des acteurs UML.
Le Gestionnaire Prestation Prévoyance (GPP) crée des dossiers, les instruit et les valide tant que le montant ne dépasse pas 50 000 €. Le Responsable Prestation Prévoyance (RPP) procède aux mêmes tâches que le GPP, mais en plus il contrôle et valide les dossiers d’un montant supérieur à 50 000 €, gère les réclamations et manage son équipe.

2- Vue d'ensemble des Cas d'Utilisation (Use Case Main View), sans les acteurs

On identifie les fonctionnalités du futur système.

Remarque : les acteurs créés dans les "Use Case Diagram ou Task Graph" ont été masqués.

Avec les outils standards UML, il suffit, à partir du référentiel, de faire un drag and drop d’un acteur dans le diagramme de Use Cases, puis de le relier par une association au Use Case désiré.

Totalement impossible avec ISD, d’ailleurs l’icône Actor est absente de la palette du diagramme de Use Case (voir la figure ci-dessus). La démarche est déroutante, quand on a l’expérience des outils standards UML.

Pour associer un acteur représenté dans le graphe des acteurs, il faut, pour chaque Cas d'Utilisation de la vue d'ensemble, créer un “Use Case Diagram” (voir annexe 1).

Voir l'annexe 1 pour la procédure de création.

3- Qui (Acteur) et Quoi (Tâches), ensemble dans un même diagramme
(Use Case Diagram) pour un Cas d'Utilisation de la vue d'ensemble

Use Case Diagram (ou Tasks Graph) "Créer un dossier de prestation prévoyance" pour le CU du même nom. Le picto en bas à droite de la 1ère tâche signifie qu'une vue "Actions Plan" lui est associée
et est accessible par un double clic. Le picto "clé" montre que la tâche réalise des exigences.

Pour chaque CU de la vue d'ensemble (Use Case Main View), il est possible de créer un “Use Case Diagram” qui est en fait, dans la méthode Graal, un graphe de tâches (voir annexe 1), dans lequel vous pourrez associer des tâches à un acteur.

4- Dernier niveau de détail, la vue des actions (Actions Plan),
pour une tâche du Use Case Diagram

Une fois les tâches d'un acteur identifiées, vous pouvez, pour chacune d’entre elles,
créer une vue plan d’actions (Actions Plan).

Un plan d’actions est associé à une tâche. Ce graphe représente, de manière pragmatique, les traitements effectués par l’application, les écrans et les interactions effectuées par l’acteur.
Il s’agit en fait d’un modèle BPMN simplifié, dans lequel on retrouve les principaux types de tâches (évènement, action de l’application, vue utilisateur, action de l’utilisateur, tâche), les gateways, nommées ici opérateurs (and, or, xor, loop) et les transitions (simple, interruptible).

Voir l'annexe 1 pour le mode opératoire.

Packages et classes participantes

Organisation hiérarchique des classes du domaine
(Domain Classes Namespaces Hierarchy)

Cartographie des Capacités de l'entreprise (réalisée avec l'outil open source Archi)

 
La méthode Graal reprend le terme namespace, utilisé dans de nombreuses technologies comme XML, pour désigner les packages UML. Seul le concept de hiérarchie est conservé. Les dépendances entre les namespaces sont automatiquement ajoutées à partir du diagramme des entités métier abordé dans le paragraphe suivant. Toutes les autres relations complexes et rarement utilisées ont été éliminées. 

Avec le formalisme UML, on peut créer des classes dans le vide sidéral, sans aucune organisation hiérarchique. Pour pallier ce défaut, la méthode d'Obeo contraint le Business Analyst à créer au moins un namespace pour pouvoir ensuite créer un modèle du domaine avec des classes métier. En UML, cela se traduirait par un diagramme de package.

Les namespaces (package en UML) peuvent modéliser des fonctions ou des domaines métier
de l'entreprise en corrélation en ajoutant les dépendances.

N.B. Le nombre de dépendances entre Prestation Prévoyance et Produit vaut 2
(voir l'annexe 1, le diagramme de classes participantes de Prestation Prévoyance)

Diagramme des entités métier (Domain Classes Diagram)

Le modélisateur qui utilise le diagramme de classes UML doit préciser le destinataire, le contexte et l’objectif. Par exemple, dans un modèle du domaine "Entités métier/Relations" réalisé par les Business Analysts pour le compte de la MOA, les méthodes, les niveaux d’encapsulation, les identifiants techniques, etc. n'y figurent pas, mais rien ne l’interdit.

Dans son Graal du NoUML, Obeo a repris le diagramme de classes UML pour en faire un diagramme de classes du domaine modélisant uniquement les entités métier avec leurs données et leurs relations. 

Diagramme de classes du domaine (namespace) "Prestation Prévoyance"

Les classes du domaine "Produit" et les relations avec les autres domaines "Contrat" et "Prestation"

Voir l'annexe 1 pour le mode opératoire.

Conclusion

Avec sa méthode Graal, Obeo s'est bien imprégnée des principes du NoUML. Son implémen-tation au travers de l'outil ISP, permet un usage pragmatique, les modèles sont affinés par de petits incréments, les notations simples facilitent la validation. L'utilisateur peut se focaliser plus aisément sur les aspects qu'il doit modéliser.

Pour l'aspect dynamique du système, la démarche permet de considérer les rôles des acteurs, puis, à une autre étape, les cas d'utilisation. Leur granularité étant toujours problématique, l'utilisateur sera aidé en ayant la possibilité de décomposer suivant 2 niveaux de détails :

• les scénarios (Tasks Graph),
   
  
• les étapes (Actions Plan).
   
  

Pour ceux qui le désirent, il est possible d'ajouter des diagrammes de séquence et d'état.

L'aspect statique se compose de diagrammes semblables à UML, mais expurgés des éléments rarement utilisés :

• les domaines métier (Namespaces),
   
  
• les entités métier et leurs relations (Domain Classes).
  

Dans notre prochain article, nous verrons que Graal a aussi intégré des concepts qui faisaient défaut à UML, comme les exigences et les User Stories. Mais cela est une autre histoire.

Merci pour vos commentaires qui seront les bienvenus, ainsi que vos retours d'expérience heureux ou malheureux, qui pourront profiter à nos lecteurs.

" L’inertie seule est menaçante. Ne crains pas, ni ne doute,
car le doute est stérile et la crainte est servile. "
Saint-John Perse

Annexe 1 : mode d'emploi

Résumé de l'épisode précédent

Dans notre article :

• Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
   

nous avions vu les caractéristiques d'ISD, son interopérabilité avec Obeo SmartEA, comment installer ISD et comment créer un "Modeling Project".

Créer un modèle Graal

Menu File ou clic droit sur le Modeling Project > New > Other > IS Designer > Graal Model

Créer un graphe d'acteurs (Actors Graph) pour un Système

Clic droit sur "System" > New representation > Actors Graph > nommer le diagramme

Créer une vue d'ensemble de Cas d’Utilisation (Use Cases Main view) pour un Système

Clic droit sur "System" > New representation > Use Cases Main View > nommer le diagramme

Use Case Main View avec les acteurs, des use case inclus, des compositions de tâches
et la traçabilité vers des exigences.

Les acteurs sont affichés uniquement quand dans la liste déroulant "Layers", l'option "Actors" est cochée (4ème icône à partir de la gauche en dessous de l’onglet de la vue). Les liens entre acteurs et les cas d’utilisation sont déterminés automatiquement à partir des liens entre acteurs et tâches dans un "Use Case Diagram" ou "Task Graph".

Les icônes "Change Diagram edition mode" et "Show/Hide" permettent d'Afficher/Masquer tous types d'éléments.

Le picto en bas à droite du CU "Créer un dossier de prestation prévoyance" signifie qu'un "Use Case Diagram" existe, pour détailler l'acteur et ses tâches. Un double clic suffit pour y accéder. Le picto "clé" sur le CU "Enregistrer un sinistre en attente de justificatifs" signifie qu'il réalise des exigences. Une simple sélection affiche un onglet avec la liste des exigences.

Créer un diagramme (Use Case diagram ou Tasks Graph) pour un cas d’utilisation

Clic droit sur le use case dans la vue d'ensemble > New > Create Use Case Diagram ou dans l'onglet Model Explorer > sélectionner le Modeling Project > la méthode Graal > le conteneur System > sélectionner un use case > clic droit > New Representation > Other > Graal Methodology > Use Case Diagram

Pour affecter un acteur à une tâche, vérifier que le calque “Actors” est bien activé dans le ruban en sélectionnant Actor > drag and drop d'Actor de la palette sur la tâche > choisisser l’acteur qui a déjà été modélisé dans le graphe des acteurs. A ce niveau, il n'est pas possible de créer un nouvel acteur, qui doit être opéré uniquement dans la vue graphe d'acteurs, ce qui plutôt bien en évitant la fonction de création à de multiples endroits.

La vue globale de cas d’utilisation du système est mise à jour automatiquement avec l’acteur.
(Il en va de même pour le graphe de tâches système.)

Créer un plan d’actions (Actions Plan) pour une tâche

Dans un graphe de tâches (ou Use Case Diagram) : clic droit sur une tâche > New > Actions Plan

Similaire à un BPMN, on retrouve la typologie
des principales tâches (Actions), les évènements, les passerelles (Operators)...

Créer des namespaces

Dans l'onglet Model Explorer, sélectionner le Modeling Project > Méthode Graal > conteneur System > Domain Classes Namespaces Hierarchy ou clic droit sur System > New Representation

Remarque : pour visualiser les dépendances entre les namespaces qui seront créées dans le Domain Classes Diagram, il faut activer le calque Dependencies dans la liste Layers, 4ème icône du ruban.

Créer un ”Domain Classes Diagram” (classes participantes ou métier)

Sélectionnez un namespace > clic droit > New > New Domain Classes Diagram

Pour relier des classes appartenant à des namespaces différents il faut : 

• dans le diagramme Domain Classes Namespaces Hierarchy activer le calque Dependencies,
   
• dans le diagramme Domain Classes Diagram activer le calque External Domain Classes,
   
• sélectionner dans la palette External Domain Class puis le namespace et la classe,
   
• sélectionner dans la palette Relation, cliquer la classe de départ, déplacer la souris jusqu’à la classe d’arrivée.

Annexe 2 : compléments de lecture

• Alimenter le référentiel d’Architecture d’Entreprise pour la couche Application de TOGAF avec l’outil Information System Designer (ISD) d’Obeo - Modélisation de l’analyse des besoins S.1 Ep.1
     
• NoSQL, NoCode et NoUML ? Faut-il encore modéliser avec UML ? Défauts et qualités de cette norme de l’OMG vieillissante
    
  
• Que faut-il garder d'UML ? Quelles seraient les évolutions nécessaires ? Va-t-on vers un reboot d'UML ? Quelles alternatives à UML ?
   
• Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
       
  
• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information
   

• ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?

L'éditeur logiciel Obeo propose 2 outils interopérables :
le premier, open source, dédié aux architectes logiciels : Information System Designer
et le second, commercial, dédié aux architectes d’entreprise : SmartEA.
Les applications sont complètement modélisées et leurs codes générés dans ISD,
et, grâce à un connecteur, les modèles peuvent ensuite être exportés dans SmartEA.

Et si l'on inversait les rôles ? Si l'on partait de la documentation pour arriver à la réalisation, au code. Le Doc2Code serait-il né ?

Pour assurer la collaboration entre l'architecte logiciel et l'architecte d'entreprise, il faudra payer. Dommage de ne pas avoir choisi le 2 en 1

Pourquoi choisir ISD ?

ISD est un studio moderne pour l’analyse, la conception et la génération de code d’applications s’interfaçant avec l’outil d’Architecture d’Entreprise SmartEA d'Obeo.

Le studio est une base centrale, collaborative de modélisation
afin de générer la documentation et le code.

L’objectif principal est de permettre aux fonctionnels, architectes applicatifs, concepteurs-développeurs et acteurs DevOps, de partager leurs connaissances et leur compréhension du SI, avec des représentations intelligibles.

La méthode Graal d'analyse métier, ainsi que les autres couches,
seront entièrement abordées dans nos prochains articles.

Information System Designer (ISD) offre à la fois la capture des besoins, les cas d’utilisation, les IHM, les services métiers, les entités métiers, les schémas de base de données.
C’est donc un studio de conception d’applications constitué d’un ensemble de modeleurs pour construire des architectures applicatives.
Il intègre une fonctionnalité nommée scaffolding permettant la transformation de modèles.

D’après Obeo, le pourcentage de code généré avec ses générateurs maison customisés avoisinerait 80 %. Les 20 % restants concernent par exemple l’implémentation des modèles états-transitions et les IHM qu'il ne serait pas rentable de faire générer.

Fiabilité de l'architecture garantie
par les générateurs d’Obeo

Contrairement aux frameworks d’ORM (Object Relational Mapping) comme Hibernate, Eclipse Link ou encore Spring Boot, ISD, à partir d’un modèle inspiré du diagramme de classe UML (voir ci-après NoUML), génère les scripts SQL, les exécute dans le RDBMS, génère le code Java et, cerise sur le gâteau, génère la totalité des tests unitaires.

NoUML, pas tout à fait, disons
un UML pragmatique sans fioritures

Entre norme pour technocrate et simplicité alliée à l'efficacité, Obeo a tranché

Comme déjà décrit dans nos articles :

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

et

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

UML pêche par sa complexité et freine l’Ingénierie Dirigée par les Modèles
(voir la catégorie IDM).

Deux solutions s’offraient à Obeo :

1. se conformer à la norme en concevant un profil UML, comme par exemple SysML
2. prendre ses distances en se déclarant NoUML

C’est la deuxième solution qui a été choisie. Comme l’objectif du studio ISD est la conception d’applications, la première solution aurait été compliquée et peu efficiente pour la génération de code.

Obeo a donc choisi, pour se libérer des sévères contraintes et pallier les manques de la norme de l’OMG, la deuxième solution en créant un DSL (Domain-Specific Language) représentant des modèles spécifiques pour représenter visuellement les différents aspects d’une application :

• Exigences (absent d’UML, mais présent dans SysML)
• Scénarios d’usage
• Base de données
• Entités de données
• Services
• IHM et cinématique des écrans (absent d’UML)

Conclusion

Cet outil, interopérable avec SmartEA, permettra d'assurer que les spécifications techniques sont correctement comprises et que les développements sont conformes à l'architecture d'entreprise.

ISD a fait le choix du NoUML en concevant son propre DSL pragmatique et inspiré d’un UML très simplifié.

De la modélisation oui, mais pas trop, juste ce qu’il faut pour pouvoir générer et documenter du code, c'est ce que nous verrons dans nos prochains articles consacrés d'abord à la méthode Graal d'Obeo pour l'analyse métier, puis aux services SOA (Service-Oriented Architecture), aux entités métiers et pour finir les générateurs de codes.

" Presque aucune part n’est réservée à l’enseignement de la parole proprement dite ; l’écolier apprend à lire, à écrire, à compter, à raisonner, non à parler (…). Ils seront dans la vie la proie de quelque bavard, expert au langage courant " 
Jean Zay

Annexes 1

Installer ISD

Comme la plupart des logiciels open source, ISD est disponible sur tous les OS :
Linux, Mac OS, et Windows.

https://github.com/ObeoNetwork/InformationSystem/releases

Télécharger l’archive correspondant à votre OS, désarchiver et lancer l’exécutable (is-designer), et c’est tout !

ISD a été développé sur un socle Eclipse auquel Obeo a ajouté de nombreux plugins.

Note : notre test s’est effectué sur Linux Ubuntu 22.04 LTS Open JDK 17 et Windows 10 Oracle JDK 11.

Créer un “Modeling Project”

Avec la perspective Modeling (Défaut) ouverte :

File > New > Modeling Project > Nommer votre projet

Annexes 2

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 :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (7)
   

Les règles à appliquer pour un diagramme de classes valide :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (8)
   

Diagramme de séquence UML :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (9)
   

Les bonnes pratiques pour un diagramme de séquence valide :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (10)
   

Les règles à appliquer pour un diagramme d'états :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (11) 

Pour créer des modèles UML avec ChatGPT
ou avec des outils gratuits

Les meilleurs logiciels de modélisation UML :

• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information
   

Création de modèles UML, BPMN et de cartographies ArchiMate avec ChatGPT :

• ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?

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.

• C4 model

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.

• UNCIA

Les organisations victimes d’attaques par malware, ransomware ou autres sont de plus nombreuses, et cela dans tous les domaines.
Laurent Jordi, architecte d’entreprise pour de grands groupes, vous explique dans une série de vidéos courtes, comment, en combinant TOGAF et SAFe, vous pourrez rendre votre SI résilient face à ces cyberattaques.

Les 2 thèmes introduits dans cette première capsule sont la Résilience opérationnelle numérique
et la Gestion des risques liés aux TIC par des tiers.

Laurent Jordi

https://www.ezlogic.mc/

EZ Logic Monaco

“J’ai toujours eu la conviction que les virus informatiques ou biologiques finiraient par détruire la quasi-totalité de l’espèce humaine.”
Franck Thilliez

Articles conseillés

Vidéo de Laurent Jordi

• Cas d'usage : Modernisation d'une partie du SI d'un leader de la sécurité

Articles consacrés à TOGAF

• TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?
• TOGAF pour les nuls.
  
  
• Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
  
  
• Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture
  
  
• Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise
  
  
• Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?
  
  
• Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces
  
  
• Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace

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".

“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 :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (7)
   

Les règles à appliquer pour un diagramme de classes valide :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (8)
   

Diagramme de séquence UML :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (9)
   

Les bonnes pratiques pour un diagramme de séquence valide :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (10)
   

Les règles à appliquer pour un diagramme d'états :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (11) 

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 :

• Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information
   

Création de modèles UML, BPMN et de cartographies ArchiMate avec ChatGPT :

• ChatGPT, l’outil idéal de réalisation de modèles pour l’Architecture d’Entreprise et l’Urbanisation du Système d’Information ?

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.

• C4 model

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.

• UNCIA

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 :

• Moteur de règles
• Drools

Pour tout savoir sur BPMN

Retrouvez tous nos articles sur BPMN dans la catégorie :

• BPMN 

Pour tout savoir sur DMN

Retrouvez tous nos articles sur DMN dans la catégorie :

• DMN

Pour tout savoir sur CMMN

Retrouvez tous nos articles sur CMMN dans la catégorie :

• CMMN

Pour tout savoir sur SysML

Retrouvez tous nos articles sur SysML dans la catégorie :

• SysML

Pour tout savoir sur BMM

Retrouvez tous nos articles sur BMM dans la catégorie :

• BMM

Pour tout savoir sur ArchiMate

Retrouvez tous nos articles sur ArchiMate dans la catégorie :

• ArchiMate