workflow xml pour l'interopérabilité des données

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

Upload: vanthu

Post on 14-Feb-2017

226 views

Category:

Documents


0 download

TRANSCRIPT

Institut Supérieur d’Informatique de

Modélisation et de leurs Applications Complexe

des Cézeaux 63173 Aubière Cedex

Rapport d’ingénieur Stage de 3ème année

Filière : Calcul et modélisation scientifiques

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

Organisme d’accueil : Cemagref

Présenté par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Durée : 4 mois Tuteur ISIMA : Jonas KOKO Mai à Septembre 2010

Institut Supérieur d’Informatique de

Modélisation et de leurs Applications Complexe

des Cézeaux 63173 Aubière Cedex

Rapport d’ingénieur Stage de 3ème année

Filière : Calcul et modélisation scientifiques

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

Organisme d’accueil : Cemagref

Présenté par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Durée : 4 mois Tuteur ISIMA : Jonas KOKO Mai à Septembre 2010

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

Remerciements

Je tiens à remercier Catherine ROUSSEY et Jean-Pierre CHANET qui m’ont encadré, aidé et guidé tout au long de ce stage.

Je remercie Jean-Claude CHAMPOMIER, Vincent SOULIGNAC, Gil de SOUSA et André

MIRALLES pour m’avoir donné accès à leurs travaux et pour le temps qu’ils m’ont accordé. Les modèles UML qu’ils m’ont fournis ont été d’une grande aide pour mes réalisations.

Je tiens enfin à remercier l’ensemble des personnes qui ont permis à ce stage de se dérouler

dans d’excellentes conditions.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

Résumé

Mon stage de troisième année à l’ISIMA s’est déroulé au Cemagref où j’ai été chargé de réaliser un workflow XML pour l’interopérabilité des données.

Pour créer l’architecture des logiciels, les développeurs ont recourt à des méthodes guidées

par les modèles. Cette approche s’intitule en anglais Model Driven Architecture (MDA). Le langage privilégié pour décrire le MDA est l’Unified Modeling Language (UML). Ainsi de nombreux Ateliers de Génie Logiciel (AGL) permettent de décrire ces modèles grâce à UML, et un standard existe pour leur sérialisation : XML Metada Interchage (XMI). Or les évolutions nombreuses et indépendantes d’UML et d’XMI ont appauvri l’interopérabilité des modèles.

L’objectif du travail décrit dans ce document est d’étudier les compatibilités entre XMI et de

fournir des outils afin d’améliorer l’interopérabilité entre AGL. C’est la technologie eXtensible Stylesheet Language Transformation (XSLT) qui a été utilisée

pour réaliser les outils. Les transformations des modèles s’effectuent au moyen d’une conversion dans un langage intermédiaire : Web Ontologie Language (OWL). Ainsi les outils permettent de créer l’ontologie associée au modèle et toutes les versions XMI existantes.

Ces transformations sont intégrées dans une application Java, nommée Model-Ontology Stylesheet Tranformation (MOST), totalement configurable afin de pouvoir s’adapter aux évolutions à venir d’UML et d’XMI. Mots clés : atelier de génie logiciel, interopérabilité, Java, modèle, ontologie, OWL, UML, workflow, XMI, XML, XSLT.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

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.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

Table des matières Remerciements .............................................................................................................................. Résumé .......................................................................................................................................... Abstract ......................................................................................................................................... Table des matières ......................................................................................................................... Lexique .......................................................................................................................................... Introduction ................................................................................................................................. 1 1 Présentation du contexte ..................................................................................................... 2

1.1 Présentation de l’organisme d’accueil ................................................................................... 2 1.1.1 Le Cemagref ................................................................................................................... 2 1.1.2 Le centre de Clermont-Ferrand ..................................................................................... 3 1.1.3 L’UR « Technologies et systèmes d’information pour les agrosystèmes » ................... 3 1.1.4 L’équipe « Systèmes d’information communicants et agri-environnementaux » ........ 3

1.2 Contexte technique ................................................................................................................ 4 1.2.1 Les technologies XML .................................................................................................... 4 1.2.2 Modèles de données et interopérabilité ...................................................................... 6 1.2.3 Conclusion sur XML ....................................................................................................... 8

2 Analyse du problème ............................................................................................................ 9 2.1 Cahier des charges ................................................................................................................. 9 2.2 Etude des entrées et sorties XMI ........................................................................................... 9

2.2.1 Recensement des entrées/sorties ............................................................................... 10 2.2.2 Equivalence UML1-UML2 ............................................................................................ 11 2.2.3 Conformité des sorties XMI ......................................................................................... 12 2.2.4 Interopérabilité des modèles UML.............................................................................. 14

2.3 Organisation du travail ......................................................................................................... 15 2.3.1 Planning ....................................................................................................................... 15 2.3.2 Plan de développement .............................................................................................. 18

3 Conception de la solution ................................................................................................... 20 3.1 Architecture du workflow .................................................................................................... 20 3.2 Transformations XSLT .......................................................................................................... 22

3.2.1 Prétraitements ............................................................................................................ 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 d’utilisation ........................................................................................................... 32 3.3.2 Classes candidates et diagrammes de classes............................................................. 34 3.3.3 Diagrammes de collaboration et de séquence ........................................................... 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 L’environnement de développement intégré ............................................................. 38

4 Réalisations ........................................................................................................................ 39 4.1 Réalisation des transformations .......................................................................................... 39

4.1.1 Prétraitements ............................................................................................................ 39 4.1.2 Transformation UML2OWL ......................................................................................... 40 4.1.3 Transformation OWL2UML ......................................................................................... 45 4.1.4 Tests et validation ....................................................................................................... 46

4.2 Réalisation de l’application MOST ....................................................................................... 47

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

4.2.1 Maquette et exemples de principes ........................................................................... 47 4.2.2 Génération de l’architecture du code ......................................................................... 50 4.2.3 Implémentation des modules ..................................................................................... 50

5 Résultats et prolongements ................................................................................................ 51 5.1 Etats des lieux ...................................................................................................................... 51

5.1.1 Ce qui a été réalisé ...................................................................................................... 51 5.1.2 Ce qu’il reste à faire .................................................................................................... 51 5.1.3 Améliorations possibles et prolongement .................................................................. 51

5.2 Bilan ..................................................................................................................................... 52 Conclusion ................................................................................................................................. 53 Index des illustrations .................................................................................................................... Références bibliographiques ...........................................................................................................

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

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

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

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

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 1/53

Introduction

Dans le domaine du développement logiciel la conception des architectures est guidée par les modèles. Cette démarche s'appelle Model Driven Architecture (MDA). Le langage privilégié pour décrire le MDA est UML. Des ateliers de génie logiciel permettent de réaliser ces modèles et de générer le code correspondant dans divers langages objets.

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

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 2/53

1 Présentation du contexte

L’objectif de cette partie est de présenter le contexte de cette étude. Elle présente dans un premier temps l’organisme dans lequel ces travaux ont été réalisés. Dans un second temps elle présente le contexte technique de l’étude, c’est-à-dire les principales technologies mises en jeu.

1.1 Présentation de l’organisme d’accueil

1.1.1 Le Cemagref

L’institut de recherche en sciences et technologies pour l’environnement, plus connu sous le

nom de Cemagref, a été créé en 1981. C’est un établissement public à caractère scientifique et technologique placé sous la double tutelle des ministères en charge de la recherche et de l'agriculture. Son activité se regroupe autour de trois thèmes structurés en trois départements :

Eaux (ressources, milieux, usages et risques)

Ecotechnologies (réseaux, épuration, déchets)

Territoires (développement territorial, biodiversité, risques et vulnérabilités)

Eaux, territoires et écotechnologies sont des thématiques qui répondent aux besoins de la société. Les moyens mis en œuvres par le Cemagref pour répondre à ces problématiques s’étendent de la recherche à l’action. En effet il fournit un appui scientifique et technique à la décision (études, expertises, modèles et outils opérationnels) et des solutions d’ingénierie qui intègrent des composantes pluridisciplinaires. Labellisé Carnot en 2006, le Cemagref a de nombreux partenaires industriels leaders dans la gestion de l’eau, des déchets et des équipements agricoles. Actif aussi au niveau Européen, il est partenaire du réseau Partnership for European Environmental Research (PEER) qui regroupe sept grands instituts européens de recherche dédiés aux interactions entre l’homme et son environnement. D’autre part le Cemagref est fortement impliqué dans l’enseignement supérieur, notamment en termes de participation à la formation. Il développe des alliances autant avec les pôles de recherche et d’enseignement supérieur français qu’avec des universités étrangères.

Figure 1 : Les centres du Cemagref

Le Cemagref en quelques chiffres c’est :

9 centres et 2 implantations hors centres (Strasbourg et Martinique)

20 unités de recherche propres (UR)

5 unités de recherche mixtes (Cirad, Inra, IRD, Engees, AgroParisTech, SupAgro)

1400 collaborateurs dont 500 ingénieurs et chercheurs, 200 doctorants et 40 post-doctorants

Un budget en 2010 de 110 M€ (dont 31 M€ de ressources propres)

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 3/53

1.1.2 Le centre de Clermont-Ferrand

Le centre de Clermont-Ferrand est implanté sur deux sites : le site d'Aubière (Puy de Dôme)

et le site de Montoldre (Allier).

Le Cemagref mène en Auvergne des recherches autour de deux axes :

les innovations technologiques pour l'agriculture raisonnée et pour l'environnement

le développement régional et l'aménagement du territoire

Le centre de recherche de Clermont-Ferrand dispose de deux unités de recherche (UR) :

Laboratoire d'Ingénierie des Systèmes Complexes (LISC)

Technologies et systèmes d’information pour les agrosystèmes (TSCF), composée de quatre équipes :

o Technologies épandage, agroéquipements, mobilité o Matériaux et milieux o Systèmes d’information communicants et agri-environnementaux o Sciences-technologies et procédés d'épandage

Et d’une unité de recherche mixte : Mutations des activités, des espaces et des formes

d’organisation dans les territoires ruraux (UMR Métafort).

Les thèmes de recherche abordés sont les suivants :

Développement Territorial et Agriculture Multifonctionnelle

Innovations technologiques pour l'agriculture durable et l'environnement

Modèles, systèmes d'information et gestion viable de l'environnement

1.1.3 L’UR « Technologies et systèmes d’information pour les agrosystèmes »

L’unité «Technologies et systèmes d’information pour les agrosystèmes» mène des

recherches sur les méthodes et outils pour une ingénierie des systèmes complexes que sont les systèmes agri-environnementaux.

Elles portent sur les technologies de la mobilité pour la sécurité et la qualité du travail des machines, sur les technologies d’épandage de matériaux organiques ou minéraux. Les systèmes écologiques y sont également abordés, à travers les technologies pour la perception et la caractérisation du sol. Enfin des recherches sont conduites sur les systèmes d’information et de communication partagés en collaboration avec les recherches menées plus largement à l’UMR «Territoires, environnement, télédétection et information spatiale» associant des équipes Cemagref, CIRAD et AgroPariTech.

1.1.4 L’équipe « Systèmes d’information communicants et agri-environnementaux »

L’activité de l’équipe « Systèmes d’information communicants et agri-environnementaux »

est consacrée aux méthodes d’ingénierie des systèmes d’information spatialisés dédiées à la gestion agri-environnementale. Cet ensemble de méthodes couvre l’analyse des besoins des acteurs, la spécification des systèmes d’information, leur modélisation, leur conception, leur gestion et leur lien avec les sources de données.

L’objectif de l'équipe est de développer des méthodes et des techniques selon deux axes :

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 4/53

déployer et gérer des réseaux de capteurs communicants adaptés aux problèmes agri-environnementaux

concevoir et gérer des systèmes d’information, tels que des entrepôts de données ou des systèmes de gestion des connaissances, adaptés au contexte de l’agri-environnement

Les thèmes de recherche associés sont les modèles, les systèmes d'information et la gestion

viable de l'environnement. Les domaines de spécialité de l’équipe sont le génie logiciel, la modélisation UML, les

entrepôts de données spatiales, l’informatique, les télécommunications et les réseaux de capteurs.

1.2 Contexte technique

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 l’interopérabilité des données entre des systèmes d’information différents. Il permet de stocker des informations arborescentes dans des fichiers de type texte. La structure de ses balises est facilement reconnaissable par l’usage des chevrons (< et >). Les principaux éléments de structure d’un document XML sont décrits dans la figure ci-contre.

Figure 2 : Syntaxe d'un fichier XML

Le langage XML est très largement utilisé dans de nombreux domaines de l’informatique et

de nombreux autres langages se basent sur sa syntaxe.

Un document XML doit respecter un certain nombre de règles éditées par le W3C. Parmi celles-ci on peut citer la correspondance des balises ouvrantes et fermantes, l’existence d’une racine unique, etc.

En plus de respecter ces règles un document XML a la possibilité de devoir être valide par

rapport à un schéma. Deux types de schéma sont principalement utilisés : DTD et XSD (aussi appelé XML Schema).

La DTD est une méthode de validation de la syntaxe et de la structure d’un fichier XML, elle définit les balises et attributs utilisables dans un document XML et leurs imbrications possibles. DTD n’est pas basée sur la syntaxe d’XML.

Le XML Schema est le successeur de la DTD et est plus restrictif car il impose les types de données des éléments. XSD est un document XML.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 5/53

1.2.1.2 eXtensible Stylesheet Language Transformation

Un document XML peut être transformé en un autre document XML grâce à la technologie XSLT. XSLT s’appuie sur des feuilles de style, ce sont des documents XML qui contiennent les transformations qui doivent être réalisées. Une transformation XSLT se passe généralement de la façon suivante : on donne un document XML et une feuille de style à un processeur XSLT qui applique les transformations et produit un nouveau document qui peut être sérialisé dans un fichier XML, HTML ou texte.

Les processeurs XSLT acceptent cependant plusieurs documents XML et plusieurs feuilles de style en entrée et peuvent produire plusieurs documents en sortie (sorties multiples en XSLT 2.0 uniquement).

Figure 3 : Transformation XSLT

Une feuille de style contient un ensemble de « fonctions » appelées template rules. Une template rule est constituée de deux parties : un pattern et un template. Le pattern est un motif qui sert à identifier les nœuds de l’arbre d’entrée auxquels va s’appliquer la template rule. Le template est le fragment d’arbre qui va être écrit dans l’arbre résultat. Un template peut contenir des résultats sous forme de texte ou encore des instructions XSLT, par exemple pour le traitement des nœuds enfants du nœud courant.

Figure 4 : Exemple de template rule XSLT

Dans cet exemple pour chaque nœud Pattern on écrit deux nœuds dans l’arbre résultat,

ResultTreeFragment et PatternNodeValue contenant le contenu du nœud Pattern. En l’absence d’une template rule adaptée à un nœud c’est une template rule native qui est appliquée à ce nœud. Elle permet de continuer le parcours récursif de l’arbre.

Figure 5 : Template rule native

Le document est ainsi parcouru en appliquant à chaque nœud la template rule ayant le

meilleur pattern correspondant. La recherche des nœuds dans les arbres XML se fait grâce à la technologie XML Path Language (XPath).

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 6/53

1.2.2 Modèles de données et interopérabilité

1.2.2.1 Modèle UML

Unified Modeling Language (UML) est un langage graphique permettant de spécifier, construire et documenter les objets d’un système informatique. UML représente l’unification des techniques les plus utilisées et les mieux conçues de modélisation orienté objet.

UML fait partie d’une architecture de métadonnées plus grande encore : Meta Object Facility (MOF). UML et MOF sont des spécifications de l’Object Managment Group *OMGMMS+.

Figure 6 : Architecture MOF

Un modèle est une abstraction d’un système physique réel dans un certain but. Un méta-modèle est un modèle qui défini le langage de description des modèles. Un méta méta-modèle est un modèle qui défini le langage de description des méta-modèles. Chaque couche de cette architecture est considérée comme une instance de la couche

supérieure.

Les modèles UML sont sérialisés dans des fichiers XMI (XML Metadata Interchange). XMI est aussi un standard de l’OMG pour l’interopérabilité et la sérialisation des modèles UML [OMGMMS]. Le langage XMI est basé sur la syntaxe XML.

1.2.2.2 Web Ontology Language (OWL)

Une ontologie est un modèle permettant de décrire de manière formelle les concepts d’un

domaine et les relations entre ces concepts. OWL est une famille de langages permettant de décrire des ontologies. OWL est une recommandation du W3C [W3COWL].

OWL est basé sur des logiques de description (opérateurs du type intersection, union, négation, équivalence, …). Ces logiques de description permettent de faire des raisonnements et de classifier les instances des concepts.

Les raisonnements en OWL sont sujets à deux hypothèses :

l’Open World Assumption : signifie que ce qui n’est pas dit est supposé indéfini, autrement dit le fait que quelque chose ne soit pas déclaré comme vraie ne suffit pas à conclure qu’elle est fausse.

l’Unique Name Assumption n’est pas respectée par OWL : deux noms différents ne font pas nécessairement références à deux objets différents.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 7/53

Il existe trois types d’ontologies OWL : OWL Lite, OWL DL et OWL Full. Ces trois types ont des pouvoirs d’expression croissants. Cependant du fait de sa grande expressivité OWL Full n’est pas un langage décidable, c’est-à-dire que l’aboutissement d’un algorithme sur une ontologie OWL Full n’est pas garanti en temps fini.

Dans le langage OWL les classes définissent les concepts du domaine et les individus sont des instances de ces classes. Les relations entre les classes sont définies par des properties. Les properties peuvent être schématisées de la manière suivante :

Figure 7 : Exemple OWL

Deux types de properties sont remarquables : les datatype properties lient les individus à des

types de donnée et les objects properties lient des individus à d’autres individus. En OWL il existe des conditions nécessaires et/ou suffisantes qui permettent de déterminer si

un individu appartient à une classe. Ces conditions sont appelées des restrictions, il en existe plusieurs sortes :

Pizza : subclassOf(aPourGarniture only Tomate) Une Pizza a pour garniture uniquement des Tomates

Pizza : subclassOf(aPourGarniture some Tomate) Une Pizza a pour garniture au moins une Tomate

Pizza : subclassOf(aPourGarniture max Tomate n) Une Pizza a au maximum n Tomate pour garniture

Pizza : subclassOf(aPourGarniture min Tomate m) Une Pizza a au minimum m Tomate pour garniture

Ensuite des raisonneurs permettront de classifier les individus d’une ontologie et par exemple, en fonction de ses ingrédients un plat pourra être reconnu comme une Pizza.

Une ontologie OWL peut être sérialisée dans un fichier. La sérialisation d’ontologies est basée sur Resource Description Framework (RDF) et RDF Schema (RDFS). RDF et RDFS ont des syntaxes basées sur XML.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 8/53

1.2.3 Conclusion sur XML

On remarque que beaucoup des technologies impliquées dans ce document sont basées sur

la syntaxe d’XML. On peut les représenter de la façon suivante :

Figure 8 : Les langages basés sur XML

XML fournit la syntaxe du langage (balises) et les autres langages définissent un vocabulaire (noms des balises).

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 9/53

2 Analyse du problème

Cette partie détaille l’analyse du problème avec dans une première partie la rédaction du cahier des charges qui identifie les travaux à réaliser. Dans une deuxième partie une étude de l’interopérabilité entre ateliers de génie logiciel est résumée. Enfin la dernière partie explique le plan de travail adopté.

2.1 Cahier des charges

Le but de ce stage est de produire des outils de transformation de modèles stockés dans différents formats XMI pour faciliter l’interopérabilité des AGL.

Pour cela une étude de compatibilité entre les formats XMI et les outils AGL sera demandée en premier lieu. L’étude portera sur plusieurs aspects de la compatibilité :

1. compatibilité entre AGL pour un format XMI donné, Par exemple un fichier XMI 1.2 produit par un AGL donné est-il totalement lisible avec un autre AGL ? Cette étude portera sur les AGL les plus populaires dans le monde Java.

2. compatibilité entre formats XMI, Le but est de vérifier que l’ensemble des éléments décrits dans un format XMI 1.0 peut être décrit dans un format XMI 2.1 et inversement.

3. l’étude devra aussi s’intéresser plus particulièrement à la description des contraintes d’intégrité en UML et leurs différentes formes de stockage en XMI.

Dans un second temps les outils qui seront développés devront permettre de produire deux

types de fichiers : 1. des fichiers OWL, 2. les différentes versions des fichiers XMI.

Une attention particulière sera portée sur la restitution des commentaires des objets UML. La réalisation de ces outils s’appuiera sur les technologies XML associées comme XSLT. Pour plus d'ergonomie ces différents outils seront ensuite intégrés dans une application développée en langage Java.

2.2 Etude des entrées et sorties XMI

L'étude suivante va être réalisée sur les entrées/sorties XMI des ateliers de génie logiciel ci-dessous :

ArgoUML

Bouml

Enterprise Architect

Mega

Modelio (successeur d'Objecteering)

Objecteering

Poseidon (construit à partir d'ArgoUML)

PowerAMC

StarUML

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 10/53

Cette liste n'a pas pour but d'être exhaustive mais présente des AGL très utilisés dans le domaine du développement logiciel. Les AGL utilisés au Cemagref sont Enterprise Architect, Mega, Objecteering (maintenant Modelio) et PowerAMC.

2.2.1 Recensement des entrées/sorties

La première étape de l'analyse des fichiers XMI produits par les divers AGL a été de faire un recensement des versions utilisées pour l'import et l'export de modèles depuis les AGL. Elle est synthétisée dans le tableau suivant.

AGL Import Export UML Version(s) correspondante(s)

Version courante

ArgoUML XMI 1.0 XMI 1.1 XMI 1.2

XMI 1.2

UML 1.3 UML 1.4 UML 1.4

ArgoUML 0.28 ArgoUML 0.30.1 (06/05/2010)

BOUML XMI 2.1

XMI 1.2 XMI 2.1

UML 1.4 UML 2.x

BOUML 4.21 BOUML 4.21 (12/05/2010)

Enterprise Architect

XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1

XMI 1.0 XMI 1.1 XMI 1.2 XMI 2.1

UML 1.3 UML 1.3 UML 1.4 UML 2.x

Enterprise Architect 7 et ultérieures

Enterprise Architect 8 build 856 (05/05/2010)

Mega XMI 1.0 UML 1.3 Mega 2009 SP3 (02/2010)

Modelio XMI 2.1 XMI 2.1 UML 2 Modelio 1.2 Modelio 1.2 (19/05/2010)

Objecteering XMI 2.1 XMI 2.1 UML 2.x Objecteering 6.1 Objecteering 6.1 SP4 (25/11/2009)

Poseidon XMI 1.0 XMI 1.1 XMI 1.2

XMI 1.2

UML 1.3 UML 1.3 UML 1.4

Poseidon 6.0 et ultérieures Poseidon 8.0

PowerAMC XMI 1.1 XMI 1.1 UML 1.3 PowerAMC 9.0 à 15 PowerAMC 15.2 XMI 2.1 XMI 2.1 UML 2.x PowerAMC 15.1 et 15.2

StarUML XMI 1.1 XMI 1.1 UML 1.3 StarUML 5.0 StarUML 5.0 (30/12/2005)

Figure 9 : Imports et exports XMI

Ces informations sont disponibles sur les documentations en ligne et guides de l'utilisateur

des AGL.

La colonne UML correspond à la norme UML choisie par l'atelier de génie logiciel pour représenter le modèle, il est ensuite écrit dans une version de XMI.

Ici UML 2.x représente seulement les versions UML 2.0 et UML 2.1.1, et l'absence de version mineure indique que la documentation n'en fait pas mention.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 11/53

On remarque déjà des associations privilégiées entre UML et XMI. Afin d’être plus complet j’ai recensé les versions de UML et de XMI existantes grâce aux spécifications de l’OMG *OMGMMS].

UML 1.3 UML 1.4 UML 1.5 UML 2.0 UML 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 grisées indiquent que les associations UML/XMI correspondantes n’existent pas. Les annotations DTD et XSD indiquent que les spécifications de l’OMG incluent un document de validation des fichiers XMI. La première remarque qui peut être faite sur ce tableau est qu’il n’existe pas toujours une unique version de XMI permettant de sérialiser les modèles d’une version d’UML donnée. Il convient aussi de noter que parmi toutes les spécifications d’UML et d’XMI seulement une partie est effectivement utilisée par les AGL pour la sérialisation de modèles UML, à savoir :

UML 1.3 XMI 1.0

UML 1.3 XMI 1.1

UML 1.4 XMI 1.1

UML 1.4 XMI 1.2

UML 2.0 XMI 2.1

UML 2.1 XMI 2.1

2.2.2 Equivalence UML1-UML2

L'analyse du contenu des fichiers XMI révèle d'abord que l'ensemble des objets qui vont être utilisées par la suite, sont présents quelque soit la version d’UML comme le montre le tableau suivant :

UML 1.3 UML 1.4 UML 2.0 UML 2.1

Modèle oui oui oui oui

Package oui oui oui oui

Classe oui oui oui oui

Attribut oui oui oui oui

Généralisation oui oui oui oui

Association oui oui oui oui

Commentaire oui oui oui oui

Type de données oui oui oui oui

Enumération oui (1) oui (1) oui oui

Classe d'association oui oui oui oui

Association n-aire oui oui oui oui

Figure 11 : Equivalence des versions d'UML

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 12/53

(1) Est parfois implémenté sous forme de stéréotype de classe.

Il n'est pas fait mention ici des méthodes car elles ne sont pas utilisées. En effet le but des modèles sur lesquels je vais travailler n'est pas de faire du développement mais de la représentation de connaissances.

Tous les objets sur lesquels se focalise cette étude sont présents dans toutes des versions d’UML. Ainsi un modèle décrit en UML 1 peut être entièrement décrit avec UML 2 (ce qui est logique compte tenu de la compatibilité ascendante) et vice versa.

2.2.3 Conformité des sorties XMI

Un problème a été identifié lors de l’analyse de l’équivalence des versions UML : pour une même version d’UML et de XMI la manière de décrire les objets varie en fonction de l'AGL.

Figure 12 : Généralisation sous PowerAMC

Figure 13 : Généralisation sous StarUML

Il m'a donc fallu trouver un moyen de distinguer quelle est la « bonne » syntaxe pour décrire ces objets. Mes recherches m'ont conduit vers des méthodes de validation des fichiers XML qui sont la DTD et le XSD. Ce sont deux manières plus ou moins restrictives de décrire le contenu d'un fichier XML. Si un fichier XML respecte les règles dictées par une DTD ou un XSD alors il est considéré comme conforme à cette DTD ou ce XSD.

L'OMG a produit des DTD et XSD pour certains couples de version UML/XMI. Par exemple, pour UML 1.3 XMI 1.1, la structure conforme d’une généralisation est la suivante :

Figure 14 : Généralisation UML 1.3 XMI 1.1 conforme

Grâce à ces schémas j'ai été en mesure de vérifier la validité des sorties des AGL par rapport

aux spécifications de l'OMG.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 13/53

Les résultats de la validation des sorties XMI sont résumés dans les tableaux ci-dessous :

UML 1.3

XMI 1.0 XMI 1.1

UML / AGL Arg

oU

ML

BO

UM

L

Ente

rpri

se A

rch

itec

t

Meg

a

Mo

del

io

Ob

ject

eeri

ng

Po

wer

AM

C

Star

UM

L

Arg

oU

ML

BO

UM

L

Ente

rpri

se A

rch

itec

t

Meg

a

Mo

del

io

Ob

ject

eeri

ng

Po

wer

AM

C

Star

UM

L

Modèle

Package

Classe

Attribut

Généralisation

Association

Commentaire

Enumération (*) (*) (*)

Classe d'association

Association n-aire

Figure 15 : Conformité des AGL pour UML 1.3

UML 1.4 UML 2.1

XMI 1.2 XMI 2.1

UML / AGL Arg

oU

ML

BO

UM

L

Ente

rpri

se A

rch

itec

t

Meg

a

Mo

del

io

Ob

ject

eeri

ng

Po

wer

AM

C

Star

UM

L

Arg

oU

ML

BO

UM

L

Ente

rpri

se A

rch

itec

t

Meg

a

Mo

del

io

Ob

ject

eeri

ng

Po

wer

AM

C

Star

UM

L

Modèle

Package

Classe

Attribut

Généralisation

Association

Commentaire

Enumération (*) (*)

Classe d'association

Association n-aire

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

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 14/53

Légende Conformité

Conforme

Non conforme (mais passe en traitement général)

Non conforme (nécessite un traitement spécifique)

Sortie non générée

Information manquante

(*) Stéréotype : classe/attributs

On remarque que peu d'AGL sont totalement conformes. Cependant j'ai identifié un "degré de gravité" dans la non-conformité. Il consiste à dire que les non-conformités qui sont traitables de la même manière que les conformités sont peu graves. Tandis que les autres nécessiteront un traitement spécifique.

2.2.4 Interopérabilité des modèles UML

L’analyse des imports et exports des ateliers de génie logiciel permet de conclure sur l’interopérabilité des données.

Tout d'abord UML et XMI vont toujours de pair, c'est-à-dire que pour décrire un modèle il faut une version d'UML et une version d’XMI. Cela a un impact direct sur l'interopérabilité puisque, les normes d'UML et d'XMI évoluant séparément, c'est de nombreuses combinaisons d'UML/XMI qui coexistent. Cependant on remarque aussi que toutes les associations UML/XMI ne sont pas utilisées.

Pour mieux évaluer l’interopérabilité on peut représenter chaque version de XMI comme un

medium de communication et ainsi obtenir le réseau suivant :

Figure 17 : Réseau des AGL

Pour un AGL la colonne de gauche représente les ports d’entrées XMI et celle de droite les

ports de sorties. Les ports qui sont ouverts sont représentés en vert, ceux fermés en rouge. Sur ce réseau nous pouvons voir que rien ne garanti la communication entre deux AGL et

encore moins la communication dans les deux sens. Par exemple Bouml et StarUML sont incapables

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 15/53

d’échanger des modèles, ArgoUML accepte la sortie XMI 1.2 de Bouml mais Bouml n’accepte pas celle d’ArgoUML. A cela il faut ajouter les nombreuses et variées non-conformités des écritures des fichiers XMI par les AGL. Elles diminuent d'autant plus l'interopérabilité.

Ainsi on constate que, sans mécanisme intermédiaire, l'interopérabilité entre les AGL est

plutôt pauvre. On note malgré tout une amélioration pour UML 2 XMI 2.1. Il reste à déterminer si cette

amélioration résulte d’une réelle volonté d’interopérabilité ou du caractère récent de ces versions.

2.3 Organisation du travail

2.3.1 Planning

Suite à l'identification du travail à effectuer j'ai mis en place un planning prévisionnel de

l'enchainement des tâches. Il est décrit dans le diagramme de Gantt donné plus loin.

La première tâche est l'étude et la formation aux technologies et logiciels utilisés lors de ce stage. A savoir XML, XSLT, UML, XMI et OWL pour les technologies et XMLSpy, Protégé et quelques AGL pour les logiciels. Bien que cette tâche ne soit pas indiquée comme devant durer tout au long du stage il est plus que probable que des retours ponctuels y soient nécessaires.

La seconde tâche est l'identification et l'étude des entrées/sorties XMI des AGL. Les tâches suivantes sont la réalisation des transformations UML vers OWL et OWL vers UML

qui seront menées en parallèle. Ensuite la réalisation de l'application interviendra lorsque les transformations seront

suffisamment avancées. Enfin tout au long du stage les présentations réalisées et documents écrits seront capitalisés en vue de la rédaction du rapport et de la préparation de la soutenance. L'enchaînement et la durée des tâches n'ont pas tout à fait suivit le planning tel qu'il était prévu. Le planning réel est donné ci-après. Tout d'abord l'identification des non-conformités c'est faite en cours de réalisation des transformations. Il a donc fallu retourner vers une analyse plus poussée des entrées/sorties XMI avec étude de la conformité. Cette étude a été suivie d’une étape non prévue initialement : la réalisation de transformations de prétraitements.

Malgré ce contretemps les tâches de réalisations des transformations ont avancé plus vite que prévu et la réalisation de l'application Java a débuté avec deux semaines d'avance.

Les tâches correspondant aux conversions UML vers OWL et OWL vers UML ont, elles aussi, subit des modifications puisqu’en cours de projet des éléments à traiter ont été identifiés et ajoutés : ce sont les énumérations, classes d’associations et associations n-aires. La partie étude des contraintes d’intégrités a été abandonnée car elles ne sont pas écrites dans les fichiers XMI.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 16/53

Figure 18 : Planning prévisionnel

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 17/53

Figure 19 : Planning réel

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 18/53

2.3.2 Plan de développement

La démarche générale qui a été suivie pour réaliser les outils de ce stage et guidée par un

cycle de développement en V [MODL]. Ce type de cycle associe à chaque phase du développement une phase de test.

Figure 20 : Cycle de développement en V

Les phases de développement :

- Prise en compte du besoin et rédaction du cahier des charges - Analyse et étude de faisabilité - Conception de l’architecture du système - Conception des modules du système - Implémentation des modules

Les objectifs des tests correspondant aux phases de développement sont les suivants :

- le test unitaire : teste le bon fonctionnement d’un module (indépendamment du système) - le test d’intégration : teste le bon fonctionnement du système lors de l’ajout d’un module - le test fonctionnel : vérifie que le système rend bien les services attendus - le test de validation : vérifie que le système répond bien aux exigences du cahier des charges

Pour la réalisation de chaque module les parties conception, implémentation et tests unitaires sont regroupées dans une itération. Une itération est la réalisation d’une fonctionnalité du système qui, une fois validée, est intégrée au système. L’intérêt de fonctionner par itérations est de ne pas pouvoir remettre en cause, à une itération donnée, ce qui a été développé antérieurement.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 19/53

Figure 21 : Déroulement d'une itération

Chaque itération a suivi un cycle de développement en Y.

Figure 22 : Cycle de développement en Y

Le cycle de développement en Y traite en parallèle la capture des besoins fonctionnels (que doit faire le module ?) et la capture des besoins techniques (comment réaliser cette fonctionnalité ?). Une fois des réponses trouvées à ces deux questions l’implémentation peut débuter.

Ce plan de développement a été suivi autant pour l’application Java que pour la réalisation des transformations XSLT. En effet, pour XSLT la conversion de chaque objet UML a fait l’objet d’une itération et pour Java ce sont les différentes fonctionnalités.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 20/53

3 Conception de la solution

Cette partie présente la solution théorique créée pour réaliser les objectifs du stage. Elle introduit le principe de fonctionnement des outils et explique le choix des technologies qui ont été retenues pour les réalisations.

3.1 Architecture du workflow

Le cahier des charges impose la production de deux types de sorties différentes : des fichiers OWL et des fichiers XMI.

Pour produire toutes les versions des fichiers XMI à partir de n’importe quelle version d’un

fichier d’entrée il est intéressant de passer par un langage pivot. C’est-à-dire effectuer une conversion du XMI dans un langage L, puis reconvertir de ce langage L vers XMI.

Dans le cas de ces travaux, six versions d’UML/XMI sont couramment utilisées par les AGL. Le nombre de transformations à écrire pour les versions UML/XMI considérées serait de 30 « directes » contre 12 avec un langage intermédiaire.

C’est OWL qui a été choisi comme langage intermédiaire. La première raison est que le cahier des charges demande la création de sortie OWL pour les modèles UML. La seconde raison est qu’OWL donne une représentation sémantique du modèle. Les informations sont extraites en ignorant les aspects implémentation et développement d’UML. Afin de produire des outils en accord avec les spécifications de l’OMG les transformations UML vers OWL s’appliqueront à des entrées XMI conformes et les transformations OWL vers UML produiront des sorties XMI conformes. Ces choix permettront aussi une meilleure réutilisabilité et maintenabilité des outils.

Cependant peu d’AGL produisent des sorties conformes. Il faut pourtant que ces outils puissent les traiter avec des pertes minimales. La solution choisie est de leur appliquer une phase de prétraitement, dite de conformité, dont l’objectif est produire une sortie XMI conforme aux spécifications de l’OMG.

Les choix d’implémentation des transformations impliquent que les fichiers en entrée aient un formatage minimum. Plus précisément, certains objets UML (packages, classes,…) devront avoir un nom et un identifiant. Une deuxième phase de prétraitement, dite de formatage, sera donc appliquée à la suite de la phase de conformité.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 21/53

L’architecture du workflow est décrite dans la figure ci-dessous.

Figure 23 : Organisation du workflow

Concrètement nous pouvons identifier les principales feuilles de style à réaliser, par exemple

pour les prétraitements de conformité, une feuille de style pour :

PowerAMC UML 1.3 XMI 1.0

PowerAMC UML 1.3 XMI 1.1

StarUML UML 1.3 XMI 1.1

Pour les prétraitements de formatage une feuille de style par version XMI, soit quatre au total. Pour UML2OWL six feuilles de style correspondant aux transformations de chaque version UML/XMI vers OWL. Pour OWL2UML six feuilles de style correspondant aux transformations d’OWL vers chaque version UML/XMI. La succession des traitements de ce workflow est implémentée dans une application Java appelée MOST. Les liens avec les feuilles de styles responsables des transformations sont réalisés au moyen d’un fichier de configuration.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 22/53

Figure 24 : Contexte de l'application MOST

L’application accepte en entrée un fichier (XMI ou OWL) et des commandes de l’utilisateur. En fonction des commandes elle produit des sorties obtenues par transformation du fichier en entrée avec les feuilles de styles et un processeur XSLT. Les parties suivantes présentent respectivement les solutions développées pour la réalisation des transformations XSLT et de l’application MOST.

3.2 Transformations XSLT

3.2.1 Prétraitements

Comme mentionné précédemment une phase de prétraitement est appliquée aux sorties des

AGL. Son objectif est de corriger la conformité du XMI et de lui donner un format standard. Ce prétraitement se compose de deux étapes successives :

1. La phase de prétraitement de conformité 2. La phase de prétraitement de formatage

Le processus de prétraitement est décrit par l’organigramme suivant :

Figure 25 : Algorithme de prétraitement

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 23/53

3.2.1.1 Prétraitement de conformité

La nature et les différences entre les non-conformités identifiées conduisent à associer une transformation de conformité à un triplet AGL, version XMI, version UML. Par exemple la sortie UML 1.3 XMI 1.0 de PowerAMC présente des non-conformités, il lui sera donc associé un fichier XSLT dans lequel seront écrites les transformations nécessaires pour la rendre conforme. De la même manière sa sortie UML 1.3 XMI 1.1 aura elle aussi un fichier de transformation adapté. Chaque fichier de transformation de conformité agira ainsi de manière ciblée sur une sortie XMI non-conforme.

3.2.1.2 Prétraitement de formatage

Il s’agit ici de rajouter des éléments dans les fichiers XMI, qui ne sont pas nécessaires à la conformité mais indispensables pour la conversion UML vers OWL. Ces éléments sont un nom et un identifiant. Le tableau suivant récapitule la nécessité pour les objets d’avoir un nom et/ou identifiant.

Objet Identifiant Nom

UML:Model oui oui

UML:Package oui oui

UML:Class oui oui

UML:Attribute non oui

UML:Generalization oui non

UML:Association oui non

UML:AssociationEnd oui non

UML:DataType oui non Figure 26 : Nécessité d’un prétraitement de formatage

La phase de prétraitement de formatage peut être appliquée de manière générique à une

version de XMI. En effet le test et l’ajout si besoin d’un nom et d’un identifiant ne requiert pas connaissance de la version d’UML et de l’AGL exportateur. Ainsi un seul fichier XSLT sera affecté à chaque version de XMI.

3.2.2 Correspondance UML-OWL

Les diagrammes UML suivant mettent en évidence les objets UML et OWL2 [W3COWL] qui

sont utilisés dans cette étude et les relations qui les lient.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 24/53

Figure 27 : Objets UML

Figure 28 : Objets OWL

Les agrégations représentent les relations d’appartenance d’un nœud fils à un nœud parent

au sens des arborescences. Par exemple en XMI un nœud attribut appartient à un nœud classe. On remarque sur ces figures que le nombre d’objets UML est supérieur à celui des objets

OWL, cela implique qu’à un objet OWL seront associés plusieurs objet UML.

Pour la réalisation des transformations UML vers OWL il faut bien garder à l’esprit que la transformation inverse doit ensuite pouvoir être réalisée. Il faut donc veiller à ce que les transformations implémentées soient réversibles. Le tableau suivant résume les associations entre objets UML et OWL qui ont été choisies pour réaliser les conversions.

UML OWL

Modèle Ontologie

Package Ontologie

Classe Classe

Attribut Datatype property

Méthode (inutilisées)

Généralisation (héritage) subClassOf

Association Object property

Agrégation Object property

Composition Object property

Commentaire Annotation property

Type de données Type de données XSD

Enumération Value Partition (Design Pattern)

Classe d'association 2 Object properties

Association n-aire Object properties

Figure 29 : Correspondance UML-OWL

Modèle et package Les modèles et packages sont des conteneurs qui regroupent des classes appartenant à un même domaine. Ils représentent en quelque sorte un modèle de données, c’est pourquoi ce sont les ontologies qui vont leur être associées.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 25/53

Classe Les classes sont utilisées autant en UML qu’en OWL pour représenter des objets ou un ensemble d’individus. Elles seront donc associées l’une à l’autre. Attribut Les attributs sont des propriétés liant les classes à d’autres objets (généralement des types de données). En OWL ce sont les datatype properties qui lient les classes aux types de données. La conversion entre attribut et datatype property se fera donc de la façon suivante :

Figure 30 : Transformation des attributs

Déclaration(s) : 1 datatype property : hasNom

Restriction(s) : 1 restriction sur la classe Organisation : hasNom some String Méthode Les méthodes ne sont pas prises en compte dans ces transformations car les modèles utilisés ne sont pas destinés au développement logiciel mais à la représentation de connaissances. Généralisation Le concept de généralisation-spécialisation est présent en UML et en OWL. En OWL il est matérialisé par la relation de subsomption (intitulée subclassOf en RDFS).

Figure 31 : Transformation des généralisations

Restriction(s) : 1 restriction sur la classe Entreprise : subClassOf Organisation

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 26/53

Association, agrégation et composition En XMI les associations, agrégations et compositions sont très similaires. Elles définissent des relations entre les objets. En OWL les relations entre objets sont définies par des object properties. La conversion association-object property se fera comme suit :

Figure 32 : Transformation des associations

Déclaration(s) : 2 object properties o hasAssociation_Organisation_Activité (inverseOf isAssociation_Organisation_Activité) o isAssociation_Organisation_Activité (inverseOf hasAssociation_Organisation_Activité)

Restriction(s) : 2 restrictions sur la classe Organisation o has Association_Organisation_Activité min 0 Activité o has Association_Organisation_Activité max 9999 Activité

Restriction(s) : 3 restrictions sur la classe Exercice o isAssociation_Organisation_Activité some Organisation o isAssociation_Organisation_Activité min 1 Organisation o isAssociation_Organisation_Activité max 1 Organisation

Ici on ne retrouve que deux restrictions sur la classe Organisation car la cardinalité minimum

est nulle. Or la restriction some implique une cardinalité au moins égale à 1. De plus on aperçoit l’apparition d’un 9999 à la place d’une cardinalité *. C’est un choix

d’implémentation, répondant à la contrainte qu’OWL ne gère les cardinalités que sous forme d’entier, pas de chaine de caractères.

Cet exemple met en évidence les deux cas particuliers. Dans le cas général on retrouve trois restrictions et les mêmes cardinalités en UML et OWL.

Les noms des object properties sont créés à partir du type de l’association (association,

agrégation ou composition) et des noms des classes liées. Ce choix a été fait car les noms des associations et des rôles ne sont pas toujours renseignés. Enumération L’énumération en UML est une collection d’objets. Il n’existe pas nativement de collections en OWL mais un Design Pattern a été créer dans ce but, c’est la Value Partition.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 27/53

Figure 33 : Transformation des énumérations

1. Créer une classe correspondant au nom de l’énumération 2. Créer des sous-classes correspondant aux objets de l’énumération 3. Définir les classes comme non équivalentes (owl:disjointWith) 4. Créer un axiome de couverture pour que l’énumération ne puisse pas avoir d’autres

items que ceux existants (owl:unionOf) Classe d’association Une classe d’association en UML permet de donner des attributs pour qualifier une association. Le diagramme UML d’une classe d’association est représenté ci-dessous.

Figure 34 : Classe d'association

Pour « traduire » une classe d’association en OWL on peut la décomposer en objets UML de base possédant déjà des objets OWL associés.

Par exemple, la première solution envisagée, décompose la classe d’association en une classe Localisation et une association entre Photo et Evénement. On associe ensuite les objets OWL correspondant, c’est-à-dire trois classes OWL, des datatype properties pour les attributs de Localisation et des object properties pour l’association. Cependant cette solution détruit en OWL le lien qui existait entre la classe Localisation et l’association.

Afin de conserver au mieux le sens de la classe d’association nous allons nous intéresser à un

diagramme UML équivalent à celui de la classe d’association :

Figure 35 : Equivalent classe d'association

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 28/53

Ce diagramme représente sans perte de sens la classe d’association. C’est donc celui-ci qui sera traduit en OWL. Il s’agit ici de trois classes, deux attributs et deux associations. Ce sont des objets UML auxquels des objets OWL ont déjà été associés. Association n-aire Bien que la transformation des associations n-aire ne soit pas encore implémentée la solution qui est pressentie est de considérer toutes les associations qu’elles recouvrent et les traduire en object properties.

Figure 36 : Association n-aire

Figure 37 : Equivalent association n-aire

Commentaire Les commentaires en OWL sont matérialisés par des annotation properties. Parmi celles existantes deux sont utilisées dans ces outils : rdfs:comment pour les commentaires et rdfs:label pour les noms des objets. Type de donnée En UML il est possible de créer des types de données. En OWL2 ce sont les types de donnée XSD qui sont utilisés.

3.2.3 Algorithme de transformation UML2OWL

Pour traiter un fichier avec la technologie XSLT il faut adapter son algorithme à la sortie que l’on veut produire et non au fichier en entrée. En effet on peut rechercher un élément dans le fichier d’entrée mais l’écriture dans le fichier de sortie se fait toujours à la fin.

L’algorithme de conversion UML vers OWL se découpe en deux étapes principales : le traitement des packages et le traitement des classes. Les boites rectangulaires des organigrammes suivants implémentent les règles de transformations décrites dans la partie précédente.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 29/53

Figure 38 : Algorithme UML2OWL :

Traitement des packages

Le traitement d’un package se fait de la manière suivante : 1. Import de la nouvelle ontologie dans

l’ontologie courante 2. Création du fichier contenant la nouvelle

ontologie 3. Pour tous les packages fils : application de

l’algorithme « Traiter package » 4. Pour toutes les associations : déclaration

des object properties 5. Pour toutes les classes : application de

l’algorithme « Traiter classe »

Le traitement des packages se fait de manière récursive, ce sont donc les packages « feuilles » (ceux qui n’ont pas d’enfants de type package) qui sont traités en premiers, ensuite on dépile les appels.

Figure 39 : Algorithme UML2OWL :

Traitement des classes

A une classe UML on associe une classe OWL. Les classes UML sont traitées comme suit : 1. Pour tous ses attributs : déclaration de

datatype properties (elles sont ainsi déclarées dans l’ontologie)

2. Création de la classe OWL 3. Ecritures des restrictions liées aux

datatype properties (attributs de la classe UML)

4. Ecritures des restrictions liées aux object properties (associations de la classe UML)

5. Ecritures des restrictions subClassOf (liées aux héritages de la classe UML)

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 30/53

3.2.4 Algorithme de transformation OWL2UML

La partie conversion OWL vers UML reprend les mêmes correspondances d’objets qu’UML

vers OWL mais les mécanismes mis en jeu sont plus complexes. Une première difficulté provient du fait qu’OWL possède moins de variétés d’objets qu’UML. A un objet OWL a été associé plusieurs objets UML. Donc lors du passage d’OWL à UML il faut identifier quel est l’objet UML à créer. Par exemple les classes et énumérations UML sont toutes deux représentées par des classes OWL. Donc lorsqu’on traite une classe OWL il faut se poser la question : est-ce une classe UML ou une énumération ? Une autre difficulté vient du fait que les properties sont déclarées dans les ontologies et ensuite utilisées dans les classes OWL. Donc pour reconstruire les associations il faut rassembler les informations présentes dans les déclarations et dans les restrictions. De plus on traite généralement plusieurs ontologies c’est-à-dire plusieurs fichiers, donc ces informations se trouvent parfois dans des fichiers différents. Les algorithmes de conversion OWL vers UML font donc apparaitre plus de tests, plus de recherches et d’accès à des fichiers. Cela rend naturellement la conversion d’une ontologie en modèle UML conceptuellement plus complexe et plus lente à l’exécution. Deux traitements sont remarquables : le traitement d’une ontologie et le traitement d’une classe.

Figure 40 : Algorithme OWL2UML :

Traitement des ontologies

Traiter une ontologie c’est : 1. construire le package UML correspondant 2. traiter les ontologies importées 3. traiter ses classes

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 31/53

Enfin on traite les classes avec l’algorithme suivant.

Figure 41 : Algorithme OWL2UML :

Traitement des classes

Le traitement d’une classe OWL suit la logique suivante : 1. Création de la classe UML correspondante 2. Pour toutes les restrictions de type

datatype property : créer un attribut 3. pour toutes les restrictions du type

subClassOf : créer une généralisation 4. pour toutes les restrictions du type object

property : créer une association

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 32/53

3.3 Application Java

3.3.1 Cas d’utilisation

Le développement de l’application Java a été guidé par la démarche UML. La première phase

de l’analyse UML est l’identification des cas d’utilisations. Ils permettent de décrire le besoin fonctionnel des utilisateurs du système et ainsi d’identifier les fonctionnalités principales de l’application.

L'application Model-Ontology Stylesheet Transformation (MOST) met en place l’architecture

du workflow et fournit une interface graphique pour la conversion de modèles UML en ontologies OWL. Les principaux cas d’utilisation de MOST sont donnés dans la figure ci-dessous :

Figure 42 : Cas d'utilisation de MOST

MOST propose deux types de transformations : UML vers OWL et OWL vers UML. Pour chacune de ces transformations l’utilisateur doit spécifier un fichier à transformer (XMI ou OWL) et choisir un fichier de transformation (XSLT). L'application dispose de la possibilité de configurer les transformations qu'elle propose aux utilisateurs. On distingue deux types d'utilisateurs de l'application MOST :

l'utilisateur standard qui peut uniquement transformer des fichiers

l'utilisateur spécialiste, qui hérite de l'utilisateur standard, peut configurer les transformations mises à disposition par l'application

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 33/53

3.3.1.1 Appliquer une transformation

Les cas d’utilisations du mode de transformation UML2OWL sont détaillés dans la figure ci-

dessous :

Figure 43 : Cas d'utilisation : Mode de transformation UML2OWL

Le mode de transformation UML vers OWL permet de transformer un modèle UML en ontologie. Pour cela l’utilisateur doit dans un premier temps choisir le fichier XMI qu’il souhaite transformer. Une fois ce modèle choisi, l’application affiche les versions d’UML, d’XMI et l’AGL utilisés pour créer ce fichier. En fonction de ces informations elle détermine aussi quelles sont les meilleures transformations à appliquer au fichier et les présélectionne. Une fois le fichier renseigné, l’utilisateur a la possibilité de vérifier sa validité par rapport à une DTD ou un XSD. Cette opération n’est pas obligatoire. L’utilisateur choisi ensuite les prétraitements de conformité et de formatage à appliquer au fichier avant transformation. L’application de prétraitement de conformité n’est pas obligatoire. Enfin l’utilisateur choisi le fichier de transformation UML vers OWL parmi ceux proposés et lance la transformation. Le mode de transformation OWL2UML ne propose que la sélection du fichier d’entrée et le choix de la transformation.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 34/53

3.3.1.2 Configuration des paramètres

Figure 44 : Cas d'utilisation : Gestion de la configuration

L’application MOST est configurable grâce à un fichier ini. Le chargement et la sauvegarde de ce fichier se font automatiquement au lancement et à l’arrêt de l’application. Configurer l’application signifie choisir les transformations qu’elle propose. En cours d’utilisation les acteurs peuvent ajouter, modifier ou supprimer des transformations. A chaque modification le fichier de configuration est sauvegardé.

Le but de la configurabilité de cette application est d’absorber au maximum les nombreuses

évolutions du contexte de l’application, à savoir : version UML, version XMI et AGL. Ces opérations n’affectent que les fichiers XSLT et ne nécessitent pas de modifier le code de l’application et de la recompiler.

3.3.2 Classes candidates et diagrammes de classes

A partir des cas d’utilisation on peut identifier les classes candidates, se sont les classes au

sens de la programmation objet qui constitueront l’architecture du système. Les principales classes identifiées sont décrites si dessous :

Le gestionnaire de fichier XMI : son

rôle est d’obtenir les informations sur le fichier XMI et de vérifier sa validité conformément à un schéma de validation.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 35/53

Le gestionnaire de transformation : c’est lui qui possèdera la responsabilité des

transformations à appliquer au fichier d’entrée.

Le fichier de configuration : un fichier de configuration est un fichier possédant des sections

qui contiennent des paramètres (clé=valeur). La structure de donnée choisie pour modéliser un fichier de configuration est une table de hachage contenant des tables de hachage donnant accès à des valeurs.

Figure 45 : Fichier de configuration

Figure 46 : Structure de donnée du fichier de

configuration

Le gestionnaire de configuration : il a la charge d’interagir avec le fichier de configuration.

C'est-à-dire le lire, le sauvegarder et mettre à disposition ses informations. L’interface graphique : l’application se présentera sous la forme d’un « wizard ».Cela

permettra à l’utilisateur de suivre le processus de transformation de manière intuitive. Ce wizard sera modélisé à la manière d’un diaporama, c’est-à-dire une JFrame qui sert de conteneur à des JPanel qui défilent par actions sur des boutons Suivant et Précédent.

Une classe principale MOST qui possède tous les composants principaux, c’est-à-dire les

gestionnaires et l’interface graphique. C’est le point d’entrée de l’application, il est modélisé grâce au Design Pattern singleton.

L’identification des classes candidates et l’édition des diagrammes de classe permettent de

créer le squelette de l’application et d’y placer ses principaux organes.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 36/53

Figure 47 : Diagramme de classe de MOST

3.3.3 Diagrammes de collaboration et de séquence

Les diagrammes de collaboration donnent une vue spatiale des échanges de messages entre

les classes du modèle. Ils répondent à la question : Qui communique et quels sont les messages ?

Figure 48 : Diagramme de collaboration : Modifier la configuration

Les diagrammes de séquence donnent une vue temporelle des échanges de messages entre

les classes du modèle. Ils répondent à la question : Quel est l’ordre des échanges de messages ?

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 37/53

Figure 49 : Diagramme de séquence : Modifier la configuration

Les diagrammes de collaboration et de séquence permettent de décrire, pour chaque fonctionnalité de l’application, les enchainements de messages échangés entre les classes. On a alors mis en place les communications entre les différents organes de notre application. L’architecture de l’application est désormais complètement décrite et prête pour l’implémentation.

3.4 Choix des technologies

3.4.1 Transformation de fichiers XML

Pour réaliser les transformations UML vers OWL et OWL vers UML une technologie est proposée par le cahier des charges : XSLT. Cette technologie est très bien adaptée à ce problème car elle permet de transformer des fichiers XML en fichier XML, XMI et OWL étant basés sur la syntaxe XML, avec uniquement les données présentes dans le XML d’origine et le fichier de transformation. C’est la version 2.0 de XLST qui a été choisie pour réaliser ces transformations, la version 1.0 ne permettant pas de produire plusieurs fichiers de sorties. Pouvoir produire plusieurs fichiers en sortie est une nécessité puisqu’à un package est associée une ontologie, or un fichier OWL ne peut contenir qu’une seule ontologie.

3.4.2 Le processeur XSLT

Les contraintes associées au choix du processeur XSLT sont les suivantes : il doit pouvoir être

utilisé depuis une application Java et doit être libre. Les bibliothèques qui répondent à ces critères sont Saxon, Xalan et AltovaXML.

Xalan ne supporte pas XSLT 2.0 dans sa version Java, elle a donc été écartée de la liste des

possibilités.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 38/53

Bien que les deux restantes soient libres d’utilisation, compatible XSLT 2.0 et disponibles en librairie pour .Net et pour Java c’est Saxon qui a été choisie comme processeur XSLT plutôt qu’AltovaXML.

Le choix ne s’est pas fait sur les performances de ces librairies mais sur leurs supports. En

plus d’être la plus répandue et la plus ancienne Saxon bénéficie d’une Javadoc très complète [SAXON]. Si cela ne suffit pas le développeur peut entrer directement en contact avec le concepteur et développeur de Saxon, qui se trouve aussi être l’auteur de la recommandation W3C sur XSLT 2.0.

3.4.3 L’environnement de développement intégré

Le choix de l’environnement de développement s’est fait entre Eclipse et Netbeans. Ils offrent tout deux de nombreuses fonctionnalités pour développer des applications Java mais c’est Netbeans qui a été choisi en raison de la nature de l’application à écrire.

En effet l’application MOST sera développée sous forme d’un wizard, donc beaucoup de composants d’interfaces graphiques seront nécessaires. Netbeans possède un éditeur d’interfaces graphiques ce qui rend leur réalisation moins fastidieuse que sous Eclipse.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 39/53

4 Réalisations

Dans cette partie sont présentés les principales réalisations et les résultats concrets.

4.1 Réalisation des transformations

4.1.1 Prétraitements

Rappelons que les deux phases de prétraitements (conformité et formatage) ont pour but de

limiter au maximum les éventuelles pertes de données dues aux non-conformités des XMI écrits par les AGL. Du point de vue technique ces deux phases de formatage sont bâties sur le même modèle. Il s’agit de recopier intégralement le fichier en entrée en y ajoutant les éléments nécessaires aux traitements ultérieurs (éléments conformes, noms et identifiants). On distingue dans les transformations deux types de template rules : - La template rule dite générique, elle s’applique récursivement à tous les éléments et attributs.

Figure 50 : Template rule générique

- La template rule dite spécialisée, elle s’applique à un élément donné.

Figure 51 : Template rule spécialisée

A l’exécution le processeur recherche la template rule la plus adaptée à un nœud. C’est de

cette manière que la template rule spécialisée remplace l’appel de la template rule générique. Ainsi lors de la recopie de cet élément on va pouvoir lui appliquer un traitement adapté.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 40/53

4.1.2 Transformation UML2OWL

Les template rules ont été écrites conformément aux algorithmes présentés dans la partie 3.

A titre d’exemple la template rule associée au traitement des packages est donnée ci-dessous.

Figure 52 : Template rules pour le traitement des packages

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 41/53

Dans la suite de cette partie nous allons présenter les transformations UML vers OWL au travers d’un exemple basé sur un modèle UML de test. Dans cet exemple ce n’est pas la pertinence de la modélisation qui est recherchée mais sa simplicité et sa capacité à couvrir les principaux cas de figures. Le modèle « Ecole » est décrit par les diagrammes de classes suivants :

Figure 53 : Diagramme de classe Ecole

Afin de visualiser les résultats de ces transformations nous allons utiliser l’éditeur

d’ontologies Protégé 4 [PROTEG]. Il offre une vue de la hiérarchie des classes (vue graphique avec le plug-in Graph Viz), des object properties et des datatype properties.

Modèles et packages Chaque modèle ou package est transformé en une ontologie stockée dans un fichier OWL.

Les liens entre ces ontologies sont matérialisés par le mot clé owl:imports. Dans cet exemple nous disposons d’un modèle : Ecole, et de trois packages Ecole Ingenieur,

Acteur et Infrastructure. L’édition de l’ontologie Ecole fait apparaitre les imports suivants :

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 42/53

Figure 54 : Ontologies du modèle Ecole

On remarque deux types d’imports : - les imports directs : ontologies directement importées - les imports indirects : ontologies importées par des ontologies importées (directement

ou indirectement)

Classes et généralisations Conformément aux algorithmes définis plus haut une classe OWL est associée à chaque

classe UML. Et les relations de généralisation-spécialisation sont décrites par le mot clé rdfs:subClassOf.

La hiérarchie des classes se présente alors sous la forme suivante :

Figure 55 : Classe OWL du modèle Ecole (Graph Viz)

Attributs

Figure 56 : Datatype properties du modèle Ecole

Figure 57 : Restriction liée aux attributs

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 43/53

On peut ici remarquer le fait qu’OWL distingue bien deux datatype properties ayant le même nom, celle associée à Personne et celle associée à Ecole Ingenieur. Des restrictions sont ensuite associées aux classes OWL, par exemple pour la matière enseignée par un enseignant comme le montre les figures ci-dessus.

Associations Pour chaque association on déclare deux object properties inverses nommées par les classes

qu’elles lient.

Figure 58 : Object properties du modèle Ecole

Des restrictions sont ensuite ajoutées aux classes avec les cardinalités correspondant aux

associations. Par exemple :

Figure 59 : Restrictions liées aux associations

Plusieurs remarques peuvent être faites ici : - Le nombre de restrictions varie effectivement en fonction de la cardinalité minimum (si

0 alors pas de some) - Pour l’auto-association Personne-Personne les deux propriétés inverses apparaissent (is

et has).

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 44/53

Enumérations Les énumérations sont associées au design pattern value partition. Les principaux points de

ce design pattern sont détaillés ici : La hiérarchie des classes :

Figure 60 : Classes de la Value Partition

Les classes disjointes :

Figure 61 : Classe OWL disjointes

L’axiome de couverture :

Figure 62 : Axiome de couverture

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 45/53

4.1.3 Transformation OWL2UML

La reconstruction du modèle UML pour UML 1.3 XMI 1.1 à partir de l’ontologie Ecole a été

importée dans StarUML. Le résultat est le suivant :

Figure 63 : Modèle Ecole reconstruit

Il est normal que l’énumération Nom_Ecole_Ingenieur n’apparaisse pas dans ce modèle car au moment de la rédaction de ce rapport elles ne sont pas encore traitées par OWL2UML. Cependant une erreur apparait, c’est la transformation des agrégations en association entre les classes Ecole_Ingenieur et Materiel et Ecole_Ingenieur et Personne. Ce problème est dû aux non-conformités de StarUML. En effet la DTD associé à UML 1.3 XMI 1.1 prévoit pour les marqueurs des agrégations la valeur shared, or StarUML utilise la valeur aggregate.

Figure 64 : DTD UML 1.3 XMI 1.1

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 46/53

Figure 65 : Agrégation 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 réaliser les tests des transformations une base de test a été constituée. Elle contient des modèles UML simples et des modèles réels (modèles UML de projets Cemagref).

4.1.4.1 Tests unitaires et tests d’intégration

Deux types de modèles ont été utilisés pour réaliser les tests : les modèles simples et les

modèles d’intégrations. Ils sont respectivement utilisés pour les tests unitaires et les tests d’intégrations. Les modèles pour les tests d’intégrations sont enrichis à chaque nouvel objet UML qui est traité.

A l’issue de chaque application d’une transformation à un modèle la sortie est étudiée scrupuleusement. Le but est de vérifier que ce qui était traité à l’étape précédente l’est toujours identiquement et que les nouveaux traitements sont opérationnels.

Les résultats de ces tests sont représentés dans un tableau comme suit :

UML to OWL

UML 1.3 UML 1.4 UML 2.1

XMI 1.0 XMI 1.1 XMI 1.1 XMI 1.2 XMI 2.1

Modèle

Package

Classe

Attribut

Généralisation

Association

+ Type

+ Multiplicités 1 seule

Commentaires

Enumération

Figure 66 : Tableau de validation des transformations

Une fois les résultats jugés satisfaisants le passage à l’itération suivante est autorisé.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 47/53

4.1.4.2 Tests de robustesse

Les modèles UML réels étant plus complexes et plus volumineux ils ont été utilisés pour des tests de robustesse. Il s’agit ici de vérifier le fonctionnement des transformations en conditions réelles. Le tableau suivant décrit quantitativement les modèles utilisés pour ces tests.

lignes packages classes attributs généralisations associations

GIEA 31203 43 263 496 235 165

SIE Pesticides

+Activités métrologiques 944 5 29 58 20 10

+Gestion exploitation 674 2 21 37 4 11

+Pratiques agricoles 945 2 23 48 14 7

SIGEMO 10800 1 90 363 5 172

SYNAPSE 4420 4 40 60 14 61

Figure 67 : Détails des modèles réels

Ces modèles ont aussi servi à valider les transformations auprès des clients. Ces derniers

connaissant bien leurs modèles, ils ont été à même de vérifier la validité des données en sorties des transformations. Un premier jalon a été passé le 13 Juillet et a abouti à la validation des transformations dans l’état où elles se trouvaient à cette date.

4.2 Réalisation de l’application MOST

4.2.1 Maquette et exemples de principes

Nous allons présenter ici la première phase du cycle de développement en V : l’analyse et la faisabilité. Cette étape a permis de présenter divers prototypes montrant la possibilité de réaliser les fonctionnalités critiques de MOST, identifiées par les cas d’utilisations.

4.2.1.1 Interface graphique

Le premier prototype est celui de l’interface graphique de MOST. Sa première version sous forme d’interface ‘’statique’’ à trois onglets n’a pas été validée. La raison est que le processus de transformation n’était pas intuitif à appréhender avec une telle interface.

La seconde version s’est naturellement orientée vers un ‘’wizard’’ c’est-à-dire une application graphique pas-à-pas. L’enchainement des étapes se présente sous la forme suivante :

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 48/53

Figure 68 : Enchainement des écrans de MOST

C’est ce prototype qui a été retenu pour l’implémentation.

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 réponse est oui puisque c’est le but même 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 à l’utilisateur (dans un panneau de texte par exemple).

Définition de la librairie Saxon comme fabrique de transformations :

Ajout d’un gestionnaire d’erreur à cette fabrique :

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 49/53

Transformation XSLT d’un fichier XML :

4.2.1.3 Gestion de la configuration

Troisième étape : rendre l’application configurable par utilisation d’un fichier ini. C’est une

technique largement utilisée dans le domaine du développement logiciel et il existe des classes l’implémentant dans divers langages objets. Bien que des codes existent déjà j’ai tout de même créé mes propres classes de gestion de fichier de configuration. Le principe reste toujours le même : 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 dernière fonctionnalité de MOST à vérifier est la validation de fichiers XML par DTD et par XSD. Ces techniques sont conceptuellement similaires mais diffèrent quelque peu d’un point de vue technologique. Pour la validation par DTD il faut en premier ajouter un doctype, c’est une référence au fichier contenant la DTD que doit respecter le fichier XML. Ensuite on utilise un parser qui lit le fichier XML et détecte les erreurs de conformité. Pour la validation par XSD pas de doctype mais un parser différent pour lequel on spécifie un fichier XSD. De la même manière le parser lit le fichier et remonte les erreurs de conformité dans un panneau de texte dédié.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 50/53

4.2.2 Génération de l’architecture du code

Conformément au cycle de développement en V, à l’issue de l’étape d’analyse et de l’étude de faisabilité c’est la phase de conception de l’architecture qui débute.

La modélisation UML de l’application MOST a été réalisée sous StarUML. C’est un atelier de génie logiciel libre et complet. Il propose bien entendu tous les outils liés à la démarche de modélisation UML et la possibilité de générer du code dans plusieurs langages dont Java. Ainsi l’architecture du code, c’est-à-dire les packages et classes identifiées lors de la modélisation, a été générée depuis StarUML. La modélisation ayant été poussée assez loin il ne reste qu’à implémenter le contenu des méthodes des classes.

4.2.3 Implémentation des modules

Avant de commencer l’implémentation du modèle, c’est-à-dire la réalisation des diverses

itérations, nous disposons d’une architecture pouvant accueillir le code et de prototypes contenant le principe des fonctionnalités. Afin de construire une application Java la première chose à faire et de définir un nouveau projet dans l’IDE Netbeans et d’y intégrer les classes générées par StarUML. Enfin pour chaque itération les phases de capture des besoins fonctionnels et techniques ont préalablement été réalisées respectivement lors de la description des cas d’utilisation et de la création des prototypes. Donc l’implémentation des classes peut commencer. La succession des itérations a été la suivante :

1. interface graphique 2. gestion de la configuration 3. transformation XSLT 4. validation des fichiers XMI

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 51/53

5 Résultats et prolongements

Cette ultime partie dresse un bilan du travail réalisé et donne les perspectives d’avenir des réalisations.

5.1 Etats des lieux

5.1.1 Ce qui a été réalisé

L’étude réalisée lors de ce stage a permis d’identifier les compatibilités entre versions

UML/XMI et de conclure sur l’état de l’interopérabilité entre les ateliers de génie logiciel. Cette étude a mis en évidence les problèmes liés à l’interopérabilité ce qui a été une première étape dans la réalisation d’un processus permettant de les résoudre. En effet la solution adoptée pour réaliser le workflow permet de traiter les problèmes de conformité identifiés et ensuite de transformer les modèles.

Lors de la rédaction de ce rapport les transformations UML vers OWL et OWL vers UML ont été implémentées pour la plupart des objets UML figurant dans le cahier des charges. Un accent a été mis sur la production d’une solution durable et adaptable aux évolutions futures au travers de la configurabilité de l’application MOST et de la structure même du workflow (organisation des feuilles de styles). Cela garanti que des développements majeurs ne seront pas à prévoir dans l’immédiat et que de petites modifications sont facilement intégrables à l’existant.

5.1.2 Ce qu’il reste à faire

Afin d’affiner l’étude il conviendrait de recueillir plus d’informations sur l’AGL Mega et d’étudier la conformité de ses sorties. Cette étude pourrait être élargie à de nombreux autres AGL (tels que Visual Paradigm, Rational Rose, …). La part du travail qui reste à ma charge avant la fin de ce stage est la réalisation des transformations OWL2UML des énumérations et les transformations des associations n-aires.

5.1.3 Améliorations possibles et prolongement

Les améliorations qui sont envisageables sur ce travail portent sur la correspondance entre

les objets UML et OWL. Par exemples les datatype properties telles qu’elles sont construites dans ces outils peuvent pointer sur des classes, c’est le cas lorsque le type d’un attribut est une classe. Or en OWL une datatype property ne peut pointer que sur un type de donnée. Il faudrait, dans l’absolu, tester le type des attributs et créer une object property dans certains cas.

Les transformations associées aux associations n-aires et aux classes d’associations conservent le sens de la modélisation mais ne permettent pas de recréer ces objets. On pourrait donc se pencher sur le problème de trouver des objets OWL qui permettraient de reconstruire des associations n-aire et des classes d’associations lors du traitement par OWL2UML.

Un point intéressant a été mis en évidence lors de la génération des ontologies

correspondant aux modèles UML, c’est l’apparition de « problèmes » dans les modèles. Ces problèmes ne peuvent pas être considérés comme des erreurs de modélisations. Par exemple

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 52/53

l’apparition de doublons dans les datatype properties signifie que deux classes ont un même attribut. Il serait peut-être judicieux de faire hériter deux classes ayant un même attribut d’une classe mère a qui on l’affecterait. Ainsi les ontologies donnent une autre vue des modèles qui pourraient permettre de réfléchir sur la modélisation et éventuellement de la retravailler.

5.2 Bilan

Le travail déjà réalisé contribue efficacement à l’interopérabilité des données entre ateliers de génie logiciel. Ainsi il accompagnera les changements d’AGL utilisés par le Cemagref dans un premier temps, puis par d’autres par la suite (ces outils de transformations ont pour projet d’être libres d’utilisation). Ils seront potentiellement intégrés dans le travail d’un autre stagiaire dont le but est la création d’un outil collaboratif de production de connaissance afin d’ajouter des données provenant d’UML, ces connaissances étant stockées sous forme d’ontologies.

Sur un plan plus personnel ce stage m’a permis d’acquérir de nouvelles compétences techniques grâce à la maitrise des langages XML et XSLT, et d’approfondir mes connaissances en UML et en programmation Java. Le travail sur les ontologies m’a aussi ouvert à une nouvelle approche des modèles : par la sémantique et la logique.

J’ai aussi progressé dans ma méthode de travail et dans l’organisation des tâches à accomplir ainsi que dans l’anticipation de celles à venir. Enfin ce stage m’a permis de découvrir les activités du Cemagref, plus particulièrement en Auvergne, et le monde de la recherche.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année 53/53

Conclusion

Malgré un standard dédié, XMI, l’étude réalisée au cours de ce stage montre que l’interopérabilité des données entre les ateliers de génie logiciel n’est pas complètement opérationnelle. C’est la conséquence des évolutions indépendantes des normes UML et XMI et du non respect de ses normes par les éditeurs de logiciels.

L’objectif de ce stage est atteint car des outils de transformation basés sur XSLT ont été développés pour produire les sorties OWL et XMI correspondant à un modèle UML. Ces outils, validés par des tests sur des modèles réels, sont intégrés dans une application Java, appelée Model-Ontology Stylesheet Transformation, entièrement configurable.

Il est plus que probable que ces travaux nécessitent d’être prolongés afin de prendre en charge les versions d’UML et d’XMI à venir. En conséquence je laisse à disposition des futurs développeurs une structure de travail propice à la reprise de ces outils. En effet, tout d’abord l’application MOST permet d’intégrer de nouvelles transformations sans avoir à redévelopper. Ensuite la base de tests existante permettra au développeur de valider ses travaux. Enfin les documents de spécification de l’étude menée constitueront une aide pour se familiariser avec les outils et leur contexte.

Ainsi, bien que de nouveaux développements paraissent inévitables, les outils réalisés au cours de ce stage améliorent déjà cette interopérabilité. Au Cemagref ils seront utiles pour la conservation des données lors de la migration vers de nouveau AGL. Par la suite ces outils seront distribués librement et pourront être utiles à d’autres organismes. Pour moi ce stage a été l’occasion de mettre en pratique et d’approfondir mes connaissances en UML et programmation Java. Il m’a permis de maitriser de nouvelles technologies et de me familiariser avec le monde de la recherche au travers des activités du Cemagref.

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

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 basés 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 : Généralisation sous PowerAMC .......................................................................................... 12 Figure 13 : Généralisation sous StarUML .............................................................................................. 12 Figure 14 : Généralisation 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 : Réseau des AGL ................................................................................................................... 14 Figure 18 : Planning prévisionnel .......................................................................................................... 16 Figure 19 : Planning réel ........................................................................................................................ 17 Figure 20 : Cycle de développement en V ............................................................................................. 18 Figure 21 : Déroulement d'une itération............................................................................................... 19 Figure 22 : Cycle de développement en Y ............................................................................................. 19 Figure 23 : Organisation du workflow ................................................................................................... 21 Figure 24 : Contexte de l'application MOST .......................................................................................... 22 Figure 25 : Algorithme de prétraitement .............................................................................................. 22 Figure 26 : Nécessité d’un prétraitement 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 généralisations .................................................................................... 25 Figure 32 : Transformation des associations ......................................................................................... 26 Figure 33 : Transformation des énumérations ...................................................................................... 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 donnée du fichier de configuration ................................................................ 35 Figure 47 : Diagramme de classe de MOST ........................................................................................... 36

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

Figure 48 : Diagramme de collaboration : Modifier la configuration .................................................... 36 Figure 49 : Diagramme de séquence : Modifier la configuration .......................................................... 37 Figure 50 : Template rule générique ..................................................................................................... 39 Figure 51 : Template rule spécialisée .................................................................................................... 39 Figure 52 : Template rules pour le traitement des packages ................................................................ 40 Figure 53 : Diagramme de classe Ecole ................................................................................................. 41 Figure 54 : Ontologies du modèle Ecole ............................................................................................... 42 Figure 55 : Classe OWL du modèle Ecole (Graph Viz) ........................................................................... 42 Figure 56 : Datatype properties du modèle Ecole ................................................................................. 42 Figure 57 : Restriction liée aux attributs ............................................................................................... 42 Figure 58 : Object properties du modèle Ecole ..................................................................................... 43 Figure 59 : Restrictions liées 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 : Modèle Ecole reconstruit .................................................................................................... 45 Figure 64 : DTD UML 1.3 XMI 1.1 .......................................................................................................... 45 Figure 65 : Agrégation StarUML non conforme .................................................................................... 46 Figure 66 : Tableau de validation des transformations ......................................................................... 46 Figure 67 : Détails des modèles réels .................................................................................................... 47 Figure 68 : Enchainement des écrans de MOST .................................................................................... 48

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

Marc ZIMMERMANN Rapport de stage de 3ème

année

Références 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 [JAVAZZ] Java pour les ZZ Cours ISIMA 3, filière Calcul et Modélisation Scientifiques Loïc YON [MODL] Méthodes et Outils de Développement Logiciel.

Cours tronc commun ISIMA 2 Christine FORCE

[OMGMMS] Catalog of OMG Modeling and Metadata Specifications

http://www.omg.org/technology/documents/modeling_spec_catalog.htm [PROTEG] A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools

Edition 1.2 Matthew Horridge The University Of Manchester March 13, 2009

[SAXON] Saxon9 Javadoc

http://www.saxonica.com/documentation/javadoc/index.html [UMLFr] UML en Français

http://uml.free.fr/ [W3COWL] OWL Web Ontology Language

http://www.w3.org/TR/2004/REC-owl-features-20040210/ W3C Recommendation

[W3CXML] Extensible Markup Language (XML)

http://www.w3.org/XML/ [W3CXSL] XSL Transformations (XSLT) Version 2.0

http://www.w3.org/TR/xslt20/ W3C Recommendation

[XSLPra] XSL Concepts and Practical Use

http://nwalsh.com/docs/tutorials/xsl/xsl/frames.html Paul Grosso, Norman Walsh