approche mda

Université Cadi Ayyad

Faculté des Sciences Semlalia

Déppartement Informatique

Master ISI

• Réalisé par :M. El Hafed MAJIDM. Fouad AALLOUCHE

• Encadré par :M. My Mouslim

2012 - 20131

2

PLAN GENERAL

PARTIE 1 : MDA (Model Driven Architecture).

PARTIE 2 : ATL (Atlas Transformation Language).

PARTIE 3 : ETUDE DE CAS .

PARTIE 4 : CONCLUSION .

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

L’histoire des systèmes d’information a connu de nombreuses évolutionsLes 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...).

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

• 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

M o d é l i s e r l ’ a p p l i c a t i o n i n d é p e n d a m m e n t d e l a p l a t e - f or m e

Solution

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


OMA : Object Management Architecture

MDA : Model Driven Architecture

• Objectif :S’abstraire de l’implémentationSe focaliser sur le modèle

• 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 servicesassociés

Les fournisseurs de plate-forme doivent mettre à disposition les outils de transformation des modèles vers leur plateforme


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


• 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

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

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

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


• 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.

• 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.


• 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.


• 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.



• 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

• 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


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


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


• 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

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.



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élesexistants. 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.





Exemple :

« Un diagramme de cas d’utilisation décrit l’utilisation d’un système. Ilcontient des acteurs, un système et des cas d’utilisation. Unacteur a un nom et est relié aux cas d’utilisation. Un acteur peuthé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 aussiun nom, et il inclut tous les cas d’utilisation. »

Exemple de Métamodèle• MOF : Meta Object Facility


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


• 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.


• 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 laconstruction 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

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

• 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

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


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èlesen 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

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


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

PARTIE 2 : ATL (Atlas Transformation Language).

JKHFJHVJFHG

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,

Diagramme De Classe

Simple non multi valuée

Complexe non multivaluée

Complexe multivaluée

Relation 0..1 , 0..1

Relation 1 , n

Relation n , n

Relation d’Héritage

approche mda

Engineering