Model driven architecture

L'approche MDA est liée à de nombreux standards tels que :

• CWM (Common Warehouse Metamodel) ;
• EDOC (Enterprise Distributed Object Computing) ;
• MOF (Meta-Object Facility) ;
• MOFM2T (MOF Model-to-Text language) ;
• QVT ;
• SPEM (Software Process Engineering Metamodel) ;
• UML (Unified Modeling Language) ;
• XMI (XML Metadata Interchange).

Il est à noter que le terme architecture dans MDA ne fait pas référence à l'architecture du système modélisé mais plutôt à l'architecture des différents standards qui forment la base technologique du MDA.

L'OMG possède l'ensemble des marques relatives au MDA ainsi que de nombreux termes similaires tels que :

• MDD (model driven development, développement piloté par les modèles) ;
• MDAD (model driven application development, développement d'application piloté par les modèles) ;
• MBAD (model based application development, développement d'application fondé sur les modèles) ;
• MBP (model based programming, programmation fondée sur les modèles).

Le sigle principal n'ayant pas encore été déposé par l'OMG est MDE (Model Driven Engineering, « ingénierie pilotée par les modèles »). En conséquence, la communauté scientifique fait souvent référence au MDE pour exprimer des idées d'ingénierie des modèles sans se restreindre aux concepts de MDA détaillés dans les standards de l'OMG.

L'OMG se focalise sur l'architecture pilotée par les modèles pour "l'ingénierie vers l'avant", c'est-à-dire produire du code à partir de source de données telles que des diagrammes ou des modèles. Le groupe d'analyse et de design de l'OMG (Analysis and Design Task Force, ADTF) dirige cet effort. Ce même groupe a choisi le terme ADM (MDA à l'envers) pour décrire l'étude de la rétro-ingénierie.

L'ADM décrit la modernisation de logiciel piloté par l'architecture (ici les standards de modélisation de l'OMG). L'objectif de l'ADM est de produire des standards pour la modernisation de vieux programmes informatiques grâce à des méthodes de rétro-ingénierie fondées sur les modèles. Le méta-modèle de découverte de connaissances (Knowledge Discovery Metamodel, KDM) est l'un de ces standards. KDM décrit ainsi les systèmes d'informations en tant que différentes données (programmes, spécifications, données, fichiers de tests, schéma de base de données, etc.).

L'un des objectifs principaux du MDA est de séparer le design de l'architecture. Comme les concepts et les technologies utilisés pour réaliser le design et les concepts et technologies utilisés pour créer les architectures des programmes ont évolué à leur rythme, découpler le design de l'architecture permet aux développeurs de choisir les concepts et les technologies les plus intéressantes dans chaque domaine. Le design se focalise sur les problèmes fonctionnels là où l'architecture donne l'infrastructure sur laquelle les besoins non fonctionnels seront réalisés, tels que la montée en charge du système, sa robustesse, et ses performances.

Le MDA considère que les modèles indépendants d'une plateforme (PIM) qui représentent le design en décrivant les besoins fonctionnels du système peuvent s'adapter aux différents changements dans la réalisation des architectures logicielles. Il existe des notions importantes dans le MDA comme la notion de transformation de modèles et la notion de génération de code. Ainsi pour la transformation de modèle, un langage standard a été spécifiquement créé par l'OMG, le langage QVT. Pour la transformation de modèles vers du texte (génération de code ou de documentation), l'OMG a ainsi créé le langage MOFM2T. Les travaux actuels autour du MDA tendent à renforcer les prérogatives des modèles et des métamodèles, avec l'utilisation de métadonnées[1].

L'OMG fournit des spécifications plutôt que des implémentations en réponse à des demandes de propositions. L'OMG documente ce processus dans un document nommé le Guide MDA.

De manière simple, un outil MDA est un outil utilisé pour développer, interpréter, comparer, aligner, mesurer, vérifier, transformer, etc. des modèles ou des métamodèles. Dans la section suivante, le terme modèle sera utilisé pour désigner n'importe quel type de modèle (exemple : un modèle UML) ou de méta-modèle (exemple : le méta-modèle CWM). Dans n'importe quel type d'approche MDA, il existe essentiellement deux types de modèles :

• Les modèles initiaux créés par des personnes ;
• Les modèles dérivés créés automatiquement par des programmes.

Par exemple, un analyste peut créer un modèle UML, résultat de ses observations d'un système métier là où un modèle Java peut être dérivé de ce modèle UML par une transformation de modèle. Un outil MDA est un outil d'au moins un des types suivants :

Outil de création

un outil permettant de créer un modèle initial et/ou d'éditer des modèles dérivés ;

Outil d'analyse

un outil permettant de vérifier la complétude, les inconsistances, ou les erreurs d'un modèle. Ce type d'outil peut aussi calculer différentes métriques sur le modèle ;

Outil de transformation

un outil utilisé pour transformer des modèles en d'autres types de modèles, ou en texte (code source ou documentation) ;

Outil de composition

un outil permettant de composer (fusionner conformément à une sémantique de composition) plusieurs modèles, de préférence correspondant à un même méta-modèle ;

Outil de test

un outil permettant de définir des tests sur le modèle, comme cela est décrit par l'approche de test fondée sur les modèles (Model-based Testing) ;

Outil de simulation

un outil utilisé pour simuler l'exécution d'un système représenté par un modèle donné. Ce type d'outil est lié au sujet d'exécution de modèle ;

Outil de gestion des méta-données

un outil conçu pour gérer les relations entre différents modèles, comme les métadonnées de chaque modèle (auteur, date de création ou de modification, outil de création, etc.) et les relations entre ces modèles (un modèle peut être le méta-modèle d'un autre modèle, un modèle peut être dérivé d'un autre modèle, etc.) ;

Outil de rétro-ingénierie

un outil permettant de transformer un code existant en un modèle.

De nombreux outils réalisent plus d'un seul des rôles décrits précédemment. Par exemple, un outil de création de modèle peut aussi proposer des fonctionnalités de transformation ou de tests. Il existe néanmoins des outils dédiés à une facette du MDA. Les implémentations des spécifications de l'OMG sont réalisées par des sociétés privées et des groupes open source. Une source importante d'implémentations des spécifications de l'OMG est la fondation Eclipse.

De nombreuses implantations des standards de modélisation de l'OMG peuvent être trouvées dans l'Eclipse Modeling Framework (EMF) ou le Graphical Modeling Framework (GMF). La fondation Eclipse développe aussi de nombreux outils autour du MDA dans son projet de modélisation, par exemple :

• Transformation de modèles vers d'autres modèles (M2M) : ATL, Procedural QVT, Declarative QVT, Xtend ;
• Transformation de modèles vers du texte (M2T) : MOFMTL (implémentation : Acceleo), Jet, XPand ;
• Outils de création ou de manipulation de modèles : Papyrus et UML2, Sirius (outils de création de modèles), MoDisco (outil de rétro-ingénierie).

Cependant la conformité de certains outils de la fondation Eclipse aux spécifications de l'OMG n'est pas toujours stricte. Ainsi, la spécification de l'OMG pour le standard EMOF est présent dans Eclipse avec l'implantation Ecore qui dérive légèrement de la spécification. D'autres exemples peuvent être trouvés dans les domaines de transformations de modèles vers modèles par rapport à la norme QVT ou de modèles vers texte par rapport à la norme MOFM2T.

Il faut ne pas confondre la liste des outils MDA avec la liste des outils UML, il existe en effet bien plus d'outils MDA qui vont toucher à des méta-modèles parfois différents d'UML.

Il est aussi possible de faire la distinction entre des outils à méta-modèle fixe et les outils à méta-modèles variables. Par exemple, un éditeur UML sera souvent limité à une version du méta-modèle d'UML (exemple UML 2.1). Au contraire, certains outils ont la capacité de s'adapter à plusieurs méta-modèles voire à des méta-modèles fournis par l'utilisateur. Habituellement, les outils MDA se focalisent sur certaines spécifications d'architectures précises, bien qu'il existe aussi des outils indépendants d'une spécification particulière. Un exemple d'outil lié à une spécification particulière pourrait être un générateur de code lié à l'implantation .NET ou Java.

De nombreux concepts clés qui composent les fondations de l'approche MDA (née en 2001) ont été élucidés par la méthode Shlaer-Mellor à la fin des années 1980. En effet, un concept technologique clé de l'approche MDA, un langage d'action pour exécuter des modèles, a été apporté par des implémentations de spécifications de l'OMG en adaptant le langage d'origine de la méthode Shlaer-Mellor, le anglais : Shlaer-Mellor Action Language, qui fut modifié pour être adapté à UML.

Néanmoins à cette époque, l'approche MDA n'a pas su se faire adopter par la majorité de l'industrie informatique. Depuis la situation a évolué mais en 2006, le groupe d'analyse Gartner identifiait toujours le MDA comme "une technologie qui commençait à décoller" et le groupe Forrester Research considérait pour sa part le MDA comme "mort à l'arrivée". Certains problèmes potentiels relevés avec l'approche MDA, prônée par l'OMG, incluent :

• Des standards incomplets : l'approche MDA est constituée d'une grande variété de standards, certains doivent encore être définis et d'autres ne possèdent toujours pas d'implémentations ;
• Manque d'interopérabilité : bien que les spécifications MDA aient été conçues pour être indépendantes de toutes plateformes, certains vendeurs de technologies MDA ont montré des réticences à concevoir des outils interopérables les uns avec les autres ;
• Idéalisme : le MDA est conçu dans l'approche selon laquelle les modèles sont transformés en éléments d'implémentation (code source généré, schéma de base de données, etc.) grâce à des outils de génération, cela implique néanmoins que les changements effectués sur les éléments générés ne sont peu ou pas supportés. Cela peut se révéler problématique si les éléments générés doivent être adaptés après leur génération. Pour répondre à ces besoins certaines implémentations des spécifications de l'OMG adoptent une approche plus pragmatique avec des fonctionnalités permettant de prendre en compte ces modifications des éléments générés ;
• Niveau de connaissance : les personnes manipulant des technologies fondées sur l'approche MDA sont souvent obligées d'avoir un grand niveau de connaissance de leur domaine afin de pouvoir en modéliser les besoins fidèlement.

• UML
• QVT
• WebML

• Métamodèle
• Ingénierie dirigée par les modèles
• Data driven architecture

• UML 2 et MDE, Ingénierie des modèles avec études de cas (Franck Barbier) (ISBN 978-2-10-049526-9)
• Jean Bézivin, Ingénierie des modèles logiciels, École d'été d'Informatique 2003, CEA, EDF, INRIA.
• Xavier Blanc, MDA en action, (ISBN 2212115393).

• Modelio
• Acceleo
• ATL
• GenerateXY
• Eclipse Modeling Framework
• Mia-Studio (Mia-Software)
• SmartQVT
• Uniface (racheté par Compuware Corp en 1994).
• CodeFluent Entities

• (en) Site web de l'OMG sur le MDA