JTC 2024 La relance de la filière de la viande de chevreau.pdf
Approche Mda
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
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
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
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
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,