Approche MDA pour la transformation d un diagramme de classes conforme UML 2.0 en un schéma relationnel conforme CWM et normalisé_l.

Transcription

1 Approche MDA pour la transformation d un diagramme de classes conforme UML 2.0 en un schéma relationnel conforme CWM et normalisé_l. Expérimenter le langage ATL dédié à la transformation de modèle pour l implémentation d une méthode de transformation d un diagramme UML en un schéma CWM. Rapport de Stage de fin de Master, Juin Etudiant : Antoine Wiedemann Etudiant en Master 2ème année mention Informatique, Mathématique et leurs Applications, option recherche Image et Calculs à l Université de La Rochelle. Encadrants : Jean-Yves et Marie-Christine Lafaye, Georges Louis Professeurs à l Université de La Rochelle

2

3 Table des matières 1 Introduction Générer un modèle relationnel normalisé à partir de diagrammes de classes UML [1] Introduction d une nouvelle forme normale : la normalisation_l Normalisation en conception de base de données [] Les premières règles de normalisation Normalisation allégée (Normalisation_L), présentée dans l article de M.C. Mafaye, J.Y. Lafaye et G. Louis [1] Quelques définitions Modèle UML OCL CWM Metamodèle MOF La génération d un modèle relationnel vue comme une transformation de modèle L ingénierie dirigée par les modèles, ou Model-driven Architecture (MDA) MDA QVT ATL L opération élémentaire de transformation : la règle ATL Utilisation d ATL Spécification des métamodèles Spécification des modèles Le module ATL Des exemples de cas d utilisation d ATL Implémentation Un exemple de modèle de domaine Accoucher les métamodèles Spécifier le métamodèle cible : le métamodèle de CWM Spécifier le métamodèle source, le métamodèle de domaine ou encore le métamdc Résultat : le métamdc Construire un exemple de modèle conforme Extraire de l algorithme les règles de transformation Algorithme général de traduction : Objet vers relationnel normalisé_l Identifier les éléments et leurs antécédents Déterminer les opérations de traduction Exprimer les opérations dans le langage ATL Exemple 1, Classe_Table Exemple 2, AssoBinaire_Cas Contrôler, compléter, corriger Conclusions à l issu de l expérimentation Les avantage d ATL... 44

4 8.2 Inconvénients d ATL Une ou plusieurs transformations? Chaînage de transformations Création de plusieurs métamodèles intermédiaires Travaux futurs Délimiter l intervention d ATL dans le processus Terminer l évolution du métamdc Terminer l extraction de règles de l algorithme Explorer les possibilités d interfaçage Conclusion Annexes Le code complet de la transformation (module MDC2MLRnL.atl) Le module MDC2Chemins.atl Description des métaclasses du métamdc Classe_persistante Generalisation_persistante Association_persistante Attribut ID ID_exportable Symb_ID_exportable Composant_identifiant Espace_de_recherche Arc_de_composition Ressources Internet et bibliographiques... 59

5 Table des figures Figure 1 - Extrait du métamodèle UML Figure 2 - Extrait du métamodèle de CWM... 8 Figure 3 - Exemple de trois classes d un modèle dont deux sont conformes à leur métaclasse dans le métamodèle... 9 Figure 4 -L architecture 4-niveaux définie par l OMG Figure 5 -L architecture de métadonnées de l OMG Figure 6 - La transformation d'un modèle Figure 7 - Logo MDA Figure 8 - Vue générale d une transformation d un PIM en PSM Figure 9 - Un exemple de règle ATL Figure 10 -Vue d ensemble d une transformation ATL Figure 11 -Extrait d un fichier de définition du métamodèle UML 2.0 au format km Figure 13 - «Injection» du fichier km3 dans le format xmi conforme Ecore Figure 14 -Extrait d un fichier de définition du métamodèle UML 2.0 au format xmi Figure 15 - Le fichier MDC.ecore affiché par l éditeur EMF Figure 16 -Exemple de départ de définition d une classe, dans un fichier ecore au format xmi Figure 17 - Un onglet «Properties» permet d accéder aux propriétés de la classe Class Figure 18 - Le mot clé container permet de refléter une aggregation UML Figure 19 -Le menu contextuel «New Child» Figure 20 - Le menu contextuel «New Sibling» Figure 21 - Extrait du code transformation du module ATL Figure 22 - L'exemple de transformation Class2Relational Figure 23 - Exemple de modèle de domaine annoté utilisé dans l article [1] Figure 24 - Extrait du fichier MLRnL.km3 édité dans la plateforme eclipse Figure 25 - Résultat de «l injection» du fichier km Figure 26 - Notre métamodèle de domaine construit sur UML Figure 27 - La classe Stage Figure 28 - Détail de l espace de recherche de la classe Stage Figure 29 - Modélisation de l'association Stage Etudiant Figure 30 - Les éléments impliqués dans la modélisation de l association Stage Etudiant Figure 31 - Algorithme général de transformation Figure 32 - Une table pour une classe, en ATL Figure 33 - Cas générique d association UML traité par la Normalisation_L Figure 34 - La règle AssoBinaire_Cas Figure 35 - Le helper cardinalites Figure 36 - Le helper cas Figure 37 - Premièr élément généré par la clause "to" Figure 38 - la deuxième partie de la clause "to" Figure 39 - Règle de génération des clés primaires Figure 40 - Extrait du résultat de la transformation de la classe Stage... 44

6 1 Introduction Le problème de la génération automatique de base de données à partir d un diagramme de classe a déjà été largement étudié et enseigné sur le plan théorique. Souvent, on se contente d étudier les différents cas de figure qui peuvent se présenter en terme de multiplicités des associations entre classes, et de déterminer dans chaque cas le schéma relationnel adapté pour implanter ces associations. En pratique pourtant, le procédé se révèle bien plus complexe dès lors que l on aborde des cas concrets et que l on se donne des exigences sur la qualité de la base de données résultante. Que ce soit sur le plan du processus de normalisation, de la conservation des connaissances métier injectées par le concepteur tout au long du processus de génération, et/ou plus concrètement de l ergonomie des outils disponibles sur le marché, beaucoup reste à faire. Ainsi, pour aller plus loin dans la précision et la correction sans perdre de vue la simplicité d utilisation, M.C. Lafaye, J.Y. Lafaye et G. Louis (ci-après nommés les auteurs) proposent dans leur article «Générer un modèle relationnel normalisé à partir de diagrammes de classes UML» [1] un processus complet qui en plus d adresser les problèmes identifiés plus haut, tire partie d une nouvelle approche pleine de promesse dans l univers du génie logiciel : l ingénierie dirigée par les modèles (MDA en anglais). Pour valider les avantages de ce processus et de la méthode qu il incarne, il a été choisi de tenter une partie de son implémentation dans le langage ATL spécialement conçu pour la transformation de modèles. Ce langage est développé dans le cadre du projet ATLAS [2] mené à l université de Nantes par une équipe de chercheurs de l INRIA. Le travail présenté ici est une expérimentation et une évaluation de l utilisation d ATL pour réaliser cette implémentation. 1

7 2 Générer un modèle relationnel normalisé à partir de diagrammes de classes UML [1] Dans l article cité en titre de cette section, les auteurs se sont attaqués à un problème finalement bien commun et déjà largement traité aussi bien sur le plan théorique dans les ouvrages pédagogiques que sur le plan pratique dans plusieurs ateliers de génie logiciel (ou CASE Tools). Cependant, leurs précédents travaux [3] ont montré à travers trois exemples que l utilisation de certains outils à disposition produit des résultats largement perfectibles. Premièrement, les règles de la normalisation ne sont pas respectées, aboutissant à des calculs de clés erronées ou manquantes. Deuxièmement, au stade de la conception, il est parfois difficile d identifier les objets aussi finement que ce que le modèle relationnel est capable de restituer, et à l inverse, certaines identifications inutiles et fastidieuses sont rendues obligatoires alors qu elles ne sont pas utilisées par la suite. Après avoir identifié ces problèmes, les auteurs se sont donnés pour but d élaborer une nouvelle méthodologie avec trois ambitions principales : produire un schéma relationnel normalisé, faciliter le travail d annotation du concepteur, et respecter autant que possible sa terminologie métier. Pour atteindre ces objectifs, les auteurs s appuient sur différentes innovations dont principalement : l introduction d une nouvelle forme normale, la forme normale allégée (appelée normalisation_l), définie par leurs soins comme un relâchement contrôlé de certaines contraintes de la normalisation classique, et l utilisation de la récente approche MDA particulièrement adaptée à la transformation de modèle et dont nous utilisons les concepts ici. 2.1 Introduction d une nouvelle forme normale : la normalisation_l Normalisation en conception de base de données [4]. La qualité d une base de donnée évoquée en introduction est très liée à la minimisation de la redondance. D une manière générale, la théorie de la normalisation utilise des dépendances parmi lesquelles les dépendances fonctionnelles, les dépendances multi-valuées et les dépendances de jointure pour construire une structure de données à redondance minimale. Rappelons la définition d une dépendance fonctionnelle en base de données : Dans une relation, un sous-ensemble Y d attributs de R est en dépendance fonctionnelle avec un sous-ensemble X d attributs 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é déterminant. Plusieurs niveaux de normalisation sont caractérisés : 1FN, 2FN, 3FN, BCNF, 4FN, 5FN Les premières règles de normalisation Première forme normale Une relation est en première forme normale si et seulement si tout attribut de cette relation est atomique, c'est-à-dire qu un attribut n est composé que d une valeur significative à la fois (par opposition à une adresse complexe, par exemple) et monovalué. 2

8 Deuxième forme normale Une relation est en deuxième forme normale si et seulement si elle est en première forme normale, qu elle n a qu une seule clé, et que tout attribut n'appartenant pas à la clé ne dépend pas d'une partie de cette clé. Troisième forme normale Une relation est en troisième forme normale si et seulement si elle est en deuxième forme normale et si chaque attribut non clé est en dépendance 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 déterminants sont des clés candidates. Quatrième et cinquième formes normales. Pour traiter les cas plus complexes ou apparaissent des association n-m entre les relations du schéma relationnel, la théorie de la normalisation introduit, au-delà des simples dépendances fonctionnelles qui sont utilisés dans les énoncés de ces premières formes normales, les notions de dépendances multi-valuées et de composantes de jointure (ou dépendance de jointure). L étude de ces notions sort du cadre du présent travail. Elles sont simplement mentionnées ici puisqu elles font partie de l arsenal des outils qui ont étés utilisés par les auteurs du processus pour garantir sa qualité. L application de ces principes permet une amélioration considérable de la qualité de la base obtenue à partir du schéma ainsi normalisé. Elle facilite le respect des contraintes d intégrité imposées lors de la conception en évitant la redondance des données et donc en rendant les mises à jour plus aisées Normalisation allégée (Normalisation_L), présentée dans l article de M.C. Mafaye, J.Y. Lafaye et G. Louis [1]. Comme nous l avons vu dans la section précédente, la théorie de la normalisation généralement admise aujourd hui, et qui par son application en conception de base de données est un gage de qualité, énonce un certain nombre de principes, qui conduisent à la modification de la structure d un schéma relationnel initial. Cependant, l application stricte de la normalisation conduit dans certains cas à la création de tables supplémentaires, qui ne font que satisfaire au principe de conservation des dépendances. C est pourquoi dans leur article [1], les auteurs s autorisent quelques entorses à ces règles de normalisation, pour pouvoir les appliquer de façon plus réaliste sans introduire forcément de redondance. Cette normalisation «allégée», ou normalisation_l propose par rapport à la normalisation stricte les nuances suivantes : Les attributs à valeur NULL sont admis Les règles des premières formes normales, jusqu à la BCNF, ne sont appliquées non pas à toutes les dépendances fonctionnelles mais seulement à celles permettant de collecter l ensemble des contraintes d unicité et de référence sur les tables relationnelles. 3

9 3 Quelques définitions Il convient, avant d aller plus loin, de définir ce que l on entend ici par modèle, et également de métamodèle ainsi que l articulation entre ces concepts. 3.1 Modèle Un modèle pourrait être défini comme une représentation abstraite de quelque chose. En pratique, les modèles sont présents partout autour de nous dans la vie courante, et les exemples sont nombreux. Un plan de votre maison par exemple est le modèle à partir duquel on a construit la maison que vous habitez. Ce plan regroupe des caractéristiques de dimension que votre maison respecte (en principe). Dans le contexte de la modélisation, on dit alors que votre maison est représentée par son modèle (son plan). Un modèle peut également représenter des choses plus abstraites, comme par exemple une séquence d opérations qui s enchaînent dans le temps, ou bien alors l organisation et les interactions qui ont lieu entre les employés d une entreprise. Il est important de noter que plusieurs entités distinctes peuvent êtres représentées par un unique modèle donné. Par exemple, dans un immeuble d habitation, tous les appartements sont souvent construits à partir d un nombre limité de modèles différents (un modèle de T3, un modèle de T2, etc.). Intuitivement, les atouts de l utilisation d un modèle sont nombreux, surtout comme outil de communication. Reprenons l exemple de la maison. Le plan d une maison est le fruit d une concertation entre un architecte et le futur propriétaire, et permet de visualiser l allure générale du bâtiment. Il permet également de faire des calculs de dimension pour les matériaux utilisés lors de la construction, mais aussi de présenter le projet à la mairie pour obtenir un permis de construire. Le plan est naturellement relu par l entrepreneur et utilisé comme guide de montage pendant la construction. Enfin, lors d un éventuel recours du propriétaire qui a noté une non conformité de l ouvrage terminé avec le plan initial, c est le document qui fait foi et qui est présenté à une instance judiciaire. Cette notion peut s appliquer à de nombreux domaines, et en particulier celui qui nous intéresse, l informatique. Dans ce cas, le modèle reste un outil de communication, mais les acteurs ne sont plus systématiquement humains. L exemple le plus connu est la programmation, où un opérateur humain (le programmeur) écrit un modèle de comportement ou de calcul (un programme), et le transmet à travers un processus de compilation ou d interprétation au système informatique qui produit un comportement ou des calculs décrits dans le modèle initial. De la même façon que le plan de l architecte est écrit avec une syntaxe, une nomenclature et des symboles picturaux précis, de nombreux langages de programmation différents coexistent et peuvent chacun exprimer certains types de modèles de cacluls. On voit donc que même si le concept de modèle est très répandu, les langages pour les exprimer sont très variables. 3.2 UML 2.0 UML [5] (pour Unified Modeling Language) est aujourd hui le standard des langages de modélisation objet partout où cette dernière est utilisée. Ce langage est l une des spécifications centrale de l OMG, et est aujourd hui dans sa version 2.0. Il présente sur le plan 4

10 sémantique et pratique de grandes qualités d utilisation, et dans le cas présent de la conception de base de données, UML est depuis longtemps utilisé pour spécifier à un haut niveau d abstraction la structure et l articulation des données, sous forme respectivement de classes et d associations. Par ailleurs, un avantage de cette technologie, à la fois cause et conséquence de sa grande popularité, est la profusion sur le marché d outils plus ou moins ergonomiques dédiés à la création et la manipulation de diagrammes UML. C est pourquoi il a été choisi, dans l implémentation de l algorithme présenté ici, d utiliser un diagramme de classe UML comme moyen de dialogue avec le concepteur, pour capter ses exigences et ses connaissances métier. Le cadre du problème étant bien délimité, nous n utiliserons pas toute la complexité du langage UML. Nous attendons du concepteur qu il exprime des informations de type structurelles et pas dynamiques. Ainsi, parmi la multitude de types de diagrammes prédéfinis par la spécification UML [6], nous n utiliserons que le format diagramme de classes. Nous pourrons même nous satisfaire d un sous-ensemble des classes prédéfinies dans le package Kernel de la spécification de la superstructure d UML 2.0. Ces classes sont indiquées dans le diagramme ci-dessous. <<metaclass>> DirectedRelationship <<metaclass>> Relationship <<metaclass>> Element * constrainedelement <<metaclass>> Generalization * generalization <<metaclass>> Namespace <<metaclass>> NamedElement name : string <<metaclass>> PackageableElement 1 1 specific general <<metaclass>> Classifier <<metaclass>> Association 0..1 association <<metaclass>> Class 0..1 class <<metaclass>> AssociationClass 2..* memberend <<metaclass>> Type type 0..1 <<metaclass>> StructuralFeature * ownedattribute <<metaclass>> Property <<metaclass>> TypedElement * operand 0..1 expression <<metaclass>> Expression symbol : string MultiplicityElement isordered : boolean isunique : boolean lowervalue 1 1 uppervalue <<metaclass>> ValueS pecification 0..1 specification <<metaclass>> Constraint Figure 1 - Extrait du métamodèle UML 2.0 Cet ensemble de classes préexiste dans la spécification, chacune avec sa sémantique et ses caractéristiques, en terme d attributs, de multiplicités, mais aussi de lien les unes avec les autres. Elles ne sont pourtant que rarement faites pour être utilisées telles quelles, mais plutôt pour constituer les éléments de base à la construction d autres classes, plus finement définies au plus proche des besoins de l utilisateur (leur majorité est en conséquence définie comme abstraite, d où leur nom de «métaclasses»). Nous avons ainsi créé un nouvel ensemble de classes spécifiques au problème posé, soit en héritant des classes de base mentionnées dans le 5

11 diagramme précédent, soit en en définissant de nouvelle. Cet ensemble nous permet dans l algorithme de proposer au concepteur le vocabulaire nécessaire et suffisant pour exprimer ses besoins et ses souhaits, en terme de structure de données, d articulation des données et d identification. Ces métaclasses sont présentées plus loin. 3.3 OCL 2.0 OCL [12] (pour Object Constraint Language) est une autre spécification de l OMG. Cette spécification propose un langage de description de contraintes sur des modèles UML. Jusqu à la version 1.4 de ce dernier, OCL était décrit à l intérieur des spécifications d UML tant les deux sont liés. Aujourd hui dans sa version 2.0, la maturation d OCL l a amené à posséder sa propre documentation parallèle à celle d UML. OCL n est pas un langage de programmation et il ne permet pas de contrôler un flot d exécution ou d agir sur son environnement d exécution, c est seulement un langage formel suffisamment simple pour être utilisé par des non mathématiciens pour écrire des expressions devant êtres évaluées sur des modèles UML. Les expressions OCL s évaluent toujours soit en un des quatre types primitifs définis : entier, réel, chaîne de caractère et booléen, soit en un élément du modèle, soit en un groupe homogène de ces types tels que les séquences d entiers, les séquences ordonnées de booléens ou une séquence de «Property» Ces expressions peuvent ensuite êtres utilisées pour spécifier des contraintes bien sûr, mais aussi des pré ou des post-conditions d opérations ou de méthodes, ou encore simplement comme expressions de requêtes de certaines valeurs d un modèle. Pour «naviguer» dans les attributs, les références ou les méthodes d un élément E de modèle, OCL utilise le point «.», comme le fait Java par exemple (E.attribut1, E.methodeB, E.associationF). Quand un attribut est multivalué ou qu une association mène à plusieurs éléments à la fois, l évaluation de cet attribut ou de cette association renvoi une séquence, ordonnée ou non des éléments qu il référence. Pour manipuler ces séquences, OCL défini toute sortes de mots clés pour les trier, en extraire des éléments, en ajouter, les compter, etc. Enfin, OCL est défini comme un langage sans effet secondaires (side-effect free en anglais), c'est-à-dire qu il garantit que l évaluation d une requête OCL sur un modèle quelconque ne modifiera en rien le modèle en question. 3.4 CWM CWM [7], pour Common Warehouse Model, est lui aussi un langage, comme UML dont il reprend la grammaire et spécialise la sémantique. Ce langage est également une spécification adoptée par l OMG, et tente de répondre aux problèmes posés par les simples constatations suivantes. Les statistiques montrent qu en moyenne, la quantité d information stockée par une organisation donnée double tous les cinq ans. La plupart du temps, la gestion de ces données est rendue extrêmement difficile par leur surabondance, leur redondance et leur hétérogénéité. Leur stockage dans des entrepôts de données («data warehouse» en anglais) structurés est indispensable pour les rendre exploitables. Or un des aspects essentiels du stockage de données dans des entrepôts est la description de ces mêmes entrepôts, pour permettre entre autre aux applications tierce d en connaître la structure et ainsi de pouvoir y puiser l information. Cette description prend la forme de métadonnées, c'est-à-dire dans le cas général de données qui décrivent les données. Pour compliquer encore la situation, on sait qu en pratique de nombreux systèmes de stockage de données différents existent et sont utilisés. Ainsi dès lors qu un besoin d échange de données va apparaître entre deux systèmes, 6

12 le premier ne pourra se contenter d exploiter sa propre description mais aura aussi besoin de celle de l autre. On utilisera alors l échange des métadonnées décrivant les deux systèmes (interchange of warehouse metadata). C est là l intérêt du langage CWM. Il propose un standard pour l échange de ces métadonnées, mais aussi pour exprimer leur transformation, leur analyse, leur création et leur gestion. En pratique, CWM est en fait constitué d une partie du langage UML 1.4 (le package Object Model) dont tous les éléments qui ne sont pas pertinents dans les scénarii de stockage de données ont étés supprimés. Comme cela est le cas pour UML, nous ne faisons quant à nous qu une utilisation partielle de CWM, puisque nous nous contentons de la partie relationnelle et statique du langage. Notre but est en effet d aboutir à un modèle conforme CWM dédiée à la génération de code SQL pour la création des tables, attributs, clé et références décrites dans le modèle. Les classes CWM que nous utiliserons, directement ou par héritage sont les suivantes et sont donc un extrait de la spécification de l OMG. 7

13 ObjectModel::Core Foundation::Keys and Indexes Feature ModelElement * feature ownedelement * namespace * feature Namespace StructuralFeature 1..* feature * typedfeature 0..1 owner UniqueKey * 1 uniquekey keyrelationship * * keyrelationship KeyRelationship * /ownedelement * /ownedelement 1 type Classifier Package Attribute DataType Class 0..1/namespace 0..1/namespace Ressource::Relational Column * col 1..* /feature 1 ColumnSet * ForeignKey /ownedelement * /uniquekey UniqueConstraint 1..* /ownedelement NamedColumnSet Table 0..1/namespace 1/namespace 0..1 /namespace PrimaryKey /ownedelement 1 Figure 2 - Extrait du métamodèle de CWM Notez qu ici, contrairement au cas précédent d UML, nous ne nous sommes pas permis de raffiner les classes prédéfinies. Cela peut paraître trivial, mais tout l intérêt du standard CWM est qu il reste standard, et qu un diagramme exprimé dans ce langage puisse être injecté dans un outil de génération de code compatible. Une quelconque modification des classes de base de CWM compromettrait voire anéantirait cette nécessaire compatibilité. Cependant, des pistes de recherche pourraient nous amener à introduire comme pour le modèle de domaine initial des classes supplémentaires, qui hériteraient ou non des classes prédéfinies par CWM, et qui nous serviraient, lors de certaines étapes du processus et avant la production d un modèle final exclusivement conforme à CWM, à exprimer des résultats 8

14 intermédiaires où des informations nécessaires aux traitements automatiques ultérieurs sont encore présents sous forme d autre classes que celles préexistantes dans la spécification. 3.5 Metamodèle Un métamodèle est simplement une description d un langage de modélisation. Il apporte les règles syntaxiques qui permettent de l utiliser (d écrire un modèle dans ce langage) et le sens de chaque item présent dans ce langage. Par exemple, la spécification du langage Java, c'est-à-dire sa grammaire et sa sémantique, constitue le métamodèle du langage Java. Dans le contexte de la modélisation on dit qu un programme Java sans erreur syntaxique est conforme au métamodèle du langage Java. Attention, cette conformité ne garantit pas que le programme ne contient pas d erreur d exécution, ou même qu en l absence d erreur d exécution, les résultats obtenus à l issu de son exécution seront ceux attendus par le programmeur. Figure 3 - Exemple de trois classes d un modèle dont deux sont conformes à leur métaclasse dans le métamodèle Remarquons qu un métamodèle est donc par essence un modèle puisqu il correspond à la définition de représentation abstraite donnée plus haut. Par voie de conséquence, pour peu que ce métamodèle soit exprimé dans un langage prédéfini, il possède lui-même un métamétamodèle qui décrit précisément ce dernier nouveau langage. Nous voyons alors se profiler, pour un modèle donné, une hiérarchie infinie de métamodèles se décrivant les uns les autres. En pratique, cette hiérarchie n est pas infinie. Elle est d ailleurs souvent très courte, puisque nous disposons en réalité d un unique métamodèle que nous partageons tous et qui grâce à son extrême richesse nous permet de décrire tous les autres. Il s agit simplement de la langue écrite ou orale. En effet, l intérêt des langues est qu elles s auto décrivent, c'est-à-dire que l on peut les utiliser pour spécifier la façon de les utiliser. Prenez un dictionnaire de français, les définitions de chaque mot sont rédigées en français. Prenez une grammaire française, à nouveau, les règles de grammaire sont exprimées par des phrases qui utilisent et respectent ces mêmes règles. Dans le cas du langage de programmation Java par exemple, le métamodèle (disons pour simplifier sa documentation), est simplement exprimée en langue écrite, que ce soit l anglais, le français ou le danois, et il n est pas nécessaire d ajouter une nouvelle description à cette documentation. 9

15 3.6 MOF Pour permettre au langage de décrire toute chose, il faut l enrichir en permanence avec une très grande variété de syntaxes, toutes sortes de cas particuliers, une très grande souplesse et une quantité énorme de vocabulaire qui le rend difficile à traiter automatiquement. Pour palier ces problèmes et faciliter l échange de métadonnées, l OMG a spécifié un langage objet graphique restreint spécialisé dans la description de métamodèles. Il s agit du langage MOF [9] (pour Meta Object Facility). La valeur ajoutée de ce nouveau langage est qu il possède un nombre limité de «mots», ici des classes, et une syntaxe précise et invariante. Par ailleurs, et c est essentiel, comme les langues il s auto décrit. Ainsi, dans un contexte de modélisation, on sait avoir toujours à notre disposition un langage généralement admis et à la sémantique bien définie pour coiffer la hiérarchie des modèles/métamodèles. L OMG précise alors qu en pratique, la très grande majorité des cas de modélisation pourra se contenter de l utilisation de 4 niveaux au maximum comme le montre le schéma ci-dessous. Figure 4 -L architecture 4-niveaux définie par l OMG Ces niveaux prennent les nom M0 jusqu à M3, et représentent chacun un étage de la hiérarchie des modèles/métamodèles dont nous parlions précédemment. Dans l exemple précis de la figure ci-dessus, on retrouve au sommet de la hiérarchie (niveau M3) le langage MOF qui spécifie et décrit le langage du métamodèle d UML (niveau M2), lui-même définissant les éléments d un modèle UML (niveau M1) dont une des classe donne à l exécution une instance (niveau M0). 10

16 Les trois derniers langages que nous avons vu, (UML, CWM et MOF) sont donc tous trois issus des réflexions de l OMG sur les notions de modélisation et de métamodélisation. Ils ont étés écrits et réécrits pour épouser leur vision hiérarchique exposée précédemment, et font tous trois partie de leur architecture de métadonnées (OMG Metadata Architecture). Figure 5 -L architecture de métadonnées de l OMG Paraphraser ce tableau constitue un bon résumé des concepts essentiels que nous venons d exposer. Les langages de modélisation UML et CWM du niveau M1 servent à modéliser des systèmes ou des entrepôts de données au niveau M0. Ces langages sont décrits au niveau M2 par leurs métamodèles respectifs, en utilisant un langage spécifique, le MOF, lui-même défini par son propre métamodèle au niveau M3. Nous pouvons maintenant avancer vers la manipulation de ces modèles et en particulier leur transformation. 4 La génération d un modèle relationnel vue comme une transformation de modèle. Dans la traduction d un diagramme de classe en un schéma relationnel, on distingue clairement ce qui peut se voir sous la forme d une transformation de modèle. 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 partagée dans la communauté informatique et au-delà. En fin du processus, le résultat final sera de la même façon un modèle, exprimé cette fois-ci dans un langage spécialement dédié à la description de structure de données persistantes : le langage CWM [7]. Ce langage jouit des mêmes qualités en terme de documentation. L expression du résultat dans ce langage permet d envisager sereinement l interopérabilité avec un générateur de code (SQL par exemple) pour la création directe de la base de données sur une quelconque plateforme. Entre le point de départ et le résultat de la méthode proposée ici, plusieurs opérations seront effectuées tantôt par le concepteur, tantôt par le système qui vont modifier l état et la nature du diagramme de classe initiale. A diverses étapes par exemple, le système aura à calculer de façon automatique les valeurs de certains attributs des classes du modèle en cours de traitement. Lors d une autre, il s agira en plus de ces calculs de traduire le 11

17 diagramme exprimé en UML en un schéma exprimé en CWM. Toute ces étapes et en particulier cette dernière, constituent des transformations de modèle, bien que parfois ces transformations se réduisent à des calculs élémentaires. Modèle UML Transformation Modèle CWM Figure 6 - La transformation d'un modèle Nous verrons comment l ingénierie dirigée par les modèles et le standard MDA sont des réponses concrètes qui permettent précisément d effectuer ce passage. Nous présenterons également l implémentation de ce cette approche, où nous avons utilisé le langage ATL. 5 L ingénierie dirigée par les modèles, ou Model-driven Architecture (MDA) Dans le contexte de l ingénierie logicielle, l OMG a depuis quelques années réfléchit sur la question de l utilisation extensive de modèles, d une part comme outil de dialogue avec les utilisateurs et/ou les concepteurs pour représenter les besoins fonctionnels, et d autre part comme langage de représentation de la connaissance suffisamment proche d une architecture logicielle donnée pour permettre un passage automatique d un modèle à du code informatique. Cette réflexion reprend l ambition fondamentale de séparer au mieux les problèmes de spécification des fonctionnalités d un système, et les détails d implémentation de ces fonctionnalités. 12

18 5.1 MDA Figure 7 - Logo MDA En 2001, l OMG a présenté le fruit de ses réflexions dans un document «Overview and guide to OMG's architecture» [8], où le groupe introduit son architecture dirigée par les modèles (Model Driven Architecture en anglais). Il y est montré comment utiliser intensivement les modèles pour le développement logiciel, et un éventail d exemples d implémentation y est décrit. L OMG définit dans ce guide MDA plusieurs niveaux d abstraction et d indépendance vis-à-vis d une implémentation particulière dans un environnement logiciel et matériel particulier. On retrouve ainsi essentiellement, du plus indépendant au plus spécifique, les niveaux «Computation independant», «Platform independant» et «Platform specific». Il est proposé d exprimer (de modéliser) successivement un problème dans ces trois niveaux, d abord au plus général pour capter le mieux possible les besoins souvent exprimés par des non-spécialistes, jusqu au plus fin permettant ainsi dans l idéal la génération directe de code fonctionnel pour une configuration logicielle et matérielle donnée. Les deux niveaux les plus utilisés sont les deux derniers, «Platform independant» et «Platform specific». Pour permettre le passage ou la traduction de l un vers l autre, l approche MDA sous-entend tout d abord de modéliser le problème ou le système considéré au niveau le plus indépendant, puis d utiliser différents types de transformation de modèle pour obtenir le modèle spécifique à la plateforme cible. 13

19 Figure 8 - Vue générale d une transformation d un PIM en PSM Ces modèles sont appelés PIM (pour Platform Independant Model» et PSM (pour «Platform Specific Model»), et sont exprimés dans n importe quel langage (par exemple UML que nous avons déjà évoqué). Le résultat de la transformation du PIM à l aide d une technique particulière sera non seulement le PSM mais également l enregistrement de la transformation, c est à dire la correspondance entre les éléments générés en sortie et leurs «parents», ou «origines» dans le PIM ainsi que les parties de la transformation (des règles ou des liens) qui ont conduit à la création des éléments en sortie. L OMG propose une classification des transformations en 5 grands types : Transformations utilisant le marquage. Ici, l architecte du système «marque» les éléments du PIM en puisant dans un ensemble de marqueurs prédéfinis pour une plateforme cible donnée. Les rôles des éléments source ainsi indiqués, on génère par l intermédiaire des liens prévus dans le «mapping», les éléments du PSM qui correspondent. 14

20 Transformation utilisant la fusion de modèles. Cette deuxième façon de procéder est proposée dans le guide de l OMG comme très générique, et il est indiqué sans plus de précisions que diverses déclinaisons MDA en dérivent. Transformations utilisant les métamodèles Dans ce cas, c est en spécifiant des règles de transformation directement entre les éléments des métamodèles du PIM et du PSM que l on crée la transformation. C est cette technique qui est utilisée par l outil ATL sur lequel nous reviendrons en détail. Transformations utilisant les types Cette fois-ci, on utilise plutôt des types que des éléments de métamodèles pour identifier les correspondances. Ces types peuvent représenter des fonctionnalités ou des caractéristiques aux niveaux indépendants de la plateforme ou spécifiques à un environnement. 15

21 Transformation utilisant les types et les patrons. Les liens sont spécifiés entres des types et des patrons définis pour le PIM et le PSM. Cette variante reprend simultanément les principes des deux précédentes. Pour résumer, quel que soit le type de transformation utilisé, le PSM sert finalement de base à la génération de code adapté à la plateforme cible. Dans notre cas, le «Platform specific model» sera un modèle conforme à CWM [7], et constituera un pont vers la génération de code SQL. 5.2 QVT Dans le cadre de l approche MDA, l OMG introduit le langage QVT [9] (pour Querry, View, Transformation). QVT est une spécification couplée à celle du MOF, et comme son nom l indique n est plus dédiée à la spécification de modèles, mais à leur manipulation. Ce langage possède une nature hybride déclarative/impérative et implémente la transformation de modèle de différentes manières. Cette spécification est encore en travaux aujourd hui, et les fonctionnalités en matière de visualisation de modèles sont peu avancées. Nous la citons ici car elle possède 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 possibilités nouvelles en matière d ingénierie logicielle. Dans le cadre des bases de données, ces techniques pourraient peut-être permettre de faciliter la modélisation des systèmes, par le développement d outils de conception plus ergonomiques et rigoureux. Le travail présent explore une partie de ces possibilités. 6 ATL Suite à la publication en 2001 du standard MDA par l OMG, de nombreux éditeurs de logiciels et laboratoires de recherches ont mit sur le marché des outils se réclamant de cette architecture. Parmi ceux-ci le laboratoire de l INRIA de Nantes a développé le langage ATL 16

22 (pour ATLAS Transformation Language) de transformation de modèles dans le cadre de son projet ATLAS [2]. Ce langage est officiellement parti d une tentative d implémentation du QVT «Request For Proposal» de l OMG, en reprenant en particulier les diverses façons déclaratives et impératives de spécifier une transformation. Il est développé sur la plateforme Eclipse et plus particulièrement sur sa branche EMF (pour Eclipse Modeling Framework). Il est accompagné de nombreux outils pour faciliter son utilisation. La mise en forme des mots clés du langage est assuré dans l éditeur de code ATL, un debugger est fourni, et une notation textuelle simple appelée km3 (pour Kernel MetaModel) permet la spécification de métamodèles. Pour réaliser notre objectif initial d automatiser le calcul d un schéma relationnel CWM à partir diagramme de classes UML, nous n utilisons que les fonctionnalités de transformation d ATL, qui sont d ailleurs les plus développées. Cependant, ce langage permet également l écriture de simples requêtes sur des modèles, comme le prévoit le volet Query de QVT. D ailleurs, il est évident que faire une transformation de modèle serait difficile sans la capacité de lire (et donc d effectuer des requêtes sur) le modèle source. Ainsi pour les transformations comme pour les seules lectures de modèles, ATL utilise intensivement le mode d écriture et la sémantique des mots clés de la norme OCL (section 3.3), aujourd hui dans sa version L opération élémentaire de transformation : la règle ATL Un programme de transformation écrit en ATL est composé de règles qui spécifient comment les éléments du modèle source sont reconnus et parcourus pour créer et initialiser les éléments du modèle cible. Ces règles sont de la forme générale suivante : rule ForExample { from i : InputMetaModel!InputElement to o : OutputMetaModel!OutputElement( attributea <- i.attributeb, attributeb <- i.attributec + i.attributed ) } Figure 9 - Un exemple de règle ATL ForExample est le nom de la règle de transformation. i (resp. o) est le nom de la variable qui dans le corps de la règle va représenter l élément source identifié (resp. l élément cible créé). InputMetaModel (resp. OutputMetaModel) est le métamodèle auquel le modèle source (resp. le modèle cible) de la transformation est conforme. InputElement désigne la métaclasse des éléments du modèle source auxquels cette règle va s appliquer. OutputElement désigne la métaclasse à partir de laquelle la règle va instancier les éléments cibles. Le point d exclamation permet de spécifier à quel métamodèle appartient une métaclasse en cas d homonymie. 17

23 attributea et attributeb sont des attributs de la métaclasse OutputElement Leur valeur est initialisée à l aide des valeurs des attributs i.attributeb, i.attributec et i.attributed de la métaclasse InputElement. Voici comment on pourrait formuler la fonction de cette règle en langage naturel. La règle ForExample, pour chaque élément i de type InputElement qu elle identifie dans le modèle source, crée dans un modèle cible un élément 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 l utilisation du «.», issu de la spécification OCL et reprit par ATL, qui permet dans les expressions i.attributeb, i.attributec et i.attributed de naviguer dans le modèle source i. En plus des règles, le langage ATL dispose du mot clé «helper», qui permet de définir des macros à l extérieur des règles pour factoriser des parties de code souvent utilisées. Des exemples de ces helpers sont utilisés et expliqués par la suite. Un programme ATL, appelé un module, est essentiellement un groupement de règles et de helpers. En dehors du module lui-même, les éléments fixes de la traduction sont donc les deux métamodèles source et cible. Le modèle source peut quant à lui être vu comme le paramètre de la transformation, et le modèle cible son résultat. C est à travers la configuration de l environnement d exécution du programme que l on spécifie concrètement dans quels fichiers le moteur de traduction doit chercher les métamodèles, le modèle source, le fichier programme, et dans quel fichier on attend qu il écrive le modèle résultat. Nous l avons vu, les modèles source et cible de la transformation sont conformes à leurs métamodèles respectifs fournis par l utilisateur. Notons qu un module ATL peut lui aussi se représenter sous forme d un modèle, puisque comme n importe quel langage ATL possède son propre métamodèle. Notons enfin qu ATL utilise nativement comme méta-métamodèle une version à peine différente du MOF, le méta-métamodèle Ecore défini par la branche EMF de la plateforme Eclipse. Le schéma suivant illustre ces principes à travers l exemple d une transformation ATL nommée Author2Person, destinée à transformer un modèle nommé Author en un modèle nommé Person. En pratique, les modèles et leurs métamodèles cibles et source prennent dans l environnement de développement Eclipse la forme de fichiers texte au format xmi avec une extension.ecore. 18

24 Figure 10 -Vue d ensemble d une transformation ATL 6.2 Utilisation d ATL Considérons notre problème «Générer un modèle relationnel normalisé à partir de diagrammes de classes UML». Faisons abstraction des calculs indiqués dans le processus de conception décrit dans l article, des nécessaires interactions avec l utilisateur, et concentrons nous sur la traduction proprement dite du modèle UML en modèle CWM. Les informations que nous devons apporter au système pour nourrir le moteur de traduction ATL sont : Le métamodèle UML 2.0 Le métamodèle CWM Le modèle UML (le modèle du domaine conforme au métamodèle UML 2.0) Le code ATL de transformation Ces éléments doivent permettre de générer automatiquement Le modèle CWM (le schéma relationnel conforme au métamodèle CWM) Spécification des métamodèles Les métamodèles UML 2.0 et CWM sont écrits dans le langage km3 dans deux fichiers textes distincts : MDC.km3 (pour Modèle De Domaine) dans lequel nous avons spécifié deux package, à la fois la partie du métamodèle d UML 2.0 qui nous intéressait, et un package où nous avons regroupé les métaclasse spécifique à notre domaine. MLRnL.km3 (pour Modèle Logique Relationnel normalisél) dans lequel nous avons extrait les packages et les métaclasses qui nous intéressaient de la spécification CWM de l OMG. 19

25 Voici un extrait du fichier MDC.km3 et plus particulièrement 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 d un fichier de définition du métamodèle UML 2.0 au format km3 A partir de ces deux fichiers textes distincts, on obtient à l aide d un «injecteur» accessible à travers l interface de la plateforme eclipse les deux fichiers xmi correspondants. Figure 12 - «Injection» du fichier km3 dans le format xmi conforme Ecore 20

26 Dans ces fichiers xmi, on trouve les classes définies initialement en km3 sous forme textuelle traduite en terme de métaclasses (puisqu il s agit d un métamodèle) en xmi, donc également sous forme textuelle, et conformes au méta-métamodèle Ecore (très proche du MOF). Voici les mêmes métaclasses que dans l exemple précédent exprimées cette fois-ci au format xmi. <?xml version="1.0" encoding="iso "?> <xmi:xmi xmi:version="2.0" xmlns:xmi=" xmlns:xsi=" xmlns: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 d un fichier de définition du métamodèle UML 2.0 au format xmi Maintenant au format xmi et comme nous venons de le dire conforme au métamétamodèle Ecore inclus dans le plugin EMF d eclipse, le métamodèle peut être interprété et affiché par l éditeur graphique développé dans le cadre de ce même plugin. 21

27 Figure 14 - Le fichier MDC.ecore affiché par l éditeur EMF Spécification des modèles Bien que de nombreux outils plus ou moins faciles à mettre en œuvre soient en principe à disposition, l écriture d un modèle est plus fastidieuse. On ne peut plus utiliser le langage km3 exclusivement dédiée à la définition de métamodèles. Il faut alors commencer par écrire directement un fichier texte au format xmi en spécifiant les éléments du modèle avec leurs balises ouvrantes et fermantes. Dans l exemple suivant, on a créé un fichier exemple.ecore où l on définit à la main une classe de type Classe. Le type Classe est une référence à la métaclasse du même nom dans le métamodèle UML20 lui-même référencé par l attribut xmlns de la balise xmi:xmi. <?xml version="1.0" encoding="iso "?> <xmi:xmi xmi:version="2.0" xmlns:xmi=" xmlns="uml20"> <Class> </Class> </xmi:xmi> Figure 15 -Exemple de départ de définition d une classe, dans un fichier ecore au format xmi Pour autant que la syntaxe xmi soit correcte et conforme au métamodèle, l éditeur permet ensuite d accéder plus facilement, à la souris, aux attributs et aux associations des éléments précédemment créés. Figure 16 - Un onglet «Properties» permet d accéder aux propriétés de la classe Class. En plus de pouvoir éditer dans un onglet les valeurs des propriétés de l élément sélectionné, un menu contextuel accessible par clic droit sur le même élément permet dans certains cas de provoquer la création de nouveaux éléments issus du métamodèle. Par exemple, on voit dans notre extrait du métamodèle d UML 2.0 que les éléments de type Class possèdent entre autre par leur membre ownedattribute des éléments de type Property. Cette relation est une relation d agrégation, précisée dans notre fichier km3 original du métamodèle UML 2.0 par le mot clé «container» 22

28 class Class extends Classifier { reference ownedattribute[*] container : Property oppositeof "class"; } Figure 17 - Le mot clé container permet de refléter une aggregation UML Cette qualité particulière de la relation entre Class et Property, permet de disposer dans l éditeur de la plateforme eclipse de la fonction de génération automatique d éléments «fils» d un autre. C est cette fonction que nous utilisons dans l exemple ci-dessous. Figure 18 -Le menu contextuel «New Child» Une fois un élément contenu par un autre créé, une variante de la fonction «New Child» est alors disponible, puisque l on peut créer à la souris des éléments «jumeaux», du même niveau dans la hiérarchie contenants/contenus. L exemple suivant montre comment créer une deuxième propriété pour la même classe, en utilisant cette possibilité. Figure 19 - Le menu contextuel «New Sibling» 23