urbanisation-si

urbanisation-si

TOGAF pour les nuls.

Voici un condensé sur TOGAF (The Open Group Achitecture Framework), le standard d’architecture d’entreprise qui s’impose aujourd’hui.

Dans cet article vous trouverez tout ce que vous devez savoir sur TOGAF sans être obligé de lire les 52 documents de référence en anglais.

 

TOGAF-les-phases-de-l-ADM-Architecture-Development-Method-01.PNG

  

Comme nous l’avions fait pour un autre cadre d'architecture d'entreprise, le framework de Zachman, pour le langage de modélisation des processus métiers BPMN et enfin le langage de modélisation des systèmes complexes SysML :

 

 
  

Le meilleur cap pour atteindre son but.

 

TOGAF est une méthode générique comportant des solutions clés en main à la transformation de l’architecture d’entreprise.

 

Évidemment l’objectif suprême est la réalisation d’applications opérationnelles.

  

Pour se faire, il faut une vision globale couvrant les aspects stratégiques, métiers, organisationnels, s’assurer de l’alignement entre le métier et la technique, rechercher constamment l’évolutivité des SI et avoir une culture de l’innovation.

 

TOGAF intègre les stratégies, les exigences, les processus métiers, les applications, les infrastructures techniques et des associations efficientes entre ces différents aspects et va même jusqu'à la planification et la gestion du changement.

 

L’ADM (Architecture Development Method) spécifie le cycle des étapes ou phases de la méthode et leurs transitions. Le plancher de la durée d’un cycle ADM peut être de 6 mois et le plafond de 2 ans.

 

Comme toutes méthodes, pour contribuer à atteindre les objectifs fixés depuis la vision (A) jusqu'à la maintenance de l’architecture déployée (H), les étapes requièrent des artefacts en entrées et fournissent des produits en sortie.

 

La démarche consiste de connaître l’existant, fixer la cible, établir la meilleure trajectoire pour l’atteindre et mettre en place les moyens pour réaliser avec succès la transformation.

 

Les déclencheurs pour une mise œuvre de TOGAF peuvent être :

  • la fusion ou rachat de 2 organisations,
  • la conception de services innovants,
  • la réorganisation interne face à la concurrence.

 

Mes retours d’expérience m’ont montré que l’on doit toujours adapter une méthode au contexte et ne jamais vouloir l’appliquer à la lettre coûte que coûte sinon de risquer que les parties prenantes ne veulent plus s’impliquer.

 

Les évolutions concernent des domaines spécifiques liées aux objectifs métiers et l’organisation continue de fonctionner comme s’il n’y avait pas de transformation en cours.

 

Concrètement la trajectoire vers l’architecture cible est constituée de projets de réorganisation de processus métiers, de développement d’applications, du changement de modèles de données.

L’élaboration de la planification des projets opérationnels est un des principaux livrables de TOGAF.

 

Exemple d’une trajectoire d’une de mes missions de conseil pour une fusion de 2 mutuelles :
 
Pallier 1
 : réalisation des modules applicatifs de gestion des personnes et des contrats pour le domaine individuel, cartographie du nouveau référentiel produit, réalisation du module applicatif concernant le paramétrage et le référentiel des produits, migration des anciennes bases de données vers le nouveau modèle.
 
Pallier 2 : développement du domaine collectif, réalisation des moteurs de liquidation des garanties santé et prévoyance, intégration des modules applicatifs
 
Pallier 3 : réalisation des modules de traitements des prestations pour les gestionnaires santé et prévoyance, intégration des modules, accompagnement aux changements pour les paramètreurs et les gestionnaires.
 
Pallier 4 : développement des batchs, refonte du site internet pour les adhérents en individuel et collectif.
 
Pallier 5 : mise en production

 

Les différences entre l’architecture d’origine et la cible doivent être liées avec les objectifs métiers, cette traçabilité est matérialisée par une matrice « écarts existant/cible et objectifs métiers » pour étude et vérification.

Ces indicateurs permettent de matérialiser l’effort à fournir pour que l’organisation capable de répondre à la nouvelle stratégie.

A-t-on suffisamment innover, a-t-on les bonnes compétences, les processus métiers sont-ils efficients, les infrastructures techniques sont-elles en adéquation avec l’ambition stratégique ?

 

Il faut bien avoir conscience qu’au cours de la phase d’élaboration, l’identification des écarts et l’évaluation des impacts sont intimement liés, et on doit toujours considérer l’entreprise dans sa globalité.

 

L’ADM a pour but d’établir de nouvelles capacités métiers, pour satisfaire les clients. C’est toute la chaîne de production de valeur qui est concernée. Une application techniquement réussie ne suffit pas s’il n’y a pas l’adhésion de ces utilisateurs, l’implication de la direction générale, un processus non optimisé.

 

 

Qu'en est il des couches d’architecture dans TOGAF.

 

TOGAF-Architecture-02.PNG

  

Dans l’architecture TOGAF, on retrouve à peu de choses près les niveaux de l’urbanisation des Systèmes d’Information (métier, fonctionnel, applicatif, technique) :

 

  1. L’architecture métier représente la stratégie, les objectifs, les processus métiers, les aspects fonctionnels.
     
  2. L’architecture des données représente les aspects organisationnels et la gestion des informations  
     
  3. L’architecture applicative représente les applications, les modules ou composants logiciels ainsi que les relations et les communications qui existent entre eux.
     
  4. L’architecture technique représente le déploiement de ces composants, les frameworks techniques de base, les matériels et les infrastructures réseaux.

  

En ce qui concerne l’ADM, la phase B est consacrée au métier, la phase C aux données et à l’applicatif et la phase D à la technique.

 

La aussi comme dans toutes les méthodes, on va trouver un référentiel d’architecture afin de stocker, communiquer et capitaliser ces informations stratégiques pour l’organisation et qui va faciliter l’aide aux décisions.

 

TOGAF n’échappe pas à la règles des méthodes en distinguant « architecture » (ABB Architecture Building Block) et « solution » (Solution Building Block). 

 

 

N’oublions pas les exigences et les contraintes !

 

L'OMG (Object Management Group) a défini une norme de modélisation sur les aspects stratégie, objectifs métiers, buts, nommée BMM (Business Motivation Model), voici les principaux articles que j'y avais consacré dans la catégorie  BMM  du site :

 

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

TOGAF défini des concepts permettant de formaliser les résultats escomptés :

 

  • Les objectifs stratégiques, buts, grandes orientations  
     
  • Les objectifs opérationnels transforment les objectifs stratégiques ou résultats mesurables
     
  • Les pilotes (drivers) concernent des changements conjoncturels et la nécessité de s’adapteraux innovations technologiques.
     
  • Les spécifications qui vont être réalisées pour parvenir à ces objectifs.
     
  • Les contraintes externes qui vont réduire les objectifs. Par exemple une nouvelle loi, impose des règles que l’on doit intégrer et qui peuvent impacter les objectifs de l’organisation.

 

L’architecture d’entreprise met en œuvre la traçabilité entre les buts fixés et les composants du système ce qui permet de toujours vérifier l’adéquation entre les besoins métiers et l’architecture.

 

 

Et l’humain dans tout ça ?

 

TOGAF propose d’identifier chaque partie prenante grâce à une série de questions ( qui gère les ressources, qui décide de la stratégie, qui met en place le processus de transformation, …).

 

TOGAF gère la conduite du changement en identifiant les risques de résistance aux changements et pouvoir définir les actions à entreprendre pour les circonscrire.

 

Pour communiquer avec les différentes parties prenantes, TOGAF met en œuvre les points de vue qui sont des représentations du système adaptées à ce que recherche l’interlocuteur, à son niveau.

Par exemple, la direction générale s’intéresse à des descriptions globales et transverses et ne veut pas rentrer dans le détail.

 

 

Qui est le patron ?

 

La direction fixe les objectifs stratégiques qui se traduisent en décision relevant de l’architecture et notamment dans l’évolution du système d’information.

 

Les objectifs stratégiques ou les exigences métiers sont formalisées dans la partie « Architecture Métier » de TOGAF ce qui permet de tracer des liens entre ces éléments et les autres composants du système.

 

Cette traçabilité permet une compréhension commune des concepts métiers à tous les acteurs et précise leurs rôles au sein de l’entreprise.
Elle permet de mesurer les impacts lorsqu'il y aura une évolution pour s’adapter aux besoins futurs.

 

Des forces parasites font que le système a tendance à s’éloigner de la trajectoire ou à ne plus respecter les règles établies.

Pour éviter cela, une organisation centralisée, basée sur une gouvernance transverse doit prendre en charge l’architecture de l’entreprise, ses choix stratégiques, ses principes et son plan d’action.

Cette gouvernance se présente sous forme d’un comité d’architecture qui a un rôle de contrôle et de de pilotage.

 

TOGAF possède un catalogue de principe d’architecture comme :

  • Le système doit être indépendant des plates-formes techniques
  • La continuité de services
  • La qualité des données
  • Les applications doivent être harmonisées
  • Les utilisateurs doivent être impliqués dans les choix d’architecture
  • L’utilisabilité des applications

 

Vous voilà maintenant pleinement rentré dans le monde TOGAF. 

Les prochains articles seront consacrés à :

  • expliquer la méthode ADM,
  • décrire le métamodèle TOGAF,
  • donner les bonnes techniques de modélisation,
  • conseiller sur les outils à utiliser,
  • formaliser les modèles à utiliser pour les différentes phases ADM,
  • ...

bref une série qui s'annonce passionnante.  

 

Rhona Maxwel

@rhona_helena

 

"Exister consiste à changer, changer à se mûrir, se mûrir à se créer indéfiniment soi-même."

Henri Bergson

 

 

Articles conseillés :

 

Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ? 
 

La méthode top-down dans l'urbanisme du Sytème d'Information
 

Objectifs des indicateurs du processus d'urbanisation du Système d'Information

 

On remet une couche sur le cadre d'urbanisation SI ?
 

Urbanisation SI : comment marche le méta-modèle ?
 

Libérez-vous, laissez votre stratégie prendre le leadership"
 

En cas d'évènements imprévus, votre SI doit savoir jouer les "Transformers" !
 

Avec un peu de métier, métamodéliser la vue métier pour assurer la traçabilité avec la stratégie
 

En urbanisation SI, comment définit-on la vue fonctionnelle et quels sont les liens avec la vue métier et applicative ?
 

En urbanisation SI, comment met on en oeuvre la traçabilité entre la vue applicative et les vues fonctionnelle et infrastructure ?


20/10/2017
0 Poster un commentaire

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

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

Parmi les principaux éléments de BMM, il nous en reste quatre à voir, regroupés sous la catégorie générique de « Placeholders »  : l’actif de l’entreprise (Asset), les unités organisationnelles (Organization Unit), les processus métiers (Business Process) et les règles métiers (Business Rule).

 

Les concepts saillants de BMM ont été abordés dans les articles suivants :  

 

  1. BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
     
  2. BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, ...
     
  3. Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
     
  4. Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
     

Les processus métier et les règles métiers ont leur propre norme OMG, nous y avons consacré de nombreux articles et ils ont même leur propre catégorie.

BPMN Business Process Modeling Notation est la norme de modélisation des processus métier.

( voir la catégorie de notre blog :

BPMN 

et l'article

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

  

DMN Decision Model and Notation est celle pour les règles métier.

( voir la catégorie de notre blog :

DMN 

l'article

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

et

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

 

BMM utilise aussi la norme sur le vocabulaire anglais concernant la sémantique des processus et règles métiers, SBVR Semantic Business Vocabulary and Business Rule.

 

Unité organisationnelle (Organization Unit)

 

tutorial-BMM-Business-Motivation-Model-norme-OMG-unite-organisationnelle_16.png

 

 

Processus métier (Business Process)

 

tutorial-BMM-Business-Motivation-Model-norme-OMG-processus-metier_17.png

 

L’actif d’entreprise

 

tutorial-BMM-Business-Motivation-Model-norme-OMG-actif-entreprise_18.png

 

L’actif d’entreprise (Asset) et ses relations (Liability)

 

Une fois les façons de procéder définies, il y a 2 choses à considérer dans le fonctionnement d’une l'entreprise et qui sont représentées dans BMM comme des actifs de deux types :

  • des immobilisations, c’est-à-dire des entités qui sont conservées à long terme, maintenues, réutilisées et remplacées. Par exemple des choses tangibles comme des équipements et des constructions (bâtiments) ou intangibles, comme des brevets et des licences.
  • des ressources, c’est-à-dire des entités qui sont consommées, approvisionnées de nouveau, comme des matières premières, des produits finis et de l’argent.

 

tutorial-BMM-Business-Motivation-Model-norme-OMG-actif-entreprise-liens_19.png

 

Rhona Maxwel

@rhona_helena

 

"A celui qui ne sait pas vers quel port il navigue, nul vent n’est jamais favorable."

Sénèque

 

 

Articles conseillés :

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 3ème partie - Processus métiers - BPMN

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 5ème partie - Règles métier- UML - Profil spécifique

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 6ème partie - Rule Flow – UML – Diag. Activité

 

Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 7ème partie - Domaine métier – UML – Diag. Classe


18/07/2017
0 Poster un commentaire