RapportAntoine 4

Approche MDA pour la transformation dun diagramme de classes conforme UML 2.0 en un schma relationnel conforme CWM et normalis_L.
Exprimenter le langage ATL ddi la transformation de modle pour limplmentation dune mthode de transformation dun diagramme UML en un schma CWM.
Rapport de Stage de fin de Master, Juin 2006.
Etudiant :
Encadrants :
Antoine Wiedemann
Etudiant en Master 2me anne mention Informatique, Mathmatique et leurs Applications, option recherche Image et Calculs lUniversit de La Rochelle.
Jean-Yves et Marie-Christine Lafaye, Georges Louis

Professeurs lUniversit de La Rochelle
Table des matires
1 2
4 5
Introduction ...................................................................................................................... 1 Gnrer un modle relationnel normalis partir de diagrammes de classes UML [1] ................................................................. 2 2.1 Introduction dune nouvelle forme normale : la normalisation_L ............................. 2 2.1.1 Normalisation en conception de base de donnes []. ......................................... 2 2.1.2 Les premires rgles de normalisation ............................................................... 2 2.1.3 Normalisation allge (Normalisation_L), prsente dans larticle de M.C. Mafaye, J.Y. Lafaye et G. Louis [1]................................................................................... 3 Quelques dfinitions......................................................................................................... 4 3.1 Modle........................................................................................................................ 4 3.2 UML 2.0 ..................................................................................................................... 4 3.3 OCL 2.0...................................................................................................................... 6 3.4 CWM .......................................................................................................................... 6 3.5 Metamodle................................................................................................................ 9 3.6 MOF ......................................................................................................................... 10 La gnration dun modle relationnel vue comme une transformation de modle. ....................................................................... 11 Lingnierie dirige par les modles, ou Model-driven Architecture (MDA) .......... 12 5.1 MDA......................................................................................................................... 13 5.2 QVT.......................................................................................................................... 16 ATL.................................................................................................................................. 16 6.1 Lopration lmentaire de transformation : la rgle ATL ...................................... 17 6.2 Utilisation dATL..................................................................................................... 19 6.2.1 Spcification des mtamodles ........................................................................ 19 6.2.2 Spcification des modles ................................................................................ 22 6.2.3 Le module ATL................................................................................................ 24 6.3 Des exemples de cas dutilisation dATL ................................................................ 25 Implmentation............................................................................................................... 26 7.1 Un exemple de modle de domaine ......................................................................... 26 7.2 Accoucher les mtamodles ..................................................................................... 27 7.2.1 Spcifier le mtamodle cible : le mtamodle de CWM. ............................... 27 7.2.2 Spcifier le mtamodle source, le mtamodle de domaine ou encore le mtaMDC. ........................................................................................................................ 28 7.2.3 Rsultat : le mtaMDC..................................................................................... 29 7.2.4 Construire un exemple de modle conforme.................................................... 31 7.3 Extraire de lalgorithme les rgles de transformation .............................................. 34 7.3.1 Algorithme gnral de traduction : Objet vers relationnel normalis_L.......... 34 7.3.2 Identifier les lments et leurs antcdents ...................................................... 36 7.3.3 Dterminer les oprations de traduction........................................................... 37 7.3.4 Exprimer les oprations dans le langage ATL ................................................. 37 7.3.5 Exemple 1, Classe_Table ................................................................................. 37 7.3.6 Exemple 2, AssoBinaire_Cas2......................................................................... 38 7.4 Contrler, complter, corriger.................................................................................. 43 Conclusions lissu de lexprimentation.................................................................... 44 8.1 Les avantage dATL................................................................................................. 44
8.2 Inconvnients dATL ............................................................................................... 45 8.3 Une ou plusieurs transformations ?.......................................................................... 45 8.3.1 Chanage de transformations............................................................................ 45 8.3.2 Cration de plusieurs mtamodles intermdiaires .......................................... 45 9 Travaux futurs................................................................................................................ 46 9.1 Dlimiter lintervention dATL dans le processus................................................... 46 9.2 Terminer lvolution du mtaMDC.......................................................................... 46 9.3 Terminer lextraction de rgles de lalgorithme....................................................... 46 9.4 Explorer les possibilits dinterfaage ..................................................................... 47 10 Conclusion....................................................................................................................... 47 11 Annexes ........................................................................................................................... 48 11.1 Le code complet de la transformation (module MDC2MLRnL.atl) ........................ 48 11.2 Le module MDC2Chemins.atl ................................................................................. 50 11.3 Description des mtaclasses du mtaMDC. ............................................................. 51 11.3.1 Classe_persistante ............................................................................................ 51 11.3.2 Generalisation_persistante ............................................................................... 52 11.3.3 Association_persistante.................................................................................... 53 11.3.4 Attribut ............................................................................................................. 53 11.3.5 ID...................................................................................................................... 54 11.3.6 ID_exportable................................................................................................... 55 11.3.7 Symb_ID_exportable ....................................................................................... 55 11.3.8 Composant_identifiant ..................................................................................... 56 11.3.9 Espace_de_recherche ....................................................................................... 56 11.3.10 Arc_de_composition .................................................................................... 57 12 Ressources Internet et bibliographiques ...................................................................... 59
Table des figures

Figure 1 - Extrait du mtamodle UML 2.0 ............................................................................... 5 Figure 2 - Extrait du mtamodle de CWM .............................................................................. 8 Figure 3 - Exemple de trois classes dun modle dont deux sont conformes leur mtaclasse dans le mtamodle ..................................................... 9 Figure 4 -Larchitecture 4-niveaux dfinie par lOMG ........................................................... 10 Figure 5 -Larchitecture de mtadonnes de lOMG............................................................... 11 Figure 6 - La transformation d'un modle ............................................................................... 12 Figure 7 - Logo MDA ............................................................................................................... 13 Figure 8 - Vue gnrale dune transformation dun PIM en PSM .......................................... 14 Figure 9 - Un exemple de rgle ATL ........................................................................................ 17 Figure 10 -Vue densemble dune transformation ATL ........................................................... 19 Figure 11 -Extrait dun fichier de dfinition du mtamodle UML 2.0 au format km3........... 20 Figure 13 - Injection du fichier km3 dans le format xmi conforme Ecore ......................... 20 Figure 14 -Extrait dun fichier de dfinition du mtamodle UML 2.0 au format xmi ........... 21 Figure 15 - Le fichier MDC.ecore affich par lditeur EMF ................................................. 22 Figure 16 -Exemple de dpart de dfinition dune classe, dans un fichier ecore au format xmi................................................................................ 22 Figure 17 - Un onglet Properties permet daccder aux proprits de la classe Class. ... 22 Figure 18 - Le mot cl container permet de reflter une aggregation UML ........................... 23 Figure 19 -Le menu contextuel New Child ......................................................................... 23 Figure 20 - Le menu contextuel New Sibling ..................................................................... 23 Figure 21 - Extrait du code transformation du module ATL ................................................... 24 Figure 22 - L'exemple de transformation Class2Relational .................................................... 25 Figure 23 - Exemple de modle de domaine annot utilis dans larticle [1] ......................... 26 Figure 24 - Extrait du fichier MLRnL.km3 dit dans la plateforme eclipse .......................... 28 Figure 25 - Rsultat de linjection du fichier km3 ............................................................ 28 Figure 26 - Notre mtamodle de domaine construit sur UML 2.0 ......................................... 30 Figure 27 - La classe Stage ...................................................................................................... 31 Figure 28 - Dtail de lespace de recherche de la classe Stage .............................................. 32 Figure 29 - Modlisation de l'association Stage Etudiant .................................................... 33 Figure 30 - Les lments impliqus dans la modlisation de lassociation Stage Etudiant .................................................................................... 33 Figure 31 - Algorithme gnral de transformation .................................................................. 35 Figure 32 - Une table pour une classe, en ATL ....................................................................... 38 Figure 33 - Cas gnrique dassociation UML trait par la Normalisation_L ....................... 38 Figure 34 - La rgle AssoBinaire_Cas2 .................................................................................. 39 Figure 35 - Le helper cardinalites ........................................................................................... 40 Figure 36 - Le helper cas2 ....................................................................................................... 40 Figure 37 - Premir lment gnr par la clause "to" ........................................................... 42 Figure 38 - la deuxime partie de la clause "to" ..................................................................... 42 Figure 39 - Rgle de gnration des cls primaires ................................................................ 43 Figure 40 - Extrait du rsultat de la transformation de la classe Stage .................................. 44
1 Introduction
Le problme de la gnration automatique de base de donnes partir dun diagramme de classe a dj t largement tudi et enseign sur le plan thorique. Souvent, on se contente dtudier les diffrents cas de figure qui peuvent se prsenter en terme de multiplicits des associations entre classes, et de dterminer dans chaque cas le schma relationnel adapt pour implanter ces associations. En pratique pourtant, le procd se rvle bien plus complexe ds lors que lon aborde des cas concrets et que lon se donne des exigences sur la qualit de la base de donnes rsultante. Que ce soit sur le plan du processus de normalisation, de la conservation des connaissances mtier injectes par le concepteur tout au long du processus de gnration, et/ou plus concrtement de lergonomie des outils disponibles sur le march, beaucoup reste faire. Ainsi, pour aller plus loin dans la prcision et la correction sans perdre de vue la simplicit dutilisation, M.C. Lafaye, J.Y. Lafaye et G. Louis (ci-aprs nomms les auteurs) proposent dans leur article Gnrer un modle relationnel normalis partir de diagrammes de classes UML [1] un processus complet qui en plus dadresser les problmes identifis plus haut, tire partie dune nouvelle approche pleine de promesse dans lunivers du gnie logiciel : lingnierie dirige par les modles (MDA en anglais). Pour valider les avantages de ce processus et de la mthode quil incarne, il a t choisi de tenter une partie de son implmentation dans le langage ATL spcialement conu pour la transformation de modles. Ce langage est dvelopp dans le cadre du projet ATLAS [2] men luniversit de Nantes par une quipe de chercheurs de lINRIA. Le travail prsent ici est une exprimentation et une valuation de lutilisation dATL pour raliser cette implmentation.
Approche MDA pour la transformation dun diagramme de classes UML 2.0 en un schma CWM
2 Gnrer un modle relationnel normalis partir de diagrammes de classes UML [1]

Dans larticle cit en titre de cette section, les auteurs se sont attaqus un problme finalement bien commun et dj largement trait aussi bien sur le plan thorique dans les ouvrages pdagogiques que sur le plan pratique dans plusieurs ateliers de gnie logiciel (ou CASE Tools). Cependant, leurs prcdents travaux [3] ont montr travers trois exemples que lutilisation de certains outils disposition produit des rsultats largement perfectibles. Premirement, les rgles de la normalisation ne sont pas respectes, aboutissant des calculs de cls errones ou manquantes. Deuximement, au stade de la conception, il est parfois difficile didentifier les objets aussi finement que ce que le modle relationnel est capable de restituer, et linverse, certaines identifications inutiles et fastidieuses sont rendues obligatoires alors quelles ne sont pas utilises par la suite. Aprs avoir identifi ces problmes, les auteurs se sont donns pour but dlaborer une nouvelle mthodologie avec trois ambitions principales : produire un schma relationnel normalis, faciliter le travail dannotation du concepteur, et respecter autant que possible sa terminologie mtier. Pour atteindre ces objectifs, les auteurs sappuient sur diffrentes innovations dont principalement : lintroduction dune nouvelle forme normale, la forme normale allge (appele normalisation_L), dfinie par leurs soins comme un relchement contrl de certaines contraintes de la normalisation classique, et lutilisation de la rcente approche MDA particulirement adapte la transformation de modle et dont nous utilisons les concepts ici.
2.1 Introduction dune nouvelle forme normale : la normalisation_L

2.1.1 Normalisation en conception de base de donnes [4]. La qualit dune base de donne voque en introduction est trs lie la minimisation de la redondance. Dune manire gnrale, la thorie de la normalisation utilise des dpendances parmi lesquelles les dpendances fonctionnelles, les dpendances multi-values et les dpendances de jointure pour construire une structure de donnes redondance minimale. Rappelons la dfinition dune dpendance fonctionnelle en base de donnes : Dans une relation, un sous-ensemble Y dattributs de R est en dpendance fonctionnelle avec un sous-ensemble X dattributs de R ( not X -> Y ) si et seulement si pour toute valeur de R, chaque valeur de X correspond exactement une seule valeur de Y. X est appel dterminant. Plusieurs niveaux de normalisation sont caractriss : 1FN, 2FN, 3FN, BCNF, 4FN, 5FN. 2.1.2 Les premires rgles de normalisation Premire forme normale Une relation est en premire forme normale si et seulement si tout attribut de cette relation est atomique, c'est--dire quun attribut nest compos que dune valeur significative la fois (par opposition une adresse complexe, par exemple) et monovalu. 2
Deuxime forme normale Une relation est en deuxime forme normale si et seulement si elle est en premire forme normale, quelle na quune seule cl, et que tout attribut n'appartenant pas la cl ne dpend pas d'une partie de cette cl. Troisime forme normale Une relation est en troisime forme normale si et seulement si elle est en deuxime forme normale et si chaque attribut non cl est en dpendance non transitive avec la cl primaire. Forme normale de Boyce-Codd (BCNF) Une relation est en forme normale de Boyce-Codd si et seulement si seuls les dterminants sont des cls candidates. Quatrime et cinquime formes normales. Pour traiter les cas plus complexes ou apparaissent des association n-m entre les relations du schma relationnel, la thorie de la normalisation introduit, au-del des simples dpendances fonctionnelles qui sont utiliss dans les noncs de ces premires formes normales, les notions de dpendances multi-values et de composantes de jointure (ou dpendance de jointure). Ltude de ces notions sort du cadre du prsent travail. Elles sont simplement mentionnes ici puisquelles font partie de larsenal des outils qui ont ts utiliss par les auteurs du processus pour garantir sa qualit. Lapplication de ces principes permet une amlioration considrable de la qualit de la base obtenue partir du schma ainsi normalis. Elle facilite le respect des contraintes dintgrit imposes lors de la conception en vitant la redondance des donnes et donc en rendant les mises jour plus aises. 2.1.3 Normalisation allge (Normalisation_L), prsente dans larticle de M.C. Mafaye, J.Y. Lafaye et G. Louis [1]. Comme nous lavons vu dans la section prcdente, la thorie de la normalisation gnralement admise aujourdhui, et qui par son application en conception de base de donnes est un gage de qualit, nonce un certain nombre de principes, qui conduisent la modification de la structure dun schma relationnel initial. Cependant, lapplication stricte de la normalisation conduit dans certains cas la cration de tables supplmentaires, qui ne font que satisfaire au principe de conservation des dpendances. Cest pourquoi dans leur article [1], les auteurs sautorisent quelques entorses ces rgles de normalisation, pour pouvoir les appliquer de faon plus raliste sans introduire forcment de redondance. Cette normalisation allge , ou normalisation_L propose par rapport la normalisation stricte les nuances suivantes : Les attributs valeur NULL sont admis Les rgles des premires formes normales, jusqu la BCNF, ne sont appliques non pas toutes les dpendances fonctionnelles mais seulement celles permettant de collecter lensemble des contraintes dunicit et de rfrence sur les tables relationnelles.
3 Quelques dfinitions
Il convient, avant daller plus loin, de dfinir ce que lon entend ici par modle, et galement de mtamodle ainsi que larticulation entre ces concepts.
3.1 Modle
Un modle pourrait tre dfini comme une reprsentation abstraite de quelque chose. En pratique, les modles sont prsents partout autour de nous dans la vie courante, et les exemples sont nombreux. Un plan de votre maison par exemple est le modle partir duquel on a construit la maison que vous habitez. Ce plan regroupe des caractristiques de dimension que votre maison respecte (en principe). Dans le contexte de la modlisation, on dit alors que votre maison est reprsente par son modle (son plan). Un modle peut galement reprsenter des choses plus abstraites, comme par exemple une squence doprations qui senchanent dans le temps, ou bien alors lorganisation et les interactions qui ont lieu entre les employs dune entreprise. Il est important de noter que plusieurs entits distinctes peuvent tres reprsentes par un unique modle donn. Par exemple, dans un immeuble dhabitation, tous les appartements sont souvent construits partir dun nombre limit de modles diffrents (un modle de T3, un modle de T2, etc.). Intuitivement, les atouts de lutilisation dun modle sont nombreux, surtout comme outil de communication. Reprenons lexemple de la maison. Le plan dune maison est le fruit dune concertation entre un architecte et le futur propritaire, et permet de visualiser lallure gnrale du btiment. Il permet galement de faire des calculs de dimension pour les matriaux utiliss lors de la construction, mais aussi de prsenter le projet la mairie pour obtenir un permis de construire. Le plan est naturellement relu par lentrepreneur et utilis comme guide de montage pendant la construction. Enfin, lors dun ventuel recours du propritaire qui a not une non conformit de louvrage termin avec le plan initial, cest le document qui fait foi et qui est prsent une instance judiciaire. Cette notion peut sappliquer de nombreux domaines, et en particulier celui qui nous intresse, linformatique. Dans ce cas, le modle reste un outil de communication, mais les acteurs ne sont plus systmatiquement humains. Lexemple le plus connu est la programmation, o un oprateur humain (le programmeur) crit un modle de comportement ou de calcul (un programme), et le transmet travers un processus de compilation ou dinterprtation au systme informatique qui produit un comportement ou des calculs dcrits dans le modle initial. De la mme faon que le plan de larchitecte est crit avec une syntaxe, une nomenclature et des symboles picturaux prcis, de nombreux langages de programmation diffrents coexistent et peuvent chacun exprimer certains types de modles de cacluls. On voit donc que mme si le concept de modle est trs rpandu, les langages pour les exprimer sont trs variables.
3.2 UML 2.0

UML [5] (pour Unified Modeling Language) est aujourdhui le standard des langages de modlisation objet partout o cette dernire est utilise. Ce langage est lune des spcifications centrale de lOMG, et est aujourdhui dans sa version 2.0. Il prsente sur le plan
smantique et pratique de grandes qualits dutilisation, et dans le cas prsent de la conception de base de donnes, UML est depuis longtemps utilis pour spcifier un haut niveau dabstraction la structure et larticulation des donnes, sous forme respectivement de classes et dassociations. Par ailleurs, un avantage de cette technologie, la fois cause et consquence de sa grande popularit, est la profusion sur le march doutils plus ou moins ergonomiques ddis la cration et la manipulation de diagrammes UML. Cest pourquoi il a t choisi, dans limplmentation de lalgorithme prsent ici, dutiliser un diagramme de classe UML comme moyen de dialogue avec le concepteur, pour capter ses exigences et ses connaissances mtier. Le cadre du problme tant bien dlimit, nous nutiliserons pas toute la complexit du langage UML. Nous attendons du concepteur quil exprime des informations de type structurelles et pas dynamiques. Ainsi, parmi la multitude de types de diagrammes prdfinis par la spcification UML [6], nous nutiliserons que le format diagramme de classes. Nous pourrons mme nous satisfaire dun sous-ensemble des classes prdfinies dans le package Kernel de la spcification de la superstructure dUML 2.0. Ces classes sont indiques dans le diagramme ci-dessous.
<<metaclass>> DirectedRelationship
<<metaclass>> Relationship
<<metaclass>> Element
* constrainedElement
<<metaclass>> Generalization * generalization
<<metaclass>> Namespace
<<metaclass>> NamedElement name : string
<<metaclass>> PackageableElement
MultiplicityElement <<metaclass>> type Type 0..1 <<metaclass>> TypedElement isOrdered : boolean isUnique : boolean
1 specific 1 general <<metaclass>> Classifier
<<metaclass>> StructuralFeature <<metaclass>> Class 0..1 class * operand <<metaclass>> Association 0..1 association <<metaclass>> AssociationClass 2..* memberEnd 0..1 expression <<metaclass>> Expression symbol : string
lowerValue 1 1 upperValue <<metaclass>> ValueSpecification 0..1 specification
* ownedAttribute <<metaclass>> Property
<<metaclass>> Constraint
Figure 1 - Extrait du mtamodle UML 2.0 Cet ensemble de classes prexiste dans la spcification, chacune avec sa smantique et ses caractristiques, en terme dattributs, de multiplicits, mais aussi de lien les unes avec les autres. Elles ne sont pourtant que rarement faites pour tre utilises telles quelles, mais plutt pour constituer les lments de base la construction dautres classes, plus finement dfinies au plus proche des besoins de lutilisateur (leur majorit est en consquence dfinie comme abstraite, do leur nom de mtaclasses ). Nous avons ainsi cr un nouvel ensemble de classes spcifiques au problme pos, soit en hritant des classes de base mentionnes dans le 5
diagramme prcdent, soit en en dfinissant de nouvelle. Cet ensemble nous permet dans lalgorithme de proposer au concepteur le vocabulaire ncessaire et suffisant pour exprimer ses besoins et ses souhaits, en terme de structure de donnes, darticulation des donnes et didentification. Ces mtaclasses sont prsentes plus loin.
3.3 OCL 2.0

OCL [12] (pour Object Constraint Language) est une autre spcification de lOMG. Cette spcification propose un langage de description de contraintes sur des modles UML. Jusqu la version 1.4 de ce dernier, OCL tait dcrit lintrieur des spcifications dUML tant les deux sont lis. Aujourdhui dans sa version 2.0, la maturation dOCL la amen possder sa propre documentation parallle celle dUML. OCL nest pas un langage de programmation et il ne permet pas de contrler un flot dexcution ou dagir sur son environnement dexcution, cest seulement un langage formel suffisamment simple pour tre utilis par des non mathmaticiens pour crire des expressions devant tres values sur des modles UML. Les expressions OCL svaluent toujours soit en un des quatre types primitifs dfinis : entier, rel, chane de caractre et boolen, soit en un lment du modle, soit en un groupe homogne de ces types tels que les squences dentiers, les squences ordonnes de boolens ou une squence de Property Ces expressions peuvent ensuite tres utilises pour spcifier des contraintes bien sr, mais aussi des pr ou des post-conditions doprations ou de mthodes, ou encore simplement comme expressions de requtes de certaines valeurs dun modle. Pour naviguer dans les attributs, les rfrences ou les mthodes dun lment E de modle, OCL utilise le point . , comme le fait Java par exemple (E.attribut1, E.methodeB, E.associationF). Quand un attribut est multivalu ou quune association mne plusieurs lments la fois, lvaluation de cet attribut ou de cette association renvoi une squence, ordonne ou non des lments quil rfrence. Pour manipuler ces squences, OCL dfini toute sortes de mots cls pour les trier, en extraire des lments, en ajouter, les compter, etc. Enfin, OCL est dfini comme un langage sans effet secondaires (side-effect free en anglais), c'est--dire quil garantit que lvaluation dune requte OCL sur un modle quelconque ne modifiera en rien le modle en question.
3.4 CWM
CWM [7], pour Common Warehouse Model, est lui aussi un langage, comme UML dont il reprend la grammaire et spcialise la smantique. Ce langage est galement une spcification adopte par lOMG, et tente de rpondre aux problmes poss par les simples constatations suivantes. Les statistiques montrent quen moyenne, la quantit dinformation stocke par une organisation donne double tous les cinq ans. La plupart du temps, la gestion de ces donnes est rendue extrmement difficile par leur surabondance, leur redondance et leur htrognit. Leur stockage dans des entrepts de donnes ( data warehouse en anglais) structurs est indispensable pour les rendre exploitables. Or un des aspects essentiels du stockage de donnes dans des entrepts est la description de ces mmes entrepts, pour permettre entre autre aux applications tierce den connatre la structure et ainsi de pouvoir y puiser linformation. Cette description prend la forme de mtadonnes, c'est--dire dans le cas gnral de donnes qui dcrivent les donnes. Pour compliquer encore la situation, on sait quen pratique de nombreux systmes de stockage de donnes diffrents existent et sont utiliss. Ainsi ds lors quun besoin dchange de donnes va apparatre entre deux systmes,
le premier ne pourra se contenter dexploiter sa propre description mais aura aussi besoin de celle de lautre. On utilisera alors lchange des mtadonnes dcrivant les deux systmes (interchange of warehouse metadata). Cest l lintrt du langage CWM. Il propose un standard pour lchange de ces mtadonnes, mais aussi pour exprimer leur transformation, leur analyse, leur cration et leur gestion. En pratique, CWM est en fait constitu dune partie du langage UML 1.4 (le package Object Model) dont tous les lments qui ne sont pas pertinents dans les scnarii de stockage de donnes ont ts supprims. Comme cela est le cas pour UML, nous ne faisons quant nous quune utilisation partielle de CWM, puisque nous nous contentons de la partie relationnelle et statique du langage. Notre but est en effet daboutir un modle conforme CWM ddie la gnration de code SQL pour la cration des tables, attributs, cl et rfrences dcrites dans le modle. Les classes CWM que nous utiliserons, directement ou par hritage sont les suivantes et sont donc un extrait de la spcification de lOMG.
ObjectM odel::Core Feature * feature ModelElement ownedElement *
Foundation::Keys and Indexes UniqueKey * 1 uniqueKey * /ownedElement
namespace 0..1 1..* feature StructuralFeature 1..*feature Namespace keyRelationship * keyRelationship 0..1 owner 1 type Classifier Package * KeyRelationship * /ownedElement
* typedFeature
Attribute
DataType
0..1 /namespace Class 0..1/namespace
Ressource::Relational 1..* /feature ColumnSet 1 ForeignKey * /ownedElement * /uniqueKey UniqueConstraint 1..* /ownedElement
Column * col
NamedColumnS et
0..1/namespace Table 1 /namespace 0..1 /namespace
PrimaryKey /ownedElement 1
Figure 2 - Extrait du mtamodle de CWM Notez quici, contrairement au cas prcdent dUML, nous ne nous sommes pas permis de raffiner les classes prdfinies. Cela peut paratre trivial, mais tout lintrt du standard CWM est quil reste standard, et quun diagramme exprim dans ce langage puisse tre inject dans un outil de gnration de code compatible. Une quelconque modification des classes de base de CWM compromettrait voire anantirait cette ncessaire compatibilit. Cependant, des pistes de recherche pourraient nous amener introduire comme pour le modle de domaine initial des classes supplmentaires, qui hriteraient ou non des classes prdfinies par CWM, et qui nous serviraient, lors de certaines tapes du processus et avant la production dun modle final exclusivement conforme CWM, exprimer des rsultats
intermdiaires o des informations ncessaires aux traitements automatiques ultrieurs sont encore prsents sous forme dautre classes que celles prexistantes dans la spcification.
3.5 Metamodle
Un mtamodle est simplement une description dun langage de modlisation. Il apporte les rgles syntaxiques qui permettent de lutiliser (dcrire un modle dans ce langage) et le sens de chaque item prsent dans ce langage. Par exemple, la spcification du langage Java, c'est--dire sa grammaire et sa smantique, constitue le mtamodle du langage Java. Dans le contexte de la modlisation on dit quun programme Java sans erreur syntaxique est conforme au mtamodle du langage Java. Attention, cette conformit ne garantit pas que le programme ne contient pas derreur dexcution, ou mme quen labsence derreur dexcution, les rsultats obtenus lissu de son excution seront ceux attendus par le programmeur.
Figure 3 - Exemple de trois classes dun modle dont deux sont conformes leur mtaclasse dans le mtamodle Remarquons quun mtamodle est donc par essence un modle puisquil correspond la dfinition de reprsentation abstraite donne plus haut. Par voie de consquence, pour peu que ce mtamodle soit exprim dans un langage prdfini, il possde lui-mme un mtamtamodle qui dcrit prcisment ce dernier nouveau langage. Nous voyons alors se profiler, pour un modle donn, une hirarchie infinie de mtamodles se dcrivant les uns les autres. En pratique, cette hirarchie nest pas infinie. Elle est dailleurs souvent trs courte, puisque nous disposons en ralit dun unique mtamodle que nous partageons tous et qui grce son extrme richesse nous permet de dcrire tous les autres. Il sagit simplement de la langue crite ou orale. En effet, lintrt des langues est quelles sauto dcrivent, c'est--dire que lon peut les utiliser pour spcifier la faon de les utiliser. Prenez un dictionnaire de franais, les dfinitions de chaque mot sont rdiges en franais. Prenez une grammaire franaise, nouveau, les rgles de grammaire sont exprimes par des phrases qui utilisent et respectent ces mmes rgles. Dans le cas du langage de programmation Java par exemple, le mtamodle (disons pour simplifier sa documentation), est simplement exprime en langue crite, que ce soit langlais, le franais ou le danois, et il nest pas ncessaire dajouter une nouvelle description cette documentation.
3.6 MOF
Pour permettre au langage de dcrire toute chose, il faut lenrichir en permanence avec une trs grande varit de syntaxes, toutes sortes de cas particuliers, une trs grande souplesse et une quantit norme de vocabulaire qui le rend difficile traiter automatiquement. Pour palier ces problmes et faciliter lchange de mtadonnes, lOMG a spcifi un langage objet graphique restreint spcialis dans la description de mtamodles. Il sagit du langage MOF [9] (pour Meta Object Facility). La valeur ajoute de ce nouveau langage est quil possde un nombre limit de mots , ici des classes, et une syntaxe prcise et invariante. Par ailleurs, et cest essentiel, comme les langues il sauto dcrit. Ainsi, dans un contexte de modlisation, on sait avoir toujours notre disposition un langage gnralement admis et la smantique bien dfinie pour coiffer la hirarchie des modles/mtamodles. LOMG prcise alors quen pratique, la trs grande majorit des cas de modlisation pourra se contenter de lutilisation de 4 niveaux au maximum comme le montre le schma ci-dessous.
Figure 4 -Larchitecture 4-niveaux dfinie par lOMG Ces niveaux prennent les nom M0 jusqu M3, et reprsentent chacun un tage de la hirarchie des modles/mtamodles dont nous parlions prcdemment. Dans lexemple prcis de la figure ci-dessus, on retrouve au sommet de la hirarchie (niveau M3) le langage MOF qui spcifie et dcrit le langage du mtamodle dUML (niveau M2), lui-mme dfinissant les lments dun modle UML (niveau M1) dont une des classe donne lexcution une instance (niveau M0).
10
Les trois derniers langages que nous avons vu, (UML, CWM et MOF) sont donc tous trois issus des rflexions de lOMG sur les notions de modlisation et de mtamodlisation. Ils ont ts crits et rcrits pour pouser leur vision hirarchique expose prcdemment, et font tous trois partie de leur architecture de mtadonnes (OMG Metadata Architecture).
Figure 5 -Larchitecture de mtadonnes de lOMG Paraphraser ce tableau constitue un bon rsum des concepts essentiels que nous venons dexposer. Les langages de modlisation UML et CWM du niveau M1 servent modliser des systmes ou des entrepts de donnes au niveau M0. Ces langages sont dcrits au niveau M2 par leurs mtamodles respectifs, en utilisant un langage spcifique, le MOF, lui-mme dfini par son propre mtamodle au niveau M3. Nous pouvons maintenant avancer vers la manipulation de ces modles et en particulier leur transformation.
4 La gnration dun modle relationnel vue comme une transformation de modle.

Dans la traduction dun diagramme de classe en un schma relationnel, on distingue clairement ce qui peut se voir sous la forme dune transformation de modle. Dans un premier temps en effet, le travail du concepteur consiste construire et enrichir par ses annotations un diagramme de classes UML, langage strictement document et dont la connaissance est largement partage dans la communaut informatique et au-del. En fin du processus, le rsultat final sera de la mme faon un modle, exprim cette fois-ci dans un langage spcialement ddi la description de structure de donnes persistantes : le langage CWM [7]. Ce langage jouit des mmes qualits en terme de documentation. Lexpression du rsultat dans ce langage permet denvisager sereinement linteroprabilit avec un gnrateur de code (SQL par exemple) pour la cration directe de la base de donnes sur une quelconque plateforme. Entre le point de dpart et le rsultat de la mthode propose ici, plusieurs oprations seront effectues tantt par le concepteur, tantt par le systme qui vont modifier ltat et la nature du diagramme de classe initiale. A diverses tapes par exemple, le systme aura calculer de faon automatique les valeurs de certains attributs des classes du modle en cours de traitement. Lors dune autre, il sagira en plus de ces calculs de traduire le
11
diagramme exprim en UML en un schma exprim en CWM. Toute ces tapes et en particulier cette dernire, constituent des transformations de modle, bien que parfois ces transformations se rduisent des calculs lmentaires.
Modle UML
Transformation
Modle CWM
Figure 6 - La transformation d'un modle Nous verrons comment lingnierie dirige par les modles et le standard MDA sont des rponses concrtes qui permettent prcisment deffectuer ce passage. Nous prsenterons galement limplmentation de ce cette approche, o nous avons utilis le langage ATL.
5 Lingnierie dirige par les modles, ou Model-driven Architecture (MDA)

Dans le contexte de lingnierie logicielle, lOMG a depuis quelques annes rflchit sur la question de lutilisation extensive de modles, dune part comme outil de dialogue avec les utilisateurs et/ou les concepteurs pour reprsenter les besoins fonctionnels, et dautre part comme langage de reprsentation de la connaissance suffisamment proche dune architecture logicielle donne pour permettre un passage automatique dun modle du code informatique. Cette rflexion reprend lambition fondamentale de sparer au mieux les problmes de spcification des fonctionnalits dun systme, et les dtails dimplmentation de ces fonctionnalits.
12
5.1 MDA
Figure 7 - Logo MDA En 2001, lOMG a prsent le fruit de ses rflexions dans un document Overview and guide to OMG's architecture [8], o le groupe introduit son architecture dirige par les modles (Model Driven Architecture en anglais). Il y est montr comment utiliser intensivement les modles pour le dveloppement logiciel, et un ventail dexemples dimplmentation y est dcrit. LOMG dfinit dans ce guide MDA plusieurs niveaux dabstraction et dindpendance vis--vis dune implmentation particulire dans un environnement logiciel et matriel particulier. On retrouve ainsi essentiellement, du plus indpendant au plus spcifique, les niveaux Computation independant , Platform independant et Platform specific . Il est propos dexprimer (de modliser) successivement un problme dans ces trois niveaux, dabord au plus gnral pour capter le mieux possible les besoins souvent exprims par des non-spcialistes, jusquau plus fin permettant ainsi dans lidal la gnration directe de code fonctionnel pour une configuration logicielle et matrielle donne. Les deux niveaux les plus utiliss sont les deux derniers, Platform independant et Platform specific . Pour permettre le passage ou la traduction de lun vers lautre, lapproche MDA sous-entend tout dabord de modliser le problme ou le systme considr au niveau le plus indpendant, puis dutiliser diffrents types de transformation de modle pour obtenir le modle spcifique la plateforme cible.
13
Figure 8 - Vue gnrale dune transformation dun PIM en PSM Ces modles sont appels PIM (pour Platform Independant Model et PSM (pour Platform Specific Model ), et sont exprims dans nimporte quel langage (par exemple UML que nous avons dj voqu). Le rsultat de la transformation du PIM laide dune technique particulire sera non seulement le PSM mais galement lenregistrement de la transformation, cest dire la correspondance entre les lments gnrs en sortie et leurs parents , ou origines dans le PIM ainsi que les parties de la transformation (des rgles ou des liens) qui ont conduit la cration des lments en sortie. LOMG propose une classification des transformations en 5 grands types :
Transformations utilisant le marquage. Ici, larchitecte du systme marque les lments du PIM en puisant dans un ensemble de marqueurs prdfinis pour une plateforme cible donne. Les rles des lments source ainsi indiqus, on gnre par lintermdiaire des liens prvus dans le mapping , les lments du PSM qui correspondent.
14
Transformation utilisant la fusion de modles. Cette deuxime faon de procder est propose dans le guide de lOMG comme trs gnrique, et il est indiqu sans plus de prcisions que diverses dclinaisons MDA en drivent.
Transformations utilisant les mtamodles Dans ce cas, cest en spcifiant des rgles de transformation directement entre les lments des mtamodles du PIM et du PSM que lon cre la transformation. Cest cette technique qui est utilise par loutil ATL sur lequel nous reviendrons en dtail.
Transformations utilisant les types Cette fois-ci, on utilise plutt des types que des lments de mtamodles pour identifier les correspondances. Ces types peuvent reprsenter des fonctionnalits ou des caractristiques aux niveaux indpendants de la plateforme ou spcifiques un environnement.
15
Transformation utilisant les types et les patrons. Les liens sont spcifis entres des types et des patrons dfinis pour le PIM et le PSM. Cette variante reprend simultanment les principes des deux prcdentes.
Pour rsumer, quel que soit le type de transformation utilis, le PSM sert finalement de base la gnration de code adapt la plateforme cible. Dans notre cas, le Platform specific model sera un modle conforme CWM [7], et constituera un pont vers la gnration de code SQL.
5.2 QVT
Dans le cadre de lapproche MDA, lOMG introduit le langage QVT [9] (pour Querry, View, Transformation). QVT est une spcification couple celle du MOF, et comme son nom lindique nest plus ddie la spcification de modles, mais leur manipulation. Ce langage possde une nature hybride dclarative/imprative et implmente la transformation de modle de diffrentes manires. Cette spcification est encore en travaux aujourdhui, et les fonctionnalits en matire de visualisation de modles sont peu avances. Nous la citons ici car elle possde des liens historiques importants avec le langage ATL que nous verrons plus loin (section 6).
MDA, associ ses outils tels que MOF/QVT et UML/OCL, est donc un nouveau paradigme qui offre des possibilits nouvelles en matire dingnierie logicielle. Dans le cadre des bases de donnes, ces techniques pourraient peut-tre permettre de faciliter la modlisation des systmes, par le dveloppement doutils de conception plus ergonomiques et rigoureux. Le travail prsent explore une partie de ces possibilits.
6 ATL
Suite la publication en 2001 du standard MDA par lOMG, de nombreux diteurs de logiciels et laboratoires de recherches ont mit sur le march des outils se rclamant de cette architecture. Parmi ceux-ci le laboratoire de lINRIA de Nantes a dvelopp le langage ATL
16
(pour ATLAS Transformation Language) de transformation de modles dans le cadre de son projet ATLAS [2]. Ce langage est officiellement parti dune tentative dimplmentation du QVT Request For Proposal de lOMG, en reprenant en particulier les diverses faons dclaratives et impratives de spcifier une transformation. Il est dvelopp sur la plateforme Eclipse et plus particulirement sur sa branche EMF (pour Eclipse Modeling Framework). Il est accompagn de nombreux outils pour faciliter son utilisation. La mise en forme des mots cls du langage est assur dans lditeur de code ATL, un debugger est fourni, et une notation textuelle simple appele km3 (pour Kernel MetaModel) permet la spcification de mtamodles. Pour raliser notre objectif initial dautomatiser le calcul dun schma relationnel CWM partir diagramme de classes UML, nous nutilisons que les fonctionnalits de transformation dATL, qui sont dailleurs les plus dveloppes. Cependant, ce langage permet galement lcriture de simples requtes sur des modles, comme le prvoit le volet Query de QVT. Dailleurs, il est vident que faire une transformation de modle serait difficile sans la capacit de lire (et donc deffectuer des requtes sur) le modle source. Ainsi pour les transformations comme pour les seules lectures de modles, ATL utilise intensivement le mode dcriture et la smantique des mots cls de la norme OCL (section 3.3), aujourdhui dans sa version 2.0.
6.1 Lopration lmentaire de transformation : la rgle ATL

Un programme de transformation crit en ATL est compos de rgles qui spcifient comment les lments du modle source sont reconnus et parcourus pour crer et initialiser les lments du modle cible. Ces rgles sont de la forme gnrale suivante : rule ForExample { from i : InputMetaModel!InputElement to o : OutputMetaModel!OutputElement( attributeA <- i.attributeB, attributeB <- i.attributeC + i.attributeD ) } Figure 9 - Un exemple de rgle ATL ForExample est le nom de la rgle de transformation. i (resp. o) est le nom de la variable qui dans le corps de la rgle va reprsenter llment source identifi (resp. llment cible cr). InputMetaModel (resp. OutputMetaModel) est le mtamodle auquel le modle source (resp. le modle cible) de la transformation est conforme. InputElement dsigne la mtaclasse des lments du modle source auxquels cette rgle va sappliquer. OutputElement dsigne la mtaclasse partir de laquelle la rgle va instancier les lments cibles. Le point dexclamation permet de spcifier quel mtamodle appartient une mtaclasse en cas dhomonymie.
17
attributeA et attributeB sont des attributs de la mtaclasse OutputElement Leur valeur est initialise laide des valeurs des attributs i.attributeB, i.attributeC et i.attributeD de la mtaclasse InputElement.
Voici comment on pourrait formuler la fonction de cette rgle en langage naturel. La rgle ForExample, pour chaque lment i de type InputElement quelle identifie dans le modle source, cre dans un modle cible un lment o de type OutputElement, et initialise les valeurs des attributs attributeA et attributeB de o avec les valeurs des attributs attributeB, attributeC et attributeD de i. Dans cet exemple simple, on voit lutilisation du . , issu de la spcification OCL et reprit par ATL, qui permet dans les expressions i.attributeB, i.attributeC et i.attributeD de naviguer dans le modle source i. En plus des rgles, le langage ATL dispose du mot cl helper , qui permet de dfinir des macros lextrieur des rgles pour factoriser des parties de code souvent utilises. Des exemples de ces helpers sont utiliss et expliqus par la suite. Un programme ATL, appel un module, est essentiellement un groupement de rgles et de helpers. En dehors du module lui-mme, les lments fixes de la traduction sont donc les deux mtamodles source et cible. Le modle source peut quant lui tre vu comme le paramtre de la transformation, et le modle cible son rsultat. Cest travers la configuration de lenvironnement dexcution du programme que lon spcifie concrtement dans quels fichiers le moteur de traduction doit chercher les mtamodles, le modle source, le fichier programme, et dans quel fichier on attend quil crive le modle rsultat. Nous lavons vu, les modles source et cible de la transformation sont conformes leurs mtamodles respectifs fournis par lutilisateur. Notons quun module ATL peut lui aussi se reprsenter sous forme dun modle, puisque comme nimporte quel langage ATL possde son propre mtamodle. Notons enfin quATL utilise nativement comme mta-mtamodle une version peine diffrente du MOF, le mta-mtamodle Ecore dfini par la branche EMF de la plateforme Eclipse. Le schma suivant illustre ces principes travers lexemple dune transformation ATL nomme Author2Person, destine transformer un modle nomm Author en un modle nomm Person. En pratique, les modles et leurs mtamodles cibles et source prennent dans lenvironnement de dveloppement Eclipse la forme de fichiers texte au format xmi avec une extension .ecore.
18
Figure 10 -Vue densemble dune transformation ATL
6.2 Utilisation dATL

Considrons notre problme Gnrer un modle relationnel normalis partir de diagrammes de classes UML . Faisons abstraction des calculs indiqus dans le processus de conception dcrit dans larticle, des ncessaires interactions avec lutilisateur, et concentrons nous sur la traduction proprement dite du modle UML en modle CWM. Les informations que nous devons apporter au systme pour nourrir le moteur de traduction ATL sont : Le mtamodle UML 2.0 Le mtamodle CWM Le modle UML (le modle du domaine conforme au mtamodle UML 2.0) Le code ATL de transformation Ces lments doivent permettre de gnrer automatiquement Le modle CWM (le schma relationnel conforme au mtamodle CWM)
6.2.1 Spcification des mtamodles
Les mtamodles UML 2.0 et CWM sont crits dans le langage km3 dans deux fichiers textes distincts : MDC.km3 (pour Modle De Domaine) dans lequel nous avons spcifi deux package, la fois la partie du mtamodle dUML 2.0 qui nous intressait, et un package o nous avons regroup les mtaclasse spcifique notre domaine. MLRnL.km3 (pour Modle Logique Relationnel normalisL) dans lequel nous avons extrait les packages et les mtaclasses qui nous intressaient de la spcification CWM de lOMG.
19
Voici un extrait du fichier MDC.km3 et plus particulirement du package UML20.

package UML20 { class Element { } abstract class NamedElement extends Element { attribute name[0-1] : String; } abstract class Namespace extends NamedElement { } abstract class Classifier extends Namespace, Type { reference generalization[*] container : Generalization oppositeOf specific; } class Class extends Classifier { reference ownedAttribute[*] container : Property oppositeOf "class"; } }
Figure 11 -Extrait dun fichier de dfinition du mtamodle UML 2.0 au format km3 A partir de ces deux fichiers textes distincts, on obtient laide dun injecteur accessible travers linterface de la plateforme eclipse les deux fichiers xmi correspondants.
Figure 12 - Injection du fichier km3 dans le format xmi conforme Ecore
20
Dans ces fichiers xmi, on trouve les classes dfinies initialement en km3 sous forme textuelle traduite en terme de mtaclasses (puisquil sagit dun mtamodle) en xmi , donc galement sous forme textuelle, et conformes au mta-mtamodle Ecore (trs proche du MOF). Voici les mmes mtaclasses que dans lexemple prcdent exprimes cette fois-ci au format xmi.
<?xml version="1.0" encoding="ISO-8859-1"?> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"> <ecore:EPackage name="UML20"> <eClassifiers xsi:type="ecore:EClass" name="Element"/> <eClassifiers xsi:type="ecore:EClass" name="NamedElement" abstract="true" eSuperTypes="/0/Element"> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name" ordered="false" unique="false" eType="/2/String"/> </eClassifiers> <eClassifiers xsi:type="ecore:EClass" name="Namespace" abstract="true" eSuperTypes="/0/NamedElement"/> <eClassifiers xsi:type="ecore:EClass" name="Classifier" abstract="true" eSuperTypes="/0/Namespace /0/Type"> <eStructuralFeatures xsi:type="ecore:EReference" name="generalization" ordered="false" upperBound="-1" eType="/0/Generalization" containment="true" eOpposite="/0/Generalization/specific"/> </eClassifiers> <eClassifiers xsi:type="ecore:EClass" name="Class" eSuperTypes="/0/Classifier"> <eStructuralFeatures xsi:type="ecore:EReference" name="ownedAttribute" ordered="false" upperBound="-1" eType="/0/Property" containment="true" eOpposite="/0/Property/class"/> </eClassifiers> </ecore:EPackage> </xmi:XMI>
Figure 13 -Extrait dun fichier de dfinition du mtamodle UML 2.0 au format xmi Maintenant au format xmi et comme nous venons de le dire conforme au mtamtamodle Ecore inclus dans le plugin EMF declipse, le mtamodle peut tre interprt et affich par lditeur graphique dvelopp dans le cadre de ce mme plugin.
21
Figure 14 - Le fichier MDC.ecore affich par lditeur EMF
6.2.2 Spcification des modles Bien que de nombreux outils plus ou moins faciles mettre en uvre soient en principe disposition, lcriture dun modle est plus fastidieuse. On ne peut plus utiliser le langage km3 exclusivement ddie la dfinition de mtamodles. Il faut alors commencer par crire directement un fichier texte au format xmi en spcifiant les lments du modle avec leurs balises ouvrantes et fermantes. Dans lexemple suivant, on a cr un fichier exemple.ecore o lon dfinit la main une classe de type Classe. Le type Classe est une rfrence la mtaclasse du mme nom dans le mtamodle UML20 lui-mme rfrenc par lattribut xmlns de la balise xmi:XMI.
<?xml version="1.0" encoding="ISO-8859-1"?> <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns="UML20"> <Class> </Class> </xmi:XMI>
Figure 15 -Exemple de dpart de dfinition dune classe, dans un fichier ecore au format xmi Pour autant que la syntaxe xmi soit correcte et conforme au mtamodle, lditeur permet ensuite daccder plus facilement, la souris, aux attributs et aux associations des lments prcdemment crs.
Figure 16 - Un onglet Properties permet daccder aux proprits de la classe Class. En plus de pouvoir diter dans un onglet les valeurs des proprits de llment slectionn, un menu contextuel accessible par clic droit sur le mme lment permet dans certains cas de provoquer la cration de nouveaux lments issus du mtamodle. Par exemple, on voit dans notre extrait du mtamodle dUML 2.0 que les lments de type Class possdent entre autre par leur membre ownedAttribute des lments de type Property. Cette relation est une relation dagrgation, prcise dans notre fichier km3 original du mtamodle UML 2.0 par le mot cl container
22
class Class extends Classifier { reference ownedAttribute[*] container : Property oppositeOf "class"; }
Figure 17 - Le mot cl container permet de reflter une aggregation UML Cette qualit particulire de la relation entre Class et Property, permet de disposer dans lditeur de la plateforme eclipse de la fonction de gnration automatique dlments fils dun autre. Cest cette fonction que nous utilisons dans lexemple ci-dessous.
Figure 18 -Le menu contextuel New Child Une fois un lment contenu par un autre cr, une variante de la fonction New Child est alors disponible, puisque lon peut crer la souris des lments jumeaux , du mme niveau dans la hirarchie contenants/contenus. Lexemple suivant montre comment crer une deuxime proprit pour la mme classe, en utilisant cette possibilit.
Figure 19 - Le menu contextuel New Sibling
23
A laide de ces derniers mcanismes et de longlet Properties, on peut ainsi spcifier relativement aisment une classe. Cependant, lexprience montre qucrire ainsi des modles complets reste assez fastidieux. 6.2.3 Le module ATL Lcriture du programme de transformation proprement dit (annexe 11.1) ne pose en pratique aucun problme. Elle se rsume simplement la cration dun fichier texte avec lextension atl, o lon crit les rgles de transformation et les helpers.
Figure 20 - Extrait du code transformation du module ATL 24
6.3 Des exemples de cas dutilisation dATL

Pour favoriser laccs ATL, lquipe des dveloppeurs du langage concentre son activit de soutien technique autour de deux ples, dune part un forum de discussion trs vivant et ractif [10], et dautre part une bibliothque dexemples de cas dutilisation [11] regroupant chaque fois au moins les mtamodles cible et source, un modle source, le code ATL et une capture dcran indiquant le paramtrage de la plateforme eclipse pour lexcution du programme. De trs nombreux cas de figures sont abords, et leur examen permet datteindre rapidement sinon un matrise, du moins une comprhension du mcanisme global de fonctionnement dATL. En particulier, un des exemples nomm Class2Relational bien que simpliste, est assez proche de nos proccupations en terme de transformation de modle UML vers un modle CWM. Contrairement aux auteurs de larticle [1], cette transformation ne se proccupe pas dune quelconque normalisation du schma relationnel obtenu, mais montre comment mettre simplement en correspondance des classes et des tables, des attributs et des colonnes...
Class2Relational
Figure 21 - L'exemple de transformation Class2Relational
25
7 Implmentation
Le cadre technique et les notions qui sont manipules sont maintenant dfinis. Nous pouvons aborder les dtails de lexprimentation que nous y avons men. Lordre dans lequel les tapes sont dcrites correspond lordre chronologique du dveloppement dune transformation de modle en gnral. En pratique cependant, dans notre cas de recherche comme dans dautres, ce processus est loin dtre linaire, et de nombreuses rtroactions ont lieu entre les phases de dveloppement. Pour nous aider, nous avons reprit ltude de cas dtaill par les auteurs du processus de conception dans leur article pour illustrer leurs propositions.
7.1 Un exemple de modle de domaine
<<persistent_class>> Personne {Alias(PERS)} K1_PERS {Id_PERS} Id_PERS : undefined Nom : undefined Adresse : undefined K1_ETUD <<ID>> {Numro}
<<persistent_class>> Enseignant {Alias(ENS)}
tuteur 0..1 * * <<persistent_class>> Stage {Alias(STG)} 1 Id_STG : undefined 0..1 Sujet : undefined Dbut : undefined Fin [0..1] : undefined 1 K1_PROP <<ID>> {ID_PROP} 0..1 K1_SOUT <<ID>> {K_STG} K1_ENT <<ID>> {Siret}
<<persistent_class>> Etudiant {Alias(ETUD)} 1 Numro : undefined
<<persistent_class>> Proposition {Alias(PROP)} Sujet : undefined Lieu : undefined Date : undefined * 1 entreprise <<persistent_class>> Entreprise {Alias(ENT)} Siret : undefined Raison_sociale : undefined Adresse : undefined
K1_STG <<ID>> {Id_STG}
K2_STG <<ID>> {K_ETUD, Dbut}
<<persistent_class>> Soutenance {Alias(SOUT)} Date : undefined Salle : undefined
Figure 22 - Exemple de modle de domaine annot utilis dans larticle [1] Cet exemple prsente le cas o un utilisateur a besoin denregistrer diverses informations relatives des stages dtudiants. On retrouve dans donc dans le modle de domaine des classes qui doivent terme permettre la persistance de ces informations. Le nom
26
des classes est explicite, on voit ainsi que le concepteur cherche enregistrer ltudiant qui a effectu le stage, lenseignant qui a ventuellement t le tuteur encadrant ce stage, de quelle proposition formule par quelle entreprise est issu ce stage, et ou et quand aura lieu sa soutenance. Comme nous lavons dit, le choix du langage UML pour exprimer le modle de domaine permet au concepteur dutiliser sa prsuppose connaissance de ce langage pour enrichir son modle. On voit par exemple quil a intelligemment factoris certaines informations personnelles pour les classes Enseignant et Etudiant dans une superclasse commune Personne, en utilisant le mcanisme dhritage dUML. On voit galement que le concepteur, en associant les classes les unes avec les autres, a spcifi des cardinalits varies sur ces associations. Ces cardinalits portent beaucoup de sens, sont prises en compte dans lalgorithme de transformation, et induisent des stratgies de cration de cl diffrentes dans le modle relationnel final. Pour faciliter le travail du concepteur lors de la spcification du modle de domaine, les auteurs de lalgorithme ont par ailleurs enrichi le vocabulaire UML avec deux strotypes importants, les strotypes persistent_class et ID . Le strotype persistent_class permet de spcifier explicitement quelles classes de son modle de domaine il souhaite voir implantes sous forme de tables dans le modle relationnel. Cette distinction entre les classes persistantes et non-persistantes lui permet davoir plus de liberts pour crer lors de la conception des classes utilitaires utiles ce moment l mais sans information pertinente prenniser. Le strotype ID permet quant lui au concepteur de spcifier des identifiants pour les classes. Ces identifiants et leur traitement sont essentiels dans lalgorithme de cration et de rsolution des cls du modle relationnel final. Ils constituent les briques de construction des cl primaires et des cls trangres des tables et des rfrences dduites du modle de domaine. Bien quil puisse dfinir un ou plusieurs identifiants par table, le concepteur ny est pas oblig. Le processus prvoit alors leur gnration automatique par le systme, pour sassurer que chaque table ait au moins un identifiant unique.
7.2 Accoucher les mtamodles

Une des premire tches effectuer pour dmarrer la programmation dune transformation de modle avec ATL est la dfinition des mtamodles cibles et source. En thorie, elle prcde toutes les autres puisquelle conditionne lcriture dune part du modle source et dautre part du code ATL lui-mme qui est exprim en terme de rgles qui manipulent les lments de ces mtamodles sources et cibles. Cette phase est absolument essentielle tout le reste du processus, et la pratique nous a montr dans notre cas que la plus grosse partie du travail de mise en uvre dune transformation consiste prcisment dfinir ces mtamodles, et sentendre sur les dfinitions que lon donne aux lments qui la compose et aux liens qui relient ces lments. 7.2.1 Spcifier le mtamodle cible : le mtamodle de CWM. Comme nous lavons dit, le but de lalgorithme est daboutir terme un modle de schma relationnel. Le langage CWM possde cette capacit grce ses packages ObjectModel::Core (emprunt UML 2.0), Foundation::Keys and Indexes et Resource::Relational, (cf figure mta CWM en page 8). Nous avons pu nous reposer
27
exclusivement sur ces trois packages pour nos besoins. Nous nous approprions la syntaxe et la smantique dcrite dans la spcification de lOMG pour documenter les modles relationnels que nous produisons. Dans la plateforme eclipse, la spcification concrte du mtamodle cible a simplement consist rcrire dans le langage km3 les contenus de ces 3 packages pour les injecter dans la plateforme sous forme de fichier ecore.
Figure 23 - Extrait du fichier MLRnL.km3 dit dans la plateforme eclipse
Figure 24 - Rsultat de linjection du fichier km3 7.2.2 Spcifier le mtamodle source, le mtamodle de domaine ou encore le mtaMDC. Le travail effectu pour aboutir un mtamodle de modle de domaine complet a t beaucoup plus long et sinueux. Il a consist mener plusieurs recherches en parallle dtailles dans les sections suivantes.
28
7.2.2.1 Chercher quoi le modle de domaine fourni en exemple est conforme.
Ceci peut tre vu comme une phase de rtro-modlisation. Bien sr, comme le modle de domaine est crit en utilisant le langage UML 2.0, tous les lments (classes, associations, multiplicits) sont lincarnations des mtaclasses correspondantes dans le mtamodle UML 2.0 (cf mtamodle en page 5). Mais comme nous lavons dit, nous avons souhait limiter le vocabulaire disponible un sous ensemble restreint dUML, et plus encore des spcialisations dun sous-ensemble des mtaclasses UML. Ainsi par exemple, plutt que de se contenter de la classe Class du mtamodle UML 2.0 comme mtaclasse de la classe persistante Stage de notre MDC, nous avons dfini une nouvelle mtaclasse, nomme Classe_persistante, qui hrite de la mtaclasse Class, et qui est spcialement ddie tre utilise comme type pour les classe persistante dans un modle de domaine. Le mme phnomne sest produit pour les attributs des classes persistantes. L, nous avons cre une nouvelle mtaclasse nomme Attribut, hritant de la mtaclasse Property du mtamodle UML, pour dfinir spcifiquement le type attributs des classes persistantes . De la mme faon, on a ajout les mtaclasses Generalisation_persistante et Association_persistante notre mtaMDC. A linverse, nous nous sommes parfois repos sur les mtaclasses dUML, comme par exemple la mtaclasse nomme Expression, pour permettre au concepteur dcrire les cardinalits des extrmits des associations persistantes.
7.2.2.2 Ajouter des classes utilitaires
Toutefois, en plus des mtaclasses ncessaires exprimer les types des lments prsents dans le MDC, nous savions avoir besoin au cours de lalgorithme dexprimer dautres concepts que ceux prsents et visibles dans le MDC final tel quil est prsent la figure de la page 26. Cest par exemple le cas de la mtaclasse Arc_de_composition, ou Espace_de_recherche. Si aucun lment de ces types napparat plus dans le MDC final, cest que ces lments nont eu de sens que temporairement au cours de lalgorithme. Ils ont cependant ts indispensable, et leur reprsentation ncessit quon ajoute au mtamodle une mtaclasse propre.
7.2.2.3 Mrir les relations entre les mtaclasses et la signification de ces liens
Ajouter des mtaclasses au mtamodle naurait pas de sens si les concepts quelles refltent navaient aucun lien entre eux. Par exemple, la notion dattribut na de sens quen conjonction avec la notion de classe persistante. Cest pourquoi dans le mtamodle on trouve une association entre les deux classes du mme nom. Il en va de mme pour toutes les classes du mtaMDC. 7.2.3 Rsultat : le mtaMDC Dans notre exprience, et comme nous lavons dj dit, la spcification du mtaMDC a t trs longue. En effet, partir dun premier essai, le travail a immdiatement aprs consist tenter de recrer un modle de domaine quivalent celui de larticle et bien entendu conforme cette premire spcification de mtaMDC. La pratique soulevait alors des problmes imprvus au dpart ou bien souvent galement des divergence dinterprtation des lments du mtaMDC, et nous amenait rviser ce dernier. Ce processus de spcification est encore en cours aujourdhui. Certains concepts tels que larc de composition pourraient par
29
exemple tre amens disparatre dans de futures versions du mtaMDC. La figure ci-dessous traduit notre vision linstant de la rdaction de ces lignes, avec ses imperfections. Pour rsumer, le mtamodle des modles de domaines complets est construit sur la base des mta classes existantes dans la norme UML 2.0. Dix classes spcifiques notre problme sont ajoutes dans un nouveau package MDC avec les hritages et les associations suivantes :
<<metaclass>> Constraint <<metaclass>> Generalization <<metaclass>> Association <<metaclass>> Class <<metaclass>> Property
Generalisation_persistante 1 Association_persistante 1 {xor} 1 propritaire Classe_persistante extrmit 1 Alias : string * * CalculerEspace() 1 1 origine 1
1..* attribut
Attribut
Symb_ID_exportable 1 /Nom : string
1 Espace_de_recherche 1 1..*
Arc_de_composition * 1..* * ID * id_ci expression implicite 1..* * {disjoin}
composant
1..*
Composant_identifiant
ID_exportable
Figure 25 - Notre mtamodle de domaine construit sur UML 2.0 Les classes en blanc appartiennent au package Classes du mtamodle UML 2.0. La description formelle des nouvelles mtaclasses introduites ici, comme celle des associations qui les relient est disponible en annexe 11.3. Une fois cette spcification tablie, son intgration dans lenvironnement eclipse se fait comme vu prcdemment par lintermdiaire de sa rcriture en km3. Le fichier MDC.km3 contient cette traduction. Y sont inclus les deux package UML20 qui regroupe les mtaclasses slectionnes parmi celles du mtamodle UML 2.0 (voir ci-dessus- Extrait du mtamodle UML 2.0 en page 5) et MDC qui contient lui les mtaclasses spcialises ajoutes par nos soins. Le fichier MDC.km3 est ensuite inject dans le format xmi conforme au mtamodle Ecore du plugin EMF declipse.
30
7.2.4 Construire un exemple de modle conforme En thorie, ayant en main les mtamodles source et cible, nous pourrions ce stade crire directement et compltement la transformation en code ATL. Cependant, pour pouvoir ds nos premiers pas dans cette criture tester notre code, nous aurons invitablement besoin dun modle candidat passer en paramtre la transformation. En pratique donc, il convient dabord de se donner ce modle candidat, en crant dans notre cas un exemple de modle conforme au mtamodle source dvelopp prcdemment. Les mtaclasses source dont nous disposons, doivent donc permettre au concepteur de construire les modles dentre du processus, appels modles de domaine. Voici, quelques exemples extraits de ltude de cas relatif aux stages dtudiant de larticle [1].
Figure 26 - La classe Stage Voici la classe stage avec ses attributs, ses ID, son espace de recherche et son symbole exportable. La nomenclature des lments est automatique et reprend dabord le nom de la mtaclasse dans le mtamodle laquelle llment se conforme, puis la valeur de lattribut name de llment, quand cet attribut est valu (ce qui est toujours le cas dans lexemple). Notez la reprsentation arborescente dans lditeur eclipse. Cette reprsentation vient du fait que toutes les mtaclasses (les types) des lments lists ci-desssus, c'est--dire les mtaclasses Attribut, ID, Espace_De_Recherche et Symbole_ID_Exportable, sont lies la mtaclasse Classe_persistante par des relations dagrgation dans le mtaMDC. Cette notion dagrgation est traduite visuellement par cette structure arborescente. Voyons maintenant en dtail llment de type Espace_de_recherche li la llment de type Classe_persistante Stage.
31
Figure 27 - Dtail de lespace de recherche de la classe Stage Comme nous venons de le dire, cet lment est reprsent dans llment Classe_persistante Stage cause du lien dagrgation qui les relie dans le mtaMDC. Lexistence de ce lien est confirme par la valeur de la rfrence nomme Classepersistante appartenant llment Espace_de_recherche Stage. On peut en effet lire dans longlet Properties de ce dernier lment que sa rfrence une classe persisante pointe vers la Classe_persistante Stage. Utilisons le mme mode de lecture pour voir que llment Espace_de_recherche Stage est li, par sa rfrence nomme Composantidentifiant, quelques lments de ce type, ici les lments Attribut Id_STG, Attribut Sujet, Attribut Debut, Attribut Fin et dautres encore. Un coup dil au mtaMDC nous indique quen effet, il existe une association entre la mtaclasse Espace_de_recherche et la mtaclasse Composant_identifiant, et que les multiplicits permettent un lment de type Espace_de_recherche dtre reli plusieurs lments de type Composant_identifiant. Notons galement que lhritage entre la supermtaclasse Composant_identifiant et la mtaclasse fille Attribut, permet de dire quun lment de type Attribut est aussi un lment de type Composant_identifiant, et peut ce titre tre reli un lment de type Espace_de_recherche. Prenons le cas plus complexe dune association persistante, par exemple entre la classe persistante Stage et la classe persistante Etudiant. Comme dans les cas prcdents, le concept dassociation persistante existe dans le mtaMDC sous la forme de la mtaclasse Association_persistante. Contrairement au cas prcdent cependant, il ny pas de lien dagrgation entre les mtaclasses Association_persistante et Classe_persistante, il ny a mme aucun lien direct entre les deux mtaclasses. Pour comprendre la faon dont sont modlises dans le mtamodle les associations entre les classes persistantes, il faut se reporter au package Class du mtamodle UML 2.0 et en particulier la partie qui a t reprise dans le mtaMDC. Voici concrtement la modlisation de lassociation entre les classes persistantes Stage et Etudiant.
32
Stage:Classe_persistante type Zro:Expression symbol=0 lowerValue
Etudiant:Classe_persistante type Un:Expression symbol=1 lowerValue
asso Stage Etudiant (ct Stage):Property
asso Stage Etudiant (ct Etudiant):Property memberEnd upperValue Un:Expression
memberEnd upperValue Etoile:Expression symbol=* association
association
symbol=1
asso_STG_ETUD:Association_persistante
Figure 28 - Modlisation de l'association Stage Etudiant Comme on le voit, cette association met en jeu tout la fois des lments de type Classe_persistante et Association_persistante bien sr, mais aussi de type Property et Expression. Voici la traduction de cette modlisation dans lenvironnement eclipse.
Figure 29 - Les lments impliqus dans la modlisation de lassociation Stage Etudiant Remarquez, dans les proprits de llment Association_persistante Stage Etudiant slectionn dans lditeur, la valeur de la rfrence Member_end, qui pointe vers les lments de type Property, comme indiqu la modlisation de la Figure 28 - Modlisation de l'association Stage Etudiant ci-dessus.
33
Le reste de la lecture du modle de domaine conforme au mtaMDC issu de ltude de cas de larticle se fait de la mme manire.
7.3 Extraire de lalgorithme les rgles de transformation

Nous avons jusqu prsent pu extraire de notre problme les mtamodles source et cible, et recrer un modle source conforme au mtaMDC qui traduit lexemple tudi dans larticle [1]. Une fois ces trois lments notre disposition, nous pouvons nous lancer dans la programmation en ATL de la transformation proprement dite. Pour ce faire, nous devons extraire de larticle [1] les oprations de transformation dcrites par les auteurs en langage naturel, et les traduire en ATL. 7.3.1 Algorithme gnral de traduction : Objet vers relationnel normalis_L Voici un extrait des annexes de larticle [1] o les auteurs dcrivent la suite des oprations qui permettent la transformation dun modle objet en un modle de schma relationnel respectant la normalisationL.
Donnes en entres Modle du domaine (MD) { - Diagramme de classes UML syntaxiquement correct et smantiquement satisfaisant - On utilise les classes, les associations, les multiplicits, les rles, les hirarchies de spcialisations/gnralisation, - les classes devant tre rendues persistantes sont tiquetes (toute association entre classes persistantes est persistante) } Rsultats Modle Logique Relationnel Normalis_L (MLRnL) i.e. : Structure assurant la persistance des informations du diagramme de classe UML conformment CWM { - Ensemble des tables relationnelles avec leur schma . Attributs typs . Contraintes de cls PRIMARY KEY, UNIQUE, . Valeurs NULL, et contraintes NOT NULL . Contraintes de rfrence - Traabilit entre les lments du MLRnL et ceux du MD annot } Algorithme (S = Systme / C = Concepteur) FAIRE : Construire le MDC C : - Donner des alias toutes les classes persistantes ; - Donner des alias aux associations de multiplicit suprieure zro aux deux extrmits S : Vrifier la dclaration persistante des classes, vrifier lunicit des alias TANT QUE [ Le MD nest pas compltement annot par le concepteur ] Annoter le MD { Pour une classe S : calculer et afficher lespace de recherche des composants didentifiants C : spcifier les contraintes didentifiants (strotypes <<ID>>) . Donner un nom de contrainte
34
. Donner la composition de lidentifiant en utilisant lespace de recherche calcul par le systme FinPour } S : prsenter au concepteur la liste de classes sans identifiants exportables SI le concepteur dclare avoir termin ALORS MD compltement annot FSI FTQ S : Affecte un identifiant systme chaque classe reste sans identifiant exportable FAIT : MDC construit
FAIRE : Construire le MLRnL S : Appliquer les rgles de Normalisation_L ;
Utilisation dATL
post : On dispose des premiers proto-schmas relationnels S : Appliquer lalgorithme de calcul des cls ; { - Capturer le graphe G de la relation de composition des identifiant - Grer les arcs dimportation - Dtecter les cycles lmentaires TANT QUE [ Il existe des cycles lmentaires ] - Solliciter le concepteur pour rompre le cycle - SI [ proposition correcte du concepteur ] ALORS Appliquer la proposition SINON remplacer un identifiant compos choisi sur le cycle par un identifiant systme. FSI FTQ post : Il nexiste plus de cycle lmentaire S : Prsenter au concepteur les choix didentifiants exportables C : Choisir les cls primaires parmi les identifiants exportables S : Rsoudre les identifiants imports { - Mettre G en ordre (identifiants complexes la racine et attributs comme feuilles) - Rsoudre le calcul des identifiants de proche en proche (en partant des attributs) TANT QUE [ il existe des composants non traits ] FAIRE - Choisir un identifiant I ayant comme fils uniquement des identifiants traits et/ou des attributs) ; - Traiter lidentifiant I en lui affectant comme attributs lensemble des attributs de sa descendance. FAIT S : Produire le MLRnL { - Grer les identifiants substituables et non substituables - Utiliser les noms de rle pour nommer les identifiants concerns - Lister les contraintes de cls et de dpendances de rfrences } FAIT post : le MLRnL est disponible Dans certains cas, guids par le mtier, on fragmente verticalement des tables cls quivalentes.
Figure 30 - Algorithme gnral de transformation 35
On remarque que lalgorithme nest pas intgralement automatique, et que lutilisateur est rgulirement appel prendre des dcisions. Larticulation entre les tapes automatiques et manuelles soulve des questions sur lesquelles nous reviendrons (section 8.3). Notons simplement pour le moment que la transformation prise dans son ensemble nest pas monolithique, et quelle comporte au contraire de multiples oprations de diverses nature, tantt de dialogue avec lutilisateur, tantt de calcul dun espace de recherche ou didentifiants, et finalement rarement de transformation proprement dite. On a vu par ailleurs quATL, bien que dot dune forme imprative qui le rend apte la programmation de nombreuses oprations, est par essence destin tre utilis sous sa forme dclarative ddie elle exclusivement la transformation de modles. Par l on comprend pourquoi nous avons pour linstant rserv lutilisation dATL la partie du processus pour laquelle il est le plus efficace : la construction du MLRnL partir du MDC annot par lutilisateur, tape signale au milieu de la Figure 30 - Algorithme gnral de transformation. En exploitant les indications de larticle [1] pour le traitement des diffrents lments du modle source (classes, tables, associations, gnralisations) on garantit implicitement le respect de la normalisation_L. Lautomatisation de cette construction se dcompose en trois grandes phases qui sont dtailles dans les 3 sections suivantes. 7.3.2 Identifier les lments et leurs antcdents Cette tape consiste dterminer quels lments du modle sources sont lorigine des lments crs dans le modle cible. En ralit, la rflexion se fait plutt au niveau des mtamodles. En effet, comme nous lavons prsent dans la section 6 ci-dessus, les rgles de transformation exprimes en ATL font exclusivement rfrence aux lments des mtamodles cible et source. La question de la correspondance entre ces lments se ddouble alors de la faon suivante : 1. Lors de la transformation, que devient cet lment de notre mtamodle source? 2. Quels lments du mtamodle source permettent dobtenir, par leur transformation, cet lment du mtamodle cible ? Pour les classes persistantes et de leurs attributs du modle source, nous savons pouvoir rpondre la question 1. En effet, les unes deviennent intuitivement des tables et les autres des colonnes de ces mmes tables. Les autres informations contenues dans le modle source, comme les identifiants, les associations et les gnralisations, doivent subir un traitement plus complexe qui est dcrit dans larticle [1] pour tous les cas de figure. Comme nous venons de le dire, un exemple trivial est la correspondance entre les mtaclasses Classe_persistante du mtaMDC et Table du mtamodle CWM. Il sagit l dune bijection sans ambigut, et les rponses concernant ces lments aux deux questions cidessus sont homognes : un classe persistante donne une table, et une table vient dune classe persistante (ceci nest pas tout fait exact, puisquune composante de jointure reprsente par une table dans le schma relationnel est engendr non pas par une classe persistante, mais par une association N-M). Prenons maintenant la mtaclasse Association_persistante du mtaMDC, et posons nous la premire question : que devient-elle dans la transformation ? La rponse est plus complexe que dans le cas prcdent. En effet, larticle [1] nous indique que le traitement des associations persistantes est conditionn par les multiplicits de leurs extrmits. Il faut dans certains cas crer une composante de jointure, dans dautre seulement une cl trangre, dans
36
dautre encore deux cl trangres symtriques. Cette interprtation du texte nous montre que la deuxime question pose sur la mtaclasse ForeignKey du mtamodle CWM na pas non plus de rponse unique. On peut ainsi obtenir de multiples manires une cl trangre dans notre schma relationnel, et il ny a donc plus de bijection entre une association persistante et une cl trangre. La grande varit de configurations possibles du modle source rend difficile didentifier les correspondances qui nous intressent pour programmer sa transformation. Mais ce travail danalyse a t effectu au pralable dans larticle [1], et limplmentation ne consiste donc qu ne rien oublier de tous les cas dcrits. 7.3.3 Dterminer les oprations de traduction Lidentification des correspondances entre les mta-lments sources et cibles dans tous les cas de figure nest bien entendu pas suffisante. La dfinition dune fonction ne se rsume pas celle de ses domaines de dpart et darriv. Un travail supplmentaire consiste dterminer pour chaque correspondance les calculs, tests et affectations oprer sur les lments. Notez que le langage ATL ne permet pas de modifier le modle source, qui est donc en lecture seule, et quil ne permet pas non plus de lire dans les lments cibles crs au cours dune transformation. Cest pourquoi des trois genres dopration lists ci-dessus, les calculs et les tests sopreront sur les valeurs dattributs ou de rfrences du modle source, et les affectations se feront exclusivement sur des valeurs dattributs ou de rfrence du modle cible. Ce mode de travail est cohrent avec une expression des rgles de transformation au niveau des mtamodles, puisque les attributs et les rfrences, au moment de lcriture du programme, ne sont pas connus en terme dlments dun modle dentre, mais en terme de types dlment quil sera possible de rencontrer dans un modle dentre. Par exemple, on ne peut pas dire que l on transforme la classe persistante A en la table A . Cette proposition fait rfrence la classe persistante A, qui est certes un lment dun modle de domaine valide et conforme au mtaMDC, mais qui nexiste pas ou nest pas connu au moment de lcriture de la rgle de transformation dune classe persistante en une table. Pour que la rgle soit gnrique et que la transformation dans son ensemble puisse sappliquer toutes sortes de modles, elle ne saurait rfrencer directement les lments du modle source. Pour traduire lexemple prcdent, on dira donc plutt que chaque lment de type classe persistante du modle source donne lieu la cration dun lment de type table dans le modle cible, et prend le nom de llment source . 7.3.4 Exprimer les oprations dans le langage ATL Enfin, une fois la smantique des rgles de transformation extraite en langage naturel, il sagit dexploiter les fonctionnalits du langage ATL pour en obtenir lquivalent dans notre module, ici le fichier MDC2MLRnL.atl . 7.3.5 Exemple 1, Classe_Table Reprenons lexemple de la transformation dune classe persistante en une table. Voici la rgle crite en ATL.
37
Figure 31 - Une table pour une classe, en ATL La ligne 33 donne le nom de la rgle. Le mot cl from indique le type dlment qui sera utilis comme paramtre dentre pour lexcution de cette rgle et le nom de ce paramtre dans le scope de la rgle. Ici le paramtre nomm classe prendra successivement la valeur de tous les lments de type ClassePersistante dfini dans le mtaMDC (identifi par le nom du package MDC ). Cette rgle sera excute une fois sur chaque lment de type ClassePersistante du modle source. Le mot cl to ouvre quant lui la dfinition de la liste des lments qui doivent tres crs dans le modle cible, partir de llment classe . Ici par exemple, puisque lon a une bijection simple entre les classes persistantes et les tables, on ne cre quun seul lment de type Table, dfini dans le mtamodle CWM identifi par le nom de son package MLRnL , et qui prend dans le scope de la rgle le nom de variable t. Les lignes 36 et 37 correspondent enfin laffectation des valeurs des attributs de llment cre. Lattribut name de llment t prend pour valeur la valeur de lattribut name de llment classe, et on fixe dautorit la valeur de lattribut isTemporary de llment t false. La navigation de la variable classe vers son attribut name , la ligne 36, et permise par lutilisation de la syntaxe OCL [12]. 7.3.6 Exemple 2, AssoBinaire_Cas2 Avant daborder cet exemple, reprenons son origine dans larticle. Ce cas prcis de transformation sapplique lorsque lon rencontre une association binaire (ne reliant que deux classes persistantes).
S rleS as : undefined ... : undefined mS..MS A T rleT mT..MT at : undefined ... : undefined
Figure 32 - Cas gnrique dassociation UML trait par la Normalisation_L Le cas gnrique reprsent ci-dessus est divis en plusieurs sous catgories : les cas MT >1 et MS >1, MT = 1 et MT > 1 et MS 1. La deuxime catgorie, (MT = 1), conduit quelques soient les valeurs des autres bornes des multiplicits de lassociation dune part lajout dun attribut K_T tabS, et la cration dune cl trangre qui rfrence tabT depuis tabS. La smantique de cette rgle de transformation est beaucoup plus riche que dans lexemple 1 et ncessite pour sa traduction en ATL la mise en uvre de nombreuses fonctionnalits du langage. Voici le code correspondant.
38
Figure 33 - La rgle AssoBinaire_Cas2 Comme dans lexemple 1, on retrouve les mots cls familiers rule , from et to , qui jouent le mme rle que prcdemment. Notons cependant ds prsent la suite de la spcification du type dlment que lon cherche dans le modle source (fin de ligne 88) lapparition entre parenthses dun guard . Il sagit dune expression boolenne qui si elle svalue faux, interdit lexcution de la rgle. Dans notre cas, on utilise cette fonctionnalit pour viter que la rgle AssoBinaire_Cas2 ne sapplique dautres associations persistantes que celles correspondantes au cas MT = 1 indiqu dans larticle. Voyons le dtail de ce guard, qui contient deux helpers (macros) imbriqus : le helper cas2 disponible sur llment thisModule , lui-mme faisant appel en paramtre au helper cardinalite disponible sur llment a
7.3.6.1 Le helper cardinalite
39
Figure 34 - Le helper cardinalites Comme tous les helpers quil est possible de dfinir avec ATL, celui-ci est invoqu comme nous lavons vu par son nom dfini ligne 5, ligne o lon trouve galement prcd du mot cl context le type dlment auquel ce helper peut sappliquer, et le type de la valeur renvoye, indiqu en vert comme tant une squence dentier. Les diffrents types disponibles ici et dans le reste des modules ATL sont les types primitifs dfinis dans la norme OCL. La ligne 6, laide de loprateur OCL collect , amorce le parcours de tous les lments de la collection des memberEnd de llment self . self reprsente ici le contexte dxcution du helper, c'est--dire un lment de type AssociationPersistante . Le parcours de cette collection se fait en affectant la variable u successivement les valeurs des lments de la collection. A chaque nouvelle valeur de u, on applique ensuite le code des lignes 7 12, et on renvoie les rsultats sous forme dune nouvelle collection. Ici, le but des lignes 7 12 est de convertir en entier les expressions des cardinalits de lassociation persistante self . Pour ce faire, on dclare la ligne 7 une nouvelle variable locale lv en utilisant les mots cls OCL let et in . lv , pour lowerValue, prend pour valeur une squence dun lment gal la conversion en entier ( toInteger() ) de la valeur de lattribut symbol de llment point par la rfrence lowerValue de la variable u . Pour bien comprendre cette navigation complexe, on peut se reporter la fois au mtaMDC (en particulier sa partie extraite du mtamodle dUML 2.0 la Figure 1) et lexemple de la Figure 28 - Modlisation de l'association Stage Etudiant. Une deuxime partie de code (lignes 8 12) permet de prvenir le cas ou le symbole dune borne suprieur de multiplicit est une toile, auquel cas loprateur toInteger() ne peut tre utilis. Un test nous permet alors de convertir cette toile en un entier trs grand. Nous venons de le voir, lexpression du guard de la rgle AssoBinaire_Cas2 utilise le helper cardinalites . Les helpers tels que celui-ci permettent dans ATL, comme les fonctions dans dautres langages de factoriser du code rutilisable. Lcriture dun helper pour obtenir les cardinalits dune association nous a simplement permis la rutilisation de son code pour le calcul de la variable local index dfinie plus loin.
7.3.6.2 Le helper cas2
Figure 35 - Le helper cas2 Dans lexpression du guard de la Figure 33, on trouve galement un appel au helper cas2 , partir de llment thisModule . Ce dernier lment reprsente dans ATL le module en cours dexcution, et permet daccder aux helpers particuliers dont la dfinition ninclue pas de contexte. Cest prcisment le cas de cas2 . Par ailleurs, une diffrence importante entre les helpers cardinalites et cas2 est la spcification dans la signature de ce dernier de paramtres. Il sagit ici dun paramtre c qui est une squence de squences dentiers. La dfinition du type de ce paramtre est homogne avec celle du type de retour du helper cardinalites , et nous avons ainsi pu les chaner dans la dfinition du guard de la 40
rgle AssoBinaire_Cas2 . Le code du helper cas2 , en ligne 21, permet simplement de vrifier que nous sommes bien dans un cas o dune part lassociation dont sont extraites les multiplicits est bien binaire ( c->size() = 2 ) et dautre au moins une des bornes suprieures des multiplicits des extrmits de lassociation persistante est bien gale 1 ( reste de la ligne). Autre nouveaut dans lexpression de cette rgle, un nouveau mot cl using ajout ligne 89 permet simplement douvrir un espace de dfinition de variables locales. Ici par exemple, quatre variables sont dfinies : index, de type entier, utilis uniquement comme outil de calcul pour dterminer dans les lignes suivantes (96 et 97) quelles sont effectivement les classes S et T de la Figure 32 - Cas gnrique dassociation UML trait par la Normalisation_L. Le calcul de la valeur de cet index repose sur le test de la ligne 91, qui lui-mme fait appel, travers le mot cl cardinalites au helper ( la macro) du mme nom. Ce helper a dj t dcrit, rappelons simplement quil permet dobtenir, partir dun lment de type AssociationPersistante reliant deux classes persistantes (ici identifi par la variable nomme a), la squence des couples de bornes de multiplicits de chaque extrmits de lassociation : { { lowerValue extrmit 1 ; upperValue extrmit 1 } ; { lowerValue extrmit 2 ; upperValue extrmit } }. La partie gauche du test dgalit renvoie donc la dernire valeur du premier couple prit dans cette squence de multiplicits. Si cette valeur est 1, on affecte la valeur 1 la variable entire index, sinon, index vaut 0. classeT, de type ClassePersistante, qui rfrence llment du modle source correspondant la classe T de la Figure 32 - Cas gnrique dassociation UML trait par la Normalisation_L. Ce rsultat est obtenu en utilisant la variable index dfinie juste au-dessus, et la navigation OCL. Ligne 96 par exemple, la partie gauche de lassociation utilise la rfrence memberEnd de llment a pour accder la collection des extrmits de lassociation persistante a. De cette collection, loprateur OCL at() permet dextraire llment la position calcule par 2 index . Si lon suit la structure du mtaMDC, on sait obtenir alors un lment de type Property. Depuis ce dernier lment on peut enfin accder par sa rfrence type la classe persistante qui nous intresse. A nouveau, on peut se reporter lexemple de la Figure 28 - Modlisation de l'association Stage Etudiant. classeS, de type ClassePersistante, qui rfrence de la mme faon que prcdemment llment du modle source correspondant la classe S de la Figure 32 - Cas gnrique dassociation UML trait par la Normalisation_L. symboleT, de type chane de caractre, qui rfrence lattribut name de llment de type SymboleIDExportable point par la rfrence symboleidexportable de la variable locale classeT. Cette dernire longue navigation est nouveau possible grce lutilisation du langage OCL. Ces quatre variables locales sont ensuite accessibles lintrieur de la ou des clauses to qui suivent le bloc using . Dans notre cas, leur utilisation permet de rendre plus lisible le code de la transformation, en remplaant des expressions OCL complexes par un simple nom au sens intuitif.
41
7.3.6.3 Dfinition de multiples lments dans la clause to
Comme nous lavons vu en dbut de section 7.3.6, la prsence dans le modle source dune association persistante binaire avec les multiplicits indiques donne lieu la cration dans le modle cible de deux lments simultanment, la fois un attribut de type colonne llment correspondant la table tabS de lexemple gnrique de la Figure 32 - Cas gnrique dassociation UML trait par la Normalisation_L, mais aussi la gnration dune cl trangre rfrenant tabT depuis tabS . La clause to de la rgle visible en Figure 33 - La rgle AssoBinaire_Cas2, possde pour cette raison deux parties. Voici la premire :
Figure 36 - Premir lment gnr par la clause "to" Dans un premier temps, on gnre naturellement un lment c de type Column. Pour fixer lappartenance de cette nouvelle colonne la table S, on affecte la rfrence columnset de llment c la variable locale classeS . On voit ici que comme indiqu prcdemment (section 7.3.3), laffectation de la rfrence columnset nutilise pas la valeur dun lment du modle cible, mais bien celle dun lment du modle source ( classeS ). La ligne 104, quant elle, utilise le helper nomCol disponible dans le contexte gnral du module, pour gnrer un nom de colonne explicite pour la cl trangre dans tabS partir des deux classes lies pas lassociation a , et du nom de la rgle. Dans un deuxime temps, nous crons, au-del de la nouvelle colonne dans tabS , llment de type ForeignKey qui incarne la cl trangre liant cette nouvelle colonne et la cl primaire de tabT . Cest la deuxime partie de la clause to :
Figure 37 - la deuxime partie de la clause "to" La ligne 107 cre llment fk , de type ForeignKey proprement dit. Il faut se reporter au mtamodle CWM pour bien comprendre comment est modlise une cl trangre. Disons simplement que ses deux rfrences essentielles sont dune part uniqueKey , qui doit pointer vers la cl unique (une cl primaire tant une cl unique) que cette cl trangre rfrence, et dautre part feature qui indique la ou les colonnes qui constituent, dans la table qui contient la cl trangre, le corps de la cl. Cest ces deux rfrences importantes qui sont tablies aux lignes 109 et 110 du code de la Figure 37 - la deuxime partie de la clause "to". La premire, ligne 109, est un peu particulire. Il sagit l comme nous venons de le dire de faire pointer la rfrence uniqueKey de la nouvelle cl trangre fk frachement 42
cre vers la cl primaire de la table tabT , elle-mme rsultat de la transformation de la classe classeT . Or, comme nous lavons dj mentionn, le langage ATL ne permet pas dutiliser dans les affectations des valeurs des lments du modle cible des valeurs dautres lments du modle cible. Pour raliser tout de mme cette affectation, il faut pour dsigner un lment du modle cible utiliser sont antcdant dans le modle source. Cest ce que nous faisons ici, avec une subtilit supplmentaire. Les lments de types PrimaryKey qui apparaissent dans le modle cible sont gnrs partir des lments de type SymboleIDExportable du modle source, par la rgle ci-dessous.
Figure 38 - Rgle de gnration des cls primaires Dans cette autre rgle, on voit cependant que les lments de type PrimaryKey sont crs (ligne 61) parmi dautres lments (lignes 56 et 67). Pour que dans le code de la figure 35 la machine affecte bien la rfrence uniqueKey le sous-ensemble de type PrimaryKey gnr par la rgle de la figure 36, on utilise loprateur ATL resolveTemp(), qui permet de prciser avec ses deux paramtre (<nom_de_rgle>, <nom_lment_cible>), llment prcis du modle cible dont on souhaite obtenir la valeur. Dans larticle [1] le traitement des associations binaires est bien plus complet et prvoit une multitude de stratgies en fonction de chaque cas particulier des multiplicits non seulement des associations mais galement des attributs qui constituent leurs extrmits. Cest la richesse des ces stratgies qui incarnent dans le code les concepts de la forme normale allge, ou normalisation_L. Tous ces cas ne sont pas encore traits par le code ATL complet fourni en annexe (section 11.1). Ltude de lexemple de la section 7.3.6 fourni cependant les cls pour comprendre comment les cas qui restent traiter pourraient tre programms.
7.4 Contrler, complter, corriger

La correction syntaxique du code est vrifie au moment de la compilation directement par la plateforme eclipse. Sa validit smantique est quant elle plutt vrifie en contrlant la conformit du rsultat obtenu aprs la transformation automatique.
43
Comme nous lavons expliqu, une transformation ATL produit un modle cible au format xmi. Ce nouveau modle est donc interprtable par lditeur du plugin EMF. Voici cidessous un court extrait du modle cible, stock dans le fichier tables.ecore , o nous trouvons entre autre llment Stage de type Table . Lutilisation de lditeur et de son onglet Properties permet ainsi de contrler non seulement la prsence des lments attendus dans le modle cible, tels que les tables, les colonnes, les cls, mais galement la valeur des attributs et des rfrences de ces lments.
Figure 39 - Extrait du rsultat de la transformation de la classe Stage
8 Conclusions lissu de lexprimentation

8.1 Les avantage dATL
Au moment de la rdaction de ces lignes, le bilan quant lutilisation du langage ATL pour aborder notre problme est positif. Aprs une prise en main du langage et des concepts qui lentourent, ATL a pleinement rvl son adquation avec notre besoin de transformer les modles qui nous intressent, et aucun verrou technique ne laisse prsager de difficult exprimer dans une transformation automatique toute la smantique dtaille dans larticle [1]. Comme il a dj t voqu, plus que sur le codage, le travail du programmeur portera sans doute sur un patient dialogue avec les concepteurs du processus de transformation pour prcisment spcifier les mtamodles sources et cibles de la transformation, qui devront tre assez complets et prcis pour permettre dexprimer lensemble des concepts utiliss dans les deux mondes de modlisation.
44
8.2 Inconvnients dATL

Au stade actuel de son dveloppement, ATL souffre cependant dune mise en uvre fastidieuse, en tout cas sur le plan des outils techniques utiliser pour sa programmation. Son intgration sous forme de plugin dans la plateforme eclipse oblige en effet le programmeur procder linstallation de plusieurs lments de sources diverses, dont les versions voluent de manire permanente et souvent incompatibles les unes avec les autres. Ainsi, trouver un instant t une combinaison des version de ces lments qui permettent dobtenir un environnement de dveloppement la fois fonctionnel, robuste et permettant de profiter de toutes les fonctionnalits de dveloppement peut parfois relever de la gageure. La situation a cependant tendance sarranger avec le souci des dveloppeurs Nantais du langage de livrer des bundle complets, intgrant dans un seul paquet dinstallation tous les lments ncessaires et compatibles entre eux. Un de ces bundle est dj disponible [13], mais pour linstant exclusivement pour le systme dexploitation Microsoft Windows.
8.3 Une ou plusieurs transformations ?

La pratique du langage ATL nous a appris quau-del de son extrme adaptation la transformation de modle proprement dite, il peut galement satteler des tches de calculs qui sortent lgrement de ce cadre. Nous avons ainsi pu implmenter un programme ATL qui plutt que de transformer un modle en un autre se contente de calculer la valeur de certaines rfrences du modle source, valeurs qui se dduisent en ralits dautres lments et rfrences de ce mme modle source et qui nont donc pas lieu dtre spcifies la main par le concepteur. Ce module ATL est indiqu en annexe 11.2, et consiste en le calcul pour chaque classe persistante du modle source de son espace de recherche. Cette notion despace de recherche est dtaille dans larticle [1]. Cette nouvelle transformation, ou plus exactement ce calcul, peut tre effectu au pralable sur un modle de domaine dentre o les espaces de recherches nont pas ts encore dtermins, et le modle rsultant de ces calculs peut tre utilis comme nouveau modle de domaine complet pour la transformation proprement dite vers un modle CWM. Nous voyons alors clairement se profiler la notion de chanage des transformations. 8.3.1 Chanage de transformations Nous venons de le voir, dans le cas de lutilisation datl pour certains calculs, la transformation globale dun modle nest plus atomique mais une suite de transformations et de calculs. Bien quil existe des outils pour mettre en place ces chanes sous forme de tche Ant, nous navons pas ce jour expriment cette faon de procder. 8.3.2 Cration de plusieurs mtamodles intermdiaires Utiliser une chane de transformations pour raliser nos objectifs a par ailleurs un impact notable sur la faon de grer les concepts manipuls dans les mtamodles sources et cibles. En effet, qui dit plusieurs transformations dit autant de couples de mtamodles cibles et sources diffrents (bien que dans certains cas purement calculatoire, ATL nous permette dutiliser le mme mtamodle source et cible). Dans ce cas, il sera certainement pertinent de ne conserver dans les mtamodles intermdiaires de la chane des transformations que les
45
mtaclasses strictement ncessaires lexpression des concepts manipuls ce moment l. Cela aboutira la cration de multiples mtamodles, dont les mutations tout au long du processus de transformations accompagneront les changements de domaines de modlisation.
9 Travaux futurs
9.1 Dlimiter lintervention dATL dans le processus
Les considrations prcdentes relatives au chanage des transformations nous ont permit danticiper lapparition dune tentation peut-tre contre-productive dans lutilisation dATL. En effet, la puissance du langage lui permet dexcuter des oprations pour lesquels il nest malgr tout pas fait. Cest le cas par exemple du calcul des espaces de recherches des classes persistantes. Certes, le code fourni en annexe montre que limplmentation en ATL dune telle tche est possible, mais est-ce vraiment performant ? Ce calcul ne peut-il pas valablement tre opr plus facilement dans dautres langages plus adapts. Nous navons pas de rponse cette question pour le moment, mais peut-tre faudra-t-il tre attentif, lors de llaboration dun processus complet de traduction, bien prciser le domaine dintervention du langage ATL, en le limitant au maximum aux tapes o il est bien le plus adapt.
9.2 Terminer lvolution du mtaMDC

La rflexion sur la dcomposition ou le chanage des transformations induira ncessairement comme nous lavons dj dit une refonte plus ou moins importante des mtamodles utiliss, quils soient 2 ou plus. Aujourdhui, ltat davancement de nos travaux na pas cr le besoin de plus des deux mtamodles que sont le mtaMDC et le mtamodle de CWM. Toutefois, la rflexion continue quant loptimisation du mtaMDC pour reprsenter encore plus prcisment et simplement les concepts utiliss dans le processus de transformatio. La pratique nous a montr que la prcision et la concision du mtaMDC a trs souvent men une simplification de lexpression et de la lisibilit des rgles de transformation, et par voie de consquence une plus grande aisance dans la vrification de leur smantique. Ce travail de mtamodlisation est donc fondamental et mrite encore aujourdhui sans doute quelques efforts.
9.3 Terminer lextraction de rgles de lalgorithme

Cette exprimentation dATL a abouti la cration dun module o quelques rgles de transformation sont codes. Bien que fonctionnelles, ces rgles sont cependant incompltes par rapport lensemble des cas de figure traits dans larticle. Bien quaucun verrou technique ne soit en vue, et quil nous semble quATL soit mme de traiter tous les cas, il reste encore beaucoup faire pour compltement extraire de cet article toute la smantique de transformation et limplmenter concrtement et toffant le module dj existant.
46
9.4 Explorer les possibilits dinterfaage

A terme, on sait que le but du processus de conception est destin permettre un utilisateur humain de matriser toute la chane de conception dune base de donne. Au-del de la transformation de modle, ce long processus sera aussi jalonn de nombreuses tapes de modlisation proprement dite et dannotation. Ces tapes ne sauraient avoir lieu dans de bonnes conditions sans le recours des interfaces graphiques ergonomiques permettant lutilisateur dentrer ses choix, ses besoins dans le systme. Les possibilits dinterfaage graphique dATL ou plus largement les conditions darticulation dATL avec dautres technologies seront des lments dterminants pour la ralisation dun outil complet et performant conforme aux attentes des auteurs de larticle [1].
10 Conclusion
Lobjectif de ce travail tait de dterminer ladquation entre lutilisation du langage de transformation de modle ATL et le besoin dimplmentation dun processus de traduction dun modle UML en un modle CWM exprim par les auteurs dans leur article [1]. A travers lexprience mene ici, on a pu apporter plusieurs rponses. Premirement, le langage ATL sadapte trs bien une partie du besoin (la transformation proprement dite), le principal effort de mise en uvre tant une dfinition claire et prcise des mtamodles source et cible utiliss dans la transformation. Deuximement, on a montr que les oprations amont et aval de calcul pourraient tre ralises avec le mme langage. Cependant, dune part la performance relative de ce langage par rapport dautres pour la ralisation de ces mmes tches na pas t teste, et dautre part, lutilisation systmatique dATL conduirait llaboration dun enchanement de transformations. Enfin, la documentation dATL et un dialogue avec ses dveloppeurs nous donnent penser quil faudra articuler ce langage avec dautres outils pour amliorer lergonomie du programme de transformation global.
47
11 Annexes
11.1 Le code complet de la transformation (module MDC2MLRnL.atl)
module MDC2MLRnL; -- Module Template create OUT : MLRnL from IN : MDC; helper context MDC!AssociationPersistante def : cardinalites : Sequence(Integer) = self.memberEnd->collect( u | let lv : Sequence(Integer) = Sequence{u.lowerValue.symbol.toInteger()} in let uv : String = u.upperValue.symbol in if uv = '*' then lv -> append(10000) else lv -> append(uv.toInteger()) endif ); --Cas MT>1 et MS>1 helper def : cas1( c : Sequence(Sequence(Integer))) : Boolean = c->size() = 2 and c.first().last() > 1 and c.last().last() > 1; --Cas MT=1 helper def : cas2( c : Sequence(Sequence(Integer))) : Boolean = c->size() = 2 and ( c.first().last() = 1 or c.last().last() = 1 ); helper def : nomCol(c:MDC!ClassePersistante,n:String,regle:String):String= c.name + '.' + n + ' (par ' + regle + ')'; helper def : nomFK(c1:MDC!ClassePersistante,c2:MDC!ClassePersistante):String= c1.name + ' rf ' + c2.name; helper def : nomPK(c1:MDC!ClassePersistante,n:String):String= c1.name + '.' + n; --Cre une table pour chaque classe persistante. rule Classe_Table { from classe : MDC!ClassePersistante to t : MLRnL!Table ( name <- classe.name, isTemporary <- false ) } --Cre une colonne pour chaque attribut, et la lie sa table contenante. rule Attribut_Column { from a : MDC!Attribut to c : MLRnL!Column ( name <- a.name, columnset <- a.proprietaire ) } --Cre une proto-colonne dans chaque table T pour son symbole d'ID Exportable rule Symbole_Column { from a : MDC!SymboleIDExportable using { classe : MDC!ClassePersistante = a.classepersistante; } to c : MLRnL!Column ( name <- thisModule.nomCol(classe,a.name,'Symbole_Column') , columnset <- classe ),
48
-- cre une cl primaire sur la proto-colonne dfinie prcdamment pk : MLRnL!PrimaryKey ( name <- thisModule.nomPK(classe,a.name), namespace_PK <- classe, feature <- c ), --Cre une proto-colonne dans chaque table importatrice, i.e qui possde un ID qui utilise cet ID Exportable. ce : distinct MLRnL!Column foreach ( id in a.id_ci ) ( name <- thisModule.nomCol(id.classepersistante,a.name,'Symbole_Column, importation') , columnset <- id.classepersistante ) } --Cre un contrainte d'unicit pour chaque ID rule ID_UC { from i : MDC!ID to u : MLRnL!UniqueConstraint ( name <- i.name, namespace_UC <- i.classepersistante,--.debug('cp'), feature <- i.expressionimplicite ) }
-- Cas MT=1 rule AssoBinaire_Cas2 { from a : MDC!AssociationPersistante ( thisModule.cas2(a.cardinalites) ) using { index : Integer = if a.cardinalites->first().last() = 1 then 1 else 0 endif; classeT : MDC!ClassePersistante = a.memberEnd->at(2 - index).type; classeS : MDC!ClassePersistante = a.memberEnd->at(1 + index).type; symboleT : String = classeT.symboleidexportable.name; } to -- proto-colonne dans la table S, avec le nom du symbole d'id exportable de la classe T c : MLRnL!Column ( columnset <- classeS, name <- thisModule.nomCol(classeS,symboleT,'AssoBinaire_Cas2') ), -- mise en relation de la cl de la table T avec le symbole de la table S, avec une cl trangre fk : MLRnL!ForeignKey ( name <- thisModule.nomFK(classeS,classeT), uniqueKey <- thisModule.resolveTemp(classeT.symboleidexportable,'pk'), feature <- c ) } --Dans le cas d'une gnralisation, on cre simplement une cl trangre dans la spcialisation rule Generalisation { from g : MDC!GeneralisationPersistante using { classeG : MDC!ClassePersistante = g.general; classeS : MDC!ClassePersistante = g.specific; symbole : String = classeG.symboleidexportable.name; --.debug('symbole'); } -- proto-colonne dans la table S, avec le nom du symbole d'id exportable de la classe G to c1 : MLRnL!Column ( columnset <- classeS, name <- thisModule.nomCol(classeS,symbole,'Generalisation') ), -- cl trangre qui associe la cl de la classe G avec le proto-atttribut de la classe S fk : MLRnL!ForeignKey ( name <- thisModule.nomFK(classeS,classeG), uniqueKey <- thisModule.resolveTemp(classeG.symboleidexportable,'pk'), feature <- c1
49
-) } -- Pour certaines associations binaires, en fonction des cardinalits, on cre des cls trangres rule AssoBinaire_Cas1 { from a : MDC!AssociationPersistante ( thisModule.cas1(a.cardinalites).debug('cas1') ) using { classeS : MDC!ClassePersistante = a.memberEnd->first().type; symboleS : String = classeS.symboleidexportable.name; classeT : MDC!ClassePersistante = a.memberEnd->last().type; symboleT : String = classeT.symboleidexportable.name; } to ta : MLRnL!Table ( name <- 'association ' + a.name.debug('asso') ), cS : MLRnL!Column ( columnset <- ta, name <- symboleS ), cT : MLRnL!Column ( columnset <- ta, name <- symboleT ), fkS : MLRnL!ForeignKey ( namespace <- classeS, uniqueKey <- thisModule.resolveTemp(classeS.symboleidexportable,'pk'), feature <- cS ), fkT : MLRnL!ForeignKey ( namespace <- classeT, uniqueKey <- thisModule.resolveTemp(classeT.symboleidexportable,'pk'), feature <- cT ), uc : MLRnL!UniqueConstraint ( name <- ta.name, namespace_UC <- ta, feature <- Sequence{cS,cT} ) } --namespace <- classeS
11.2 Le module MDC2Chemins.atl

module MDC2Chemins; -- Module Template create OUT : MDC refining IN : MDC; helper context MDC!EspaceDeRecherche def : attributs : Sequence(MDC!Attributs) = self.classepersistante.attribut; helper context MDC!EspaceDeRecherche def : symboles_classes_associees : Sequence(MDC!SymbolesIDExportables) = -- ici, on souhaite rcuprer les symboles d'id exportables de toutes les classes atteignables depuis la classe de l'espace de recherche courant -- par une association l'extrmit de laquelle la multiplicit est 1 ou 0..1 (i.e que upperValue = 1) let classe : MDC!ClassePersistante = self.classepersistante in -- ensemble des proprits qui sont membres d'une association et qui ont pour type la classe de l'espace de recherche. let proprietes_origine : Sequence(MDC!Property) = MDC!Property.allInstances()->select( p | p.type = classe ) in -- ensemble des associations dont les proprietes origine sont un membre let assos : Sequence(MDC!AssociationPersistante) = proprietes_origine->collect( p | p.association ) in
50
-- ensemble des proprits qui sont membre d'une des associations prcdentes qui ont pour multiplicit -- maximum 1, et qui n'ont pas pour type la classe dfinie en dbut de marco. let proprietes_extremite : Sequence(MDC!Property) = assos->collect( a | a.memberEnd )->flatten()->select( p | p.type <> classe )->select( p | p.upperValue.name = 'Un') in -- symboles exportables des classes qui sont type des proprits extrmits proprietes_extremite->collect( p | p.type.symboleidexportable ); helper context MDC!EspaceDeRecherche def : symboles_generalisations : Sequence(MDC!SymbolesIDExportables) = -- ici, il faut rcuprer les symboles d'id exportables de toutes les classes atteignables depuis -- la classe de l'espace de recherche courant par une gnralisation self.classepersistante.generalization->collect( g | g.general.symboleidexportable ); rule CalculEspaces { from i : MDC!EspaceDeRecherche to o : MDC!EspaceDeRecherche ( name <- i.name, classepersistante <- i.classepersistante.debug('classe'), composantidentifiant <- i.attributs->union(i.symboles_classes_associees)>union(i.symboles_generalisations).debug('symboles') ) } rule CopieEtudeDeCas { from i : MDC!EtudeDeCas to o : MDC!EtudeDeCas( nom <- i.nom, element <- i.element ) }
11.3 Description des mtaclasses du mtaMDC.

11.3.1 Classe_persistante
11.3.1.1 Gnralisations
Class de UML 2.0 Superstructure.
11.3.1.2 Description
Une classe persistante est une classe que le concepteur a spcifie comme telle. Elle est destine devenir une table dans la future base de donnes.
11.3.1.3 Attributs
Alias : String Une des exigences de lalgorithme propos ici est que tous les lments spcifis persistants reoivent lors de la conception un alias. Cet alias sera utilis comme identifiant lors de la cration des tables correspondantes dans la base de donne.
51
11.3.1.4 Associations
attribut :Attribut Chaque attribut dune classe persistante est reprsent par une instance de la classe Attribut implicitement persistante et qui deviendra une colonne dans la table rsultante. :Symb_ID_exportable Chaque classe persistante sera associe un symbole dID exportable au moment du calcul explicite des identifiants. :Espace_de_recherche Lespace de recherche dune classe C est compos didentifiants qui sont soit des attributs de C soit des symboles dID exportables dautres classes accessibles par C par un chemin de composition. :ID Chaque classe persistante posssde un ou plusieurs ID permettant leur identification unique. Lun de ces ID sera qualifi dexportable et deviendra lunique symbole dID exportable de la classe. :Chemin_de_composition Une classe persistante peut constituer lextrmit ou lorigine dun chemin de composition. Un chemin de composition est une squence dassociations dont les extrmits sont de multiplicit 1 ou 0-1 ou de gnralisation.
11.3.1.5 Contraintes
Une classe persistante possde toujours un alias dfinit par le concepteur.
11.3.2 Generalisation_persistante
Generalization de UML 2.0 Superstructure.
Une gnralisation persistante permet de rendre prenne la relation dhritage entre deux classes du MDC.
11.3.2.3 Attributs
Aucun attribut additionnel.
arc : Arc_de_composition Identifie larc de composition dont cette gnralisation est lincarnation.
52
11.3.3 Association_persistante
Association de UML 2.0 Superstructure.
Une association persistante permet de rendre prenne la relation dassociation entre deux classes du MDC.
11.3.3.3 Attributs
Aucun attribut additionnel.
arc : Arc_de_composition Identifie larc de composition dont cette gnralisation est lincarnation. 11.3.4 Attribut
Property de UML 2.0 Superstructure. Composant_identifiant du package MDC.
La classe attribut reprsente les attributs des classes persistantes
11.3.4.3 Attributs
La classe Attribut ne dfinit aucun attribut additionnel ceux hrits de ses superclasses dUML 2.0 Superstructure. On notera lutilisation systmatique de lattribut name de la classe parente NamedElement .
propritaire : Classe_persistante rfrence la classe propritaire de lattribut. id_at : ID 53
Rfrence les cls (les ID) dont cet attribut fait partie de lexpression explicite. 11.3.5 ID
Constraint de UML 2.0 Superstructure.
Les ID sont des identifiants construits par le concepteur en assemblant des attributs de la classe et/ou de symboles dID exportables dautres classes.
11.3.5.3 Attributs
La classe ID ne dfinit aucun attribut additionnel ceux hrits de ses superclasses dUML 2.0 Superstructure. On notera lutilisation systmatique de lattribut name de la classe parente NamedElement .
: Arc_de_composition Spcifie le ou les arcs de composition qui permettent datteindre le ou les symboles dID exportables qui peuvent composer lID. : Classe_persistante Rfrence la classe_persistante laquelle appartient cet ID. expression_implicite: Composant_identifiant Spcifie les composants de lidentifiant, quils soient des attributs ou des symboles dID exportables, qui dans ce dernier cas ne sont pas encore dtermins en terme dattributs. expression_explicite : Attribut Donne la composition finale exhaustive de lID exclusivement en terme dattributs, de la classe ou dautres classes.
Le nom dun ID est compos comme suit : nomIdentifiant ::= K<numro dordre>_< alias de la classe traite>
54
11.3.6 ID_exportable
ID
Pour chaque classe persistante, un unique identifiant sera choisi comme exportable parmi les ID dfinis sur la classe.
11.3.6.3 Attributs
Aucun attribut additionnel
Aucune association additionnelle
Lidentifiant choisi comme exportable devra en plus de possder une proprit dunicit, ne comporter aucun composant didentifiant qui prenne des valeurs nulles.
11.3.7 Symb_ID_exportable
Composant_identifiant du package MDC
Le symbole dID exportable est une variable temporaire qui intervient dans le calcul et lexpression des cls des tables dans le modle relationnel. Cette variable est dfinie et valorise sur les classes du MDC. Elle joue le rle dinconnue dans le systme dquations permettant de rsoudre le calcul final explicite des identifiants.
11.3.7.3 Attributs
Comme la classe ID, la classe Symb_ID_exportable fait simplement lusage de lattribut name de sa superclasse NamedElement .
55
: Classe_persistante symbole dID exportable.
Rfrence la classe persistante dont ce symbole et le
De faon presque similaire lID, le nom du symbole est contraint de la faon suivante : nomSymbole ::= K_<alias de la classe traite>
11.3.8 Composant_identifiant
Aucun hritage
Cette classe abstraite reprsente un composant utilis dans la construction des ID des classes persistantes.
11.3.8.3 Attributs
id_ci : ID Rfrence les ID dont ce composant fait partie de lexpression implicite. : Espace_de_recherche Rfrence les espaces de recherche qui contiennent ce composant. 11.3.9 Espace_de_recherche
Aucun hritage
56
Lespace de recherche de la classe considre est constitu de lensemble de ses attributs, augment des symboles didentifiant exportable des classes voisines auxquelles elle est relie par un arc de composition . Lespace de recherche dune classe C est compos didentifiants qui sont soit des attributs de C soit des symboles dID exportables dautres classes accessibles par C par un chemin de composition.
11.3.9.3 Attributs
: Classe_persistante Rfrence la classe persistante dont cet ensemble est lespace de recherche. : Composant_identifiant Spcifie les composants didentifiant qui font parti de cet espace de recherche. 11.3.10
11.3.10.1
Arc_de_composition
Gnralisations
Aucun hritage
Description
11.3.10.2
Les arcs dimportation sont de deux sortes, ceux qui proviennent dassociations et ceux qui proviennent de gnralisations. Dans le premier cas, les associations prises en compte joignent la classe considre (origine) une quelconque autre classe (extrmit), avec comme contrainte que la multiplicit de lextrmit soit (1) ou (0..1). Larc dimportation est naturellement orient de lorigine vers lextrmit. Dans le second cas, larc dimportation est orient de la spcialisation vers la gnralisation.
Attributs
11.3.10.3

Associations
11.3.10.4
gen : Generalisation_persistante Spcifie la gnralisation qui incarnation cet arc. asso : Association_persistante 57
Spcifie lassociation qui incarnation cet arc. extrmit : Classe_persistante Rfrence la classe persistante extrmit de larc de composition. origine : Classe_persistante Rfrence la classe persistante de dpart du arc de composition, autrement dit la classe persistante laquelle appartient cet arc. : ID Spcifie le ou les ID dont un composant didentifiant est accd par ce chemin de composition
Une classe persistante ne peut pas tre la fois extrmit et origine dun chemin de composition. Un arc de composition ne peut tre incarn que par une association persistante ou une gnralisation persistante, exclusivement.
58
12 Ressources Internet et bibliographiques
1 Gnrer un modle relationnel normalis partir de diagrammes de classes UML, M.C. Lafaye, J.Y. Lafaye, G. Louis, 2006. 2 ATLAS (ATLantic dAta Systems), http://www.sciences.univ-nantes.fr/lina/ATLAS/ 3 Mise en oeuvre de lapproche MDA pour la conception de bases de donnes normalises-L, Sabirou Touri, 2004
.d ]rC.dl=gZ_fJ ]r.ntl .X..l=.Kntlont krtrCudl=..x_ldh.__fV ]rtrCldhJhVl=.]_m-kQ2___.)
4 Introduction aux bases de donnes (6me dition), Chris J. Date, Ed Vuibert, 1998 5 UML http://www.uml.org/ 6 UML Superstrucutre, http://www.omg.org/cgi-bin/doc?formal/05-07-04 7 CWM http://www.omg.org/technology/cwm/ 8 MDA Guide Version 1.0.1 http://www.omg.org/docs/omg/03-06-01.pdf 9 MOF/QVT http://www.omg.org/cgi-bin/apps/doc?ptc/05-11-01.pdf 10 Le forum de discussion sur ATL : http://groups.yahoo.com/group/atl_discussion/ 11 Le zoo des transformation ATL : http://www.eclipse.org/gmt/atl/atlTransformations/ 12 La specification officielle du langage OCL version 2.0 : http://www.omg.org/docs/formal/06-05-01.pdf 13 Le bundle ATL pour Windows: http://www.sciences.univ-nantes.fr/lina/atl/atldemo/adt/
59

RapportAntoine 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RapportAntoine 4

Uploaded by

Copyright:

Available Formats

Approche MDA pour la transformation dun diagramme de classes conforme UML 2.0 en un schma relationnel conforme CWM et normalis_L.

Rapport de Stage de fin de Master, Juin 2006.

Jean-Yves et Marie-Christine Lafaye, Georges Louis

Table des matires

Table des figures

2 Gnrer un modle relationnel normalis partir de diagrammes de classes UML [1]

2.1 Introduction dune nouvelle forme normale : la normalisation_L

3.2 UML 2.0

<<metaclass>> Generalization * generalization

<<metaclass>> NamedElement name : string

1 specific 1 general <<metaclass>> Classifier

lowerValue 1 1 upperValue <<metaclass>> ValueSpecification 0..1 specification

* ownedAttribute <<metaclass>> Property

3.3 OCL 2.0

ObjectM odel::Core Feature * feature ModelElement ownedElement *

Foundation::Keys and Indexes UniqueKey * 1 uniqueKey * /ownedElement

0..1 /namespace Class 0..1/namespace

0..1/namespace Table 1 /namespace 0..1 /namespace

4 La gnration dun modle relationnel vue comme une transformation de modle.

5 Lingnierie dirige par les modles, ou Model-driven Architecture (MDA)

6.1 Lopration lmentaire de transformation : la rgle ATL

Figure 10 -Vue densemble dune transformation ATL

6.2 Utilisation dATL

6.2.1 Spcification des mtamodles

Voici un extrait du fichier MDC.km3 et plus particulirement du package UML20.

Figure 12 - Injection du fichier km3 dans le format xmi conforme Ecore

Figure 14 - Le fichier MDC.ecore affich par lditeur EMF

Figure 19 - Le menu contextuel New Sibling

Figure 20 - Extrait du code transformation du module ATL 24

6.3 Des exemples de cas dutilisation dATL

Figure 21 - L'exemple de transformation Class2Relational

7.1 Un exemple de modle de domaine

<<persistent_class>> Enseignant {Alias(ENS)}

<<persistent_class>> Etudiant {Alias(ETUD)} 1 Numro : undefined

K1_STG <<ID>> {Id_STG}

K2_STG <<ID>> {K_ETUD, Dbut}

<<persistent_class>> Soutenance {Alias(SOUT)} Date : undefined Salle : undefined

7.2 Accoucher les mtamodles

Figure 23 - Extrait du fichier MLRnL.km3 dit dans la plateforme eclipse

7.2.2.1 Chercher quoi le modle de domaine fourni en exemple est conforme.

Symb_ID_exportable 1 /Nom : string

Arc_de_composition * 1..* * ID * id_ci expression implicite 1..* * {disjoin}

Stage:Classe_persistante type Zro:Expression symbol=0 lowerValue

Etudiant:Classe_persistante type Un:Expression symbol=1 lowerValue

asso Stage Etudiant (ct Stage):Property

asso Stage Etudiant (ct Etudiant):Property memberEnd upperValue Un:Expression

memberEnd upperValue Etoile:Expression symbol=* association

7.3 Extraire de lalgorithme les rgles de transformation

FAIRE : Construire le MLRnL S : Appliquer les rgles de Normalisation_L ;

Figure 30 - Algorithme gnral de transformation 35

7.3.6.3 Dfinition de multiples lments dans la clause to

7.4 Contrler, complter, corriger

Figure 39 - Extrait du rsultat de la transformation de la classe Stage

8 Conclusions lissu de lexprimentation

8.2 Inconvnients dATL

8.3 Une ou plusieurs transformations ?

9.2 Terminer lvolution du mtaMDC

9.3 Terminer lextraction de rgles de lalgorithme

9.4 Explorer les possibilits dinterfaage

11.2 Le module MDC2Chemins.atl

11.3 Description des mtaclasses du mtaMDC.

Class de UML 2.0 Superstructure.

Une classe persistante possde toujours un alias dfinit par le concepteur.