urbanisation-si

urbanisation-si

Quels sont les meilleurs langages et notations de modélisation pour TOGAF ?

TOGAF est un cadre méthodologique générique pour l’architecture d’entreprise, il propose une liste d’artefacts facultatifs non exhaustive, mais n’impose aucune technique ni méthode et il est fortement recommandé d’en prendre et de les adapter.

Doit on alors absolument utiliser une multitude de normes et réaliser un travail d’adaptation complexe ou tout simplement prendre la voie du pragmatisme et choisir le langage de TOGAF, ArchiMate, prêt à l’emploi et simple d’utilisation mais non reconnu comme norme ?

 

meilleurs-langages-notations-de-modélisation-pour-TOGAF.jpg

 

Les normes rien que les normes, réservées aux experts en modélisation avec un budget d’adaptation et d’intégration.

 

L’étude de cas “Discount Travel” de l’open source Modelio a fait l’objet de plus de 40 articles.

Voir le dernier article référençant l'ensemble de l'étude de cas : 

 

Pour couvrir la modélisation des différentes phase ADM de TOGAF, nous avions utilisé exclusivement des normes de l’OMG :

  • UML (Unified Modeling Language),
  • SysML (System Modeling Language, qui est un profil UML)
  • BPMN (Business Process Model And Notation).

 

Le métamodèle TOGAF définit les concepts fondamentaux.

Voir l'annexe 1 : Le métamodèle TOGAF

 

L'implémentation de ces concepts de base, est réalisée dans un profil, seul possibilité d’extension d’UML.

 

Qu'est ce qu'un profil UML ?

Un profil est un ensemble de stéréotypes, de tagged-value et de contraintes OCL.

 

Un stéréotype est la possibilité de redéfinir un artefact de modélisation sans en changer la sémantique UML.

Par exemple, sur l’artefact UML “composant”, on peut définir le stéréotype “composant d’application d’entité” en précisant ses caractéristiques et éventuellement une icône le représentant visuellement.

 

Les tagged-value permettent de définir sur un élément, des méta-information sous forme de paires clé=valeur comme par exemple sur un composant UML :  “complexité=simple”.

 

Le langage OCL (Object Constraint Language) permet de mettre des règles s’appliquant sur le modèle.

Voir nos articles en annexe 2 : Le langage de contraintes OCL

Par exemple un voyageur ne peut pas être dans 2 hôtels différents à la même date.   

  

Nous avons vu au cours de l’étude qu’il fallait adapter et filtrer tous ces langages pour correspondre aux concepts et à la structure de TOGAF.

Voir en annexe 3 les articles dans lesquels les stéréotypes utilisés dans les phases ADM ont été définis.

 

Trois normes OMG pour TOGAF : UML, SysML et BPMN !

Par exemple UML, SysML et BPMN ne possèdent pas de concept de point de vue, notion fondamentale de TOGAF.

En UML, l’artefact le plus approprié pour modéliser un point de vue est le package.

 

UML est une boite à outil généraliste, on peut tout modéliser à condition de personnaliser les éléments du langage.

Pour TOGAF, la plupart des artefacts UML (classe, attribut, méthode, objet, package, cas d’utilisation, acteur, composant, port, interface, noeud, association, dépendance, …) ont été utilisés.

Pour qu’ils correspondent aux éléments de TOGAF, il a fallu les stéréotyper.

 

En ce qui concerne SysML, son diagramme d’exigences, unanimement reconnu comme la meilleure pratique, a été choisi pour modéliser cet aspect.

 

BPMN conçu spécifiquement pour les MOA pour modéliser les processus métier, il est évident de l’utiliser pour pour la partie processus de TOGAF.

 

Ces choix de langages et notations de modélisation ont été fait sur le critère principal que ce sont des normes acceptées et largement utilisées dans le monde entier aussi bien dans l’ensemble des domaines métier que par les éditeurs d’outils.

 

On trouve donc aujourd’hui une offre très large d’outils de modélisation supportant ces normes allant des open source aux versions commerciales.

En plus ces outils vont bien plus loin que d’offrir de la simple modélisation.

Ils mettent en place la vérification, la simulation et la transformation des modèles, la génération de code, la gestion d’un référentiel, dictionnaire, planification, traçabilité, estimation, génération de documentation, …

 

Mais est ce suffisant ?

En plus des 3 normes UML, SysML et BPMN, pour vraiment modéliser dans les règles de l’art et en suivant les recommandations de l’OMG, on pourrait ajouter dans l’étude de cas :

  • BMM Business Motivation Model, voir l'annexe 4 
  • DMN Decision Model and Notation, voir l'annexe 5 
  • SoaML Service Oriented Architecture Modeling Language

 

Juste pour information, car ça commence à faire beaucoup, je cite d’autres normes complémentaires, peu utilisées mais très intéressantes et définissant bon nombre de concepts et bonne pratiques.

 

  • CMMN Case Management Model and Notation : complète BPMN pour les cas d’utilisation, par exemple certaines activités d’un processus BPMN peuvent demander une séquence d’actions ad hoc à un acteur.
  • VDML Value Delivery Modeling Language : langage de modélisation standard pour l'analyse et la conception du fonctionnement d'une entreprise, en mettant l'accent sur la création et l'échange de valeur
  • OSM Organization Structure Metamodel : l’objectif principal est de permettre une représentation robuste de la structure d’une organisation, y compris les relations formelles qui vont au-delà de la structure hiérarchique traditionnelle.
  • ODM Ontology Definition Metamodel : la spécification définit une famille de méta modèles indépendants, de profils associés et de correspondances entre les métamodèles de plusieurs normes internationales pour l’ontologie et les paradigmes de modélisation conventionnels pour la capture de connaissances conceptuelles, telle que la modélisation entité-relation.

 

Cela fait beaucoup de normes !

Mais cela ne signifie en aucun cas de toutes les utiliser à tout prix.

Le théoricien et le puriste s’y intéressent, mais les décideurs d’entreprise ont des critères beaucoup plus pragmatiques et orientent leurs choix sur des solutions concrètes répondant juste à leurs besoins avec des retours d’expérience de mise en production réussie par la concurrence.

 

La logique voudrait qu’on utilise uniquement ces normes de l’OMG car elles constituent un véritable espéranto permettant à l’ensemble des acteurs d’une entreprise de communiquer.

L’intérêt est aussi de pouvoir s’adresser à une large communauté d’utilisateurs connaissant déjà UML et BPMN.

 

Installer un profil UML, les ennuis commencent !

Le nombre d’outils ayant fait leurs preuves et supportant ces normes est important aussi bien en gratuit/open source qu’en version commerciale.

 

Mais comme on vient de le voir, il y a beaucoup d’effort à fournir pour personnaliser ces normes afin de les adapter aux concepts de TOGAF.

Par exemple, l’ensemble des stéréotypes utilisé dans l’étude de cas est regroupé dans un profil UML nommé EAP (Enterprise Architecture Profil), en open source mais spécifique à l’outil Modelio.

 

Pour l’utiliser dans un autre outil, vous devez, télécharger le profil en choisissant le format, puis l’importer. :

  • Profil EAP (format XMI OMG UML 2.1.1)
  • Profil EAP (format XMI EMF UML 3.0.0)

Mais premier problème, quel profil choisir ?

Si vous n’êtes pas expert en modélisation, passez votre chemin.

XMI (XML Metadata Interchange) est une norme de l’OMG (décidément on ne les compte plus) définissant un format XML permettant d’avoir une représentation textuelle d’un modèle UML.

 

XMI définit l’aspect syntaxique, et l’aspect sémantique c’est à dire les éléments (classe, association, acteur, état, …) est défini par le métamodéle UML.

L’OMG définit une architecture en 4 couches, nommée MOF (Meta Object Facility).

Le niveau 0 représente le monde réel, les objets, le niveau 1 : le modèle, le niveau 2 : le métamodèle (modèle du modèle) et le 3ème : le métamétamodèle qui s’auto définit et permet de s’arrêter là.

 

Voir l'annexe 6 : les méta modèles

 

L’objectif est double, d’abord permettre l’exportation/importation d’un modèle entre différents outils de modélisation ensuite de donner la possibilité à des outils de pouvoir transformer les modèles en parsant ces fichiers XML soit par XSLT soit par des langages spécifiques à MDE (Model Driven Engineering) comme ATL (voir Annexe 7 : Un cours exhaustif en français sur ATL (Atlas Transformation Language) ) ou  QVT (voir Annexe 8 : Exemple complet des possibilités de QVT (Query View Transform) ).

 

S’il n’y avait qu’un seul métamodèle et qu’un seul choix mais malheureusement ce serait trop simple, il y a un autre standard de l’industrie qui n’est passé pas au stade de norme, nommé “Ecore” faisant partie de la galaxie des opens source de la modélisation EMF (Eclipse Modeling Framework).

Ecore est un métamodèle conçu pour être plus simple que la norme MOF et que l’on peut vraiment utiliser et il est supporté par beaucoup d’outils fonctionnant sous Eclipse, comme ATL, QVT, Sirius, … mais aussi par la majorité des outils commerciaux comme IBM, Oracle, ...

A cause de sa simplicité et de son utilisabilité, Ecore a eu la faveur de l’industrie qui a délaissé la norme MOF trop complexe et trop coûteuse à mettre en oeuvre comme bien souvent pour les normes.  

 

Il vous faudra donc vérifier que votre outil de modélisation supporte XMI MOF ou EMF Ecore.

Mais pas seulement, car une fois choisi, se pose le problème de la version.

 

Deuxième problème, qui dit version, dit risque d’incompatibilité !

Concernant XMI OMG, il existe plusieurs versions, la dernière étant la 2.5.1.

Si votre outil de modélisation ne supporte pas une version supérieure ou égale à la version téléchargée, le profil ne pourra pas être importé et vous ne pourrez pas l’utiliser.

Il vous faudra alors soit trouver un outil supportant la version ou bien tout recréer manuellement !

Ecore est stable, la dernière version date de 2014.

 

A l’inverse de ces normes, on trouve un langage de modélisation spécifique à TOGAF : ArchiMate.

 

Vous désirez directement modéliser TOGAF de la manière la plus efficiente, alors c'est ArchiMate qu'il vous faut.

Si vous ne connaissez pas UML, si vous ne maîtrisez pas le concept de profil, de métamodèle, si vous ne voulez pas prendre de risques d’importation de profil ou réaliser une adaptation manuelle et si pour vous l’utilisation des normes n’est pas une obligation : alors la solution à tous ces problèmes est  ArchiMate.

 

ArchiMate publié par l’Open Group, est un langage de modélisation entièrement dédié à l’architecture d’entreprise et dont les concepts correspondent exactement à ceux de TOGAF.

 

Avantages :

  • Par exemple ArchiMate propose des point de vue tels qu’ils sont spécifiés dans TOGAF.
  • Si vous connaissez TOGAF, vous n’aurez aucun mal à maîtriser ArchiMate.
  • Vous n’avez aucun profil à télécharger, d’adaptation à faire.
  • Beaucoup d’outils existent, en open source comme Archi de l’éditeur Archimatetool, ou commerciaux comme Enterprise Architect de Sparx Systems, ModelioSoft, Obeo SmartEA, Bizzdesign, Visual Paradigm, …

 

Inconvénients :

Si l’avantage d’ArchiMate est simple et peut être rapidement utilisé, il a aussi un principal défaut :

  • il n’est pas aussi complet que les normes OMG. notamment ArchiMate ne détaille pas les processus et règles métier
    La bonne pratique utilisée par les éditeurs est de combiner ArchiMate avec BPMN pour modéliser les processus, sachant que BPMN est prêt à l’emploi et ne nécessite pas l’importation de profil.


Dans la prochaine version 10 de TOGAF, il est à parier qu’ArchiMate sera complètement intégré dans le framework.

Conclusion

Soit vous êtes dans un environnement où tout est normalisé et l’utilisation des normes vous est imposée, et dans ce cas un profil UML pour TOGAF est la meilleure solution.

Il vous faudra alors choisir un profil existant, mais cela comporte des risques de maintenabilité et d’intégration ou bien vous décidez de créer votre profil UML mais cela va vous demander des compétences en métamodélisation ce qui n’est pas forcément votre métier sans parler du coût et de la charge de travail.

 

Vous êtes libre d’utiliser les outils que vous voulez, vous ne voulez pas vous embarrasser de détails techniques, vous désirez un formalisme synthétique pour modéliser directement en appliquant les recommandations TOGAF avec le moindre effort et à moindre coût, alors utiliser ArchiMate.

 

La meilleure pratique est un compromis consistant à utiliser ArchiMate et pour les processus métier BPMN.

 

Nous reviendrons sur une présentation d’ArchiMate (AchiMate pour les nuls) et nous ferons une correspondance avec les modèles UML de l’étude de cas “Discount Travel” dans les prochains articles.

 

Rhona Maxwel

@rhona_helena

 

“Si je recommençais ma vie je tâcherais de faire mes rêves encore plus grands ; parce que la vie est infiniment plus belle et plus grande que je n'avais cru, même en rêve.”
Georges Bernanos

 

 

Annexe 1 : Le métamodèle TOGAF

 



Annexe 2 : Le langage de contraintes OCL

  

 

Annexe 3 : Les stéréotypes utilisés dans les phases ADM

 

 

 

Annexe 4 : BMM Business Motivation Model

 

 

 

Annexe 5 : DMN Decision Model and Notation

Concepts de base 

 

Exemple allant des modèles jusqu’à leur exécution :

 

  1. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
  2. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions
  3. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision
  4. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions
  5. DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?

 

Exemple d'utilisation d'un métamodèle : pour aller plus loin avec DMN, nous avions même consacré un tutorial archi complet sur comment concevoir un outil de modélisation DMN :

 

  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 6 : Les méta modèles 

 

 

 

Annexe 7 : Un cours exhaustif en français sur ATL (Atlas Transformation Language)

 

  1. Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), concevez les métamodèles avant de passer aux choses sérieuses
  2. Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), le "Da Vinci code" de la transformation ATL
  3. Ingénierie Dirigée par les Modèles (IDM) : documentation ATL (ATLAS Transformation Language), vous saurez tout ou presque sur les modules
  4. Ingénierie Dirigée par les Modèles (IDM) : cours complet sur ATL (ATLAS Transformation Language)
  5. Ingénierie Dirigée par les Modèles (IDM) : cours complet sur ATL (ATLAS Transformation Language) : librairie ATL
  6. Ingénierie Dirigée par les Modèles (IDM) : cours complet sur ATL (ATLAS Transformation Language) : les types ATL
  7. Cours complet sur ATL (ATLAS Transformation Language) : les types primitifs
  8. Cours complet sur ATL (ATLAS Transformation Language) : les collections
  9. Cours complet sur ATL (ATLAS Transformation Language) : les énumérations
  10. Cours complet sur ATL (ATLAS Transformation Language) : les tuples
  11. Cours complet sur ATL (ATLAS Transformation Language) : les éléments de modèles des métamodèles
  12. Cours complet sur ATL (ATLAS Transformation Language) : Les expressions déclaratives dans OCL / ATL
  13. Cours complet sur ATL (ATLAS Transformation Language) : quelques trucs et astuces sur les expressions
  14. Cours complet sur ATL (ATLAS Transformation Language) : les helpers
  15. Cours complet sur ATL (ATLAS Transformation Language) : introduction aux règles ATL
  16. Cours complet sur ATL (ATLAS Transformation Language) : le code impératif ATL, l’instruction d’affectation
  17. Cours complet sur ATL (ATLAS Transformation Language) : le code impératif ATL, l’instruction de test : if
  18. Cours complet sur ATL (ATLAS Transformation Language) : le code impératif ATL, l’instruction de boucle : for
  19. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules” (les règles de correspondance), présentation (1/5)
  20. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, la section “from” (pattern source) (2/5)
  21. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, la section des variables locales (3/5)
  22. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, le pattern élément cible (4/5)
  23. Cours complet sur ATL (ATLAS Transformation Language) : les “Matched Rules”, la section bloc impératif (5/5)
  24. Cours complet sur ATL (ATLAS Transformation Language) : les règles paresseuses (Lazy Rules)
  25. Cours complet sur ATL (ATLAS Transformation Language) : les règles appelées (Called Rules)
  26. Cours complet sur ATL (ATLAS Transformation Language) : l’héritage des règles
  27. Cours complet sur ATL (ATLAS Transformation Language) : De la bonne utilisation des règles dans le langage ATL
  28. Cours complet sur ATL (ATLAS Transformation Language) : le mode “affiné” ATL
  29. Cours complet sur ATL (ATLAS Transformation Language) : les requêtes ATL
  30. Cours complet sur ATL (ATLAS Transformation Language) : les mots clés ATL
  31. Cours complet sur ATL (ATLAS Transformation Language) : pour terminer, une dernière chose à laquelle il faut prendre garde !
  32. Le plugin ATL (ATLAS Transformation Language) pour Eclipse : les étapes pour réaliser une transformation (1/2)
  33. Le plugin ATL (ATLAS Transformation Language) pour Eclipse : les étapes pour réaliser une transformation (2/2)

 

 

Annexe 8 : Exemple complet des possibilités de QVT (Query View Transform)

 



03/09/2018
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 192 autres membres