urbanisation-si.com

urbanisation-si.com

Knowledge Graph et Architecture d’Entreprise (2/2)

Des ontologies modulaires
pour gérer la complexité et la pluridisciplinarité

Un Knowledge Graph, c’est une base de connaissance sous forme de graphe. Pour sa conception, il est crucial de clarifier les questions auxquelles elle devrait pouvoir répondre, ainsi que celles portant sur sa maintenance et son évolution.

 

Une approche clé pour assurer la flexibilité et la maintenabilité d’un Knowledge Graph consiste à le baser sur plusieurs ontologies modulaires inter-reliées, avec un noyau central. Chaque module peut alors être conçu pour traiter des concepts, des relations et des règles spécifiques à un sous-domaine d’expertise, ce qui en facilite la gestion et l’évolution avec les experts du domaine.

 

En reliant ces ontologies modulaires entre elles, on crée un réseau de connaissances. Cela permet de représenter des relations complexes entre les concepts qui transcendent les frontières des différents sous-domaines, offrant ainsi une vue globale et intégrée du domaine métier dans son ensemble. Or c’est typiquement un besoin des descriptions d’architecture de pouvoir représenter des couches d’architecture et leurs correspondances. Ou de présenter des perspectives spécifiques. Par exemple, la gestion des risques, l’architecture applicative, l’architecture des données, l’infrastructure technologique, l’évaluation de la performance…

 

Un noyau central définissant les fondamentaux de l’EA, via les concepts et relations réutilisables pour tous les modules, permettra l’interopérabilité. La référence à une ontologie de haut niveau (top-level) ou des « patrons » de conception servira à ne pas réinventer la poudre pour des problèmes généraux de conception déjà bien connus.

 

Bien entendu, la conception d’un Knowledge Graph d’Architecture d’Entreprise doit suivre les bonnes pratiques. En particulier, réutiliser autant que possible des ontologies existantes et des vocabulaires standards pour éviter la duplication d’efforts et promouvoir la cohérence avec les pratiques établies dans le domaine.

 

Des ontologies pour des Knowledge Graphs agnostiques des cadres de référence

Les concepts décrits dans une ontologie d’Architecture d’Entreprise (ou module), existent indépendamment des cadres de référence ou langages de description. Car si ces derniers sont réutilisables pour les identifier et les définir, ni un glossaire, ni des textes descriptifs, ni des objets graphiques ne spécifient formellement des concepts et des relations. « Things, not strings » : une ontologie définit des choses et les labels donnés aux choses ne suffisent pas pour les définir. Si deux terminologies différentes désignent le même concept, on trouvera un concept et deux labels dans l’ontologie. Quand elles désignent l’une une spécialisation, l’autre une généralisation, on définira les relations de subsomption et les caractéristiques propres des deux concepts. Et si au contraire elles désignent deux choses différentes et disjointes, on doit le définir également.

 

Une ontologie, c’est une représentation sémantique riche des entités et de leurs relations en mesure de suivre l’évolution des connaissances. En utilisant les standards du Web sémantique (RDF, RDFS, OWL), contrairement à certains langages de modélisation plus rigides, les Knowledge Graphs sont flexibles et extensibles. Ils permettent d’ajouter de nouveaux concepts, relations et attributs au fur et à mesure que l’Architecture d’Entreprise évolue, assurant ainsi une représentation toujours à jour et adaptable.

 

Pour prendre l’exemple du langage graphique de description d’architecture ArchiMate, les liens sont limités et certains concepts spécifiques à la stratégie d’offre, au marché, aux situations, aux aspects financiers, ne sont pas dans l’ensemble de ceux prédéfinis.

 

A contrario, un réseau d’ontologies modulaires peut spécifier des concepts dans tous les sous-domaines de gouvernance et de pilotage de l’entreprise et les relier aux capacités de l’entreprise et les composants qui les supportent. Tout Knowledge Graph exploitant ce réseau peut dès lors procurer une représentation plus riche, flexible et contextuelle des éléments clés éclairant les décisions qui engagent l’entreprise.

 

Architecture d’Entreprise et continuum d’ontologies

OntoPortal-Alliance

 

Alliance autour de la technologie OntoPortal

 

La démarche de description d’Architecture d’Entreprise est continue, itérative et incrémentale. On peut difficilement arriver à une architecture unifiée unique qui satisferait à toutes les exigences de toutes les parties prenantes à tout moment et l’idéal d’avoir des documentations et des modèles à jour suivant toutes les perspectives est une utopie dont la mise en œuvre est dystopique.

 

Des plateformes pour réutiliser des ontologies consistantes et cohérentes, ou accéder à des patrons de conception et des outils de développement et de curation pour modéliser et implémenter de nouvelles spécifications, ont été mises en place dans différents secteurs d’industrie. Elles concrétisent une approche réellement FAIR des métadonnées.

 

L’alliance OntoPortal autour de l’outil éponyme (https://ontoportal.org) est significative du besoin de promotion de telles plateformes pour « le développement de référentiels d’ontologie – en science et dans d’autres disciplines ».

 

Le parallèle peut être fait avec la notion de Continuum d’Entreprise qu’on trouve dans TOGAF. L’idée est d’organiser des artefacts d’architecture et des actifs de solutions réutilisables afin de maximiser les opportunités d’investissement dans l’Architecture d’Entreprise. Dans cette optique, la construction de plateformes communes aux architectes d’entreprises pour recevoir, héberger, servir, aligner et permettre la réutilisation d’ontologies pour l’EA a tout son intérêt. On devrait y trouver différentes ontologies d’entreprise et des métamodèles génériques à spécialiser ou étendre.

 

Un métamodèle d’entreprise générique
et un langage graphique : EDGY

EDGY-Design-Facets

 

EDGY enterprise design facets

 

Si toute entreprise a sa propre dynamique, toutes les entreprises partagent le fait d’avoir des produits et/ou services, des offres portant sur ces produits, des processus supportant les opérations, des rôles, des acteurs, des applications des SI avec des composants, etc. On peut très bien s’entendre sur un vocabulaire et des axiomes logiques pour exprimer ce genre de choses et leurs liens.

 

Dans ce domaine, l’initiative de la communauté Intersection Group est à souligner. Car elle introduit, avec l’approche « Enterprise Design with EDGY », un langage graphique simple et expressif pour un métamodèle d’entreprise transverse à tous les métiers. En effet, EDGY propose une vue unifiée et consolidée de l’entreprise à des fins de décision collaborative grâce à l’intersection entre trois perspectives : identité, Expérience et Architecture.

 

La première traite de la raison d’être de l’entreprise aussi bien que de sa culture. A ce sujet, le mantra
« culture eats strategy at breakfast » illustre bien l’importance de ces concepts. La seconde se focalise sur l’expérience procurée aux clients et aux autres acteurs. Une manière également pertinente de traiter dynamiquement de la valeur créée pour les parties prenantes. La dernière s’interroge sur comment orchestrer tout cela, en déclinant modèle d’affaires, modèle opératoire et composants d’architecture.

 

Le credo d’EDGY est d’avancer que les connecteurs nécessaires à créer entre des disciplines traitées aujourd’hui de façon trop isolée se trouvent à l’intersection desdites perspectives, où l’on trouvera les concepts de produit, organisation, marque.

 

L’approche EDGY propose les outils pour élaborer une représentation graphique commune, utile et transverse, des éléments clés de l’entreprise à des fins de décision. Cependant, il lui manque encore la dimension formelle des ontologies, pour disposer également d’une base de connaissances sémantiquement riche.

 

Un outil d’EA basé sur des ontologies :
The Essential Project

Essential-Project-Meta-Model

 

Illustration du Meta-Model d’Essential avec zoom sur partie métier

 

Fournir pour la description des composants d’architecture, un métamodèle à base d’ontologies, flexible et extensible, cela existe déjà. Dès 2009, «The Essential Project » a été lancé par l’équipe des consultants d’EAS (Enterprise Architecture Solutions) sur cette base, en modélisant des ontologies sous Protégé. La première version open source d’Essential (visant les capacités essentielles à une pratique d’EA) date de mars 2009. La mise en relation avec les concepts TOGAF n’est arrivée qu’en 2015.

 

Certes, ce sont des demandes des utilisateurs qui ont conduit à la publication d’un mappage TOGAF vers Essential. Reste que, selon EAS, « le métamodèle Essential est, en fait, plus riche en contenu et prend en charge tous les principaux frameworks EA, tout en restant indépendant du framework ».

 

L’outil Essential a été placé « visionnaire » dans le Gartner Magic Quadrant 2023 des outils d’Architecture d’Entreprise. Si l’on consulte Gartner Peer Reviews, il est globalement bien noté. Avec des commentaires tels que ce dernier : « EAS has a powerful metadata repository that can cover multiple dimensions of the architecture. Also, the look and feel is very appealing, with easy to navigate reports ». Certes, à d’autres égards, notamment les représentations graphiques, il offre moins de richesse que d’autres alternatives.

 

Mais si l’essentiel recherché est d’avoir effectivement les bons liens entre composants, pour une bonne analyse d’impact, il correspond. Grâce à son métamodèle à base d’ontologies. Tandis que ceci est rarement capturé sans la moindre ambiguïté par un diagramme, au contraire d’un Knowledge Graph. De plus, si l’on part sur l’usage des technologies RDF et OWl, l’interopérabilité du référentiel d’architecture avec d’autres outils utilisés comme bases de modèles, de documentation ou d’exigence sera de facto facilitée, éventuellement avec un VKG et des outils de conversion conformes à RML.

 

A quand un EAO comme OBO ?

Il manque toutefois un véritable consensus sur des spécifications formelles de conceptions partagées des domaines de connaissance en Architecture d’Entreprise. I.E les ontologies du réseau modulaire évoquées précédemment, avec un moyen de généraliser ou spécialiser certaines. Tout autant qu’un moyen pour les partager (en mode FAIR) ainsi que disposer de services utiles sur tout le cycle de vie du (ou des) Knowledge Graph d’architecture qu’on peut construire à partir de ces spécifications.

 

On sait que dans certains domaines, cela existe, le plus connu étant l’OBO foundry pour la biologie et la biomédecine. Une communauté autour d’OBO a développé de bonnes pratiques autant pour l’évaluation, la curation, la réutilisation des ontologies que pour la constitution d’outils utiles à leur développement. On peut évoquer des outils comme ODK, ROBOT, ou OntoPortal.

 

Comme on peut évoquer de nombreux outils, conformes à RML, qui faciliteront le mapping en RDF de sources de données existantes pour la construction des Knowledge Graphs d’EA en entreprise.

 

Si les bénéfices et les outils existent, une question demeure. Pourquoi nulle communauté d’architecte, éventuellement avec le financement d’une association de standardisation, n’a construit d’EA Ontology foundry ? Est-ce parce que financer une telle démarche serait contre-productif pour certains modèles d’affaires associés aux cadres de références d’EA existants ?

 

Sabine BOHNKÉ

Logo-Semsimo

"Le vrai signe d'intelligence n'est pas la connaissance, c'est l'imagination."
Albert Einstein

 

Compléments de lecture

  

 


06/06/2024
0 Poster un commentaire

Knowledge Graph et Architecture d’Entreprise (1/2)

Un potentiel mal exploité

architecture-entreprise-champ-des-éléments-en-interaction

 

Champ des éléments en interaction pour l’Architecture d’Entreprise

 

L’Architecture d’Entreprise (AE) est une discipline destinée à favoriser, face à des situations en constante évolution, le développement d‘une stratégie d’entreprise conforme à ses finalités ainsi que son exécution ad hoc.

 

Cette discipline est profondément liée aux approches de représentation des connaissances. Il est donc curieux que le potentiel des Knowledge Graphs y soit encore insuffisamment exploité. En effet, ces derniers sont pertinents pour représenter de manière expressive la sémantique d’un système. Ils offrent également des moyens de naviguer entre les concepts de connaissance et leurs interrelations. Cela en suivant des standards du Web sémantique et des modèles et ensembles de données FAIR (Findable, Accessible, Inter-operable, Re-usable).

 

Il est toutefois décevant, au niveau de la couche sémantique, de constater que les essais d’approche des Knowledge Graphs pour l’Architecture d’Entreprise – à quelques exceptions près – se soient cantonnés à des traductions littérales en langage OWL de modèles ou de cadre de référence existants. Or exprimer en OWL les règles et objets de langages tels ArchiMate ou la terminologie de TOGAF, a peu d’intérêt. On restreint ainsi une richesse d’expression sémantique aux contraintes voire incohérences de sources existantes. Les réutiliser à un sens, mais il ne faut pas confondre sources terminologiques et spécification formelle d’une conceptualisation.

 

Pour que l’approche des graphes de connaissances appliquée à l’Architecture d’Entreprise fonctionne, il ne faut pas se tromper de cible. Aussi suivre les bonnes pratiques de construction, tant pour la conception que l’implémentation. Cet article développe aussi bien les enjeux en la matière que les moyens d’y arriver.

 

Architecture d’Entreprise
et représentation des connaissances

Une partie de l’Architecture d’Entreprise consiste à décrire le système entreprise au juste nécessaire dans son environnement. Ce « juste nécessaire » revient à disposer d’informations clés afin de réduire l’incertitude sur les situations en développement. Il s’agit autant de décrire les objectifs stratégiques que les aspects organisationnels, les capacités, les ressources, les processus, les technologies, en d’autres termes, tous les composants essentiels qui structurent l’entreprise, leurs interactions ainsi que leurs évolutions dans un monde ouvert, à des fins décisionnelles. L’idéal étant de pouvoir simuler l’impact de choix sur une représentation de l’entreprise à un instant t.

 

Les descriptions d’architecture servent à acquérir une connaissance utile pour comprendre, choisir et planifier les actions de transformation en continu. L’entreprise est, par ailleurs, un système dynamique complexe. Dès lors, l’approche systémique est de mise. Elle conduit à se concentrer sur les interactions internes entre éléments du système ainsi que leurs relations externes avec l’environnement. Sans oublier, bien sûr, de définir clairement les finalités du système pour identifier des pistes d’évolution conformes aux enjeux stratégiques.

 

Tout cela nécessite de décrire explicitement ce qui est su des éléments et leurs interactions. Donc de collaborer avec des « SME » (Subject Matter Expert) pour éliciter leurs connaissances. Il faut ensuite la formaliser tout en intégrant la nécessité permanente de mise à jour. Dès lors, des outils et procédés de représentation et partage des connaissances sont nécessaires à plusieurs niveaux d’abstraction.

Things, not strings

things-not-strings-example

 

Image extraite de l’article de Amit Singhal « Introducing the Knowledge Graph: things, not strings »

 

Deux erreurs communes depuis des années sont prégnantes dans les systèmes d’information. Modéliser des données pour stockage avant d’expliciter les concepts manipulés et penser plus au couple problème/solution qu’aux enjeux globaux. D’où le fameux « integration spaghetti » du Gartner. C’est à dire un SI constitué d’une mosaïque de systèmes peu évolutifs, peu interopérables, avec de nombreux silos de données.

 

Quand on parle de concepts manipulés, ce sont les objets métiers, concrets ou abstraits de l’univers du discours de l’entreprise. Un constructeur automobile manipulera des concepts liés aux voitures, un assureur, des contrats d’assurance. Les acteurs métiers aujourd’hui évoquent des « données métiers ». En réalité, les données ne sont déjà plus des objets métiers. Ce sont des traductions en formats numériques, de parties de choses utiles au métier. Et souvent, sous la seule perspective à court terme d’un fonctionnement applicatif recherché.

 

Dans le champ de l’Architecture d’Entreprise, il y a nécessairement la description des objets métiers manipulés par les acteurs. Cette description sert autant à définir les capacités à développer qu’à fluidifier les échanges entre systèmes d’information.

 

En 2012, un article de Amit Singhal « Introducing the Knowledge Graph: things, not strings » saluait l’arrivée du Google Knowledge Graph. Things, not strings : tel devrait être également le slogan des échanges entre systèmes d’information.

 

Les choses sur lesquelles on a besoin d’information ne sont pas les chaines de caractères qui les désignent. Pas plus qu’elles ne sont la façon dont on les stocke ou on les transfère. On a besoin d’un niveau de représentation indépendant des plateformes ou des syntaxes des formats d‘échange pour dire que les données qu’on manipule sont bien liées à telle ou telle chose. Des métadonnées connectées dans un « Knowledge Graph » sont typiquement une réponse à ce besoin.

 

Architecture d’Entreprise,
Virtual Knowledge Graph et Data Fabric

using-data-fabric-architecture-to-modernize-data-integration-0

Image extraite de l’article du Gartner
« Data Fabric Architecture is Key to Modernizing Data Management and Integration »

 

Un Knowledge Graph consiste en une ou plusieurs ontologies formelles liées et des ensembles de données cohérents avec celles-ci. En créant les ontologies spécifiant les concepts de l’entreprise, on peut ensuite créer un « Virtual Knowledge Graph » (VKG). Il s’agit du concept autrefois nommé OBDA (Ontology-Based Data Access).

 

En utilisant des ontologies, de la fédération de requêtes SPARQL et du mapping (R2ML), cette approche offre un moyen d’interroger les différentes sources de données distribuées au sein de plusieurs systèmes en fonction des concepts métiers sur lesquels elles ont des informations. Elle permet en outre aux données de rester dans leurs bases d’origine pour une gestion plus agile et plus efficace.

 

Ici, la description, via une spécification formelle, de composants de l’Architecture d’Entreprise, permet d’optimiser la construction d’autres composants d’architecture. Il existe par ailleurs des outils commerciaux et open source pour créer des VKG. Au-delà de la notion de VKG, c’est le concept de Data Fabric qui profite au mieux des Knowledge Graphs. En utilisant la couche sémantique du graphe de connaissance pour établir la provenance, la qualité et le sens des données gérées dans les systèmes d’information de l’entreprise, on s’oriente vers une meilleure vue intégrée et unifiée de ces derniers. Ce que soulignait l’article publié en 2021 sur le site du Gartner « Data Fabric Architecture is Key to Modernizing Data Management and Integration » : « Data fabric must create and curate knowledge graphs ».

 

Architecture d’Entreprise :
cas d’usage des Knowledge Graphs

Certes, la construction et la curation desdits Knowledge Graphs nécessitent des efforts. Cependant, il existe de meilleures pratiques et des outils pour des résultats relativement rapides avec des solutions robustes et évolutives.

 

Deux orientations d’usages des Knowledge Graphs dans le domaine de l’Architecture d’Entreprise sont particulièrement intéressantes. L’une, déjà évoquée, porte sur l’interopérabilité sémantique via la spécification des concepts métiers pour cas d’usage analytique ou transactionnel. L’autre porte sur l’activation dynamique d’un métamodèle des composants d’une entreprise pour guider des changements stratégiques. En spécifiant formellement les composants à connaître, ainsi que leurs interrelations, pour décider et suivre au mieux l’évolution des transformations, on peut construire un graphe de connaissance qui permettrait de réduire les incertitudes liées aux options de changement.

 

Les Knowledge Graphs aident à contextualiser les décisions liées à l’évolution du système d’information en reliant les éléments architecturaux aux facteurs d’influence externes, aux objectifs métier, aux contraintes opérationnelles et aux tendances technologiques. Cette vision holistique guide les décideurs vers des choix plus éclairés et alignés sur les objectifs stratégiques de l’entreprise. Par ailleurs, en spécifiant avec des métadonnées les relations entre les composants, les Knowledge Graphs facilitent l’analyse d’impact des changements. Cela permet de comprendre rapidement comment une modification dans une partie spécifique de l’architecture peut affecter d’autres composants, aidant ainsi à anticiper les conséquences potentielles et à simuler des scénarios pour prise de décision.

 

Mais si l’on veut un Knowledge Graph d’Architecture d’Entreprise, contenant tous les composants de l’entreprise ainsi que leurs liens, comment procéder ? N’est-ce pas un travail trop complexe ?


Vous trouverez des éléments de réponses dans le prochain article
" Knowledge Graph et Architecture d’Entreprise (2/2) ".

 

 

Sabine BOHNKÉ

Logo-Semsimo

 

 

 

 

« La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information. »

Albert Einstein

 

Compléments de lecture

Métamodèle TOGAF - ArchiMate

  

Les critères d'un bon modèle

   


28/05/2024
0 Poster un commentaire

Découvrez pourquoi vous devez rationaliser votre portefeuille applicatif avant toute tentative de transformation numérique

La rationalisation des applications est cruciale pour les organisations afin de maintenir leur agilité et d'optimiser les coûts. Cela est particulièrement important avant d'entreprendre une transformation digitale, telle que la migration vers le cloud ou le changement de votre système d’ERP. 

 

rationalisation-portefeuille-application-leanix-04 

La rationalisation des applications est le processus d'organisation et de rationalisation de votre portefeuille applicatif pour accompagner au mieux vos objectifs commerciaux.

 

Avant de tenter toute transformation, vous devez vous assurer que votre paysage actuel est optimisé, sinon vous risquez non seulement de migrer des problèmes existants vers votre architecture cible, mais également de créer de nouveaux problèmes. La rationalisation des applications permet à l’entreprise de démarrer le processus de transformation au bon moment, avec la meilleure visibilité. 

Cependant, cela ne doit pas être un processus ponctuel. La rationalisation des applications doit être une habitude régulière pour répondre aux besoins de transformation continue exigés dans l’ère moderne.

Pour soutenir la rationalisation régulière et la transformation continue, vous avez besoin d'une solution comme l’outil d’architecture d'entreprise LeanIX, capable de suivre rigoureusement votre portefeuille d'applications et de vous aider à concevoir des feuilles de route pour la transformation.

 

Pourquoi la rationalisation est-elle importante pour la transformation ?


Rappelons-le, la rationalisation des applications est le processus d'organisation et de rationalisation de votre portefeuille applicatif pour accompagner au mieux vos objectifs commerciaux.

La meilleure pratique consiste à catégoriser chaque application selon la méthodologie TIME de Gartner :

 

Tolérer : accepter l'application dans son état actuel pour le moment

Investir : donner la priorité aux applications les plus stratégiques

Migrer : Trouver une autre application qui répond davantage à un besoin commercial

Éliminer : supprimer l'application quand elle n'est pas nécessaire ou souhaitable

Une fois que vous avez effectué cette catégorisation, vous pouvez :

 

  • Supprimer les applications qui ne sont plus nécessaires
  • Éliminer progressivement les applications nécessaires mais indésirables
  • Remplacer les applications par d’autres qui conviennent mieux ou les migrer vers le cloud
  • Utiliser le budget que vous avez économisé en investissant dans de nouvelles applications clés

 

Il est essentiel d'effectuer une rationalisation des applications pour garantir que votre portefeuille applicatif est optimisé et offre le meilleur retour sur investissement possible (ROI). Tout aussi importante est la nécessité de répéter ce processus régulièrement pour vous assurer que votre portefeuille s'adapte aux besoins changeants de votre entreprise.

 

Seulement 15 % des organisations effectuent une rationalisation des applications régulière, selon notre enquête sur l'optimisation des coûts informatiques en 2023.

Pour en savoir plus, téléchargez l'enquête complète.   

 

Les organisations qui effectuent une rationalisation des applications de manière régulière seront prêtes à relever tous les défis auxquels elles seront confrontées. Il est particulièrement important d'harmoniser votre portefeuille avant toute transformation digitale.

 

Transformation sans rationalisation

 

Imaginez que vous deviez déménager et donc emballer tous vos biens pour les transporter dans votre future maison. Dans le meilleur des cas, vous trieriez d'abord les objets pour voir ceux qui pourraient être jetés, puis vous emballeriez en toute sécurité ceux que vous souhaiteriez conserver.

De la même manière, une rationalisation des applications peut vous assurer que vous êtes entièrement prêt pour votre transformation avant de la commencer. Si vous ne le faites pas, votre transformation pourrait échouer.

Une étude célèbre du BCG a révélé que 70 % des transformations digitales échouent. La rationalisation des applications est essentielle pour vous donner la meilleure chance de réussir.

Sans rationalisation des applications, plusieurs conséquences : 

 

1 Des applications qui ne fonctionnent plus

Vos applications héritées ne sont pas conçues pour être aussi flexibles que les logiciels modernes et peuvent moins bien fonctionner, voire plus du tout. Une rationalisation des applications soumettra vos applications à des tests et déterminera si elles fonctionneront comme prévu dans votre nouveau paysage informatique.

 

2 Il est fréquent d’oublier l’existence de certaines applications 

Maintenant que l'utilisation d'applications SaaS au sein des entreprises est devenue monnaie courante, il est inévitable que certaines applications en cours d'utilisation ne soient pas documentées. La rationalisation des applications impliquera la recherche de ces applications "fantômes" et veillera à ce qu'elles soient prises en compte dans le cadre de votre transformation.

 

3 Certains coûts sont inattendus

De la mise à niveau d'applications qui ne conviennent plus post-transformation, aux coûts de migration inattendus liés à des applications non découvertes, vous n'aurez pas une estimation complète des coûts de votre transformation avant d'avoir réalisé une évaluation rigoureuse de votre portefeuille applicatif.

 

4 Réticence potentielle des employés

Un facteur majeur de réussite de votre transformation est lié à l'adhésion des parties prenantes. Un effort de rationalisation des applications aidera à justifier des décisions en toute transparence auprès de votre leadership et de vos employés. 

 

5 Problèmes réglementaires

Enfin, il est possible de réaliser une migration de données et constater que votre nouvelle architecture n'est plus conforme aux exigences réglementaires. Cela devient encore plus complexe lorsque l'on considère les différentes réglementations des régions du monde.

 

La rationalisation des applications ne s’arrête pas là

 

Pour optimiser vos chances de succès dans votre transformation, vous devez mener à bien un effort de rationalisation des applications. Cependant, trop souvent, les informations que vous découvrez pendant le processus sont immédiatement égarées une fois que vous avez terminé.

Conserver ces informations dans une base de données dédiée vous permettra de répéter les efforts de rationalisation des applications régulièrement, sans avoir à recommencer à zéro à chaque fois. 

 

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

 

urbanisation-si_logo

 

Neil Sheppard

LeanIX

 

 

 

 

 

 

"Il y a une illusion anthropomorphique qui s'installe avec les machines, avec le risque d'une manipulation considérable."

Serge Tisseron

 

 

[Cet article a été rédigée par un contributeur extérieur à la rédaction. Le site urbanisation-si.com ne le rémunère pas, et ce dernier n'a pas non plus payé pour publier ce texte. Le choix de le publier s'est donc fait uniquement sur des critères éditoriaux.]

 

Compléments de lecture

 


12/03/2024
0 Poster un commentaire

Comment gérer efficacement votre documentation d'architecture technique ? Essayez le C4 model avec l'outil Uncia

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

uncia-documentation-manuelle-01

 

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

 

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

 

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


Par exemple, elles vont utiliser : 

 

 

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

 

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


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

 

Alors que faut-il faire ?

 uncia-processus-ideal 

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

 

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

 

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

 

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

 

C4 model

 

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

 

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

 

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

 

Contexte, Conteneurs, Composants, Code

 

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

C4model4levels

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

 

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

 

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

 

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

 

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

 

C4 model legend

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

 

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

 

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

 

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

 

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

 

Avec Uncia, vous pouvez :

 

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

     
  • Cartographier très finement le SI et identifier les ressources critiques.

 

Comment fonctionne Uncia ?

  uncia-structure-du-dat

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

 

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

 

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

 

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

 

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

 

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

 

ExempleUncia

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

 

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

 

  • Une uniformisation de la documentation d'architecture technique,
    qui facilite la communication et la compréhension entre les différents acteurs du projet,

     
  • Une sécurisation du respect de la politique de sécurité de votre organisation,
    depuis la définition des architectures jusqu'à la préparation des mises en production,

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

     
  • Consommabilité via des APIs permettant des intégrations avancées,
     
  • Automatisation des Workflows offrant des cycles de relecture, la gestion des commentaires, et le suivi des modifications. Cela accélère la validation des DAT et réduit les délais.

 

Conclusion

 

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

 

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

 

 

urbanisation-si_logo

 

Rhona Maxwel

Thierry Biard

urbanisation-si.com

 

 

 

 

 

 

 

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

 

Compléments de lecture

 

 


13/02/2024
0 Poster un commentaire

Comment consolider un référentiel centralisé TOGAF rassemblant les autres référentiels Stratégie, Métier, Applications, Infrastructure… ? Obeo SmartEA S.1 Ep.2

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

 

communication-architecte-entreprise-02

  

Une meilleure communication pour une meilleure transformation numérique

 

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


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

 

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


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

 

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


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

 

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

 

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

 

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


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


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


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


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

  

obeo-smartea-realisation-des-objectifs-constat-objectif-resultat-principe-exigence

  

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

 

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

 

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

 

obeo-smartea-verrouillage-01

  

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

 

 

obeo-smartea-verrouillage-02

  

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

 

Le tableau de bord de l’Architecte d’Entreprise

 

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

 

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


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

 

obeo-smartea-dashboard-architecte-entreprise

  

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

 

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


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

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

 

obeo-smartea-apres-lancement-connecteur-java-isd-smartea

  

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

 

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

 

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

 

obeo-smartea-connecteur-sparx-system-enterprise-architect-02

    

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

 

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

 

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

 

obeo_smartea-excel-echanges-absents-du-referentiel

  

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

 

obeo-smartea-resultat-import-excel

  

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

 

Conclusion

 

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

 

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

 

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

 

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

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

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

 

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

Woody Allen

 

Annexe : nos tests

 

 


19/12/2023
0 Poster un commentaire

Quel outil ArchiMate pour modéliser vos architectures d’entreprise sources et cibles, évaluer les écarts, analyser les impacts et élaborer des trajectoires de transformation ? Obeo SmartEA S.1 Ep.1

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

 

obeo-smartea-nouveau-navigateur-url-differences-salesforce-chatgpt

   

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


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

 

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

 

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

 

obeo-smartea-gestion-des-branches-git

 

   

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

 

Obeo SmartEA, un outil branché !

 

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

 

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


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

 

Créez une branche

 

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

 

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

 

obeo-smartea-nouveau-branche-master-vue-motivation

    

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

 

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

 

obeo-smartea-creation-branches-2

 

  

obeo-smartea-creation-branches-Salesforce-Cloud-IA

 

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

 
obeo-smartea-nouveau-branche-ia-vue-motivation

     

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

 

Analysez les écarts

 

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

 

obeo-smartea-nouveau-menu-analyse-ecarts

   

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

 

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

 

obeo-smartea-nouveau-differences-ia-master

 

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

 

obeo-smartea-nouveau-differences-ia-master-zoom

   

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

 

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

 

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

 

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

 

Scénario #1 : l'association API ChatGPT avec le workflow No Code Make
et la plateforme de développent No Code HubSpotobeo-smartea-nouveau-branche-chatgpt-vue-technologie

    

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

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

 

Scénario #2 : Salesforce Cloud 

obeo-smartea-nouveau-branche-salesforce-vue-technologie

 

 

 

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

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

 

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

 

obeo-smartea-nouveau-differences-chatgpt-salesforce

  

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

 

 

obeo-smartea-nouveau-differences-chatgpt-salesforce-zoom

 

 

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

 

Et réciproquement.

 

obeo-smartea-nouveau-differences-salesforce-chatgpt

  

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

  

obeo-smartea-nouveau-differences-salesforce-chatgpt-zoom

  

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

 

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

 

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

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

 

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

 

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

 

 

obeo-smartea-branche-chatgpt-flux-entre-applications

   

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

 

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

 

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

 

obeo-smartea-nouveau-synchronisation-master-avec-chatgpt

  

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

 

Conclusion

 

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

 

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

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

 

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

 

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

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

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

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

Antonio Gramsci

 

Annexe : compléments de lecture

 

 

       


28/11/2023
0 Poster un commentaire

Vous cherchez un outil pour gérer le mapping entre les objets métier et une base de données relationnelle, générer les scripts SQL et produire du code à partir de vos modèles ? Obeo ISD S.1 Ep.5

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

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

 

obeo-isd-mpd-et-generation-scripts-sql    

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

 

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

  obeo-isd-resume-4-episodes-graal-cinematic-soa    

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

 

Les différents modeleurs et leurs fonctions

 

Créez des entités persistantes

Jouez la partition

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

 

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

 

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

 

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

 

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

 

obeo-isd-creation-entity-model-namespaces   

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

 

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

 

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

 

obeo-isd-entity-model-diagram-entities-complet 

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

 

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

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

 

Un bémol à la clé

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

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

 

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

 obeo-isd-entity-model-vue-entities-physical-names

 

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

 

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


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


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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

obeo-isd-creation-database-model-mld-schemas 

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

 

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

 

obeo-isd-creation-database-model-mld-tables-prestation   

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

 

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

 

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

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

 

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

 

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

 

obeo-isd-creation-database-model-mld-bogue-heritage  

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

 

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


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

 

obeo-isd-creation-database-model-mld-bogue-coordonnees 

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

 

Gestion des modifications

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

 

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

 

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

 

Prenons MySQL comme RDBMS de test.

 

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

 

obeo-isd-creation-database-model-creation-mpd-mysql8    

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

 

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

 

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

 

obeo-isd-creation-database-model-generer-mpd-a-partir-mld    

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

 

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

 

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

 

Générez les scripts SQL

 

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

 

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

 

obeo-isd-generation-scripts-sql   

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

 

Exécutez les scripts SQL directement dans la base

 

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

 

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

 

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

 

obeo-isd-scripts-sql-liquidbase  

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

 

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

 

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

 

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

 

Nous avons rencontré 2 types d’exceptions : 

 

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

 

obeo-isd-resultat-execution-scripts-sql  

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

 

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

 

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

 

obeo-isd-historique-modifications-base-2        

Exemple d'utilisation de l'historique.

 

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

 

information-system-designer-openapi-liquibase

   

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

 

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

 

Génération documentaire

 

information-system-designer-generation-de-documents-rapports-2

       

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

 

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

 

information-system-designer-generation-de-code-2   

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

 

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

 

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

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

 

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

 

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

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

 

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

 

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

information-system-designer-comment-utiliser        

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

 

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

 

Travail collaboratif avec l’extension payante
Obeo Designer Team

 

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

 

Conclusion

 

information-system-designer-outils-utilises 

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

 

Les éloges

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

 

Les déceptions

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

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


Open source oui, closed pour le reste.

 

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

 

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

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


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

 

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

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

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

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

 

Compléments de lecture

 

 

      


10/10/2023
0 Poster un commentaire

Quelle solution pour concevoir la modélisation d’une architecture micro-services, l’intégrer dans une architecture d’entreprise et permettre une collaboration avec l’ensemble des acteurs projet ? Obeo ISD S.1 Ep.4

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. 

 

obeo-isd-diagramme-soa-composants-interfaces 

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 ?

 

open-group-microservices-architecture 

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 >

 

 

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

 

obeo-isd-creation-modele-soa  

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 

 obeo-isd-dto-diagram-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

 

obeo-isd-dto-diagram-details 

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

 

obeo-isd-creation-soa-diagram-dossier-sinistre-oauth2  

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

 

obeo-isd-creation-soa-diagram-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.

 

obeo-isd-creation-soa-diagram-component-contract-securité-cumul 

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

 

obeo-isd-creation-soa-diagram-component-contract-securité-creer-survenance 

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.

 

obeo-isd-creation-soa-diagram-component-contract-survenance-service-exigences 

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. 

 

 

obeo-isd-creation-soa-diagram-component-contract-survenance-service-cle-grise  

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 >

 

 

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.

 

 

urbanisation-si_logo

 

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


26/09/2023
0 Poster un commentaire

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

L’outil open source et low code d’architecture logicielle Obeo Information System Designer (ISD) et sa méthode Graal, un fork agile d’UML, intègre les User Stories et les aspects statiques et dynamiques des IHM, le tout relier à un gestionnaire d'exigences.
Les matrices de traçabilité garantiront que les parties prenantes auront une compréhension complète du produit en cours de développement et que toutes les exigences seront satisfaites.

obeo-information-system-designer-flow-exigences 

Exemple de la cartographie de la cinématique des écrans,
comprenant leur aspect et leur composition, ainsi que les actions assurant la navigation.
Une vue permet d'avoir la liste des exigences prises en compte par le workflow.

 

Le NoUML est apparu parce que les formalismes normalisés de modélisation comme UML n’ont jamais pris en compte les méthodes agiles, c’est ce que nous déplorions dans nos 2 précédents articles :

 

 

La méthode Graal d’Obeo a réparé cette erreur en intégrant, entre autres, les User Stories des méthodes agiles.

 

Un peu d’histoire sur les User Stories

 

En 1999, Kent Beck publie en premier le principe des User Stories (US) ou récits utilisateurs dans le cadre de la méthode « eXtreme Programming (XP) ». 

 

Les US sont largement adoptées par les méthodes agiles comme Scrum, en raison du formalisme minimaliste et de l’amélioration de la communication MOA/MOE. Elles sont en parfaite adéquation avec des itérations courtes, car une US doit pouvoir être implémentée en une itération contrairement aux cas d'utilisation UML.

 

Une US illustre un besoin fonctionnel exprimé par la typologie d’utilisateurs. Cela permet d’assurer que l’on délivre bien pour eux de la valeur. Les avantages sont de permettre :

 

  • de coller au maximum au besoin et à la vision de l’utilisateur (car elles sont exprimées de manière simple, en langage courant) ;
     
  • d’engendrer un gain de temps considérable pour les équipes de développement dans leur compréhension de la fonctionnalité à développer (toujours grâce à sa forme synthétique) ;
     
  • d’aligner la vision, et de confirmer la compréhension du métier, du Product Owner, des développeurs, du Scrum Master, des testeurs et de toute autre partie prenante, en les rassemblant autour d’un langage commun.

 

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

 

ISD de l’éditeur français Obeo 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.


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 à ceux d'UML, mais expurgés des éléments rarement utilisés :

 

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

 

Si vous avez manqué le début, voici les 2 épisodes précédents : 

 

  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

 

Conception d’une User Story
à partir d'un Tasks Graph ou d’un Actions Plan

 

Dans notre article cité au début « Que faut-il garder d'UML... », nous proposions que les cas d'utilisation UML référencent plusieurs User Stories. C’est ce que propose la méthode Graal d’ISD. Une fois une User Story créée (voir en annexe la procédure), vous pouvez lui rattacher (lien de composition UML dans le métamodèle de la méthode Graal ?) des tâches d’un Tasks Graph ou des actions d’un Actions Plan, appartenant à un Use Case. Le principe fondamental de l’agilité consistant à simplifier et à faciliter l'analyse d'impacts est bien respecté.

 

obeo-information-system-designer-user-stories-parcours-actions-plan-2 

Un ensemble d'actions de la tâche « Rechercher un assuré » sont liées à la User Story :
« US02 : En tant que Gestionnaire Prévoyance, je veux rechercher un assuré suivant des critères,
afin d'avoir l'historique des survenances et sinistres associés,
pour prendre la décision d'ouvrir un nouveau dossier de prestation. »

 

Gestion des exigences

 

Plus besoin de SysML, ISD est un studio « all inclusive »

A l’identique de ce qui précède, UML ne possède aucun diagramme pour modéliser les exigences. Si l’on veut rester dans la nébuleuse des normes de l’OMG, il faudra se tourner vers une autre notation, SysML.

 

Voir nos articles : 

 

 

ISD possède un outillage de gestion des exigences, offrant un ensemble de fonctionnalités permettant d’intégrer la gestion d’exigences d’un projet dans le processus de modélisation. Il est composé d’un éditeur permettant de saisir ses exigences et d’une vue gérant le lien entre les modèles et les exigences du projet (voir les procédures en annexe).

 

Etude d'impacts : merci aux matrices de traçabilité de la méthode Graal d'ISD

La méthode Graal possède des matrices de traçabilité, offrant une vue consolidée, pour les tâches, les use case et une dernière rassemblant tous les éléments concernés par des exigences, comme les écrans et les workflows (voir les procédures en annexe).

 

obeo-information-system-designer-traceability-matrix-task-requirement 

Tout changement sur les 3 exigences impacterait la tâche « Rechercher assuré »,
ainsi que les actions qui la composent, représentées par le diagramme de plan d'actions.

   

  obeo-information-system-designer-traceability-matrix-use-case-requirement 

Liste des exigences réalisées par un use case. 

 

Les diagrammes de séquence et d’états UML ont été simplifiés dans la méthode Graal et l'on applaudit

 

obeo-information-system-designer-diagramme-sequence 

Les principaux éléments standards d’un diagramme de séquence UML sont présents,
sauf ceux plus exotiques (voir en annexe la procédure de création).

 

 

obeo-information-system-designer-diagramme-etat 

On retrouve un diagramme d’états UML pragmatique ;
Obeo a élagué tous les concepts complexes des machines à états de la norme
et inutiles en informatique de gestion (voir en annexe la procédure de création).

 

Faites votre film en dessinant
l'enchaînement de vos écrans

 

Vous pouvez concrétiser vos US en modélisant la cinématique et les maquettes des écrans. ISD possède un outil de conception d'écrans d’application nommé Cinematic Designer, permettant de décrire la structure d’une IHM (modélisation statique) et son comportement (modélisation dynamique).

 

Cinematic Designer apporte le point de vue Cinematic Views qui permet de :

 

  • Modéliser des vues et leurs éléments comme les composants graphiques d’une IHM,
     
  • Modéliser la structure de la disposition graphique sous une structure de type « Grid Layout »,
     
  • Modéliser les états et le flot entre les états de l’application,
     
  • Organiser les Flows et les View Elements en packages.

 

Le directeur de la photo : Vue Statique ou View Container (maquette écran ou mockup)

Cette représentation apporte la modélisation de la disposition graphique des composants de l’IHM. Elle permet de créer et positionner les View Elements dans les View Containers.

 

obeo-information-system-designer-view-container-synthese-evenements-assure-ecran 

Maquette d’écran représentant la User Story de recherche d'assuré par le gestionnaire prévoyance,
décrite précédemment (voir en annexe la procédure de création).

 

Le metteur en scène : Vue Dynamique ou Flow

Ce diagramme permet d'afficher :

  • Les états du Flow (InitialState, FinalState, ViewState, ActionState, DecisionState, AsyncEventState, SubflowState),
     
  • Les événements transitoires éventuellement conditionnés (guard entre crochets) qui font transiter d'un écran ou d'un état à un autre,
     
  • Un conteneur flottant nommé FlowEvents présente les FlowEvents génériques du flow de portée globale, qui représentent des événements logiques ou métier,
     
  • Les ViewContainers rassemblant les éléments d'un écran (boutons, tableaux, zones de formulaires...) référencés par les ViewState affichés.

 

obeo-information-system-designer-flow-2 

Cinématique des écrans de la User Story de recherche d'assuré par le gestionnaire prévoyance décrite précédemment, avec les événements assurant la navigation. Le picto « clé » indique que l'élément est lié à des exigences. En double cliquant sur l'autre picto, on accède à la maquette d'écran.
Dommage qu'on ne puisse pas avoir une fonctionnalité identique avec les User Stories !

 

Le producteur : Vue Package

Ce diagramme permet de modéliser les Packages, Flows et ViewContainers.

 

obeo-information-system-designer-package-complet 

Représentation du package contenant le ViewContainer et le Flow associé, abordés précédemment. 

 

Le directeur du casting : Vue de la structure de l’interface utilisateur (UI Structure)

La représentation UI Structure fournit une vue d’ensemble complète de la structure des écrans de l’application modélisée, sous forme arborescente.

 

obeo-information-system-designer-UI-structure-complet 

Vue hiérarchisée de la structure de l'écran « Synthèse des événements initiaux » de notre User Story.

 

Le réalisateur d'effets spéciaux : Création de toolkits

Un des objectifs du métamodèle Cinématique est de permettre de créer facilement de nouveaux toolkits. La création d’un toolkit consiste en la création de widgets, et, sous chaque widget, la création des types d'événements qu’il peut déclencher.


Cela est rendu possible par l’intégration du framework open source Sirius, permettant de créer ses propres outils de modélisation, en association avec le métamodèle Eclipse Ecore et l'éditeur EMF (Eclipse Modeling framework).

 

Si le sujet vous intéresse, consultez les 4 articles que nous avions consacrés à la réalisation d'un outil de modélisation DMN (Decision Model Notation) :

 

  1. DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
     
  2. Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]
     
  3. Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
     
  4. 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]

 

Les répétitions : le calque « Example » pour la valorisation des écrans

Une fonctionnalité intéressante est la valorisation des écrans avec des exemples permettant de concrétiser du storytelling, technique hyper efficace de communication entre les experts métier et la MOE.

 

obeo-information-system-designer-calque-exemple 

Le calque Example modifie le label des View Elements, permettant de visualiser l’IHM
avec des données d’exemple. Le label est alors calculé tel que défini dans le toolkit.

 

Critique du film : dommage qu'on ne puisse pas lier des user stories à des exigences !

Si la fonctionnalité Flow représente la cartographie pour la navigation et les événements de transition d'un écran à un autre, il nous a été impossible d'associer des user stories, bien que le logiciel le laissait penser.

 

Par exemple en sélectionnant un élément « View », en cliquant sur l'onglet « User Stories » puis sur le picto +, une boîte de dialogue apparaît permettant de saisir une nouvelle US, une fois complétée et validée, mais l'onglet reste désespérément vide ! 

 

Générer la documentation

 

Finies les SFD (Spécifications Fonctionnelles Détaillées) et STD (Spécifications Techniques Détaillées), ISD va vous faciliter la vie (voir en annexe la procédure de génération de documentation).

 

obeo-information-system-designer-generation-de-documentation  

Comme dans tout générateur de documentation, il faut un modèle variabilisé. 

 

Conclusion

 

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’états des entités métier.


Comme le montre notre étude de cas, avec les matrices de traçabilité des exigences avec les use case, les tâches, la cinématique 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és, 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.


Jusqu’ici, nous avons vu des équivalents de cartographie métier, fonctionnelle, applicative avec la cinématique et les représentations des écrans : il restera l’architecture technique, abordée dans notre prochain article. Nous verrons qu'ISD a plus d’un tour dans son sac, puisqu’il permet de modéliser une architecture SOA, comme une architecture micro-services.


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

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

 

« Quand les hommes ne peuvent changer les choses, ils changent les mots. »

Jean Jaurès

 

Annexe 1 : comment procéder ?

 

 

Gérer les User Stories (US)

 

obeo-information-system-designer-user-stories-parcours-de-taches 

Pour Graal, une user story permet de décrire un enchaînement de tâches
et un parcours dans un plan d'actions.

 

La procédure de création est la suivante :

 

Menu Window > Show View > Other… > Information System Designer > User stories

 

Dès qu’un élément Graal est sélectionné sur un diagramme ou dans la vue Model Explorer, les User Stories du système sont affichées dans la vue permettant de gérer le cycle de vie d’une US.
Pour créer un parcours de tâches à effectuer représentant la US :

 

  1. faire une sélection multiple soit dans un Tasks Graph ou dans un Actions Plan,
     
  2. cliquer sur le pictogramme +,
     
  3. indiquer un nom et une description de la US,
     
  4. cocher la case de la US nouvellement créée.

 

obeo-information-system-designer-user-stories-creation 

Association d'un workflow d'actions à une User Story.

 

Procédure d'association d'une tâche à une User Story :

 

  1. Sélectionner la ou les tâche(s) « Créer un dossier de prestation prévoyance »
    dans le Tasks Graph,
     
  2. Cocher la US « Ouvrir un nouveau dossier de prestation ».

 

Une fois l'association activée, pour visualiser le parcours, double cliquer sur la US ou sélectionner le picto ampoule. Toutes les actions composant la tâche font automatiquement partie de la US. Remarque : Rechercher assuré n'est pas sélectionné, puisque c'est la tâche suivante dans le Tasks Graph.

  

obeo-information-system-designer-user-stories-parcours-actions-plan-3

  

Le fait d’avoir sélectionné une tâche dans un Tasks Graph (partie supérieure de l'illustration)
sélectionne automatiquement tous ses composants dans le diagramme Actions Plan
(partie inférieure de l'illustration) sauf l'élément représentant la tâche suivante dans le Tasks Graph. 

 

Pour dissocier, sélectionner les éléments affichés par le picto ampoule et décocher la case correspondant à la User story.

 

 

Gérer les exigences (requirements)

 

Classer hiérarchiquement vos exigences en catégorie

  1. Menu File > New > Other… > Requirement Model > sélectionner votre projet,
    un Requirements Table est créé. Modifier son nom dans la vue Properties.
     
  2. Dans l’onglet Requirements table, clic droit sur la première ligne > Create Category
    ou dans la vue Properties, cliquer sur le +


    Une fois une catégorie créée, de la même manière vous pouvez créer des sous-catégories.

 

obeo-information-system-designer-creation-sous-categorie-et-exigences 

Exemple d'organisation arborescente de catégories d'exigences

 

Gérer le référentiel d'exigences

Vous pouvez créer vos exigences dans un premier temps dans le modèle Requirements table :


Clic droit sur une catégorie ou sous-catégorie > Create Requirement ou +
dans la vue Properties > dans la vue Properties,
renseigner les différents champs : Id ; Name ; Version ; Status ; Statement.

 

obeo-information-system-designer-liste-exigences  

ISD offre la possibilité de créer un référentiel d'exigences organisé en une arborescence de catégories. On retrouve le fonctionnement des outils de gestion d'exigences
où chacune est documentée avec un ensemble exhaustif de propriétés.

 

Le menu contextuel sur une ligne du tableau permet la gestion (créer, modifier, supprimer, copier, déplacer...) du référentiel d'exigences.

 

Associer des exigences à un use case, une tâche ou à une action

  1. Une fois un use case décomposé en Tasks Graph et chaque tâche décomposée en Actions Plan, vous pouvez sélectionner un de ces éléments pour lui associer des exigences.

  2. Activer la vue Linked Requirements : Menu Window > Show View > Other… > Linked Requirements.

  3. Sélectionner un Tasks Graph > cliquer sur une tâche > cliquer sur Link Requirements with Selection de la vue Linked Requirements et sélectionner une ou plusieurs exigences.
     
  4. Une clé jaune apparaît alors dans l’élément de modèle, signifiant que des exigences lui sont liées.
     

La procédure serait identique pour un use case ou une action d'un diagramme Actions Plan.

 

obeo-information-system-designer-creation-exigence-liee-a-une-tache-2 

Association de 2 exigences à la tâche « Créer une survenance »

 

Créer une exigence liée à un élément de modèle, use case, tâche ou action

En sélectionnant un élément (use case, tâche, action), vous pouvez créer et associer
une exigence, en cliquant sur le + de la vue Linked Requirements.

 

obeo-information-system-designer-creation-exigence-liee-a-une-tache    

Création d'une nouvelle exigence liée à la tâche « Rechercher un assuré »

 

obeo-information-system-designer-creation-exigence-categorie  

Sélection de la catégorie de la nouvelle exigence

 

Détacher une exigence liée à un élément de modèle, use case, tâche ou action

Sélectionner l’élément de modèle avec une clé > dans la vue Linked Requirements,
sélectionner l’exigence à détacher > cliquer sur la croix rouge.

 

Créer des matrices de traçabilité pour les exigences

Sélectionner le point de vue d’exigences > clic droit > New Representation >
sélectionner Task Traceability Matrix ou Use Case Traceability Matrix.

 

 

Créer des diagrammes de séquence et d’états UML

 

Sur la méthode Graal, sélectionner le point de vue System > clic droit > New interaction >
new Sequence Diagram > nommer votre diagramme.


Sur la méthode Graal, sélectionner le point de vue System > clic droit > New state Machine > new State Machine Diagram > nommer votre diagramme.

 

 

La couche front-end (IHM) :
conception de maquettes et cinématique d'écrans

Créer un modèle d'IHM (Cinematic Model)

File > New > Other > IS Designer > Cinematic Model > Choisir un projet >
Saisir un nom de modèle.

 

  • Pour le Toolkit, on a le choix entre Web ou SWT (Standard Widget Toolkit de la fondation Eclipse). SWT est une boîte à outils de widget open source pour Java, conçue pour fournir un accès efficace et portable aux fonctionnalités de l'interface utilisateur des systèmes d'exploitation sur lesquels il est implémenté.
     
  • Pour Main container, on a le choix entre Page, Panel et Table.

 

obeo-information-system-designer-modeleur-cinematic 

Le modeleur Cinematic va créer un écran (View Container), une cartographie des transitions d'écrans (Flow), un diagramme de package pour organiser les éléments de l'IHM
et une vue hiérarchisée des widgets graphiques composant les écrans.

 

Fonctionnalités du modeleur Cinematic

Le modeleur Cinematic apporte les représentations suivantes :

 

  • View Container Mockup : diagramme permettant de modéliser l'aspect statique avec la structure et l’apparence des IHM.

  • Flow Diagram : diagramme permettant de modéliser la dynamique de l’IHM. Le Flow Diagram permet le dialogue entre l’analyste ou le product owner dans un contexte Scrum et le concepteur/développeur schématisant les vues.
    Par contre, ce diagramme de flow ne permet pas de définir le contenu des écrans, ce qui se fait sur un diagramme de View Container Mockup.

  • Package Diagram : diagramme permettant de modéliser les Packages, Flows et ViewContainers.

  • UI Structure : représentation arborescente permettant de modéliser la description statique de l’IHM (écrans, panels, widgets...).

  • Layout Diagram : diagramme de consultation des composants et composites d’un layout.

 

View Container Mockup : dessiner une ébauche d'écran illustrant une User Story

L’objectif n’est pas de concevoir un écran WYSIWYG (What You See Is What You Get), mais de définir une maquette servant par exemple de base de réflexion pour un atelier d’un groupe de travail.

 

Menu contextuel sur View Container WenPage > New Representation > View Container Mockup

Une fois que l’on a assimilé les concepts, et pour ceux qui connaissent la plateforme Eclipse, le produit est relativement convivial.

 

ISD crée des images JPEG pour chaque version de la maquette.

 

obeo-information-system-designer-view-container-synthese-evenements-assure-complet   

Maquette (Mockup) de l'écran illustrant la User Story : « US02 : En tant que Gestionnaire Prévoyance, je veux rechercher un assuré suivant des critères afin d'avoir l'historique des survenances et sinistres associés pour prendre la décision d'ouvrir un nouveau dossier de prestation ». 

 

Flow Diagram : cinématique de navigation, cartographie des événements système
et utilisateurs pour les transitions d'écrans. 

obeo-information-system-designer-flow-complet   

Les états (States) View peuvent être représentés par leur Mockup (Maquette) et être lié avec leur View Container. Les transitions peuvent être des actions système ou utilisateur, comme cliquer sur un bouton.

 

Associer des écrans et des éléments d'IHM avec des exigences 

Dans Cinematic > View Container > View Container Mockup > Sélectionner un composant (bouton, etc.) > dans la vue Linked Requirements cliquer sur le bouton jaune Link Requirements with selection > dans la fenêtre sélectionner un référentiel, puis une catégorie et enfin une ou plusieurs exigences.

 

Traçabilité d'une exigence avec les éléments d'IHM (Requirements Traceability Matrix)

Au chapitre « Classer hiérarchiquement vos exigences en catégorie », nous avions vu comment créer un Requirement Model dans lequel il y avait 3 matrices de traçabilité :

 

  • Requirements Task Traceability Matrix,
     
  • Requirements Traceability Matrix,
     
  • Requirements Use Case Traceability Matrix.

 

Les Requirements Task Traceability Matrix et Requirements Use Case Traceability Matrix ont été abordées. Reste la matrice Requirements Traceability Matrix. Cette matrice est complète, en indiquant pour une exigence tous les éléments de l'application qui lui sont liés. En plus des use cases, tâches et actions, elle indique les éléments d'IHM.

 

obeo-information-system-designer-matrice-tracabilite-view-3 

Requirements Traceability Matrix permet de voir les éléments d'IHM en lien avec une exigence.
Ici, le bouton « Rechercher, » la cinématique des écrans « Flow »
et l'écran « Synthèse des événements d'un assuré » sont liés à l'exigence Req01.

 

 

Générer une documentation

  1. Sélectionner le projet dans Model Explorer > Menu File > New > Other… > M2Doc > New Generation > sélectionner un template, pour le test nous avons pris ceux de l’exemple E-BookStore (voir paragraphe suivant). Pour cela, il suffit de cliquer dans Browse workspace et de choisir un template. Plusieurs templates sont proposés :
    • E-BookStore_Cinematic_template.docx pour les écrans
    • E-BookStore_DataBase_template.docx pour les bases de données
    • E-BookStore_GraalSystemAndRequirements_template.docx pour la méthode de spécifications fonctionnelles Graal et les exigences.

  2. Sélectionner le fichier MyGeneration.genconf qui est apparu dans le projet > clic droit > Generate documentation.

  3. Un document MyGeneration.generated.docx Word est généré.

  

obeo-information-system-designer-procedure-generation-de-documentation  

Des modèles prêts à l'emploi sont proposés dans l'exemple complet E-BookStore fourni avec ISD.

 

 

Une étude de cas pédagogique couvrant l'ensemble des étapes d'un projet de réalisation d'une application avec ISD, allant de l'analyse à la génération de code

 

File > New > Example > Information System > E Book Store

 

obeo-information-system-designer-exemples-ebookstore-04 

Exemple complet d’un site de e-commerce d’une librairie en ligne,
illustrant toutes les couches applicatives de démonstration

 

Annexe 2 : liste des liens présents dans cet article

Les articles précédents consacrés à Obeo ISD :

 

  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

 

 

Le site de référence :

 

Obeo Information System Designer (ISD)

 

 

Nos articles sur NoUML :

 

 

 

Le site de Kent Beck, l'inventeur des users stories :

 

Kent Beck

 

 

Diagramme d'exigences normalisé avec SysML de l'OMG :

 

 

 

Si vous voulez savoir comment est conçu ISD :

 

  1. DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
      
  2. Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]
      
  3. Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
      
  4. 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]

 

Annexe 3 : pour aller plus loin

 

    

    


12/09/2023
0 Poster un commentaire

Méthode Graal, le NoUML d’Obeo, parfaite fusion entre un UML phagocyté et un BPMN édulcoré. S.1 Ep.2

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.

 

archimate-processus-et-service-metier-abip-04     

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 : 

 

 

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

 

 

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 : 

 

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

 

obeo-information-system-designer-graphe-des-acteurs-10 

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

obeo-information-system-designer-use-case-main-view-sans-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

obeo-information-system-designer-use-case-diagram-creer-un-dossier-prevoyance 

 

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

obeo-information-system-designer-use-case-diagram-creer-un-sinistre

 

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)

 

CapabilityMapAvecLogo   

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.

 

obeo-information-system-designer-namespace-hierarchy-and-dependencies 

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. 

 

obeo-information-system-designer-domain-classes-diagram-prestation-prevoyance 

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

 

obeo-information-system-designer-domain-classes-diagram-produit

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.

 

 

urbanisation-si_logo

 

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 :

 

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

obeo-information-system-designer-graal-model 

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

 

obeo-information-system-modele-graal-liste-graphe 

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

 

obeo-information-system-designer-use-case-main-view-avec-acteurs-2 

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

 

obeo-information-system-designer-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

 

 


29/08/2023
0 Poster un commentaire