Liens avec la synchronisation documentaire

Dans le cadre de nos travaux, la documentation se limite à l’ensemble des documents tech-

niques. Il s’agit d’une documentation permettant de justifier des choix de conception. Elle ac-

compagne le modèle d’ouvrage et évolue ainsi en même temps que lui. Nous définissons alors un document comme le résultat d’une transformation de modèles, enrichie d’une mise en pages et d’annotations. De plus, le résultat de la transformation se limite ici aux structures d’arbres. Nous excluons ainsi les hypertextes qui peuvent être associés, via les hyperliens, à des structures

FIGURE4.16 :Extraits des modèles d’ouvrages fournis par le SETRA. En haut, il s’agit du pont sur la Truyère à Garabit (Cantal (15), sur l’A75). En bas, à gauche, la section du tablier du pont de l’Iroise (Finistère (29)), à droite, une partie du tablier du pont de Genevilliers sur la Seine (Hauts-de-Seine (92)).

de graphes. En outre, un document technique contient les informations relatives à un seul corps de métier, il s’agit seulement d’une vue du modèle, résultat d’une extraction d’informations.

La synchronisation documentaire consiste alors à mettre à jour le document en y insérant une structure d’arbres modifiée par une nouvelle étape de conception, sans altérer si possible la mise en pages éventuellement effectuée par le concepteur ainsi que les annotations qu’il a ajoutées. La productivité est ainsi augmentée, car le concepteur ne doit pas recommencer sa mise en page et l’ajout de ses annotations.

Par exemple, un nouveau matériau fait son apparition dans le modèle d’ouvrages, et le do- cument technique liste dans un tableau l’ensemble des matériaux utilisés. De plus, le concepteur a commenté un choix technique se situant à un autre endroit du document. Sans synchronisa- tion, il doit ajouter des nouvelles lignes au tableau de matériaux, au risque d’en oublier, ou de faire une erreur. Il peut aussi utiliser un outil qui génère sa documentation technique à partir du modèle d’ouvrage (conformément à la définition faite précédemment), mais il doit remettre dans ce cas ses commentaires dans le nouveau document généré. En effet, nous constatons que les commentaires et justifications sont rarement intégrés au modèle d’ouvrage, mais font l’objet d’une entrée manuelle dans un document. Si le document est regénéré, ces informations sont perdues.

4.4. Intégrations au sein de systèmes de gestion de la MNC 135

La synchronisation documentaire s’adapte ainsi aux pratiques professionnelles (entrées ma- nuelles d’informations dans le document et non dans le modèle d’ouvrage), tout en proposant une amélioration de la productivité.

Le travail consiste alors à définir une chaîne de traitement permettant de :

1. Transformer un modèle d’ouvrage en une structure d’arbre contenant l’information à pla- cer dans le document.

2. Enrichir la structure d’arbre d’une mise en page par défaut pour obtenir un document. 3. Synchroniser au besoin ce document avec la version antérieure déjà annotée, commentée,

et mise en page.

La comparaison sémantique joue alors un rôle lors de la synchronisation des documents. Comme pour le démonstrateur du projet SAKURA (cf. section 4.4.1), les résultats de la compa- raison sont réutilisés au moment de la synchronisation. Cette dernière va cependant plus loin que le démonstrateur SAKURA : il ne s’agit pas ici de superposer deux modèles en annotant les changements. Il s’agit d’extraire du nouveau document tous les changements du modèle de don- nées, et de les insérer dans l’ancien, sans altérer l’information autour de cette insertion. Dans cette optique nous avons choisi pour ce travail des structures simples d’arbres. Synchroniser des structures plus complexes dépasse le cadre de cette thèse.

L’hypothèse principale rendant possible la synchronisation documentaire est la suivante : l’information générée par le modèle d’ouvrage est séparée de la mise en forme du document. Il s’agit d’un principe fondamental en gestion de contenu (cf. préface de [Goossens99]). C’est pourquoi nous avons souhaité décomposer la génération du document en deux étapes : extrac- tion de l’information sous forme d’arbre structuré, et création d’un document mis en pages en utilisant un formalisme permettant de séparer le fond de la forme, même au sein du document final.

Pour implémenter ce système, nous avons choisi des technologies avec un souci de réuti- lisabilité. Ainsi, la structure d’arbres est encapsulée dans un fichier XML, et la transformation de la structure en un document mis en pages utilise la technologie XSLT [Clark99], permet- tant de transformer une structure XML en une autre. Enfin, nous avons choisi de développer la synchronisation documentaire sur le logiciel Microsoft Word c_{, et son format XML WordML} [Aitken03]. Ce dernier supporte en effet le principe de séparation, grâce à une distinction entre les balises de l’information pure et les balises de mise en page. De plus, la solution Microsoft Office c _{reste globalement très utilisée dans tous les secteurs industriels. La figure 4.17 illustre} la chaîne globale de traitement. Elle suppose l’emploi d’une application de visualisation/édition de modèle d’ouvrage, qui exploite la comparaison sémantique et la génération d’un fichier XML de la structure en arbre. Dans nos travaux, nous avons choisi la plateforme EVE 2 munie des modules IFC-Bridge et de comparaison sémantique (cf. section 4.4.1).

La synchronisation documentaire se décompose selon deux phases. La première correspond à la génération du document à partir du modèle d’ouvrage. Elle suit trois étapes :

MNC 1.0 Instance originale MNC 1.1 Instance modifiée XML Résultats de comparaison Rapport XML (instance originale) Rapport XML (instance modifiée) Doc WordML (instance originale) Doc WordML (instance modifiée) MS Word 2003 Comparaison sémantique Application de

visualisation/édition XSLT _{VBA ou C#}Plug-in

Document technique synchronisé

WordML

Concepteur

Parcours de l'instance originale Parcours de l'instance modifiée

FIGURE4.17 :Diagramme global de la synchronisation documentaire.

1. Création de la structure XML à partir du modèle d’ouvrage. Dans le cadre de nos travaux, nous n’avons pas développé de mécanisme générique permettant d’extraire l’information d’un modèle STEP pour créer une structure XML. Nous avons néanmoins implémenté des fonctions d’extraction et d’export XML, grâce à la bibliothèque Xerces [Dubchak03], pour une vue spécifique d’un modèle de données particulier.

2. Transformation du fichier XML en un document WordML. Grâce à une feuille XSLT, qui suit aussi le formalisme XML, un fichier XML est transformable en un autre fichier XML. Le but est ici de fournir une mise en pages par défaut, correspondant à la charte graphique d’une société, ou d’un projet.

3. Modification du document par le concepteur. Ce dernier annote, commente, et ajuste la mise en page. L’annotation et les commentaires sont effectués dans des zones prévues à cet effet. L’ajustement de la mise en pages consiste à n’effectuer que des changements locaux (modification du style d’une phrase, centrer un paragraphe, etc.).

La deuxième phase intervient lorsque le modèle d’ouvrage a été modifié. Les étapes suivantes s’enchaînent :

1. Comparaison sémantique des deux modèles d’ouvrage. Un résultat de comparaison est généré au format XML.

2. Génération d’un nouveau document WordML, suivant les étapes 1. et 2. de la première phase.

3. Synchronisation du document original avec le nouveau. Grâce à une macro VBA ou un plug-in C#, le document original, enrichi de ses annotations, est synchronisé, grâce au

4.5. Conclusion 137

nouveau document WordML et au rapport XML de comparaison. Les éléments éventuelle- ment ajoutés dans le nouveau document possèdent la mise en page par défaut.

Microsoft Word c _{permet d’utiliser le mécanisme des révisions : les modifications ne sont pas} appliquées directement, mais suggérées en marge du document, et sont donc soumises à l’accord du concepteur. L’utilisation de ce logiciel (et du format WordML) n’est cependant pas obligatoire. En effet, l’architecture que nous avons choisie autorise l’adaptation à d’autres traitements de texte. Il suffit pour cela de recréer la feuille de transformation XSLT — une connaissance de ce langage est cependant nécessaire — tâche à affecter au constructeur d’application.

4.5

Conclusion

Ce chapitre a permis d’abord de démontrer la possibilité d’implémenter les méthodes de com- paraison structurelle et sémantique de la MNC. La solution proposée semble un bon compromis entre performance (approche Early-Binding) et facilité d’implémentation (génération automa- tique de la biliothèque C++). Le recours à un constructeur d’application demeure néanmoins nécessaire afin de créer le système adapté à un projet, à une équipe de projet, ou encore à un corps de métier particulier, selon l’utilisation du comparateur.

Ensuite, plusieurs exemples ont détaillé des cas d’utilisation du comparateur sémantique. Ainsi, la productivité est-elle potentiellement améliorable grâce à ces outils, tout en respectant les pratiques profesionnelles de la construction.

Par rapport au processus-type défini au premier chapitre (figure 1.26), nous avons donc proposé une méthodologie concernant le suivi des modifications (à travers la comparaison sé- mantique) et la synchronisation documentaire. La fusion des modèles n’a pas été abordée. Cette question mériterait en effet une analyse qui dépasse la cadre de nos travaux. Néanmoins, il convient au moins d’étudier les perspectives de cette méthodologie de comparaison sémantique, par rapport à la fusion des modèles d’ouvrage, point essentiel pour réaliser la synchronisation de la MNC.

Résumé

Ce chapitre englobe l’ensemble des implémentations informatiques de nos travaux, à travers trois axes : le système de comparaison structurelle, l’analyse sémantiques, et l’intégration au sein d’applica- tions existantes. Notre choix s’est porté sur le C++ car son adoption est très large dans tous les domaines industriels et reste très bien placé en termes de performance. Cependant, nos travaux pourraient très bien s’implémenter dans n’importe avec langage orienté objet. Dans tous les cas, l’implémentation de la comparaison structurelle nécessite une bibliothèque pour gérer les modèles de données EXPRESS, en particulier les IFC et IFC-BRIDGE. Il existe deux types d’implémentations : early-binding et late-binding. La première correspond à des bibliothèques compilées pour un modèle de données particulier pour des performances optimisées, alors que le deuxième est adaptable à n’importe quel modèle de données, au détriment des performances. Nous avons choisi la première approche, via l’utilisation du projet Open- Source Expressik, écrit en Java. A partir de la spécification EXPRESS d’un modèle de données (comme IFC ou IFC-BRIDGE), le programme génère une bibliothèque C++ capable de charger, modifier et sauver n’importe quel modèle d’ouvrage, instance du modèle de données précédent. Nous avons alors choisi une approche similaire pour la comparaison structurelle : à partir du modèle de données EXPRESS, il s’agit de générer le code source d’une application C++ capable de comparer deux modèles d’ouvrages. Un tel programme a besoin de paramètres supplémentaires : la structure statique (squelette) du code C++ en sortie et l’ensemble des informations structurelles spécifiques au modèle de données (racine de parcours, entités identifiables). Pour le premier, deux variantes ont été envisagées : les fichiers sque- lettes (template) munis de tags ou l’utilisation d’un paquetage Java capable de générer n’importe quel code C++. Concernant le deuxième paramètre, ces informations sont encapsulées dans un fichier XML nommé assistant structurel. Pour le modèle IFC-BRIDGE, il indique ainsi que l’entité racine est l’instance

de■❢❝Pr♦❥❡❝t et que les entités sont identifiables si et seulement si elles instancient ■❢❝❘♦♦t. De plus,

le code C++ généré utilise la bibliothèque créée par Expressik et son architecture utilise massivement le modèle de conception Visiteur [Gamma94]. Les résultats de comparaison sont quant à eux encapsulés dans un autre fichier XML. Concernant l’analyse sémantique, nous avons choisi d’étendre les capacités de l’assistant structurel par de nouveaux tags, créant ainsi un assistant d’extraction d’information et un assistant d’équivalents sémantiques. Nous remarquons que l’utilisation de techniques de hachage, per- mettant d’accélérer les performances du comparateur, nécessite une adaptation lorsque des équivalents sémantiques sont définis. La dernière partie de ce chapitre est consacrée à l’intégration de nos travaux au sein de systèmes de gestion de la MNC. Ces intégrations sont d’ordre visuels : utilisation de la plateforme EVE 2, visualisation sur AutoCAD dans le cadre du partenariat SAKURA. Elles peuvent aussi concerner l’interopérabilité avec des logiciels de CAO ou de calculs de ponts. Enfin, pour la synchronisation docu- mentaire, essentielle au niveau du processus-type défini au premier chapitre, un framework est proposé pour réutiliser les résultats de comparaison au sein d’un traitement de texte supportant le mécanisme de révisions, comme MS Word 2003.

4.5. Conclusion 139

Abstract

This chapter encapsulates all implementations of our work through three main axes : structural com- parison system, semantic analysis, integration into existing software. We choose C++ language because of its large adoption by every industrial field and its good performance. However our work could be im- plemented using any object-oriented language. Anyway implementation of structural comparison needs a library to handle EXPRESS data models, especially IFC and IFC-BRIDGE. Two kinds of implementations coexist : early-binding and late-binding. The first one relates to compiled libraries for a specific data mo- del with optimized performance, whereas the second one is a generic solution for every data model to the expense of less performance. We choose the first approach by using the Open Source Java project :

Expressik. From EXPRESS specifications of a data model (for example IFC and IFC-BRIDGE), this tool

generates a C++ library able to load, edit, and save any product model, which instantiates this data model. Therefore we choose a similar approach for structural comparison : from an EXPRESS data mo- del, the goal is to generate the source code of a C++ tool able to compare two product models. Such a program needs complementary parameters : static structure (template) of output C++ code and all specific information from the data model (root entity, identifiable entities). Concerning the first item two options can be implemented : template files with tags or the use of a Java package able to generate any C++ code. Concerning the second parameter this information is encapsulated into a XML file called

structural helper. Applied on IFC-BRIDGE model, it indicates the root entity is the instance of■❢❝Pr♦❥❡❝t

and identifiable entities inherit from■❢❝❘♦♦t. Furthermore generated C++ code uses a library created

by Expressik and its architecture is based on Visitor design pattern [Gamma94]. Comparison results are then encapsulated into another XML file. Concerning semantic analysis we choose to extend the struc- tural helper with new tags, in order to create an extraction helper and an equivalence helper. We notice that using hashing mechanisms increases system’s performance but needs to be adapted when the system exploits semantic equivalences. Last part from this chapter is dedicated to integration of our work within systems of DMUC handling. These integrations could be visual : use of EVE 2 platform, AutoCAD plug-in for the SAKURA partnership. They could also refer to interoperability with CAD software and engineer software. Last documents’ synchronizing is essential for the DMUC framework (defined at the first chap- ter). Another framework is proposed to reuse comparison results within word processing software, if it supports revision functionalities, like MS Word 2003.

Chapitre 5

Évaluation et perspectives de la

comparaison sémantique

5.1

Introduction

Après avoir mené un premier examen de nos travaux par rapport à sa faisabilité et sa ca- pacité à s’adapter au sein d’environnements logiciels existants, ce chapitre a pour objectif de montrer les limites actuelles de nos travaux, dans certaines phases du cycle de vie d’un ouvrage et quelles seraient les perspectives et les pistes d’analyse, permettant de trouver des solutions pour contourner ces limites.

Pour cela, il convient d’aborder une problématique concernant la synchronisation de MNC, à savoir la fusion des modèles d’ouvrages en préparation à une réunion de synthèse/co-conception (section 5.2). Afin de de répondre aux problèmes posés, une analyse des relations entre la MNC, les méthodes de comparaison sémantiques et les activités de conception est mené (section 5.3). Enfin l’objectif consiste à étudier la portée de nos travaux au-delà de la conception d’un projet, c’est-à-dire lors de l’éxécution des travaux et la maintenance de l’ouvrage (section 5.4).