Workflow XML pour l interopérabilité des données

Transcription

1 Institut Supérieur d Informatique de Modélisation et de leurs Applications Complexe des Cézeaux Aubière Cedex Rapport d ingénieur Stage de 3ème année Filière : Calcul et modélisation scientifiques Workflow XML pour l interopérabilité des données Organisme d accueil : Cemagref Présenté par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Durée : 4 mois Tuteur ISIMA : Jonas KOKO Mai à Septembre 2010

2

3 Institut Supérieur d Informatique de Modélisation et de leurs Applications Complexe des Cézeaux Aubière Cedex Rapport d ingénieur Stage de 3ème année Filière : Calcul et modélisation scientifiques Workflow XML pour l interopérabilité des données Organisme d accueil : Cemagref Présenté par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Durée : 4 mois Tuteur ISIMA : Jonas KOKO Mai à Septembre 2010

4

5 Remerciements Je tiens à remercier Catherine ROUSSEY et Jean-Pierre CHANET qui m ont encadré, aidé et guidé tout au long de ce stage. Je remercie Jean-Claude CHAMPOMIER, Vincent SOULIGNAC, Gil de SOUSA et André MIRALLES pour m avoir donné accès à leurs travaux et pour le temps qu ils m ont accordé. Les modèles UML qu ils m ont fournis ont été d une grande aide pour mes réalisations. Je tiens enfin à remercier l ensemble des personnes qui ont permis à ce stage de se dérouler dans d excellentes conditions. Marc ZIMMERMANN Rapport de stage de 3 ème année

6 Résumé Mon stage de troisième année à l ISIMA s est déroulé au Cemagref où j ai été chargé de réaliser un workflow XML pour l interopérabilité des données. Pour créer l architecture des logiciels, les développeurs ont recourt à des méthodes guidées par les modèles. Cette approche s intitule en anglais Model Driven Architecture (MDA). Le langage privilégié pour décrire le MDA est l Unified Modeling Language (UML). Ainsi de nombreux Ateliers de Génie Logiciel (AGL) permettent de décrire ces modèles grâce à UML, et un standard existe pour leur sérialisation : XML Metada Interchage (XMI). Or les évolutions nombreuses et indépendantes d UML et d XMI ont appauvri l interopérabilité des modèles. L objectif du travail décrit dans ce document est d étudier les compatibilités entre XMI et de fournir des outils afin d améliorer l interopérabilité entre AGL. C est la technologie extensible Stylesheet Language Transformation (XSLT) qui a été utilisée pour réaliser les outils. Les transformations des modèles s effectuent au moyen d une conversion dans un langage intermédiaire : Web Ontologie Language (OWL). Ainsi les outils permettent de créer l ontologie associée au modèle et toutes les versions XMI existantes. Ces transformations sont intégrées dans une application Java, nommée Model-Ontology Stylesheet Tranformation (MOST), totalement configurable afin de pouvoir s adapter aux évolutions à venir d UML et d XMI. Mots clés : atelier de génie logiciel, interopérabilité, Java, modèle, ontologie, OWL, UML, workflow, XMI, XML, XSLT. Marc ZIMMERMANN Rapport de stage de 3 ème année

7 Abstract My training period for the third year at the ISIMA was conducted at the Cemagref where I was in charge of realizing an XML workflow for data interoperability. Developers use methods guided by the models to design and create software. These methods are known as Model Driven Architecture (MDA). The preferred language to describe the MDA is the Unified Modeling Language (UML). So, many computer-aided software engineering (CASE) tools help developers to describe these models using UML, and a standard exists for their serialization: XML Metadata Interchange (XMI). But many independent evolutions of UML and XMI have reduced the interoperability of models. This report presents the compatibility study between XMI versions and describes the design process of the software developed to improve interoperability between CASE softwares. This tool is named Model-Ontology Stylesheet Transformation (MOST). This tool was based on extensible Stylesheet Language Transformation technology (XSLT). The transformations of models are made using a conversion into an intermediate language: Web Ontology Language (OWL). Thus, the application creates the ontologies associated to the model and all existing versions of XMI. These transformations are embedded in a fully configurable Java application in order to adapt to future evolutions of UML and XMI. Keywords : computer-aided software engineering, interoperability, Java, model, ontology, OWL, UML, workflow, XMI, XML, XSLT. Marc ZIMMERMANN Rapport de stage de 3 ème année

8 Table des matières Remerciements... Résumé... Abstract... Table des matières... Lexique... Introduction Présentation du contexte Présentation de l organisme d accueil Le Cemagref Le centre de Clermont-Ferrand L UR «Technologies et systèmes d information pour les agrosystèmes» L équipe «Systèmes d information communicants et agri-environnementaux» Contexte technique Les technologies XML Modèles de données et interopérabilité Conclusion sur XML Analyse du problème Cahier des charges Etude des entrées et sorties XMI Recensement des entrées/sorties Equivalence UML1-UML Conformité des sorties XMI Interopérabilité des modèles UML Organisation du travail Planning Plan de développement Conception de la solution Architecture du workflow Transformations XSLT Prétraitements Correspondance UML-OWL Algorithme de transformation UML2OWL Algorithme de transformation OWL2UML Application Java Cas d utilisation Classes candidates et diagrammes de classes Diagrammes de collaboration et de séquence Choix des technologies Transformation de fichiers XML Le processeur XSLT L environnement de développement intégré Réalisations Réalisation des transformations Prétraitements Transformation UML2OWL Transformation OWL2UML Tests et validation Réalisation de l application MOST Marc ZIMMERMANN Rapport de stage de 3 ème année

9 4.2.1 Maquette et exemples de principes Génération de l architecture du code Implémentation des modules Résultats et prolongements Etats des lieux Ce qui a été réalisé Ce qu il reste à faire Améliorations possibles et prolongement Bilan Conclusion Index des illustrations... Références bibliographiques... Marc ZIMMERMANN Rapport de stage de 3 ème année

10 Lexique AGL : Atelier de Génie Logiciel. Suite de logiciels permettant de construire des logiciels complexes en garantissant leur maintenabilité. Ces ateliers automatisent un grand nombre de tâches du développement logiciel. Design Pattern : En français patron de conception, ils décrivent des solutions standards pour répondre à des problèmes récurrents de conception d architectures des logiciels. Le même terme est utilisé dans le domaine de la conception d ontologies pour proposer des solutions à des problèmes de modélisation. DTD : Document Type Definition. C'est une grammaire qui décrit les balises utilisables dans un document XML et leurs imbrications possibles. DTD est un type de schéma XML qui possède son propre langage, non basé sur XML. Interopérabilité : En informatique c est la capacité d un système à fonctionner avec d'autres, existants ou futurs, sans restriction d'accès ou de mise en œuvre. Ontologie : Ensemble formalisé de termes du vocabulaire associé à un domaine. L'ontologie constitue un modèle représentant un ensemble de concepts d un domaine, ainsi que les relations entre ces concepts. OMG : Object Management Group. Association américaine créée en 1989 destinée à promouvoir et standardiser le modèle objet. OWL : Web Ontology Language. Langage permettant de décrire des ontologies Web. Il est basé sur trois sous-langages possédant des pouvoirs d'expressions croissants : OWL-Lite, OWL-DL et OWL-Full. RDF : Resource Description Framework. RDF est un langage général pour la représentation d informations Web. Il fait partie des recommandations du W3C et est sérialisé en XML. RDF Schema : RDFS est une extension de la sémantique de RDF. Il permet de décrire des ressources et les liens entre elles. RDFS est notamment utilisé pour décrire des ontologies. Sérialisation : mécanisme permettant de stocker des informations dans un fichier. UML : Unified Modeling Language. Langage de modélisation dans le domaine du développement logiciel. Spécification de l'omg. W3C : World Wide Web Consortium. Organisme à but non lucratif destiné à promouvoir la compatibilité des technologies Web. Workflow : Enchainement de tâches à réaliser pour atteindre un objectif. XMI : XML Metadata Interchange. Standard d'échange d'informations de métadonnées UML basé sur XML. Permet l'échange de données entres AGL. Standard de sérialisation d'uml. XML : extensible Markup Language. Langage informatique permettant de stocker de manière arborescente des données de type texte grâce à des balises (reconnaissables par des chevrons <>). Marc ZIMMERMANN Rapport de stage de 3 ème année

11 XML Schema : Un XML Schema permet de décrire la structure d'un fichier XML (éléments, attributs, types de données, ). C'est un document XML, alternative à la DTD. XSD inclus une déclaration de types de données. XPath : XML Path Language. Langage de requêtes pour sélectionner des nœuds dans un fichier XML. Il permet de naviguer dans l'arborescence d'un fichier XML. XSD : XML Schema Definition. Equivalent à XML Schema. XSLT : extensible Stylesheet Language Transformations. Langage permettant la transformation d un fichier XML vers un autre document (XML, HTML, texte). Marc ZIMMERMANN Rapport de stage de 3 ème année

12 Introduction Dans le domaine du développement logiciel la conception des architectures est guidée par les modèles. Cette démarche s'appelle Model Driven Architecture (MDA). Le langage privilégié pour décrire le MDA est UML. Des ateliers de génie logiciel permettent de réaliser ces modèles et de générer le code correspondant dans divers langages objets. Pour stocker et échanger les modèles UML un standard édité par l OMG existe : XML Metadata Interchange (XMI). Cependant les normes UML et XMI ont évolué séparément. Les modèles peuvent donc être décrits dans plusieurs versions d UML et sérialisés dans plusieurs versions de XMI. Cette situation pose des problèmes d'interopérabilité des données entre les AGL. Le premier objectif de ce stage est de fournir des outils de transformation de fichiers XMI afin d améliorer l interopérabilité entre AGL. Le second objectif est d extraire les connaissances présentes dans ces modèles. Afin de représenter les modèles sans leur aspect implémentation lié à UML, ils seront convertis dans un formalisme de représentation des connaissances basé sur XML : le Web Ontology Language (OWL). Ces outils seront réalisés grâce à la technologie extensible Stylesheet Language Transformations (XSLT). Concrètement, à partir d'un modèle UML stocké dans un fichier XMI ces outils doivent permettre de produire des fichiers OWL représentant la sémantique du modèle UML. Ensuite ces fichiers OWL seront traduits dans les différents formats existants de XMI. Pour réaliser ces objectifs la première tâche consistera à étudier la compatibilité entre les formats XMI et les AGL. La seconde tâche sera de créer les outils permettant de produire les fichiers OWL. Enfin la dernière étape sera la réalisation des outils pour transformer les fichiers OWL en fichiers XMI. L ensemble de ces outils de transformations sera intégré dans une application écrite en Java, nommée Model-Ontology Stylesheet Transformation (MOST). Ce rapport présente l étude et les résultats de ce stage avec dans une première partie la présentation du contexte du stage, dans une seconde l analyse du problème. La solution envisagée pour répondre au problème sera décrite dans la troisième partie et les principales réalisations seront expliquées dans la quatrième. Enfin la dernière partie dressera un bilan des travaux réalisés. Marc ZIMMERMANN Rapport de stage de 3 ème année 1/53

13 1 Présentation du contexte L objectif de cette partie est de présenter le contexte de cette étude. Elle présente dans un premier temps l organisme dans lequel ces travaux ont été réalisés. Dans un second temps elle présente le contexte technique de l étude, c est-à-dire les principales technologies mises en jeu. 1.1 Présentation de l organisme d accueil Le Cemagref L institut de recherche en sciences et technologies pour l environnement, plus connu sous le nom de Cemagref, a été créé en C est un établissement public à caractère scientifique et technologique placé sous la double tutelle des ministères en charge de la recherche et de l'agriculture. Son activité se regroupe autour de trois thèmes structurés en trois départements : Eaux (ressources, milieux, usages et risques) Ecotechnologies (réseaux, épuration, déchets) Territoires (développement territorial, biodiversité, risques et vulnérabilités) Eaux, territoires et écotechnologies sont des thématiques qui répondent aux besoins de la société. Les moyens mis en œuvres par le Cemagref pour répondre à ces problématiques s étendent de la recherche à l action. En effet il fournit un appui scientifique et technique à la décision (études, expertises, modèles et outils opérationnels) et des solutions d ingénierie qui intègrent des composantes pluridisciplinaires. Labellisé Carnot en 2006, le Cemagref a de nombreux partenaires industriels leaders dans la gestion de l eau, des déchets et des équipements agricoles. Actif aussi au niveau Européen, il est partenaire du réseau Partnership for European Environmental Research (PEER) qui regroupe sept grands instituts européens de recherche dédiés aux interactions entre l homme et son environnement. D autre part le Cemagref est fortement impliqué dans l enseignement supérieur, notamment en termes de participation à la formation. Il développe des alliances autant avec les pôles de recherche et d enseignement supérieur français qu avec des universités étrangères. Le Cemagref en quelques chiffres c est : 9 centres et 2 implantations hors centres (Strasbourg et Martinique) 20 unités de recherche propres (UR) 5 unités de recherche mixtes (Cirad, Inra, IRD, Engees, AgroParisTech, SupAgro) 1400 collaborateurs dont 500 ingénieurs et chercheurs, 200 doctorants et 40 postdoctorants Un budget en 2010 de 110 M (dont 31 M de ressources propres) Figure 1 : Les centres du Cemagref Marc ZIMMERMANN Rapport de stage de 3 ème année 2/53

14 1.1.2 Le centre de Clermont-Ferrand Le centre de Clermont-Ferrand est implanté sur deux sites : le site d'aubière (Puy de Dôme) et le site de Montoldre (Allier). Le Cemagref mène en Auvergne des recherches autour de deux axes : les innovations technologiques pour l'agriculture raisonnée et pour l'environnement le développement régional et l'aménagement du territoire Le centre de recherche de Clermont-Ferrand dispose de deux unités de recherche (UR) : Laboratoire d'ingénierie des Systèmes Complexes (LISC) Technologies et systèmes d information pour les agrosystèmes (TSCF), composée de quatre équipes : o Technologies épandage, agroéquipements, mobilité o Matériaux et milieux o Systèmes d information communicants et agri-environnementaux o Sciences-technologies et procédés d'épandage Et d une unité de recherche mixte : Mutations des activités, des espaces et des formes d organisation dans les territoires ruraux (UMR Métafort). Les thèmes de recherche abordés sont les suivants : Développement Territorial et Agriculture Multifonctionnelle Innovations technologiques pour l'agriculture durable et l'environnement Modèles, systèmes d'information et gestion viable de l'environnement L UR «Technologies et systèmes d information pour les agrosystèmes» L unité «Technologies et systèmes d information pour les agrosystèmes» mène des recherches sur les méthodes et outils pour une ingénierie des systèmes complexes que sont les systèmes agri-environnementaux. Elles portent sur les technologies de la mobilité pour la sécurité et la qualité du travail des machines, sur les technologies d épandage de matériaux organiques ou minéraux. Les systèmes écologiques y sont également abordés, à travers les technologies pour la perception et la caractérisation du sol. Enfin des recherches sont conduites sur les systèmes d information et de communication partagés en collaboration avec les recherches menées plus largement à l UMR «Territoires, environnement, télédétection et information spatiale» associant des équipes Cemagref, CIRAD et AgroPariTech L équipe «Systèmes d information communicants et agri-environnementaux» L activité de l équipe «Systèmes d information communicants et agri-environnementaux» est consacrée aux méthodes d ingénierie des systèmes d information spatialisés dédiées à la gestion agri-environnementale. Cet ensemble de méthodes couvre l analyse des besoins des acteurs, la spécification des systèmes d information, leur modélisation, leur conception, leur gestion et leur lien avec les sources de données. L objectif de l'équipe est de développer des méthodes et des techniques selon deux axes : Marc ZIMMERMANN Rapport de stage de 3 ème année 3/53

15 déployer et gérer des réseaux de capteurs communicants adaptés aux problèmes agrienvironnementaux concevoir et gérer des systèmes d information, tels que des entrepôts de données ou des systèmes de gestion des connaissances, adaptés au contexte de l agri-environnement Les thèmes de recherche associés sont les modèles, les systèmes d'information et la gestion viable de l'environnement. Les domaines de spécialité de l équipe sont le génie logiciel, la modélisation UML, les entrepôts de données spatiales, l informatique, les télécommunications et les réseaux de capteurs. 1.2 Contexte technique Les technologies XML extensible Markup Language Le langage informatique de balisage XML est un standard recommandé par le W3C [W3CXML]. Son objectif est de favoriser l interopérabilité des données entre des systèmes d information différents. Il permet de stocker des informations arborescentes dans des fichiers de type texte. La structure de ses balises est facilement reconnaissable par l usage des chevrons (< et >). Les principaux éléments de structure d un document XML sont décrits dans la figure ci-contre. Figure 2 : Syntaxe d'un fichier XML Le langage XML est très largement utilisé dans de nombreux domaines de l informatique et de nombreux autres langages se basent sur sa syntaxe. Un document XML doit respecter un certain nombre de règles éditées par le W3C. Parmi celles-ci on peut citer la correspondance des balises ouvrantes et fermantes, l existence d une racine unique, etc. En plus de respecter ces règles un document XML a la possibilité de devoir être valide par rapport à un schéma. Deux types de schéma sont principalement utilisés : DTD et XSD (aussi appelé XML Schema). La DTD est une méthode de validation de la syntaxe et de la structure d un fichier XML, elle définit les balises et attributs utilisables dans un document XML et leurs imbrications possibles. DTD n est pas basée sur la syntaxe d XML. Le XML Schema est le successeur de la DTD et est plus restrictif car il impose les types de données des éléments. XSD est un document XML. Marc ZIMMERMANN Rapport de stage de 3 ème année 4/53

16 extensible Stylesheet Language Transformation Un document XML peut être transformé en un autre document XML grâce à la technologie XSLT. XSLT s appuie sur des feuilles de style, ce sont des documents XML qui contiennent les transformations qui doivent être réalisées. Une transformation XSLT se passe généralement de la façon suivante : on donne un document XML et une feuille de style à un processeur XSLT qui applique les transformations et produit un nouveau document qui peut être sérialisé dans un fichier XML, HTML ou texte. Les processeurs XSLT acceptent cependant plusieurs documents XML et plusieurs feuilles de style en entrée et peuvent produire plusieurs documents en sortie (sorties multiples en XSLT 2.0 uniquement). Figure 3 : Transformation XSLT Une feuille de style contient un ensemble de «fonctions» appelées template rules. Une template rule est constituée de deux parties : un pattern et un template. Le pattern est un motif qui sert à identifier les nœuds de l arbre d entrée auxquels va s appliquer la template rule. Le template est le fragment d arbre qui va être écrit dans l arbre résultat. Un template peut contenir des résultats sous forme de texte ou encore des instructions XSLT, par exemple pour le traitement des nœuds enfants du nœud courant. Figure 4 : Exemple de template rule XSLT Dans cet exemple pour chaque nœud Pattern on écrit deux nœuds dans l arbre résultat, ResultTreeFragment et PatternNodeValue contenant le contenu du nœud Pattern. En l absence d une template rule adaptée à un nœud c est une template rule native qui est appliquée à ce nœud. Elle permet de continuer le parcours récursif de l arbre. Figure 5 : Template rule native Le document est ainsi parcouru en appliquant à chaque nœud la template rule ayant le meilleur pattern correspondant. La recherche des nœuds dans les arbres XML se fait grâce à la technologie XML Path Language (XPath). Marc ZIMMERMANN Rapport de stage de 3 ème année 5/53

17 1.2.2 Modèles de données et interopérabilité Modèle UML Unified Modeling Language (UML) est un langage graphique permettant de spécifier, construire et documenter les objets d un système informatique. UML représente l unification des techniques les plus utilisées et les mieux conçues de modélisation orienté objet. UML fait partie d une architecture de métadonnées plus grande encore : Meta Object Facility (MOF). UML et MOF sont des spécifications de l Object Managment Group *OMGMMS+. Figure 6 : Architecture MOF Un modèle est une abstraction d un système physique réel dans un certain but. Un méta-modèle est un modèle qui défini le langage de description des modèles. Un méta méta-modèle est un modèle qui défini le langage de description des méta-modèles. Chaque couche de cette architecture est considérée comme une instance de la couche supérieure. Les modèles UML sont sérialisés dans des fichiers XMI (XML Metadata Interchange). XMI est aussi un standard de l OMG pour l interopérabilité et la sérialisation des modèles UML [OMGMMS]. Le langage XMI est basé sur la syntaxe XML Web Ontology Language (OWL) Une ontologie est un modèle permettant de décrire de manière formelle les concepts d un domaine et les relations entre ces concepts. OWL est une famille de langages permettant de décrire des ontologies. OWL est une recommandation du W3C [W3COWL]. OWL est basé sur des logiques de description (opérateurs du type intersection, union, négation, équivalence, ). Ces logiques de description permettent de faire des raisonnements et de classifier les instances des concepts. Les raisonnements en OWL sont sujets à deux hypothèses : l Open World Assumption : signifie que ce qui n est pas dit est supposé indéfini, autrement dit le fait que quelque chose ne soit pas déclaré comme vraie ne suffit pas à conclure qu elle est fausse. l Unique Name Assumption n est pas respectée par OWL : deux noms différents ne font pas nécessairement références à deux objets différents. Marc ZIMMERMANN Rapport de stage de 3 ème année 6/53

18 Il existe trois types d ontologies OWL : OWL Lite, OWL DL et OWL Full. Ces trois types ont des pouvoirs d expression croissants. Cependant du fait de sa grande expressivité OWL Full n est pas un langage décidable, c est-à-dire que l aboutissement d un algorithme sur une ontologie OWL Full n est pas garanti en temps fini. Dans le langage OWL les classes définissent les concepts du domaine et les individus sont des instances de ces classes. Les relations entre les classes sont définies par des properties. Les properties peuvent être schématisées de la manière suivante : Figure 7 : Exemple OWL Deux types de properties sont remarquables : les datatype properties lient les individus à des types de donnée et les objects properties lient des individus à d autres individus. En OWL il existe des conditions nécessaires et/ou suffisantes qui permettent de déterminer si un individu appartient à une classe. Ces conditions sont appelées des restrictions, il en existe plusieurs sortes : Pizza : subclassof(apourgarniture only Tomate) Une Pizza a pour garniture uniquement des Tomates Pizza : subclassof(apourgarniture some Tomate) Une Pizza a pour garniture au moins une Tomate Pizza : subclassof(apourgarniture max Tomate n) Une Pizza a au maximum n Tomate pour garniture Pizza : subclassof(apourgarniture min Tomate m) Une Pizza a au minimum m Tomate pour garniture Ensuite des raisonneurs permettront de classifier les individus d une ontologie et par exemple, en fonction de ses ingrédients un plat pourra être reconnu comme une Pizza. Une ontologie OWL peut être sérialisée dans un fichier. La sérialisation d ontologies est basée sur Resource Description Framework (RDF) et RDF Schema (RDFS). RDF et RDFS ont des syntaxes basées sur XML. Marc ZIMMERMANN Rapport de stage de 3 ème année 7/53

19 1.2.3 Conclusion sur XML On remarque que beaucoup des technologies impliquées dans ce document sont basées sur la syntaxe d XML. On peut les représenter de la façon suivante : Figure 8 : Les langages basés sur XML XML fournit la syntaxe du langage (balises) et les autres langages définissent un vocabulaire (noms des balises). Marc ZIMMERMANN Rapport de stage de 3 ème année 8/53

20 2 Analyse du problème Cette partie détaille l analyse du problème avec dans une première partie la rédaction du cahier des charges qui identifie les travaux à réaliser. Dans une deuxième partie une étude de l interopérabilité entre ateliers de génie logiciel est résumée. Enfin la dernière partie explique le plan de travail adopté. 2.1 Cahier des charges Le but de ce stage est de produire des outils de transformation de modèles stockés dans différents formats XMI pour faciliter l interopérabilité des AGL. Pour cela une étude de compatibilité entre les formats XMI et les outils AGL sera demandée en premier lieu. L étude portera sur plusieurs aspects de la compatibilité : 1. compatibilité entre AGL pour un format XMI donné, Par exemple un fichier XMI 1.2 produit par un AGL donné est-il totalement lisible avec un autre AGL? Cette étude portera sur les AGL les plus populaires dans le monde Java. 2. compatibilité entre formats XMI, Le but est de vérifier que l ensemble des éléments décrits dans un format XMI 1.0 peut être décrit dans un format XMI 2.1 et inversement. 3. l étude devra aussi s intéresser plus particulièrement à la description des contraintes d intégrité en UML et leurs différentes formes de stockage en XMI. Dans un second temps les outils qui seront développés devront permettre de produire deux types de fichiers : 1. des fichiers OWL, 2. les différentes versions des fichiers XMI. Une attention particulière sera portée sur la restitution des commentaires des objets UML. La réalisation de ces outils s appuiera sur les technologies XML associées comme XSLT. Pour plus d'ergonomie ces différents outils seront ensuite intégrés dans une application développée en langage Java. 2.2 Etude des entrées et sorties XMI L'étude suivante va être réalisée sur les entrées/sorties XMI des ateliers de génie logiciel cidessous : ArgoUML Bouml Enterprise Architect Mega Modelio (successeur d'objecteering) Objecteering Poseidon (construit à partir d'argouml) PowerAMC StarUML Marc ZIMMERMANN Rapport de stage de 3 ème année 9/53

21 Cette liste n'a pas pour but d'être exhaustive mais présente des AGL très utilisés dans le domaine du développement logiciel. Les AGL utilisés au Cemagref sont Enterprise Architect, Mega, Objecteering (maintenant Modelio) et PowerAMC Recensement des entrées/sorties La première étape de l'analyse des fichiers XMI produits par les divers AGL a été de faire un recensement des versions utilisées pour l'import et l'export de modèles depuis les AGL. Elle est synthétisée dans le tableau suivant. AGL Import Export UML Version(s) Version courante correspondante(s) ArgoUML XMI 1.0 XMI 1.1 UML 1.3 UML 1.4 ArgoUML 0.28 ArgoUML (06/05/2010) XMI 1.2 XMI 1.2 UML 1.4 BOUML XMI 2.1 XMI 1.2 XMI 2.1 UML 1.4 UML 2.x BOUML 4.21 BOUML 4.21 (12/05/2010) Enterprise Architect XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1 XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1 UML 1.3 UML 1.3 UML 1.4 UML 2.x Enterprise Architect 7 et ultérieures Enterprise Architect 8 build 856 (05/05/2010) Mega XMI 1.0 UML 1.3 Mega 2009 SP3 (02/2010) Modelio XMI 2.1 XMI 2.1 UML 2 Modelio 1.2 Modelio 1.2 (19/05/2010) Objecteering XMI 2.1 XMI 2.1 UML 2.x Objecteering 6.1 Objecteering 6.1 SP4 (25/11/2009) Poseidon XMI 1.0 XMI 1.1 XMI 1.2 XMI 1.2 UML 1.3 UML 1.3 UML 1.4 Poseidon 6.0 et ultérieures Poseidon 8.0 PowerAMC XMI 1.1 XMI 1.1 UML 1.3 PowerAMC 9.0 à 15 PowerAMC 15.2 XMI 2.1 XMI 2.1 UML 2.x PowerAMC 15.1 et 15.2 StarUML XMI 1.1 XMI 1.1 UML 1.3 StarUML 5.0 StarUML 5.0 (30/12/2005) Figure 9 : Imports et exports XMI Ces informations sont disponibles sur les documentations en ligne et guides de l'utilisateur des AGL. La colonne UML correspond à la norme UML choisie par l'atelier de génie logiciel pour représenter le modèle, il est ensuite écrit dans une version de XMI. Ici UML 2.x représente seulement les versions UML 2.0 et UML 2.1.1, et l'absence de version mineure indique que la documentation n'en fait pas mention. Marc ZIMMERMANN Rapport de stage de 3 ème année 10/53

22 On remarque déjà des associations privilégiées entre UML et XMI. Afin d être plus complet j ai recensé les versions de UML et de XMI existantes grâce aux spécifications de l OMG *OMGMMS]. UML 1.3 UML 1.4 UML 1.5 UML 2.0 UML UML UML 2.2 UML 2.3 XMI 1.0 DTD XMI 1.1 DTD DTD DTD XMI 1.2 DTD XMI 1.3 XMI 2.0 XMI 2.1 XSD XSD XMI Figure 10 : Associations entre UML et XMI Les cases grisées indiquent que les associations UML/XMI correspondantes n existent pas. Les annotations DTD et XSD indiquent que les spécifications de l OMG incluent un document de validation des fichiers XMI. La première remarque qui peut être faite sur ce tableau est qu il n existe pas toujours une unique version de XMI permettant de sérialiser les modèles d une version d UML donnée. Il convient aussi de noter que parmi toutes les spécifications d UML et d XMI seulement une partie est effectivement utilisée par les AGL pour la sérialisation de modèles UML, à savoir : UML 1.3 XMI 1.0 UML 1.3 XMI 1.1 UML 1.4 XMI 1.1 UML 1.4 XMI 1.2 UML 2.0 XMI 2.1 UML 2.1 XMI Equivalence UML1-UML2 L'analyse du contenu des fichiers XMI révèle d'abord que l'ensemble des objets qui vont être utilisées par la suite, sont présents quelque soit la version d UML comme le montre le tableau suivant : UML 1.3 UML 1.4 UML 2.0 UML 2.1 Modèle oui oui oui oui Package oui oui oui oui Classe oui oui oui oui Attribut oui oui oui oui Généralisation oui oui oui oui Association oui oui oui oui Commentaire oui oui oui oui Type de données oui oui oui oui Enumération oui (1) oui (1) oui oui Classe d'association oui oui oui oui Association n-aire oui oui oui oui Figure 11 : Equivalence des versions d'uml Marc ZIMMERMANN Rapport de stage de 3 ème année 11/53

23 (1) Est parfois implémenté sous forme de stéréotype de classe. Il n'est pas fait mention ici des méthodes car elles ne sont pas utilisées. En effet le but des modèles sur lesquels je vais travailler n'est pas de faire du développement mais de la représentation de connaissances. Tous les objets sur lesquels se focalise cette étude sont présents dans toutes des versions d UML. Ainsi un modèle décrit en UML 1 peut être entièrement décrit avec UML 2 (ce qui est logique compte tenu de la compatibilité ascendante) et vice versa Conformité des sorties XMI Un problème a été identifié lors de l analyse de l équivalence des versions UML : pour une même version d UML et de XMI la manière de décrire les objets varie en fonction de l'agl. Figure 13 : Généralisation sous StarUML Figure 12 : Généralisation sous PowerAMC Il m'a donc fallu trouver un moyen de distinguer quelle est la «bonne» syntaxe pour décrire ces objets. Mes recherches m'ont conduit vers des méthodes de validation des fichiers XML qui sont la DTD et le XSD. Ce sont deux manières plus ou moins restrictives de décrire le contenu d'un fichier XML. Si un fichier XML respecte les règles dictées par une DTD ou un XSD alors il est considéré comme conforme à cette DTD ou ce XSD. L'OMG a produit des DTD et XSD pour certains couples de version UML/XMI. Par exemple, pour UML 1.3 XMI 1.1, la structure conforme d une généralisation est la suivante : Figure 14 : Généralisation UML 1.3 XMI 1.1 conforme Grâce à ces schémas j'ai été en mesure de vérifier la validité des sorties des AGL par rapport aux spécifications de l'omg. Marc ZIMMERMANN Rapport de stage de 3 ème année 12/53

24 ArgoUML BOUML Enterprise Architect Mega Modelio Objecteering PowerAMC StarUML ArgoUML BOUML Enterprise Architect Mega Modelio Objecteering PowerAMC StarUML ArgoUML BOUML Enterprise Architect Mega Modelio Objecteering PowerAMC StarUML ArgoUML BOUML Enterprise Architect Mega Modelio Objecteering PowerAMC StarUML Workflow XML pour l interopérabilité des données Les résultats de la validation des sorties XMI sont résumés dans les tableaux ci-dessous : UML 1.3 XMI 1.0 XMI 1.1 UML / AGL Modèle Package Classe Attribut Généralisation Association Commentaire Enumération (*) (*) (*) Classe d'association Association n-aire Figure 15 : Conformité des AGL pour UML 1.3 UML 1.4 UML 2.1 XMI 1.2 XMI 2.1 UML / AGL Modèle Package Classe Attribut Généralisation Association Commentaire Enumération (*) (*) Classe d'association Association n-aire Figure 16 : Conformité des AGL pour UML 1.4 et UML 2.1 Marc ZIMMERMANN Rapport de stage de 3 ème année 13/53

25 Légende Conformité Conforme Non conforme (mais passe en traitement général) Non conforme (nécessite un traitement spécifique) Sortie non générée Information manquante (*) Stéréotype : classe/attributs On remarque que peu d'agl sont totalement conformes. Cependant j'ai identifié un "degré de gravité" dans la non-conformité. Il consiste à dire que les non-conformités qui sont traitables de la même manière que les conformités sont peu graves. Tandis que les autres nécessiteront un traitement spécifique Interopérabilité des modèles UML L analyse des imports et exports des ateliers de génie logiciel permet de conclure sur l interopérabilité des données. Tout d'abord UML et XMI vont toujours de pair, c'est-à-dire que pour décrire un modèle il faut une version d'uml et une version d XMI. Cela a un impact direct sur l'interopérabilité puisque, les normes d'uml et d'xmi évoluant séparément, c'est de nombreuses combinaisons d'uml/xmi qui coexistent. Cependant on remarque aussi que toutes les associations UML/XMI ne sont pas utilisées. Pour mieux évaluer l interopérabilité on peut représenter chaque version de XMI comme un medium de communication et ainsi obtenir le réseau suivant : Figure 17 : Réseau des AGL Pour un AGL la colonne de gauche représente les ports d entrées XMI et celle de droite les ports de sorties. Les ports qui sont ouverts sont représentés en vert, ceux fermés en rouge. Sur ce réseau nous pouvons voir que rien ne garanti la communication entre deux AGL et encore moins la communication dans les deux sens. Par exemple Bouml et StarUML sont incapables Marc ZIMMERMANN Rapport de stage de 3 ème année 14/53

26 d échanger des modèles, ArgoUML accepte la sortie XMI 1.2 de Bouml mais Bouml n accepte pas celle d ArgoUML. A cela il faut ajouter les nombreuses et variées non-conformités des écritures des fichiers XMI par les AGL. Elles diminuent d'autant plus l'interopérabilité. Ainsi on constate que, sans mécanisme intermédiaire, l'interopérabilité entre les AGL est plutôt pauvre. On note malgré tout une amélioration pour UML 2 XMI 2.1. Il reste à déterminer si cette amélioration résulte d une réelle volonté d interopérabilité ou du caractère récent de ces versions. 2.3 Organisation du travail Planning Suite à l'identification du travail à effectuer j'ai mis en place un planning prévisionnel de l'enchainement des tâches. Il est décrit dans le diagramme de Gantt donné plus loin. La première tâche est l'étude et la formation aux technologies et logiciels utilisés lors de ce stage. A savoir XML, XSLT, UML, XMI et OWL pour les technologies et XMLSpy, Protégé et quelques AGL pour les logiciels. Bien que cette tâche ne soit pas indiquée comme devant durer tout au long du stage il est plus que probable que des retours ponctuels y soient nécessaires. La seconde tâche est l'identification et l'étude des entrées/sorties XMI des AGL. Les tâches suivantes sont la réalisation des transformations UML vers OWL et OWL vers UML qui seront menées en parallèle. Ensuite la réalisation de l'application interviendra lorsque les transformations seront suffisamment avancées. Enfin tout au long du stage les présentations réalisées et documents écrits seront capitalisés en vue de la rédaction du rapport et de la préparation de la soutenance. L'enchaînement et la durée des tâches n'ont pas tout à fait suivit le planning tel qu'il était prévu. Le planning réel est donné ci-après. Tout d'abord l'identification des non-conformités c'est faite en cours de réalisation des transformations. Il a donc fallu retourner vers une analyse plus poussée des entrées/sorties XMI avec étude de la conformité. Cette étude a été suivie d une étape non prévue initialement : la réalisation de transformations de prétraitements. Malgré ce contretemps les tâches de réalisations des transformations ont avancé plus vite que prévu et la réalisation de l'application Java a débuté avec deux semaines d'avance. Les tâches correspondant aux conversions UML vers OWL et OWL vers UML ont, elles aussi, subit des modifications puisqu en cours de projet des éléments à traiter ont été identifiés et ajoutés : ce sont les énumérations, classes d associations et associations n-aires. La partie étude des contraintes d intégrités a été abandonnée car elles ne sont pas écrites dans les fichiers XMI. Marc ZIMMERMANN Rapport de stage de 3 ème année 15/53

27 Figure 18 : Planning prévisionnel Marc ZIMMERMANN Rapport de stage de 3 ème année 16/53

28 Figure 19 : Planning réel Marc ZIMMERMANN Rapport de stage de 3 ème année 17/53

29 2.3.2 Plan de développement La démarche générale qui a été suivie pour réaliser les outils de ce stage et guidée par un cycle de développement en V [MODL]. Ce type de cycle associe à chaque phase du développement une phase de test. Figure 20 : Cycle de développement en V Les phases de développement : - Prise en compte du besoin et rédaction du cahier des charges - Analyse et étude de faisabilité - Conception de l architecture du système - Conception des modules du système - Implémentation des modules Les objectifs des tests correspondant aux phases de développement sont les suivants : - le test unitaire : teste le bon fonctionnement d un module (indépendamment du système) - le test d intégration : teste le bon fonctionnement du système lors de l ajout d un module - le test fonctionnel : vérifie que le système rend bien les services attendus - le test de validation : vérifie que le système répond bien aux exigences du cahier des charges Pour la réalisation de chaque module les parties conception, implémentation et tests unitaires sont regroupées dans une itération. Une itération est la réalisation d une fonctionnalité du système qui, une fois validée, est intégrée au système. L intérêt de fonctionner par itérations est de ne pas pouvoir remettre en cause, à une itération donnée, ce qui a été développé antérieurement. Marc ZIMMERMANN Rapport de stage de 3 ème année 18/53

30 Figure 21 : Déroulement d'une itération Chaque itération a suivi un cycle de développement en Y. Le cycle de développement en Y traite en parallèle la capture des besoins fonctionnels (que doit faire le module?) et la capture des besoins techniques (comment réaliser cette fonctionnalité?). Une fois des réponses trouvées à ces deux questions l implémentation peut débuter. Figure 22 : Cycle de développement en Y Ce plan de développement a été suivi autant pour l application Java que pour la réalisation des transformations XSLT. En effet, pour XSLT la conversion de chaque objet UML a fait l objet d une itération et pour Java ce sont les différentes fonctionnalités. Marc ZIMMERMANN Rapport de stage de 3 ème année 19/53

31 3 Conception de la solution Cette partie présente la solution théorique créée pour réaliser les objectifs du stage. Elle introduit le principe de fonctionnement des outils et explique le choix des technologies qui ont été retenues pour les réalisations. 3.1 Architecture du workflow Le cahier des charges impose la production de deux types de sorties différentes : des fichiers OWL et des fichiers XMI. Pour produire toutes les versions des fichiers XMI à partir de n importe quelle version d un fichier d entrée il est intéressant de passer par un langage pivot. C est-à-dire effectuer une conversion du XMI dans un langage L, puis reconvertir de ce langage L vers XMI. Dans le cas de ces travaux, six versions d UML/XMI sont couramment utilisées par les AGL. Le nombre de transformations à écrire pour les versions UML/XMI considérées serait de 30 «directes» contre 12 avec un langage intermédiaire. C est OWL qui a été choisi comme langage intermédiaire. La première raison est que le cahier des charges demande la création de sortie OWL pour les modèles UML. La seconde raison est qu OWL donne une représentation sémantique du modèle. Les informations sont extraites en ignorant les aspects implémentation et développement d UML. Afin de produire des outils en accord avec les spécifications de l OMG les transformations UML vers OWL s appliqueront à des entrées XMI conformes et les transformations OWL vers UML produiront des sorties XMI conformes. Ces choix permettront aussi une meilleure réutilisabilité et maintenabilité des outils. Cependant peu d AGL produisent des sorties conformes. Il faut pourtant que ces outils puissent les traiter avec des pertes minimales. La solution choisie est de leur appliquer une phase de prétraitement, dite de conformité, dont l objectif est produire une sortie XMI conforme aux spécifications de l OMG. Les choix d implémentation des transformations impliquent que les fichiers en entrée aient un formatage minimum. Plus précisément, certains objets UML (packages, classes, ) devront avoir un nom et un identifiant. Une deuxième phase de prétraitement, dite de formatage, sera donc appliquée à la suite de la phase de conformité. Marc ZIMMERMANN Rapport de stage de 3 ème année 20/53

32 L architecture du workflow est décrite dans la figure ci-dessous. Figure 23 : Organisation du workflow Concrètement nous pouvons identifier les principales feuilles de style à réaliser, par exemple pour les prétraitements de conformité, une feuille de style pour : PowerAMC UML 1.3 XMI 1.0 PowerAMC UML 1.3 XMI 1.1 StarUML UML 1.3 XMI 1.1 Pour les prétraitements de formatage une feuille de style par version XMI, soit quatre au total. Pour UML2OWL six feuilles de style correspondant aux transformations de chaque version UML/XMI vers OWL. Pour OWL2UML six feuilles de style correspondant aux transformations d OWL vers chaque version UML/XMI. La succession des traitements de ce workflow est implémentée dans une application Java appelée MOST. Les liens avec les feuilles de styles responsables des transformations sont réalisés au moyen d un fichier de configuration. Marc ZIMMERMANN Rapport de stage de 3 ème année 21/53

33 Figure 24 : Contexte de l'application MOST L application accepte en entrée un fichier (XMI ou OWL) et des commandes de l utilisateur. En fonction des commandes elle produit des sorties obtenues par transformation du fichier en entrée avec les feuilles de styles et un processeur XSLT. Les parties suivantes présentent respectivement les solutions développées pour la réalisation des transformations XSLT et de l application MOST. 3.2 Transformations XSLT Prétraitements Comme mentionné précédemment une phase de prétraitement est appliquée aux sorties des AGL. Son objectif est de corriger la conformité du XMI et de lui donner un format standard. Ce prétraitement se compose de deux étapes successives : 1. La phase de prétraitement de conformité 2. La phase de prétraitement de formatage Le processus de prétraitement est décrit par l organigramme suivant : Figure 25 : Algorithme de prétraitement Marc ZIMMERMANN Rapport de stage de 3 ème année 22/53

34 Prétraitement de conformité La nature et les différences entre les non-conformités identifiées conduisent à associer une transformation de conformité à un triplet AGL, version XMI, version UML. Par exemple la sortie UML 1.3 XMI 1.0 de PowerAMC présente des non-conformités, il lui sera donc associé un fichier XSLT dans lequel seront écrites les transformations nécessaires pour la rendre conforme. De la même manière sa sortie UML 1.3 XMI 1.1 aura elle aussi un fichier de transformation adapté. Chaque fichier de transformation de conformité agira ainsi de manière ciblée sur une sortie XMI non-conforme Prétraitement de formatage Il s agit ici de rajouter des éléments dans les fichiers XMI, qui ne sont pas nécessaires à la conformité mais indispensables pour la conversion UML vers OWL. Ces éléments sont un nom et un identifiant. Le tableau suivant récapitule la nécessité pour les objets d avoir un nom et/ou identifiant. Objet Identifiant Nom UML:Model oui oui UML:Package oui oui UML:Class oui oui UML:Attribute non oui UML:Generalization oui non UML:Association oui non UML:AssociationEnd oui non UML:DataType oui non Figure 26 : Nécessité d un prétraitement de formatage La phase de prétraitement de formatage peut être appliquée de manière générique à une version de XMI. En effet le test et l ajout si besoin d un nom et d un identifiant ne requiert pas connaissance de la version d UML et de l AGL exportateur. Ainsi un seul fichier XSLT sera affecté à chaque version de XMI Correspondance UML-OWL Les diagrammes UML suivant mettent en évidence les objets UML et OWL2 [W3COWL] qui sont utilisés dans cette étude et les relations qui les lient. Marc ZIMMERMANN Rapport de stage de 3 ème année 23/53

35 Figure 28 : Objets OWL Figure 27 : Objets UML Les agrégations représentent les relations d appartenance d un nœud fils à un nœud parent au sens des arborescences. Par exemple en XMI un nœud attribut appartient à un nœud classe. On remarque sur ces figures que le nombre d objets UML est supérieur à celui des objets OWL, cela implique qu à un objet OWL seront associés plusieurs objet UML. Pour la réalisation des transformations UML vers OWL il faut bien garder à l esprit que la transformation inverse doit ensuite pouvoir être réalisée. Il faut donc veiller à ce que les transformations implémentées soient réversibles. Le tableau suivant résume les associations entre objets UML et OWL qui ont été choisies pour réaliser les conversions. Modèle et package UML OWL Modèle Ontologie Package Ontologie Classe Classe Attribut Datatype property Méthode (inutilisées) Généralisation (héritage) subclassof Association Object property Agrégation Object property Composition Object property Commentaire Annotation property Type de données Type de données XSD Enumération Value Partition (Design Pattern) Classe d'association 2 Object properties Association n-aire Object properties Figure 29 : Correspondance UML-OWL Les modèles et packages sont des conteneurs qui regroupent des classes appartenant à un même domaine. Ils représentent en quelque sorte un modèle de données, c est pourquoi ce sont les ontologies qui vont leur être associées. Marc ZIMMERMANN Rapport de stage de 3 ème année 24/53

36 Classe Les classes sont utilisées autant en UML qu en OWL pour représenter des objets ou un ensemble d individus. Elles seront donc associées l une à l autre. Attribut Les attributs sont des propriétés liant les classes à d autres objets (généralement des types de données). En OWL ce sont les datatype properties qui lient les classes aux types de données. La conversion entre attribut et datatype property se fera donc de la façon suivante : Figure 30 : Transformation des attributs Déclaration(s) : 1 datatype property : hasnom Restriction(s) : 1 restriction sur la classe Organisation : hasnom some String Méthode Les méthodes ne sont pas prises en compte dans ces transformations car les modèles utilisés ne sont pas destinés au développement logiciel mais à la représentation de connaissances. Généralisation Le concept de généralisation-spécialisation est présent en UML et en OWL. En OWL il est matérialisé par la relation de subsomption (intitulée subclassof en RDFS). Figure 31 : Transformation des généralisations Restriction(s) : 1 restriction sur la classe Entreprise : subclassof Organisation Marc ZIMMERMANN Rapport de stage de 3 ème année 25/53

37 Association, agrégation et composition En XMI les associations, agrégations et compositions sont très similaires. Elles définissent des relations entre les objets. En OWL les relations entre objets sont définies par des object properties. La conversion association-object property se fera comme suit : Figure 32 : Transformation des associations Déclaration(s) : 2 object properties o hasassociation_organisation_activité (inverseof isassociation_organisation_activité) o isassociation_organisation_activité (inverseof hasassociation_organisation_activité) Restriction(s) : 2 restrictions sur la classe Organisation o has Association_Organisation_Activité min 0 Activité o has Association_Organisation_Activité max 9999 Activité Restriction(s) : 3 restrictions sur la classe Exercice o isassociation_organisation_activité some Organisation o isassociation_organisation_activité min 1 Organisation o isassociation_organisation_activité max 1 Organisation Ici on ne retrouve que deux restrictions sur la classe Organisation car la cardinalité minimum est nulle. Or la restriction some implique une cardinalité au moins égale à 1. De plus on aperçoit l apparition d un 9999 à la place d une cardinalité *. C est un choix d implémentation, répondant à la contrainte qu OWL ne gère les cardinalités que sous forme d entier, pas de chaine de caractères. Cet exemple met en évidence les deux cas particuliers. Dans le cas général on retrouve trois restrictions et les mêmes cardinalités en UML et OWL. Les noms des object properties sont créés à partir du type de l association (association, agrégation ou composition) et des noms des classes liées. Ce choix a été fait car les noms des associations et des rôles ne sont pas toujours renseignés. Enumération L énumération en UML est une collection d objets. Il n existe pas nativement de collections en OWL mais un Design Pattern a été créer dans ce but, c est la Value Partition. Marc ZIMMERMANN Rapport de stage de 3 ème année 26/53

38 Figure 33 : Transformation des énumérations 1. Créer une classe correspondant au nom de l énumération 2. Créer des sous-classes correspondant aux objets de l énumération 3. Définir les classes comme non équivalentes (owl:disjointwith) 4. Créer un axiome de couverture pour que l énumération ne puisse pas avoir d autres items que ceux existants (owl:unionof) Classe d association Une classe d association en UML permet de donner des attributs pour qualifier une association. Le diagramme UML d une classe d association est représenté ci-dessous. Figure 34 : Classe d'association Pour «traduire» une classe d association en OWL on peut la décomposer en objets UML de base possédant déjà des objets OWL associés. Par exemple, la première solution envisagée, décompose la classe d association en une classe Localisation et une association entre Photo et Evénement. On associe ensuite les objets OWL correspondant, c est-à-dire trois classes OWL, des datatype properties pour les attributs de Localisation et des object properties pour l association. Cependant cette solution détruit en OWL le lien qui existait entre la classe Localisation et l association. Afin de conserver au mieux le sens de la classe d association nous allons nous intéresser à un diagramme UML équivalent à celui de la classe d association : Figure 35 : Equivalent classe d'association Marc ZIMMERMANN Rapport de stage de 3 ème année 27/53

39 Ce diagramme représente sans perte de sens la classe d association. C est donc celui-ci qui sera traduit en OWL. Il s agit ici de trois classes, deux attributs et deux associations. Ce sont des objets UML auxquels des objets OWL ont déjà été associés. Association n-aire Bien que la transformation des associations n-aire ne soit pas encore implémentée la solution qui est pressentie est de considérer toutes les associations qu elles recouvrent et les traduire en object properties. Figure 36 : Association n-aire Figure 37 : Equivalent association n-aire Commentaire Les commentaires en OWL sont matérialisés par des annotation properties. Parmi celles existantes deux sont utilisées dans ces outils : rdfs:comment pour les commentaires et rdfs:label pour les noms des objets. Type de donnée En UML il est possible de créer des types de données. En OWL2 ce sont les types de donnée XSD qui sont utilisés Algorithme de transformation UML2OWL Pour traiter un fichier avec la technologie XSLT il faut adapter son algorithme à la sortie que l on veut produire et non au fichier en entrée. En effet on peut rechercher un élément dans le fichier d entrée mais l écriture dans le fichier de sortie se fait toujours à la fin. L algorithme de conversion UML vers OWL se découpe en deux étapes principales : le traitement des packages et le traitement des classes. Les boites rectangulaires des organigrammes suivants implémentent les règles de transformations décrites dans la partie précédente. Marc ZIMMERMANN Rapport de stage de 3 ème année 28/53

40 Le traitement d un package se fait de la manière suivante : 1. Import de la nouvelle ontologie dans l ontologie courante 2. Création du fichier contenant la nouvelle ontologie 3. Pour tous les packages fils : application de l algorithme «Traiter package» 4. Pour toutes les associations : déclaration des object properties 5. Pour toutes les classes : application de l algorithme «Traiter classe» Le traitement des packages se fait de manière récursive, ce sont donc les packages «feuilles» (ceux qui n ont pas d enfants de type package) qui sont traités en premiers, ensuite on dépile les appels. Figure 38 : Algorithme UML2OWL : Traitement des packages A une classe UML on associe une classe OWL. Les classes UML sont traitées comme suit : 1. Pour tous ses attributs : déclaration de datatype properties (elles sont ainsi déclarées dans l ontologie) 2. Création de la classe OWL 3. Ecritures des restrictions liées aux datatype properties (attributs de la classe UML) 4. Ecritures des restrictions liées aux object properties (associations de la classe UML) 5. Ecritures des restrictions subclassof (liées aux héritages de la classe UML) Figure 39 : Algorithme UML2OWL : Traitement des classes Marc ZIMMERMANN Rapport de stage de 3 ème année 29/53

41 3.2.4 Algorithme de transformation OWL2UML La partie conversion OWL vers UML reprend les mêmes correspondances d objets qu UML vers OWL mais les mécanismes mis en jeu sont plus complexes. Une première difficulté provient du fait qu OWL possède moins de variétés d objets qu UML. A un objet OWL a été associé plusieurs objets UML. Donc lors du passage d OWL à UML il faut identifier quel est l objet UML à créer. Par exemple les classes et énumérations UML sont toutes deux représentées par des classes OWL. Donc lorsqu on traite une classe OWL il faut se poser la question : est-ce une classe UML ou une énumération? Une autre difficulté vient du fait que les properties sont déclarées dans les ontologies et ensuite utilisées dans les classes OWL. Donc pour reconstruire les associations il faut rassembler les informations présentes dans les déclarations et dans les restrictions. De plus on traite généralement plusieurs ontologies c est-à-dire plusieurs fichiers, donc ces informations se trouvent parfois dans des fichiers différents. Les algorithmes de conversion OWL vers UML font donc apparaitre plus de tests, plus de recherches et d accès à des fichiers. Cela rend naturellement la conversion d une ontologie en modèle UML conceptuellement plus complexe et plus lente à l exécution. classe. Deux traitements sont remarquables : le traitement d une ontologie et le traitement d une Traiter une ontologie c est : 1. construire le package UML correspondant 2. traiter les ontologies importées 3. traiter ses classes Figure 40 : Algorithme OWL2UML : Traitement des ontologies Marc ZIMMERMANN Rapport de stage de 3 ème année 30/53

42 Enfin on traite les classes avec l algorithme suivant. Le traitement d une classe OWL suit la logique suivante : 1. Création de la classe UML correspondante 2. Pour toutes les restrictions de type datatype property : créer un attribut 3. pour toutes les restrictions du type subclassof : créer une généralisation 4. pour toutes les restrictions du type object property : créer une association Figure 41 : Algorithme OWL2UML : Traitement des classes Marc ZIMMERMANN Rapport de stage de 3 ème année 31/53

43 3.3 Application Java Cas d utilisation Le développement de l application Java a été guidé par la démarche UML. La première phase de l analyse UML est l identification des cas d utilisations. Ils permettent de décrire le besoin fonctionnel des utilisateurs du système et ainsi d identifier les fonctionnalités principales de l application. L'application Model-Ontology Stylesheet Transformation (MOST) met en place l architecture du workflow et fournit une interface graphique pour la conversion de modèles UML en ontologies OWL. Les principaux cas d utilisation de MOST sont donnés dans la figure ci-dessous : Figure 42 : Cas d'utilisation de MOST MOST propose deux types de transformations : UML vers OWL et OWL vers UML. Pour chacune de ces transformations l utilisateur doit spécifier un fichier à transformer (XMI ou OWL) et choisir un fichier de transformation (XSLT). L'application dispose de la possibilité de configurer les transformations qu'elle propose aux utilisateurs. On distingue deux types d'utilisateurs de l'application MOST : l'utilisateur standard qui peut uniquement transformer des fichiers l'utilisateur spécialiste, qui hérite de l'utilisateur standard, peut configurer les transformations mises à disposition par l'application Marc ZIMMERMANN Rapport de stage de 3 ème année 32/53

44 Appliquer une transformation Les cas d utilisations du mode de transformation UML2OWL sont détaillés dans la figure cidessous : Figure 43 : Cas d'utilisation : Mode de transformation UML2OWL Le mode de transformation UML vers OWL permet de transformer un modèle UML en ontologie. Pour cela l utilisateur doit dans un premier temps choisir le fichier XMI qu il souhaite transformer. Une fois ce modèle choisi, l application affiche les versions d UML, d XMI et l AGL utilisés pour créer ce fichier. En fonction de ces informations elle détermine aussi quelles sont les meilleures transformations à appliquer au fichier et les présélectionne. Une fois le fichier renseigné, l utilisateur a la possibilité de vérifier sa validité par rapport à une DTD ou un XSD. Cette opération n est pas obligatoire. L utilisateur choisi ensuite les prétraitements de conformité et de formatage à appliquer au fichier avant transformation. L application de prétraitement de conformité n est pas obligatoire. Enfin l utilisateur choisi le fichier de transformation UML vers OWL parmi ceux proposés et lance la transformation. Le mode de transformation OWL2UML ne propose que la sélection du fichier d entrée et le choix de la transformation. Marc ZIMMERMANN Rapport de stage de 3 ème année 33/53

45 Configuration des paramètres Figure 44 : Cas d'utilisation : Gestion de la configuration L application MOST est configurable grâce à un fichier ini. Le chargement et la sauvegarde de ce fichier se font automatiquement au lancement et à l arrêt de l application. Configurer l application signifie choisir les transformations qu elle propose. En cours d utilisation les acteurs peuvent ajouter, modifier ou supprimer des transformations. A chaque modification le fichier de configuration est sauvegardé. Le but de la configurabilité de cette application est d absorber au maximum les nombreuses évolutions du contexte de l application, à savoir : version UML, version XMI et AGL. Ces opérations n affectent que les fichiers XSLT et ne nécessitent pas de modifier le code de l application et de la recompiler Classes candidates et diagrammes de classes A partir des cas d utilisation on peut identifier les classes candidates, se sont les classes au sens de la programmation objet qui constitueront l architecture du système. Les principales classes identifiées sont décrites si dessous : Le gestionnaire de fichier XMI : son rôle est d obtenir les informations sur le fichier XMI et de vérifier sa validité conformément à un schéma de validation. Marc ZIMMERMANN Rapport de stage de 3 ème année 34/53

46 Le gestionnaire de transformation : c est lui qui possèdera la responsabilité des transformations à appliquer au fichier d entrée. Le fichier de configuration : un fichier de configuration est un fichier possédant des sections qui contiennent des paramètres (clé=valeur). La structure de donnée choisie pour modéliser un fichier de configuration est une table de hachage contenant des tables de hachage donnant accès à des valeurs. Figure 45 : Fichier de configuration Figure 46 : Structure de donnée du fichier de configuration Le gestionnaire de configuration : il a la charge d interagir avec le fichier de configuration. C'est-à-dire le lire, le sauvegarder et mettre à disposition ses informations. L interface graphique : l application se présentera sous la forme d un «wizard».cela permettra à l utilisateur de suivre le processus de transformation de manière intuitive. Ce wizard sera modélisé à la manière d un diaporama, c est-à-dire une JFrame qui sert de conteneur à des JPanel qui défilent par actions sur des boutons Suivant et Précédent. Une classe principale MOST qui possède tous les composants principaux, c est-à-dire les gestionnaires et l interface graphique. C est le point d entrée de l application, il est modélisé grâce au Design Pattern singleton. L identification des classes candidates et l édition des diagrammes de classe permettent de créer le squelette de l application et d y placer ses principaux organes. Marc ZIMMERMANN Rapport de stage de 3 ème année 35/53

47 Figure 47 : Diagramme de classe de MOST Diagrammes de collaboration et de séquence Les diagrammes de collaboration donnent une vue spatiale des échanges de messages entre les classes du modèle. Ils répondent à la question : Qui communique et quels sont les messages? Figure 48 : Diagramme de collaboration : Modifier la configuration Les diagrammes de séquence donnent une vue temporelle des échanges de messages entre les classes du modèle. Ils répondent à la question : Quel est l ordre des échanges de messages? Marc ZIMMERMANN Rapport de stage de 3 ème année 36/53

48 Figure 49 : Diagramme de séquence : Modifier la configuration Les diagrammes de collaboration et de séquence permettent de décrire, pour chaque fonctionnalité de l application, les enchainements de messages échangés entre les classes. On a alors mis en place les communications entre les différents organes de notre application. L architecture de l application est désormais complètement décrite et prête pour l implémentation. 3.4 Choix des technologies Transformation de fichiers XML Pour réaliser les transformations UML vers OWL et OWL vers UML une technologie est proposée par le cahier des charges : XSLT. Cette technologie est très bien adaptée à ce problème car elle permet de transformer des fichiers XML en fichier XML, XMI et OWL étant basés sur la syntaxe XML, avec uniquement les données présentes dans le XML d origine et le fichier de transformation. C est la version 2.0 de XLST qui a été choisie pour réaliser ces transformations, la version 1.0 ne permettant pas de produire plusieurs fichiers de sorties. Pouvoir produire plusieurs fichiers en sortie est une nécessité puisqu à un package est associée une ontologie, or un fichier OWL ne peut contenir qu une seule ontologie Le processeur XSLT Les contraintes associées au choix du processeur XSLT sont les suivantes : il doit pouvoir être utilisé depuis une application Java et doit être libre. Les bibliothèques qui répondent à ces critères sont Saxon, Xalan et AltovaXML. Xalan ne supporte pas XSLT 2.0 dans sa version Java, elle a donc été écartée de la liste des possibilités. Marc ZIMMERMANN Rapport de stage de 3 ème année 37/53

49 Bien que les deux restantes soient libres d utilisation, compatible XSLT 2.0 et disponibles en librairie pour.net et pour Java c est Saxon qui a été choisie comme processeur XSLT plutôt qu AltovaXML. Le choix ne s est pas fait sur les performances de ces librairies mais sur leurs supports. En plus d être la plus répandue et la plus ancienne Saxon bénéficie d une Javadoc très complète [SAXON]. Si cela ne suffit pas le développeur peut entrer directement en contact avec le concepteur et développeur de Saxon, qui se trouve aussi être l auteur de la recommandation W3C sur XSLT L environnement de développement intégré Le choix de l environnement de développement s est fait entre Eclipse et Netbeans. Ils offrent tout deux de nombreuses fonctionnalités pour développer des applications Java mais c est Netbeans qui a été choisi en raison de la nature de l application à écrire. En effet l application MOST sera développée sous forme d un wizard, donc beaucoup de composants d interfaces graphiques seront nécessaires. Netbeans possède un éditeur d interfaces graphiques ce qui rend leur réalisation moins fastidieuse que sous Eclipse. Marc ZIMMERMANN Rapport de stage de 3 ème année 38/53

50 4 Réalisations Dans cette partie sont présentés les principales réalisations et les résultats concrets. 4.1 Réalisation des transformations Prétraitements Rappelons que les deux phases de prétraitements (conformité et formatage) ont pour but de limiter au maximum les éventuelles pertes de données dues aux non-conformités des XMI écrits par les AGL. Du point de vue technique ces deux phases de formatage sont bâties sur le même modèle. Il s agit de recopier intégralement le fichier en entrée en y ajoutant les éléments nécessaires aux traitements ultérieurs (éléments conformes, noms et identifiants). On distingue dans les transformations deux types de template rules : - La template rule dite générique, elle s applique récursivement à tous les éléments et attributs. Figure 50 : Template rule générique - La template rule dite spécialisée, elle s applique à un élément donné. Figure 51 : Template rule spécialisée A l exécution le processeur recherche la template rule la plus adaptée à un nœud. C est de cette manière que la template rule spécialisée remplace l appel de la template rule générique. Ainsi lors de la recopie de cet élément on va pouvoir lui appliquer un traitement adapté. Marc ZIMMERMANN Rapport de stage de 3 ème année 39/53

51 4.1.2 Transformation UML2OWL Les template rules ont été écrites conformément aux algorithmes présentés dans la partie 3. A titre d exemple la template rule associée au traitement des packages est donnée ci-dessous. Figure 52 : Template rules pour le traitement des packages Marc ZIMMERMANN Rapport de stage de 3 ème année 40/53

52 Dans la suite de cette partie nous allons présenter les transformations UML vers OWL au travers d un exemple basé sur un modèle UML de test. Dans cet exemple ce n est pas la pertinence de la modélisation qui est recherchée mais sa simplicité et sa capacité à couvrir les principaux cas de figures. Le modèle «Ecole» est décrit par les diagrammes de classes suivants : Figure 53 : Diagramme de classe Ecole Afin de visualiser les résultats de ces transformations nous allons utiliser l éditeur d ontologies Protégé 4 [PROTEG]. Il offre une vue de la hiérarchie des classes (vue graphique avec le plug-in Graph Viz), des object properties et des datatype properties. Modèles et packages Chaque modèle ou package est transformé en une ontologie stockée dans un fichier OWL. Les liens entre ces ontologies sont matérialisés par le mot clé owl:imports. Dans cet exemple nous disposons d un modèle : Ecole, et de trois packages Ecole Ingenieur, Acteur et Infrastructure. L édition de l ontologie Ecole fait apparaitre les imports suivants : Marc ZIMMERMANN Rapport de stage de 3 ème année 41/53

53 Figure 54 : Ontologies du modèle Ecole On remarque deux types d imports : - les imports directs : ontologies directement importées - les imports indirects : ontologies importées par des ontologies importées (directement ou indirectement) Classes et généralisations Conformément aux algorithmes définis plus haut une classe OWL est associée à chaque classe UML. Et les relations de généralisation-spécialisation sont décrites par le mot clé rdfs:subclassof. La hiérarchie des classes se présente alors sous la forme suivante : Attributs Figure 55 : Classe OWL du modèle Ecole (Graph Viz) Figure 56 : Datatype properties du modèle Ecole Figure 57 : Restriction liée aux attributs Marc ZIMMERMANN Rapport de stage de 3 ème année 42/53

54 On peut ici remarquer le fait qu OWL distingue bien deux datatype properties ayant le même nom, celle associée à Personne et celle associée à Ecole Ingenieur. Des restrictions sont ensuite associées aux classes OWL, par exemple pour la matière enseignée par un enseignant comme le montre les figures ci-dessus. Associations Pour chaque association on déclare deux object properties inverses nommées par les classes qu elles lient. Figure 58 : Object properties du modèle Ecole Des restrictions sont ensuite ajoutées aux classes avec les cardinalités correspondant aux associations. Par exemple : Figure 59 : Restrictions liées aux associations Plusieurs remarques peuvent être faites ici : - Le nombre de restrictions varie effectivement en fonction de la cardinalité minimum (si 0 alors pas de some) - Pour l auto-association Personne-Personne les deux propriétés inverses apparaissent (is et has). Marc ZIMMERMANN Rapport de stage de 3 ème année 43/53

55 Enumérations Les énumérations sont associées au design pattern value partition. Les principaux points de ce design pattern sont détaillés ici : La hiérarchie des classes : Les classes disjointes : Figure 60 : Classes de la Value Partition L axiome de couverture : Figure 61 : Classe OWL disjointes Figure 62 : Axiome de couverture Marc ZIMMERMANN Rapport de stage de 3 ème année 44/53