urbanisation-si

urbanisation-si

Ingénierie Dirigée par les Modèles (IDM)


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

Convaincue que certains outils open source et les normes sont aujourd'hui arrivés à maturités et présentent pour les entreprises de nombreux avantages, nous avons volontairement écarté les produits commerciaux et leurs langages propriétaires comme MEGA, IBM Rational, Entreprise Architect, ... pour nous consacrer uniquement à 2 solutions open source QVT (Query View Transformation) et ATL (ATLAS Transformation Language) implémentées dans Eclipse Modeling Tools.

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-ATL-QVT-1.PNG

 

Tous les langages de modélisation unanimement reconnus et largement utilisés que ce soit UML, OCL, BPMN, SysML, MDA, … proviennent de l'OMG (Object Management Group).

 

Dans le cadre de son framework MDA (Model Driven Architecture, ou on veut s’affranchir de cette marque déposée, on parle plus généralement de MDE Model Driven Engineering ou en français IDM  Ingénierie Dirigées par les Modèles), l’OMG  proposait, il y a maintenant 12 ans,  QVT comme langage de manipulations  de modèles.

 

Voir les articles sur MDA :

 

 

Comme à son habitude, l'OMG fournit une documentation abondante très théorique à charge comme ils disent aux éditeurs de fournir des implémentations. Plus facile à dire qu’à faire.

 

Mais que signifie QVT ?

 

« Q » pour « Query », on peut sélectionner des éléments sur un modèle. Le langage utilisé pour cela est OCL  (Object Constraint Language) légèrement modifié et étendu, avec une syntaxe différente et simplifiée.

 

Voir les articles sur OCL :

 

  

« V » pour « View » : une vue est une sous-partie d'un modèle et est définie via une query. Une vue est un modèle à part, avec éventuellement un méta modèle restreint spécifique à cette vue.

 

« T » pour « Transformation » : transformation d'un modèle en un autre.

 

Les habitués de l’OMG savent que leurs normes sont complètes et complexes afin de couvrir un périmètre très large.

 

QVT n’échappe pas à la règle puisqu’on dispose, excuser du peu, de 3 langages et 2 modes pour définir des transformations.

 

1) Mode impératif
QVTo (Query View Tranformation Operational)
En utilisant ce langage, il vous faudra écrire l’algorithme d’implémentation comme dans un langage de programmation classique comme Java ou le langage C.

 

2) Mode déclaratif
On exprime ce qu’on veut sans dire comment le réaliser comme par exemple XSLT pour les transformations d’arbre XML.
On trouve :
QVTr (Query View Tranformation Relational) : il s’agit d’un langage de haut niveau où on spécifie des correspondances entre des ensembles/patrons d'éléments de 2 modèles.
QVTc (Query View Tranformation Core) :  plus bas niveau que QVTr, le langage est plus simple, mais avec le même pouvoir d'expression de transformations que QVTr.

 

La seule plateforme open source solide que j’utilise est Eclipse et pour l’IDM, la suite « Eclipse Modeling Tools ».

Le métamétamodèle maison est Ecore.

 

Voir les articles sur Ecore :

 

 

Au cours de mes différentes mission, l’outillage de cartographie des systèmes d’information et la conception de méta modèle ont toujours reposé sur Ecore.

 

On trouve des méta modèles Ecore pour les langages de modélisation (DMN, …), les différents cadres d’architectures d’entreprise (Praxeme, TOGAF, Urba-EA, ...), des langages aussi spécifiques comme ceux de règles métiers (DROOLS), …

 

A la date de cet article, la version Oxygen d'Eclipse, intègre la plupart des plugins (Ecore, OCL, Sirius) et ceux qui manquent peuvent être installés directement dans le menu Help – Install Modeling Components, c'est le cas de QVTo et ATL.

 

Plus la peine d’être un geek pour installer un plugin.

 

 

Malheureusement, c’était trop beau pour être vrai, si effectivement ATL et QVTo ne pose pas de problèmes, QVTr (appélé QVTd Declarative dans Eclipse) n’est pas proposé dans la liste et pour cause, le projet est en incubation.

 

Voici le lien si vous voulez évaluez l’état d’avancement.

http://www.eclipse.org/mmt/downloads/?project=qvtd

Il vous faudra donc vous bagarrez, téléchargez, dézippez et installez dans Eclipse qvtd-incubation-Update-0.14.0.zip.

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-QVT-Declarative-2.PNG

 

 

QVTr (Query View Tranformation Relational, (appélé QVTd Declarative dans Eclipse)

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-Eclipse-QVT-Declarative-3.PNG

 

QVTr par sa nature, est limité aux relations entre les éléments de modèle source et cible.

Il permet d'exprimer une représentation de haut niveau des transformations de modèle à modèle. Mais il est parfois difficile de faire des transformations complexes dans un style déclaratif tel qu'utilisé dans QVTr.

 

QVTr suffit pour les transformations simples.

La performance est très faible.

Il est possible de manipuler de petits modèles contenant quelques centaines d'éléments mais l'utiliser avec des modèles plus gros donne des résultats de temps d'exécution énormes.

La principale raison en est le mécanisme d’identification de schémas et le fait que chaque relation doit être établie pour que la transformation réussisse.

Pour chaque relation dans la transformation, il est nécessaire de passer en revue tout le modèle pour toutes les correspondances et de les maintenir.

 

La documentation nous met en garde que cette version est encore immature et ne peut être utilisée qu’à des fins de recherches et d’expérimentations.

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-Eclipse-QVT-Declarative-not-for-use-4.PNG
 

 

QVTo (Query View Tranformation Operational)

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-Eclipse-QVT-Operational-architecture-3_1.PNG

  

QVTo (Query View Tranformation Operational) pour le mode impératif, étend QVTr avec des constructions impératives comme le « if », … (extension d’OCL). Il possède une « Black Box », qui est un mécanisme pour appeler un programme externe.

 

Pour un exemple complet des possibilités de QVTo, voir le tutoriel :

 

 

Toutes les fonctionnalités de la norme ne sont pas encore implémentées. On nous promet qu’elles le seront dans un roche avenir.

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-Eclipse-QVT-Operational-not-for-use-4.PNG
 

 

ATL (ATLAS Transformation Language)

 

meilleur-outil-MDA-MDE-IDM-transformation-de modeles-Eclipse-ATL-logo-6.PNG

 

Le langage de transformation ATL (ATLAS Transformation Language) est un langage (french tech) et un ensemble de transformation prêtes à l’emploi, développé et maintenu par OBEO et INRIA-AtlanMod (2006). Il a été initié par l'équipe AtlanMod (précédemment appelée ATLAS Group).

 

Les objectifs sont de :

  • Faciliter la résolution de problème d’interopérabilité entre systèmes,
  • Résoudre les problèmes de développement logiciel  
  • Traiter des structures de données hétérogènes

 

 

 

Dans le domaine de l'IDM (MDE), ATL fournit des moyens de produire un ensemble de modèles cibles à partir d'un ensemble de modèles sources.

 

 

Publié selon les termes de la Licence publique Eclipse, ATL est un composant M2M (Eclipse), à ​​l'intérieur du Projet de modélisation Eclipse (EMP Eclipse Modeling Project).

 

ATL est basé sur QVT qui est un groupe de gestion des objets standard pour effectuer des transformations de modèles. Il peut être utilisé pour faire une traduction syntaxique ou sémantique.

 

ATL est construit sur une machine virtuelle de transformation de modèles.

 

ATL est un langage à vocation déclarative, mais en réalité hybride, qui permet de faire des transformations de modèles aussi bien endogènes qu’exogènes.

 

Les outils de transformation liés à ATL sont intégrés sous forme de plug-in ADT (ATL Development Tool) pour l’environnement de développement Eclipse.

 

Un modèle de transformation ATL se base sur des définitions de métamodèles au format XMI. Sachant qu’il existe des dialectes d’XMI, ADT est adapté pour interpréter des métamodèles décrits à l’aide d’EMF Ecore (Eclipse) ou MDR (NetBeans).

  

ATL est défini par un modèle MOF pour sa syntaxe abstraite et possède une syntaxe concrète textuelle.

Pour accéder aux éléments d’un modèle, ATL utilise des requêtes sous forme d’expressions OCL. Une requête permet de naviguer entre les éléments d’un modèle et d’appeler des opérations sur ceux-ci.

 

 

Une règle déclarative d’ATL, appelée Matched Rule, est spécifiée par un nom, un ensemble de patrons sources (InPattern) mappés avec les éléments sources, et un ensemble de patrons cibles (OutPattern) représentant les éléments créés dans le modèle cible.

 

 

Depuis la version 2006 d’ATL, de nouvelles fonctionnalités ont été ajoutées telles que l’héritage entre les règles et le multiple pattern matching (plusieurs modèles en entrée).

  

Le style impératif d’ATL est supporté par deux constructions différentes. En effet, on peut utiliser soit des règles impératives appelées Called Rule, soit un bloc d’instructions impératives (ActionBlock) utilisé avec les deux types de règles.
Une Called Rule est appelée explicitement en utilisant son nom et en initialisant ses paramètres.

 

ATL supporte deux modes d’exécution différents : le mode standard et le mode par raffinement.

 

 

Dans le mode standard, les éléments sont créés seulement quand les patterns sources définis dans les règles déclaratives ont été reconnus dans le modèle ; le système instancie alors les éléments du pattern cible. Une fois l’étape d’instanciation passée, un lien de traçabilité est créé, et associe chaque élément reconnu du modèle source à un élément du modèle cible. Finalement, le système évalue ensuite ces liens de traçabilité afin de déterminer les valeurs des propriétés des éléments instanciés.

 

 

Dans le mode par raffinement, les éléments dont les patterns sources non pas été matchés par les règles sont automatiquement copiés dans le modèle cible par le moteur d’exécution. Ceci réduit considérablement le développement de transformations destinées à modifier une petite partie d’un modèle en gardant le reste inchangé.

 

L'écriture d’une transformation dans ATL est assez simple et la partie impérative d'une règle ATL aide beaucoup à gérer la création des éléments et le flux d’exécution. Il est également possible de générer la cible et de lier les modèles directement dans une exécution afin de rendre la règle plus intuitive.

 

ATL est une implémentation de la proposition QVT, mais c'est un langage hybride à la fois déclaratif et impératif. Cela améliore son expressivité et s'accorde avec la capacité à exprimer toute forme de transformation mais contrairement à QVT, les transformations ATL sont unidirectionnel.

 

Dans QVTr, les appels d'une relation à l'autre se font via la clause where mais dans ATL, ce n'est pas le seul moyen d'appeler d'autres règles.

Il est possible de spécifier dans une règle que la spécification d’un élément mappé doit être transformé en transformant un élément spécifique du modèle source.

En utilisant ce mécanisme, il est possible de réduire le nombre d'éléments qui doivent être adaptés dans une règle de transformation.

Le fait que ATL est également compilé et exécuté dans une machine virtuelle rend l'exécution plus rapide que l'interprétation classique des règles de transformation.

  

Le plugin ATL pour Eclipse est depuis plusieurs années dans un état finalisé, complet, stable, robuste, performant, supportant des modèles volumineux et s’inspire de QVTr et QVTo.

Je l’ai utilisé pour la migration d’un modèle de données vers un nouveau dans le cadre d’une fusion de 2 organisations qui en profitaient pour urbaniser et intégrer des innovations dans leur nouveau Système d’Information.

 

Vous trouverez ci-dessous un cours exhaustif en français sur ATL. 

 

  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)

  

Sans aucune hésitation, le meilleur outil MDA, MDE/IDM est ATL d’OBEO / AtlanMod INRIA.
 
Il répondra à tous vos besoins de traitement de modèles que ce soit des transformations, des dérivations, la possibilité de faire des requêtes complexes à des fins de traçabilité, de vérification de règles, de comparaison, de statistiques ou bien de migration d’un modèle de données vers un nouveau.

 

Rhona Maxwel

@rhona_helena

 

"Créer, c'est donner une forme à son destin."

Albert Camus

 

 

Articles conseillés :

 

 


14/10/2017
0 Poster un commentaire

Transformation de modèles et Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture)

L'architecture d'entreprise qui inclut l'urbanisation des Systèmes d'Information ne cesse de prôner la transformation ou dérivation des couches la composant, stratégie en métier, métier en fonctionnelle, fonctionnelle en applicative et applicative en infrastructure à des fins d'automatisation, de traçabilité et de gouvernance. 

C'est la que rentre en jeu, l’Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture) qui repose sur la volonté de décrire précisément les besoins des clients par des CIM (Computational Independent Models) et la connaissance métier d’une organisation dans des modèles abstraits indépendants des plates-formes (PIM - Platform Independent Models).

 

Ayant isolé le savoir-faire métier dans des PIM, on a besoin soit de transformer ces modèles en d’autres PIM (besoin d’interopérabilité, migration vers un nouveau système, fusion de SI en cas d’acquisition d’une autre organisation, …), soit de produire ou de créer des modèles PSM (Platform Specific Models) ciblant une plate-forme d’exécution spécifique (pour améliorer la portabilité et augmenter la productivité).

 

Dans le cadre de l’IDM, les artefacts manipulés sont des modèles.

Ces types de modèles sont donc des méta-modèles.

Un méta-modèle est un modèle qui définit les concepts d'un modèle d'instance.

Cette relation est purement syntaxique. 

 

transformation-de-modèles-IDM-MDE-MDA-00.PNG

 

La Meta-Object Facility (MOF) de la norme OMG à quatre couches (M0, M1, M2, M3) est l’architecture de méta-modélisation.

 

Voir ci-dessous un article que j'avais consacré aux métamodèles :

 

 

Par exemple, le métamodèle de UML (Unified Modeling Language) est un modèle M2 du MOF.

De même, tous les langages spécifiques à un domaine (DSL Domain Specific Language) peuvent également être exprimé en modèles MOF.

 

Le noyau de MOF permet seulement d'exprimer des propriétés structurelles simples,

Associations similaires entre éléments, encapsulation, cardinalité, etc.

Le langage de contraintes d'objet (OCL Object Constraint Language) est un langage de contrainte déclaratif d’instructions ordonnées standard et un langage de requête, qui est utilisé pour associer des règles à des modèles.

Par exemple, on peut spécifier une structure, des invariants, des définitions et des pré/post conditions, des opérations MOF abstraites dans la langue OCL.

 

Voir mes tutoriaux sur OCL :

 

 

Le métamodèle de transformation contient trois éléments essentiels : source, cible et relation de transformation ou dérivation.

La relation de transformation est un ensemble de liens explicites entre les éléments de la source et le modèle cible.

Ces liens explicites jouent un rôle clé dans l’approche IDM.

Les relations entre les métamodèles définissent la structure des liens et des propriétés qu'ils doivent satisfaire et le méta-modèle de transformation, les liens qui doivent exister.

 

Une transformation de modèles est la génération d’un ou de plusieurs modèles cibles à partir d’un ou de plusieurs modèles sources.

 

Une transformation des entités du modèle source met en jeu deux étapes.

 

La première étape permet d’identifier les correspondances entre les concepts des modèles source et cible au niveau de leurs métamodèles, ce qui induit l’existence d’une fonction de transformation applicable à toutes les instances du métamodèle source. Cette correspondance se fait par l'établissement de règles. 
La seconde étape consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou d’exécution.

 

L’approche par modélisation consiste quant à elle à appliquer les concepts de l’ingénierie des modèles aux transformations des modèles elles-mêmes.

 

L’objectif est de modéliser les transformations de modèles et de rendre les modèles de transformation pérennes et productifs, en exprimant leur indépendance vis-à-vis des plates-formes d’exécution.

 

transformation-de-modèles-IDM-MDE-MDA-01.PNG

 

Une transformation endogène se situe dans le même espace technologique et les modèles source et cible sont conformes au même méta- modèle.

Par exemple transformation d'un modèle UML en un autre modèle UML

 

Une transformation exogène se situe entre 2 espaces technologique différents et les modèles source et cible sont conformes à des méta- modèles différents.

 

Par exemple transformation d'un modèle DMN ( Decision Model Notation )  en DRL (Drools Rules Language, le langage natif de règles métiers du moteur open source DROOLS).

 

taxonomie-transformation-de-modèles-IDM-MDE-MDA-02.PNG

 

Une transformation en série peut servir à réaliser une application ou un processus basé sur une série de transformations de modèles.

 

Par exemple : modèle de l'application au niveau abstrait, avec un modèle de composant abstrait, modèle PIM puis une projection du modèle vers un modèle de web services (SOAML) : PSM

 

Les types d’outils de transformation de modèles :

  • Langage de programmation « standard » : Ex : Java, pas forcément adapté pour tout, sauf si interfaces spécifiques, ex : framework Eclipse/EMF
  • Langage dédié d'un atelier de génie logiciel : Ex : MDG pour l’AGL Enterprise Architect, Langage de script de l’AGL MEGA, MDA Modeler IBM Rational, souvent propriétaire et inutilisable en dehors de l'AGL
  • Langage lié à un domaine/espace technologique : Ex: XSLT dans le domaine XML, AWK pour fichiers texte ...
  • Langage/outil dédié à la transformation de modèles : Ex : la norme QVT (Query View Transform) de l'OMG, le standard de l’industrie actuellement : ATL (Atlas Transform Language)

 

3 grandes familles de modèles et outils associés :

  • Données sous forme de séquence : Ex : fichiers textes (AWK)
  • Données sous forme d'arbre : Ex: XML (XSLT)
  • Données sous forme de graphe : Ex : diagrammes UML, outils : QVT, ATL, …

 

3 grandes catégories de techniques de transformation :

  • Approche déclarative : recherche de certains patrons (d'éléments et de leurs relations) dans le modèle source. Chaque patron trouvé est remplacé dans le modèle cible par une nouvelle structure d'élément. L’écriture de la transformation est « assez » simple mais ne permet pas toujours d'exprimer toutes les transformations facilement.
  • Approche impérative : proche des langages de programmation usuels, on parcourt le modèle source dans un certain ordre et on génère le modèle cible lors de ce parcours. L’écriture transformation peut être plus lourde mais permet de toutes les définir, notamment les cas algorithmiquement complexes.
  • Approche hybride : à la fois déclarative et impérative. La plupart des approches déclaratives offrent de l'impératif en complément car plus adapté dans certains cas.

 

Les référentiel pour stocker les modèles et méta-modèles utilise XMI (XML Interchange, norme de l'OMG). 

 

Les principales implémentations des langages de transformation de modèles ATL et QVT utilisent le métamétamodèle Ecore d'Eclipse qui est le standard de l'industrie. On retrouve tous les principaux concepts du niveau M3 UML du MOF  de l'OMG.

 

On trouve les métamodèles Ecore à peu près pour tout, les langages de modélisation normalisés (UML, SysML, BPMN, DMN, BMM, SOAML, ...) et même des langages open source comme celui de DROOLS, le moteur de règles métier, standard de l'industrie.

 

Voir mes articles sur Ecore : 

Les cadres d'architecture d'entreprise comme TOGAF (The Open Group Architecture Framework), Praxeme, ... énoncent des principes de dérivation des différents niveaux ou aspects. Mais aucune ne précise avec quels outils.

 

Alors, la question qui me tourmente, avez-vous ou votre organisation, mis en place des transformations de modèles et avec quels outils ?  

 

Rhona Maxwel

@rhona_helena

 

"Parmi les objets répandus au hasard, le plus beau c'est le cosmos. L'harmonie invisible est plus belle que le visible."

Héraclite d'Ephèse  

 

 

Articles conseillés :

 


06/10/2017
0 Poster un commentaire

Pour trouver les services logiques, les modèles sémantiques et pragmatiques tu dériveras. (« Praxeme 4ème commandement extrait de la bible de l’aspect logique »).

La bible de la méthodologie d’architecture d’entreprise franco française Praxeme, énonce entre autres que l’architecture logique prolonge les décisions d’urbanisation du SI et que les services et données dérivent des modèles amont c’est-à-dire des aspects sémantique (entités métiers) et pragmatique (processus métiers et cas d’utilisation).

  

praxeme-service-logique-derivation-aspect-semantique-aspect-pragmatique.PNG

 

En 2006, le buzz était sur l’architecture SOA (Service Oriented Architecture) et je me suis intéressée à Praxeme qui était une des seules méthodes SOA open source et cerise sur le gâteau en français.

  

Aujourd’hui, Praxeme est à l’architecture d’entreprise ce que la théorie unifiée est à la physique.

 

Praxeme agrège toutes les bonnes pratiques en cours, allant de la stratégie d’entreprise à la réalisation d’applications informatiques en passant par l’urbanisation du Système d’Information, la gouvernance SI, l’architecture technique, SOA, l’ingénierie dirigée par les modèles jusqu’aux bonnes pratiques de conception.

 

 

On peut dire que Praxeme n’a rien inventé, mais elle a le mérite d’avoir intégré avec succès toutes ces bonnes pratiques avec une terminologie bien à elle.

 

Par exemple, la dérivation des aspects sémantique et pragmatique en aspect logique s'inspire de MDA (Model Driven Architecture, norme OMG) à la transformation du niveau CIM (Computational Independent Model) en PIM (Platform Independent Model) ou bien encore dans le monde de l’urbanisation du Système d’Information, à la cartographie métier qui se projette sur la cartographie fonctionnelle.

 

Voici quelques articles que nous avions consacrés sur ces sujets :

1) Sur les transformations des vues de l'urbanisation du Système d'Information

 

2) Sur l'Ingénierie Dirigée par les Modèles (MDE Model Driven Engineering)

  

Pour pouvoir manipuler un modèle, on doit avoir son méta-modèle.

 

Mais où est passé le méta-modèle Praxeme ?

 

Sur le site officiel :

http://www.praxeme.org/telechargements/catalogue/

il est indiqué que le document PxMDS-05 traitant du méta-modèle est « en cours ».

Mais il y a un bouton « Visiter » qui nous renvoie sur la page : 

http://wiki.praxeme.org/index.php?n=Modus.PraxemeMetamodel

Le lien « Le méta-modèle Praxeme » nous envoie à : 

http://wiki.praxeme.org/Praxeme.MetaModel/index.html

Nous arrivons sur un diagramme de package cliquable mais malheureusement quand on clique sur un package, on arrive sur une description textuelle des entités mais point de diagramme de classe représentant le méta-modèle.

Plus grave, quand on clique sur le deuxième lien « Caisse d’allocations Familiales », un autre lien « méta-modèle Praxeme » nous répond « Error 404, page not-found ».

 

meta-modele-praxeme-error-404-page-not-found.PNG

 

Notre objectif est de réaliser des prototypes, les extraits fournis dans les différents évangiles Praxeme seront donc parfaits pour nos démonstrateurs.

 

Voyons d’un peu plus près à quoi ressemblent les règles de dérivation. 

 

praxeme-service-logique-derivation-BRMS-BPM.PNG

 

Par exemple une classe sémantique (métier) devient une Machine Logique Métier élémentaire (attributs, opérations, associations et navigations) et une Machine Logique Métier ensembliste (services sur les collections).

 

Le modèle pragmatique composé de la vue de l’utilisation (use case) et la vue de l’organisation (processus métier, diagramme d’activité).

Par exemple, concernant la première, un use case devient une Machine Logique Organisation et un Service Logique Transactionnel.

Pour la dérivation des processus métier, la méthode parle d’un dispositif transverse chargé de l’ordonnancement et de l’exécution des services autrement dit un moteur de processus exécutables, BPM Business Process Management.

Pour la dérivation des règles métiers 2 solutions sont envisagées :

  • La programmation de la règle en dur
  • L’enregistrement dans un dispositif ad hoc autrement dit un moteur de règles, BRMS Business Rules Management System.

 

La méthode devrait intégrer plus clairement le couple de normes (BPMN, DMN).

BPMN (Business Process Model and Notation)  pour les processus métiers (aspect pragmatique vue organisation), et la norme DMN (Decision Model and Notation) pour les règles métiers (aspect sémantique).

Et pourquoi pas SOAML (SOA Modeling Language) pour les aspects logiques et les services ?

 

L’OMG (Object Management Group) fourni pour toutes ces normes, les méta-modèles complets avec leurs diagrammes de classes accompagnés des description textuelles.

 

Ainsi en utilisant des outils de transformation de modèles, il est possible d'industrialiser les processus et les règles de dérivation des aspects Praxeme.

 

Les aspects stratégiques peuvent être modélisés en utilisant la norme BMM (Business Motivation Model) que l'on pourrait dériver en aspects sémantique et pragmatique.

 

Et pourquoi pas dériver le couple (BPMN, DMN) en modèle de code (PSM Platform Specific Model) d’un moteur de processus métier ou de règles métiers, par exemple le couple open source bien intégré (jBPM, Drools).

 

Voir la série d’articles sur jBPM :

 

Voir la série d’articles sur les moteurs de règles métiers :

 

Comment automatiser ces transformations, (en praxemien on parle de dérivations car le terme transformation implique une modification du modèle source) ?

 

De nombreuses solutions existent comme XSLT (XML Stylesheet Language Transformation), ATL (Atlas Transformation Language), QVT (Query View Language), …

 

Voir par exemple le cours complet sur ATL et le tutoriel QVT.

1) ATL (Atlas Transformation Language)

 

2) QVT

 

Mais laquelle choisir ?

C’est ce que nous verrons prochainement.

 

Rhona Maxwel

@rhona_helena

 

"Et le secret de toute la méthode est là : en toute choses repérer soigneusement ce qui est le plus absolu."

René Descartes

 

 

Articles conseillés :

 

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?

  

Vous cherchez désespérement un formalisme pour vos processus métiers mettant en accord MOA et MOE, la solution miracle existe, elle s'appelle BPMN 

 

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN 

 

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

 

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

 

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

 

Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques

 

SysML pour les nuls : de la modélisation des exigences à la réalisation du système


18/08/2017
0 Poster un commentaire

Query View Transform (QVT) Operational : tutoriel, plus simple tu meurs !

query-view-transform-qvt-operational-tutoriel.png

Le métamodèle source et cible. 

 

Mes derniers articles sont consacrés au langage de transformation de modèles ATL (Atlas Transformation Language). 

Voir par exemple le tutoriel complet :

http://www.urbanisation-si.com/ingenierie-dirigee-par-les-modeles-idm-tutoriel-atl-atlas-transformation-language-le-da-vinci-code-de-la-transformation-atl

ou bien le cours complet qui commence :

http://www.urbanisation-si.com/ingenierie-dirigee-par-les-modeles-idm-documentation-atl-atlas-transformation-language-vous-saurez-tout-ou-presque-sur-les-modules

 

ATL est un langage opensource, largement utilisé utilisé dans l'industrie. Son implémentation est robuste et performante. Et surtout il existe des outils fiables comme le plugin pour Eclipse.

 

Mais ATL n'est pas une norme.

 

Son concurrent à l'avantage d'être une norme de l'OMG Object Management Group , l'organisation qui a fait notamment UML, MDA, ...

Il s'agit de QVT (Query View Transform). Il existe 2 types de QVT : QVTd (déclaratif, diisé en QVTr Relation et QVTc Core), équivalent des "matched rules" ATL et QVT Operational (impératif), équivalent des "called rules" ATL.

QVT avec son pédigré, pourrait être "La Solution" ultime pour transformer des modèles.

Seulement voilà, comme très souvent dans les normes, QVT souffre d'une grande complexité.

Mais il y a pire ! Les outils l'implémentant sont rares et incomplet. Seul QVTo commence à être implémenté alors que QVT-Relation est à l'état d'embryon.

 

Eclipse propose un plugin pour QVT Operational et un autre non finalsé pour QVT Relation.

 

Pour l'installer :

  1. http://projects.eclipse.org/projects/modeling.mmt.qvt-oml/downloads
  2. Décompressez le zip dans un répertoire.
  3. Dans Eclipse, allez dans le menu Help - Install new software - Add - Local - sélecionnez le répertoire - nommez et OK

N'échapperons pas à la règle de commencer par le traditionnel "Hello world" que font tous les débutants dans un langage.

 

Tout d'abord le métamodèle source et cible dans notre cas de tutoriel "plus simple tu meurs", voici son fichier Ecore (ABC.ecore) : 

 

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="ABC" nsURI="http:///ABC.ecore" nsPrefix="ABC">
<eClassifiers xsi:type="ecore:EClass" name="Root">
<eStructuralFeatures xsi:type="ecore:EReference" name="element" upperBound="-1"
eType="#//Element" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="A" eSuperTypes="#//Element">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="a" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="B" eSuperTypes="#//Element">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="b" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="C" eSuperTypes="#//Element">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="c" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Element" abstract="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="id" lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="abc" upperBound="-1" eType="#//Element"
containment="true"/>
</eClassifiers>
</ecore:EPackage>

Créer un nouveau projet : File - New - Project - Eclipse Modeling Framework -Empty EMF Project

 

Clic droit sur ABC.ecore - Initialize ecore diagram : pour générer le diagramme du modèle, cela ne peut pas faire de mal !

 

Double clic droit sur ABC.genmodel - clic droit sur ABC (2 ème icône dans la hiérarchie) - Generate All

 

Clic droit sur le projet - run As - Run Configurations - onglet Arguments - VM arguments :

-Dosgi.requiredJavaVersion=1.6  -Xms256m  -Xmx768m  -XX:MaxPermSize=256m

puis Run

 

Une nouvelle instance d'Eclipse se lance pour exécuter le nouveau plugin.

 

File - New - Project - Model to Model Transformation - Operational QVT Project.

Nommez votre projet

 

Ecrire le source de la transformation :

 

modeltype ABC uses ABC('http:///ABC.ecore');

transformation NewTransformation(in source:ABC, out target:ABC);

main() {
      source.rootObjects()[Root]->map Root2Root();
}

mapping Root :: Root2Root() : Root {
      element += self.element->select(a |
            a.oclIsKindOf(A))[A]->map A2B();
}

mapping A :: A2B() : B
      when {
            self.id > 0
      }
      {
      result.id := self.id;
      result.b := self.a + " World!";
}

 A est transformé en B, en utilisant le même id et en concaténant l'attribut "a" à la chaîne "World" pour créer l'attribut "b".

 

Créer le modèle à transformer : 

Clic droit sur le projet - New - Other - Example EMF Model Creation Wizards - ABC Model 

Double clic sur le modèle vide - clic droit sur Root - New chlid - ajouter et modifier dans la vue Properties : 

  • A: id=1, A=”Hello”
  • A: id=-1, A=”World”
  • C: id=1, C=”C'est quoi ce truc ?”

query-view-transform-qvt-operational-tutoriel-1.png

 

Pour exécuter la transformation :

Clic droit sur le fichier de transformation (.qvto) - Run As - Run Configuration - Operational QVT Interpreter - New_configuration - Run

 

query-view-transform-qvt-operational-tutoriel-2.png

 

Le modèle transformé se trouve dans le fichier "sortie.abc" :

 

query-view-transform-qvt-operational-tutoriel-3.png

 

 

"La vraie valeur d'un homme réside, non dans ce qu'il a, mais dans ce qu'il est."
Oscar Wilde

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


20/10/2015
0 Poster un commentaire

Le plugin ATL (ATLAS Transformation Language) pour Eclipse : les étapes pour réaliser une transformation (2/2)

Surcharge de module et exécution de la configuration de lancement

plugin-eclipse-atlas-transformation-language-surcharge-module.png

Tandis que les modules et requêtes ATL sont exécutés un par un, il est aussi possible d'exécuter des modules par dessus d'autres.

Le résultat final est une transformation contenant l'union de toutes les règles de transformations et helpers, quand il est possible pour un module de surcharger des règles et helpers du module inférieur.

 

Exemple :

 

 

Ce module est réutilisé et surchargé quand c'est nécessaire par le module :

 

La transformation UML2Copy inclu la règle de transformation pour chaque instance de méta-classe qu'il doit copier.

Ce qui fait approximativement 200 règles pour la totalité du métamodèle  

 

Chaque transformation spécifique doit copier toutes les méta-classse exceptées les quelques méta-classes qui sont redéfinies.

La transformation UML2Profiles applique un profil aux instances de "uml::Model" instance, tous les autres éléments sont juste copiés.

Pour terminer, le module UML2Profiles est exécuté par dessus le module UML2Copy.

Il redéfini la règle "Model" qui copie chaque instance de "uml::Model", avec une version vérifiant que le profil que nous voulons appliqué  a déjà été appliqué.

Il introduit aussi une nouvelle règle "ModelProfile", qui vérifie que le profil que nous voulons appliquer n'a pas été appliqué et dans ce cas applique le profil.

Le résultat de la transformation contient toutes les règles figurant ci-dessus qui n'ont pas été barrées.  

La surimpression se est faite à l'exécution : il n'y a pas de module représentant la surimpression des différents modules les uns par dessus les autres.

Il y a juste plusieurs modules chargés les uns au dessus des autres, surchargeant les règles existantes et en ajoutant des nouvelles.

 

La surimpression est configurée dans l'onglet "Advanced",  "Run..."  de la configuration de l'exécution.

Attention : quand on ajoute des modules en surimpression, dans l'onglet "Advanced",  ils surchargent le module "main" spécifié dans l'onglet  "ATL Main Configuration".

 

Exécution de la configuration

Une fois la configuration de la transformation correctement effectuée, elle peut être lancée autant de fois que l'on désire.

Il suffit juste d'aller dans la fenêtre Run,  pour sélectionner la transformation et clique sur "Run".

 
"Tu dois devenir l'homme que tu es. Fais ce que toi seul peux faire. Deviens sans cesse celui que tu es, sois le maître et le sculpteur de toi-même."
Friedrich Nietzsche

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


18/10/2015
0 Poster un commentaire