MDA(Model Driven Architecture)

Plan

Objectif :
- fournir les bonnes pratiques de modélisation afin de déterminer comment, quand, quoi et pourquoi modéliser et d’exploiter pleinement les avantages des modèles.
- mettre en valeur les qualités intrinsèques des modèles, telles que pérennité, productivité et prise en compte des plates formes d’exécution. MDA inclut la définition de plusieurs standards, notamment UML,MOF et XMI.
En pratique, on rencontre le plus souvent la MDA en définissant une application avec UML et en générant automatiquement l'exécutable lié, grâce à des générateurs Java, C# ou autre...

Un ensemble d'interfaces standards permettant de définir et modifier des meta-modèles et leurs modèles correspondants.
Le MOF est un moyen de définir la syntaxe et la sémantique d'un langage de modélisation - il a donc été créé par l'OMG afin de définir la notation UML, par exemple.
C'est un standard de métamodélisation.
Pour pouvoir exprimer des liens de traçabilité ainsi que des transformations entre modèles:
- il est indispensable de travailler non pas uniquement au niveau des modèles, mais aussi au niveau des formalismes de modélisation.
- Il faut exprimer des liens entre les concepts des différents formalismes. Par exemple, il faut pouvoir exprimer que le concept de classe UML doit être transformé dans le concept de classe Java.

Le CWM est le standard de l’OMG pour les techniques liées aux entrepôts de données.
Il couvre le cycle de vie complet de modélisation, construction et gestion des entrepôts de données.
Le CWM définit un méta-modèle qui représente les méta-données aussi bien métiers que techniques qui sont le plus souvent trouvées dans les entrepôts de données.
Il est utilisé à la base des échanges de méta-données entre systèmes hétérogènes.

Un langage visuel permettant de modéliser des besoins d'un système à l'aide de diagrammes et de textes.
Il permet aussi de décrire des architectures, des solutions ou des points de vue.

Un tel modèle doit représenter l’application dans son environnement afin de définir quels sont les services offerts par l’application et quelles sont les autres entités avec lesquelles elle interagit.
Permet de créer Un lien durable avec les besoins du client de l’application.
Il est important de noter qu’un modèle d’exigences ne contient pas d’information sur la réalisation de l’application ni sur les traitements.
Dans le vocabulaire MDA, les modèles d’exigences sont appelés des CIM (Computation Independent Model), littéralement « modèle indépendant de la programmation ».
Avec UML, un modèle d’exigences peut se résumer à un diagramme de cas d’utilisation.
Ces derniers contiennent en effet les fonctionnalités fournies par l’application (cas d’utilisation) ainsi que les différentes entités qui interagissent avec elle (acteurs) sans apporter d’information sur le fonctionnement de l’application.

L’analyse et la conception sont les étapes où la modélisation est la plus présente.
d’abord avec les méthodes: Merise et Coad/Yourdon puis avec les méthodes objet Schlear et Mellor, OMT, OOSE et Booch.
Ces méthodes proposent toutes leurs propres modèles.
Aujourd’hui, le langage UML s’est imposé comme la référence pour réaliser tous les modèles d’analyse et de conception.

MDA considère que le code d’une application peut être facilement obtenu à partir de modèles de code.
La différence principale entre un modèle de code et un modèle d’analyse ou de conception réside dans le fait que le modèle de code est lié à une plate-forme d’exécution.
Les modèles de code servent essentiellement à faciliter la génération de code à partir d’un modèle d’analyse et de conception.

Le domaine de la construction des applications réparties.

Les premiers travaux effectués à l’OMG pour faciliter la construction et la maintenance des applications réparties ont porté sur l’élaboration de la spécification CORBA.
L’objectif de CORBA était de fournir un environnement standard et ouvert permettant à tout type d’application d’interopérer.
il fallait résoudre tous les problèmes d’interopérabilité en standardisant les communications réparties et les interfaces des différentes entités composant l’application répartie.
Pour diverses raisons, CORBA n’a pas été un franc succès. D’autres intergiciels ont à leur tour tenté de résoudre le problème de l’interopérabilité en offrant toujours plus de services aux concepteurs d’applications (EJB, DCOM, Web Services).
les intergiciels qui ont été initialement conçus pour faire face à la complexité des applications réparties ont finalement apporté beaucoup plus de complexité qu’ils n’en ont enlevée.
Le problème n’est pas tant leur propre complexité, qui est inévitable, que le fait que les applications qui les utilisent dépendent fortement des services offerts par ces intergiciels.
De ce fait, changer d’intergiciel devient un cauchemar.
La Solution :
- La séparation des préoccupations entre le métier des applications et la technique des intergiciels.
- De là est né MDA

La pérennité des savoir-faire, afin de permettre aux entreprises de capitaliser sur leur métier sans avoir à se soucier de la technique.
Les gains de productivité, afin de permettre aux entreprises de réduire les coûts de mise en oeuvre des applications informatiques nécessaires à leur métier.
La prise en compte des plates-formes d’exécution, afin de permettre aux entreprises de bénéficier des avantages des plates-formes sans souffrir d’effets secondaires.