urbanisation-si.com

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.

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

 

 

 

 

 

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

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

 

 

 

 

 

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

 

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

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

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

“Mes méthodes sont-elles malsaines ?
Je ne vois aucune méthode, mon colonel.”

Echange tiré du film culte Apocalypse Now, de Francis Ford Coppola

 

Annexes

Les 4 diagrammes UML à utiliser

Les bonnes pratiques pour modéliser les Cas d'Utilisation UML :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (5)
• Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
    
  

Diagramme de classes UML :

• 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

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

 

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

UML doit-il prendre sa retraite ?

 

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

UML est allergique à l’Agile

 

 

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

 

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

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

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

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

 

Près de 800 pages de spécifications !

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

 

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

 

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

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

 

 

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

 

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

 

 

 

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

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

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

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

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

 

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

 

UML exécutable, une utopie ?

  

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

 

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

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

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

 

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

 

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

 

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

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

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

 

  

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

 

UML n’est pas une méthode

    

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

      

    

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

 

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

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

 

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

 

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

 

 

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

 

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

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

 

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

D’autre part, UML ne permet pas directement de modéliser les exigences et d'assurer la traçabilité vers leurs réalisations par les autres éléments de conception, à moins de construire son propre profil personnalisé avec stéréotypes, tags-value et règles OCL.

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

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

 

Just code it

 

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

 

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

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

 

Qu’en “pense” notre ami ChatGPT

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

Réponse de ChatGPT

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

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

 

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

 

Conclusion

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

 

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

 

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

 

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

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

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

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

Sam Altman, le père de ChatGPT

 

Annexe

Certification, validité, prototypage et vérification des modèles UML :

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

Les aspects structurels, fonctionnels et dynamiques d'UML :

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

Définir formellement les règles et trouver un algorithme qui permette de les vérifier :

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

Correspondances entre éléments de modélisation de niveaux (abstraction ou modèle) différents.

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

Les bonnes pratiques pour modéliser les Cas d'Utilisation UML :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (5)
• Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
   

Diagrammes de composants et de déploiement UML :

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

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)
   

Les règles UML sont écrites en OCL :

• Modélisation de système : Soyez maniaque, croisez et recroisez vos modèles UML pour être certain qu'ils soient valides (12)
• Modélisation de système : UML n'est rien sans OCL !
• Modélisation de système : OCL ça se complique !
• Modélisation de système : OCL vous en redemandez ?
   

UML n'est pas une méthode : exemple de méthode à adapter pour la modélisation métier et les besoins :

• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 2ème partie - Processus métiers - Profil UML Eriksson Penker
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 3ème partie - Processus métiers - BPMN
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 4ème partie - Processus métiers - UML - Diag. Activité
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 5ème partie - Règles métier- UML - Profil spécifique
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 8ème partie - Etats métiers – UML – Diag. Etats
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 9ème partie - Domaines métiers – UML – Diag. Package
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 10ème partie - Liste des exigences – UML – Diag. Package
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 11ème partie - Exigences – UML – Profil spécifique
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 12ème partie - Contexte Statique – UML – Diag. Classe
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 13ème partie - Contexte Dynamique/Diag. Flux
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 14ème partie - Cas d’Utilisation – UML – Diag. Use Case
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 15ème partie - Regroupement par Domaines – UML – Diag. Package
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 16ème partie - Scénarios Cas d’Utilisation – UML – Diag. Séquence
• Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - Dernière partie - Traçabilité – UML – Relation de dépendance
   

Pour tout savoir sur l'Ingénierie Dirigée par les Modèles :

• Le meilleur outil pour transformer, dériver, parcourir, requêter sur des modèles afin de mettre en œuvre MDA (Model Driven Architecture)
   

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 ?

Dans notre quête du Graal pour outiller les méthodes d’AE et d'urbanisation du SI et plus généralement pour la modélisation multiparadigmes, nous avons testé ChatGPT pour la production de code PlantUML (voir notre article : Texte vers UML et autres outils de "diagrammes en tant que code" - Le moyen le plus rapide de créer vos modèles ? ) pour des vues ArchiMate et XMI pour des diagrammes UML et BPMN. L'intérêt d'avoir les diagrammes sous forme de code facilite entre autres la mise en œuvre de MDA (Model Driven Architecture).

  

Évidemment, nous avons demandé à DALL·E, une autre IA d'OpenAI,
spécialisée dans la génération d'images à partir d'une description textuelle, d'illustrer notre article.

"An illustration for an article about a chatbot generating code for diagrams".

 

Un générateur de code qui tient compte de ses erreurs

A quoi sait-on qu’une nouvelle technologie peut vraiment changer la donne ? Quand elle suscite la panique chez les leaders installés du secteur, tout autant que leur convoitise. Présenté pour la première fois fin novembre par OpenAI, le bot conversationnel ChatGPT n’a mis que quelques jours pour devenir le sujet de discussion numéro 1 de la planète numérique.

ChatGPT se révèle être à la fois :

• un moteur de recherche donnant immédiatement et exactement le résultat sans avoir à ouvrir plusieurs liens,
• un Wikipédia,
• un générateur de contenu,
• un traducteur,
• un agent conversationnel mémorisant tous les éléments du dialogue lui permettant d’affûter ses réponses. Chaque conversation est stockée, pour être potentiellement reprise ultérieurement,
• un générateur et vérificateur de code informatique ayant absorbé tous les codes trouvés sur internet jusqu’à fin 2021. 

C’est cette dernière fonctionnalité qui nous intéresse ici.

 

En lui fournissant des informations supplémentaires, comme des données contextuelles ou des préférences utilisateur, ChatGPT formule une réponse encore plus en adéquation avec le sujet demandé. De manière similaire à une conversation entre 2 humains, où la reformulation est le moyen le plus efficace pour se faire comprendre et en procédant par itérations de plus en plus précises, nous avons constaté que ChatGPT affine sa compréhension des attendus et fournit un meilleur résultat.

 

Le système fait également croire qu’il peut se corriger. Si l’utilisateur n’est pas satisfait d’une réponse, il peut demander de recommencer, et recueillir ensuite une meilleure réponse. ChatGPT ne comprend pas son erreur, mais comme c’est un système probabiliste qui fournit la meilleure réponse parmi plusieurs possibles, il finit par proposer les suivantes dans la liste.

 

Nos tests (les codes générés se trouvent en annexe 1)

Pour connaître l'environnement de nos essais, les reproduire et les adapter, vous pouvez vous reporter à l'annexe 1 à la fin de cet article.

 

Nous avons choisi de converser avec ChatGPT en anglais sachant que le domaine abordé est plutôt anglophone, ce qui n’aurait pas été le cas si nous lui avions demandé de disserter sur l'œuvre romanesque de Proust.

 

Test #1

Code PlantUML d'une vue ArchiMate d'un processus de prêt bancaire

Étant néophytes pour la génération de code PlantUML pour des vues ArchiMate avec ChatGPT, nous nous lançons avec une première demande relativement basique. 

 

Question :

 

"Give me the code for PlantUML corresponding of an ArchiMate diagram for a bank loan process"

 

Résultat :

 

Le résultat est un diagramme de classes UML largement satisfaisant pour un débutant en UML.

 

 

ChatGPT a généré du code PlantUML représentant un diagramme de classe
alors qu'on lui a demandé un diagramme ArchiMate. Il a pris le type de diagramme par défaut.

 

A priori, ChatGPT n’a pas tout à fait compris que nous voulions une vue ArchiMate un peu plus consistante.

 

Nous allons alors lui indiquer le code de démonstration pour ArchiMate fourni par PlantUML et nous lui demanderons de générer un code similaire pour un prêt bancaire.

 

Test #2

La même demande après lui avoir donné un exemple

Question :

 

"Can you generate a similar plantuml code for a bank loan process"

 

Résultat :

 

 

Résultat après lui avoir indiqué un exemple et lui avoir dit que nous voulions le même type de code

 

Nous avons une vue faisant intervenir les niveaux métier et applicatif. Des relations de composition relient les processus. Les services applicatifs fournissent des fonctionnalités au processus et les composants réalisent les services.

ChatGPT a compris que nous voulions incorporer dans le diagramme un titre et une légende qui sont souvent négligés et fastidieux à mettre en œuvre.

 

ChatGPT mémorise tous les échanges, nous pouvons donc lui demander de détailler tour à tour chacun des sous-processus. 

 

Test #3

Zoom sur le sous-processus de vérification

Question :

 

"Like the previous plantuml diagram, can you give me the plantuml code for the Verification process ?"

 

Résultat :

 

 

Zoom sur le processus de vérification

 

Nous avons demandé le détail de tous les sous-processus composant le prêt bancaire.

Les autres codes générés n'ont pas été intégrés à cet article, mais restent disponibles sur demande.

 

Test #4

Description textuelle du cas d'utilisation ""Demander un prêt bancaire"

Examinons maintenant ce que va nous donner ChatGPT pour le cas d'utilisation cas d'école "Demander un prêt bancaire".

 

Question :

 

"Lets define a simple use case in bank loan, something that is very well established and easy to understand"

 

Réponse :

 

Sure, let's consider the use case of obtaining a personal loan from a bank.

 

Here's how the process might work:

 

1. A customer starts by researching different banks and comparing their personal loan options.
2. Once the customer has found a loan that they are interested in, they complete a loan application, which requires them to provide personal and financial information, such as their income, employment history, and credit score.
3. The bank uses this information to determine the customer's creditworthiness and assess their ability to repay the loan.
4. If the customer is approved for the loan, they receive an offer with the loan terms, including the interest rate, monthly payment amount, and repayment period.
5. If the customer accepts the loan offer, they sign the loan agreement and provide any necessary documentation, such as proof of income or collateral.
6. The bank then disburses the loan funds to the customer, either as a lump sum payment or in installments.
7. The customer then repays the loan over time, including both the principal amount and the interest, according to the terms agreed to in the loan agreement.

 

This is just a basic example of how a personal loan from a bank works, but it should give you an idea of how individuals can use loans to access the funds they need for a variety of purposes, from paying for large expenses to consolidating debt.

 

Test #5

Tableau du modèle métier d'un prêt bancaire

Évidemment il s'agit du processus standard. Pour un cas plus spécifique, il suffirait d'ajouter les informations métier supplémentaires.

Demandons-lui le modèle métier sous la forme de tableau au format standard markdown.

 

Question :

 

"Describe the data model in more detail or tabular format using markdown"

 

Réponse :

 

Test #6

Diagramme de classe UML d'un prêt bancaire

Passons à l'aspect structurel avec un diagramme de classe UML généré à base de code PlantUML.

 

Question :

 

"This is perfect, I would like to depict the relationships in a plantuml diagram, can you give me the code to do this"

 

A la première génération, ChatGPT met des espaces dans les noms de classe, ce qui provoque un message d'erreur de syntaxe à l'exécution dans PlantUML.

 

Nous lui indiquons :

"There is a syntax error about class Loan Application, I think there is no space in the class name."

 

Résultat :

 

I apologize, you're correct. Here's the corrected PlantUML code:

 

Voir le code généré en annexe 1.

 

Voici l'exécution dans PlantUML :

 

 

Représentation dans PlantUML du code généré par ChatGPT
pour le modèle d'entités métiers pour un prêt bancaire.

 

Test #7

Diagramme de séquence UML pour le prêt bancaire

Continuons avec l'aspect comportemental avec un diagramme de séquence UML.

 

Question :

 

"How would a client asking for a bank loan impact the classes mentioned above, I would like to depict this as a sequence diagram. Can you help describe the diagram in code for plantuml"

 

Résultat :

 

 

Le diagramme de séquence UML avec les commentaires s'il vous plaît !

 

Test #8

Diagramme états/transitions UML pour le prêt bancaire

Demandons à ChatGPT quels seraient les états métier du prêt bancaire et de générer le code PlantUML pour le représenter dans un diagramme de "state machine" UML.

 

Question :

 

"Will the loan have states like new, closed, active inactive, cancelled, etc ? I would like to depict the states in a state diagram using plantuml. Can you help describe the diagram in code for plantuml"

 

Résultat :

 

  

Les états et les transitions représentés par PlantUML correspondant au code généré par ChatGPT

 

Test #9

Mind map pour un prêt bancaire

On aurait pu commencer par là : voyons ce que donne un mind map toujours relatif au prêt bancaire.

 

Question :

 

"Let's start by creating a simple MindMap on the topic of Bank Loan 
Can you give the mindmap in PlantUML format. Keep it structured from the core central topic branching out to other domains and sub-domains. Let's go to 5 levels to begin with. Add the start and end mindmap tags and keep it expanding on one side for now"

 

Résultat :

 

  

Pour finir un mind map des concepts clés d'un prêt bancaire
toujours avec du code PlantUML généré par ChatGPT.

 

Test #10

Un pattern ArchiMate : Strategic Value Map View

Évidemment, si l’on restreint le périmètre, si on supprime les mots clés, et si l’on ne précise pas les règles métier, tout en augmentant le niveau d’abstraction, on obtient une vue correspondant au contexte demandé.

 

Question :

 

"Like the previous plantuml diagram, can you give me the plantuml code for the Strategic Value Map View ?"

 

Résultat :

 

 

Essai de génération du pattern "Strategic Value Map View"

 

Test #11

Business Model Canvas View

Demandons-lui de faire un template avec ArchiMate pour un Business Model Canvas View.

 

Question :

 

"Like the previous plantuml diagram, can you give me the plantuml code for the Business Model Canvas View ?"

 

Réponse :

 

ChatGPT répond que malheureusement PlantUML ne supporte pas ce type de diagramme. Il nous propose de trouver un plugin ou de créer nos propres éléments.

 

En fait, il est tout à fait possible de créer une telle vue avec ArchiMate.

 

 

Un Business Model Canvas View avec les artefacts ArchiMate et réalisé avec l’outil open source Archi (voir notre article : Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information )

 

Test #12

Plus on donne d'informations à ChatGPT, meilleure sera la réponse. Exemple d'une librairie en ligne.

Question :

 

"Give me the code for PlantUML corresponding of a class diagram for an online library with Author, Book, User, ShoppingCartLine, ShippingCart, PurchaseOrder and Status. Don't forget the multiplicity. Author wrote 0 or several books and a book is written by 0 or several authora. A User is an aggragate of 0 or several shopping cart which is an aggragate of 0 or several shopping cart lines which is linked at a book. A PurchaseOrder is linked at one user and one shopping cart. The Status are pending and shipped."

 

Résultat :

 

 

Diagramme de classe UML pour une librairie en ligne, généré par ChatGPT
après avoir décrit le contexte métier.

 

Si l’ajout des attributs des entités métier était trivial, il n'en va pas de même pour ce qui est des méthodes. Heureusement, ChatGPT les a correctement modélisées selon les meilleures pratiques de conception orientée objet.

 

Test #13

Qu’en est-il pour du code plus verbeux comme XMI représentant un processus BPMN ?

Question :

 

“Write BPMN code for a pizza order”

 

Résultat :

 

Le code XML de l’OMG pour représenter un simple cas d’école de processus BPMN est tellement verbeux que ChatGPT ne finissait pas sa génération. On peut comprendre qu’il soit limité dans sa réponse en nombre de mots étant donné les millions de conversations simultanées auxquelles il doit participer.

Nous lui avons demandé par 2 fois de terminer son code. 

Puis nous avons concaténé les 3 parties de code dans un fichier avec l’extension .bpmn, que nous avons ensuite ouvert avec l’outil bpmn.io (https://bpmn.io/) de Camunda (voir notre article : Top 5 2023 des outils gratuits ou open source pour l’Architecture d'Entreprise et la modélisation du Système d’Information ) 

 

 

En demandant par 3 fois à ChatGPT de continuer à générer le code XML pour le diagramme BPMN, nous avons pu constituer le fichier .bpmn et l'ouvrir avec l'open source bpmn.io de Camunda.

 

Un assistant de choix pour les cartographes

ChatGPT peut accompagner les cartographes de SI dans leur production quotidienne, en leur suggérant du code pour les outils de modélisation visuelle. En les aidant, ChatGPT peut augmenter leurs capacités et leur productivité, réduire les tâches manuelles et leur permettre de se concentrer sur les aspects les plus intéressants de leur travail.
Cela fait intrinsèquement partie des métiers de l’IT d’évoluer en fonction des innovations technologiques. Un développeur d'application de gestion ne programme plus en assembleur, un architecte logiciel n’écrit plus manuellement les codes techniques pour une architecture distribuée, les outils low code/no code se développent… 
De langages impératifs fastidieux, on passera inéluctablement à un formalisme déclaratif voir au langage naturel. 

Pourquoi se fatiguer à apprendre ?

Quand Wikipédia est apparu, les instances pédagogiques se sont alarmées des possibilités de plagiat par les apprenants. Avec le temps, des logiciels antiplagiat sont apparus, les enseignants ont largement fait la morale en expliquant les raisons pour lesquelles il ne fallait pas copier et finalement Wikipédia est devenu un outil pédagogique comme un autre.
Nous pensons qu’il se passera la même chose avec ChatGPT. Il ne faudrait pas exercer des contraintes coercitives, mais au contraire innover dans l’ingénierie pédagogique en incluant ce type d’agent conversationnel comme un formidable moyen pour développer les capacités cognitives. Les pédagogues devront alors vérifier, expliquer les résultats et les utiliser comme support pour aller plus loin sur le sujet concerné.

 

Conclusion

CQFD.

Bien sûr, il s'agit d'une première prise en main de ChatGPT et nos tests portent sur des cas d’école, pouvant par exemple servir comme matériel pédagogique à de futurs étudiants dans le domaine de la modélisation de Système d'Information.

Cependant, ils montrent qu’en apprivoisant ChatGPT, en décrivant un contexte métier en langage naturel, en explicitant la formulation, en ajoutant au fur et à mesure des échanges des informations supplémentaires sur l'ontologie utilisée, en affinant la question et en demandant de détailler certaines parties, ce chatbot est capable de générer du code représentant des vues ArchiMate d’Architecture d’Entreprise ainsi que des diagrammes UML et BPMN pour le SI.

 

Cette génération de "diagram as code" est fondamentale, car les avantages à représenter les modèles sous forme textuelle sont nombreux : synchronisation automatique entre les modèles, versioning avec des outils de type Git, conception collaborative avec des outils de type Google Doc, solutions open source légères, code moins verbeux que le XMI de l'OMG... (voir notre article : Texte vers UML et autres outils de "diagrammes en tant que code" - Le moyen le plus rapide de créer vos modèles ? ).

Sans oublier la mise en œuvre grandement facilitée de MDA avec la réalisation par scripts de transformations de modèles à partir de leur code. Les normes XMI et DI de l'OMG, très complexes, verbeuses et avec leurs nombreuses versions incompatibles, empêchaient la démocratisation de la dérivation des modèles correspondant par exemple aux couches d'architecture.

 

Au vu de ce que prépare par exemple le géant chinois de l’internet Baido avec son Ernie Bot, Google avec Bard et OpenAI avec la prochaine version de ChatGPT (GPT-4) et avec l’aide des milliards de Microsoft, soyons assurés que dans un proche avenir, les architectes d’entreprise, urbanistes et cartographes de SI, voir les modélisateurs multiparadigmes, seront dispensés des tâches fastidieuses et sans valeur ajoutée, leur permettant d’être plus créatif.

 

De notre côté, nous comptons bien en faire une utilisation plus poussée et utiliser ChatGPT à des fins professionnelles. Nous ne manquerons pas de vous tenir informé.

ChatGPT chat.openai.com @ChatGPT

Rhona Maxwel urbanisation-si.com @rhona_helena

“Autrefois pour faire sa cour
On parlait d'amour
Pour mieux prouver son ardeur
On offrait son cœur
Maintenant, c'est plus pareil
Ça change, ça change
…
Viens m'embrasser
Et je te donnerai
…
Une tourniquette
Pour faire la vinaigrette
Un bel aérateur
Pour bouffer les odeurs
Des draps qui chauffent
Un pistolet à gaufres
…”
Boris Vian - La complainte du progrès

 

 

Annexe 1

Les codes générés

Mode d'emploi

1. Créer un compte sur le site : chat.openai.com puis se connecter.
   
   
2. Cliquer sur le lien Serveur de démonstration en ligne de PlantUML.
   
   
3. Copier/Coller le code de ChatGPT, le diagramme correspondant apparaît instantanément.
   

 

Test #1

Code PlantUML d'une vue ArchiMate d'un processus de prêt bancaire

Question :

 

"Give me the code for PlantUML corresponding of an ArchiMate diagram for bank loan process"

 

Réponse :

 

@startuml
!define ARCHIMATE_COLOR #6495ED

class LoanProcess {
  + requestLoan(amount: int, purpose: String)
  + checkEligibility(borrower: Borrower)
  + calculateInterestRate(amount: int, purpose: String)
  + issueLoan(borrower: Borrower, amount: int)
}

class Borrower {
  + name: String
  + address: String
  + income: int
}

class Bank {
  + name: String
  + address: String
  + processLoan: LoanProcess
  + approveLoan(borrower: Borrower, amount: int)
}

Borrower -> LoanProcess : request loan
LoanProcess -> Borrower : check eligibility
LoanProcess -> Bank : calculate interest rate
Bank -> LoanProcess : approve loan
LoanProcess -> Borrower : issue loan
@enduml

chatgpt-01-code-PlantUML-ArchiMate-diagram-bank-loan-proces-.png

 

Test #2

La même demande après lui avoir donné un exemple

Question :

 

"Can you generate a similar plantuml code for a bank process"

 

Réponse :

 

@startuml
skinparam rectangle<<behavior>> {
    roundCorner 25
}
sprite $bProcess jar:archimate/business-process
sprite $aService jar:archimate/application-service
sprite $aComponent jar:archimate/application-component

rectangle "Handle claim"  as HC <<$bProcess>><<behavior>> #Business
rectangle "Capture Information"  as CI <<$bProcess>><<behavior>> #Business
rectangle "Notify\nAdditional Stakeholders" as NAS <<$bProcess>><<behavior>> #Business
rectangle "Validate" as V <<$bProcess>><<behavior>> #Business
rectangle "Investigate" as I <<$bProcess>><<behavior>> #Business
rectangle "Pay" as P <<$bProcess>><<behavior>> #Business

HC *-down- CI
HC *-down- NAS
HC *-down- V
HC *-down- I
HC *-down- P

CI -right->> NAS
NAS -right->> V
V -right->> I
I -right->> P

rectangle "Scanning" as scanning <<$aService>><<behavior>> #Application
rectangle "Customer admnistration" as customerAdministration <<$aService>><<behavior>> #Application
rectangle "Claims admnistration" as claimsAdministration <<$aService>><<behavior>> #Application
rectangle Printing <<$aService>><<behavior>> #Application
rectangle Payment <<$aService>><<behavior>> #Application

scanning -up-> CI
customerAdministration  -up-> CI
claimsAdministration -up-> NAS
claimsAdministration -up-> V
claimsAdministration -up-> I
Payment -up-> P

Printing -up-> V
Printing -up-> P

rectangle "Document\nManagement\nSystem" as DMS <<$aComponent>> #Application
rectangle "General\nCRM\nSystem" as CRM <<$aComponent>>  #Application
rectangle "Home & Away\nPolicy\nAdministration" as HAPA <<$aComponent>> #Application
rectangle "Home & Away\nFinancial\nAdministration" as HFPA <<$aComponent>>  #Application

DMS .up.|> scanning
DMS .up.|> Printing
CRM .up.|> customerAdministration
HAPA .up.|> claimsAdministration
HFPA .up.|> Payment

legend left
Example from the "Archisurance case study" (OpenGroup).
See
====
<$bProcess> :business process
====
<$aService> : application service
====
<$aComponent> : application component
endlegend
@enduml
Can you generate a similar plantuml code for a bank process

Certainly! Here is an example of PlantUML code for a bank loan process:

@startuml
skinparam rectangle<<behavior>> {
    roundCorner 25
}
sprite $bProcess jar:archimate/business-process
sprite $aService jar:archimate/application-service
sprite $aComponent jar:archimate/application-component

rectangle "Loan Application" as LA <<$bProcess>><<behavior>> #Business
rectangle "Verification" as V <<$bProcess>><<behavior>> #Business
rectangle "Credit Check" as CC <<$bProcess>><<behavior>> #Business
rectangle "Approval" as A <<$bProcess>><<behavior>> #Business
rectangle "Funding" as F <<$bProcess>><<behavior>> #Business

LA *-down- V
V *-down- CC
CC *-down- A
A *-down- F

rectangle "Customer\nInformation\nSystem" as CIS <<$aService>><<behavior>> #Application
rectangle "Credit\nBureau\nSystem" as CBS <<$aService>><<behavior>> #Application
rectangle "Loan\nAdministration\nSystem" as LAS <<$aService>><<behavior>> #Application
rectangle "Payment\nSystem" as PS <<$aService>><<behavior>> #Application

CIS -up-> LA
CBS -up-> CC
LAS -up-> A
LAS -up-> F
PS -up-> F

rectangle "Database" as DB <<$aComponent>> #Application
rectangle "CRM\nSystem" as CRM <<$aComponent>>  #Application
rectangle "Financial\nAdministration\nSystem" as FAS <<$aComponent>> #Application

DB .up.|> CIS
DB .up.|> CBS
CRM .up.|> CIS
FAS .up.|> PS

legend left
Example of a bank loan process.
See
====
<$bProcess> : business process
====
<$aService> : application service
====
<$aComponent> : application component
endlegend
@enduml

This code will create a diagram that visualizes the loan application process in a bank. The customer submits their information, which is verified and goes through a credit check. Based on the results, the loan is approved or rejected and, if approved, the funds are disbursed. The diagram also shows the relationships between the various business processes, application services, and application components involved in the loan process.

 

Test #3

Zoom sur le sous-processus de vérification

Question :

 

"Like the previous plantuml diagram, can you give me the plantuml code for the Verification process ?"

 

Réponse :

 

Here is an example of a PlantUML diagram for a Verification process:

 

@startuml
skinparam rectangle<<behavior>> {
    roundCorner 25
}
sprite $bProcess jar:archimate/business-process
sprite $aService jar:archimate/application-service
sprite $aComponent jar:archimate/application-component

rectangle "Verify Information" as VI <<$bProcess>><<behavior>> #Business
rectangle "Collect Information" as CI <<$bProcess>><<behavior>> #Business
rectangle "Check Credibility" as CC <<$bProcess>><<behavior>> #Business
rectangle "Notify Customer" as NC <<$bProcess>><<behavior>> #Business

CI *-down- VI
VI *-down- CC
CC *-down- NC

rectangle "Information Gathering" as IG <<$aService>><<behavior>> #Application
rectangle "Data Validation" as DV <<$aService>><<behavior>> #Application
rectangle "Notification" as N <<$aService>><<behavior>> #Application

IG -up-> VI
DV -up-> CC
N -up-> NC

rectangle "Know Your Customer (KYC)" as KYC <<$aComponent>> #Application
rectangle "Credit Bureau" as CB <<$aComponent>> #Application
rectangle "Notification System" as NS <<$aComponent>> #Application

KYC .up.|> IG
CB .up.|> DV
NS .up.|> N

legend left
Example of a verification process.
See
====
<$bProcess> :business process
====
<$aService> : application service
====
<$aComponent> : application component
endlegend
@enduml

 

Test #4

Description textuelle du cas d'utilisation "Demander un prêt bancaire"

Examinons maintenant ce que va nous donner ChatGPT pour le cas d'utilisation cas d'école "Demander un prêt bancaire".

 

Question :

 

"Lets define a simple use case in bank loan, something that is very well established and easy to understand"

 

Réponse :

 

Sure, let's consider the use case of obtaining a personal loan from a bank.

 

Here's how the process might work:

 

1. A customer starts by researching different banks and comparing their personal loan options.
2. Once the customer has found a loan that they are interested in, they complete a loan application, which requires them to provide personal and financial information, such as their income, employment history, and credit score.
3. The bank uses this information to determine the customer's creditworthiness and assess their ability to repay the loan.
4. If the customer is approved for the loan, they receive an offer with the loan terms, including the interest rate, monthly payment amount, and repayment period.
5. If the customer accepts the loan offer, they sign the loan agreement and provide any necessary documentation, such as proof of income or collateral.
6. The bank then disburses the loan funds to the customer, either as a lump sum payment or in installments.
7. The customer then repays the loan over time, including both the principal amount and the interest, according to the terms agreed to in the loan agreement.

 

This is just a basic example of how a personal loan from a bank works, but it should give you an idea of how individuals can use loans to access the funds they need for a variety of purposes, from paying for large expenses to consolidating debt.

 

Test #5

Tableau du modèle métier d'un prêt bancaire

Évidemment il s'agit du processus standard. Pour un cas plus spécifique, il suffirait d'ajouter les informations métier supplémentaires.

Demandons-lui le modèle métier sous forme de tableau au format standard markdown.

 

Question :

 

"Describe the data model in more detail or tabular format using markdown"

 

Réponse :

 

 

Test #6

Diagramme de classe UML d'un prêt bancaire

Question :

 

"this is perfect, I would like to depict the relationships in a plantuml diagram, can you give me the code to do this"

 

Après détection d'une erreur de syntaxe dans PlantUML :

"there is a syntax error about class Loan Application, I think there is no space in the class name"

 

Réponse :

 

I apologize, you're correct. Here's the corrected PlantUML code:

 

@startuml
title Personal Loan Data Model Relationships

class Customer {
  + CustomerID: Integer
  + Name: String
  + Address: String
  + PhoneNumber: String
  + Email: String
  + DateOfBirth: Date
  + SocialSecurityNumber: String
}

class LoanApplication {
  + LoanApplicationID: Integer
  + CustomerID: Integer
  + LoanAmount: Decimal
  + LoanPurpose: String
  + Status: String
  + DateSubmitted: Date
}

class LoanOffer {
  + LoanOfferID: Integer
  + LoanApplicationID: Integer
  + InterestRate: Decimal
  + MonthlyPaymentAmount: Decimal
  + RepaymentPeriod: Integer
  + DateOffered: Date
}

class LoanAgreement {
  + LoanAgreementID: Integer
  + LoanOfferID: Integer
  + DateSigned: Date
  + CollateralInformation: String
  + RepaymentTerms: String
}

class LoanRepayment {
  + LoanRepaymentID: Integer
  + LoanAgreementID: Integer
  + PaymentAmount: Decimal
  + PaymentDate: Date
  + Balance: Decimal
}

Customer "1" -- "1..*" LoanApplication
LoanApplication "1" -- "1" LoanOffer
LoanOffer "1" -- "1" LoanAgreement
LoanAgreement "1" -- "1..*" LoanRepayment

@enduml

 

Test #7

Diagramme de séquence UML pour le prêt bancaire

Question :

 

"How would a client asking for a bank loan impact the classes mentioned above, I would like to depict this as a sequence diagram. Can you help describe the diagram in code for plantuml"

 

Réponse :

 

Certainly! Here's a PlantUML sequence diagram that depicts the interaction between a client and the classes in the personal loan use case when the client applies for a loan:

 

@startuml
title Personal Loan Application Sequence Diagram

participant Customer
participant LoanApplication
participant LoanOffer
participant LoanAgreement

Customer -> LoanApplication: Submit Loan Application

Note right of LoanApplication: LoanApplication\nvalidates the application

LoanApplication -> LoanOffer: Generate Loan Offer

Note right of LoanOffer: LoanOffer\ncalculates loan terms and conditions

LoanOffer -> Customer: Present Loan Offer

Note right of Customer: Customer\nreviews and accepts loan offer

Customer -> LoanAgreement: Sign Loan Agreement

Note right of LoanAgreement: LoanAgreement\nrecords loan agreement details

@enduml

 

This diagram depicts the interactions between the customer, the LoanApplication class, the LoanOffer class, and the LoanAgreement class when a client applies for a personal loan. The customer submits a loan application to the LoanApplication class, which validates the application. The LoanApplication class then generates a loan offer by calculating loan terms and conditions and presenting the offer to the customer. If the customer accepts the loan offer, they sign the loan agreement, which is recorded by the LoanAgreement class.

 

Test #8

Diagramme états/transitions UML pour le prêt bancaire

Question :

 

"Will the loan have states like new, closed, active inactive, cancelled, etc ? I would like to depict the states in a state diagram using plantuml. Can you help describe the diagram in code for plantuml"

 

Réponse :

 

@startuml
title Personal Loan State Diagram

[*] --> New
[*] --> Active : Loan Agreement Signed
New --> Cancelled : Loan Application Cancelled

Active --> Inactive : Loan Repayment Completed
Active --> Closed : Loan Agreement Terminated

Inactive --> Active : Loan Repayment Resumed

Closed --> Cancelled : Loan Agreement Cancelled
@enduml

 

Test #9

Mind map pour un prêt bancaire

Question :

 

"Let's start by creating a simple MindMap on the topic of Bank Loan 
Can you give the mindmap in PlantUML format. Keep it structured from the core central topic branching out to other domains and sub-domains. Let's go to 5 levels to begin with. Add the start and end mindmap tags and keep it expanding on one side for now"

 

Remarque : au 1er essai ChatGPT nous dit que les diagrammes de mind map n'existent pas dans PlantUML.

 

Nous lui donnons alors l'exemple fourni dans la documentation de PlantUML.

 

Réponse :

 

I apologize for the earlier confusion. You are correct, PlantUML does support mind map diagrams. Here's an example of a simple mind map for the topic of "Bank Loan":

 

@startmindmap
* Bank Loan
** Loan Types
*** Personal Loan
*** Home Loan
*** Car Loan
*** Education Loan
*** Business Loan
** Loan Requirements
*** Proof of Income
*** Credit History
*** Collateral
*** Loan Application
** Loan Approval Process
*** Application Review
*** Credit Check
*** Risk Assessment
*** Approval Decision
** Loan Repayment
*** Repayment Terms
*** Interest Rate
*** Penalty for Default
*** Loan Refinancing
@endmindmap

 

This mind map starts with the central topic of "Bank Loan" and branches out to different loan types, loan requirements, the loan approval process, and loan repayment. Each sub-topic is indented and connected to the central topic.

 

Test #10

Un pattern ArchiMate : Strategic Value Map View

Question :

 

"Like the previous plantuml diagram, can you give me the plantuml code for the Strategic Value Map View ?"

 

Réponse :

 

Here is a sample PlantUML code for the Strategic Value Map View pattern in ArchiMate:

@startuml
skinparam rectangle<<strategy>> {
roundCorner 25
}

sprite $goal jar:archimate/goal
sprite $businessActor jar:archimate/business-actor

rectangle "Improve Loan Processing Efficiency" as ILPE <<$goal>><<strategy>> #Business
rectangle "Satisfy Customer Needs" as SCN <<$goal>><<strategy>> #Business
rectangle "Maximize Profit" as MP <<$goal>><<strategy>> #Business
rectangle "Customer" as C <<$businessActor>> #Business

ILPE *-down-> SCN
SCN *-down-> MP
C -- ILPE
legend left
Example of a Strategic Value Map view pattern in ArchiMate.
See
<$goal> : goal

<$businessActor> : business actor
endlegend
@enduml

 

Test #11

Business Model Canvas View

Question :

 

"Like the previous plantuml diagram, can you give me the plantuml code for the Business Model Canvas View ?"

Réponse :

 

Unfortunately, PlantUML does not have built-in support for creating a Business Model Canvas view. You may need to find a plugin or create your own custom shapes to represent the elements of the Business Model Canvas in PlantUML.

 

Test #12

Plus on donne d'informations à ChatGPT, meilleure sera la réponse. Exemple d'une librairie en ligne.

Question :

 

Give me the code for PlantUML corresponding of a class diagram for an online library with Author, Book, User, ShoppingCartLine, ShippingCart, PurchaseOrder and Status. Don't forget the multiplicity. Author wrote 0 or several Book and a Book is written by 0 or several Author. A User is an aggragate of 0 or several ShoppingCart which is an aggragate of 0 or several ShoppingCartLine which is linked at a Book. A PurchaseOrder is linked at one User and one ShoppingCart. The Status are pending and shipped.

 

Réponse :

 

class Author {
  +writtenBooks(): Book[]
}

class Book {
  +writtenByAuthors(): Author[]
  +belongsToShoppingCartLine(): ShoppingCartLine[]
}

class User {
  +hasShoppingCarts(): ShoppingCart[]
  +hasPurchaseOrders(): PurchaseOrder[]
}

class ShoppingCartLine {
  +belongsToShoppingCart(): ShoppingCart
  +linkedToBook(): Book
}

class ShoppingCart {
  +belongsToUser(): User
  +containsShoppingCartLines(): ShoppingCartLine[]
  +hasPurchaseOrder(): PurchaseOrder
}

class PurchaseOrder {
  +belongsToUser(): User
  +belongsToShoppingCart(): ShoppingCart
  +hasStatus(): Status
}

class Status {
  +pending
  +shipped
}

Author "0..*" -- "0..*" Book
User -- "0..*" ShoppingCart
ShoppingCart -- "0..*" ShoppingCartLine
ShoppingCartLine -- Book
PurchaseOrder -- User
PurchaseOrder -- ShoppingCart

 

Test #13

Qu’en est-il pour du code plus verbeux comme XMI représentant un processus BPMN ?

Ouvrir le code avec : https://bpmn.io/

 

Question :

 

Write BPMN code for a pizza command

 

Réponse :

 

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_1" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="11.3.1">
  <bpmn:process id="Process_1" isExecutable="false">
    <bpmn:startEvent id="StartEvent_1">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_1" name="Receive Pizza Order">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_2" name="Prepare Pizza">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_3" name="Bake Pizza">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_4" name="Deliver Pizza">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="EndEvent_1">
      <bpmn:incoming>Flow_5</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="StartEvent_1" targetRef="Task_1" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_1" targetRef="Task_2" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_2" targetRef="Task_3" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_3" targetRef="Task_4" />
    <bpmn:sequenceFlow id="Flow_5" sourceRef="Task_4" targetRef="EndEvent_1" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_1">
    <bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Process_1">
      <bpmndi:BPMNShape id="_BPMNShape_StartEvent_2" bpmnElement="StartEvent_1">
        <dc:Bounds x="173" y="102" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="157" y="142" width="68" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Task_1_di" bpmnElement="Task_1">
        <dc:Bounds x="259" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Task_2_di" bpmnElement="Task_2">
        <dc:Bounds x="443" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Task_3_di" bpmnElement="Task_3">
        <dc:Bounds x="632" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Task_4_di" bpmnElement="Task_4">
        <dc:Bounds x="825" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="_BPMNShape_EndEvent_2" bpmnElement="EndEvent_1">
        <dc:Bounds x="1018" y="102" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1002" y="142" width="68" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Flow_1_di" bpmnElement="Flow_1">
        <di:waypoint x="209" y="120" />
        <di:waypoint x="259" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_2_di" bpmnElement="Flow_2">
        <di:waypoint x="359" y="120" />
        <di:waypoint x="443" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_3_di" bpmnElement="Flow_3">
        <di:waypoint x="543" y="120" />
        <di:waypoint x="632" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_4_di" bpmnElement="Flow_4">
        <di:waypoint x="732" y="120" />
        <di:waypoint x="825" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_5_di" bpmnElement="Flow_5">
        <di:waypoint x="925" y="120" />
        <di:waypoint x="1018" y="120" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

 

Annexe 2

Les principaux concurrents à ChatGPT
en attendant la réponse de Google

• Chatsonic
   
• YouChat
   
• Copysmith
   
• Copymatic

 

 

Existe-t-il des outils idoines et en plus gratuits pour la mise en œuvre efficiente de l’Architecture d’Entreprise (AE) ? Voici notre classement des 5 meilleurs, d’après nos tests complets réalisés en 2022.

 

  

   

L’outil idéal serait un croisement de Modelio, Visual Paradigm, ADOIT:CE, Archi et GenMyModel.

 

Pas de leader parmi les outils gratuits d’AE

Dans le domaine de l’IA, nous voyons apparaître des disrupteurs gratuits comme ChatGPT d’OpenAI qui pénètre le marché, le révolutionne et bouleverse un grand nombre de domaines comme l’ingénierie logicielle, les productions de contenus textuels, la prospective, les arts, etc.

En est-il de même dans le monde de l’Architecture d’Entreprise (AE) ? Des outils open source comme Modelio, Visual Paradigm, ADOIT:CE ou encore Archi peuvent-ils couvrir tous les aspects de l’AE ? Peuvent-ils répondre aux exigences des urbanistes de SI, des architectes logiciels, des business analysts et autres consultants en IT ?

 

Le modèle open source est un facteur primordial d’innovation permettant la démocratisation et le partage de connaissances. Il offre au monde éducatif, universités, écoles d’ingénieurs ou de reconversion, professeurs, étudiants souvent sans grands moyens, la possibilité de sortir d’un monde livresque, de mettre en pratique des concepts théoriques et d’accéder à des études de cas tirées de retours d’expérience de projets réels.

 

Modsars 2023, le palmarès d’urbanisation-si.com
des outils gratuits de modélisation

 

2 outils français dans le classement cette année.

 

1ère place : Modelio

 

 

 

Modelio, le seul outil open source fonctionnant sur Windows, Linux, Mac OS, supportant ArchiMate, TOGAF, BPMN, UML, SysML, MDA et offrant, pour tous ces artefacts de modélisation, un référentiel commun assurant la traçabilité depuis la stratégie jusqu’à la couche technologique. Modelio offre une étude de cas exhaustive illustrant l’architecture d’une agence de voyages fictive. L'éditeur Softeam, société de conseils et de services, est français, c'est une filiale de Docaposte.

 

2ème place : Visual Paradigm (online) 

 

 

 

Visual Paradigm Online : sa gratuité, sa facilité d’installation en mode SaaS ne demandant aucune connaissance technique, la possibilité de partager son écran à des coéquipiers et les nombreux exemples ArchiMate, BPMN, UML, prêts à être adaptés, font de Visual Paradigm un excellent outil pédagogique pour mettre en pratique l’art de la modélisation. 

 

3ème place : ADOIT:CE

 

 

ADOIT:CE : rien à installer, toujours la dernière version en ligne, interface utilisateur relativement simple, support complet d’ArchiMate, 35 vues différentes proposées, nombreuses fonctionnalités, gestion de portefeuille d'application, Master Data Management, un contenu de démonstration de l’architecture d’une banque fictive, etc.

 

 

4ème place : Archi (archimatetool)

 

 

Archi (archimatetool) : convient parfaitement au consultant pour des missions ponctuelles. L'absence de mode collaboratif finalisé, nécessitant des installations locales aussi simples soient-elles, prive Archi de pouvoir être utilisé dans une équipe d'architectes d'entreprise.

Alors que Modelio, son concurrent direct comme outil open source de modélisation pour l’Architecture d’Entreprise, est en français, supporte en plus d’ArchiMate, BPMN, UML, SysML, MDA avec un référentiel commun et fourni une étude de cas pédagogique, Archi n’intègre qu’ArchiMate et donc n’est pas archi complet.

 

 

5ème place : GenMyModel

 

 

GenMyModel est une plate-forme française de conception logicielle basée sur les normes UML pour la modélisation de systèmes, BPMN pour les processus d'entreprise, DMN pour les règles métier et AchiMate pour l’Architecture d’Entreprise. Complètement accessible dans le cloud en mode SaaS, il fournit des générateurs de code intégrés pour Java, SQL, Spring…

 

A quoi reconnaît-on un bon outil
d’Architecture d’Entreprise ?

 

Les outils EA aident à imaginer, modéliser et planifier l'avenir de l'entreprise, avec des fonctionnalités permettant de faire évoluer en permanence les modèles commerciaux et opérationnels. Les responsables de l'architecture d'entreprise et de l'innovation technologique doivent sélectionner des outils EA qui soutiennent les objectifs de transformation, de modernisation et d'innovation à long terme.

 

Voici les principales fonctionnalités que doit posséder l'outil idéal pour l'Architecture d'Entreprise et l'Urbanisation du SI.

 

Référentiel central et collaboratif

Un référentiel central et collaboratif permet de gérer l'ensemble des objets et métadonnées sur les artefacts dont une entreprise se soucie, il offre une vue partagée du SI, comprise de tous, et permet d'anticiper l’évolutivité des services métier de l’entreprise.

Il doit intégrer la gouvernance, la gestion du cycle de vie des objets, le versioning, les accès, les typologies, les cartographies, les modèles et artefacts de modélisation, les relations et vues métier associées.

 

Contrôle de l'alignement du SI avec le métier

Il s'agit de mettre en œuvre un support à un alignement du SI avec un métier en constante évolution, facilitant la synergie, le partage et la collaboration.

 

Gestion du changement

Permettre d’examiner à la fois le besoin et l'impact du changement. 

 

Métrique de couplage entre les écosystèmes

Capturer les interrelations et les interdépendances au sein et entre un écosystème de partenaires, de modèles d'exploitation, de capacités, de personnes, de processus, d'informations, d'applications et de technologies. 

 

Socle d’architecture d’entreprise exhaustif, supportant les standards du marché

Disposer d’un socle d’architecture d’entreprise exhaustif et ouvert supportant les standards du marché (TOGAF, ArchiMate, BPMN, UML…).

Le support de TOGAF doit comprendre une bibliothèque de méthodes décrivant l’ensemble de l’ADM (Architecture Development Method) avec les différentes phases, les entrées, les sorties, les livrables, les rôles…

La modélisation doit structurer les relations entre les entités, telles que les stratégies commerciales, les objectifs, les buts, les contraintes, les capacités, les personnalités, les parcours des clients, les activités, les processus, les flux de valeur, les politiques, les modèles de décision, les métriques, les applications, les technologies, les feuilles de route, les projets et les programmes…

 

Approche capacitaire

Gérer les capacités métier afin de répondre aux besoins et enjeux du business, dans un contexte numérique. Cette approche capacitaire se concentre avant tout sur les besoins des métiers et permet aux équipes d’architecture de coller au plus près à la stratégie de l’entreprise.

 

Fonctions d’analyse et de reporting

Posséder des fonctions d’analyse et de reporting nécessaire à l’optimisation du patrimoine applicatif de l’entreprise, en lien avec la cartographie applicative et les méthodes d’urbanisation du SI.

 

Cloud et modélisation

Supporter les dernières méthodes d’architecture logicielle, le cloud, la modélisation systémique, la modélisation complexes comme les systèmes de systèmes.

 

Portfolio d'application

Gérer le portefeuille applicatif, les ressources, les projets, la gouvernance, les risques et la mise en conformité des opérations.

 

Vérification de la conformité et simulation des diagrammes

Intégrer la validation des diagrammes, avec la description détaillée des erreurs et des propositions de solutions pédagogiques.

 

Aides à la compréhension des impacts liés aux solutions

Présenter les informations sous forme de tableaux de bord, de cartes thermiques, de Sketch View, de Business Model Canvas, de modèles et de scénarios. Cela aide à comprendre et à évaluer les impacts associés aux décisions et aux solutions proposées.

 

Utilisabilité

Être convivial, facile d'utilisation permettant la prise en charge de différentes catégories d'utilisateurs. Outre les architectes d'entreprise, cela inclut les utilisateurs de n'importe où dans l'entreprise, les analystes, les utilisateurs métier, les architectes logiciels, les analystes stratégiques et les chercheurs opérationnels.

 

Administration des accès et sécurité

Gérer l’administration pour prendre en charge la sécurité de l'outil EA, ainsi que la configuration de différentes classes d'utilisateurs, leurs droits d'accès et l'alignement des fonctionnalités. Cela implique également de contrôler l'accès aux informations stockées dans le référentiel.

 

Extensibilité 

Être extensible avec la possibilité d'étendre le métamodèle de l'outil EA via la définition de nouveaux concepts de modélisation et de types de relations, jusqu'à de nouvelles représentations graphiques et l'application de règles spécifiques au domaine.

 

Exportation / Importation des données

Exporter et importer les données vers et depuis d'autres produits, permettant à l'outil EA d'être une plaque tournante réunissant d'autres outils communs dans un écosystème technologique d’entreprise. 

 

Management de l'innovation

Gérer l'innovation en soutenant la création et le suivi des initiatives de changement. Cela inclut le soutien à l'idéation, la détection des tendances et l'engagement de tous les acteurs.

 

Qu’en pense ChatGPT, la star des IA ?

Notre question

Nous avons posé la question suivante à ChatGPT, l’IA conversationnelle d’OpenAI :
" Top 5 des outils gratuits complets pour l'Architecture d'Entreprise ? "

 

Sa réponse

Enterprise Architect : un outil de modélisation d'entreprise complet qui prend en charge une variété de méthodologies et de standards, y compris ArchiMate, UML, BPMN, SysML, et les architectures d'entreprise. Il inclut également des fonctionnalités de gestion de projet, de gestion de portefeuille et de gestion de la conformité.

 

BizzDesign Architect : un outil d'architecture d'entreprise complet qui permet de créer des modèles visuels de processus, de données et de systèmes, ainsi que de gérer les aspects de la gouvernance et de la conformité de l'architecture d'entreprise.

 

Sparx Systems Enterprise Architect : un outil de modélisation d'entreprise complet qui prend en charge une variété de méthodologies et de standards, y compris ArchiMate, UML, BPMN, SysML, et les architectures d'entreprise. Il inclut également des fonctionnalités de gestion de projet, de gestion de portefeuille et de gestion de la conformité.

 

MagicDraw : un outil de modélisation unifiée qui prend en charge UML, BPMN, SysML, et les architectures d'entreprise, avec des fonctionnalités de gestion de projet, de gestion de portefeuille et de conformité pour aider les utilisateurs à créer des modèles visuels pour les processus, les systèmes et les données.

 

Visual Paradigm: un outil de modélisation d'entreprise complet qui prend en charge UML, BPMN, SysML, ArchiMate et les diagrammes de cas d'utilisation pour créer des modèles d'architecture d'entreprise, inclut également des fonctionnalités de gestion de projet, de gestion de portefeuille et de conformité pour aider les utilisateurs à gérer les aspects de la gouvernance et de la conformité de l'architecture d'entreprise.

 

Il est important de noter que la meilleure solution dépendra des besoins spécifiques de l'entreprise et de son niveau de maturité en matière d'architecture d'entreprise. Il est donc important de faire des recherches et des essais pour choisir l'outil qui convient le mieux à votre entreprise.

 

Notre avis sur la réponse de ChatGPT 

Pour ChatGPT Enterprise Architect et Sparx Systems Enterprise Architect sont 2 outils différents, alors qu'il s'agit du même outil, bien entendu. 

Malgré que l'on ait bien précisé "gratuits", ChatGPT a cité 4 outils payants sur 5. 

Enterprise Architect ne possède aucune version gratuite.

BizzDesign Architect est payant, il n’y a aucune version gratuite, même limitée.

Magic Draw est payant, on peut télécharger une version d’essai limitée dans le temps.

 

Le seul outil gratuit étant Visual Paradigm, qui arrive en 2ème position dans notre TOP 5.

 

ChatGPT a été entraîné avec des milliards de données prises sur internet (web scraping). Est-il possible que certaines de ces données soient obsolètes ?

 

Conclusion

 

L’outil idéal serait un croisement de :

 

• Modelio pour la fonctionnalité d’un référentiel commun d’Entreprise, le support d’ArchiMate, TOGAF, BPMN, UML, SysML, MDA, la validation des modèles, la traçabilité des objets du référentiel assurant l’alignement du SI sur le métier, la génération de rapports, le support d’un langage de script permettant l’automatisation.
  
  
• Visual Paradigm pour ne nécessiter aucune installation en local, être en mode Cloud, le mode collaboratif à la Google. 
  
  
• ADOIT:CE pour le cas complet de démonstration d’une banque, la gestion du portfolio d’applications, le Master Data Management, les matrices de traçabilité, les visuels.
  
  
• Archi pour la Sketch View, les conseils et la documentation sur ArchiMate.
  
  
• GenMyModel pour DMN (modélisation de règles métier), pour les générateurs de code intégrés pour Java, SQL, Spring…

 

L’outil gratuit open source d’AE capable de disrupter le marché n’est donc pas encore né. 

Si les outils précédents conviennent parfaitement au monde de l’éducation et aux PME, les très grandes organisations aux moyens plus conséquents se tournent volontiers vers les logiciels commerciaux comme MEGA, BOC Group, LeanIX, ...

 

Etes-vous certain que cet article a été rédigé par un humain et non pas par ChatGPT ?

 

 

Rhona Maxwel urbanisation-si.com @rhona_helena

 

 

"L'intelligence artificielle est la prochaine grande révolution de notre époque et les modèles de traitement du langage comme ChatGPT en sont un exemple évident."

ChatGPT

 

"Il est consolant de constater que la dysharmonie de ce monde ne semble être que numérique."

Franz Kafka

 

 

Annexe : liste de nos essais

 

Evaluations des outils gratuits/open source

Nous avons pris le parti dans cette série de tests, d’évaluer uniquement des outils gratuits-open source ou proposant une version d’évaluation ne nécessitant pas de sortir sa carte de crédit ou la visite d’un commercial pour obtenir une licence de prêt.

 

• Modelio
  
  
• Visual Paradigm (online)
  
  
• ADOIT:CE (BOC Group) et ADOIT:CE (compléments d’information)
  
  
• Archi (archimatetool)
  
  
• GenMyModel
  
  
• Camunda (les tests spécifiques sont à venir, nous l'indiquons ici, car nous l'avons utilisé maintes fois comme illustration d'articles et au cours de divers projets)
  
  
• Papyrus
  
  
• Eclipse Modeling Tools
  
  
• diagrams.net ou draw.io
  
  
• Texte vers UML et autres outils de "diagrammes en tant que code"
  
  
• Sirius (Obéo) :
  • Améliorations et notions avancées Eclipse Sirius, suite et fin de notre saga : comment concevoir son propre outil de modélisation DMN ? [4/4]
  • Ingénierie Dirigée par les Modèles : fini Eclipse GMF, vive Eclipse Sirius ( didacticiel / tutoriel Sirius)
  • Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : le digne successeur de GMF le framework le plus complexe du monde !
  • Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : on peaufine l'éditeur de diagramme
    

 

 

Les outils payants, mais abordables, et que nous aimons bien

• Enterprise Architect Sparx Systems :
  • 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…
    
    
• WinDesign (outil français, incluant une étude de cas exhaustive illustrant l’architecture d’une compagnie d'assurance fictive.)

 

Les différents niveaux d'architecture répondent à différents niveaux de préoccupations et ont des publics différents. Le cadre d'architecture et le référentiel doivent aider à garantir que ces architectures soient stratifiées et synchronisées, afin qu’elles forment une vision cohérente et équilibrée de l'ensemble de l'entreprise. 

 

       

Les niveaux d'architecture selon TOGAF
(diagramme UML de package réalisé avec Modelio Open Source)

   

La dénomination des niveaux a été influencée par
“The Open Group Architecture Framework” (TOGAF). 

Une entreprise a une structure complexe et généralement hiérarchique, et l'on doit créer des architectures à des niveaux discrets de cette structure. Cette hiérarchie d'architectures est analogue aux hiérarchies d'objectifs et de capacités, et s'aligne intuitivement sur les divisions au niveau stratégique, programme et projet. Dans une petite organisation, il est possible de créer une architecture unique qui couvre le niveau stratégique et les niveaux de projet ou de capacité, mais dans une grande entreprise, au moins trois niveaux distincts sont généralement nécessaires :

 

• Stratégique - Long terme, de l'ordre de 3 à 5 ans,
   
• Tactique - Moyen terme, de l'ordre de 1 à 2 ans,
  
  
• Solution - Court terme, de l'ordre de 6 à 12 mois.

  

Les architectures Stratégiques

  

  

Exemples d'Architectures Stratégique, Tactique et de Solutions
(diagramme UML de package réalisé avec Modelio Open Source)

  

Elles décrivent des plans et des initiatives stratégiques et s'exécutent généralement pendant des années. Les architectures stratégiques fournissent des plans à long terme, qui sont généralement des visions de l'avenir sur une période de trois à cinq ans.
La période peut être plus longue pour les industries ou les entreprises qui ne sont pas affectées par des environnements dynamiques et perturbateurs. Les architectures stratégiques doivent prendre en charge ou s'aligner sur les objectifs stratégiques de l'entreprise.

 

La technologie de modélisation stratégique dispose d'un certain nombre d'outils qui peuvent être utilisés, tels que le diagramme “Balanced Scorecard”, qui peut aider à identifier les objectifs liés à l’IT.

  

    

Diagramme "Balanced Scorecard" (diagramme réalisé avec Visual Paradigm)

    

 

Les architectures Tactiques

  

  

Exemples d'Architecture Tactique intégrant des architectures de solutions
(diagramme UML de package réalisé avec Modelio Open Source) 

  

Elles décrivent des plans intermédiaires qui aident à partitionner les architectures de niveau Stratégique en groupes gérables.

Elles peuvent généralement durer un certain nombre d'années et représenter une feuille de route au niveau du portefeuille applicatif ou des étapes sur la manière d'atteindre les objectifs exprimés dans les architectures Stratégiques auxquelles ils se rapportent.

Elles agissent comme un cadre pour l'organisation au niveau des solutions et assurent que les capacités sont développées et qu'elles créent finalement de la valeur métier. 

  

Les diagrammes de “Roadmap” peuvent être utilisés à tous les niveaux de l'architecture Tactique, y compris les Architectures d'Entreprise, d'Information, d'Application et de Technologie, montrant le séquencement temporel des actions au niveau d'un portefeuille applicatif ou d'un programme.

  

Exemple de diagramme de "Roadmap" (diagramme réalisé avec ADOIT:CE)

     

Les architectures de Solutions

Elles décrivent des projets spécifiques ou des activités au niveau des capacités qui peuvent généralement être réalisées en quelques mois, plutôt qu'en plusieurs années. D'un point de vue métier, elles se concentrent généralement sur un problème ou une opportunité particulière. De même, d'un point de vue technique, elles impliquent généralement une tranche des domaines de l'information, des applications et de la technologie, mais peuvent, dans certaines circonstances, nécessiter l'examen d'un certain nombre de ces domaines. 

Les outils doivent aider au niveau de l'architecture de chaque Solution, de la définition des buts et objectifs métier et de leur mise en relation avec les composants d'Information et d'Application, et de Technologie qui sous-tendent les applications. 

L'architecture Métier peut être définie et gérée à l'aide de profils UML (ensemble de stéréotypes, tagged values et contraintes OCL). Cela permet de créer des “Drivers” (représentations des conditions motivant une organisation métier à définir ses objectifs et à mettre en œuvre les changements nécessaires pour les atteindre), des buts et des objectifs, qui peuvent être démontrés aux parties prenantes à l'aide de diagrammes, de matrices et de documentation, publiés automatiquement à partir des modèles.

Des générateurs de schémas de RDBMS et de scripts SQL à partir de diagrammes de classes UML aident à travailler avec l'architecture de l'Information, et les éléments créés peuvent être liés à l'architecture métier. 

Les services applicatifs, les applications et les interfaces peuvent être modélisés, et leurs relations entre eux et avec les éléments des architectures métiers et technologiques peuvent être définies et représentées par des liens de traçabilités entre des artefacts de modélisation appartenant même à des notations différentes, comme ArchiMate, BPMN, DMN, UML…

Les services technologiques, les nœuds et dispositifs technologiques peuvent être gérés et, le cas échéant, peuvent être dérivés du Modèle de référence technique. 

Les outils doivent gérer les exigences architecturales, qui peuvent être liées aux éléments qui composent entreprise, processus métier, fonctions, applications, technologies et autres architectures spécifiques. 

Un framework agile (Kanban, Scrum…) peut être utilisé pour gérer ces projets et garantir que la valeur métier est livrée en temps opportun.

 

Mais au fait, y a-t-il une norme pour représenter
les architectures Stratégiques et Tactiques ?

Vous n'en avez peut-être jamais entendu parler, mais cette norme existe et se nomme BMM (Business Motivation Model). Il s'agit d'un modèle de motivation métier qui fournit aux entreprises un ensemble de notations normalisé par l’OMG (Object Management Group), pour l'élaboration de plans métier. Il permet de modéliser ce que l'entreprise souhaite réaliser, comment y parvenir, les impacts potentiels, les ressources, etc.

  

Voir nos articles consacrés à la norme BMM de l'OMG à la fin, dans les compléments de lecture.

  

  

Exemple de diagramme BMM (diagramme réalisé avec Visual Paradigm)

  

Et l'apport d'ArchiMate ?

La stratégie et les éléments de motivation d'ArchiMate ont été inspirés en partie par BMM.
Bien qu'un mappage entre de nombreux éléments de motivation d'ArchiMate et les concepts BMM soit possible, BMM fournit une description plus détaillée de la motivation, tandis que le langage ArchiMate vise à couvrir un large champ et à interconnecter différents domaines.

  

Voir nos articles consacrés aux éléments de stratégie et de motivation d'ArchiMate à la fin, dans les compléments de lecture.

  

  

Diagramme ArchiMate de la couche Strategy, représentant les objectifs (Goals),
les résultats attendus (Outcomes) et les principes (Principles) (diagramme réalisé avec ADOIT:CE)  

 

La traçabilité comme assurance de l'alignement stratégique

La traçabilité occupe une place transverse et traverse toutes les strates d’architecture.

Il existe plusieurs outils, dont la matrice des relations et les diagrammes de traçabilité, qui peuvent être utilisés pour montrer les relations entre les éléments des architectures d'entreprise, afin de s'assurer qu'ils contribuent tous de manière démontrable à la réalisation des objectifs stratégiques. 

  

  

Matrice de Relations entre Exigences et Cas d’Utilisation et une vue de ces relations
(diagramme réalisé avec Enterprise Architect)
    

Le diagramme de Traçabilité fournit une vue hiérarchique des connexions d'éléments, permettant de visualiser et d'interroger la traçabilité au fur et à mesure qu'on accède aux éléments dans le modèle. Cet outil est particulièrement utile, car un modélisateur choisira souvent de masquer les relations du diagramme, mais en sélectionnant un élément dans le diagramme et en visualisant ses connexions dans la fenêtre Traçabilité, toutes ses relations seront révélées.

  

  

Exemple d'outil de traçabilité (diagramme réalisé avec Enterprise Architect)

  

Conclusion

Pour ne plus souffrir des modèles opérationnels, qui ont subi des changements progressifs et non structurés au fil du temps, devenant souvent des obstacles à la mise en œuvre de leur stratégie, les entreprises ne devraient plus commettre l'erreur d'appliquer leur stratégie de bas en haut (bottom-up), comme si, lors de la conception d’un bâtiment, on s’adressait en premier aux ingénieurs spécialisés dans les fondations.

Pour une entreprise, une approche de haut en bas (top-down) permet de se restructurer, de ne pas risquer de s'éloigner de la réalisation de ses objectifs à long terme, et de respecter l'alignement stratégique. 

  

Rhona Maxwel urbanisation-si.com @rhona_helena

  

"Toute idée devient fausse au moment où l’on s’en contente."

Alain

  

Compléments de lecture

BMM (Business Motivation Model)

• BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
  
  
• BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, …
  
  
• Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
  
  
• Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
  
  
• Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques

 

ArchiMate

• ArchiMate la synthèse : les éléments de motivation
  
  
• ArchiMate en condensé : les éléments de stratégie

 

Outils d'Architecture d'Entreprise

• Essai et évaluation de Modelio : est-il un bon outil de modélisation ?
  
  
• Visual Paradigm : l’eldorado du consultant en quête de présentations dorées, mais est-il un bon outil de modélisation pour l’architecte d’entreprise, voici notre test
  
  
• ADOIT:CE pour la gestion de l’Architecture d’Entreprise
  
  
• Archi (archimatetool) : essai et analyse de cet outil ArchiMate français gratuit sous Windows, Linux et Mac OS
  
  
• 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