Maîtrise des transformations XML dans une chaîne de publication

HAL Id: dumas-01873339

https://dumas.ccsd.cnrs.fr/dumas-01873339

Submitted on 13 Sep 2018

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

publication

Renaud Marchand

To cite this version:

Renaud Marchand. Maîtrise des transformations XML dans une chaîne de publication. Traitement du texte et du document. 2016. �dumas-01873339�

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

CENTRE REGIONAL ASSOCIE DE TOULOUSE

_______

MEMOIRE

Présenté en vue d'obtenir

Le DIPLOME d'INGENIEUR CNAM

en

INFORMATIQUE

OPTION : Systèmes d’Information (ISI) Par

Renaud MARCHAND

Soutenu le 3 juin 2016

JURY

PRESIDENT : Monsieur Yann POLLET, professeur des Universités (CNAM Paris).

MEMBRES : Monsieur Thierry MILLAN, maître de conférences (Toulouse-III-Paul-Sabatier)

et responsable de la filière informatique (CNAM Midi-Pyrénées). Monsieur Pascal DAYRE, ingénieur de Recherche (CNRS Toulouse).

Monsieur Julien GUIRAUD, chef de projet (STUDEC). Madame Marie RIGAIL, chef de projet (STUDEC).

Maîtrise des Transformations XML dans une Chaîne de

Publication

Remerciements

Je tiens tout d’abord à remercier le «Conservatoire National des Arts et Métiers» de Midi Pyrénées pour l'enseignement suivi et plus particulièrement Monsieur Pascal Dayre pour ces précieux conseils pour la rédaction de ce mémoire. Son soutien, sa clairvoyance et ses compétences m'ont été d'une aide inestimable.

Un grand merci à Monsieur Philippe Thiels, Directeur Général Adjoint de Studec, qui m’a toujours apporté son soutien dans ce projet professionnel. Julien Guiraud et Marie Rigail pour leurs nombreux conseils et aides, ainsi que pour l’intérêt qu’ils ont porté à ce projet.

Qu'ils puissent trouver dans ce travail le témoignage de ma sincère gratitude et de mon respect. Je tiens également à remercier mes collègues des agences STU21 et STU22 pour leurs encouragements tout au long de cette formation. Je pense en particulier à Serge, Hervé, Isabelle, Sophie, Romain, …

Je tiens à remercier aussi sincèrement les membres du jury qui me font le grand honneur d'évaluer ce travail.

Enfin, je remercie ma conjointe, ainsi que l’ensemble de ma famille pour leur soutien sans faille tout au long de ces années au CNAM.

Liste des Abre viations

AFNOR Association française de normalisation

ASD AeroSpace and Defence Industries Association of Europe

ATA Air Transport Association of America

A-TDD Acceptance Test Driven Development (TDD)

B

BDD Behavior Driven Development

Développement Piloté par le Comportement

BPMN Business Process Modeling and Notation

Modèle de processus métier et de notation

C

CIM Computer Independent Model

Modèle indépendant de l’informatique

COTS Commercial off-the-shelf

Produits Commerciaux Prêts à Utiliser

CSDB Common Source Data Base

Base de données des sources communes

CSS Cascading Stylesheets

Feuilles de Style en Cascade

D

DGAC Direction Générale de l'Aviation Civile

DITA Darwin Information Typing Architecture

Architecture Darwinienne d'information typée

DM Data Module

D

DSL Domain Specific Language

Langage Dédié

E

EASA European Aviation Safety Agency

Agence européenne de la sécurité aérienne (appelée aussi AESA)

EMOF Essential MOF

F

FAA Federal Aviation Administration

Administration Fédérale de l’Aviation (aux E.U)

FO Formatting Objects

Langage des objets de formatage

FOP Formatting Objects Processor

Processeur de formatage des objets

G

GED Gestion Electronique de Documents

I

IDE Integrated Development Environment

Environnement Intégré de Développement

IDM Ingénierie Dirigée par les Modèles

IETP Interactive Electronic Technical Publication

J

JDK Java Development Kit

Le Kit de Développement Java

JVM Java Virtual Machine

Machine Virtuelle Java

M

MDA Model Driven Architecture

Architecture Dirigée par les Modèles

MOF Meta-Object Facility

O

OACI International Civil Aviation Organization (appelé aussi ICAO)

Organisation de l'Aviation Civile Internationale

OASIS Advancing Open Standards for the Information Society

Standard Avancé et Ouvert pour la Société d’Information

OMG Object Management Group

P

PAQ Plan d’assurance Qualité

PDF Portable Document Format

PM Publication Module

Module de publication

PDM Platform Deployment Model

Modèle de Déploiement Spécifique à une Plateforme

PIM Platform Independent Model

Modèle Indépendant de la Plateforme

PSM Platform Specific Model

S

SGBD Système de Gestion de Base de Données

SGML Standard Generalized Markup Language

Langage de Balisage Généralisé Normalisé

T

TDD Test Driven Development

Développement Piloté par les Tests

TMX Translation Memory eXchange

Echange de Mémoire de Traduction

U

UML Unified Modeling Language

Langage de Modélisation Unifié

X

XML eXtensible Markup Language

Langage de Balisage eXtensible

XSL / XSLT Extensible Stylesheet Language (Transformation) Language de description des feuilles de style

Glossaire

Sens 1 : Airline Transport Association

Groupe composé d’industriels et d’exploitants du secteur de l’aéronautique. Ce groupe a pour objectif de façonner et d’orienter les efforts de l'industrie afin d’améliorer la sécurité, la sureté ainsi que la vitalité (économique) de l’aéronautique. L’ATA traite d’un large éventail de discipline (technique ou non) et vise à traiter de nombreux problèmes dans divers domaines (carburants, aéroports, ingénierie et maintenance, environnement, formation,…).

Cf. http://airlines.org

Sens 2 : Norme documentaire

Ensemble de normes, orientées vers les documentations aéronautiques, dont les objectifs sont de minimiser les efforts, les coûts (pour les exploitants et les industriels) en améliorant la qualité et la rapidité du partage de l’information entre les différents acteurs.

APPLICABILITE

Une applicabilité est une indication spécifiant qu’une section d’une documentation technique est spécifique à un équipement (série, version, ….) ou soumise à certaines conditions (météo, localisation, utilisation d’un outil en maintenance, …).

Lors de la publication, des filtrages sont généralement effectués sur ces applicabilités.

EFFET DE BORD

Un effet de bord est la modification d’un état du système autre que celui de son résultat direct. Le langage XSL est sans effet de bord, c’est-à-dire qu’une règle de transformation ne peut pas modifier l’attribution d’une variable de la feuille de style.

FEUILLE DE STYLES

Une feuille de style est un ensemble de règles de transformation définissant la mise en forme d’un document. Il existe différents type de feuilles de style (FOSI, CSS, XSL, …). Une feuille de style n’effectue pas forcement uniquement des opérations de mise en page, elle peut aussi effectuer des traitements (filtrage, conversion de donnée, …).

LISTE DEDUITE

On appelle liste déduite toute les sections d’une documentation qui ne sont pas explicitement rédigées par les rédacteurs. Ces listes sont donc calculées lors de la publication. On retrouve dans ces listes : les tables des références, les sommaires, la liste des figures, la liste alphanumérique des pièces de rechange, …

METTRE A PLAT UN SCHEMA

Mettre à plat un schéma XSD consiste à définir localement chaque élément et attribut du schéma. L’utilisation des éléments typés, excepté par les types primitifs du W3C XML Schéma (xs:string, xs:integer, …), sont interdits. La mise en plat d’un schéma ne modifie pas sa définition mais alourdit fortement sa maintenance.

Cf. http://xmlfr.org/documentations/tutoriels/001218-0001 MODELE

Un modèle est une représentation conceptuelle d’une idée ou d’un objet réel. Les propriétés du modèle, sans influence dans l’étude du concept pour lequel le modèle est créé, sont généralement écartées du modèle ; on dit que le modèle fait abstraction de ces propriétés.

Un modèle est généralement conforme à des règles de modélisation qui définissent sa compréhension.

MODULE DE DONNEES (appelé aussi unité documentaire)

Un module de données (ou unité documentaire) est une unité documentaire indépendante décrivant généralement un type d’opération pour une sous-partie d’un équipement. Un module de données comprend une identification unique, et peut être de différents types (description, procédure, catalogue de pièce, …).

TUNNEL XML (appelé aussi pipeline XML ou chaîne de transformation XML)

Un tunnel XML (appelé aussi pipeline XML ou chaîne de transformation XML) est l’assemblage de différentes opérations (validation XSD, transformation XSL, requête XQuery, …) permettant de créer le processus de transformation d’une donnée.

PROCESSEUR XSLT

Un processeur XSLT est un moteur qui produit à partir d’un ou plusieurs documents XML en entrée, un ou plusieurs documents en sortie aux formats désirés. Cette transformation s’effectue conformément aux règles de transformation spécifiées dans une XSL.

Quelques processeurs XSLT :

Saxon (http://saxon.sourceforge.net), Xalan (https://xml.apache.org/xalan-j/), …

PROCESSEUR DE FORMATAGE DES OBJETS

Un processeur de formatage des objets est un moteur qui produit à partir d’une instance conforme à XSL-FO un document PDF.

Processeurs de formatage des objets:

Apache FOP (https://xmlgraphics.apache.org/fop/), Altsoft Xml2PDF (

https://www.alt-soft.com) …

PROGRAMMATION FONCTIONNELLE1

La programmation fonctionnelle est un paradigme de programmation qui considère le calcul en tant qu'évaluation des fonctions mathématiques.

Comme le changement d'état et la mutation des données ne peuvent pas être représentés par des évaluations de fonctions, la programmation fonctionnelle ne les admet pas. Au contraire elle met en avant l'application des fonctions, contrairement au modèle de programmation impérative qui met en avant les changements d'état.

PUBLICATION

Sens 1 : Processus

Processus permettant de créer une publication à partir des données documentaires.

Sens 2 : Produit livrable

Une publication est le produit livrable des fonctions documentaires et « porte » les documentations. Il existe principalement deux types de publication :

 publication volume orientée pour l’impression papier des manuels. Cette

publication se présente généralement sous la forme d’un ou plusieurs fichiers PDF.

 publication électronique orientée pour la diffusion des manuels sur des

équipements informatiques (intranet, tablette, système embarqué, …). Cette publication se présente généralement sous la forme d’une application Web.

REGLE DE TRANSFORMATION

Une règle de transformation est une série d’instruction permettant de spécifier la transformation d’une donnée. Dans le langage XSLT, il existe deux types de règle de transformation :

 Les règles nommées (xsl:template name) sont des règles explicitement nommées,

et qui sont appelées à l’aide d’une instruction (xsl:call-template)

 Les règles déclenchées (xsl:template match) sont des règles qui sont exécutées

lorsque la condition XPath de la règle est respectée (des règles de priorité peuvent être aussi spécifiées). L’appel à une règle déclenchée s’effectue à l’aide de l’instruction (xsl:apply-templates select)

RESOLVER

Un revolver est un processus permettant de résoudre l’adresse logique d’une ressource informatique en une adresse physique

T

ABLE DES

M

ATIERES

REMERCIEMENTS ... 3

LISTE DES ABREVIATIONS... 5

GLOSSAIRE ... 9

TABLE DES MATIERES ...13

RESUME ...17 ABSTRACT ...17 INTRODUCTION ...18 LE CONTEXTE ... 18 LES ATTENTES DU PROJET ... 19 LE DEROULEMENT DU PROJET ... 19 L’ORGANISATION DU MEMOIRE ... 20 PRESENTATION DE STUDEC ...21 LES METIERS DE STUDEC ... 21

IMPLANTATION GEOGRAPHIQUE DU GROUPE ... 23

CERTIFICATION QUALITE ... 24

QUELQUES SOLUTIONS LOGICIELS DEVELOPPEES PAR STUDEC ... 24

MES FONCTIONS ... 25 PREAMBULE ...27 1. FONCTION DOCUMENTAIRE ... 27 1.1. ENJEUX DE LA DOCUMENTATION ... 29 1.2. LES NORMES DOCUMENTAIRES ... 30 1.3. 1.3.1. DocBook ... 30 1.3.2. DITA ... 31 1.3.3. Standard ATA ... 31 1.3.4. Standard S1000D ... 31 CHAINES DE PUBLICATION ... 33 1.4. LE DEVELOPPEMENT XSL ... 35 1.5. LA PROBLEMATIQUE DETAILLEE ...37 2. LES RESULTATS ATTENDUS ... 37 2.1. ETUDE DE L’EXISTANT ... 38 2.2. 2.2.1. La méthode de développement ... 38 La phase de spécification ...39 La phase de codage...39

La phase de recette ...40

2.2.2. Les défauts ... 40

LES CHOIX DES AXES D’AMELIORATION ... 42

2.3. La modularité ... 43

Le paramétrage ... 43

La documentation technique ... 43

Les extensions ... 43

LES BONNES PRATIQUES XSL ...45

3. MISE EN PLACE DE LA DOCUMENTATION LOGICIELLE ... 45

3.1. 3.1.1. Le dossier de spécification ... 45

3.1.2. La documentation technique ... 46

LES PRINCIPES DE CONCEPTION ... 48

3.2. 3.2.1. Développement par tunnel XML ... 48

3.2.1.1. Définition des tunnels XML ...48

3.2.1.2. XProc ...48

3.2.1.3. Cas d’étude ...50

3.2.2. Les pratiques de codage ... 52

3.2.2.1. Décorréler la structure et le style du document : la couche CSS ...52

3.2.2.2. Mutualisation du code ...53

3.2.2.3. Le paramétrage ...54

3.2.2.4. L’internationalisation ...54

3.2.2.5. Les traitements génériques ...55

LES METHODES DE TESTS ... 56

3.3. 3.3.1. Les tests unitaires ... 56

3.3.1.1. Les méthodologies TDD/BDD ...56

3.3.1.2. Les outils TDD ...58

3.3.1.3. La mise en œuvre ...58

3.3.2. Les inspections ... 60

3.3.2.1. Le contrôle des publications ...60

3.3.2.2. Les revues de code ...61

3.3.2.3. Règles de codage ...62

3.3.2.4. Analyse des performances ...63

ETRE SUPPORT A LA REDACTION ... 64

3.4. SYNTHESE ... 65

3.5. APPROCHE PAR LES MODELES ...67

4. INTRODUCTION A L’IDM ... 67

4.1. Une architecture de modélisation ... 68

Les transformations ... 69

Un cycle de développement ... 69

TRANSPOSITION AU XML ... 70

DEFINITION DES MODELES ... 71

4.3. 4.3.1. Principes généraux du DSL ... 72

4.3.2. Règles du modèle PIM ... 73

Règle 1 : Représentation des règles de transformation...73

Règle 2: La création d’un flux dans la sortie ...74

Règle 3: Les conditions ...74

4.3.3. Règles du modèle PSM ... 75

Règle 4 : Définition des règles de transformation ...75

Règle 5: Définition des appels aux règles de transformation ...76

Règle 6 : Définition des instructions de création dans le flux de sortie ...77

Règle 7 : Définition des instructions de boucle ...77

Règle 8 : Définition des instructions de condition ...78

CAS D’ETUDE ... 79

4.4. Préparation du schéma de la donnée ... 81

Initialisation du modèle PIM ... 82

L’habillage du modèle PIM ... 84

Création du modèle PSM ... 85

Génération du modèle de sortie ... 86

Génération de la feuille de style XSL ... 87

SYNTHESE ... 88

4.5. SYNTHESE ...91

ANNEXES ...93

ANNEXE I. MUTUALISATION DES INDEXES ... 94

ANNEXE II. XSPEC ... 96

ANNEXE III. CONTROLE SCHEMATRON ... 98

ANNEXE IV. DEFINITION DU DSL... 101

ANNEXE V. MODELE DE LA DONNEE D’ENTREE (A PLAT) ... 105

ANNEXE VI. MODELE PIM ... 106

ANNEXE VII. MODELE PSM ... 107

ANNEXE VIII. MODELE DE SORTIE GENERE ... 108

REFERENCES ET BIBLIOGRAPHIE ... 109

LISTE DES FIGURES ... 111

Re sume

La maintenance et la correction des anomalies d’un produit logiciel entraînent des coûts importants, ainsi que des retards de livraison. La diminution de ces anomalies est donc une préoccupation majeure dans les projets informatiques.

Dans le domaine de la documentation technique, le langage XML est très souvent utilisé pour la rédaction des données documentaires. Par conséquence, les transformations XSL sont essentielles à la publication de ces documentations techniques, et donc aux chaînes de publication.

Ce mémoire présente une analyse des anomalies usuelles rencontrées dans les feuilles de styles des chaînes de publication et étudie les méthodes et bonnes pratiques adaptées au développement XSL.

Mots clés : XML, XSL, feuilles de style, transformation, documentation technique, chaîne de

publication, IDM, modèle, test logiciel, qualité logicielle, tunnel XML, bonnes pratiques, conception

Abstract

The maintenance and correction of anomalies in a software product causes significant costs and delivery delays. Therefore this reduction of these anomalies is a major preoccupation in the IT projects.

In the field of the technical documentation, XML is used to write the documentary data. In consequence, the XSL transformations are essential to the publication of these technical documentations and to the publishing chains.

This paper presents an analysis of the usual anomalies in the stylesheets, included in the publication chains, and studies the methods and the best practices adapted to the XSL development.

Keywords: XML, XSL, stylesheet, transformation, technical documentation, publication chains,

Introduction

Le travail accompli pour rédiger ce mémoire représente l’aboutissement de ma formation au

Centre National d’Arts et Métiers de Toulouse ainsi que l’apprentissage acquis tout au long de ma

carrière professionnelle dans les métiers de l’informatique et de la documentation technique. Ce travail a pour but de montrer mes capacités et mes compétences pour exercer le métier d’Ingénieur en Informatique et participer ainsi au développement des activités et projets d’un groupe dans le domaine du développement d’un produit logiciel.

Le sujet choisi pour ce mémoire, La Maîtrise des Transformations XSL dans une Chaîne de

Publication, est lié à un intérêt professionnel dans le cadre de mes activités, mais aussi à l’attrait

personnel que je porte au développement XSL.

Le contexte

La documentation technique représente une part importante d’un produit, informatique ou autre. Les manuels de maintenance et d’exploitation sont essentiels, ils sont le principal support pour la maintenance et logistique d’un produit. Ils permettent de transférer des informations du concepteur à l’utilisateur, garantissant ainsi les conditions optimales d’utilisation du système. Le domaine de la documentation technique s’est rapidement intéressé au langage de balisage, historiquement avec le langage SGML. Ce type de langage permet de stocker facilement l’information documentaire et offre des mécanismes de transformation permettant sa diffusion. Le langage XSLT, permettant de transformer les langages à balisage, est donc devenu essentiel aux traitements de ces données dans les chaînes de publication.

Maîtrise : Sûreté de l'exécution dans un domaine technique

Ces dernières années, tout comme pour le reste des systèmes d’information, les chaînes de publication ont fortement évolué, et leur complexité s’est accrue. Le volume important des données documentaires ainsi que la complexité de ces données nécessitent de mettre en œuvre des méthodes permettant de garantir la maîtrise de ces publications documentaires.

Les attentes du projet

Les transformations XSL ont un rôle essentiel dans les chaînes de publication et font partie du cœur de métier de Studec. Elles sont alors d’autant plus un point critique de ces chaînes, en particulier car la qualité des publications produites dépend fortement de ces transformations XSL. Les attentes de ce projet sont donc doubles :

 D’un point de vue professionnel, ce projet doit permettre d’améliorer significativement la

qualité des feuilles de style XSL et ainsi participer à l’amélioration générale de nos chaînes de publication.

 D’un point de vue personnel, il doit me permettre d’approfondir mes connaissances des

transformations XSL et de mettre en œuvre des principes de l’IDM découverts lors de mon sujet probatoire (ENG221) [1].

Le déroulement du projet

Le projet, présenté dans ce document, représente un travail effectué d’une part lors de mes activités de développeur XSL à Studec et d’autre part lors de recherches personnelles.

Ce sujet comporte deux méthodes de résolution de la problématique de transformation, la deuxième étant traitée de façon plus expérimentale. Cependant, comme je le montrerai dans la synthèse, ces deux méthodes ne sont pas antagonistes mais plutôt complémentaires. Une étude préalable, basée sur l’analyse des défauts usuels de nos feuilles de style et sur le retour d’expérience de nos développements, permettra de détailler et affiner les problématiques de ce projet.

Lorsque cela a été possible, les méthodes étudiées ont été mise en œuvre lors de développement. Je me suis alors attaché à mesurer les résultats et à mettre en œuvre une amélioration continue de ces méthodes.

L’organisation du mémoire

Ce mémoire est organisé en quatre chapitres :

 Chapitre 1 : Préambule

Ce chapitre est une introduction au contexte métier de la documentation technique. Il permet de présenter les différentes notions (fonctions et normes documentaires, chaîne de publication, …) nécessaires à la bonne compréhension de ce mémoire.

 Chapitre 2 : La problématique

Ce chapitre présente les défauts usuels rencontrés dans les feuilles de style, ainsi que les observations faîtes sur mon retour d’expérience de nos développements. Cette analyse permet de détailler la problématique générale du projet ainsi que de présenter les axes d’amélioration.

 Chapitre 3 : Les Bonnes Pratiques XSL

Ce chapitre présente les travaux effectués dans la mise en œuvre des bonnes pratiques de développement XSL, ainsi que les résultats obtenus avec ces pratiques.

 Chapitre 4 : Approche par les Modèles

Ce chapitre présente les travaux effectués dans la mise en œuvre d’un développement XSL à l’aide d’une approche pilotée par les modèles. La création du langage dédié (DSL), développé dans le cadre de cette étude, est détaillée. Une étude de cas permet d’illustrer la mise œuvre d’une telle approche.

 Synthèse

La synthèse présente les résultats obtenus par la mise en œuvre de ces méthodes et évalue leur pertinence.

Pre sentation de Studec

Studec est l'une des principales sociétés françaises d'ingénierie documentaire, d'études et

réalisations de soutien logistique fortement présent dans les domaines de l’aéronautique, l’espace et la défense. Créée en 1956, Studec devient filiale à 100% d’ALTERUP SAS en 2008 et dirige le groupement européen IDEA.

http://www.studec.biz

Studec intervient dans les secteurs de pointe de l’industrie et du tertiaire:

 Aéronautique et spatial

 Naval

 Défense et industrie

 Administration

Les métiers de Studec

La diversité des métiers de Studec permet de proposer des prestations complètes répondant aux besoins des grands projets industriels.

L’ingénierie documentaire

Création de documents dont le contenu et la forme permettent aux utilisateurs d’installer, d’exploiter et de maintenir des matériels ou systèmes dans tous les domaines de l'industrie et de la défense.

La conduite du changement

Développement et mise en œuvre de nombreux modèles d’ingénierie de formation, en analysant les besoins et en définissant la meilleure pédagogie, dans une recherche d'efficacité et d’efficience (Elaboration de la stratégie d’accompagnement du changement).

La traduction

Traduction de document (technique, juridique, …) répondant aux besoins multilingues de nos clients, et cela à tous les stades de leurs activités.

Le développement de logiciels

Etude des problèmes spécifiques de production ou d'exploitation informatisée des documentations clients. Création d’interface entre des bases de données techniques et les bases documentaires de l'entreprise pour rendre l'information documentaire accessible sur les médias les plus modernes.

Les études logistiques

Définition de tâches de management et des tâches d'analyses techniques et économiques ayant pour objectifs :

 D'améliorer la qualité des prestations de support logistique du système concerné

en termes d'efficacité et de cohérence,

 De définir le soutien logistique qui optimise la disponibilité et les performances du

système par rapport au coût de ce soutien,

 De maîtriser le coût global de possession du système.

Les études industrielles

De l’analyse de besoins à la conception et à la réalisation, intervention à toutes les étapes de projets industriels :

o Etudes d’intégration et aménagement de coque dans le secteur naval, o Conception des éléments de structure des pièces de forme complexe, o Modélisation, aide à la conception des pièces.

Figure 1 : Répartition des activités de STUDEC Traduction 15% Documentation Technique 40% Développements Logiciels 18% SLI & Design

12%

Gestion du Changement

Implantation géographique du groupe

Parallèlement à son évolution technique, STUDEC a multiplié ses implantations géographiques en créant une dizaine d’agences régionales ainsi qu’une agence en Inde.

Figure 2 : Implantation de Studec

Situé près de ses clients, chaque établissement de STUDEC leur apporte souplesse, réactivité et qualité tout en leur garantissant la solidité et la fiabilité d'un groupe. Pour rester proche de ses clients et réactive à leurs attentes, STUDEC est organisée en régions autonomes sur un périmètre d’activité.

Les principales activités de la région Sud-Ouest sont :

 La rédaction des manuels de maintenance et opérationnels

 La création d’illustrations

 Le développement logiciel

Figure 3 : Organisation en région Certification qualité

L’agence de Toulouse, comme l’ensemble des agences, est certifiée ISO 9001 et EN 9100 (version 2009).

Quelques solutions logiciels développées par STUDEC

 Système de E-learning et de formation conforme à SCORM : @CERES

 Chaînes de publication : Suite WebXML (conforme S1000D) et NOMAD (conforme ATA)

 Wysiwis ( what you see is what i see): outil d’assistance à distance pour l’aéronautique 1

1

Mes fonctions

Salarié de STUDEC depuis 2004, j’ai effectué des fonctions de rédacteur technique pendant 8 ans. En 2011, j’ai changé de fonction pour intégrer le service de développement logiciel en parallèle de ma formation au CNAM. J’exerce depuis des fonctions de développeurs XSL, et participe au développement de chaînes de publication.

Du fait de mes connaissances approfondies des fonctions documentaires et de la rédaction technique, je suis amené à mener des activités diverses.

Figure 4 : Répartition de mes activités dans les projets

Les principaux projets sur lesquels j’interviens sont listés ci-dessous :

 WEBXML-SRM/SRKM (client ATR)

Chaîne de publication des manuels Structural Repair Manual (SRM) et Structural Repair Kit Manual (SRKM) (à la norme ATA2200). Cette chaîne comprend un module de saisie de la donnée, un gestionnaire de documents, un module de publication ainsi qu’un intranet encapsulant des publications PDF.

Je travaille sur ce projet depuis son lancement en 2012. J’ai notamment participé à la phase de spécification du système et à la conception des feuilles de style XSL-PDF. Lors de ce projet, j’ai aussi assisté les rédacteurs techniques à la conversion (PDF vers XML) et la mise en conformité des données documentaires. Aujourd’hui, je suis en charge du support aux utilisateurs et des corrections/évolutions (analyse et développement XSL) de cette chaîne. Développement XSL Spécification de système Expertise documentaire Expertise technique XSL Support développeur Support utilisateur/ rédacteur Test

 WEBXML-RTM (client Turbomeca)

Chaîne de publication des manuels de maintenance (niveau 1 à 3) des moteurs RTM322 1 (à

la norme S1000D 1.8). Cette chaîne comprend un module de publication ainsi qu’un IETP. Initié en 2013, je travaille sur ce projet depuis son lancement. J’ai notamment réalisé la spécification du module de publication et conçu les feuilles de style XSL (HTML et PDF) nécessaires à la génération des publications.

Aujourd’hui, je participe aux études d’analyse des besoins et de faisabilité des évolutions, ainsi qu’à la maintenance des feuilles de style XSL.

 Suite WEXML (client Studec)

Chaîne de publication, de la rédaction à la diffusion, conforme au standard S1000D (versions : 1.8, 2.3 et 4.x) conçu comme un produit sur étagère.

Ce projet, lancé en 2015, commence à être déployé chez certains clients. Il permet aujourd’hui de créer des publications volumes.

Ce projet a été particulièrement utilisé pour mettre en œuvre les méthodes et bonnes pratiques de développement étudiées dans ce mémoire.

 Projet LEAP-COBALT (client SNECMA)

Chaîne de publication (module de publication et IETP) pour la documentation des moteurs LEAP 2 (S1000D et ATA2200). Ce projet, lancé en 2015, arrive bientôt dans sa phase de déploiement aux utilisateurs de la documentation.

Au sein d’une équipe de trois développeurs XSL, je suis en charge du développement des feuilles de style XSL (HTML et PDF), ainsi que de l’analyse des données d’entrée et du processus de publication. 1 Cf. http://www.turbomeca.com/fr/moteurs-dhelicopteres/superieur-2-000-shp/rtm322 2 Cf. http://www.snecma.com/fr/moteurs-civils/avions-court-et-moyen-courriers/leap/leap

P

REAMBULE

1.

F

1.1.

La fonction documentaire ne doit plus être comprise comme une fonction qui répond aux seuls besoins d’informations de l’entreprise. Elle a maintenant la capacité de répondre très concrètement à une nécessité : accroître les connaissances de l’entreprise. [2]

La fonction documentaire est l'ensemble des techniques permettant le traitement des données dans le but précis d’accroire la connaissance d’un groupe ciblé d’utilisateur. Cette fonction couvre l’ensemble des opérations permettant la création d’une documentation à partir de données brutes (dossier de modification, plan mécanique, rapport d’exploitation, …). La donnée documentaire est le résultat de l’analyse de données brutes et de la rédaction.

Figure 5: Fonctions documentaires

Collecter Analyser rédaction Stocker Diffuser Documentation Données documentaires Données brutes

Couverture des chaînes de publication STUDEC

Une documentation se présente sous la forme d’un média (papier, électronique, vidéo, …). Dans le secteur de l’aéronautique, l’organisation et la présentation de ces documentations sont fortement normalisées, ceci afin d’en standardiser la lecture et éviter ainsi une mauvaise compréhension de l’information par les opérateurs (navigant, maintenance, …).

Une documentation est créée dans le cadre d’un projet documentaire. Ces projets documentaires sont gérés par un gestionnaire de documentation qui a pour mission de s’assurer de la conformité de la documentation et de « coordonner » les parties prenantes du projet (cf. Figure 5). Chaque partie prenante amène ces exigences dans la documentation, qui peuvent parfois être contradictoires entre-elles. Il existe donc constamment un arbitrage entre l’information à diffuser dans la documentation et les considérations commerciales ou de protection de la propriété intellectuelle et du savoir-faire de l’entreprise [3].

Figure 6 : Partie prenante d’un projet documentaire

Pour réaliser la documentation, le gestionnaire de publication s’appuie sur des rédacteurs

techniques. Les rédacteurs techniques sont les spécialistes des normes documentaires et de la

reformulation de l’information. Le métier de rédacteur technique demande à la fois une connaissance des fonctions documentaires et une connaissance technique du système traité dans la documentation. Documentation Opérateur /utilisateur de la doc. Service après-vente Service commerciale Bureau d'étude ... Agence de certification Service marketing DSI

E

1.2.

Dans un secteur fortement concurrentiel comme celui de l’aéronautique, en plus du cadre réglementaire imposé par les directives de l’Organisation de l'Aviation Civile Internationale (OACI)

et de ces agences supranationales1, la documentation représente un enjeu industriel et

commercial pour les industriels.

Du point de vue réglementaire, les informations contenues à l’intérieur d’une documentation doivent être suffisantes pour conduire les opérations de maintenance et d’exploitation de l’équipement en toute sécurité. Le format du document est aussi normalisé afin d’avoir une uniformité générale des documentations aéronautiques quel que soit l’équipement (modèle d’avion par exemple). Certaines de ces documentations doivent être approuvées par les agences supranationales et sont nécessaires pour l’obtention du certificat de navigabilité de l’aéronef. Du point de vue industriel et commercial, la documentation est un argument de vente supplémentaire. Le constructeur doit fournir les informations permettant aux opérateurs de définir leur propre opération de maintenance, il n’est pas obligé de fournir directement une documentation. Alors, la documentation est souvent proposée comme un service supplémentaire, qui sera facturé ou pas selon les termes du contrat établi lors de la vente. Il existe aussi une concurrence entre les industriels et les prestataires de services aéronautiques proposant leurs solutions de maintenance et donc implicitement leurs documentations. Un autre point important pris en compte lors de la conception de ces documentations est son impact sur le coût de maintenance : une documentation facile à utiliser (facilité pour trouver et comprendre une information) doit permettre d’optimiser les opérations de maintenance (programmées ou pas). Aujourd’hui, de plus en plus, ces documentations permettent de proposer un ensemble de services complémentaires aux opérateurs (suivi automatique des stocks en magasin, aide à la résolution des pannes, support en direct d’un expert, …).

Pour finir, il existe aussi un point plus suggestif mais non négligeable : la documentation participe à la construction de l’image de marque de l’industriel. La documentation permet de refléter la maîtrise de son domaine de compétence, ainsi que sa capacité à innover et à proposer des services permettant d’optimiser l’exploitation de l’équipement.

1

On peut citer notamment l’Agence Européenne de la Sécurité Aérienne (AESA) et la Federal Aviation Administration (FAA) aux Etats Unis

L

1.3.

La rédaction des documentations s’appuie sur l’utilisation des spécifications documentaires. Ces spécifications décrivent principalement le format de la donnée, les préconisations de présentation de la documentation ainsi que les processus de publication.

Généralement, dans un projet documentaire, ces normes documentaires sont complétées par des règles de rédaction permettant de limiter l’utilisation de certaines structures dans la donnée documentaire, d’homogénéiser la saisie des informations, et répondre à des cas spécifiques de rédaction. La donnée documentaire doit alors être conforme aux normes documentaires et aux règles de rédaction.

Figure 7 : Conformité d’une donnée documentaire

Les paragraphes suivants permettent de présenter les principales normes documentaires rencontrées lors de mes projets. Ces spécifications sont toutes (dans leur dernière version) basées sur l’utilisation de langages à balisage (défini à l’aide de DTD, schéma XSD ou relax NG) pour la rédaction des données documentaires.

1.3.1.

D

B

La spécification DocBook1, maintenue par le comité technique du consortium

Advancing Open Standards for the Information Society (OASIS), permet de créer des documents de la forme d’un livre ou d’un article.

Ce standard apparu dans le début des années 1990 est un standard qui se veut ouvert et générique à tous les domaines (informatique, scientifique, technique, …). Il met aussi en place des mécanismes permettant d’enrichir ou restreindre son vocabulaire, et ainsi faciliter sa personnalisation en fonction des besoins.

1 https://www.oasis-open.org/docbook/ Conformité de la donnée documentaire Conformité avec la norme documentaire Conformité avec les règles

1.3.2.

DITA

La spécification DITA1 , historiquement développée par IBM, a été

rattachée à l’OASIS en 2005. Cette spécification permet de définir une architecture documentaire.

DITA propose de voir la documentation comme un ensemble de modules documentaires indépendants, classés en fonction de la nature de l’information. L’assemblage de ces données documentaires entre-elles permet la création des documentations techniques.

1.3.3.

S

ATA

Les spécifications ATA2, maintenues par l’Airline Transport Association,

décrivent des méthodes d’analyse et d’organisation de l’information nécessaire à la maintenance et l’exploitation des équipements aéronautiques.

La première version de cette spécification, datant de 1956, l’ATA ispec 100 est une spécification orientée vers les publications volumes (pour l’impression). Le format des données documentaires est alors un format texte. Dans les années 2000, le standard s’oriente, dans sa version ATA ispec 2200, vers les publications électroniques. Les données documentaires sont alors saisies en SGML.

1.3.4.

S

S1000D

Le standard S1000D3 est un standard documentaire adapté à

l’ensemble des équipements (terre, mer, air et spatial). Historiquement utilisé pour les programmes militaires, ce standard maintenu par le S1000D Steering Committee, s’est ouvert au programme civil. Aujourd’hui, il tend à s’imposer comme le principal standard de la documentation aéronautique (en remplacement du standard ATA).

Ce standard, qui a été initialisé au début des années 90, est orienté vers les publications électroniques. Tout comme le standard DITA, la spécification S1000D définit une organisation des données documentaires. Cette organisation est composée de référentiels (outillages, des fournisseurs, applicabilités, …) et de module de données (DM) stockés dans une base de données 1 http://docs.oasis-open.org/dita/v1.2/spec/DITA1.2-spec.html 2 https://www.ataebiz.org/ 3 http://public.s1000d.org/Pages/Home.aspx

(CSDB). Les publications sont définies dans des modules de publication (PM) qui appelle ces DM. La spécification S1000D favorise la mise en commun et la réutilisation des informations.

La Figure 8 présente un comparatif, entre les spécifications S1000D et ATA2200 (la même comparaison peut être effectuée entre la spécification DITA et DocBook). Ce comparatif met en avant l’intérêt de la CSDB pour la mutualisation et la réutilisation de l’information.

Figure 8 : Comparaison entre le standard ATA et S1000D 1

1

C

1.4.

Une chaîne de publication est un ensemble de sous-systèmes permettant de répondre aux besoins de la fonction documentaire : créer, organiser et diffuser une documentation. Interconnectés entre eux, ces sous-systèmes créent un système d’information complexe. De plus, aujourd’hui, ils existent des connexions entre les chaînes de publication et les autres systèmes métiers (cf. Figure 9).

Figure 9 : Type d’interconnexion des chaînes de publication

Les chaînes de publication, que nous développons, couvrent principalement les fonctions documentaires comprises entre la rédaction de la donnée documentaire et la diffusion des publications.

Figure 10 : Modèle simplifié d’une chaîne de publication type

Chaîne de publication Système de gestion - qualité BDD • Commerciale • Partenaire • Fournisseur Système Web Réalité augmenté Système BE •modèle 3D •simulation •dossier conception Système résolution des pannes Système embarqué

Ces chaînes sont typiquement composées de quatre modules fonctionnels (cf. Figure 10):

 Le module : rédaction de la donnée

Le module de rédaction comporte les outils de rédaction permettant de rédiger et valider la donnée documentaire.

 Le module : gestionnaire de document

Le gestionnaire de document est le module responsable de la gestion et le stockage des données documentaires. Ce module a un comportement identique que les modules de Gestion Electronique de Documents (GED).

 Le module : publication

Le module publication a pour fonction l’assemblage des données documentaires et la construction de la documentation.

 Le module : IETP (Viewer)

L’IETP est le module en charge de diffuser les documentations. L’IETP est le résultat de la publication et se présente généralement sous la forme d’un système Web.

Figure 11 : Aperçu d’un IETP

Ces chaînes de publication sont fortement personnalisables. L’implémentation et le déploiement de ces chaînes diffèrent en fonction des besoins et contraintes du client. Des transformations XSL peuvent exister dans chacun de ces modules.

L

XSL

1.5.

Une transformation XSL est une opération permettant de transformer, suivant des règles, un ou plusieurs documents XML « source » en un ou plusieurs documents « destination » (cf. Figure 12).

Figure 12 : Transformation XSL

Une transformation ne se déroule pas nécessairement en une étape. Elle peut être réalisée en N étape successives. La transformation XSL-Formating Object (FO) est un exemple de transformation en deux étapes : transformation XML vers FO suivi d’une transformation FO vers PDF.

Cette façon de penser, très différente de la démarche de la programmation impérative, est l'une des causes principales de la difficulté qu'ont les programmeurs formés aux langages impératifs pour aborder la programmation fonctionnelle. Cependant, elle ne pose généralement pas de difficultés particulières aux débutants qui n'ont jamais été exposés à des langages impératifs. [4]

Le développement XSL est basé sur une programmation fonctionnelle, ce qui le rend très atypique pour les développeurs codant habituellement avec des langages impératifs. Cette programmation semble simple aux premiers abords, les règles de transformations sont autonomes et il n’existe pas d’effet de bord [5]. Les difficultés du développement XSL réside surtout dans sa difficulté à maintenir et optimiser les règles de transformation, ainsi qu’à concevoir tous les cas de transformation. En plus des connaissances techniques des langages de transformation (XSL, XQuery et XPath), le développement XSL nécessite une bonne connaissance du modèle de la donnée d’entrée et du modèle de la donnée à produire (HTML, FO) [6].

Les transformations XSL étant des opérations permettant de mettre en place une mise en page, elles nécessitent aussi d’avoir une connaissance des feuilles de style CSS et ainsi qu’une grande finesse de développement.

Dans la littérature, le développeur XSL est aussi fréquemment appelé « auteur XSL», ceci renforce l’impression d’un développement particulier et à part. Dans l’article [7], l’auteur suppose que ceci participe à expliquer les singularités de ce développement et son manque de bonne pratique. Il existe un socle commun de connaissance entre la rédaction technique et le développement XSL. A la différence que le développement XSL utilise des méthodes et processus du génie logiciel. Ces deux métiers sont cependant complémentaires, l’échec de l’un entraîne souvent l’échec de l’autre.

L

A PROBLEMATIQUE

D

ETAILLEE

2.

Les feuilles de style XSL sont essentielles à la transformation des données documentaires en documentation technique. Il est d’une importance majeure de maîtriser ces transformations, qui sont au cœur des métiers de Studec.

Ces dernières années, un effort particulier a été mis en œuvre afin d’améliorer la qualité logiciel de nos projets. Cependant, l’amélioration générale de cette qualité n’a pas encore porté sur la partie XSL. L’objectif de ce projet est donc l’amélioration de la qualité logicielle des feuilles de style XSL, ainsi que la création d’une feuille de style « standard » à la norme S1000D.

Il est à noter que ces problèmes XSL ne sont pas spécifiques à nos développements, comme le fait remarquer Norman Walsh [8]:

La plupart des feuilles de style se développent et mûrissent au fil du temps. Les développeurs reviennent souvent sur leurs pas et ceci a plusieurs reprises, faisant de petits et de grands changements pour ajouter des fonctionnalités, corriger les bugs, et les adapter à l'évolution des besoins.

L

2.1.

La maîtrise des transformations XSL dans les chaînes de publication, consiste à améliorer la qualité logicielle des feuilles de styles. Pour fixer et mesurer les améliorations, je m’appuis sur la définition, donnée dans la norme ISO 9126, de la qualité logicielle et de ces six indicateurs :

 la capacité fonctionnelle

La capacité fonctionnelle, capacité d’un logiciel à répondre aux exigences et besoins des usagers (implicites ou explicites), peut se définir par la capacité de la feuille de style à créer des documents conformes aux règles de présentation et de publication.

 la facilité d'utilisation

L’utilisation d’une feuille de style pour l’utilisateur est souvent transparente. Pour ce projet, je considère que la facilité d’utilisation d’une la feuille de style est sa capacité à remonter les erreurs et avertissements de publication.

 la fiabilité

La fiabilité, capacité du logiciel à produire un résultat correct quelles que soient les conditions d’exécution, peut être évaluée par le taux d’échec de publication suite à des données non conformes et la capacité de la feuille de style à produire un résultat même avec une donnée d’entrée dégradée (non conforme avec les règles de rédaction).

 la performance

D’un point du vue utilisateur, la performance d’une transformation se mesure principalement par le temps d’exécution de la transformation. La consommation CPU et de la mémoire est aussi un bon indice des performances de transformation.

 la maintenabilité

La maintenabilité est un facteur très important pour un produit personnalisable comme les feuilles de styles. Les améliorations de maintenabilité ne peuvent se mesurer que sur une longue période.

 la portabilité

La portabilité XSL consiste à réduire la dépendance par rapport au composant pris sur étagère (COTS) utilisés pour exécuter la transformation et du contexte de l’exécution (module de publication, IETP, …).

E

’

2.2.

Lors de cette première phase, je procède à une analyse des défauts existants dans nos feuilles de style dans le but de déterminer les défauts types ainsi que leurs causes. Lors de cette étude, j’étudie en plus des causes techniques, notre processus de développement pour comprendre comment ces défauts sont créés et pourquoi ils ne sont pas identifiés lors des tests.

2.2.1.

L

Nos développements XSL sont réalisés suivant un cycle de développement en V dans lequel la phase de conception est assez réduite, voir intégrée à la phase de spécification. Il est aussi important de noter que ce cycle de développement est très peu itératif. On observe aussi, que lorsque le projet comporte deux types de transformation (PDF ou HTML), il existe quasiment deux projets menés successivement. Cela s’explique par le fait qu’il existe généralement deux jalons de livraison des XSL ; le premier jalon avec seulement un type de transformation (HTML par exemple) déployé, et le second avec les deux types de transformation (HTML et PDF par exemple) déployés.

La phase de spécification

La phase de spécification est basée principalement sur l’analyse du schéma de la donnée à transformer, des exemples de donnée, des règles de rédaction et des exigences de présentation. La première phase consiste à effectuer « les jonctions » entre le modèle de donnée et les éléments de présentation. Pour cela, les différentes structures du modèle sont explorées au fur et à mesure et rattachées à une structure de présentation. Ces jonctions permettent ensuite de déterminer la ou les règles de transformation selon le modalisme :

Lorsque l’élément {nom de l’élément} est rencontré dans le contexte {prédicat XPath} alors le modèle est transformé en …

Un exemple de la transformation réalisée par la règle est ajouté à la spécification. La structure produite est directement décrite dans le langage à produire (FO ou HTML). Une représentation du résultat (maquette) est associée à cet exemple de transformation.

Le dossier de spécification permet aussi de lister les styles utilisés dans les documents. Une section est ajoutée afin de lister les éléments qui ne sont pas pris en compte dans la transformation, ainsi qu’une section recensant les éléments ne modifiant pas le style de l’affichage.

En parallèle du dossier de spécification, une instance XML, représentative des données réelles à publier, est créée. Cette instance comporte notamment des points de contrôle à vérifier.

La phase de codage

Le codage des feuilles de style est généralement réparti entre plusieurs développeurs. Le découpage s’effectue souvent en suivant les structures logiques du schéma (type de tâche, indexes, …). Ce mode de répartition fonctionne bien mais nécessite une bonne communication entre les développeurs, car des sous-structures sont souvent communes aux autres structures logiques. Pour coder les règles, les développeurs doivent respecter des règles de développements définies dans un document transverse à nos projets XSL. Ces recommandations visent principalement à améliorer la lisibilité du code et à interdire l’introduction de code « à risque » (principalement pour les performances d’exécution).

Des tests intermédiaires sont régulièrement réalisés par les développeurs pour valider « l’assemblage » de la feuille de style, et ceci au fur et à mesure de l’avancement du développement. Une revue de code, en collaboration avec un autre développeur, est obligatoirement effectuée.

La phase de recette

Cette phase consiste à valider la conformité des feuilles de style XSL avec le dossier de spécification. Lors de cette phase, deux types de tests sont déroulés manuellement :

 Un contrôle de la publication de l’instance de test, dans laquelle la procédure de test et les

points de contrôle sont directement rédigés dans le document.

 Un contrôle « à l’aveugle » qui consiste à contrôler une ou plusieurs publications réelles et

à vérifier le résultat.

Le dernier test réalisé avant une livraison est un test de non-régression. Ce test consiste à publier une donnée de référence avec la version N et N-1 de la XSL. Les deux documents produits sont ensuite comparés automatiquement à l’aide d’un outil, et chaque différence détectée est ensuite analysée pour vérifier si le changement est conforme aux attentes. Cette analyse est effectuée manuellement.

2.2.2.

L

Les défauts XSL peuvent avoir une criticité importante, avec toutes les conséquences qui en découlent (livraison d’un patch correctif, non satisfaction du client, …). Ces défauts ont généralement un impact important sur le résultat de la publication pouvant aller jusqu’à un échec de la publication. Cependant, la criticité du défaut n’est pas forcement liée à sa conséquence ; un petit défaut sur un élément fortement présent dans la documentation peut devenir très vite critique.

Une étude des défauts XSL usuels m’a permis de les classifier, en fonction de leur conséquence, en quatre grands types:

 Les défauts de mise en page

Ces défauts entrainent une erreur d’affichage. Ces défauts deviennent critiques lorsqu’ils finissent par gêner fortement la lecture du document.

 Les défauts de cohérence documentaire

Ces défauts concernent souvent des erreurs telles que les erreurs de numérotation des éléments (table, figure, ..), des références erronées, des listes ou données déduites incorrectes, …. Ces erreurs sont généralement critiques car elles peuvent altérer la compréhension de la documentation.

 Les défauts de contexte XML non-couvert

Ces défauts concernent des informations dans la donnée d’entrée et qui n’apparaissent pas dans la documentation. La criticité de ces défauts est déterminée en fonction de l’importance de la donnée et des impacts sur la compréhension du document.

 Les échecs de publication

Les échecs de publication sont des défauts critiques qui nécessitent une intervention immédiate. Ces erreurs entraînent l’impossibilité de publier la documentation et donc de la diffuser.

Dans la réalité, la distinction n’est pas aussi simple, un défaut a souvent plusieurs conséquences (un défaut de cohérence causé par un contexte XML non couvert par exemple).

Figure 13 : Répartition des défauts

Les défauts XSL ne sont pas forcément plus importants que les défauts des autres composants de la chaîne de publication. Cependant, trois raisons principales expliquent pourquoi ces défauts sont perçus différemment :

 Les défauts XSL impactent directement la qualité du produit délivré par la chaîne de

publication et sont directement « exposés » aux lecteurs et utilisateurs de la documentation.

 Dans la donnée d’entrée, il y a de nombreuses structures XML communes ou semblables,

et un défaut, même mineur, peut avoir des répercussions sur un nombre important de pages de la publication.

40%

25% 25%

10%

Répartition des défauts

Défaut de mise en page Défaut de cohérence documentaire

Contexte XML non couvert Echec de publication

 Dans les transformations XSL, 90% de la donnée est transformée ou utilisée, à la différence des autres composants qui ne vont utiliser en moyenne que 15% de la donnée, correspondant aux informations de gestion (date, version, identifiant, …) des documents, dans leurs traitements.

Lorsque j’ai étudié les origines de ces défauts, il est apparu trois grandes familles :

 Les problèmes de spécification

Un nombre important de défauts sont liés à un manquement dans la spécification. En effet, les contextes non couverts et les défauts de cohérence documentaire proviennent généralement d’une erreur ou d’un oubli dans le dossier de spécification.

 Les problèmes de codage

Les défauts de mise en page sont généralement liés à un problème de codage (style incorrecte appliqué à un élément, …) ou de complexité XSL. Ces défauts ne sont pas nécessairement XSL, ils peuvent provenir aussi d’une erreur dans la feuille de style CSS. Dans quelques cas, il arrive aussi que les défauts proviennent d’un défaut (par rapport à la

recommandation W3C XSL1) du processeur de formatage Objet/PDF (FOP) ; dans ce cas,

une solution de contournement doit être trouvée.

 Les problèmes de données

Certains défauts sont liés à un problème de donnée (souvent une non-conformité avec une règle de rédaction), et sont régulièrement à l’origine d’un échec de publication.

J’ai ensuite vérifié si ces défauts avaient été détectés lors de nos tests. J’ai pour cela « épluché » les rapports de test et recherché les défauts. Ceux-ci sont généralement présents, sans être cependant signalés. Ce constat permet de déduire que la couverture des tests est suffisante pour détecter les défauts, mais que l’exploitation des rapports de test est insuffisante pour les mettre en évidence, ces défauts étant « noyés » dans la quantité importante de données à contrôler.

L

’

2.3.

En plus de la diminution significativement du nombre de défauts, un autre objectif fort de ce projet est d’arriver à créer une feuille de style standard S1000D. Cette XSL doit être aussi facilement personnalisable en fonction des besoins spécifiques d’un client (comportement comme

1

présentation). Il est donc nécessaire de mettre en place des mécanismes permettant la personnalisation et le paramétrage dans la feuille de style.

Avant de commencer ce projet, je me suis intéressé aux feuilles de styles DocBook développées par Norman Walsh [9]. Ces feuilles de style ont notamment la réputation d’être fortement configuration et personnalisable. Dans le document [8], les principes de conception et les règles de codage appliquées dans ces feuilles de style sont décrits :

La modularité

La modularité XSL permet de rendre une feuille de style flexible, ce qui facilite d’autant plus sa maintenabilité et sa personnalisation. Dans les feuilles de style DocBook, cette modularité se traduit par le découpage de la feuille de style et des règles de transformation. Ces XSL mettent en œuvre une mutualisation du code (HTML et FO), et une internalisation.

Le paramétrage

Le paramétrage de la feuille de style XSL comprend toutes les règles permettant de faciliter les opérations de personnalisation de la transformation et de la mise en page des documents produits. Dans DocBook, ce paramétrage est très avancé, car il vise à rendre la feuille de style facilement paramétrable à tous les utilisateurs, quel que soit leur niveau de connaissance en XSL.

La documentation technique

Comme pour tous les autres produits logiciels, les feuilles de style XSL nécessitent une documentation technique afin de faciliter la maintenance, les évolutions ainsi que son utilisation.

Les extensions

La nécessité d’utiliser des extensions au langage XSL part du constat que toutes les opérations de traitement et de transformation ne sont pas nécessairement adaptées au langage XSL. Lorsqu’un traitement semble difficile à réaliser en XSL, il est alors nécessaire de se questionner sur la nécessité d’utiliser une extension développée dans un langage adapté au traitement à faire.

Dans l’objectif d’amélioration des transformations XSL, ce projet doit aboutir à intégrer ces quatre principes dans la conception de nos feuilles de style, et nécessite, à cette fin, de modifier notre façon de concevoir ces transformations XSL. Pour cela, les cas d’utilisation présentés dans le document [10], une introduction à XProc, ont retenu mon attention. Ces cas d’utilisation mettent en évidence l’intérêt des transformations en plusieurs étapes dans les opérations de publication. Le manque de mise en évidence des défauts dans nos tests est problématique car il rend difficile et coûteuse la vérification de la conformité aux spécifications. Pour résoudre cette problématique, je me suis m’intéressé à la méthode de développement par les tests (TDD) préconisée dans la pratique Agile [11].

Dans la première partie du projet (Chapitre 3), je cherche à améliorer la qualité de nos feuilles de style à travers la mise en œuvre de ces méthodes et bonnes pratiques de développement.

Dans une seconde partie du projet (Chapitre 4), je cherche à résoudre ces problématiques à l’aide d’une approche de développement pilotée par les modèles, issue des pratiques de l’Ingénierie Dirigée par les Modèles (IDM). Cette partie, plus expérimentale, ne sera pas mise en œuvre dans un projet, mais est complétée par un cas d’utilisation.

L

ES

B

ONNES

P

RATIQUES

XSL

3.

Ce chapitre présente le choix des méthodes et bonnes pratiques qui permettent d’améliorer la qualité générale de nos feuilles de style XSL.

M

3.1.

La documentation technique est généralement un livrable contractuel d’un projet logiciel. Cette documentation permet notamment de délimiter le périmètre d’un système par la spécification de son comportement, faciliter la maintenance par l’explication de ces composants et expliquer son utilisation.

De façon générale, j’ai pu observer que les documentations que nous produisons actuellement répondent difficilement à ces objectifs. Il est aussi à noter que pour le moment le manuel utilisateur de la feuille de style n’est pas nécessaire, les feuilles de style n’étant pas encore ouvertes à un paramétrage direct par des utilisateurs.

3.1.1.

L

Le dossier de spécification, tel qu’il est conçu actuellement est problématique notamment car il n’est pas forcement simple à comprendre (donc à faire valider par les demandeurs) et qu’il est surtout souvent incomplet. De plus, la lecture de ce document permet difficilement de se faire une idée globale de la transformation. D’après moi, cette complexité existe principalement car le comportement de la transformation et la définition des styles du document à produire sont trop « mélangés » dans ce document.

Les recherches que j’ai effectuées sur ce domaine montrent qu’il est préférable d’éclater le dossier de spécification dans deux spécifications distinctes:

 La spécification de présentation (appelé aussi guide de présentation dans le domaine de la

documentation) qui spécifie comment l’information est formatée. Il peut être aussi intéressant d’attacher un guide des styles, en particulier pour les transformations HTML. L’article [12] met en avant les avantages de ce type de guide pour la spécification des sites/applications Web, et la création des feuilles de style CSS.

 La spécification de transformation qui spécifie les règles de transformation. Ces règles permettent d’établir le mapping entre les structures documentaires et les structures décrites dans le guide de présentation.

Ces deux spécifications ne peuvent être réalisées sans prendre en compte le guide de rédaction, qui spécifie le format de la donnée d’entrée. Il est à noter, que concrètement, ces guides ne sont pas toujours de la responsabilité de la même personne (cf. Figure 14), et qu’il nécessite donc une collaboration entre ces personnes.

Figure 14 : Dépendance entre les dossiers de spécification

Cette façon d’organiser ces spécifications, en scindant la présentation du comportement, présentent deux autres avantages : faciliter les personnalisations (de l’affichage notamment) et la réutilisation des définitions (entre les publications volume et électronique). Il est à noter que cette organisation des spécifications est effectuée de façon similaire dans la norme S1000D.

3.1.2.

L

Ce projet m’a permis d’intégrer une nouvelle documentation technique décrivant l’architecture générale et le code XSL. Pour notre objectif de créer une feuille de style standard, cette documentation est fondamentale pour donner aux futurs développeurs l’information permettant de facilement faire évoluer la feuille de style.

Guide de

présentation

Guide de

transformation

Guide de

rédaction

Décris la présentation des publications

Développeurs

Décris la mise en place des éléments

Gestionnaires de documentation/rédacteurs

Décris la structure de la donnée d’entrée

Exemple : Les étapes d’une procédure sont affichées en (10px, normal), interligne,… Le titre …. Exemple :

L’élément step est utilisé pour définir une étape de procédure. Le titre est obligatoire

Exemple : L’élément {step} crée une étape de procédure. La numérotation du § est posée au niveau du titre

Numérotation = compteur numérique des éléments step