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.

“ 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