Acceleo est un générateur de code de dernière génération. Il est basé sur l'approche MDA permettant notamment une réelle séparation entre le fonctionnel des applications et l'architecture technique cible, grâce à l'utilisation de modèles de haut niveau.

Acceleo permet d'automatiser les tâches répétitives en générant la majeure partie de l'infrastructure technique.

Acceleo se différencie par les points suivants :

• Licence OpenSource GPL
• Syntaxe à base de templates hautement paramétrables
• Support des standards de modélisation (UML, EMF, XMI, MOF)
• Gestion du développement itératif et du travail en équipe
• Intégration forte dans Eclipse
• Rapidité de mise en place

Il est possible de completer ce ytres bref descriptif via le lien suivant : http://www.acceleo.org

Ci-dessous la réponse de Pierre Bonet à une question que j'ai posté sur le site http://www.orchestranetworks.com/fr.

Bonne lecture.

Question

Bonjour,

Merci de mettre votre expertise au service des questions posées par les visiteurs du site. Ma question est rapide, mais je doute bien que la réponse soit pas de même.

Comment peut-on concrètement aligner MDA sur SOA ou vice versa?

Merci de votre réponse et bonne journée.

Réponse
C’est une question d’actualité. Je travaille depuis plusieurs mois sur un projet de grande ampleur qui met en place une stratégie SOA + MDA.

Nous pensons qu’il faut distinguer le MDA de la couche SOA métier (profiles XSD, WSDL et BPEL) et le MDA de la couche SOA de l’architecture applicative (par exemple profiles Pojo, EJB, Mapping Hibernate, Pattern State Machine…).

L’alignement dont vous parlez s’opère donc selon ces deux couches. Pour le SOA métier, il faut bien noter que l’implémentation des profiles XML restent encore peu matures ; il faut souvent assurer un développement spécifique des générateurs et accepter l’usage de profiles non standards (stéréotypes, tagged values). Malheureusement, l’OMG ne propose pas encore de profiles sur cette couche, sans doute à venir sur 2006. Attention, l’aspect génération XML pour les règles de type pré- et post-conditions à partir, par exemple, d’une représentation formelle en OCL dans les modèles UML n’est pas possible, à ma connaissance et malheureusement, aujourd’hui, sauf en laboratoire.

Pour le SOA de l’architecture applicative, il existe des profiles UML standards publiés par l’OMG (Corba, Ejb, Test…) et d’autres assez répandus sur le marché (pattern State machine, Factory…).

Il ne faut pas négliger le profile UML pour la génération du MLD et MPD à partir d’un modèle de classe du niveau conceptuel.

Sur la partie IHM, on trouve aussi des profiles UML pour Struts (le framework MVC en Java) par exemple.

Au-delà de la génération de code dont je viens de parler, le MDA concerne aussi la génération automatique de la documentation ou plus précisément le packaging de la documentation. Par exemple, le pseudo-code est positionné directement dans les modèles puis repris dans les documentations générées. Du côté ingénierie, on peut envisager de remonter le code source logiciel dans les modèles selon un mécanisme de type round-trip ou assimilé. Mais ce mécanisme est loin d’être évident à grande échelle… De même, l’idée d’une génération automatique de code Java pour le corps des méthodes reste encore théorique. Au mieux, on peut trouver des générateurs pour les assertions OCL, utilisées comme pré- et post-conditions des services.

Sur ces points et d’autres il y a beaucoup de sujets à détailler et je manque d’espace pour les présenter ici ; j’ai écris il y a quelques mois une contribution sur le thème Offshore + MDA + SOA qui apporte des compléments. Je vous invite à le consulter en téléchargement libre sur notre site : http://www.orchestranetworks.com/fr/soa/extraitoffshore.cfm

Vous pouvez aussi rester attentif aux publications sur notre site. Nous allons proposer en téléchargement libre, début Septembre, un document complet de synthèse de nos meilleures pratiques SOA et Web services qui détaille l’architecture logique SOA que nous préconisons. C’est une base de départ qui peut être utile pour contribuer à la mise en place d’une stratégie MDA.

Espérant contribuer à vos réflexions et merci pour votre question ouverte.

Pierre Bonnet

SOA propose de résoudre le problème de l’interopérabilité en introduisant des services distribués et faiblement couplés et qui communiquent via des messages standards. Ces services peuvent être orchestrés ou chorégraphiés afin de construire un processus. SOA propose aussi une infrastructure QoS ainsi qu’un environnement ESB. La démarche SOA est une démarche plutôt technique. Schématiquement, des interfaces de service (WSDL) sont orchestrées en des processus métier (BPEL), se basant sur une architecture et protocoles sécurisés, fiables et transactionnels (WS-*) transportés par des protocoles standards (http/SOAP).

MDA est une approche pour la modélisation du système et du métier qui relie de manière explicite plusieurs perspectives en un modèle unifié. Chaque perspective fait appel à une compétence ou un rôle spécifique. Les perspectives sont des perspectives business indépendantes de toutes plates-formes ou technologies (PIM).

SOA est basée sur des bonnes pratiques en terme d’architecture et suscite un engouement dans la communauté informatique. Cet engouement s’explique avec les outils, les articles et l’émergence de cette architecture ainsi que les technologies qui sont susceptibles d’adhérer à ses principes. MDA est le résultat d’un effort très réussi de la part d’organismes pour unifier, interopérer la modélisation et proposer une méthodologie efficace concernant la génération de code pour des plates-formes techniques spécifiques.

MDA est basée sur le concept qui stipule que tout processus peut être définit en tant que modèle ou même plus : un méta-modèle qui peut être transformé en un composant applicatif. MDA permet aussi de définir la notion de sous-modèle, comme pour SOA, un processus contient des sous-processus ou services.

SOA définit un paradigme d’architecture pour interconnecter des systèmes à un niveau macro, elle ne spécifie pas de démarche pour le passage de l’architecture au code. MDA permet de suivre n’importe quel paradigme d’architecture et définir une démarche pour le passage au code.

L’implémentation de SOA ne dépend d’une seule technologie. Chaque entreprise spécifie ses outils techniques, frameworks, serveurs applications pour implémenter cette dernière. SOA a eu un essor significatif après le tremplin des technologies WS-*. D’autres technologies risquent de voir le jour dans les années à venir. Les applications générées à partir de MDA sont supposées résister au changement et à l’évolution des technologies, par le biais de la génération du PSM.

L’implémentation de SOA ne dépend d’une seule technologie. Chaque entreprise spécifie ses outils techniques, frameworks, serveurs applications pour implémenter cette dernière. SOA a eu un essor significatif après le tremplin des technologies WS-*. D’autres technologies risquent de voir le jour dans les années à venir. Les applications générées à partir de MDA sont supposées résister au changement et à l’évolution des technologies, par le biais de la génération du PSM.

Les fonctionnalités offertes par la démarche MDA permettent de catégoriser les outils MDA comme suit :

• Editeur de Définition de Transformation
• Editeur de Modèle
• Outil de Transformation
• Générateur de Code
• Référentiel de Définition de Transformation
• Validateur de Modèle
• Référentiel de Modèle Base de données
• Référentiel de Code
• Editeur de Code intégré

Ci-dessous une liste d'outils Open Source qui suivent ou peuvent être utilisés pour adhérer à la démarche MDA :

Ci-dessous une liste d'outils commerciaux:

• ArcStyler
• MCC
• Codagen Architect
• OptimalJ
• Xactium XMF Mosiac
• SosyInc
• Model-in-Action

L'architecture MDA

Le but de l’approche MDA est de diriger le développement à partir de la modélisation. La réalisation ne devient pas code-centric mais plutôt model-centric. MDA permet de réaliser des applications à partir de modèle de conception en se basant sur les concepts d’abstraction, d’automatisation de génération et d’indépendance des plates-formes. Elle promet donc une flexibilité en terme de d’implémentation, d’intégration, de maintenance, de tests et de simulation.

MDA fournit l’approche de spécification du système en terme de modèle. Les besoins du système (requirements) sont spécifiés au niveau du CIM indépendamment de la plate-forme. PIM est le modèle qui décrit le design système indépendamment de la plate-forme. PSM décrit le design du système dépendamment de la plate-forme qui va le supporter.

Dans l’approche MDA, les modèles sont transférés d’une forme à une autre. Tout d’abord, les besoins via CIM qui sont convertis en modèles PIM qui décrit le système sans les détails relatifs à la plate-forme qui hébergera l’application, le PIM est ensuite transformé en PSM. Les modèles PSM sont ensuite utilisés pour la génération automatique du code en fonction de la plate-forme choisie. La transformation d’un niveau à un autre est faite de manière automatisée

L’architecture de MDA se définit en quatre couches principales. Chacune des couches adopte un standard reconnu et mature.

Le noyau de MDA repose sur les formalismes et les spécifications : UML, MOF, CWM gérées par l’OMG, ces formalismes permettent de modéliser la logique métier applicative.

Ce modèle métier est ensuite traduit via une technologie middleware comme les EJBs, Services Web, Corba.

Ensuite, sont représentes les services, ces services peuvent être des services de persistance, de transactions ou d’événements etc…

La dernière couche se base sur les profiles UML qui permet donc de proposer des frameworks spécifiques en fonction du domaine applicatif (domaine bancaire, Spatial, télécommunications)

Introduction

MDA n’est pas une architecture récemment initiée, elle est un fruit d’une mure réflexion de la part d’architectes et d’organismes compétents.

MDA est une démarche qui permet de :

ü Fournir des modèles indépendants de toute plate-forme (PIM)

ü Établir la correspondance entre le PIM et une plate-forme spécifique (PSM)

Plusieurs concepts sont impliqués dans les spécifications MDA

ü UML 2.0 et OCL pour la modélisation

ü MOF pour la modélisation des méta-données (échanges entre systèmes)

ü CORBA et profiles UML pour les transformations

ü XMI pour l’échange de modèles UML

Essayons de voir les raisons pour les quelles cette architecture a vu le jour et les raisons pour lesquelles aussi elle fait partie des bonnes pratiques et devenu assez prisée pour les développement des applications entreprise.

Beaucoup de domaines ont révolutionné le monde informatique essentiellement pour le développement d’applications entreprise. Ces domaines ont subi des changements et renouveaux qui sont coûteux en terme d’adoption et de mise en œuvre.

Ces domaines sont les suivants :

ü Les langages : Les premières générations des langages de programmation étaient celles des langages procéduraux et fonctionnels comme le langage C ou Cobol. Le souci de reutilisabilité et de productivité a donné naissances aux langages orienté objet comme SmallTalk ou Java. L’émergence d’Internet a nécessite la définition de langages permettant de manipuler des composants distants via les réseaux comme DCOM ou CORBA. La nouvelle génération des langages est portée sur les services WEB d’où SOAP, UDDI et de nombreux formalismes compliqués. Plusieurs applications entreprise reposent sur plusieurs langages et nécessitent dans des cas des migrations de langage. L’effort de refonte basée sur le langage est très fastidieux.

ü Les midllewares : CORBA était le middlleware le plus performant et le plus indépendant des plate-forme, mais il a l’inconvénient d’être compliqué à mettre en œuvre. J2EE est venue avec sa couche EJB puis .NET avec sa couche Services WEB. J2EE à suivi l’exemple après. Quel middleware choisir ?

ü Les méthodes : Avec l’avènement des langages orientés objet, UML a été proposer afin d’unifier et de standardiser la syntaxe de représentation des concepts de conception et de modélisation. UML souffrait du manque d’un processus de mise au point, de son ininteropérabilité entre les différents éditeurs UML et de sa difficulté d’industrialisation et de génération de code pour différents langages. La version officielle courante de UML est la 2.0.

Le but de ce chapitre est de définir l’intérêt d’utiliser l’architecture ou le modèle ou la démarche MDA dans l’adoption de l’Architecture Orientée Services.