Définitions

2.1.1. MDA (Model Driven Architecture)

Suite aux évolutions permanentes subies par les architectures middleware, les langages de programmation et les méthodes de génie logiciel, en novembre 2000, l‘OMG rend public l‘architecture MDA basée sur une utilisation intensive de l‘UML (Unified Modeling Language) pour séparer les spécifications fonctionnelles d‘un système des spécifications de son implémentation. L‘OMG place la modélisation au centre du processus de développement (Figure 11) en découplant la logique métier, la logique applicative et le code. Dans MDA, la partie

Mohieddine MISSAOUI Page 87 centrale est de construire un PIM représentant le modèle métier en utilisant les technologies UML, MOF et CWM (Common Warehouse Meta-Model). La deuxième étape consiste à transformer le PIM en PSM qui représente un modèle comprenant des parties techniques propres à la plateforme cible basée sur les technologies telles que EJB (Entreprise Java Beans), CORBA (Common Object Request Broker Architecture), .NET, XMI (XML Metadata Interchange) ou encore les web services. La dernière étape consiste à générer du code applicatif à partir du PSM pour une plate-forme spécifique au domaine d‘application du logiciel.

Figure 11: L’architecture MDA.

Plusieurs outils proposent effectivement la transformation suivant les standards MDA des PIM en PSM. Aujourd‘hui, il est concevable de s‘appuyer sur cette architecture pour concevoir des applications WEB, des systèmes embarqués ou encore des systèmes d‘information entiers. Parmi les outils proposés on trouve : OptimalJ (plate-forme J2EE) de CompuWare1 qui est proposée dorénavant sous forme plus exhaustive au niveau des langages de programmation cible avec ACCELEO2 (Figure 12), ATLAS Transformation Language3, MODEL-IN-ACTION de Mia Software4, ANDROMDA5, OpenMDX6 [plates-formes J2EE et .NET], MDE Eclipse7, Blueprint ME de @PORTUNITY8 ou encore Visual Studio (VS) de Microsoft avec son Entity Designer intégré à l‘IDE de VS pour le développement d‘applications .NET Entreprise.

————————— 1http://www.compuware.fr 2http://www.acceleo.org 3http://www.sciences.univ-nantes.fr/lina/atl/ 4http://www.mia-software.com 5http://www.andromda.org 6http://www.openmdx.org 7http://sourceforge.net/projects/mde 8http://www.atportunity.com

Mohieddine MISSAOUI Page 88 Figure 12: Exemple d’implémentation de l’architecture MDA. Extrait du site internet d’ACCELEO.

(Source : http://www.acceleo.org)

Bien que l‘architecture MDA soit suffisamment bien définie dans le cadre du génie logiciel pour répondre à la problématique d‘abstraction et aux notions fondamentales de modèle, de méta-modèle, de transformation et de plate-forme, il est difficile de définir de manière précise et sans ambigüité la notion de plate-forme par exemple qui tend à disparaitre au profit des notions de modèle et de méta-modèle (Favre et al., 2006). La relation entre ces notions est loin d‘être définitivement caractérisée et l‘ingénierie dirigée par les modèles s‘inscrit dans cette logique évolutive pour proposer des concepts unificateurs basés sur les modèles afin de généraliser et d‘intégrer tout type de modèle.

2.1.2. Modèle, Méta-modèle et Système

Dans les années 80, le principe fondamental sur lequel ont été basées toutes les approches technologiques était « Everything is an object ». Depuis, le principe est transformé pour que le système ne soit plus un objet du point de vue abstraction, mais plutôt un modèle avec le nouveau principe « Everything is a model » (Bézivin, 2004). C‘est la preuve que les notions ont largement évolué pour permettre de modéliser non plus les composants logiciels uniquement mais aussi les différentes étapes de la création d‘un outil.

Paradoxalement, il n‘existe pas de définition universelle pour le terme « Modèle » d‘après Jean–Marie Favre. Néanmoins, plusieurs définitions apparues dans la littérature peuvent donner un aperçu de ce qu‘est un modèle. En effet, un modèle peut désigner « l’abstraction d’un système construit dans une intention particulière pour un rôle bien défini par rapport à un autre système » ou « un ensemble de faits sur un système considéré » ou « une description (d’une partie) d’un système dans un langage bien

Mohieddine MISSAOUI Page 89 défini » ou encore « un modèle doit répondre aux questions à la place du système réel ». Pour définir les relations entre modèles (représentations abstraites des systèmes), il est nécessaire d‘utiliser les notions d‘inclusion, d‘appartenance et de représentation ou d‘interprétation.

Un méta-modèle quant à lui est défini comme étant « un modèle qui définit le langage pour exprimer un modèle » ou aussi « un modèle de spécification d’une classe de systèmes où chaque système de la classe est lui-même un modèle valide exprimé dans un certain langage de modélisation ». Les notions de langage et de méta-modèle sont souvent confondues mais concrètement, un méta-modèle est finalement un moyen de définir un langage.

Un système du point de vue de l‘IDM est tout élément du discours. C'est donc ce qui fait l‘objet de la modélisation réalisée par un modèle. Mais tout système peut jouer le rôle d‘un modèle par rapport à un autre système. En conclusion, l‘IDM est basée en partie sur ces trois notions fondamentales tirées de l‘architecture MDA de l‘OMG et sont parfois difficiles à assimiler (Favre et al., 2006).

2.1.3. Transformation de modèles

Pour rejoindre les définitions précédentes, un modèle est vu comme une interprétation du monde réel. L‘une des notions les plus importantes introduite par l‘OMG pour définir la fonction qui permet de passer d‘un modèle à un autre est la transformation de modèles. Dans le cadre de l‘IDM, on parle de modèle de transformation pour désigner un programme, exécutable ou non, permettant de réaliser une conversion du système source en un système cible. L‘objectif est de proposer une automatisation de telles fonctions dans l‘approche de l‘ingénierie dirigée par les modèles. Dans un processus de transformation basée sur l‘IDM, les règles de transformations sont décrites dans les spécifications (Figure 13).

Figure 13: Approche de transformation d’un modèle basée sur la liaison entre les types du modèle source (PIM) et les types du modèle cible spécifié par l’OMG.

Mohieddine MISSAOUI Page 90 En cas de besoin, le modèle cible est créé en se basant sur le modèle source. La complexité de cette tâche a même été simplifiée en ajoutant un nouveau concept : le méga-modèle qui vise à modéliser l‘évolution des logiciels à travers les transformations (Favre et Nguyen, 2005) dans le cadre de la MDE. D‘après (Sendall et Kosaczynski, 2003), un langage de transformation de modèle doit:

 Etre exécutable,

 Etre implémenté efficacement,

 Etre totalement expressif et sans ambigüité pour les transformations de modèles existants ou pour la création de nouveaux modèles,

 Faciliter la productivité du développeur avec précision, concision et clarté,

 Fournir un moyen de combiner des transformations pour former des composites, une sélection conditionnelle et une répétition des transformations,

 Fournir un moyen de définir les conditions de l‘exécution des transformations.

Certaines transformations ne sont pas automatisables et dans ce cas là elles ne sont pas intéressantes pour une approche par IDM, comme par exemple la correction de bogues dans des programmes informatiques. A titre d‘exemples, on peut citer SmartQVT (http://smartqvt.elibel.tm.fr/) qui est une implémentation JAVA du langage QVT des spécifications MOF 2.0, le projet M2M (Model-2-Model) de Eclipse qui vise à proposer une infrastructure composée de 3 moteurs de transformations [ATL (Atlas Transformation Language), QVT procédural et QVT déclaratif (tous deux basés sur MOF 2.0)], ou encore le projet Kermata de Triskell (www.kermata.org) basé sur une extension de la MOF qui s‘inspire du MTL (Model Transformation Language ) et du OCL (Object Constraint language). On peut également citer XAL (Xion Action Language) (Heitz et al., 2007) basé sur les diagrammes d‘activités UML et XMLTL (XML Transformation Language) qui permet de transformer un document XML en une sortie XML. Plusieurs implémentations sont disponibles [XSLT (eXtensible Stylesheet Language Transformation), WQuery, STX, XML Script, FXT (Functional XML Transformation), XDuce, XStream…). Enfin citons VIATRA (Visual Automated Model Transformation) un environnement de vérification et de validation basé sur la transformation de modèles implémenté en UML et permettant d‘accroitre la qualité des systèmes en vérifiant de manière automatique la consistance, la complétude et la dépendance des spécifications d‘un système.

Mohieddine MISSAOUI Page 91

2.1.4. Méta-modélisation et méta-programmation

La méta-modélisation dans une approche IDM est la définition d‘un méta-modèle qui décrit une famille de modèles. L‘OMG a standardisé l‘approche à l‘aide de la MOF pour fournir un outil générique permettant de manipuler ces concepts. L‘approche comprend 4 niveaux d‘abstraction (Figure 14):

Le niveau M0: il définit le système réel en lui-même.

Le niveau M1: il définit le modèle du système dans un certain langage. Le niveau M2: il définit le méta-modèle qui décrit ce langage.

Le niveau M3: il définit le méta-méta-modèle qui décrit le méta-modèle (couche auto descriptive).

Figure 14: Les niveaux d’abstraction selon la MOF du MDA.

A l‘aide de cette approche à 4 couches, tout modèle peut être décrit par une syntaxe, une sémantique, et des règles selon la MOF, même les modèles de transformation.

De façon analogue à la méta-modélisation, on peut définir la méta-programmation comme étant la méta-modélisation de programmes informatiques. Cependant, il ne faut pas confondre IDM et méta-programmation même si les deux partagent quelques concepts: les programmes sont des modèles (ex. classe JAVA) sur lesquels on peut effectuer des opérations de transformation (ex. méthodes) de manière automatique (ex. un calcul particulier) et ayant plusieurs représentations possibles (ex. C++, C#...). Cette analogie est simpliste (Tableau 8) mais permet de formaliser les concepts de l‘IDM de manière concrète (Batory, 2006). Si on prend

Mohieddine MISSAOUI Page 92 l‘exemple d‘un MAKEFILE, il est évident qu‘il s‘agit d‘un méta-modèle (méta-programme, par analogie à l‘IDM) permettant de générer un modèle (respectivement un programme). L‘idée de base dans l‘ingénierie dirigée par les modèles dans ce cadre est la capacité à créer des langages personnalisés pour un domaine d‘application particulier et de définir leurs spécifications. Les méta-modèles sont alors la pièce maîtresse de la définition même des DSL (Domain Specific Language) tirés de l‘IDM. On peut étendre cette analogie aux bases de données pour se rendre compte que les notions de l‘IDM ne sont rien d‘autres que des représentations de concepts familiers.

Tableau 8: Correspondances entre les terminologies MDE, les bases de données et les langages Orienté Objet d’après (Batory, 2006).

MDE Bases de données Programmation Méta-méta-modèle Schéma d‘information Méta-classe

Méta-modèle Schéma Classe

Modèle Base de données Objet

Transformation Transaction Méthode

Par analogie cette fois à la programmation, la synthèse d‘une application à partir de son modèle par génération de code est un processus à 2 étapes qui commence par une transformation du modèle en langage de programmation de haut niveau (C, C++, JAVA,…) et se termine par la compilation de ce programme en binaires exécutables qui réalise l‘application par l‘utilisation d‘un compilateur support du langage ciblé lors de la première étape (Favre et al., 2006). La génération de code peut être comprise comme un ensemble de règles de transformation de modèles et peut être optimisée pour une plate-forme donnée. Les patrons de conception (les design patterns) peuvent alors implémenter ces règles.

Enfin, dans une démarche MDE, la génération de code semble adaptée car elle offre une flexibilité face à l‘évolution permanente des standards des langages de modélisation et face à la diversité des plates-formes et des systèmes. Seule nuance, reste la gestion des corrections (débogage) qui n‘est pas une tâche triviale et se fait généralement au niveau du code généré et non pas au niveau du modèle. Une solution envisageable est celle d‘un interpréteur de modèle qui puisse anticiper les erreurs à partir du modèle.

Mohieddine MISSAOUI Page 93 Plusieurs outils permettant la génération de code automatisée sont disponibles: GreenBox1

pour les plates-formes JAVA, ALTOVA2 basé sur des modèles décrits en XML ou en UML, Codus3 permettant la génération de code pour la mise à jour des bases de données et bien d‘autres outils4.