Vous êtes sur la page 1sur 67
I nstitut S upérieur d’ I nformatique de M odélisation et de leurs A pplications

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

de s données Organisme d’accueil : Cemagref Présenté par : Marc ZIMMERMANN Tuteurs entreprise :

Présenté par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Tuteur ISIMA : Jonas KOKO

Durée : 4 mois Mai à Septembre 2010

I nstitut S upérieur d’ I nformatique de M odélisation et de leurs A pplications

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

des données Organisme d’accueil : Cemagref Présenté par : Marc ZIMMERMANN Tuteurs entreprise :

Présenté par : Marc ZIMMERMANN Tuteurs entreprise : Jean-Pierre CHANET et Catherine ROUSSEY Tuteur ISIMA : Jonas KOKO

Durée : 4 mois Mai à Septembre 2010

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

Remerciements

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

Je remercie Jean-Claude CHAMPOMIER, Vincent SOULIGNAC, Gil de SOUSA et André MIRALLES pour m’avoir donné accès à leurs travaux et pour le temps qu’ils m’ont accordé. Les modèles UML qu’ils m’ont fournis ont été d’une grande aide pour mes réalisations.

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

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

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 dXMI ont appauvri l’interopérabilité des modèles.

L’objectif du travail décrit dans ce document est d’étudier les compatibilités entre XMI et de fournir des outils afin d’améliorer l’interopérabilité entre AGL.

C’est la technologie eXtensible Stylesheet Language Transformation (XSLT) qui a été utilisée pour réaliser les outils. Les transformations des modèles s’effectuent au moyen d’une conversion dans un langage intermédiaire : Web Ontologie Language (OWL). Ainsi les outils permettent de créer l’ontologie associée au modèle et toutes les versions XMI existantes. Ces transformations sont intégrées dans une application Java, nommée Model-Ontology Stylesheet Tranformation (MOST), totalement configurable afin de pouvoir s’adapter aux évolutions à venir d’UML et d’XMI.

Mots clés : atelier de génie logiciel, interopérabilité, Java, modèle, ontologie, OWL, UML, workflow, XMI, XML, XSLT.

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

Abstract

My training period for the third year at the ISIMA was conducted at the Cemagref where I was in charge of realizing an XML workflow for data interoperability.

Developers use methods guided by the models to design and create software. These methods are known as Model Driven Architecture (MDA). The preferred language to describe the MDA is the Unified Modeling Language (UML). So, many computer-aided software engineering (CASE) tools help developers to describe these models using UML, and a standard exists for their serialization: XML Metadata Interchange (XMI). But many independent evolutions of UML and XMI have reduced the interoperability of models.

This report presents the compatibility study between XMI versions and describes the design process of the software developed to improve interoperability between CASE softwares. This tool is named Model-Ontology Stylesheet Transformation (MOST).

This tool was based on eXtensible Stylesheet Language Transformation technology (XSLT). The transformations of models are made using a conversion into an intermediate language: Web Ontology Language (OWL). Thus, the application creates the ontologies associated to the model and all existing versions of XMI. These transformations are embedded in a fully configurable Java application in order to adapt to future evolutions of UML and XMI.

Keywords : computer-aided software engineering, interoperability, Java, model, ontology, OWL, UML, workflow, XMI, XML, XSLT.

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

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

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

 

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 Index des illustrations Références bibliographiques

53

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

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 dun domaine, ainsi que les relations entre ces concepts.

OMG : Object Management Group. Association américaine créée en 1989 destinée à promouvoir et standardiser le modèle objet.

OWL : Web Ontology Language. Langage permettant de décrire des ontologies Web. Il est basé sur trois sous-langages possédant des pouvoirs d'expressions croissants : OWL-Lite, OWL-DL et OWL-Full.

RDF : Resource Description Framework. RDF est un langage général pour la représentation d’informations Web. Il fait partie des recommandations du W3C et est sérialisé en XML.

RDF Schema : RDFS est une extension de la sémantique de RDF. Il permet de décrire des ressources et les liens entre elles. RDFS est notamment utilisé pour décrire des ontologies.

Sérialisation : mécanisme permettant de stocker des informations dans un fichier.

UML : Unified Modeling Language. Langage de modélisation dans le domaine du développement logiciel. Spécification de l'OMG.

W3C : World Wide Web Consortium. Organisme à but non lucratif destiné à promouvoir la compatibilité des technologies Web.

Workflow : Enchainement de tâches à réaliser pour atteindre un objectif.

XMI : XML Metadata Interchange. Standard d'échange d'informations de métadonnées UML basé sur XML. Permet l'échange de données entres AGL. Standard de sérialisation d'UML.

XML : eXtensible Markup Language. Langage informatique permettant de stocker de manière arborescente des données de type texte grâce à des balises (reconnaissables par des chevrons <>).

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

XML Schema : Un XML Schema permet de décrire la structure d'un fichier XML (éléments, attributs, types de données,…). C'est un document XML, alternative à la DTD. XSD inclus une déclaration de types de données.

XPath : XML Path Language. Langage de requêtes pour sélectionner des nœuds dans un fichier XML. Il permet de naviguer dans l'arborescence d'un fichier XML.

XSD : XML Schema Definition. Equivalent à XML Schema.

XSLT : eXtensible Stylesheet Language Transformations. Langage permettant la transformation d’un fichier XML vers un autre document (XML, HTML, texte).

Marc ZIMMERMANN

Rapport de stage de 3 ème année

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

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

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 lorganisme daccueil

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.

français qu’avec des universités étrangères. Figure 1 : Les centres du Cemagref Le Cemagref en quelques

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

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 LUR « Technologies et systèmes dinformation 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

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.

d’un document XML sont décrits dans la figure ci-contre. Figure 2 : Syntaxe d'un fichier XML

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

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.

peut être sérialisé dans un fichier XML, HTML ou texte. Les processeurs XSLT acceptent cependant plusieurs

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.

pour le traitement des nœuds enfants du nœud courant. Figure 4 : Exemple de template rule

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.

Elle permet de continuer le parcours récursif de l’arbre. Figure 5 : Template rule native Le

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

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+.

spécifications d e l’Object Managment Group *OMGMMS+ . Figure 6 : Architecture MOF Un modèle est

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 :

lOpen 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 quelle est fausse.

lUnique 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

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 :

peuvent être schématisées de la manière suivante : Figure 7 : Exemple OWL Deux types de

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

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 :

d’XML. On peut les représenter de la façon suivante : Figure 8 : Les langages basés

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

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

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)

 

Version courante

 

correspondante(s)

 

ArgoUML

XMI 1.0

 

UML 1.3

ArgoUML 0.28

 

ArgoUML 0.30.1

 

XMI 1.1

UML 1.4

 

(06/05/2010)

XMI 1.2

XMI 1.2

UML 1.4

BOUML

 

XMI 1.2

UML 1.4

BOUML 4.21

 

BOUML 4.21

XMI 2.1

XMI 2.1

UML 2.x

 

(12/05/2010)

Enterprise

XMI 1.0

XMI 1.0

UML 1.3

Enterprise

Architect

7

et

Enterprise

Architect

8

Architect

XMI 1.1

XMI 1.1

UML 1.3

ultérieures

build 856

XMI 1.2

XMI 1.2

UML 1.4

(05/05/2010)

XMI 2.1

XMI 2.1

UML 2.x

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

 

UML 1.3

Poseidon 6.0 et ultérieures

Poseidon 8.0

XMI 1.1

UML 1.3

XMI 1.2

XMI 1.2

UML 1.4

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

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

(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.

de décrire les objets varie en fonction de l'AGL. Figure 12 : Généralisation sous PowerAMC Figure

Figure 12 : Généralisation sous PowerAMC

de l'AGL. Figure 12 : Généralisation sous PowerAMC Figure 13 : Généralisation sous StarUML Il m'a

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 :

conforme d’une généralisation est la suivante : Figure 14 : Généralisation UML 1.3 XMI 1.1 conforme

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

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

UML 1.3 XMI 1.0 XMI 1.1 UML / AGL Modèle Package Classe Attribut Généralisation Association
UML 1.3
XMI 1.0
XMI 1.1
UML / AGL
Modèle
Package
Classe
Attribut
Généralisation
Association
Commentaire
Enumération
(*)
(*)
(*)
Classe d'association
Association n-aire
Figure 15 : Conformité des AGL pour UML 1.3
UML 1.4
UML 2.1
XMI 1.2
XMI 2.1
UML / AGL
Modèle
Package
Classe
Attribut
Généralisation
Association
Commentaire
Enumération
(*)
(*)
Classe d'association
Association n-aire
ArgoUML
ArgoUML
BOUML
BOUML
Enterprise Architect
Enterprise Architect
Mega
Mega
Modelio
Modelio
Objecteering
Objecteering
PowerAMC
PowerAMC
StarUML
StarUML
ArgoUML
ArgoUML
BOUML
BOUML
Enterprise Architect
Enterprise Architect
Mega
Mega
Modelio
Modelio
Objecteering
Objecteering
PowerAMC
PowerAMC
StarUML
StarUML

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

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

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 linteropérabilité on peut représenter chaque version de XMI comme un medium de communication et ainsi obtenir le réseau suivant :

de communication et ainsi obtenir le réseau suivant : Figure 17 : Réseau des AGL Pour

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

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

Workflow XML pour l’interopérabilité des données Figure 18 : Planning prévisionnel Marc ZIMMERMANN Rapport de

Figure 18 : Planning prévisionnel

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

Workflow XML pour l’interopérabilité des données Figure 19 : Planning réel Marc ZIMMERMANN Rapport de stage

Figure 19 : Planning réel

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

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.

associe à chaque phase du développement une phase de test. Figure 20 : Cycle de développement

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

Workflow XML pour l’interopérabilité des données Figure 21 : Déroulement d'une itération Chaque itération a

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

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

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

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

Figure 22 : Cycle de développement en Y

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

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

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

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

du workflow est décrite dans la figure ci-dessous. Figure 23 : Organisation du workflow Concrètement nous

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

Workflow XML pour l’interopérabilité des données Figure 24 : Contexte de l'application MOST L’application

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 :

prétraitement est décrit par l’organigramme suivant : Figure 25 : Algorithme de prétraitement Marc ZIMMERMANN

Figure 25 : Algorithme de prétraitement

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

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

Workflow XML pour l’interopérabilité des données Figure 27 : Objets UML Figure 28 : Objets OWL

Figure 27 : Objets UML

l’interopérabilité des données Figure 27 : Objets UML Figure 28 : Objets OWL Les agrégations représentent

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

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 :

et datatype property se fera donc de la façon suivante : Figure 30 : Transformation des

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).

la relation de subsomption (intitulée subclassOf en RDFS). Figure 31 : Transformation des généralisations 

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

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 :

association- object property se fera comme suit : Figure 32 : Transformation des associations 

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

Workflow XML pour l’interopérabilité des données Figure 33 : Transformation des énumérations 1. Créer une classe

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.

d’une classe d’association est représenté ci -dessous. Figure 34 : Classe d'association Pour « traduire »

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 :

UML équivalent à celui de la classe d’association : Figure 35 : Equivalent classe d'association Marc

Figure 35 : Equivalent classe d'association

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

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.

recouvrent et les traduire en object properties . F i g u r e 3 6

Figure 36 : Association n-aire

Commentaire

s s o c i a t i o n n - a i r e

Figure 37 : Equivalent association n-aire

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

Workflow XML pour l’interopérabilité des données Figure 38 : Algorithme UML2OWL : Traitement des packages Figure

Figure 38 : Algorithme UML2OWL :

Traitement des packages

Figure 38 : Algorithme UML2OWL : Traitement des packages Figure 39 : Algorithme UML2OWL : Traitement

Figure 39 : Algorithme UML2OWL :

Traitement des classes

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.

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

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.

d’une ontologie et le traitement d’ une classe. Figure 40 : Algorithme OWL2UML : Traitement des

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

Enfin on traite les classes avec l’algorithme suivant.

Enfin on traite les classes avec l’algorithme suivant. Figure 41 : Algorithme OWL2UML : Traitement des

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

3.3 Application Java

3.3.1 Cas dutilisation

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 didentifier 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 :

de MOST sont donnés dans la figure ci-dessous : Figure 42 : Cas d'utilisation de MOST

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

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 :

UML2OWL sont détaillés dans la figure ci- dessous : Figure 43 : Cas d'utilisation : Mode

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

3.3.1.2 Configuration des paramètres

des données 3.3.1.2 Configuration des paramètres Figure 44 : Cas d'utilisation : Gestion de la

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.

sa validité conformément à un schéma de validation. Marc ZIMMERMANN Rapport de stage de 3 è

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

Le

gestionnaire

de

transformation :

c’est

lui

qui

possèdera

transformations à appliquer au fichier d’entrée.

la

responsabilité

des

à appliquer au fichier d’entrée. la responsabilité des Le fichier de configuration : un fichier de

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.

des tables de hachage donnant accès à des valeurs. F i g u r e 4

Figure 45 : Fichier de configuration

h i e r d e c o n f i g u r a t

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

Workflow XML pour l’interopérabilité des données Figure 47 : Diagramme de classe de MOST 3.3.3 Diagrammes

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 ?

à la question : Qui communique et quels sont les messages ? Figure 48 : Diagramme

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

Workflow XML pour l’interopérabilité des données Figure 49 : Diagramme de séquence : Modifier la configuration

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

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

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.

récursivement à tous les éléments et attributs . Figure 50 : Template rule générique - La

Figure 50 : Template rule générique

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

spécialisée, elle s’applique à un élément donné. Figure 51 : Template rule spécialisée A l’exécution le

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

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.

associée au traitement des packages est donnée ci-dessous. Figure 52 : Template rules pour le traitement

Figure 52 : Template rules pour le traitement des packages

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

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 :

» est décrit par les diagrammes de classes suivants : Figure 53 : Diagramme de classe

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

Workflow XML pour l’interopérabilité des données Figure 54 : Ontologies du modèle Ecole On remarque deux

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 :

des classes se présente alors sous la forme suivante : Figure 55 : Classe OWL du

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

Attributs

55 : Classe OWL du modèle Ecole (Graph Viz) Attributs Figure 56 : Datatype properties du

Figure 56 : Datatype properties du modèle Ecole

Attributs Figure 56 : Datatype properties du modèle Ecole F i g u r e 5

Figure 57 : Restriction liée aux attributs

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

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.

inverses nommées par les classes qu’elles lient. Figure 58 : Object properties du modèle Ecole Des

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 :

cardinalités correspondant aux associations. Par exemple : Figure 59 : Restrictions liées aux associations Plusieurs

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

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 :

pattern sont détaillés ici : La hiérarchie des classes : Figure 60 : Classes de la

Figure 60 : Classes de la Value Partition

Les classes disjointes :

60 : Classes de la Value Partition Les classes disjointes : Figure 61 : Classe OWL

Figure 61 : Classe OWL disjointes

L’axiome de couverture :

61 : Classe OWL disjointes L’axiome de couverture : Figure 62 : Axiome de couverture Marc

Figure 62 : Axiome de couverture

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

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 :

été importée dans StarUML. Le résultat est le suivant : Figure 63 : Modèle Ecole reconstruit

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.

valeur shared , or StarUML utilise la valeur aggregate . Figure 64 : DTD UML 1.3

Figure 64 : DTD UML 1.3 XMI 1.1

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

Workflow XML pour l’interopérabilité des données Figure 65 : Agrégation StarUML non conforme La solution est

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 1.3

UML 1.4

UML 2.1

UML to OWL

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

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 linterface 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

Workflow XML pour l’interopérabilité des données Figure 68 : Enchainement des écrans de MOST C’est ce

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 :

de la librairie Saxon comme fabrique de transformations : Ajout d’un gestionnaire d’erreur à cette fabrique

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

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

Workflow XML pour l’interopérabilité des données Transformation XSLT d’un fichier XML : 4.2.1.3 Gestion de la

Transformation XSLT d’un fichier XML :

des données Transformation XSLT d’un fichier XML : 4.2.1.3 Gestion de la configuration Troisième étape :

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

4.2.2 Génération de larchitecture 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

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 quil 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

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

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

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