Partie 2 Modèle et Application - INSA Lyon

Partie 2 / Modèle et Application

Partie 2

Modèle et Application

Chapitre 4 / Modélisation des données

ALVAREZ Abraham 79 Thèse en Informatique / 2003 Institut national des sciences appliquées de Lyon

Chapitre 4

Modélisation des données

« Un problème sans solution est un problème mal posé »

Albert Einstein

Résumé du chapitre : Ce chapitre présente la définition d’un modèle basé sur une

double modélisation qui va nous permettre de représenter les documents, leurs liens

et les versions avec une granularité fine (c'est-à-dire une représentation au niveau

élément du document). Autour d’une étude de cas, nous aborderons la gestion de la

cohérence des documents tout au long de leur cycle de vie.



Table des matières

1 INTRODUCTION _______________________________________________ 81

1.1 DEFINITION DE L'INTEGRITE DOCUMENTAIRE _______________________________82

2 CONTEXTE ET PROBLEMATIQUE__________________________________ 83

2.1 PRESENTATION DU CHAPITRE (SCENARIO) __________________________________85

2.2 IMPLICATION de la documentation technique dans le processus de production _____86

2.3 PROPOSITION _______________________________________________________89

2.4 CLASIFICATION DE LIENS ______________________________________________90

2.4.1 Lien de référence (nommé aussi simple) ______________________________91

2.4.2 Lien de partage d'information (ou de connaissances)____________________92

2.4.3 Lien de composition _______________________________________________97

3 MODELE DE DONNEES POUR LA GESTION DE LIENS _______________ 98

3.1 DIMENSION STRUCTURE _______________________________________________98

3.2 GESTION DES VERSIONS ______________________________________________100

3.2.1 Versions des fragments ___________________________________________102

3.2.2 Incidences des mises à jour ________________________________________103

3.2.3 Instanciation du modèle de données _________________________________104

3.3 ACTEURS __________________________________________________________106

3.4 FORMALISATION DU MODELE __________________________________________107

3.4.1 Formalisation des documents ______________________________________107

3.4.2 Formalisation des liens____________________________________________109

3.4.3 Versions des liens ________________________________________________109

3.5 DESCRIPTION DES CLASSES DU MODELE ________________________________111

4 CONCLUSION ______________________________________________ 114



1 Introduction

Comme dit auparavant, dans le monde de l’entreprise, chaque processus majeur de

l’entreprise est un processus conduit ou supporté par des documents techniques;

comme le processus de production d’un produit industriel. En rationalisant les pro-

cessus de création, validation, gestion et distribution de documents, les entreprises

peuvent réduire d’une manière importante les procédures commerciales, raccourcir

les délais de mise sur le marché, améliorer la qualité des produits.

Il est incontestable, que la documentation technique joue un rôle clé dans les

étapes du cycle de vie d'un produit en tant qu’entrée, et support dans ce processus de

production, depuis l'étape de conception jusqu’au moment où le produit est terminé.

Elle est donc le reflet des connaissances du domaine, connaissances permettant

l’exécution des tâches courantes de l’activité concernée. La documentation technique

est rencontrée sous une grande diversité de formes :

les guides donnant des consignes pour l’exécution de telle ou telle tâche

les manuels décrivant un système

les manuels techniques et les manuels d'opération pour les utilisateurs

les manuels de spécifications, de fabrication et de la maintenance pour

les ingénieurs

des informations de gestion de production

des procédures, le cahier de charges, etc.

Cet ensemble de documents est relatif à un domaine donné et sert comme

instrument de travail pour une activité bien déterminée. Dans notre travail de recher-

che, cette activité est considérée comme un métier d’ingénierie où il s’agit, par exem-

ple, de supporter toutes les étapes du cycle de vie d’élaboration d’un produit. Cette

activité doit être supportée par un Système de Gestion Électroniques de Documents

(Systèmes de GED), dont l’objectif est d’assurer toutes les fonctionnalités dans la

chaîne documentaire : depuis leur création jusqu’à leur archivage, en passant par les

étapes de révision, d'approbation et diffusion [Amghar97]. La gestion des documents

est une des préoccupations majeures de toute entreprise.



Les nouvelles générations d’applications basées sur des environnements X-

Net (Intranet et Extranet), telles que les applications Workflow, Groupware et plus

précisément les Systèmes de GED occupent de plus en plus de places stratégiques, ils

nécessitent :

des plates-formes plus complexes (haute performance et haute qualité)

qui fournissent des outils qui soient capables de gérer les insuffisances

des Systèmes de GED.

des modèles de données qui permettent extension et généralisation.

la prise en compte de la gestion globale de la cohérence qui, à notre

point de vue, constitue une caractéristique fondamentale de ces systèmes

et n'est traitée que partiellement dans la plupart des systèmes existants.

1.1 Définition de l'intégrité documentaire

Nous pouvons formuler une définition de l'intégrité d'un document comme suit :

I ) « L'intégrité d'un document est assurée lorsqu'il y a la possibilité de véri-

fier que l'information n'en est pas altérée et qu'elle est maintenue dans

son intégralité. De plus, il faut que le support portant l'information pro-

cure à celle-ci la stabilité et la pérennité voulue. Il ne faut pas que l'in-

formation soit susceptible de disparaître ou d'être modifiée sans que l'on

puisse s'en apercevoir ».

II ) « L'intégrité d'un document vis-à-vis des liens est assurée lorsque tous les

liens sont cohérents ».

Ces définitions vont nous permettre de poser la problématique de notre re-

cherche. En effet, nous cherchons à élaborer une solution de gestion de la cohérence

des liens Inter & Intra documents en vue d'améliorer les processus de workflow dans

le contexte de suivi du cycle de vie d'un produit manufacturé.

Dans la section suivante intitulée contexte et problématique, nous aborderons

deux approches qui interviennent dans le processus de production de documents élec-

troniques : l'approche Workflow et l'approche Cycle de vie du produit. Nonobstant



ces deux approches accentuent la complexité pour contrôler et gérer la gestion de

liens Inter & Intradocuments.

2 Contexte et Problématique

La nécessité pour les entreprises de dépasser le cadre local ou national entraîne de

nouvelles organisations de travail où l'aspect géographique n’est plus un paramètre

déterminant pour faire fonctionner des équipes autour d’un projet. Les outils de

Workflow et de Groupware deviennent dans ce contexte incontournables pour

l’aboutissement des projets. A côté de ces outils, la GED joue un rôle prépondérant

proportionnel à la complexité et au volume important de la documentation technique

avec :

Des manuels d'opération, de spécifications, de fabrication, de la mainte-

nance.

Des manuels techniques pour les utilisateurs, des documents

d’ingénierie, des informations de gestion de production et enfin des bre-

vets, des procédures, le cahier de charges, etc.

Le processus de production de documents est ainsi supporté par le Système

de Gestion Électronique Documentaire (Systèmes de GED) le plus souvent dans des

environnements Inter & IntraNet. L’objectif d’une GED est d’assurer toutes les fonc-

tionnalités dans la chaîne documentaire : depuis la création jusqu'à l'archivage, en

passant par la révision, l'approbation et la diffusion.

La figure 4-1 schématise l'interaction et/ou l'interrelation de l'ensemble du

processus entre les différents Serveurs de GED et les processus Workflow de l'entre-

prise pour la conception d'un produit manufacturé.



Serveur de documents A

Système de GED

Client Browser

Base de documents, audio, vidéo

Internet

Client BrowserBase de

documents

Clients Browser

I n t r a n e t

Serveur de documents B

Système de GED


Serveur de documents C

Système de GED


PC PC

Liens Inter et Intra documentsLiens Inter et Intra documentsLiens Inter et Intra documents

Serveur Web de documents

Processus de Workflow

Ingén

ierie

Docu

men

taire

Création Révision Approbation ArchivageDiffusion

Cycle de vie du documentconception fabrication

contrôle de qualité

maintenance

PC

Serveur de documents A

Système de GED

Client Browser


Internet

Client BrowserBase de

documents

Clients Browser

I n t r a n e t

Serveur de documents B

Système de GED


Serveur de documents C

Système de GED


PC PC

Liens Inter et Intra documentsLiens Inter et Intra documentsLiens Inter et Intra documents

Serveur Web de documents

Processus de Workflow

Ingén

ierie

Docu

men

taire

Création Révision Approbation ArchivageDiffusion

Cycle de vie du documentconception fabrication

contrôle de qualité

maintenance

PC

Figure 4-1 Ensemble de processus liés à la gestion de la cohérence des liens Inter

& Intra documents.

Mettons en évidence la complexité que représente l’action de gérer de façon

efficace l'ensemble des documents et des liens repartis sur de Serveurs de GED. Cette

complexité est due à :

la diversité des médias contenus dans les documents (tels que l'audio, la

vidéo, l'hypertexte, les hyperliens, etc.)

les différents types d'hyperliens et/ou liens hypertextuels (par exemple :

liens de référence, de partage d'information et de composition)

au volume des données.

Par ailleurs, l'ensemble des documents structurés est lié par des liens hyper-

textuels. Il est cependant inévitable que ces documents ainsi que leur contenu (texte,

liens, images, etc.) soient exposés aux modifications effectuées par un auteur ou un

groupe d’auteurs. Lorsque ces manipulations sont achevées, il existe un risque poten-

tiel d’altérer ou détruire l’intégrité de la base documentaire et du document même.

Cette répercussion peut avoir un impact en chaîne sur les autres activités ou tâches,

par exemple : dans un processus workflow (le cycle de vie d'un produit manufacturé)



ou dans le processus de l'ingénierie documentaire comme par exemple le cas du cycle

de vie d’un document.

2.1 Présentation du chapitre (scénario)

Imaginons un fabricant de produits électroniques grand public dans le domaine de la

téléphonie mobile (téléphones mobiles, chargeurs, etc.) La compagnie a décidé de

s’étendre en créant un nouveau secteur commercial et un nouveau produit pour le

marché canadien. Concernant les données du produit, deux grandes catégories

d’informations peuvent être distinguées :

1. Les informations qui décrivent les produits de l’entreprise aux différentes

phases de leur cycle de vie. Un manuel d'inspection qui décrit les caracté-

ristiques techniques (volume, mesure, aspect physique, etc.) dans certains

phases du cycle de vie du produit.

2. Les informations qui se réfèrent aux composants préexistants, qui sont uti-

lisés pour concevoir, fabriquer ou maintenir les produits de l’entreprise,

c'est-à-dire les guides d'opération et/ou maintenance qui décrivent les ca-

ractéristique physiques et techniques de la matière première.

Ces types de données possèdent des points en commun (par exemple : le fait

qu’ils décrivent), du point de vue de la modélisation, ils se caractérisent par deux as-

pects :

L’origine de l’information : l’information sur les produits de l’entreprise

est créée dans l’entreprise elle-même. La description et la connaissance

sur les composants proviennent de leurs fournisseurs. Un échange entre

fournisseurs et utilisateurs de composants augmenterait la disponibilité

et la précision de l’information.

La structure de l’information : chaque produit réalisé par l’entreprise est

individuellement, explicitement et exhaustivement représenté pour per-

mettre sa fabrication.

Cependant, ces types de données nécessitent à leur tour, la définition d’un

modèle pour les représenter, gérer et exploiter. (C.f. Section 3).



La production actuelle des téléphones mobiles et de leur documentation est

basée sur les normes de réseau GSM900 et GSM1800 bien spécifiques pour la com-

munauté européenne (CE). En revanche, il faut savoir que pour pénétrer le marché

canadien on doit respecter deux normes : la norme IDEN et la norme PCS 1900. Pour

l'orient on peut citer la norme CDMA.

2.2 Implication de la documentation technique dans le processus de production

La compagnie se voit obligée de créer des annexes techniques et de remettre en

production des éléments de sa documentation technique afin de les adapter aux

normes utilisées pour le marché canadien : la norme IDEN et la norme PCS1900.

Dans cette perspective, distinguons la création de deux documents, un pour chaque

norme respectivement.

Nous considérons dans ce scénario d’utilisation, le domaine de la

documentation technique pour illustrer notre proposition. La documentation

technique traverse différents processus impliqués dans la production d’un produit.

Elle peut être définie de la façon suivante :

« Un document technique qui explique comment utiliser, maintenir et

manipuler un produit depuis sa mise à création jusqu’à sa livraison, et

qui fournit en outre une information technique dont l’utilisateur a be-

soin pendant le cycle de vie du produit ». (C.f. figure 4.2). [AA03],

[AACH02b].



Fabrication Contrôle de qualité

Acquisition(achat)

Maintenance(service

après vente)

début processus Livraison

client

Conception (CAO)

(1, 2) ( 2 ) (3, 4)

(5)(6)(1,7)

(1) manuel des spécifications techniques

(2) manuel de fabrication(3) manuel d’inspection(4) ISO 9000(5) procédure ventes, facture(6) garantie, manuel d’opération(7) manuel de maintenance

fin du processus

Documentation technique

Étapes de processus de production d’un produit

Fabrication Contrôle de qualité

Acquisition(achat)

Maintenance(service

après vente)

début processus Livraison

client

Conception (CAO)

(1, 2) ( 2 ) (3, 4)

(5)(6)(1,7)

(1) manuel des spécifications techniques

(2) manuel de fabrication(3) manuel d’inspection(4) ISO 9000(5) procédure ventes, facture(6) garantie, manuel d’opération(7) manuel de maintenance

fin du processus

Documentation technique

Étapes de processus de production d’un produit

Figure 4-2 La documentation technique dans le processus de production d'un produit.

Voyons maintenant l’association (document – étape) du processus. Nous as-

socions à chaque type de document créé la phase qui lui est associée. Notons qu’un

document peut intervenir ou être impliqué à la fois sur une ou plusieurs phases. Par

exemple le manuel de spécification technique est utilisé dans la phase de conception,

la phase de fabrication et également dans la phase de maintenance.

Le tableau ci-dessous résume l’association «document – étape du processus»

de la documentation technique dans le processus de production d'un produit.

Document Processus de

l'entreprise Autre information attachée

Manuel des spécifications tech-niques

Conception, fabrication, maintenance

Dessins, diagrammes, images, maquettes, graphes, modèle CAO

Manuel de fabrication Fabrication Procédures, cahier des charges, schémas, organigrammes

Manuel d'inspection Manuel ISO9000,

Contrôle de qua-lité

Spécifications, plannings, procédures de stockage, de manipulation, procédures de mise en œuvre.

Manuel de maintenance Maintenance Gamme d'opération. Manuel de procédures d'acquisi-tion,

Acquisition (achat)

Procédures de ventes, facture, garantie.

Tableau 4-1 Implication de la documentation technique vers le processus de production

d'un produit.



La documentation technique regroupe plusieurs familles de manuels que l'on

peut classer en trois grandes catégories :

1. Ceux qui décrivent la machine ou le matériel : notices techniques, ma-

nuels de référence, nomenclatures, etc.

2. Ceux qui servent à la formation des utilisateurs : manuels de formation et

d'utilisation, aide-mémoire des fonctions d'un logiciel, etc.

3. Ceux qui servent à la maintenance du matériel : manuels de maintenance,

catalogues de pièces, guide des procédures, cahiers d'incidents, rapports

d’anomalies, etc.

Retenons bien ici, que c’est grâce au mécanisme des liens hypertextuels, que

ces documents sont liés entre eux. Cela signifie qu'ils sont capables de véhiculer

toute ou une partie de l’information nécessaire aux différentes intervenants dans la

chaîne du processus d'élaboration d’un produit industriel. (C.f. figure 4-3). En

d’autres termes, un document et ses liens sont comme un chaînon dans le processus

d'élaboration du produit.

Lien 1 Lien 2

Lien 3Lien 4Lien 5Lien 6

Bureau d’études

Processus de production

Départementde fabrication

Départementcontrôle de qualité

Départementd’assemblage

Manipulations

Création Révision Approbation

Archivage Diffusion

Consultation

Système de GED

Manuel de fabrication


Manuel de maintenanceManuel de

maintenance


maintenanceManuel

d’installationManuel

d’installationProcéduresProcédures

Manuel techniqueManuel

techniqueManuels ISO-

9000Manuels ISO-

9000Manuel de

spécificationsManuel de

spécifications

Lien 1 Lien 2

Lien 3Lien 4Lien 5Lien 6

Bureau d’études

Processus de production

Départementde fabrication

Départementcontrôle de qualité

Départementd’assemblage

Manipulations

Création Révision Approbation

Archivage Diffusion

Consultation

Système de GED




maintenance


maintenanceManuel

d’installationManuel

d’installationProcéduresProcédures

Manuel techniqueManuel

techniqueManuels ISO-

9000Manuels ISO-

9000Manuel de

spécificationsManuel de

spécifications

Figure 4-3 Mécanisme de liens dans le processus de production.



Il est cependant inévitable que ces documents ainsi que leur contenu (texte,

liens, images, etc.) soient exposés aux modifications par un auteur ou un groupe

d’auteurs. Lorsque ces manipulations sont achevées, il existe un risque potentiel

d’altérer ou de détruire l’intégrité de la base documentaire et du document même.

2.3 Proposition

La gestion de la cohérence d'une base documentaire dans des environnements Intra-

Net et ExtraNet, constitue une de nos préoccupations majeures, car c'est un problème

important dans le cas des Systèmes de Gestion Électronique Documentaires (Systè-

mes de GED).

Ces objectifs nous posent de nouvelles interrogations :

« Comment peut-on gérer conjointement la cohérence globale du do-

cument et la cohérence des différents composants du document tout au

long de leur cycle de vie ? »

Pour répondre à cette question, nous constatons que la cohérence globale

d'un document et de ses différents composants, résultent de la gestion intelligente de

deux niveaux de gestion : un premier niveau concerne l'ensemble entier du document

et un deuxième les éléments du document. Cela implique la définition d’un méca-

nisme actif, lequel va interagir entre ces deux niveaux de manipulation et les données

de la base. Bien entendu, un tel mécanisme suppose l'élaboration de règles permettant

de garantir automatiquement la cohérence de ces manipulations, donc la cohérence

des documents et de la base.

La gestion de la cohérence des documents et la définition du mécanisme actif

mettent en jeu deux aspects indispensables dans nos travaux de recherche :

L’aspect modélisation des données. La définition d’un modèle de données

pour la représentation des documents et la gestion de leurs versions.

L’aspect des règles actives. La définition d’un modèle de règles actives

pour assurer la gestion automatique de la cohérence des documents.



2.4 Classification de liens

Comme nous l'avons signalé précédemment dans la introduction générale, la gestion

de la cohérence de la base documentaire, y compris les liens, est une de nos préoccu-

pations majeures et définit l'objet de l'un de nos objectifs. Avant citer les caractéristi-

ques de liens, nous considérons pertinent de donner une définition de lien hyper-

texte :

« Un lien hypertexte est une relation (interconnexion) entre différen-

tes parties d’un hypertexte et est souvent représenté par un bouton (un

graphique, une image, ou le classique mot souligné) qui lors de son

activation va afficher un nouveau fragment hypertexte. »

Remarquons que les liens constituent le principal moyen d’organiser un système hy-

pertexte. Ils permettent à l’utilisateur de se déplacer d’un endroit à un autre d’une

manière non séquentielle. Il existe différents types de liens :

Des liens simples ou de référence

Des liens étendus (bidirectionnels)

Des liens internes. Lorsque la cible est interne au document qui

contient le lien.

Des liens externes. Lorsque la cible est à l'extérieur du document qui

contient le lien.

La codification d'un lien (son point d'ancrage) s'effectue au niveau de l'ancre

source, en introduisant dans le contenu du document source du lien, la balise <A> ca-

ractérisée par l'attribut href selon la syntaxe suivante :

<A href= identifiant système de l'ancre cible> identifiant de l'ancre cible</A>

L'identifiant système de l'ancre cible correspond à l'URL (Uniform Resource

Locator) de la page cible, suivi éventuellement du caractère "#" et d'une séquence de

caractères correspondant à un identifiant local à cette page utilisé pour repérer une

partie du contenu. L'identifiant utilisateur de l'ancre est généralement une chaîne de

caractères à laquelle est associée une mise en forme particulière (exemple). Ceci per-



met au lecteur d'identifier la présence d'un lien activable pour l'atteindre et ainsi de

visualiser le contenu de l'ancre source.

Il est évident que de nombreux autres types de liens sont possibles (C.f. Sec-

tion 4, chapitre 1), Randall [Trigg83] dans la collaboration du projet Texnet. Néan-

moins, les types que nous abordons sont ceux les plus couramment rencontrés dans

les documents que nous étudions. Voyons, en détail ces liens :

2.4.1 Lien de référence (nommé aussi simple)

Un lien simple est défini par deux ancres : une ancre source et une ancre ci-

ble. Ce type de lien est un lien unidirectionnel qui associe exactement deux res-

sources. Cela signifie que les ancres peuvent être nommées ancre départ (pour la

source) et ancre d'arrivée (pour la cible). En d’autres termes, c’est une relation entre

deux points d'un lien : le point source (initial) et le point cible (final). Une ancre est

définie comme une extrémité d'un lien.

La figure 4-4, illustre ce type de lien et ses deux ancres respectivement.

Ancre départ(source)

Ancre d’arrivé(cible)

Fichier A Fichier A ou B

Ancre départ(source)

Ancre d’arrivé(cible)

Fichier A Fichier A ou B

Figure 4-4. Représentation d'un lien de référence

L'origine du lien est locale car elle est définie à l'intérieur même du lien (en-

tre ses balises). La cible du lien est distante car elle est située en dehors de celui-ci,

que ce soit dans le même document ou non. Ce type de lien est dit "en ligne" car il

possède une ressource locale, son origine.

Ce type de lien est en général introduit pour référencer d'autres informations

qui peuvent être des explications (définitions, illustrations, etc.) ou des expressions

réservées, comme par exemple "voir figure 2.3", "C.f. la section 2.1", "comme exposé



dans …". Le nombre d'expressions est hélas trop important pour permettre une détec-

tion automatique des liens de référence. Il semble donc plus prudent de demander

l'intervention de l'utilisateur afin de mettre ces liens en évidence.

La figure 4-5 illustre un exemple de lien simple qui pointe vers le fichier

alvarez.xml du site « LIRIS ».

URL du fichier index

http://liris.insa-lyon.fr/auteurs/alvarez.xml

Sens de la Navigation

Fichiers associés par le lien XML

<AUTEUR xmlns:xlink="http://www.w3.org/1999/xlink/namespace/" xlink:type="simple"xlink:href="http://liris.insa-lyon.fr/auteurs/alvarez.xml" xlink:title="l'auteur de cette page"> Abraham Alvarez

</AUTEUR>

Auteur: Abraham Alvarez

http://liris.insa-lyon.fr/auteurs/index.xml

Lien XML

Fichier AFichier B

URL du fichier BURL du fichier index

http://liris.insa-lyon.fr/auteurs/alvarez.xml

Sens de la Navigation


<AUTEUR xmlns:xlink="http://www.w3.org/1999/xlink/namespace/" xlink:type="simple"xlink:href="http://liris.insa-lyon.fr/auteurs/alvarez.xml" xlink:title="l'auteur de cette page"> Abraham Alvarez

</AUTEUR>

Auteur: Abraham Alvarez

http://liris.insa-lyon.fr/auteurs/index.xml

Lien XML

Fichier AFichier B

URL du fichier B

Figure 4-5. Représentation d'un lien simple

Les liens de XML ne se limitent pas aux liens simples comme le HTML. Ils

offrent la possibilité de liens étendus beaucoup plus puissants.

2.4.2 Lien de partage d'information (ou de connaissances)

Ce type de lien est représenté grâce à XML en lien étendu. Ce dernier est caractérisé

par sa double direction, c'est-à-dire type « bidirectionnel », étant donné que chaque

ancre est à la fois source et cible du lien.

Un lien de partage d'information permet de mettre en évidence que deux por-

tions de textes contiennent la même information, que ce soit partiellement ou totale-

ment. Un exemple est quand un document fait référence à des exemples d'un autre

document (par exemple, l'instruction "démonter la façade", renvoie à un autre docu-

ment qui détaille le démontage).



La figure 4-6 illustre le lien de référence et le lien de partage d'information

(partiel). On considère dans cette figure un manuel d'utilisation numéro 760112-A,

C'est celui qui correspond aux normes GSM900 et GSM1800, il comporte un premier

lien du type lien de référence, examinons que son ancre d’arrivée se dirige vers le do-

cument B. Un deuxième lien de partage partiel d'information associe un nombre res-

sources, ce lien peut donc être bi-directionnel du document A vers le document C et

vice-versa : dans cet exemple ces documents partageant le paragraphe 2 pour le do-

cument A et le paragraphe 1 pour le document C.

Manuel d'utilisation 760112-A

Le téléphone sans fil décrit dans ce manuel 760112-A, est agréé pour les réseaux GSM 900 et GSM 1800. C.f. la norme GSM 900. Le type de bande de votre téléphone mobile, est une fonctionnalité dépendant du réseau. Votre Nokia 2010 est de type "double bande". Vérifiez auprès de votre opérateur local s'il est possible de vous abonner à cette fonction et de l'utiliser.Voir aussi la norme DCS1800 de type tri-bandes avec une carte à puce intégrée ( SIM ). Classe de puissance - "Les classes de puissance qui existent actuellement sont les suivantes: classe 4 (2 Watt de puissance maximale) utilisée dans les terminaux GSM900 portables; classe 2 (8 Watt de puissance maximale) utilisée dans les terminaux GSM900 …

Norme GSM 900Plusieurs normes coexistent actuellement : GSM900, la plus connue et la plus ancienne, est utilisée par presque tous les opérateurs de portables en Europe. La norme DCS1800 est une évolution du GSM900 avec une meilleure qualitésonore et de nouveaux services. Le système PCS1900 est utilisé aux États-Unis et n'est pas compatible avec les systèmes européens. Il y a des téléphones dual-band et tri-band qui accumulent plusieurs systèmes. En France, la norme GSM900 est utilisée par SFR et France Telecom Mobiles.

Document A

Document C

Document BLien de référence (unidirectionnel)(de document A vers document B)

Carte SIM

Elle est insérée à l'intérieur du téléphone et existe sous deux formats: ISO/Standard (format CB) et PLUG IN (avec les dimensions d'un petit timbre). Il est possible d'utiliser un adaptateur qui permet d'insérer les cartes PLUG-IN dans les appareils qui acceptent les cartes au format ISO.

Carte SIM - La carte SIM contient les informations relatives à l'abonnement au réseau GSM.Lien de partage d’information

partiel (bidirectionnel)Le document A et le document C partagent un paragraphe

Lien de référence


Le téléphone sans fil décrit dans ce manuel 760112-A, est agréé pour les réseaux GSM 900 et GSM 1800. C.f. la norme GSM 900. Le type de bande de votre téléphone mobile, est une fonctionnalité dépendant du réseau. Votre Nokia 2010 est de type "double bande". Vérifiez auprès de votre opérateur local s'il est possible de vous abonner à cette fonction et de l'utiliser.Voir aussi la norme DCS1800 de type tri-bandes avec une carte à puce intégrée ( SIM ). Classe de puissance - "Les classes de puissance qui existent actuellement sont les suivantes: classe 4 (2 Watt de puissance maximale) utilisée dans les terminaux GSM900 portables; classe 2 (8 Watt de puissance maximale) utilisée dans les terminaux GSM900 …

Norme GSM 900Plusieurs normes coexistent actuellement : GSM900, la plus connue et la plus ancienne, est utilisée par presque tous les opérateurs de portables en Europe. La norme DCS1800 est une évolution du GSM900 avec une meilleure qualitésonore et de nouveaux services. Le système PCS1900 est utilisé aux États-Unis et n'est pas compatible avec les systèmes européens. Il y a des téléphones dual-band et tri-band qui accumulent plusieurs systèmes. En France, la norme GSM900 est utilisée par SFR et France Telecom Mobiles.

Document A

Document C

Document BLien de référence (unidirectionnel)(de document A vers document B)

Carte SIM

Elle est insérée à l'intérieur du téléphone et existe sous deux formats: ISO/Standard (format CB) et PLUG IN (avec les dimensions d'un petit timbre). Il est possible d'utiliser un adaptateur qui permet d'insérer les cartes PLUG-IN dans les appareils qui acceptent les cartes au format ISO.

Carte SIM - La carte SIM contient les informations relatives à l'abonnement au réseau GSM.Lien de partage d’information

partiel (bidirectionnel)Le document A et le document C partagent un paragraphe

Lien de référence

Figure 4-6. Illustration d'un document contenant des liens

Parmi les liens de partage, on peut différencier deux types distincts d’après

[Chabbat97] : le partage intégral et partiel. Le premier type de lien relie deux élé-

ments possédant exactement le même texte tandis que le second relie deux éléments

avec un texte différent mais exprimant une information similaire. Ce type de lien re-



quiert l'intervention de l'utilisateur afin d'identifier les portions de texte partageant

une même information.

Une des caractéristiques du lien étendu est qu'il associe un nombre arbi-

traire de ressources qui peuvent être locales ou distantes au lien. Il contient un mé-

lange des éléments suivants, chacun ayant une fonctionnalité précise :

▪ Des éléments de type "resource" qui fournissent les ressources locales au

lien.

▪ Des éléments de type "locator" qui fournissent les ressources distantes au

lien.

▪ Des éléments de type "arc" qui définissent un sens de liaison entre deux res-

sources du lien.

Ce type de lien peut donc être bi-directionnel, multi-directionnel, mais aussi en li-

gne ou hors ligne.

▪ Liens en ligne : Un lien étendu est dit en ligne s'il possède au moins une res-

source locale au lien. L'exemple de la figure 4-7 représente un lien étendu en

ligne. Considérons que ce lien se situe sur la page principale de l'INSA de

Lyon portant sur les liens XML d'adresse "http://www.insa-lyon.fr/etablisse

ments/index.xml". Il permet de lier cette page au réseau national des l'INSA.

http://www.insa-lyon.fr/etablissements/index.xml

http://www. insa-rouen.fr

http://www.insa-rennes.fr

http://www-insa.u-strasbg.fr

Etablissements de l’INSA:établissements

Fichier B

Lien XML

URL du fichierindex


URL du fichier C URL du fichier B

URL du fichier A

Fichier INDEX.XMLFichier A

Fichier C

http://www.insa-lyon.fr/etablissements/index.xml




Etablissements de l’INSA:établissementsEtablissements de l’INSA:établissements

Fichier B

Lien XML

URL du fichierindex


URL du fichier C URL du fichier B

URL du fichier A

Fichier INDEX.XMLFichier A

Fichier C

Figure 4-7. Représentation des liens étendus en ligne



Les liens étendus en ligne ne sont pas les plus intéressants, ceux hors ligne offrent

une souplesse de liaison supplémentaire.

▪ Liens hors ligne : Un lien étendu est dit hors ligne s'il ne possède aucune

ressource locale au lien. L'intérêt des liens étendus est qu'ils peuvent lier

plusieurs ressources sans qu'elles le sachent. Les liens sont en fait stockés

dans un autre fichier. Les liens hors ligne sont donc très utiles dans les cas

suivants :

1. quand le nombre de ressources est élevé, ils permettent une mise à jour

souple et simple des liens entre les ressources, sans avoir à modifier ces

ressources. Ainsi, si des ressources changent de position, seul le fichier

contenant les liens hors ligne a besoin d'être modifié.

2. quand les ressources à lier sont en lecture seule ou inaccessibles, les

liens hors ligne permettent malgré tout de les lier.

3. quand il est coûteux de modifier les ressources pour y ajouter des liens.

Voyons un exemple de lien étendu hors ligne figure 4-8 : Supposons que le lien

étendu en ligne de la figure 4-7 n'existe pas sur la page XML de l'INSA de Lyon

comportant sur les liens XML. Une personne pourrait vouloir lier cette page à d'au-

tres établissements pour la rendre plus complète. Par la même occasion, elle pourrait

aussi lier un des établissements de l'INSA à la page de référence ou page principale,

normalement celle-ci est le fichier index.




BaseDeLiens.XML

Etablissements de l’INSA

Lien XML

Navigation URL du fichier B

URL du fichier A

http://www-insa-lyon.fr

Fichier A

Fichier index

Fichier B

URL du fichier C

Fichier CLiaison bidirectionnelle




BaseDeLiens.XML

Etablissements de l’INSA

Lien XML

Navigation URL du fichier B

URL du fichier A

http://www-insa-lyon.fr

Fichier A

Fichier index

Fichier B

URL du fichier C

Fichier CLiaison bidirectionnelle

Figure 4-8. Représentation des liens étendus hors ligne



Ce lien possède deux types de liaison : une liaison multi-directionnelle de la

page de référence aux pages des établissements, et une liaison bi-directionnelle entre

la page de référence et l'INSA Rouen. Les liens hors ligne sont stockés dans un do-

cument XML particulier séparé des ressources qu'ils lient. Ce document XML est ap-

pelé une base de liens.

Dans le cas de ressources distantes servant d'origine à des liens figurant dans

une base de liens, l'application traitant une de ces ressources devrait pouvoir localiser

la base de liens pour créer le lien. L'idéal serait un mécanisme externe aux ressources

informant l'application sur cette base de liens. Mais cela dépendrait des applications

et reste pour l'instant hypothétique. Néanmoins, une solution interne aux ressources

reste possible par l'utilisation de groupes de liens externes. Un tel groupe de liens

est en fait un lien étendu hors ligne particulier qui pointe vers la base de liens, dont

l'attribut role prend la valeur xlink:external-linkset.

Voici un exemple de groupe de liens externes pointant vers la base de liens

BaseDeLiens.xml, cette technique correspond à l'approche "Hyperbases" (C.f. Sec-

tion 2, chapitre 2).

<GROUP xmlns:xlink="http://www.w3.org/1999/xlink/namespace/"

xlink:type="extended"

xlink:role="xlink:external-linkset">

<BASE xlink:type="locator"

xlink:href=" BaseDeLiens.xml"/>

</GROUP>

Dans le cas de groupes de liens externes chaînés (un groupe de liens faisant

référence à une base de liens contenant elle-même un groupe de liens ...), l'applica-

tion devra choisir le nombre de groupes maximum qu'elle traitera dans la chaîne. En

plus d'un mécanisme de liaison puissant, les liens XML peuvent aussi utiliser le lan-

gage XPointer pour localiser des parties précises de documents XML.



2.4.3 Lien de composition

Le lien de composition, représente la structure hiérarchique de composition d'un do-

cument par des éléments nommés nœuds. Ce type de lien permet d'organiser de façon

hiérarchique des fragments afin de reconstituer, par la suite, un document suivant le

schéma xml ou la DTD à laquelle il est conforme. Ces liens sont unidirectionnels et

sont établis par le système. Ce type de lien est représenté dans la figure 4-9.

TitleManualTitleManual

Section ISection I

ReferenceReferenceBodyBody

RootRootComposition link

ManualManual

URL or file URL or file locationlocation

Voir aussi la norme DCS1800

de type....


Le téléphone sans fil décrit dans ce

manuel …Element

Text

Section IISection II

Le type de bande de votre

téléphone mobile ...

TitleManualTitleManual

Section ISection I

ReferenceReferenceBodyBody

RootRootComposition link

ManualManual

URL or file URL or file locationlocation

Voir aussi la norme DCS1800

de type....


Le téléphone sans fil décrit dans ce

manuel …Element

Text

Section IISection II

Le type de bande de votre

téléphone mobile ...

Figure 4-9 Illustration d'un document contenant des liens

Ces liens constituent le principal moyen d’organiser un système hypertexte.

Ils permettent à l’utilisateur de se déplacer d’un endroit à un autre d’une manière non

séquentielle. Par ailleurs, la gestion de ces liens suppose une gestion de la structure

logique spécifique de la documentation technique. Cette structure devra également

être utilisée pour gérer les différentes versions de ces documents.

Dans la section suivante nous proposons un modèle pour la représentation

des documents XML, leurs liens intra et inter documents et la gestion de leurs ver-

sions.

Dans notre modèle, les documents sont modélisés au travers de trois dimen-

sions : une dimension structure, une deuxième dimension version et une dernière ac-

teurs. La figure 4-10 schématise notre modèle de données.



Enfin, notre modèle prévoit également le stockage des données de chaque

nœud dans le SGBD. Ceci est lié au choix de faire de notre système un système Hy-

perbase où la totalité des informations est gérée par l’application afin de prévenir les

risques d’incohérence liés à des interventions de la part d’auteurs pressés. En effet, se

contenter d’indexer les fichiers pour représenter leurs structures dans la base de don-

nées présente le risque de voir des manipulations effectuées sur les documents qui ne

seraient pas prises en compte et donc compensées par le système à travers la mise en

œuvre de ses règles actives.

3 Modèle de données pour la gestion de liens

Dans cette section, nous nous intéressons uniquement aux propriétés statiques. Ulté-

rieurement, pour les besoins de l'implémentation, nous introduirons les propriétés dy-

namiques dans la section suivante consacrée au modèle de règles. (C.f. Chapitre 5).

3.1 Dimension Structure

Nous avons comme première structure, la structure interne selon

l’organisation classique interne des documents, c’est-à-dire les sections, sous-

sections et autres paragraphes. Lorsque nous parlons d'organisation interne, nous

pouvons citer le concept de structure logique d'un document comme : l’organisation

hiérarchique des données du document, c’est-à-dire une organisation de l’information

qui sous-tend le discours de l’auteur du document. Cette organisation s’établit autour

d’abstractions représentant des parties du document dans le cas classique, un docu-

ment étant composé d’un titre, d’une ou plusieurs sections, elles mêmes composées

d’un titre, d’une ou plusieurs sous-sections. C’est une organisation qui est utilisée

dans la quasi-totalité des documents, et qui est facilement représentée ou réalisée

avec des outils comme Word ou de méta-langages comme XML. Si l’on considère

l’arbre représentant cette thèse, les modifications peuvent se traduire par des créa-

tions, des suppressions et des déplacements de nœuds, ainsi que par des mises à jour

du contenu textuel des feuilles.



Nous avons également une organisation non linéaire à travers un réseau de

liens, que nous appelons par analogie à hyperliens, hyperstructure. Cette dernière est

représentée dans notre modèle par les entités element, lien et URL qui constituent

l'hyperstructure, c’est-à-dire que nous serons capables de représenter la structure d'un

document dit Hypertexte. Dans l'entité element deux types d'éléments sont considé-

rés; l'élément composé et l'élément composite. Plusieurs éléments peuvent en compo-

ser un autre, l'élément composé est de type composite, sinon il est considéré comme

élémentaire. Les éléments de type multimédia (images, vidéo, etc.) sont représentés

dans la classe qui est séparée pour des raisons de stockage. Pour les liens, nous

considérons un lien comme un élément de type lien avec les attributs type de lien.

Les valeurs possibles pour cet attribut sont : simple, étendu, bidirectionnel, statut du

lien. Le contenu du lien est stocké dans la classe nommée URL. Cette classe a été dé-

composée selon la syntaxe d’une URL.

La syntaxe générale d'une URL est très spécifique, cela est défini par le

Network Working Group [RFC1738]. L'entité URL désormais peut être instanciée

avec les éléments que constituent la syntaxe de l'URL. L'exemple suivant l'illustre :

protocol ://hostname/chemin/nom fichier#pathsection

http:// lisi.insa-lyon.fr/~aalvarez/index.xml#section1

Nous avons choisi de formaliser notre modèle de données en utilisant la

notation UML. La figure 4-10 schématise cette première dimension.



1..*

URL

id_urlprotocolhostNamepathNamefile_Name

Multimedia

id_mdesc_mcontenu_m

Lien

id_lientype_de_lienstatut_du_lien

1..* 1..1

un lien se dirige vers

Element

id_eletype_elenom_tag

plusieurs éléments peuvent en composer

un autre

un type d'élément peut être du type multimédia

0..*

0..*

un type d'élément contient

1..1

1..*

Cache_URLs

id_aliasdate_aliasURL

1 .. *

1..1

a document est formé de

1..1

un document peut référencer vers un

Documentid_doc

titre_doc

type_doc

auteur_docmots_clesdep_emebalise_xml

creer_doc()modifier_doc()supprimer_doc()deplacer_doc()rename_doc()notifier_doc()

etat_doc

transmettre_doc()

Auteurs

id_auteurnom_auteurauteur_type

demander.creation()demander.modification()demander.suppression()demander.lecture()demander.transmission()valider.etape()demander.changement etat()

un document peut être créepar plusieurs auteurs

1..1 1..*

1..*

URL

id_urlprotocolhostNamepathNamefile_Name

Multimedia

id_mdesc_mcontenu_m

Lien


1..* 1..1


Element


plusieurs éléments peuvent en composer

un autre

un type d'élément peut être du type multimédia

0..*

0..*

un type d'élément contient

1..1

1..*

Cache_URLs


1 .. *

1..1

a document est formé de

1..1

un document peut référencer vers un

Documentid_doc

titre_doc

type_doc



etat_doc

transmettre_doc()

Auteurs




1..1 1..*

Figure 4-10 Représentation de la dimension structure

3.2 Gestion des Versions

Pour les systèmes de GED l'approche de versions est un atout indéniable, car la ges-

tion de versions permet de proposer une alternative au problème de la cohérence des

documents. Cette approche permet à l'utilisateur d'avoir une traçabilité et/ou un histo-

rique de tous les mouvements effectués sur un document, c'est-à-dire les différentes

versions du document.

Les documents que nous considérons sont donc évolutifs, liés les uns aux au-

tres, et leur évolution dépend du temps. Afin de restituer un ensemble de documents

cohérents à un utilisateur, il est donc nécessaire de conserver l'historique des docu-

ments (par le biais des versions) ainsi que celui des liens (en les versionnalisant).

La figure 4-11 illustre en détail l'approche gestion des versions de documents

et des fragments.



1..*

URL

id_urlprotocolhostNamepathName

fileName

Version_d_element

id_vers_elenumero_vers_eledate_vers_ele

contenu_elemodificateur_ele

Multimedia

id_m

desc_mcontenu_m

Lien


0..1

1..1un lien point vers un version

1..* 1..1


Element


plusieurs éléments peuvent en composer un autre

1..1

1..*

1..1un élément point vers

0..*

un type d'element peut être du type multimédia0..*

1.. *

un type d'elementcontient

Version_du_document

id_vers_doc

numero_vers_doctype_vers_doc

date_vers_docstatut_vers_docmodificateur_doc

1 .. 1

1..*

une version est formée de

Cache_URLs


1..1

a document peut contenir

1 .. *

1..1un document peut référencer vers un cache

Documentid_doc

titre_doc

type_doc



etat_doc

transmettre_doc()

Auteurs




1..1 1..*

1..*

URL

id_urlprotocolhostNamepathName

fileName

Version_d_element

id_vers_elenumero_vers_eledate_vers_ele

contenu_elemodificateur_ele

Multimedia

id_m

desc_mcontenu_m

Lien


0..1

1..1un lien point vers un version

1..* 1..1


Element


plusieurs éléments peuvent en composer un autre

1..1

1..*

1..1un élément point vers

0..*

un type d'element peut être du type multimédia0..*

1.. *

un type d'elementcontient

Version_du_document

id_vers_doc

numero_vers_doctype_vers_doc

date_vers_docstatut_vers_docmodificateur_doc

1 .. 1

1..*

une version est formée de

Cache_URLs


1..1

a document peut contenir

1 .. *

1..1un document peut référencer vers un cache

Documentid_doc

titre_doc

type_doc



etat_doc

transmettre_doc()

Auteurs




1..1 1..*

Figure 4-11 Représentation du modèle pour la représentation de documents et leurs

versions

Dans notre modèle, deux niveaux des versions sont distingués :

Version du document : une version qui porte sur la structure et le

contenu du document. Si l'on considère l'arbre représentant ce docu-

ment, ces modifications peuvent se traduire par des créations, des sup-

pressions et des déplacements de nœuds, ainsi que par des mises à jour

du contenu textuel des feuilles.

Version d'élément et/ou fragment : Une deuxième gestion des ver-

sions, plus fine, se situe au niveau de ses éléments (nœuds). Chaque

nœud possède sa propre version et appartient à une version du docu-

ment. Chaque nœud est ainsi caractérisé par un ensemble de versions



indiquant sa position dans l’arbre et son contenu à une date donnée.

Ces nœuds sont dits multi-versions. Un nœud multi-version contient

donc l’ensemble de ses versions successives ordonnées dans le temps.

Enfin, en ce qui concerne la gestion des versions de documents, nous consi-

dérons dans notre modèle que pour chaque document il existe une ou plusieurs ver-

sions du document. Ensuite, chaque version du document est composée d’éléments, et

des versions des éléments, c'est-à-dire que chaque élément possède sa propre version

et appartient à une version du document. En revanche, nous ne pouvons pas autoriser

des modifications uniquement sur la dernière version d’un document.

3.2.1 Versions des fragments

La gestion simultanée des versions et des liens pour les documents structurés

implique introduire la notion de contexte estampillé. Un contexte estampillé est un

ensemble de documents valides et/ou cohérents techniquement parlant, à une date

donnée. La validité des documents s'entend selon leur validité donnée par le rédac-

teur, c'est-à-dire que leur contenu est applicable à la date considérée.

La figure ci-après illustre un exemple de contexte estampillé, selon le temps.

L'exemple ne prend en compte qu'un seul document, mais en réalité, un contexte es-

tampillé peut contenir plusieurs documents, chacun dans une version donnée.

f1V0 f2V0 f3V0 f4V0

f5V0

f3V1 f4V1f2V1f1V0

f5V0

Nouvelle version de fragment

f1V0 f2V1 f3V1

f4V1 f5V0

f1V0 f2V1 f3V2

f4V2 f5V0

f1V0 f2V0 f3V0

f4V0 f5V0

f3V2 f4V2f2V1f1V0

f5V0

Version 1 du document

Version 0 du

document

Version 2 dudocument

f1V0 f2V0 f3V0 f4V0

f5V0

f3V1 f4V1f2V1f1V0

f5V0

Nouvelle version de fragment

f1V0 f2V1 f3V1

f4V1 f5V0

f1V0 f2V1 f3V2

f4V2 f5V0

f1V0 f2V0 f3V0

f4V0 f5V0

f3V2 f4V2f2V1f1V0

f5V0

Version 1 du document

Version 0 du

document

Version 2 dudocument

Figure 4-12 Exemple de contexte estampillé.



Dans l'exemple de la figure 4-12, nous considérons un document D en version 0

comme le point de départ. Notre document est constitué de cinq fragments, tous en

version 0. Ensuite, le document va évoluer, c'est-à-dire avoir des modifications :

Le fragment 2 va passer en version 1 ;

Le fragment 4 va passer en version 1 lui aussi. Étant donné que le

fragment 4 a pour parent le fragment 3, l'évolution de version de f4 en-

traîne l'évolution de version de son parent f3. De même pour la suite, le

passage en version 2 de f4 entraîne à nouveau la création d'une nouvelle

version pour f3. On obtient alors trois contextes différents, à l'intérieur

desquels le document est constitué d'un ensemble cohérent de versions

de fragments.

Un contexte estampillé est un ensemble de documents à une date donnée,

donc il est un ensemble de versions de documents, donc un ensemble de versions de

fragments, à une date précise. Un contexte estampillé va donc permettre à un utilisa-

teur de consulter un ensemble de documents à une date demandée.

3.2.2 Incidences des mises à jour

La modification d'un document entraîne, généralement, la création d'une nouvelle

version. Comme nous l'avons vu précédemment, cela implique la vérification voire la

modification des liens associés aux fragments mis en cause dans la modification.

Ajout d'un fragment. Lors de l'ajout d'un fragment, les premiers liens

à mettre en place sont les liens de composition. En effet, avant toute

autre liaison, le fragment doit être rattaché à un fragment (excepté s'il

s'agit de la racine), devenant ainsi partie de document. L'ajout d'un

fragment dans un document entraîne évidemment la création d'une nou-

velle version pour ce document, ainsi que pour les fragments parents de

celui ajouté. Les autres types de liens peuvent ensuite être ajoutés.

Modification du contenu d'un fragment feuille. Lorsque le contenu

textuel d'un document est à modifier, c'est un des fragments feuilles

dudit document qui est à modifier. Une nouvelle version de ce fragment



est alors créée. Cette création est propagée jusqu'à la racine du docu-

ment, entraînant une nouvelle version du document lui-même. Les dif-

férents liens qui ont pour ancre le fragment modifié doivent être contrô-

lés et éventuellement invalidés.

Suppression d'un fragment. Il est possible qu'un fragment soit à sup-

primer d'un document. Cette suppression ne peut être que logique, et

non pas physique, étant donné la gestion de versions.

3.2.3 Instanciation du modèle de données

Exemple d'un extrait du fichier XML

À titre d'illustration, voyons comme un fichier du type xml est instancié dans notre

modèle de données. Tout d'abord commençons à instancier la table nommée « Do-

cument », cette table est instanciée de façon indépendante des autres tables. Instanciation de la table « Document » <?xml version="1.0" encoding="ISO8859-1"?>

<Titre>Specifications techniques de la carte Etherlink XL</Titre>

Id_doc titre_doc type_doc etat_doc auteurs_doc mots_cles dep_eme balise_xml 0010 Specifications

techniques de la carte Etherlink XL

man en cours de rédaction

10, 15, 8 Etherlink, 802.3, 802.3u

fabrication ?xml version="1.0" en-coding="ISO8859-1"?

<?xml version="1.0" encoding="ISO8859-1"?> <Specifications> <Titre>Specifications techniques de la carte Etherlink XL</Titre> <Section> <Titre_section>1. Normes</Titre_section> Media: 10BASE-T/100BASE-TX, Connectors: RJ-45,Bus: 32-bit PCI, Operating distance (10BASE-T):

Category 3/4/5 UTP to 100m (328ft).IEEE compliance: 802.3, 802.3u, 802.2, 802.1p, 802.1Q, 802.1... </Section> <Section> <Titre_section>2. Systeme requis</Titre_section> PCI 2.1 or 2.2 compliant PC NIC, Remote wake up cable, either CDROM with Dynamic Acces … <Image xlink:href="images\lan_card.jpg"/> <Lien xlink:href="demarrage_rapide_etherlink.xml">Guide de demarrage rapide</Lien> </Section> </Specifications>



Instanciation de la classe « Version_du_document »

Id_vers_doc Numero_vers_doc Type_vers_doc date_vers_doc Statut_vers_doc Modificator_doc 0010 1 Nouveau document 01.10.2003 En cours de redaction nulle

Instanciation des classes « element, et Version_d_element »

<Section> élément 1 <Titre_section>1. Normes</Titre_section> élément 2 Media: 10BASE-T/100BASE-TX, Connectors: RJ-45, Bus: 32-bit PCI, Operating distance (10BASE-T):

Category 3/4/5 UTP to 100m (328 ft).IEEE compliance: 802.3, 802.3u, 802.2, 802.1p, 802.1Q, 802.1... </Section> <Section> élément 3 <Titre_section>2. Systeme requis</Titre_section> élément 4 PCI 2.1 or 2.2 compliant PC-NIC, Remote wake up cable, either CDROM with Dynamic Acces … <Image xlink:href="http:\liris.insa-lyon.fr\images\lan_card.jpg"/>carte reseau élément 5 <Lien xlink:href="="http:\liris.insa-lyon.fr\lan\d_rap.xml"> élément 6 Guide de demarrage rapide</Lien> </Section>

Instanciation de la classe « Element » Instanciation de la classe «Version_d_element »

Id_ele Type_ele

Nom_tag Id_vers_ele

Nu-mero_vers_ele

Date_vers_ele

contenu_ele

001 c Section 001 01 01.10.2003 Media: 10BASE-T/100BASE-TX, Connectors: RJ,Bus: 32-bit PCI, Operating distance (10BASE …

002 s Titre_section 002 01 01.10.2003 1. Normes

003 c Section 003 01 01.10.2003 PCI 2.1 or 2.2 compliant PC-NIC, Remote wake up cable …

004 s Titre_section 004 01 01.10.2003 2. Systeme requis

005 s Image xlink:href 005 01 01.10.2003 nulle

006 s Lien xlink:href 006 01 01.10.2003 Guide de demarrage rapide

Instanciation de la classe « multimedia » Instanciation de la classe «Lien »

Id_m desc_m contenu_m Id_lien type_de_lien

statut_du_lien

001 carte reseau ordimge 001 TS Valide

002 TS Valide

Instanciation de la table « URL »

id_url protocol hostname pathName fileName 001 http liris.insa-lyon.fr images lan_card.jpg

002 http liris.insa-lyon.fr lan d_rap.xml

Notons dans cet exemple l'existence de deux éléments de type <<section>>, ils sont composés de six fragments, le fragment 2 et correspondent aux titres des éléments. Le contenu de chaque élément est stockée dans la table de version_d_element, donc la table Element et version_d_element sont associées par l'dentifiant id_ele et id_vers_ele. Également les liens sont instanciées dans deux tables: dans la table liens on stocke le type de lien et son statut, et dans la table <<URL>> les éléments composants d'un lien sur la forme : protocol ://hostname/chemin/nom_fichier.



3.3 Acteurs

Définir des acteurs permet surtout de trouver le cas d'utilisation (par exemple

un rédacteur, un lecteur, un utilisateur, etc.) Mais elle peut aussi être utilisée pour :

définir différents points de vues sur le système,

déterminer des droits d'accès par type d'acteur, etc.

Un acteur est un élément externe qui interagit avec le système. L'acteur

prend des décisions, des initiatives, bref il est actif. L'ensemble des acteurs partici-

pants dans notre modèle sont représentés dans la figure 4-13.

ré da c teu r e n ch ef

( f rom Ac t ors )

c ré e r u n n o u ve a u d o cu m e n t a p p ro u ve r d ocu m e n t

ré v ise r d o cu m e n t

va l i d e r é ta p e

ch a n g e m e n t d 'é ta p e

ré d a cte u r d u typ e e xp e rt

ré d a cte u r d u typ e co rre c te u r

a rch i ve r d o cu m e n t

A d m i n i stra te u r d u sy stèm e d e G E D

C yc l e to ta l d e v i e d 'u n d o cu m e n t

é q u i p e d e systè m e d e p rod u cti o n

d i ffu se r d o cu m e n t

Figure 4-13 Représentation des acteurs

Il existe trois types d'acteurs : les experts qui rédigent les documents, les cor-

recteurs qui corrigent les épreuves du document, et les lecteurs qui consultent des

documents. L'administrateur du système crée et met à jour la structure de la base do-

cumentaire, gère les évolutions fonctionnelles et techniques, définit les accès et veille

au respect des règles de sécurité et de protection des données, est garant de la cohé-

rence et du bon fonctionnement global.

Nous constatons que tous ces éléments sont organisés selon un modèle objet

de document (DOM), cela va nous permettre de décomposer et représenter le docu-



ment sous une forme arborescente et par la suite de reconstituer correctement le do-

cument.

3.4 Formalisation du modèle

3.4.1 Formalisation des documents

Il est possible de formaliser la représentation d'un document. En terme de modélisa-

tion, nous considérons qu'un document est constitué d'un ensemble des fragments

et/ou éléments non décomposables.

Une représentation formelle pour un document D est :

D = ({fD = ({f1, f, f2, f, f3 … f… fn}V}Vd)) D : Document représente le document auquel un fragment ou fragment(s)

sont rattachés.

f : Fragment = <t,type, м,Vf,Vd,D, {ffils}|cont> représente un fragment de document.

t : nom du tag représente un type caractéristique du fragment. Par exemple : titre, section, lien, image, etc.

type : C, E détermine si le composant est encore décomposable ou non. C pour composite et/ou E pour élémentaire.

м : média les types sont (texte, vidéo, image.)

ffils : Fragment ensemble des fragments fils du fragment

Vf : Version = <num, cdate > indique la version de fragment

num : N numéro de la version

cdate : date date de création de la version

cont contenu du fragment

Vd : version = <num, cdate > indique la version de document

num : N numéro de la version

cdate : date date de création de la version

Un Fragment possède :

un tag ou type de balise qui vient du mot tag au sens XML du terme;

(par exemple un nom d'étiquette peut être : <titre>, <section>, <lien>,

<image>, <sous-section>, etc.) ce qui permet de réaliser des recherches

sur la structure du document.



un type, qui permet de déterminer, pour chaque fragment de D, si le

composant est encore décomposable ou non. C'est-à-dire si le type du

fragment est : composite ou élémentaire.

une version, contenant à la fois un numéro de version et la date à la-

quelle cette version a été créée.

une version de document, afin de savoir à partir de quelle version du

document cette version de fragment doit être considérée. Il est possible

de ne prendre en compte que les dates de version, les numéros de ver-

sion pouvant se déduire facilement des dates de création.

une liste de fragments fils ou bien d'un contenu textuel. La liste de

fragments fils permet de connaître les fragments dont celui considéré

est le père hiérarchiquement parlant, et le contenu textuel marque un

élément feuille de l'arbre Document qui, comme son nom l'indique,

présente une partie du contenu textuel du Document.

un type de média (texte, vidéo, image, etc.)

la version du document auquel le fragment est rattaché.

Nous ferons une distinction particulière entre :

les fragments ayant uniquement du contenu textuel ou multimédia, qui

sont les feuilles de l’arbre du document, et

ceux qui constituent des nœuds (il faudra pour cela, lors de toute mani-

pulation, s’intéresser à leur descendance). Néanmoins, un document

peut être vu comme un fragment particulier, étant donné qu'il corres-

pond à l'élément racine d'un texte.

Une création de version commence toujours, dans notre étude, par la création

d'une nouvelle version d'une feuille de l'arbre. Cette création est ensuite propagée

jusqu'à la racine de l'arbre, entraînant ainsi la création d'une nouvelle version pour le

document lui-même.



3.4.2 Formalisation des liens

Lors de la formalisation des documents, un autre aspect a dû être étudié à savoir la

formalisation des liens [Karl97, Davis95, Nadalin94, ACH93, HHD93]. Pourtant, il

est nécessaire de formaliser aussi bien les liens que les documents.

Un lien a, par définition les caractéristiques suivantes :

un identifiant,

un type (dans notre cas, le type sera "référence", "partage d'information",

"composition")

une référence à son ancre "source",

une référence à son ancre "cible",

un paramètre de similarité en cas de lien de partage d'information,

une date de création.

Ces informations permettent d'utiliser par la suite un lien, à partir d'une date

donnée (celle de sa création), entre deux fragments de documents. Ces fragments

peuvent appartenir à un même document (lien intra-document) ou bien à deux docu-

ments distincts (lien inter-documents).

3.4.3 Versions des liens

Ne pas tenir compte de l'évolution des liens équivaudrait à perdre les traces (histori-

que) des liaisons entre les éléments. Si un élément "A" est relié à un élément "B" et si

la destination de l’élément "A" est changée en faveur de l’élément "C" alors l'an-

cienne destination de "A" est irrémédiablement perdue. Inversement, une gestion des

versions uniquement orientée liens introduira des problèmes d'ambiguïté : si, dans

l'exemple précédent, on garde la liaison A-B, il y a situation de concurrence entre le

lien menant vers "B" et le lien menant vers "C". Une solution est la gestion des ver-

sions des liens. Le nouveau lien de "A" vers "C" entraînera la création d'une nouvelle

version, ce lien passe de la version 1 à la version 2. La dernière version est la version

active. Nous pouvons faire référence à la section précédente pour illustrer la gestion

de versions de liens étant donné que dans notre modèle un lien est considéré comme

un élément du type lien ou bien un fragment.



Lorsque l'on introduit la notion de version avec les liens, il nous faut prendre

en compte le fait qu'à une date donnée, un lien va relier deux versions : celle de sa

source et celle de sa cible. A une autre date, les numéros de versions des fragments

ancres peuvent être différents. Néanmoins, une même version du lien peut être utili-

sée à plusieurs dates différentes, avec des fragments associés de versions différentes,

suivant l'évolution de ce dernier fragment.

De plus, un lien peut être momentanément invalidé. Il faut par conséquent

être capable d'indiquer au système (ainsi qu'à l'utilisateur) qu'il est impossible d'utili-

ser le lien à telle date. C'est pourquoi nous ajoutons la propriété suivante à la descrip-

tion d'un lien :

Une liste de triplets : (date, vnum_source, vnum_cible) date correspond à la date à partir de laquelle le couple qui suit doit être

utilisé

vnum_source correspond au numéro de la version de l'ancre source à consi-

dérer lors de l'utilisation du lien

vnum_cible correspond au numéro de la version de l'ancre cible à considé-

rer lors de l'utilisation du lien

Si l'on considère la formalisation précédemment émise, nous pouvons la

compléter par celle des liens versionnalisés. l : Liens = <t,dc,s,c,vv> représente le lien

t : {référence, partage d'in-

formation, composition} représente le type du lien

dc : Date date de création du lien

s : Fragment "source" du lien

c : Fragment "cible" du lien

vv = {(datevv, nums, numc)} ensemble des versions valides des ancres

datevv : Date date de début de prise en compte du couple de versions des ancres associé

nums : N numéro de la version de l'ancre "source" à prendre en compte

numc : N numéro de la version de l'ancre "cible" à prendre en compte

Si nums et numc sont à 0, cela signifie que le lien est invalide à partir de la

date associée à ce couple de versions d'ancres.



3.5 Description des classes du modèle

« Classe Document » Il s’agit d’un document au sens large. Toutes les versions, dans chaque partie d’un même document, géné-rées au fil du temps seront rattachées à cette entité. C’est aussi à cette entité que sont rattachés les rensei-gnements complémentaires utiles et généralement disponibles sur tout système : type de document, auteurs, mots-clefs, etc.

« Attributs » Les attributs titre_doc, type_doc, auteurs_doc, mots_cles, dep_eme sont des renseignement complémentai-res, qui sont mis ici à titre informatif. Ils n’ont pas d’utilité pour la gestion de la cohérence des liens mais ont vocation à être pris en charge par notre système.

Nom Attribut Type de donnée

longueur Libellé

id_doc numérique 10 C’est l’identifiant du document

titre_doc, alphanumérique 25 Décrit le nom du document et est de type alphanumé-rique.

type_doc,

alphanumérique 4 Ce champ de type alphanumérique sert à identifier un type de document. Quelques exemples de types de documents sont : le type manuel : MAN, le type catalogue : CATA, le type brevet : BRE, le type procédures : PROCE, etc.

etat_doc alphanumérique 30 Détermine l'état actuel qui porte un document. Quel-ques exemples d'états de documents sont : en cours de rédaction révisé, corrigé approuvé, etc.

auteurs_doc, list 25 C'est une liste de tous les auteurs ayant le droit de participer dans le cycle de production des documents.

mots_cles, alphanumérique 50 Les mots clés sont des champs permettant une re-cherche rapide sur un document.

dep_eme alphanumérique 25 Il s'agit du département concerné par l'émission ou la responsabilité du document.

balise_xml alphanumérique 30 La balise XML est l’élément qui signale la version d’xml référencée, la police de caractères, et d’autres informations de ce type : c’est la balise d’ouverture généralement située en tête de fichier

« Méthodes » creer_doc,modi-fier_doc,supprimer_doc deplacer_doc, rename_doc

Ce sont les opérations qu’un utilisateur peut faire sur un docu-ment. Elles sont ensuite prises en charge par notre système afin de maintenir l’intégrité de la base de documents.

notifier_doc Lorsque des modifications sont faites à l’intérieur du document, le document en est notifié

« Classe Auteurs» Cette classe représente les auteurs. La notion d’auteur est représentée au niveau du modèle de données pour qu’il soit possible de leur attribuer ou non des droits spécifiques pour les manipulations aux documents.

« Attributs » Nom Attribut Type de

donnée longueur Libellé

Id_auteur alphanumérique 15 Chaque auteur est identifié par un identifiant unique.



nom_auteur alphanumérique 40 Il ne s’agit que d’un rappel de l’identité de l’auteur, de manière à ce que l’on puisse le retrouver si on veut savoir qui a participé lors de la création du do-cument.

auteur_type alphanumérique 30 Pour ce champ, il existe trois types d'auteurs : 1.- Les experts qui rédigent les documents 2.- Les correcteurs qui corrigent les épreuves du do-

cument 3.- Les lecteurs

« Méthodes » demander.creation, deman-der.modification, deman-der.suppression, deman-der.lecture, demander.transmission, de-mander.changement, et vali-der.etape

Ces méthodes décrivent les possibles manipulations qu'un auteur ou un groupe d'auteurs peuvent réaliser sur un document. Ces manipulations sont liées aux événements que se produisent.

Classe « Element » C’est l’unité de base du document, le nœud de l’arbre du document où peuvent être attachés d’autres élé-ments (éléments composites), et/ou du contenu (texte ou multimédia).



id_ele numérique 10 C’est l’identifieur de l’élément

type_ele alphanumérique 2 Ce champ permet de déterminer le type d’élément : composite ou simple, contenu texte et/ou multimédia

type_vers_doc alphanumérique 2 Ce champ permet d'identifier la raison pour laquelle a été créée une nouvelle version. Ce peut être des mi-ses à jour importantes de contenus, identifiées par (MS), des suppressions de contenus (SU), des ajouts de nouvelles sections (AJ), et ainsi de suite. Un exemple de ce type est : lorsque l'utilisateur a modifié un élément, le système doit créer soit auto-matiquement soit par demande explicite de l’utilisateur, une nouvelle version.

nom_tag alphanumérique 30 Il s’agit bien ici du nom de tag au sens XML du terme. Notons par ailleurs que les attributs non gérés par le système (ceux liés aux liens ou aux contenus multimédias) sont conservés à cet endroit

Classe « Version_du_document » Les versions de documents sont formées d’une séquence d’éléments. Toute modification de cette séquence conduit à la création d’une nouvelle version du document. Seules des modifications internes aux éléments peuvent ne pas conduire à la création d’une nouvelle version. C’est alors l’auteur qui prend la décision.



id_vers_doc numérique 10 C’est l’identifieur de la version du document

numero_vers_doc numérique 6 C’est le numéro de version du document, à ne pas confondre avec l’identifiant de version du document. Il peut exister plusieurs versions du document ayant



comme numéro de version 2, pour des documents dif-férents. Alors que l’identifiant est unique.

type_vers_doc alphanumérique 25 Il s’agit du type de version (relativement à la version précédente). Ce peut être des mises à jour importan-tes de contenus, des suppressions de contenus obso-lètes, des ajouts de nouvelles sections, etc.

date_vers_doc date La date de création de cette nouvelle version. Un uti-lisateur désireux d’obtenir des informations sur un produit ou des renseignements dans un document se référera en priorité à la date pour sa recherche plutôt qu’a un numéro de version. Le système sera capable de lui proposer tous les documents mis à jour à cette date.

statut_vers_doc alphanumérique 30 Précise l'état actuel de la version du document. Plu-sieurs états sont considérés : En cours de rédaction, Brouillon, En cours de finalisa-tion, Corrigé, Final, Transmis. Si un auteur décide de la création d’une nouvelle ver-sion, celle-ci est créée et modifiée au fil de ses édi-tions, tout en n'étant pas encore validée. Par la suite, l’auteur satisfait valide et « fige » sa version. Toute nouvelle édition entraîne alors la création d’un nou-veau document.

modificateur_doc alphanumérique 30 Ce champ permet de connaître l’auteur qui a fait des changements sur ce document par rapport à la ver-sion précédente

Classe « Version_d_element » C’est la version d’élément qui détient l’éventuel contenu texte du nœud. Cela permet d’éviter la création d’une nouvelle version du document chaque fois qu’un auteur retouche un texte. En effet, cela ne se produi-ra pas car si le contenu est changé, seule une nouvelle version de l’élément est créée. La version du docu-ment est constituée d’éléments et non pas de versions d’éléments.



id_vers_ele numérique 10 C’est l’identifieur de la version d’élément.

numero_vers_ele numérique 6 C’est le numéro de version de l’élément, à ne pas confondre avec l’identifieur de version d’élément.

date_vers_ele date La date de création de cette nouvelle version. C’est grâce à elle que l’utilisateur qui consulte les docu-ments obtient des documents à jour pour une date donnée.

contenu_ele CLOB Le contenu texte de l’élément.

modificateur_ele alphanumérique 30 Ce champ permet de connaître l’auteur qui a fait des changements sur ce document par rapport à la ver-sion précédente.



Classe « Lien » Les liens sont une spécialisation des éléments. L’élément, qui est aussi un lien, peut avoir comme tous les autres éléments, du contenu texte ou du contenu multimédia (comme dans le cas d’une image sur laquelle on clique et qui dirige vers une nouvelle page, en html). Un lien désigne en revanche une ou plusieurs ver-sions d’éléments. Cela peut être une (ou des) version(s) d’éléments racines du document dans le cas d’un lien désignant un document entier sans plus de précisions. Cela peut également être un élément de l’arbre du document, dans le cas d’un lien désignant un paragraphe ou une sous section, interne ou externe.

« Attributs » Nom Attribut Type de don-

née longueur Libellé

id_lien numérique 10 C’est l’identifieur du lien.

type_de_lien

alphanumé-rique

30 Quand on parle de liens, on parle aussi de types. Par exemple : Type simple interne :TSI, Type étendu (TE), Type simple externe :TSE, Type utilisateur (TU)

statut_du_lien alphanumé-rique

40 Lors de la suppression d’un élément, si celui-ci est désigné par un lien, un auteur peut choisir de l’invalider. C’est un état « provisoire » qui peut servir à attendre la création d’une nouvelle cible pour le lien.

url Table_url

Ce sont les URL des éléments liés. Elles sont stockées dans une table imbriquée car il peut y en avoir plu-sieurs. Note : le type Table_url est un type que nous avons défini.

« Classe Multimedia » Les éventuels contenus multimédia des éléments sont conservés dans cette entité a part. Ces contenus mul-timédia seront stockés dans la base, sous forme de BLOB par exemple, pour éliminer les risques de modifica-tions non prises en charges par le système.



id_m numérique 6 C’est l’identifieur de l’élément multimédia.

desc_m alphanumérique 30 description du contenu muiltimédia (image, audio, vi-déo, …) et format.

Contenu_m ordimage il s’agit du contenu lui-même, sous forme d’un bloc binaire.

4 Conclusion

Nous avons présenté en détail la partie concernant la modélisation des don-

nées. Notre modèle a été conçu selon trois dimensions : de la structure, des versions

et finalement des auteurs. Ces trois dimensions permettent de représenter les docu-

ments, leurs liens et les versions avec une représentation au niveau élément du docu-

ment). Également la formalisation des documents, des liens et des versions des liens

a été abordée.