2. les modèles n’ont été présentés que par le biais de leur
métamodèle.
ils restent des entités théoriques abstraites fortement
volatiles et ne peuvent être ni stockés ni échangés sur
un support informatique.
Il est bien difficile dans ces conditions de parler de
pérennité.
2
3. La solution
L’OMG propose les standards :
XMI (XML Metadata Interchange)
DI (Diagram Interchange)
qui permettent le support informatique des modèles pour le
stockage et l’échange.
Pour ces standards, l’OMG a choisi de s’appuyer sur le
formatW3C XML.
qui est considéré comme le format international d’échange
de données.
3
4. Le format XML
Documents bien formés :Un document XML bien formé est un
document textuel structuré par un ensemble de balises ouvertes
et fermées.
Exemple :
<Livre titre=’MDA’>
<Auteur prenom=’xavier’ nom=’blanc’></Auteur>
<Chapitre numero=’4’ titre=’Modèles en XML’>
.
.
.
</Chapitre>
</Livre >
4
5. Documents valides :un document valide doit respecter une
structure préétablie d’un ensemble de balises.
Une telle structure préétablie peut, en reprenant l’exemple
précédent, spécifier que la balise Chapitre soit
obligatoirement incluse dans la balise Livre.
Le standard XML propose des moyens pour définir ces
structurations de balises, notamment via les DTD et XML
Schéma.
5
6. DTD (Document Type Definition)
Une DTD est un document textuel qui permet de spécifier une
structuration d’un ensemble de balises en définissant leurs
relations d’inclusion.
Le mot-clé ELEMENT permet de définir une balise. Il doit être
suivi du nom de la balise et de l’ensemble des balises contenues.
Le mot-cléATTLIST permet de définir un ensemble d’attributs
associés à une balise.
Ce mot-clé doit être suivi du nom de la balise qui contiendra les
attributs puis de la liste des attributs.
6
8. XML Schema
Les schémas XML ont été standardisés par leW3C pour
remplacer les DTD en raison de leur souplesse pour définir des
structurations de balises XML.
Exemple :
<element name=’Livre’>
<complexType>
<sequence>
<element ref=’Chapitre’></element>
/sequence>
</complexType>
</element>
8
10. Namespace XML
Les namespace sont utilisés pour regrouper différentes balises
ayant une signification commune.
Un namespace est défini simplement par une URL.
Par exemple, l’OMG a défini l’URL http://org.omg/UML/1.3
pour le namespace des balises UML1.3.
10
12. XSLT (eXtensible Stylesheet Language Transformations)
LeW3C a proposé le standard XSLT (eXtensible Stylesheet
LanguageTransformations) pour élaborer des transformations de
documents XML.
L’approche définie dans ce standard permet de spécifier des
transformations de documents XML à l’aide de templates.
Le standard XSLT est utilisé, par exemple, pour transformer les
documents XML en documents HTML afin de rendre les
documents XML présentables dans les navigateursWeb.
12
14. XMI (XML Metadata Interchange)
L’objectif premier de XMI est de définir un moyen permettant
de représenter un modèle sous forme de document XML.
XMI permet de définir les structurations de balises nécessaires et
suffisantes à la représentation des modèles au format XML.
14
15. Pour définir ces structurations de balises XMI s’appuie sur
l’alignement existant entre les modèles et leur métamodèle.
et les documents XML et leur structuration.
15
17. Règles de génération des balises XML
L’alignement des métamodèles et des structurations de balises
XML permet à XMI de définir un ensemble de règles de
génération automatique de structuration de balises XML à partir
d’un métamodèle.
17
19. Exemple de règles XMI de génération de DTD à partir
d’un métamodèle MOF1.4
1. Toute métaclasse fournit la définition d’une balise ayant
comme nom le nom de la métaclasse.
2. Tout méta-attribut d’une métaclasse fournit la définition d’une
balise ayant comme nom le nom du méta-attribut.
3. Toute métaréférence d’une métaclasse fournit la définition
d’une balise ayant comme nom le nom de la métaréférence.
4. Toute méta-association entre deux métaclasses fournit la
définition d’une balise ayant comme nom le nom de la méta-
association.
19
22. En résumé
Le standard XMI permet de représenter n’importe quel modèle
sous forme de document XML.
Le principe de fonctionnement de XMI consiste : à générer
automatiquement une spécification de structuration de balises
XML (DTD ou XML Schema) à partir d’un métamodèle.
XMI est donc considéré comme le standard assurant
l’interopérabilité minimale pour l’échange des modèles entre
outils.
22
24. Problème : XMI ne permet pas le développement
d’opérations sur les modèles.
Un autre format de représentation des modèles est nécessaire
pour :
permettre leur manipulation dans les langages de
programmation orientée objet.
développer les opérations sur les modèles de la même
manière que pour développer n’importe quelle application
informatique.
24
25. L’OMG a proposé un format de représentation permettant la
manipulation des modèles dans les langages de programmation
orientée objet.
Ce format était défini initialement dans le standard MOF1.3 et
utilisait le langage de définition d’interface CORBA/IDL.
Actuellement, c’est le standard MOF2.0 to IDL qui définit ce
format.
De son côté, le JCP (Java Community Process) a défini le
standard JMI (Java Metadata Interface), uneAPI Javapermettant
la manipulation des modèles.
Enfin, le framework EMF (Eclipse Modeling Framework) a été
conçu pour la manipulation des modèles dans l’environnement
ouvert Eclipse.
25
26. Le principe
Quel que soit le standard ou le framework (MOF, JMI ou
EMF), l’approche est sensiblement la même.
L’idée est de fournir un ensemble d’interfaces offrant les
opérations nécessaires à la manipulation des modèles.
Le développement d’une opération sur les modèles consiste
simplement à développer une application utilisant ces
interfaces de manipulation des modèles.
26
27. Les interfaces de manipulation de modèles proposées par ces
standards sont de deux types :
les interfaces dites taylored,c’est-à-dire taillées sur mesure pour un
métamodèle donné.
et les interfaces dites réflectives, qui permettent l’accès au
niveau du métamodèle.
27
28. Les interfaces taylored
Les interfaces taylored relatives au métamodèle représentant
la structure des diagrammes de cas d’utilisation permettent
d’effectuer les opérations suivantes :
Connaître le nombre d’acteurs contenus dans un modèle,
ajouter ou supprimer des acteurs, connaître le nom d’un
acteur et le modifier, connaître les liens d’héritage entre
acteurs et les modifier et connaître et modifier les cas
d’utilisation dans lesquels participe un acteur.
28
29. Connaître le nombre de cas d’utilisation contenus dans
un modèle, ajouter ou supprimer des cas d’utilisation,
connaître l’intitulé d’un cas d’utilisation et le modifier,
connaître les cas d’utilisation étendus ou inclus dans un
cas d’utilisation et les modifier.
Connaître le nombre de systèmes contenus dans un
modèle, ajouter ou supprimer des systèmes, connaître le
nom d’un système et le modifier et connaître l’ensemble
des cas d’utilisation contenus dans un système et les
modifier.
29
31. Les interfaces réflectives
L’intérêt des interfaces réflectives est qu’elles offrent des moyens
d’accéder aux métaclasses des métamodèles.
À partir d’un élément d’un modèle, il est possible d’accéder à sa
métaclasse et ainsi d’obtenir toutes les informations qui le structurent
(attributs, références, etc.).
Par exemple, sur le modèle de la figure (diapositive précédente) , à
partir de l’élément correspondant au système, il est possible d’accéder
à la métaclasse système et ainsi de savoir que cette métaclasse a un
méta-atttibut nommé nom et des métaréférences vers des éléments
instances de la métaclasse cas d’utilisation.
Grâce à ces informations, nous pouvons connaître le nom du système
ainsi qu’obtenir les cas d’utilisation qui le composent.
31
33. Rendre les modèles productifs consiste à leur
appliquer des transformations de modèles pour
obtenir des résultats utiles au développement,
généralement sous la forme de modèles plus
détaillés et proches de la solution technique ou
du code.
33
34. Différentes transformation
Transformations de modèles CIM vers PIM:
Transformations de modèles PIM vers PIM:
Permettent de raffiner les PIM afin d’améliorer la précision
des informations qu’ils contiennent.
Transformations de modèles PIM vers PSM.
Transformations de modèles PSM vers du code.
34
36. une transformation exprime des correspondances
structurelles entre les modèles source et cible.
Ces correspondances structurelles s’appuient sur
les métamodèles des modèles source et cible.
36
37. Par exemple, une transformation de modèles visant à
transformer des modèles UML vers des schémas de
bases de données relationnelles (BD) spécifierait la
règle suivante :
à toute classe UML correspond une table d’un
schéma d’une base de données.
Cette règle exprime bien une correspondance
structurelle entre les métamodèles UML et BD et
plus précisément une correspondance entre les
métaclasses Class etTable.
37
39. Spécification des règles de transformation
Trois approches aujourd’hui répertoriées permettent
la spécification de ces règles de correspondances:
1. Approche par programmation: Consiste à
utiliser les langages de programmation orientée
objet, Cette approche est la plus utilisée car elle
est très puissante et fortement outillée.
39
40. 2. Approche par template : Consiste à définir
les canevas des modèles cibles souhaités en y
déclarant des paramètres. Ces paramètres
seront substitués par les informations contenues
dans les modèles sources.
Cette approche nécessite un langage particulier
permettant la définition des modèles templates.
40
41. 3. Approche par modélisation : L’objectif est de
modéliser les transformations de modèles et de rendre
les modèles de transformation pérennes et productifs
et d’exprimer leur indépendance vis-à-vis des plates-
formes d’exécution.
Le standard MOF2.0 QVT (Query,View,
Transformation) définie par l’OMG a pour objectif de
définir le métamodèle permettant l’élaboration des
modèles de transformation de modèles.
41
42. résumé
la transformation des modèles de MDA avec les
différentes approches à donner issue au
développement des outils permettant
d’automatiser le passage d’un modèle à un autre.
Les différents outils montrent que l’approche
MDA n’est pas seulement théorique et qu’elle est
incontournable dans les développements
logiciels.
42
