Pub 00029264

Institut Suprieur dInformatique de Modlisation et de leurs Applications Complexe des Czeaux 63173 Aubire Cedex
Rapport dingnieur Stage de 3me anne Filire : Calcul et modlisation scientifiques
Workflow XML pour linteroprabilit des donnes

Organisme daccueil : Cemagref
Prsent par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Tuteur ISIMA : Jonas KOKO
Dure : 4 mois Mai Septembre 2010
Institut Suprieur dInformatique de Modlisation et de leurs Applications Complexe des Czeaux 63173 Aubire Cedex
Rapport dingnieur Stage de 3me anne Filire : Calcul et modlisation scientifiques

Organisme daccueil : Cemagref
Prsent par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Tuteur ISIMA : Jonas KOKO
Dure : 4 mois Mai Septembre 2010
Remerciements
Je tiens remercier Catherine ROUSSEY et Jean-Pierre CHANET qui mont encadr, aid et guid tout au long de ce stage. Je remercie Jean-Claude CHAMPOMIER, Vincent SOULIGNAC, Gil de SOUSA et Andr MIRALLES pour mavoir donn accs leurs travaux et pour le temps quils mont accord. Les modles UML quils mont fournis ont t dune grande aide pour mes ralisations. Je tiens enfin remercier lensemble des personnes qui ont permis ce stage de se drouler dans dexcellentes conditions.
Marc ZIMMERMANN
Rapport de stage de 3
me
anne
Rsum
Mon stage de troisime anne lISIMA sest droul au Cemagref o jai t charg de raliser un workflow XML pour linteroprabilit des donnes. Pour crer larchitecture des logiciels, les dveloppeurs ont recourt des mthodes guides par les modles. Cette approche sintitule en anglais Model Driven Architecture (MDA). Le langage privilgi pour dcrire le MDA est lUnified Modeling Language (UML). Ainsi de nombreux Ateliers de Gnie Logiciel (AGL) permettent de dcrire ces modles grce UML, et un standard existe pour leur srialisation : XML Metada Interchage (XMI). Or les volutions nombreuses et indpendantes dUML et dXMI ont appauvri linteroprabilit des modles. Lobjectif du travail dcrit dans ce document est dtudier les compatibilits entre XMI et de fournir des outils afin damliorer linteroprabilit entre AGL. Cest la technologie eXtensible Stylesheet Language Transformation (XSLT) qui a t utilise pour raliser les outils. Les transformations des modles seffectuent au moyen dune conversion dans un langage intermdiaire : Web Ontologie Language (OWL). Ainsi les outils permettent de crer lontologie associe au modle et toutes les versions XMI existantes. Ces transformations sont intgres dans une application Java, nomme Model-Ontology Stylesheet Tranformation (MOST), totalement configurable afin de pouvoir sadapter aux volutions venir dUML et dXMI.
Mots cls : atelier de gnie logiciel, interoprabilit, Java, modle, ontologie, OWL, UML, workflow, XMI, XML, XSLT.
Marc ZIMMERMANN
me
anne
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
me
anne
Table des matires

Remerciements .............................................................................................................................. Rsum .......................................................................................................................................... Abstract ......................................................................................................................................... Table des matires ......................................................................................................................... Lexique .......................................................................................................................................... Introduction ................................................................................................................................. 1 1 Prsentation du contexte ..................................................................................................... 2 1.1 Prsentation de lorganisme daccueil ................................................................................... 2 1.1.1 Le Cemagref................................................................................................................... 2 1.1.2 Le centre de Clermont-Ferrand ..................................................................................... 3 1.1.3 LUR Technologies et systmes dinformation pour les agrosystmes ................... 3 1.1.4 Lquipe Systmes dinformation communicants et agri-environnementaux ........ 3 1.2 Contexte technique................................................................................................................ 4 1.2.1 Les technologies XML .................................................................................................... 4 1.2.2 Modles de donnes et interoprabilit ...................................................................... 6 1.2.3 Conclusion sur XML ....................................................................................................... 8 2 Analyse du problme............................................................................................................ 9 2.1 Cahier des charges ................................................................................................................. 9 2.2 Etude des entres et sorties XMI ........................................................................................... 9 2.2.1 Recensement des entres/sorties............................................................................... 10 2.2.2 Equivalence UML1-UML2 ............................................................................................ 11 2.2.3 Conformit des sorties XMI ......................................................................................... 12 2.2.4 Interoprabilit des modles UML.............................................................................. 14 2.3 Organisation du travail......................................................................................................... 15 2.3.1 Planning ....................................................................................................................... 15 2.3.2 Plan de dveloppement .............................................................................................. 18 3 Conception de la solution ................................................................................................... 20 3.1 Architecture du workflow .................................................................................................... 20 3.2 Transformations XSLT .......................................................................................................... 22 3.2.1 Prtraitements ............................................................................................................ 22 3.2.2 Correspondance UML-OWL......................................................................................... 23 3.2.3 Algorithme de transformation UML2OWL .................................................................. 28 3.2.4 Algorithme de transformation OWL2UML .................................................................. 30 3.3 Application Java ................................................................................................................... 32 3.3.1 Cas dutilisation ........................................................................................................... 32 3.3.2 Classes candidates et diagrammes de classes............................................................. 34 3.3.3 Diagrammes de collaboration et de squence ........................................................... 36 3.4 Choix des technologies ........................................................................................................ 37 3.4.1 Transformation de fichiers XML .................................................................................. 37 3.4.2 Le processeur XSLT ...................................................................................................... 37 3.4.3 Lenvironnement de dveloppement intgr ............................................................. 38 4 Ralisations........................................................................................................................ 39 4.1 Ralisation des transformations .......................................................................................... 39 4.1.1 Prtraitements ............................................................................................................ 39 4.1.2 Transformation UML2OWL ......................................................................................... 40 4.1.3 Transformation OWL2UML ......................................................................................... 45 4.1.4 Tests et validation ....................................................................................................... 46 4.2 Ralisation de lapplication MOST ....................................................................................... 47
Marc ZIMMERMANN
me
anne
4.2.1 Maquette et exemples de principes ........................................................................... 47 4.2.2 Gnration de larchitecture du code ......................................................................... 50 4.2.3 Implmentation des modules ..................................................................................... 50 5 Rsultats et prolongements ................................................................................................ 51 5.1 Etats des lieux ...................................................................................................................... 51 5.1.1 Ce qui a t ralis ...................................................................................................... 51 5.1.2 Ce quil reste faire .................................................................................................... 51 5.1.3 Amliorations possibles et prolongement .................................................................. 51 5.2 Bilan ..................................................................................................................................... 52 Conclusion ................................................................................................................................. 53 Index des illustrations .................................................................................................................... Rfrences bibliographiques ...........................................................................................................
Marc ZIMMERMANN
me
anne
Lexique
AGL : Atelier de Gnie Logiciel. Suite de logiciels permettant de construire des logiciels complexes en garantissant leur maintenabilit. Ces ateliers automatisent un grand nombre de tches du dveloppement logiciel. Design Pattern : En franais patron de conception, ils dcrivent des solutions standards pour rpondre des problmes rcurrents de conception darchitectures des logiciels. Le mme terme est utilis dans le domaine de la conception dontologies pour proposer des solutions des problmes de modlisation. DTD : Document Type Definition. C'est une grammaire qui dcrit les balises utilisables dans un document XML et leurs imbrications possibles. DTD est un type de schma XML qui possde son propre langage, non bas sur XML. Interoprabilit : En informatique cest la capacit dun systme fonctionner avec d'autres, existants ou futurs, sans restriction d'accs ou de mise en uvre. Ontologie : Ensemble formalis de termes du vocabulaire associ un domaine. L'ontologie constitue un modle reprsentant un ensemble de concepts dun domaine, ainsi que les relations entre ces concepts. OMG : Object Management Group. Association amricaine cre en 1989 destine promouvoir et standardiser le modle objet. OWL : Web Ontology Language. Langage permettant de dcrire des ontologies Web. Il est bas sur trois sous-langages possdant des pouvoirs d'expressions croissants : OWL-Lite, OWL-DL et OWL-Full. RDF : Resource Description Framework. RDF est un langage gnral pour la reprsentation dinformations Web. Il fait partie des recommandations du W3C et est srialis en XML. RDF Schema : RDFS est une extension de la smantique de RDF. Il permet de dcrire des ressources et les liens entre elles. RDFS est notamment utilis pour dcrire des ontologies. Srialisation : mcanisme permettant de stocker des informations dans un fichier. UML : Unified Modeling Language. Langage de modlisation dans le domaine du dveloppement logiciel. Spcification de l'OMG. W3C : World Wide Web Consortium. Organisme but non lucratif destin promouvoir la compatibilit des technologies Web. Workflow : Enchainement de tches raliser pour atteindre un objectif. XMI : XML Metadata Interchange. Standard d'change d'informations de mtadonnes UML bas sur XML. Permet l'change de donnes entres AGL. Standard de srialisation d'UML. XML : eXtensible Markup Language. Langage informatique permettant de stocker de manire arborescente des donnes de type texte grce des balises (reconnaissables par des chevrons <>).
Marc ZIMMERMANN
me
anne
XML Schema : Un XML Schema permet de dcrire la structure d'un fichier XML (lments, attributs, types de donnes,). C'est un document XML, alternative la DTD. XSD inclus une dclaration de types de donnes. XPath : XML Path Language. Langage de requtes pour slectionner des nuds 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 dun fichier XML vers un autre document (XML, HTML, texte).
Marc ZIMMERMANN
me
anne
Introduction
Dans le domaine du dveloppement logiciel la conception des architectures est guide par les modles. Cette dmarche s'appelle Model Driven Architecture (MDA). Le langage privilgi pour dcrire le MDA est UML. Des ateliers de gnie logiciel permettent de raliser ces modles et de gnrer le code correspondant dans divers langages objets. Pour stocker et changer les modles UML un standard dit par lOMG existe : XML Metadata Interchange (XMI). Cependant les normes UML et XMI ont volu sparment. Les modles peuvent donc tre dcrits dans plusieurs versions dUML et srialiss dans plusieurs versions de XMI. Cette situation pose des problmes d'interoprabilit des donnes entre les AGL. Le premier objectif de ce stage est de fournir des outils de transformation de fichiers XMI afin damliorer linteroprabilit entre AGL. Le second objectif est dextraire les connaissances prsentes dans ces modles. Afin de reprsenter les modles sans leur aspect implmentation li UML, ils seront convertis dans un formalisme de reprsentation des connaissances bas sur XML : le Web Ontology Language (OWL). Ces outils seront raliss grce la technologie eXtensible Stylesheet Language Transformations (XSLT). Concrtement, partir d'un modle UML stock dans un fichier XMI ces outils doivent permettre de produire des fichiers OWL reprsentant la smantique du modle UML. Ensuite ces fichiers OWL seront traduits dans les diffrents formats existants de XMI. Pour raliser ces objectifs la premire tche consistera tudier la compatibilit entre les formats XMI et les AGL. La seconde tche sera de crer les outils permettant de produire les fichiers OWL. Enfin la dernire tape sera la ralisation des outils pour transformer les fichiers OWL en fichiers XMI. Lensemble de ces outils de transformations sera intgr dans une application crite en Java, nomme Model-Ontology Stylesheet Transformation (MOST). Ce rapport prsente ltude et les rsultats de ce stage avec dans une premire partie la prsentation du contexte du stage, dans une seconde lanalyse du problme. La solution envisage pour rpondre au problme sera dcrite dans la troisime partie et les principales ralisations seront expliques dans la quatrime. Enfin la dernire partie dressera un bilan des travaux raliss.
Marc ZIMMERMANN
me
anne
1/53
1 Prsentation du contexte
Lobjectif de cette partie est de prsenter le contexte de cette tude. Elle prsente dans un premier temps lorganisme dans lequel ces travaux ont t raliss. Dans un second temps elle prsente le contexte technique de ltude, cest--dire les principales technologies mises en jeu.
1.1 Prsentation de lorganisme daccueil

1.1.1 Le Cemagref
Linstitut de recherche en sciences et technologies pour lenvironnement, plus connu sous le nom de Cemagref, a t cr en 1981. Cest un tablissement public caractre scientifique et technologique plac sous la double tutelle des ministres en charge de la recherche et de l'agriculture. Son activit se regroupe autour de trois thmes structurs en trois dpartements : Eaux (ressources, milieux, usages et risques) Ecotechnologies (rseaux, puration, dchets) Territoires (dveloppement territorial, biodiversit, risques et vulnrabilits) Eaux, territoires et cotechnologies sont des thmatiques qui rpondent aux besoins de la socit. Les moyens mis en uvres par le Cemagref pour rpondre ces problmatiques stendent de la recherche laction. En effet il fournit un appui scientifique et technique la dcision (tudes, expertises, modles et outils oprationnels) et des solutions dingnierie qui intgrent des composantes pluridisciplinaires. Labellis Carnot en 2006, le Cemagref a de nombreux partenaires industriels leaders dans la gestion de leau, des dchets et des quipements agricoles. Actif aussi au niveau Europen, il est partenaire du rseau Partnership for European Environmental Research (PEER) qui regroupe sept grands instituts europens de recherche ddis aux interactions entre lhomme et son environnement. Dautre part le Cemagref est fortement impliqu dans lenseignement suprieur, notamment en termes de participation la formation. Il dveloppe des alliances autant avec les ples de recherche et denseignement suprieur franais quavec des universits trangres.
Le Cemagref en quelques chiffres cest : 9 centres et 2 implantations hors centres (Strasbourg et Martinique) 20 units de recherche propres (UR) 5 units de recherche mixtes (Cirad, Inra, IRD, Engees, AgroParisTech, SupAgro) 1400 collaborateurs dont 500 ingnieurs 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
me
anne
2/53
1.1.2 Le centre de Clermont-Ferrand

Le centre de Clermont-Ferrand est implant sur deux sites : le site d'Aubire (Puy de Dme) et le site de Montoldre (Allier). Le Cemagref mne en Auvergne des recherches autour de deux axes : les innovations technologiques pour l'agriculture raisonne et pour l'environnement le dveloppement rgional et l'amnagement du territoire Le centre de recherche de Clermont-Ferrand dispose de deux units de recherche (UR) : Laboratoire d'Ingnierie des Systmes Complexes (LISC) Technologies et systmes dinformation pour les agrosystmes (TSCF), compose de quatre quipes : o Technologies pandage, agroquipements, mobilit o Matriaux et milieux o Systmes dinformation communicants et agri-environnementaux o Sciences-technologies et procds d'pandage
Et dune unit de recherche mixte : Mutations des activits, des espaces et des formes dorganisation dans les territoires ruraux (UMR Mtafort). Les thmes de recherche abords sont les suivants : Dveloppement Territorial et Agriculture Multifonctionnelle Innovations technologiques pour l'agriculture durable et l'environnement Modles, systmes d'information et gestion viable de l'environnement
1.1.3 LUR Technologies et systmes dinformation pour les agrosystmes

Lunit Technologies et systmes dinformation pour les agrosystmes mne des recherches sur les mthodes et outils pour une ingnierie des systmes complexes que sont les systmes agri-environnementaux. Elles portent sur les technologies de la mobilit pour la scurit et la qualit du travail des machines, sur les technologies dpandage de matriaux organiques ou minraux. Les systmes cologiques y sont galement abords, travers les technologies pour la perception et la caractrisation du sol. Enfin des recherches sont conduites sur les systmes dinformation et de communication partags en collaboration avec les recherches menes plus largement lUMR Territoires, environnement, tldtection et information spatiale associant des quipes Cemagref, CIRAD et AgroPariTech.
1.1.4 Lquipe Systmes dinformation communicants et agri-environnementaux

Lactivit de lquipe Systmes dinformation communicants et agri-environnementaux est consacre aux mthodes dingnierie des systmes dinformation spatialiss ddies la gestion agri-environnementale. Cet ensemble de mthodes couvre lanalyse des besoins des acteurs, la spcification des systmes dinformation, leur modlisation, leur conception, leur gestion et leur lien avec les sources de donnes. Lobjectif de l'quipe est de dvelopper des mthodes et des techniques selon deux axes :
Marc ZIMMERMANN
me
anne
3/53
dployer et grer des rseaux de capteurs communicants adapts aux problmes agrienvironnementaux concevoir et grer des systmes dinformation, tels que des entrepts de donnes ou des systmes de gestion des connaissances, adapts au contexte de lagri-environnement
Les thmes de recherche associs sont les modles, les systmes d'information et la gestion viable de l'environnement. Les domaines de spcialit de lquipe sont le gnie logiciel, la modlisation UML, les entrepts de donnes spatiales, linformatique, les tlcommunications et les rseaux de capteurs.
1.2 Contexte technique

1.2.1 Les technologies XML
1.2.1.1 eXtensible Markup Language
Le langage informatique de balisage XML est un standard recommand par le W3C [W3CXML]. Son objectif est de favoriser linteroprabilit des donnes entre des systmes dinformation diffrents. Il permet de stocker des informations arborescentes dans des fichiers de type texte. La structure de ses facilement reconnaissable par chevrons (< et >). Les principaux structure dun document XML dans la figure ci-contre. balises est lusage des lments de sont dcrits
Figure 2 : Syntaxe d'un fichier XML
Le langage XML est trs largement utilis dans de nombreux domaines de linformatique et de nombreux autres langages se basent sur sa syntaxe. Un document XML doit respecter un certain nombre de rgles dites par le W3C. Parmi celles-ci on peut citer la correspondance des balises ouvrantes et fermantes, lexistence dune racine unique, etc. En plus de respecter ces rgles un document XML a la possibilit de devoir tre valide par rapport un schma. Deux types de schma sont principalement utiliss : DTD et XSD (aussi appel XML Schema). La DTD est une mthode de validation de la syntaxe et de la structure dun fichier XML, elle dfinit les balises et attributs utilisables dans un document XML et leurs imbrications possibles. DTD nest pas base sur la syntaxe dXML. Le XML Schema est le successeur de la DTD et est plus restrictif car il impose les types de donnes des lments. XSD est un document XML.
Marc ZIMMERMANN
me
anne
4/53
1.2.1.2
eXtensible Stylesheet Language Transformation
Un document XML peut tre transform en un autre document XML grce la technologie XSLT. XSLT sappuie sur des feuilles de style, ce sont des documents XML qui contiennent les transformations qui doivent tre ralises. Une transformation XSLT se passe gnralement de la faon 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 srialis dans un fichier XML, HTML ou texte. Les processeurs XSLT acceptent cependant plusieurs documents XML et plusieurs feuilles de style en entre 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 appeles template rules. Une template rule est constitue de deux parties : un pattern et un template. Le pattern est un motif qui sert identifier les nuds de larbre dentre auxquels va sappliquer la template rule. Le template est le fragment darbre qui va tre crit dans larbre rsultat. Un template peut contenir des rsultats sous forme de texte ou encore des instructions XSLT, par exemple pour le traitement des nuds enfants du nud courant.
Figure 4 : Exemple de template rule XSLT
Dans cet exemple pour chaque nud Pattern on crit deux nuds dans larbre rsultat, ResultTreeFragment et PatternNodeValue contenant le contenu du nud Pattern. En labsence dune template rule adapte un nud cest une template rule native qui est applique ce nud. Elle permet de continuer le parcours rcursif de larbre.
Figure 5 : Template rule native
Le document est ainsi parcouru en appliquant chaque nud la template rule ayant le meilleur pattern correspondant. La recherche des nuds dans les arbres XML se fait grce la technologie XML Path Language (XPath).
Marc ZIMMERMANN
me
anne
5/53
1.2.2 Modles de donnes et interoprabilit

1.2.2.1 Modle UML
Unified Modeling Language (UML) est un langage graphique permettant de spcifier, construire et documenter les objets dun systme informatique. UML reprsente lunification des techniques les plus utilises et les mieux conues de modlisation orient objet. UML fait partie dune architecture de mtadonnes plus grande encore : Meta Object Facility (MOF). UML et MOF sont des spcifications de lObject Managment Group *OMGMMS+.
Figure 6 : Architecture MOF
Un modle est une abstraction dun systme physique rel dans un certain but. Un mta-modle est un modle qui dfini le langage de description des modles. Un mta mta-modle est un modle qui dfini le langage de description des mta-modles. Chaque couche de cette architecture est considre comme une instance de la couche suprieure. Les modles UML sont srialiss dans des fichiers XMI (XML Metadata Interchange). XMI est aussi un standard de lOMG pour linteroprabilit et la srialisation des modles UML [OMGMMS]. Le langage XMI est bas sur la syntaxe XML.
1.2.2.2
Web Ontology Language (OWL)
Une ontologie est un modle permettant de dcrire de manire formelle les concepts dun domaine et les relations entre ces concepts. OWL est une famille de langages permettant de dcrire des ontologies. OWL est une recommandation du W3C [W3COWL]. OWL est bas sur des logiques de description (oprateurs du type intersection, union, ngation, quivalence, ). Ces logiques de description permettent de faire des raisonnements et de classifier les instances des concepts. Les raisonnements en OWL sont sujets deux hypothses : lOpen World Assumption : signifie que ce qui nest pas dit est suppos indfini, autrement dit le fait que quelque chose ne soit pas dclar comme vraie ne suffit pas conclure quelle est fausse. lUnique Name Assumption nest pas respecte par OWL : deux noms diffrents ne font pas ncessairement rfrences deux objets diffrents.
Marc ZIMMERMANN
me
anne
6/53
Il existe trois types dontologies OWL : OWL Lite, OWL DL et OWL Full. Ces trois types ont des pouvoirs dexpression croissants. Cependant du fait de sa grande expressivit OWL Full nest pas un langage dcidable, cest--dire que laboutissement dun algorithme sur une ontologie OWL Full nest pas garanti en temps fini. Dans le langage OWL les classes dfinissent les concepts du domaine et les individus sont des instances de ces classes. Les relations entre les classes sont dfinies par des properties. Les properties peuvent tre schmatises de la manire suivante :
Figure 7 : Exemple OWL
Deux types de properties sont remarquables : les datatype properties lient les individus des types de donne et les objects properties lient des individus dautres individus. En OWL il existe des conditions ncessaires et/ou suffisantes qui permettent de dterminer si un individu appartient une classe. Ces conditions sont appeles 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 dune ontologie et par exemple, en fonction de ses ingrdients un plat pourra tre reconnu comme une Pizza. Une ontologie OWL peut tre srialise dans un fichier. La srialisation dontologies est base sur Resource Description Framework (RDF) et RDF Schema (RDFS). RDF et RDFS ont des syntaxes bases sur XML.
Marc ZIMMERMANN
me
anne
7/53
1.2.3 Conclusion sur XML

On remarque que beaucoup des technologies impliques dans ce document sont bases sur la syntaxe dXML. On peut les reprsenter de la faon suivante :
Figure 8 : Les langages bass sur XML
XML fournit la syntaxe du langage (balises) et les autres langages dfinissent un vocabulaire (noms des balises).
Marc ZIMMERMANN
me
anne
8/53
2 Analyse du problme
Cette partie dtaille lanalyse du problme avec dans une premire partie la rdaction du cahier des charges qui identifie les travaux raliser. Dans une deuxime partie une tude de linteroprabilit entre ateliers de gnie logiciel est rsume. Enfin la dernire 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 modles stocks dans diffrents formats XMI pour faciliter linteroprabilit des AGL. Pour cela une tude de compatibilit entre les formats XMI et les outils AGL sera demande en premier lieu. Ltude 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 vrifier que lensemble des lments dcrits dans un format XMI 1.0 peut tre dcrit dans un format XMI 2.1 et inversement. 3. ltude devra aussi sintresser plus particulirement la description des contraintes dintgrit en UML et leurs diffrentes formes de stockage en XMI. Dans un second temps les outils qui seront dvelopps devront permettre de produire deux types de fichiers : 1. des fichiers OWL, 2. les diffrentes versions des fichiers XMI. Une attention particulire sera porte sur la restitution des commentaires des objets UML. La ralisation de ces outils sappuiera sur les technologies XML associes comme XSLT. Pour plus d'ergonomie ces diffrents outils seront ensuite intgrs dans une application dveloppe en langage Java.
2.2 Etude des entres et sorties XMI

L'tude suivante va tre ralise sur les entres/sorties XMI des ateliers de gnie logiciel cidessous : ArgoUML Bouml Enterprise Architect Mega Modelio (successeur d'Objecteering) Objecteering Poseidon (construit partir d'ArgoUML) PowerAMC StarUML
Marc ZIMMERMANN
me
anne
9/53
Cette liste n'a pas pour but d'tre exhaustive mais prsente des AGL trs utiliss dans le domaine du dveloppement logiciel. Les AGL utiliss au Cemagref sont Enterprise Architect, Mega, Objecteering (maintenant Modelio) et PowerAMC.
2.2.1 Recensement des entres/sorties

La premire tape de l'analyse des fichiers XMI produits par les divers AGL a t de faire un recensement des versions utilises pour l'import et l'export de modles depuis les AGL. Elle est synthtise dans le tableau suivant.
AGL ArgoUML Import XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1 XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1 Export UML UML 1.3 UML 1.4 UML 1.4 UML 1.4 UML 2.x UML 1.3 UML 1.3 UML 1.4 UML 2.x UML 1.3 UML 2 UML 2.x UML 1.3 UML 1.3 UML 1.4 UML 1.3 UML 2.x UML 1.3 Version(s) correspondante(s) ArgoUML 0.28 Version courante ArgoUML 0.30.1 (06/05/2010) BOUML 4.21 (12/05/2010) Enterprise Architect 8 build 856 (05/05/2010) Mega 2009 SP3 (02/2010) Modelio 1.2 (19/05/2010) Objecteering 6.1 SP4 (25/11/2009) Poseidon 8.0
BOUML Enterprise Architect
Mega Modelio Objecteering Poseidon XMI 2.1 XMI 2.1 XMI 1.0 XMI 1.1 XMI 1.2 XMI 1.1 XMI 2.1 XMI 1.1
XMI 1.2 XMI 1.2 XMI 2.1 XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1 XMI 1.0 XMI 2.1 XMI 2.1
BOUML 4.21 Enterprise Architect 7 et ultrieures
Modelio 1.2 Objecteering 6.1 Poseidon 6.0 et ultrieures
PowerAMC StarUML
XMI 1.2 XMI 1.1 XMI 2.1 XMI 1.1
PowerAMC 9.0 15 PowerAMC 15.1 et 15.2 StarUML 5.0
PowerAMC 15.2 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 gnie logiciel pour reprsenter le modle, il est ensuite crit dans une version de XMI. Ici UML 2.x reprsente 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
me
anne
10/53
On remarque dj des associations privilgies entre UML et XMI. Afin dtre plus complet jai recens les versions de UML et de XMI existantes grce aux spcifications de lOMG *OMGMMS].
UML 1.3 UML 1.4 UML 1.5 UML 2.0 UML 2.1.1 UML 2.1.2 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 2.1.1 Figure 10 : Associations entre UML et XMI
Les cases grises indiquent que les associations UML/XMI correspondantes nexistent pas. Les annotations DTD et XSD indiquent que les spcifications de lOMG incluent un document de validation des fichiers XMI. La premire remarque qui peut tre faite sur ce tableau est quil nexiste pas toujours une unique version de XMI permettant de srialiser les modles dune version dUML donne. Il convient aussi de noter que parmi toutes les spcifications dUML et dXMI seulement une partie est effectivement utilise par les AGL pour la srialisation de modles 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 2.1
2.2.2 Equivalence UML1-UML2

L'analyse du contenu des fichiers XMI rvle d'abord que l'ensemble des objets qui vont tre utilises par la suite, sont prsents quelque soit la version dUML comme le montre le tableau suivant :
UML 1.3 UML 1.4 UML 2.0 UML 2.1 Modle Package Classe Attribut Gnralisation Association Commentaire Type de donnes Enumration oui oui oui oui oui oui oui oui oui (1) oui oui oui oui oui oui oui oui oui (1) oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui oui
Classe d'association oui
Association n-aire oui oui oui oui Figure 11 : Equivalence des versions d'UML
Marc ZIMMERMANN
me
anne
11/53
(1) Est parfois implment sous forme de strotype de classe. Il n'est pas fait mention ici des mthodes car elles ne sont pas utilises. En effet le but des modles sur lesquels je vais travailler n'est pas de faire du dveloppement mais de la reprsentation de connaissances. Tous les objets sur lesquels se focalise cette tude sont prsents dans toutes des versions dUML. Ainsi un modle dcrit en UML 1 peut tre entirement dcrit avec UML 2 (ce qui est logique compte tenu de la compatibilit ascendante) et vice versa.
2.2.3 Conformit des sorties XMI

Un problme a t identifi lors de lanalyse de lquivalence des versions UML : pour une mme version dUML et de XMI la manire de dcrire les objets varie en fonction de l'AGL.
Figure 13 : Gnralisation sous StarUML
Figure 12 : Gnralisation sous PowerAMC
Il m'a donc fallu trouver un moyen de distinguer quelle est la bonne syntaxe pour dcrire ces objets. Mes recherches m'ont conduit vers des mthodes de validation des fichiers XML qui sont la DTD et le XSD. Ce sont deux manires plus ou moins restrictives de dcrire le contenu d'un fichier XML. Si un fichier XML respecte les rgles dictes par une DTD ou un XSD alors il est considr 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 dune gnralisation est la suivante :
Figure 14 : Gnralisation UML 1.3 XMI 1.1 conforme
Grce ces schmas j'ai t en mesure de vrifier la validit des sorties des AGL par rapport aux spcifications de l'OMG.
Marc ZIMMERMANN
me
anne
12/53
Les rsultats de la validation des sorties XMI sont rsums dans les tableaux ci-dessous :
UML 1.3 XMI 1.0 Enterprise Architect Enterprise Architect XMI 1.1
Objecteering
Objecteering
PowerAMC
PowerAMC PowerAMC
ArgoUML
ArgoUML
StarUML
UML / AGL Modle Package Classe Attribut Gnralisation Association Commentaire Enumration Classe d'association Association n-aire
(*)
(*)
(*)
Figure 15 : Conformit des AGL pour UML 1.3 UML 1.4 XMI 1.2 Enterprise Architect Enterprise Architect UML 2.1 XMI 2.1
Objecteering
Objecteering
PowerAMC
ArgoUML
ArgoUML
StarUML
UML / AGL Modle Package Classe Attribut Gnralisation Association Commentaire Enumration Classe d'association Association n-aire
(*) (*)
Figure 16 : Conformit des AGL pour UML 1.4 et UML 2.1
Marc ZIMMERMANN
me
anne
StarUML 13/53
Modelio
Modelio
BOUML
BOUML
Mega
Mega
StarUML
Modelio
Modelio
BOUML
BOUML
Mega
Mega
Lgende Conformit Conforme Non conforme (mais passe en traitement gnral) Non conforme (ncessite un traitement spcifique) Sortie non gnre Information manquante (*) Strotype : 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-conformits qui sont traitables de la mme manire que les conformits sont peu graves. Tandis que les autres ncessiteront un traitement spcifique.
2.2.4 Interoprabilit des modles UML

Lanalyse des imports et exports des ateliers de gnie logiciel permet de conclure sur linteroprabilit des donnes. Tout d'abord UML et XMI vont toujours de pair, c'est--dire que pour dcrire un modle il faut une version d'UML et une version dXMI. Cela a un impact direct sur l'interoprabilit puisque, les normes d'UML et d'XMI voluant sparment, c'est de nombreuses combinaisons d'UML/XMI qui coexistent. Cependant on remarque aussi que toutes les associations UML/XMI ne sont pas utilises. Pour mieux valuer linteroprabilit on peut reprsenter chaque version de XMI comme un medium de communication et ainsi obtenir le rseau suivant :
Figure 17 : Rseau des AGL
Pour un AGL la colonne de gauche reprsente les ports dentres XMI et celle de droite les ports de sorties. Les ports qui sont ouverts sont reprsents en vert, ceux ferms en rouge. Sur ce rseau 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
me
Marc ZIMMERMANN
anne
14/53
dchanger des modles, ArgoUML accepte la sortie XMI 1.2 de Bouml mais Bouml naccepte pas celle dArgoUML. A cela il faut ajouter les nombreuses et varies non-conformits des critures des fichiers XMI par les AGL. Elles diminuent d'autant plus l'interoprabilit. Ainsi on constate que, sans mcanisme intermdiaire, l'interoprabilit entre les AGL est plutt pauvre. On note malgr tout une amlioration pour UML 2 XMI 2.1. Il reste dterminer si cette amlioration rsulte dune relle volont dinteroprabilit ou du caractre rcent de ces versions.
2.3 Organisation du travail

2.3.1 Planning
Suite l'identification du travail effectuer j'ai mis en place un planning prvisionnel de l'enchainement des tches. Il est dcrit dans le diagramme de Gantt donn plus loin. La premire tche est l'tude et la formation aux technologies et logiciels utiliss lors de ce stage. A savoir XML, XSLT, UML, XMI et OWL pour les technologies et XMLSpy, Protg et quelques AGL pour les logiciels. Bien que cette tche ne soit pas indique comme devant durer tout au long du stage il est plus que probable que des retours ponctuels y soient ncessaires. La seconde tche est l'identification et l'tude des entres/sorties XMI des AGL. Les tches suivantes sont la ralisation des transformations UML vers OWL et OWL vers UML qui seront menes en parallle. Ensuite la ralisation de l'application interviendra lorsque les transformations seront suffisamment avances. Enfin tout au long du stage les prsentations ralises et documents crits seront capitaliss en vue de la rdaction du rapport et de la prparation de la soutenance. L'enchanement et la dure des tches n'ont pas tout fait suivit le planning tel qu'il tait prvu. Le planning rel est donn ci-aprs. Tout d'abord l'identification des non-conformits c'est faite en cours de ralisation des transformations. Il a donc fallu retourner vers une analyse plus pousse des entres/sorties XMI avec tude de la conformit. Cette tude a t suivie dune tape non prvue initialement : la ralisation de transformations de prtraitements. Malgr ce contretemps les tches de ralisations des transformations ont avanc plus vite que prvu et la ralisation de l'application Java a dbut avec deux semaines d'avance. Les tches correspondant aux conversions UML vers OWL et OWL vers UML ont, elles aussi, subit des modifications puisquen cours de projet des lments traiter ont t identifis et ajouts : ce sont les numrations, classes dassociations et associations n-aires. La partie tude des contraintes dintgrits a t abandonne car elles ne sont pas crites dans les fichiers XMI.
Marc ZIMMERMANN
me
anne
15/53
Figure 18 : Planning prvisionnel
Marc ZIMMERMANN
me
anne
16/53
Figure 19 : Planning rel
Marc ZIMMERMANN
me
anne
17/53
2.3.2 Plan de dveloppement

La dmarche gnrale qui a t suivie pour raliser les outils de ce stage et guide par un cycle de dveloppement en V [MODL]. Ce type de cycle associe chaque phase du dveloppement une phase de test.
Figure 20 : Cycle de dveloppement en V
Les phases de dveloppement : Prise en compte du besoin et rdaction du cahier des charges Analyse et tude de faisabilit Conception de larchitecture du systme Conception des modules du systme Implmentation des modules Les objectifs des tests correspondant aux phases de dveloppement sont les suivants : le test unitaire : teste le bon fonctionnement dun module (indpendamment du systme) le test dintgration : teste le bon fonctionnement du systme lors de lajout dun module le test fonctionnel : vrifie que le systme rend bien les services attendus le test de validation : vrifie que le systme rpond bien aux exigences du cahier des charges
Pour la ralisation de chaque module les parties conception, implmentation et tests unitaires sont regroupes dans une itration. Une itration est la ralisation dune fonctionnalit du systme qui, une fois valide, est intgre au systme. Lintrt de fonctionner par itrations est de ne pas pouvoir remettre en cause, une itration donne, ce qui a t dvelopp antrieurement.
Marc ZIMMERMANN
me
anne
18/53
Figure 21 : Droulement d'une itration
Chaque itration a suivi un cycle de dveloppement en Y.
Le cycle de dveloppement en Y traite en parallle la capture des besoins fonctionnels (que doit faire le module ?) et la capture des besoins techniques (comment raliser cette fonctionnalit ?). Une fois des rponses trouves ces deux questions limplmentation peut dbuter.
Figure 22 : Cycle de dveloppement en Y
Ce plan de dveloppement a t suivi autant pour lapplication Java que pour la ralisation des transformations XSLT. En effet, pour XSLT la conversion de chaque objet UML a fait lobjet dune itration et pour Java ce sont les diffrentes fonctionnalits.
Marc ZIMMERMANN
me
anne
19/53
3 Conception de la solution
Cette partie prsente la solution thorique cre pour raliser les objectifs du stage. Elle introduit le principe de fonctionnement des outils et explique le choix des technologies qui ont t retenues pour les ralisations.
3.1 Architecture du workflow

Le cahier des charges impose la production de deux types de sorties diffrentes : des fichiers OWL et des fichiers XMI. Pour produire toutes les versions des fichiers XMI partir de nimporte quelle version dun fichier dentre il est intressant de passer par un langage pivot. Cest--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 dUML/XMI sont couramment utilises par les AGL. Le nombre de transformations crire pour les versions UML/XMI considres serait de 30 directes contre 12 avec un langage intermdiaire. Cest OWL qui a t choisi comme langage intermdiaire. La premire raison est que le cahier des charges demande la cration de sortie OWL pour les modles UML. La seconde raison est quOWL donne une reprsentation smantique du modle. Les informations sont extraites en ignorant les aspects implmentation et dveloppement dUML. Afin de produire des outils en accord avec les spcifications de lOMG les transformations UML vers OWL sappliqueront des entres XMI conformes et les transformations OWL vers UML produiront des sorties XMI conformes. Ces choix permettront aussi une meilleure rutilisabilit et maintenabilit des outils. Cependant peu dAGL 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 prtraitement, dite de conformit, dont lobjectif est produire une sortie XMI conforme aux spcifications de lOMG. Les choix dimplmentation des transformations impliquent que les fichiers en entre aient un formatage minimum. Plus prcisment, certains objets UML (packages, classes,) devront avoir un nom et un identifiant. Une deuxime phase de prtraitement, dite de formatage, sera donc applique la suite de la phase de conformit.
Marc ZIMMERMANN
me
anne
20/53
Larchitecture du workflow est dcrite dans la figure ci-dessous.
Figure 23 : Organisation du workflow
Concrtement nous pouvons identifier les principales feuilles de style raliser, par exemple pour les prtraitements 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 prtraitements 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 dOWL vers chaque version UML/XMI. La succession des traitements de ce workflow est implmente dans une application Java appele MOST. Les liens avec les feuilles de styles responsables des transformations sont raliss au moyen dun fichier de configuration.
Marc ZIMMERMANN
me
anne
21/53
Figure 24 : Contexte de l'application MOST
Lapplication accepte en entre un fichier (XMI ou OWL) et des commandes de lutilisateur. En fonction des commandes elle produit des sorties obtenues par transformation du fichier en entre avec les feuilles de styles et un processeur XSLT. Les parties suivantes prsentent respectivement les solutions dveloppes pour la ralisation des transformations XSLT et de lapplication MOST.
3.2 Transformations XSLT

3.2.1 Prtraitements
Comme mentionn prcdemment une phase de prtraitement est applique aux sorties des AGL. Son objectif est de corriger la conformit du XMI et de lui donner un format standard. Ce prtraitement se compose de deux tapes successives : 1. La phase de prtraitement de conformit 2. La phase de prtraitement de formatage Le processus de prtraitement est dcrit par lorganigramme suivant :
Figure 25 : Algorithme de prtraitement

me
Marc ZIMMERMANN
anne
22/53
3.2.1.1
Prtraitement de conformit
La nature et les diffrences entre les non-conformits identifies 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 prsente des non-conformits, il lui sera donc associ un fichier XSLT dans lequel seront crites les transformations ncessaires pour la rendre conforme. De la mme manire 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 manire cible sur une sortie XMI non-conforme.
3.2.1.2
Prtraitement de formatage
Il sagit ici de rajouter des lments dans les fichiers XMI, qui ne sont pas ncessaires la conformit mais indispensables pour la conversion UML vers OWL. Ces lments sont un nom et un identifiant. Le tableau suivant rcapitule la ncessit pour les objets davoir un nom et/ou identifiant. Objet UML:Model UML:Package UML:Class UML:Attribute UML:Generalization UML:Association UML:AssociationEnd UML:DataType Identifiant oui oui oui non oui oui oui oui Nom oui oui oui oui non non non non
Figure 26 : Ncessit dun prtraitement de formatage
La phase de prtraitement de formatage peut tre applique de manire gnrique une version de XMI. En effet le test et lajout si besoin dun nom et dun identifiant ne requiert pas connaissance de la version dUML et de lAGL exportateur. Ainsi un seul fichier XSLT sera affect chaque version de XMI.
3.2.2 Correspondance UML-OWL

Les diagrammes UML suivant mettent en vidence les objets UML et OWL2 [W3COWL] qui sont utiliss dans cette tude et les relations qui les lient.
Marc ZIMMERMANN
me
anne
23/53
Figure 28 : Objets OWL
Figure 27 : Objets UML
Les agrgations reprsentent les relations dappartenance dun nud fils un nud parent au sens des arborescences. Par exemple en XMI un nud attribut appartient un nud classe. On remarque sur ces figures que le nombre dobjets UML est suprieur celui des objets OWL, cela implique qu un objet OWL seront associs plusieurs objet UML. Pour la ralisation des transformations UML vers OWL il faut bien garder lesprit que la transformation inverse doit ensuite pouvoir tre ralise. Il faut donc veiller ce que les transformations implmentes soient rversibles. Le tableau suivant rsume les associations entre objets UML et OWL qui ont t choisies pour raliser les conversions.
UML OWL Modle Ontologie Package Ontologie Classe Classe Attribut Datatype property Mthode (inutilises) Gnralisation (hritage) subClassOf Association Object property Agrgation Object property Composition Object property Commentaire Annotation property Type de donnes Type de donnes XSD Enumration Value Partition (Design Pattern) Classe d'association 2 Object properties Association n-aire Object properties Figure 29 : Correspondance UML-OWL
Modle et package Les modles et packages sont des conteneurs qui regroupent des classes appartenant un mme domaine. Ils reprsentent en quelque sorte un modle de donnes, cest pourquoi ce sont les ontologies qui vont leur tre associes.
Marc ZIMMERMANN
me
anne
24/53
Classe Les classes sont utilises autant en UML quen OWL pour reprsenter des objets ou un ensemble dindividus. Elles seront donc associes lune lautre. Attribut Les attributs sont des proprits liant les classes dautres objets (gnralement des types de donnes). En OWL ce sont les datatype properties qui lient les classes aux types de donnes. La conversion entre attribut et datatype property se fera donc de la faon suivante :
Figure 30 : Transformation des attributs
Mthode
Dclaration(s) : 1 datatype property : hasNom Restriction(s) : 1 restriction sur la classe Organisation : hasNom some String
Les mthodes ne sont pas prises en compte dans ces transformations car les modles utiliss ne sont pas destins au dveloppement logiciel mais la reprsentation de connaissances. Gnralisation Le concept de gnralisation-spcialisation est prsent en UML et en OWL. En OWL il est matrialis par la relation de subsomption (intitule subclassOf en RDFS).
Figure 31 : Transformation des gnralisations
Restriction(s) : 1 restriction sur la classe Entreprise : subClassOf Organisation
Marc ZIMMERMANN
me
anne
25/53
Association, agrgation et composition En XMI les associations, agrgations et compositions sont trs similaires. Elles dfinissent des relations entre les objets. En OWL les relations entre objets sont dfinies par des object properties. La conversion association-object property se fera comme suit :
Figure 32 : Transformation des associations
Dclaration(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 aperoit lapparition dun 9999 la place dune cardinalit *. Cest un choix dimplmentation, rpondant la contrainte quOWL ne gre les cardinalits que sous forme dentier, pas de chaine de caractres. Cet exemple met en vidence les deux cas particuliers. Dans le cas gnral on retrouve trois restrictions et les mmes cardinalits en UML et OWL. Les noms des object properties sont crs partir du type de lassociation (association, agrgation ou composition) et des noms des classes lies. Ce choix a t fait car les noms des associations et des rles ne sont pas toujours renseigns. Enumration Lnumration en UML est une collection dobjets. Il nexiste pas nativement de collections en OWL mais un Design Pattern a t crer dans ce but, cest la Value Partition.
Marc ZIMMERMANN
me
anne
26/53
Figure 33 : Transformation des numrations
1. 2. 3. 4.
Crer une classe correspondant au nom de lnumration Crer des sous-classes correspondant aux objets de lnumration Dfinir les classes comme non quivalentes (owl:disjointWith) Crer un axiome de couverture pour que lnumration ne puisse pas avoir dautres items que ceux existants (owl:unionOf)
Classe dassociation Une classe dassociation en UML permet de donner des attributs pour qualifier une association. Le diagramme UML dune classe dassociation est reprsent ci-dessous.
Figure 34 : Classe d'association
Pour traduire une classe dassociation en OWL on peut la dcomposer en objets UML de base possdant dj des objets OWL associs. Par exemple, la premire solution envisage, dcompose la classe dassociation en une classe Localisation et une association entre Photo et Evnement. On associe ensuite les objets OWL correspondant, cest--dire trois classes OWL, des datatype properties pour les attributs de Localisation et des object properties pour lassociation. Cependant cette solution dtruit en OWL le lien qui existait entre la classe Localisation et lassociation. Afin de conserver au mieux le sens de la classe dassociation nous allons nous intresser un diagramme UML quivalent celui de la classe dassociation :
Figure 35 : Equivalent classe d'association
Marc ZIMMERMANN
me
anne
27/53
Ce diagramme reprsente sans perte de sens la classe dassociation. Cest donc celui-ci qui sera traduit en OWL. Il sagit ici de trois classes, deux attributs et deux associations. Ce sont des objets UML auxquels des objets OWL ont dj t associs. Association n-aire Bien que la transformation des associations n-aire ne soit pas encore implmente la solution qui est pressentie est de considrer toutes les associations quelles recouvrent et les traduire en object properties.
Figure 36 : Association n-aire
Figure 37 : Equivalent association n-aire
Commentaire Les commentaires en OWL sont matrialiss par des annotation properties. Parmi celles existantes deux sont utilises dans ces outils : rdfs:comment pour les commentaires et rdfs:label pour les noms des objets. Type de donne En UML il est possible de crer des types de donnes. En OWL2 ce sont les types de donne XSD qui sont utiliss.
3.2.3 Algorithme de transformation UML2OWL

Pour traiter un fichier avec la technologie XSLT il faut adapter son algorithme la sortie que lon veut produire et non au fichier en entre. En effet on peut rechercher un lment dans le fichier dentre mais lcriture dans le fichier de sortie se fait toujours la fin. Lalgorithme de conversion UML vers OWL se dcoupe en deux tapes principales : le traitement des packages et le traitement des classes. Les boites rectangulaires des organigrammes suivants implmentent les rgles de transformations dcrites dans la partie prcdente.
Marc ZIMMERMANN
me
anne
28/53
Le traitement dun package se fait de la manire suivante : 1. Import de la nouvelle ontologie dans lontologie courante 2. Cration du fichier contenant la nouvelle ontologie 3. Pour tous les packages fils : application de lalgorithme Traiter package 4. Pour toutes les associations : dclaration des object properties 5. Pour toutes les classes : application de lalgorithme Traiter classe Le traitement des packages se fait de manire rcursive, ce sont donc les packages feuilles (ceux qui nont pas denfants de type package) qui sont traits en premiers, ensuite on dpile les appels.
Figure 38 : Algorithme UML2OWL : Traitement des packages
A une classe UML on associe une classe OWL. Les classes UML sont traites comme suit : 1. Pour tous ses attributs : dclaration de datatype properties (elles sont ainsi dclares dans lontologie) 2. Cration de la classe OWL 3. Ecritures des restrictions lies aux datatype properties (attributs de la classe UML) 4. Ecritures des restrictions lies aux object properties (associations de la classe UML) 5. Ecritures des restrictions subClassOf (lies aux hritages de la classe UML)
Figure 39 : Algorithme UML2OWL : Traitement des classes
Marc ZIMMERMANN
me
anne
29/53
3.2.4 Algorithme de transformation OWL2UML

La partie conversion OWL vers UML reprend les mmes correspondances dobjets quUML vers OWL mais les mcanismes mis en jeu sont plus complexes. Une premire difficult provient du fait quOWL possde moins de varits dobjets quUML. A un objet OWL a t associ plusieurs objets UML. Donc lors du passage dOWL UM L il faut identifier quel est lobjet UML crer. Par exemple les classes et numrations UML sont toutes deux reprsentes par des classes OWL. Donc lorsquon traite une classe OWL il faut se poser la question : est-ce une classe UML ou une numration ? Une autre difficult vient du fait que les properties sont dclares dans les ontologies et ensuite utilises dans les classes OWL. Donc pour reconstruire les associations il faut rassembler les informations prsentes dans les dclarations et dans les restrictions. De plus on traite gnralement plusieurs ontologies cest--dire plusieurs fichiers, donc ces informations se trouvent parfois dans des fichiers diffrents. Les algorithmes de conversion OWL vers UML font donc apparaitre plus de tests, plus de recherches et daccs des fichiers. Cela rend naturellement la conversion dune ontologie en modle UML conceptuellement plus complexe et plus lente lexcution. Deux traitements sont remarquables : le traitement dune ontologie et le traitement dune classe.
Traiter une ontologie cest : 1. construire le package UML correspondant 2. traiter les ontologies importes 3. traiter ses classes
Figure 40 : Algorithme OWL2UML : Traitement des ontologies
Marc ZIMMERMANN
me
anne
30/53
Enfin on traite les classes avec lalgorithme suivant.
Le traitement dune classe OWL suit la logique suivante : 1. Cration de la classe UML correspondante 2. Pour toutes les restrictions de type datatype property : crer un attribut 3. pour toutes les restrictions du type subClassOf : crer une gnralisation 4. pour toutes les restrictions du type object property : crer une association
Figure 41 : Algorithme OWL2UML : Traitement des classes
Marc ZIMMERMANN
me
anne
31/53
3.3 Application Java

3.3.1 Cas dutilisation
Le dveloppement de lapplication Java a t guid par la dmarche UML. La premire phase de lanalyse UML est lidentification des cas dutilisations. Ils permettent de dcrire le besoin fonctionnel des utilisateurs du systme et ainsi didentifier les fonctionnalits principales de lapplication. L'application Model-Ontology Stylesheet Transformation (MOST) met en place larchitecture du workflow et fournit une interface graphique pour la conversion de modles UML en ontologies OWL. Les principaux cas dutilisation de MOST sont donns 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 lutilisateur doit spcifier 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 spcialiste, qui hrite de l'utilisateur standard, peut configurer les transformations mises disposition par l'application
Marc ZIMMERMANN
me
anne
32/53
3.3.1.1
Appliquer une transformation
Les cas dutilisations du mode de transformation UML2OWL sont dtaills dans la figure cidessous :
Figure 43 : Cas d'utilisation : Mode de transformation UML2OWL
Le mode de transformation UML vers OWL permet de transformer un modle UML en ontologie. Pour cela lutilisateur doit dans un premier temps choisir le fichier XMI quil souhaite transformer. Une fois ce modle choisi, lapplication affiche les versions dUML, dXMI et lAGL utiliss pour crer ce fichier. En fonction de ces informations elle dtermine aussi quelles sont les meilleures transformations appliquer au fichier et les prslectionne. Une fois le fichier renseign, lutilisateur a la possibilit de vrifier sa validit par rapport une DTD ou un XSD. Cette opration nest pas obligatoire. Lutilisateur choisi ensuite les prtraitements de conformit et de formatage appliquer au fichier avant transformation. Lapplication de prtraitement de conformit nest pas obligatoire. Enfin lutilisateur choisi le fichier de transformation UML vers OWL parmi ceux proposs et lance la transformation. Le mode de transformation OWL2UML ne propose que la slection du fichier dentre et le choix de la transformation.
Marc ZIMMERMANN
me
anne
33/53
3.3.1.2
Configuration des paramtres
Figure 44 : Cas d'utilisation : Gestion de la configuration
Lapplication MOST est configurable grce un fichier ini. Le chargement et la sauvegarde de ce fichier se font automatiquement au lancement et larrt de lapplication. Configurer lapplication signifie choisir les transformations quelle propose. En cours dutilisation 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 dabsorber au maximum les nombreuses volutions du contexte de lapplication, savoir : version UML, version XMI et AGL. Ces oprations naffectent que les fichiers XSLT et ne ncessitent pas de modifier le code de lapplication et de la recompiler.
3.3.2 Classes candidates et diagrammes de classes

A partir des cas dutilisation on peut identifier les classes candidates, se sont les classes au sens de la programmation objet qui constitueront larchitecture du systme. Les principales classes identifies sont dcrites si dessous : Le gestionnaire de fichier XMI : son rle est dobtenir les informations sur le fichier XMI et de vrifier sa validit conformment un schma de validation.
Marc ZIMMERMANN
me
anne
34/53
Le gestionnaire de transformation : cest lui qui possdera la responsabilit des transformations appliquer au fichier dentre.
Le fichier de configuration : un fichier de configuration est un fichier possdant des sections qui contiennent des paramtres (cl=valeur). La structure de donne choisie pour modliser un fichier de configuration est une table de hachage contenant des tables de hachage donnant accs des valeurs.
Figure 45 : Fichier de configuration
Figure 46 : Structure de donne du fichier de configuration
Le gestionnaire de configuration : il a la charge dinteragir avec le fichier de configuration. C'est--dire le lire, le sauvegarder et mettre disposition ses informations. Linterface graphique : lapplication se prsentera sous la forme dun wizard .Cela permettra lutilisateur de suivre le processus de transformation de manire intuitive. Ce wizard sera modlis la manire dun diaporama, cest--dire une JFrame qui sert de conteneur des JPanel qui dfilent par actions sur des boutons Suivant et Prcdent. Une classe principale MOST qui possde tous les composants principaux, cest--dire les gestionnaires et linterface graphique. Cest le point dentre de lapplication, il est modlis grce au Design Pattern singleton. Lidentification des classes candidates et ldition des diagrammes de classe permettent de crer le squelette de lapplication et dy placer ses principaux organes.
Marc ZIMMERMANN
me
anne
35/53
Figure 47 : Diagramme de classe de MOST
3.3.3 Diagrammes de collaboration et de squence

Les diagrammes de collaboration donnent une vue spatiale des changes de messages entre les classes du modle. Ils rpondent la question : Qui communique et quels sont les messages ?
Figure 48 : Diagramme de collaboration : Modifier la configuration
Les diagrammes de squence donnent une vue temporelle des changes de messages entre les classes du modle. Ils rpondent la question : Quel est lordre des changes de messages ?
Marc ZIMMERMANN
me
anne
36/53
Figure 49 : Diagramme de squence : Modifier la configuration
Les diagrammes de collaboration et de squence permettent de dcrire, pour chaque fonctionnalit de lapplication, les enchainements de messages changs entre les classes. On a alors mis en place les communications entre les diffrents organes de notre application. Larchitecture de lapplication est dsormais compltement dcrite et prte pour limplmentation.
3.4 Choix des technologies

3.4.1 Transformation de fichiers XML
Pour raliser les transformations UML vers OWL et OWL vers UML une technologie est propose par le cahier des charges : XSLT. Cette technologie est trs bien adapte ce problme car elle permet de transformer des fichiers XML en fichier XML, XMI et OWL tant bass sur la syntaxe XML, avec uniquement les donnes prsentes dans le XML dorigine et le fichier de transformation. Cest la version 2.0 de XLST qui a t choisie pour raliser ces transformations, la version 1.0 ne permettant pas de produire plusieurs fichiers de sorties. Pouvoir produire plusieurs fichiers en sortie est une ncessit puisqu un package est associe une ontologie, or un fichier OWL ne peut contenir quune seule ontologie.
3.4.2 Le processeur XSLT

Les contraintes associes au choix du processeur XSLT sont les suivantes : il doit pouvoir tre utilis depuis une application Java et doit tre libre. Les bibliothques qui rpondent ces critres sont Saxon, Xalan et AltovaXML. Xalan ne supporte pas XSLT 2.0 dans sa version Java, elle a donc t carte de la liste des possibilits.
Marc ZIMMERMANN
me
anne
37/53
Bien que les deux restantes soient libres dutilisation, compatible XSLT 2.0 et disponibles en librairie pour .Net et pour Java cest Saxon qui a t choisie comme processeur XSLT plutt quAltovaXML. Le choix ne sest pas fait sur les performances de ces librairies mais sur leurs supports. En plus dtre la plus rpandue et la plus ancienne Saxon bnficie dune Javadoc trs complte [SAXON]. Si cela ne suffit pas le dveloppeur peut entrer directement en contact avec le concepteur et dveloppeur de Saxon, qui se trouve aussi tre lauteur de la recommandation W3C sur XSLT 2.0.
3.4.3 Lenvironnement de dveloppement intgr

Le choix de lenvironnement de dveloppement sest fait entre Eclipse et Netbeans. Ils offrent tout deux de nombreuses fonctionnalits pour dvelopper des applications Java mais cest Netbeans qui a t choisi en raison de la nature de lapplication crire. En effet lapplication MOST sera dveloppe sous forme dun wizard, donc beaucoup de composants dinterfaces graphiques seront ncessaires. Netbeans possde un diteur dinterfaces graphiques ce qui rend leur ralisation moins fastidieuse que sous Eclipse.
Marc ZIMMERMANN
me
anne
38/53
4 Ralisations
Dans cette partie sont prsents les principales ralisations et les rsultats concrets.
4.1 Ralisation des transformations

4.1.1 Prtraitements
Rappelons que les deux phases de prtraitements (conformit et formatage) ont pour but de limiter au maximum les ventuelles pertes de donnes dues aux non-conformits des XMI crits par les AGL. Du point de vue technique ces deux phases de formatage sont bties sur le mme modle. Il sagit de recopier intgralement le fichier en entre en y ajoutant les lments ncessaires aux traitements ultrieurs (lments conformes, noms et identifiants). On distingue dans les transformations deux types de template rules : La template rule dite gnrique, elle sapplique rcursivement tous les lments et attributs.
Figure 50 : Template rule gnrique
La template rule dite spcialise, elle sapplique un lment donn.
Figure 51 : Template rule spcialise
A lexcution le processeur recherche la template rule la plus adapte un nud. Cest de cette manire que la template rule spcialise remplace lappel de la template rule gnrique. Ainsi lors de la recopie de cet lment on va pouvoir lui appliquer un traitement adapt.
Marc ZIMMERMANN
me
anne
39/53
4.1.2 Transformation UML2OWL

Les template rules ont t crites conformment aux algorithmes prsents dans la partie 3. A titre dexemple la template rule associe au traitement des packages est donne ci-dessous.
Figure 52 : Template rules pour le traitement des packages
Marc ZIMMERMANN
me
anne
40/53
Dans la suite de cette partie nous allons prsenter les transformations UML vers OWL au travers dun exemple bas sur un modle UML de test. Dans cet exemple ce nest pas la pertinence de la modlisation qui est recherche mais sa simplicit et sa capacit couvrir les principaux cas de figures. Le modle Ecole est dcrit par les diagrammes de classes suivants :
Figure 53 : Diagramme de classe Ecole
Afin de visualiser les rsultats de ces transformations nous allons utiliser lditeur dontologies Protg 4 [PROTEG]. Il offre une vue de la hirarchie des classes (vue graphique avec le plug-in Graph Viz), des object properties et des datatype properties.
Modles et packages Chaque modle ou package est transform en une ontologie stocke dans un fichier OWL. Les liens entre ces ontologies sont matrialiss par le mot cl owl:imports. Dans cet exemple nous disposons dun modle : Ecole, et de trois packages Ecole Ingenieur, Acteur et Infrastructure. Ldition de lontologie Ecole fait apparaitre les imports suivants :
Marc ZIMMERMANN
me
anne
41/53
Figure 54 : Ontologies du modle Ecole
On remarque deux types dimports : - les imports directs : ontologies directement importes - les imports indirects : ontologies importes par des ontologies importes (directement ou indirectement) Classes et gnralisations Conformment aux algorithmes dfinis plus haut une classe OWL est associe chaque classe UML. Et les relations de gnralisation-spcialisation sont dcrites par le mot cl rdfs:subClassOf. La hirarchie des classes se prsente alors sous la forme suivante :
Figure 55 : Classe OWL du modle Ecole (Graph Viz)
Attributs
Figure 56 : Datatype properties du modle Ecole
Figure 57 : Restriction lie aux attributs
Marc ZIMMERMANN
me
anne
42/53
On peut ici remarquer le fait quOWL distingue bien deux datatype properties ayant le mme nom, celle associe Personne et celle associe Ecole Ingenieur. Des restrictions sont ensuite associes aux classes OWL, par exemple pour la matire enseigne par un enseignant comme le montre les figures ci-dessus. Associations Pour chaque association on dclare deux object properties inverses nommes par les classes quelles lient.
Figure 58 : Object properties du modle Ecole
Des restrictions sont ensuite ajoutes aux classes avec les cardinalits correspondant aux associations. Par exemple :
Figure 59 : Restrictions lies 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 lauto-association Personne-Personne les deux proprits inverses apparaissent (is et has).
Marc ZIMMERMANN
me
anne
43/53
Enumrations Les numrations sont associes au design pattern value partition. Les principaux points de ce design pattern sont dtaills ici : La hirarchie des classes :
Figure 60 : Classes de la Value Partition
Les classes disjointes :
Figure 61 : Classe OWL disjointes
Laxiome de couverture :
Figure 62 : Axiome de couverture
Marc ZIMMERMANN
me
anne
44/53
4.1.3 Transformation OWL2UML

La reconstruction du modle UML pour UML 1.3 XMI 1.1 partir de lontologie Ecole a t importe dans StarUML. Le rsultat est le suivant :
Figure 63 : Modle Ecole reconstruit
Il est normal que lnumration Nom_Ecole_Ingenieur napparaisse pas dans ce modle car au moment de la rdaction de ce rapport elles ne sont pas encore traites par OWL2UML. Cependant une erreur apparait, cest la transformation des agrgations en association entre les classes Ecole_Ingenieur et Materiel et Ecole_Ingenieur et Personne. Ce problme est d aux non-conformits de StarUML. En effet la DTD associ UML 1.3 XMI 1.1 prvoit pour les marqueurs des agrgations la valeur shared, or StarUML utilise la valeur aggregate.
Figure 64 : DTD UML 1.3 XMI 1.1
Marc ZIMMERMANN
me
anne
45/53
Figure 65 : Agrgation StarUML non conforme
La solution est simple : dans le fichier XMI il suffit de remplacer toutes les occurrences de shared par aggregate. Autrement dit il faut rendre la sortie des outils non-conforme.
4.1.4 Tests et validation

Afin de raliser les tests des transformations une base de test a t constitue. Elle contient des modles UML simples et des modles rels (modles UML de projets Cemagref).
4.1.4.1
Tests unitaires et tests dintgration
Deux types de modles ont t utiliss pour raliser les tests : les modles simples et les modles dintgrations. Ils sont respectivement utiliss pour les tests unitaires et les tests dintgrations. Les modles pour les tests dintgrations sont enrichis chaque nouvel objet UML qui est trait. A lissue de chaque application dune transformation un modle la sortie est tudie scrupuleusement. Le but est de vrifier que ce qui tait trait ltape prcdente lest toujours identiquement et que les nouveaux traitements sont oprationnels. Les rsultats de ces tests sont reprsents dans un tableau comme suit :
UML 1.3 UML to OWL Modle Package Classe Attribut Gnralisation Association + Type + Multiplicits Commentaires Enumration Figure 66 : Tableau de validation des transformations 1 seule UML 1.4 UML 2.1
XMI 1.0 XMI 1.1 XMI 1.1 XMI 1.2 XMI 2.1
Une fois les rsultats jugs satisfaisants le passage litration suivante est autoris.
Marc ZIMMERMANN
me
anne
46/53
4.1.4.2
Tests de robustesse
Les modles UML rels tant plus complexes et plus volumineux ils ont t utiliss pour des tests de robustesse. Il sagit ici de vrifier le fonctionnement des transformations en conditions relles. Le tableau suivant dcrit quantitativement les modles utiliss pour ces tests.
lignes packages classes attributs gnralisations associations 31203 43 263 496 235 165 944 5 29 58 674 2 21 37 945 2 23 48 10800 1 90 363 4420 4 40 60 Figure 67 : Dtails des modles rels 20 4 14 5 14 10 11 7 172 61
GIEA SIE Pesticides +Activits mtrologiques +Gestion exploitation +Pratiques agricoles SIGEMO SYNAPSE
Ces modles ont aussi servi valider les transformations auprs des clients. Ces derniers connaissant bien leurs modles, ils ont t mme de vrifier la validit des donnes en sorties des transformations. Un premier jalon a t pass le 13 Juillet et a abouti la validation des transformations dans ltat o elles se trouvaient cette date.
4.2 Ralisation de lapplication MOST

4.2.1 Maquette et exemples de principes
Nous allons prsenter ici la premire phase du cycle de dveloppement en V : lanalyse et la faisabilit. Cette tape a permis de prsenter divers prototypes montrant la possibilit de raliser les fonctionnalits critiques de MOST, identifies par les cas dutilisations.
4.2.1.1
Interface graphique
Le premier prototype est celui de linterface graphique de MOST. Sa premire version sous forme dinterface statique trois onglets na pas t valide. La raison est que le processus de transformation ntait pas intuitif apprhender avec une telle interface. La seconde version sest naturellement oriente vers un wizard cest--dire une application graphique pas--pas. Lenchainement des tapes se prsente sous la forme suivante :
Marc ZIMMERMANN
me
anne
47/53
Figure 68 : Enchainement des crans de MOST
Cest ce prototype qui a t retenu pour limplmentation.
4.2.1.2
Transformation XSLT avec Saxon
Le second exemple de principe vise prouver que les transformations XSLT sont possibles depuis Java et Saxon. Trivialement la rponse est oui puisque cest le but mme de la librairie. En quelques lignes de code on peut appliquer une transformation un fichier XML. De plus il est possible de remonter les erreurs et avertissement lutilisateur (dans un panneau de texte par exemple). Dfinition de la librairie Saxon comme fabrique de transformations :
Ajout dun gestionnaire derreur cette fabrique :
Marc ZIMMERMANN
me
anne
48/53
Transformation XSLT dun fichier XML :
4.2.1.3
Gestion de la configuration
Troisime tape : rendre lapplication configurable par utilisation dun fichier ini. Cest une technique largement utilise dans le domaine du dveloppement logiciel et il existe des classes limplmentant dans divers langages objets. Bien que des codes existent dj jai tout de mme cr mes propres classes de gestion de fichier de configuration. Le principe reste toujours le mme : utilisation de tables de hachage et structure du fichier du type : [section] avec cl=valeur.
4.2.1.4
Validation par DTD et XSD
La dernire fonctionnalit de MOST vrifier est la validation de fichiers XML par DTD et par XSD. Ces techniques sont conceptuellement similaires mais diffrent quelque peu dun point de vue technologique. Pour la validation par DTD il faut en premier ajouter un doctype, cest une rfrence au fichier contenant la DTD que doit respecter le fichier XML. Ensuite on utilise un parser qui lit le fichier XML et dtecte les erreurs de conformit. Pour la validation par XSD pas de doctype mais un parser diffrent pour lequel on spcifie un fichier XSD. De la mme manire le parser lit le fichier et remonte les erreurs de conformit dans un panneau de texte ddi.
Marc ZIMMERMANN
me
anne
49/53
4.2.2 Gnration de larchitecture du code

Conformment au cycle de dveloppement en V, lissue de ltape danalyse et de ltude de faisabilit cest la phase de conception de larchitecture qui dbute. La modlisation UML de lapplication MOST a t ralise sous StarUML. Cest un atelier de gnie logiciel libre et complet. Il propose bien entendu tous les outils lis la dmarche de modlisation UML et la possibilit de gnrer du code dans plusieurs langages dont Java. Ainsi larchitecture du code, cest--dire les packages et classes identifies lors de la modlisation, a t gnre depuis StarUML. La modlisation ayant t pousse assez loin il ne reste qu implmenter le contenu des mthodes des classes.
4.2.3 Implmentation des modules

Avant de commencer limplmentation du modle, cest--dire la ralisation des diverses itrations, nous disposons dune architecture pouvant accueillir le code et de prototypes contenant le principe des fonctionnalits. Afin de construire une application Java la premire chose faire et de dfinir un nouveau projet dans lIDE Netbeans et dy intgrer les classes gnres par StarUML. Enfin pour chaque itration les phases de capture des besoins fonctionnels et techniques ont pralablement t ralises respectivement lors de la description des cas dutilisation et de la cration des prototypes. Donc limplmentation des classes peut commencer. La succession des itrations a t la suivante : interface graphique gestion de la configuration transformation XSLT validation des fichiers XMI
1. 2. 3. 4.
Marc ZIMMERMANN
me
anne
50/53
5 Rsultats et prolongements
Cette ultime partie dresse un bilan du travail ralis et donne les perspectives davenir des ralisations.
5.1 Etats des lieux

5.1.1 Ce qui a t ralis
Ltude ralise lors de ce stage a permis didentifier les compatibilits entre versions UML/XMI et de conclure sur ltat de linteroprabilit entre les ateliers de gnie logiciel. Cette tude a mis en vidence les problmes lis linteroprabilit ce qui a t une premire tape dans la ralisation dun processus permettant de les rsoudre. En effet la solution adopte pour raliser le workflow permet de traiter les problmes de conformit identifis et ensuite de transformer les modles. Lors de la rdaction de ce rapport les transformations UML vers OWL et OWL vers UML ont t implmentes pour la plupart des objets UML figurant dans le cahier des charges. Un accent a t mis sur la production dune solution durable et adaptable aux volutions futures au travers de la configurabilit de lapplication MOST et de la structure mme du workflow (organisation des feuilles de styles). Cela garanti que des dveloppements majeurs ne seront pas prvoir dans limmdiat et que de petites modifications sont facilement intgrables lexistant.
5.1.2 Ce quil reste faire

Afin daffiner ltude il conviendrait de recueillir plus dinformations sur lAGL Mega et dtudier la conformit de ses sorties. Cette tude pourrait tre largie de nombreux autre s AGL (tels que Visual Paradigm, Rational Rose, ). La part du travail qui reste ma charge avant la fin de ce stage est la ralisation des transformations OWL2UML des numrations et les transformations des associations n-aires.
5.1.3 Amliorations possibles et prolongement

Les amliorations qui sont envisageables sur ce travail portent sur la correspondance entre les objets UML et OWL. Par exemples les datatype properties telles quelles sont construites dans ces outils peuvent pointer sur des classes, cest le cas lorsque le type dun attribut est une classe. Or en OWL une datatype property ne peut pointer que sur un type de donne. Il faudrait, dans labsolu, tester le type des attributs et crer une object property dans certains cas. Les transformations associes aux associations n-aires et aux classes dassociations conservent le sens de la modlisation mais ne permettent pas de recrer ces objets. On pourrait donc se pencher sur le problme de trouver des objets OWL qui permettraient de reconstruire des associations n-aire et des classes dassociations lors du traitement par OWL2UML. Un point intressant a t mis en vidence lors de la gnration des ontologies correspondant aux modles UML, cest lapparition de problmes dans les modles. Ces problmes ne peuvent pas tre considrs comme des erreurs de modlisations. Par exemple
Marc ZIMMERMANN
me
anne
51/53
lapparition de doublons dans les datatype properties signifie que deux classes ont un mme attribut. Il serait peut-tre judicieux de faire hriter deux classes ayant un mme attribut dune classe mre a qui on laffecterait. Ainsi les ontologies donnent une autre vue des modles qui pourraient permettre de rflchir sur la modlisation et ventuellement de la retravailler.
5.2 Bilan
Le travail dj ralis contribue efficacement linteroprabilit des donnes entre ateliers de gnie logiciel. Ainsi il accompagnera les changements dAGL utiliss par le Cemagref dans un premier temps, puis par dautres par la suite (ces outils de transformations ont pour projet dtre libres dutilisation). Ils seront potentiellement intgrs dans le travail dun autre stagiaire dont le but est la cration dun outil collaboratif de production de connaissance afin dajouter des donnes provenant dUML, ces connaissances tant stockes sous forme dontologies. Sur un plan plus personnel ce stage ma permis dacqurir de nouvelles comptences techniques grce la maitrise des langages XML et XSLT, et dapprofondir mes connaissances en UML et en programmation Java. Le travail sur les ontologies ma aussi ouvert une nouvelle approche des modles : par la smantique et la logique. Jai aussi progress dans ma mthode de travail et dans lorganisation des tches accomplir ainsi que dans lanticipation de celles venir. Enfin ce stage ma permis de dcouvrir les activits du Cemagref, plus particulirement en Auvergne, et le monde de la recherche.
Marc ZIMMERMANN
me
anne
52/53
Conclusion
Malgr un standard ddi, XMI, ltude ralise au cours de ce stage montre que linteroprabilit des donnes entre les ateliers de gnie logiciel nest pas compltement oprationnelle. Cest la consquence des volutions indpendantes des normes UML et XMI et du non respect de ses normes par les diteurs de logiciels. Lobjectif de ce stage est atteint car des outils de transformation bass sur XSLT ont t dvelopps pour produire les sorties OWL et XMI correspondant un modle UML. Ces outils, valids par des tests sur des modles rels, sont intgrs dans une application Java, appele ModelOntology Stylesheet Transformation, entirement configurable. Il est plus que probable que ces travaux ncessitent dtre prolongs afin de prendre en charge les versions dUML et dXMI venir. En consquence je laisse disposition des futurs dveloppeurs une structure de travail propice la reprise de ces outils. En effet, tout dabord lapplication MOST permet dintgrer de nouvelles transformations sans avoir redvelopper. Ensuite la base de tests existante permettra au dveloppeur de valider ses travaux. Enfin les documents de spcification de ltude mene constitueront une aide pour se familiariser avec les outils et leur contexte. Ainsi, bien que de nouveaux dveloppements paraissent invitables, les outils raliss au cours de ce stage amliorent dj cette interoprabilit. Au Cemagref ils seront utiles pour la conservation des donnes lors de la migration vers de nouveau AGL. Par la suite ces outils seront distribus librement et pourront tre utiles dautres organismes. Pour moi ce stage a t loccasion de mettre en pratique et dapprofondir mes connaissances en UML et programmation Java. Il ma permis de maitriser de nouvelles technologies et de me familiariser avec le monde de la recherche au travers des activits du Cemagref.
Marc ZIMMERMANN
me
anne
53/53
Index des illustrations

Figure 1 : Les centres du Cemagref ......................................................................................................... 2 Figure 2 : Syntaxe d'un fichier XML ......................................................................................................... 4 Figure 3 : Transformation XSLT ............................................................................................................... 5 Figure 4 : Exemple de template rule XSLT ............................................................................................... 5 Figure 5 : Template rule native ............................................................................................................... 5 Figure 6 : Architecture MOF .................................................................................................................... 6 Figure 7 : Exemple OWL .......................................................................................................................... 7 Figure 8 : Les langages bass sur XML ..................................................................................................... 8 Figure 9 : Imports et exports XMI.......................................................................................................... 10 Figure 10 : Associations entre UML et XMI ........................................................................................... 11 Figure 11 : Equivalence des versions d'UML ......................................................................................... 11 Figure 12 : Gnralisation sous PowerAMC .......................................................................................... 12 Figure 13 : Gnralisation sous StarUML .............................................................................................. 12 Figure 14 : Gnralisation UML 1.3 XMI 1.1 conforme ......................................................................... 12 Figure 15 : Conformit des AGL pour UML 1.3...................................................................................... 13 Figure 16 : Conformit des AGL pour UML 1.4 et UML 2.1 ................................................................... 13 Figure 17 : Rseau des AGL ................................................................................................................... 14 Figure 18 : Planning prvisionnel .......................................................................................................... 16 Figure 19 : Planning rel ........................................................................................................................ 17 Figure 20 : Cycle de dveloppement en V ............................................................................................. 18 Figure 21 : Droulement d'une itration............................................................................................... 19 Figure 22 : Cycle de dveloppement en Y ............................................................................................. 19 Figure 23 : Organisation du workflow ................................................................................................... 21 Figure 24 : Contexte de l'application MOST .......................................................................................... 22 Figure 25 : Algorithme de prtraitement .............................................................................................. 22 Figure 26 : Ncessit dun prtraitement de formatage....................................................................... 23 Figure 27 : Objets UML .......................................................................................................................... 24 Figure 28 : Objets OWL .......................................................................................................................... 24 Figure 29 : Correspondance UML-OWL ................................................................................................. 24 Figure 30 : Transformation des attributs .............................................................................................. 25 Figure 31 : Transformation des gnralisations .................................................................................... 25 Figure 32 : Transformation des associations ......................................................................................... 26 Figure 33 : Transformation des numrations ...................................................................................... 27 Figure 34 : Classe d'association ............................................................................................................. 27 Figure 35 : Equivalent classe d'association ........................................................................................... 27 Figure 36 : Association n-aire ................................................................................................................ 28 Figure 37 : Equivalent association n-aire............................................................................................... 28 Figure 38 : Algorithme UML2OWL : Traitement des packages ............................................................. 29 Figure 39 : Algorithme UML2OWL : Traitement des classes ................................................................. 29 Figure 40 : Algorithme OWL2UML : Traitement des ontologies ........................................................... 30 Figure 41 : Algorithme OWL2UML : Traitement des classes ................................................................. 31 Figure 42 : Cas d'utilisation de MOST .................................................................................................... 32 Figure 43 : Cas d'utilisation : Mode de transformation UML2OWL ...................................................... 33 Figure 44 : Cas d'utilisation : Gestion de la configuration ..................................................................... 34 Figure 45 : Fichier de configuration....................................................................................................... 35 Figure 46 : Structure de donne du fichier de configuration ................................................................ 35 Figure 47 : Diagramme de classe de MOST ........................................................................................... 36
Marc ZIMMERMANN
me
anne
Figure 48 : Diagramme de collaboration : Modifier la configuration.................................................... 36 Figure 49 : Diagramme de squence : Modifier la configuration.......................................................... 37 Figure 50 : Template rule gnrique ..................................................................................................... 39 Figure 51 : Template rule spcialise .................................................................................................... 39 Figure 52 : Template rules pour le traitement des packages ................................................................ 40 Figure 53 : Diagramme de classe Ecole ................................................................................................. 41 Figure 54 : Ontologies du modle Ecole ............................................................................................... 42 Figure 55 : Classe OWL du modle Ecole (Graph Viz) ........................................................................... 42 Figure 56 : Datatype properties du modle Ecole................................................................................. 42 Figure 57 : Restriction lie aux attributs ............................................................................................... 42 Figure 58 : Object properties du modle Ecole ..................................................................................... 43 Figure 59 : Restrictions lies aux associations ...................................................................................... 43 Figure 60 : Classes de la Value Partition................................................................................................ 44 Figure 61 : Classe OWL disjointes .......................................................................................................... 44 Figure 62 : Axiome de couverture ......................................................................................................... 44 Figure 63 : Modle Ecole reconstruit .................................................................................................... 45 Figure 64 : DTD UML 1.3 XMI 1.1 .......................................................................................................... 45 Figure 65 : Agrgation StarUML non conforme .................................................................................... 46 Figure 66 : Tableau de validation des transformations ......................................................................... 46 Figure 67 : Dtails des modles rels .................................................................................................... 47 Figure 68 : Enchainement des crans de MOST .................................................................................... 48
Marc ZIMMERMANN
me
anne
Rfrences bibliographiques
[JAVA2] Java 2 Platform, Standard Edition, v 1.4.2 API Specification http://java.sun.com/j2se/1.4.2/docs/api/index.html Java pour les ZZ Cours ISIMA 3, filire Calcul et Modlisation Scientifiques Loc YON Mthodes et Outils de Dveloppement Logiciel. Cours tronc commun ISIMA 2 Christine FORCE Catalog of OMG Modeling and Metadata Specifications http://www.omg.org/technology/documents/modeling_spec_catalog.htm A Practical Guide To Building OWL Ontologies Using Protg 4 and CO-ODE Tools Edition 1.2 Matthew Horridge The University Of Manchester March 13, 2009 Saxon9 Javadoc http://www.saxonica.com/documentation/javadoc/index.html UML en Franais http://uml.free.fr/ OWL Web Ontology Language http://www.w3.org/TR/2004/REC-owl-features-20040210/ W3C Recommendation Extensible Markup Language (XML) http://www.w3.org/XML/ XSL Transformations (XSLT) Version 2.0 http://www.w3.org/TR/xslt20/ W3C Recommendation XSL Concepts and Practical Use http://nwalsh.com/docs/tutorials/xsl/xsl/frames.html Paul Grosso, Norman Walsh
[JAVAZZ]
[MODL]
[OMGMMS]
[PROTEG]
[SAXON]
[UMLFr]
[W3COWL]
[W3CXML]
[W3CXSL]
[XSLPra]
Marc ZIMMERMANN
me
anne

Pub 00029264

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pub 00029264

Transféré par

Droits d'auteur :

Formats disponibles

Institut Suprieur dInformatique de Modlisation et de leurs Applications Complexe des Czeaux 63173 Aubire Cedex

Rapport dingnieur Stage de 3me anne Filire : Calcul et modlisation scientifiques

Workflow XML pour linteroprabilit des donnes

Dure : 4 mois Mai Septembre 2010

Rapport dingnieur Stage de 3me anne Filire : Calcul et modlisation scientifiques

Workflow XML pour linteroprabilit des donnes

Dure : 4 mois Mai Septembre 2010

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

Table des matires

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

Workflow XML pour linteroprabilit des donnes

1.1 Prsentation de lorganisme daccueil

Workflow XML pour linteroprabilit des donnes

1.1.2 Le centre de Clermont-Ferrand

1.1.3 LUR Technologies et systmes dinformation pour les agrosystmes

1.1.4 Lquipe Systmes dinformation communicants et agri-environnementaux

Workflow XML pour linteroprabilit des donnes

1.2 Contexte technique

Figure 2 : Syntaxe d'un fichier XML

Workflow XML pour linteroprabilit des donnes

eXtensible Stylesheet Language Transformation

Figure 3 : Transformation XSLT

Figure 4 : Exemple de template rule XSLT

Figure 5 : Template rule native

Workflow XML pour linteroprabilit des donnes

1.2.2 Modles de donnes et interoprabilit

Figure 6 : Architecture MOF

Web Ontology Language (OWL)

Workflow XML pour linteroprabilit des donnes

Figure 7 : Exemple OWL

Workflow XML pour linteroprabilit des donnes

1.2.3 Conclusion sur XML

Figure 8 : Les langages bass sur XML

Workflow XML pour linteroprabilit des donnes

2.1 Cahier des charges

2.2 Etude des entres et sorties XMI

Workflow XML pour linteroprabilit des donnes

2.2.1 Recensement des entres/sorties

BOUML Enterprise Architect

BOUML 4.21 Enterprise Architect 7 et ultrieures

Modelio 1.2 Objecteering 6.1 Poseidon 6.0 et ultrieures

XMI 1.2 XMI 1.1 XMI 2.1 XMI 1.1

PowerAMC 9.0 15 PowerAMC 15.1 et 15.2 StarUML 5.0

PowerAMC 15.2 StarUML 5.0 (30/12/2005)

Figure 9 : Imports et exports XMI

Workflow XML pour linteroprabilit des donnes

2.2.2 Equivalence UML1-UML2

Classe d'association oui

Workflow XML pour linteroprabilit des donnes

2.2.3 Conformit des sorties XMI

Figure 13 : Gnralisation sous StarUML

Figure 12 : Gnralisation sous PowerAMC

Figure 14 : Gnralisation UML 1.3 XMI 1.1 conforme

Workflow XML pour linteroprabilit des donnes

Figure 16 : Conformit des AGL pour UML 1.4 et UML 2.1

Workflow XML pour linteroprabilit des donnes

2.2.4 Interoprabilit des modles UML

Figure 17 : Rseau des AGL