TD – Ing´enierie des Mod`eles
Transformation de mod`eles
Master des Technologies de l’Internet 2
eme`Ann´ee
Le but de ce TD est de d´efinir une transformation de mod`ele simple `a la fois via ATL et Kermeta pour ´etudier la diff´erence d’expression entre un langage d´eclaratif et un langage imp´eratif.
1 Description des mod` eles
On traite dans ce TD un mod`ele tr`es simplifi´e d’architecture logicielle. Une appplication est form´ee de clients et de serveurs qui sont li´es via des interfaces de services. La tranformation consiste
`a placer un ´el´ement proxy entre chaque client et chaque serveur.
1.1 Description informelle
Dans le mod`ele initial, on trouve trois types d’´el´ements : – Interfaces de service (on n’en d´etaillera pas le contenu)
– Serveur : impl´emente une ou plusieurs interfaces et est associ´e `a plusieurs types de clients – Client : chaque type de client est associ´e `a un seul serveur et utilise une de ses interfaces Apr`es transformation, il s’agit de trouver un proxy associ´e `a chaque type de client entre ce type de client et le serveur. Le proxy impl´emente alors l’interface utilis´e par ce type de client `a la place du serveur. Les clients n’ont plus de liaison directe avec le serveur mais uniquement avec les proxys. Ces derniers sont associ´es au serveur.
<< proxy >>
<< server >>
Server
<< interface >>
Service1
<< interface >>
Service2
<< server >>
Server
Proxy2
<< proxy >>
Proxy1
<< interface >>
Service1
<< interface >>
Service2
<< client >>
Client1
<< client >>
Client2
<< client >>
Client1
<< client >>
Client2 1
1
1
* 1
* 1 *
*
1 1
1
Figure 1: Exemple de transformation d’application
La figure 1 montre un exemple d’une telle application, avant et apr`es transformation, pour 2 types de clients1.
1La notation utilis´ee ici est celle d’un diagramme de classe UML utilisant des st´er´eotypes pour chaque type d’´el´ement.
1
1.2 D´ efinition des m´ eta-mod` eles
Les 2 m´eta-mod`eles source et cible sont d´efinis ci-dessous `a la fois en Kermeta et sous la forme d’un diagramme de classe2.
1.2.1 M´eta-mod`ele source class ModelElement
{
attribute nom : String }
class Interface inherits ModelElement {
reference estImplementeePar : Serveur reference estUtiliseePar : Client }
class Client inherits ModelElement {
reference utilise : Interface reference connecteA : Serveur }
class Serveur inherits ModelElement {
reference implemente : Interface[1..*]
reference connecteA : Client[1..*]
}
utilise ModelElement
nom : String
Serveur
Client Interface
1..* connecteA 1 connecteA
1
estImplementePar
implemente 1..*
1 1
estUtilisePar
Figure 2: M´eta-mod`ele source
2Pour simplifier les m´eta-mod`eles, les associations (ainsi que les cardinalit´es) ne sont pas explicitiment d´efinies, on se contentera de consid´erer les r´ef´erences entre m´eta-classes comme des associations simplifi´ees. On en fera de mˆeme pour la relation d’impl´ementation ou de de d´ependance entre une classe et une interface.
2
1.2.2 Mod`ele cible class ModelElement {
attribute nom : String }
class Interface inherits ModelElement {
reference estImplementeePar : Proxy reference estUtiliseePar : Client }
class Proxy inherits ModelElement {
reference clientConnecte : Client reference serveurConnecte : Serveur reference implemente : Interface }
class Client inherits ModelElement {
reference utilise : Interface reference connecteA : Proxy }
class Serveur inherits ModelElement {
reference connecteA : Proxy[1..*]
}
estUtilisePar
Proxy Interface
Serveur Client
ModelElement nom : String
1estImplementePar 1
1
serveurConnecte
connecteA
1..*
connecteA
1 1
1
implemente utilise clientConnecte
1
Figure 3: M´eta-mod`ele cible
3
1.3 Exercice
1. D´efinir les contraintes OCL manquantes pour exprimer compl´etement les 2 m´eta-mod`eles afin de respecter la description informelle
2. D´efinir la transformation en mode purement imp´eratif en Kermeta 3. D´efinir la transformation en mode purement d´eclaratif en ATL 4. Commenter les diff´erences entre les 2 modes de transformation
4
