Vous êtes sur la page 1sur 53
Université Cadi Ayyad Faculté des Sciences Semlalia Déppartement Informatique Master ISI • Réalisé par : •
Université Cadi Ayyad
Faculté des Sciences Semlalia
Déppartement Informatique
Master ISI
Réalisé par :
• Encadré par :
M.
El Hafed MAJID
M. My Mouslim
M.
Fouad AALLOUCHE
2012 - 2013
1
PLAN GENERAL
PLAN GENERAL

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

2

PARTIE 1 : MDA (Model Driven Architecture).  PROBLÉMATIQUE  SOLUTION  MODÈLE OU SYSTÈME
PARTIE 1 : MDA (Model Driven Architecture).
PROBLÉMATIQUE
SOLUTION
MODÈLE OU SYSTÈME
  • PASSAGE DE L’OMA AU MDA

  • OBJET OU MODÈLE ?

  • MDA «Model Driven Architecture »

  • LES DIFFÉRENTS MODÈLES DU MDA

  • LA TRANSFORMATION DES MODÈLES DU MDA

  • LES STANDARDS DE L'OMG UTILISES

  • 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 évolutions Les langages de programmation (procéduraux et fonctionnels,

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

...

Problématique Lors d’une migration d’une infrastructure vers une nouvelle
Problématique
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 :
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

Solution
Solution

Modé lis er

l’ appli c ati on

indépendamment

de

l a

pl a t e - f orme

OBJET OU MODÈLE ?
OBJET OU MODÈLE ?
OBJET OU MODÈLE ? • Le tout est objet a connu ses limites :  Les

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

PASSAGE DE L’OMA AU MDA
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

PASSAGE DE L’OMA AU MDA • La réalité des industriels :  La logique métier est
PASSAGE DE L’OMA AU MDA
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 • Les objectifs  Construire des modèles de références
PASSAGE DE L’OMA AU MDA
Les objectifs
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

  • ...

MODÈLE OU SYSTÈME • Notion de modèle
MODÈLE OU SYSTÈME
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

MDA
MDA

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
MDA
La migration d’une application d’une infrastructure à une
MDA La migration d’une application d’une infrastructure à une autre consiste ainsi à demander, du modèle

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
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.
LES DIFFÉRENTS MODÈLES DU MDA • CIM Le CIM est l’abréviation anglaise de Computation Independent Model.
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.

LES DIFFÉRENTS MODÈLES DU MDA • PIM Le terme PIM est l’acronyme de Platform Independent Model
LES DIFFÉRENTS MODÈLES DU MDA
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 • PSM
LES DIFFÉRENTS MODÈLES DU MDA
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 • PDM
LES DIFFÉRENTS MODÈLES DU MDA
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
LES DIFFÉRENTS MODÈLES DU MDA
LA TRANSFORMATION DES MODÈLES DU MDA • De PIM vers PIM
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

LA TRANSFORMATION DES MODÈLES DU MDA • De PIM vers PSM
LA TRANSFORMATION DES MODÈLES DU MDA
De PIM vers PSM

Un fois le PIM suffisamment raffiné pour pouvoir être

LA TRANSFORMATION DES MODÈLES DU MDA • De PIM vers PSM Un fois le PIM suffisamment

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 • De PSM vers PSM
LA TRANSFORMATION DES MODÈLES DU MDA
De PSM vers PSM

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

LA TRANSFORMATION DES MODÈLES DU MDA • De PSM vers PIM
LA TRANSFORMATION DES MODÈLES DU MDA
De PSM vers PIM

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

LA TRANSFORMATION DES MODÈLES DU MDA
LA TRANSFORMATION DES MODÈLES DU MDA
Les standards de l'OMG utilises • MOF : Meta Object Facility
Les standards de l'OMG utilises
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 • MOF : Meta Object Facility
Les standards de l'OMG utilises
MOF : Meta Object Facility
  • 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 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.

Les standards de l'OMG utilises • MOF : Meta Object Facility
Les standards de l'OMG utilises
MOF : Meta Object Facility
  • 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.

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

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

Exemple :

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

Exemple de Métamodèle

« 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. »

Les standards de l'OMG utilises • MOF : Meta Object Facility
Les standards de l'OMG utilises
MOF : Meta Object Facility
Les standards de l'OMG utilises • UML : Unified Modeling Language  UML est devenu le
Les standards de l'OMG utilises
UML : Unified Modeling Language
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

Les standards de l'OMG utilises • CWM : Common Warehouse Metamodel
Les standards de l'OMG utilises
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,. .

transformation entre ceux-ci.

.) et propose des règles de

Les standards de l'OMG utilisés • XMI : XML Metadata Interchange
Les standards de l'OMG utilisés
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 AVANTAGES DE MDA • Des systèmes interopérables favorisant l’hétérogénéité des plate-formes
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 internes ou interentreprises

LES AVANTAGES DE MDA • Des systèmes interopérables favorisant l’hétérogénéité des plate-formes  Aucun plate- forme

Faciliter les transactions

LES AVANTAGES DE MDA • Le choix de la plate-forme technique la mieux adaptée
LES AVANTAGES DE MDA
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 FAIBLESSES 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

LES MYTHES AUTOUR DE MDA  L’indépendance totale de plate-forme
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.

LES MYTHES AUTOUR DE MDA  Pour résoudre ce problème, l’OMG propose l’utilisation des
LES MYTHES AUTOUR DE MDA
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

40

Conclusion
Conclusion

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.

41

PARTIE 2 : ATL (Atlas Transformation Language).
PARTIE 2 : ATL (Atlas Transformation Language).

JKHFJHVJFHG

42

PARTIE 3 : ETUDE DE CAS . Diagramme De Classe , Simple non multivaluée, Complexe non
PARTIE 3 : ETUDE DE CAS .
Diagramme De Classe ,
Simple non multivaluée,
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
Diagramme De Classe
Simple non multi valuée
Simple non multi valuée
Simple non multi valuée
Simple non multi valuée
Complexe non multivaluée
Complexe non multivaluée
Complexe non multivaluée
Complexe non multivaluée
Complexe multivaluée
Complexe multivaluée
Complexe multivaluée
Complexe multivaluée
Relation 0 .. 1 , 0 .. 1
Relation 0
..
1
, 0
..
1
Relation 0 .. 1 , 0 .. 1
Relation 0 .. 1 , 0 .. 1
Relation 1 .. 1 , 1 .. 1
Relation 1
..
1
,
1
..
1
Relation 1 .. 1 , 1 .. 1
Relation 1 .. 1 , 1 .. 1
Relation 0 .. 1 , 1 .. 1
Relation 0
..
1
,
1
..
1
Relation 0 .. 1 , 1 .. 1
Relation 0 .. 1 , 1 .. 1
Relation 1 , n
Relation 1 , n
Relation 1 , n
Relation n , n
Relation n , n
Relation n , n
Relation d’Héritage
Relation d’Héritage
Relation d’Héritage
Relation d’Héritage