Le document présente une étude approfondie sur l'architecture pilotée par les modèles (MDA), la transformation de modèles à l'aide de l'ATL et démontre l'importance de séparer la logique métier de l'implémentation technique pour favoriser l'évolutivité et l'interopérabilité. L'analyse couvre les différents types de modèles MDA ainsi que les standards de l'OMG impliqués tels que UML, MOF et XMI. Enfin, le document discute des avantages, des faiblesses et des mythes entourant l'approche MDA, tout en soulignant son potentiel pour transformer le développement logiciel.

1. Université Cadi Ayyad
Faculté des Sciences Semlalia
Déppartement Informatique
Master ISI
• Réalisé par :
M. El Hafed MAJID
M. Fouad AALLOUCHE
• Encadré par :
M. My Mouslim
2012 - 20131

2. 2
PLAN GENERAL
 PARTIE 1 : MDA (Model Driven Architecture).
 PARTIE 2 : ATL (Atlas Transformation Language).
 PARTIE 3 : ETUDE DE CAS .
 PARTIE 4 : CONCLUSION .

3. PARTIE 1 : MDA (Model Driven Architecture).
 SOLUTION
 PROBLÉMATIQUE
 MODÈLE OU SYSTÈME
 PASSAGE DE L’OMA AU MDA
 OBJET OU MODÈLE ?
 LES STANDARDS DE L'OMG UTILISES
 LA TRANSFORMATION DES MODÈLES DU MDA
 LES DIFFÉRENTS MODÈLES DU MDA
 MDA «Model Driven Architecture »
 LES FORCES DE MDA
 LES FAIBLESSES DE MDA
 LES MYTHES AUTOUR DE MDA
 CONCLUSION

4. L’histoire des systèmes d’information a connu de nombreuses
évolutions
Les langages de programmation (procéduraux et fonctionnels,
événementiels, orientés objet, services web...)
Les middleware (propriétaires, Corba,….)
Les méthodes de conception ( Merise, les méthodes orientées objet...).

5. Lors d’une migration d’une infrastructure vers une nouvelle
technologie, la logique métier de l’application reste globalement la
même.
Il est donc évident de tenter de différencier l’architecture technique
dépendant de la technologie utilisée de celle de la logique métier.
L’intérêt est de favoriser l’ évolutivité, la réduction de coût et
l’interopérabilité.
Problématique

6. • Le SI prend de plus en plus de place :
Comment le décrire ?
Comment le faire évoluer ?
• Le SI se complexifie :
Le volume des données et du code augmente
Les types d’informations à prendre en compte sont variées
Les plates-formes d’exécution évoluent rapidement
Problématique

7. Modéliser l’application indépendamment
de la plate-forme
Solution

8. OBJET OU MODÈLE ?
• Le tout est objet a connu ses limites :
 Les applications ne sont pas objets
 Les patrons ne sont pas des objets
 Un service n’est pas un objet
 L’étude des besoins n’est pas objet
Cas d’utilisation : étude d’une fonction, d’un
processus

9. PASSAGE DE L’OMA AU MDA
OMA : Object Management Architecture
MDA : Model Driven Architecture
• Objectif :
S’abstraire de l’implémentation
Se focaliser sur le modèle

10. • La réalité des industriels :
 La logique métier est stable
 L’évolution des systèmes, des plateformes est constante
 Les migrations coûtent chère sans de réel retour sur
investissement
• Les objectifs
 Construire des modèles abstraits de leur métier et des services
associés
 Les fournisseurs de plate-forme doivent mettre à disposition
les outils de transformation des modèles vers leur plateforme
PASSAGE DE L’OMA AU MDA

11.  Construire des modèles de références
 Utiliser des méta modèles adaptés pour construire ces
modèles
• Exemple :
 UML : génie logiciel
 CWM : génie des données
 EDOC : modélisation entreprise
 ...
• Les objectifs
PASSAGE DE L’OMA AU MDA

12. • Notion de modèle
 Un modèle est une image simplifiée d’un système
 Un modèle est une représentation d’un système
• Notion de système
 Ensemble organisé d'éléments intellectuels.
 Un système est un ensemble d’éléments en interaction
MODÈLE OU SYSTÈME

13. Le MDA est un méta-modèle de composants.
définit une représentation de l’architecture abstraite et indépendante
de la plate-forme technique, tout en lui associant une multitude de
services métiers.
L’objectif du MDA est la création d’une représentation
UML de la logique métier et de lui associer des caractéristiques
MDA .
MDA

14. La migration d’une application d’une infrastructure à une
autre consiste ainsi à demander, du modèle MDA de la logique métier,
une génération du modèle spécifique à la nouvelle infrastructure cible
MDA

15.  Le noyau de l’architecture de MDA est basé sur des standards de
l’OMG tels que UML, MOF, CWM et XMI.
 L’anneau autour représente les technologies middleware. Nous y
retrouvons les standards actuels tels que les EIB, CORBA, .net et les
Services Web.
 L’anneau extérieur au cercle représente les services.
MDA

16. LES DIFFÉRENTS MODÈLES DU MDA
• CIM
Le CIM est l’abréviation anglaise de Computation Independent Model.
Les exigences du système sont modélisées dans ce modèle qui décrit la
situation dans laquelle le système sera utilisé.
Un tel modèle est parfois appelé Business Model ou Domain Model
c’est-à-dire un modèle de l’entreprise.
Il ne montre pas les détails de la structure du système. Typiquement
ce modèle est indépendant de l’implémentation du système. Le CIM
correspond à la modélisation de l’entreprise sans parler encore de
système informatique.

17. • PIM
Le terme PIM est l’acronyme de Platform Independent Model soit le
modèle indépendant de la plate-forme.
Il décrit le système mais ne montre pas les détails de son
utilisation sur la plate-forme.
Ce modèle est concrètement représenté par un diagramme de
classes en UML.
LES DIFFÉRENTS MODÈLES DU MDA

18. • PSM
Le PSM, pour Platform Specific Model, est, quant à lui, un modèle
dépendant de la plate-forme technique. Ce type de modèle sert
essentiellement de base à la génération de code exécutable.
Il décrit aussi comment ce système utilisera la plate-forme
choisie.
LES DIFFÉRENTS MODÈLES DU MDA

19. • PDM
Ce modèle est désigné par l’acronyme Plateform Description Model. Il
correspond à un modèle de transformation du PIM vers un PSM
d’implémentation. L’architecte doit choisir une ou plusieurs plate-
forme pour l’implémentation du système avec les qualités
architecturales désirées.
Il représente les particularités de chaque plate-forme.
LES DIFFÉRENTS MODÈLES DU MDA

20. LES DIFFÉRENTS MODÈLES DU MDA

21. LA TRANSFORMATION DES MODÈLES DU MDA
• De PIM vers PIM
Ces transformations sont utilisées pour enrichir, filtrer ou
spécialiser les informations des modèles sans rajouter aucune
information liée à la plate-forme. Un exemple de transformation PIM
vers PIM est de masquer des éléments afin de s’abstraire des détails
fonctionnels. Un autre exemple est le passage du modèle d’analyse à
celui de conception

22. • De PIM vers PSM
Un fois le PIM suffisamment raffiné pour pouvoir être
spécialisé vers une plate-forme donnée, il peut alors être transformé
en PSM. Cette opération consiste à ajouter au PIM des informations
propres à une plate-forme technique. Les principales plates-formes
visées sont J2EE, .NET ou CORBA, ...C’est le PDM qui contient les
caractéristiques de transformation. Il est alors possible de passer d’un
modèle indépendant à un modèle dépendant. Les règles de
transformation devront être généralisées et capitalisées pour obtenir
dans le futur une automatisation importante
LA TRANSFORMATION DES MODÈLES DU MDA

23. Une transformation PIM vers PSM n’est pas toujours
suffisante pour permettre la génération de code d’où la nécessité de
passer de PSM à PSM en utilisant des formalismes intermédiaires.
Par exemple, pour générer un code C++, à partir d’un formalisme en
UML, un passage d’UML vers SDL (Specification and Description
Language) puis de SDL vers C++ pourrait être utilisé.
La transformation PSM à PSM s’effectue lors de phases de
déploiement, d’optimisation ou de reconfiguration
• De PSM vers PSM
LA TRANSFORMATION DES MODÈLES DU MDA

24. Cette transformation est utilisée pour revenir à un modèle
indépendant de plate-forme (PIM) à partir d’un modèle spécifique de
plate-forme (PSM) ou éventuellement du code. C’est une opération de
rétro-ingénierie (reverse engineering) qui est assez complexe à
réaliser et difficilement automatisable. Ces transformations sont
néanmoins nécessaires pour permettre l’intégration d’applications
existantes dans le processus MDA
• De PSM vers PIM
LA TRANSFORMATION DES MODÈLES DU MDA

25. LA TRANSFORMATION DES MODÈLES DU MDA

26. • MOF : Meta Object Facility
 Permet d’exprimer les formalismes de modélisation (méta modèles)
 s'intéressant à la représentation des méta modèles et leur
manipulation.
M3: le méta-métamodèle ;
M2: les méta-modèles ;
M1: les modèles ;
M0: le monde réel.
Les standards de l'OMG utilises

27.  Le niveau M1 (ou modèle) est composé de modèles d’information. Il
décrit les informations de M0. Les modèles UML, les PIM et les PSM
appartiennent à ce niveau. Les modèles M1 sont des instances de
méta-modèle de M2.
 Le niveau M0 (ou instance) correspond au monde réel. Ce sont les
informations réelles de l’utilisateur, instance du modèle de M1.
• MOF : Meta Object Facility
Les standards de l'OMG utilises

28.  Le niveau M3 (ou méta-méta-modèle) est composé d’une unique
entité qui s’appelle le MOF. Le MOF permet de décrire la structure
des méta-modèles, d’étendre ou de modifier les méta-modéles
existants. Le MOF est réflexif, il se décrit lui-même.
 Le niveau M2 (ou méta-modèle), il définit le langage de modélisation
et la grammaire de représentation des modèles M1. Le méta-modèle
UML qui est décrit dans le standard UML, et qui définit la structure
interne des modèles UML, fait partie de ce niveau. Les méta-modèles
sont des instances du MOF.
• MOF : Meta Object Facility
Les standards de l'OMG utilises

29. • MOF : Meta Object Facility
Les standards de l'OMG utilises

30. • MOF : Meta Object Facility
Les standards de l'OMG utilises
Exemple :

31. « Un diagramme de cas d’utilisation décrit l’utilisation d’un système. Il
contient des acteurs, un système et des cas d’utilisation. Un
acteur a un nom et est relié aux cas d’utilisation. Un acteur peut
hériter d’un autre acteur. Un cas d’utilisation a un intitulé et peut
étendre ou inclure un autre cas d’utilisation. Le système a lui aussi
un nom, et il inclut tous les cas d’utilisation. »
Exemple de Métamodèle
• MOF : Meta Object Facility
Les standards de l'OMG utilises

32. • MOF : Meta Object Facility
Les standards de l'OMG utilises

33.  UML est devenu le standard de modélisation des logiciels à objets.
Il permet la modélisation d’architectures, de structure d’objets,
d’interactions entre ces objets, de données, de composants, . . .
 Le MDA préconise l’utilisation d’UML pour l’élaboration des
modèles après la sortie de la version 2.0 qui contient des concepts
renfoncés pour les composants et s'intégrera plus facilement dans
le MDA.
 Un des aspects intéressants d ’UML est le concept de profils. C'est
adapter UML à un domaine qui était souvent mal couvert
 Par exemple le profil EJB permet l’é́laboration de PSM pour la
plate-forme EJB
• UML : Unified Modeling Language
Les standards de l'OMG utilises

34. • CWM : Common Warehouse Metamodel
 CWM est le standard de l’OMG qui traite des entrepôts de données.
Il couvre toutes les étapes nécessaires à l’élaboration, à la création et
à la transformation des entrepôts de données. L’approche préconisée
par ce standard pour la migration est une approche MDA. C’est-à-
dire la création de modèles et leurs transformations.
 CWM définit les méta-modèles des principaux types d’entrepôts de
données (Relationnel, Objet, XML,. . .) et propose des règles de
transformation entre ceux-ci.
Les standards de l'OMG utilises

35. • XMI : XML Metadata Interchange
XMI est le standard de l’OMG qui fait la jonction entre le
monde des modèles et le monde XML. XMI se base sur le MOF. Il
permet la génération de DTD et de schémas XML à partir de méta-
modèles. L’application la plus connue de XMI est celle qui a permis la
construction de la DTD UML. Cette dernière permet la représentation
des modèles UML sous forme de documents XML et assure ainsi les
échanges de modèles UML entre les différents outils du marché. Le
standard XMI de sérialisation des modèles compatibles avec MOF est
en cours de stabilisation et son utilisation devient incontournable dans
les outils industriels.
Les standards de l'OMG utilisés

36. LES AVANTAGES DE MDA
• Des systèmes interopérables favorisant l’hétérogénéité des plate-formes
 Aucun plate-forme ne peut gérer l’ensemble de l’interopérabilité du
réseau
 les éditeurs de logiciels peuvent rendre rapidement disponible leurs
produits pour différentes plates-formes et en développant
l’interopérabilité avec les systèmes existants grâce à la démarche de
MDA.
 l’interopérabilité d’une plate-forme Faciliter les transactions
internes ou interentreprises

37. • Le choix de la plate-forme technique la mieux adaptée
• Un développement plus rapide et des logiciels de meilleure
qualité
 Les architectes et les concepteurs peuvent se focaliser exclusivement
sur le détail de la logique métier. Ils travailleront le modèle jusqu’à
obtenir exactement ce qui est spécifié dans le cahier des charges.
 Si un aspect de l’implémentation ne fonctionne pas correctement,
il est facile de savoir s’il s’agit d’une erreur comportementale sur
le modèle métier ou d’une faute dans le code.
LES AVANTAGES DE MDA

38. LES FAIBLESSES DE MDA
• la technologie cible change trop rapidement
• Le MDA est trop compliqué
 avoir les compétences pour modéliser complètement
des systèmes

39. LES MYTHES AUTOUR DE MDA
 L’indépendance totale de plate-forme
 Indépendance des systèmes d’exploitation et des langages
de programmation.
 La génération automatique et complète du code à partir de modèles
en règle générale, il est possible de générer un code à partir d’un
modèle seulement si l’information nécessaire à sa génération est
présente dans le modèle. Dans l’état actuel de l’ingénierie de modèles
et de MDA, il n’est pas possible de générer l’intégralité du code, puis
les modèles ne définissent pas la sémantique et la logique avec un
niveau de détail suffisant.

40. 40
 Pour résoudre ce problème, l’OMG propose l’utilisation des
actions sémantiques de UML 2.0
 L’action sémantique est une proposition qui présente des aspects
positifs, mais elle est encore très récente et peu expérimentée pour
assurer que son utilisation va permettre la génération de l’intégralité
du code dans une approche MDA
LES MYTHES AUTOUR DE MDA

41. 41
La démarche MDA, bien qu’assez récente, suscite un réel
intérêt chez bon nombre d’industriels et de développeurs. En effet,
cette démarche est prometteuse et répond à des attentes légitimes
non comblées par les technologies objet ou composant. Elle autorise
la séparation de la logique métier de l’entreprise de son
implémentation physique. Cette nouvelle approche bouleverse
complètement notre façon de concevoir une application et ouvre de
nouveaux horizons pour le génie logiciel qui ne sera plus dépendant
des évolutions technologiques.
Conclusion

42. 42
PARTIE 2 : ATL (Atlas Transformation Language).
 JKHFJHVJFHG

43. PARTIE 3 : ETUDE DE CAS .
Simple non multivaluée,
Diagramme De Classe ,
Complexe non multivaluée,
Complexe multivaluée,
Relation 0..1 , 0..1,
Relation 1..1 , 1..1,
Relation 0..1 , 1..1,
Relation 1 , n,
Relation n , n,

44. Diagramme De Classe

45. Simple non multi valuée

46. Complexe non multivaluée

47. Complexe multivaluée

48. Relation 0..1 , 0..1

49. Relation 1..1 , 1..1

50. Relation 0..1 , 1..1

51. Relation 1 , n

52. Relation n , n

53. Relation d’Héritage