L’architecture dirigée par les modèles ou MDA (pour l'anglais model driven architecture) est une démarche de réalisation de logiciels, proposée et soutenue par l'OMG. C'est une variante particulière de l'ingénierie dirigée par les modèles (IDM, ou MDE pour l'anglais model driven engineering). D'autres variantes de l'IDM ont été développées, par exemple par Microsoft avec DSL Tools.
Introduction
Le principe de base du MDA est l'élaboration de différents modèles, en partant d'un modèle métier indépendant de l'informatisation (computation independent model, CIM), la transformation de celui-ci en modèle indépendant de la plate-forme (platform independent model, PIM) et enfin la transformation de ce dernier en modèle spécifique à la plate-forme cible (platform specific model, PSM) pour l'implémentation concrète du système. Les PSMs peuvent utiliser des langages spécifiques à un domaine ou des langages généralistes comme Java, C#, Python… Les techniques employées dans le cadre de l'approche MDA sont donc principalement des techniques de modélisation et des techniques de transformation de modèles.
L'OMG fournit des spécifications des standards plutôt que des implémentations, le plus souvent après avoir reçu une demande de proposition (Request for Proposals). Les implémentations sont ensuite le fruit du travail d'entreprises privées ou de groupes open source.
Standards liés au MDA
L'approche MDA est liée à de nombreux standards tels que :
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.
Marques déposées
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.
le standard UML, et l'outil de modélisation qui l'implante (ex. : Rose, Enterprise Architect, Together, MagicDraw, RSA, Dia) ;
des templates de génération UML→code source, et l'outil de génération de code qui s'appuie dessus (ex MIA-Studio) ;
le tout intégré dans une « chaîne » de production.
Il n'est bien sûr pas requis que la totalité du code soit générée automatiquement, mais l'architecture globale du système (ex: squelettes de code) au moins doit être obtenue ainsi.
Les transformations entre le CIM, le PIM et les PSM sont souvent automatisées à l'aide d'outils plus ou moins compatibles avec QVT, le standard de l'OMG pour les transformations de modèles.
Le passage du PSM à la génération du code est la suite logique de ce traitement. Elle peut être réalisée par des générateurs tels que ceux-ci afin de produire tout type de cibles technologiques.
Domaine du MDA
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].
Outillage MDA
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.
Implémentations des spécifications de l'OMG par 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.
Problèmes du MDA
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.
