216
N˚d’ordre : 2009-ISAL-0100 Ann´ ee 2009 TH ` ESE pr´ esent´ ee devant L’INSTITUT NATIONAL DES SCIENCES APPLIQU ´ EES DE LYON pour obtenir LE GRADE DE DOCTEUR ´ ECOLE DOCTORALE : INFORMATIQUE ET MATHEMATIQUES SP ´ ECIALIT ´ E : INFORMATIQUE par Ovidiu VASUTIU Ing´ enieur en Informatique GESTION DES CONNAISSANCES POUR LA MA ˆ ITRISE DE LA RELATION ENTRE PATRIMOINE DOCUMENTAIRE ET SYST ` EME D’INFORMATION Soutenue le : 3 d´ ecembre 2009 devant la Commission d’examen Composition du jury : Rapporteurs : Eric Gaussier (Professeur) Ioan Roxin (Professeur) Examinateurs : Youssef Amghar (Professeur) David Jouve (Encadrant Cnedi de Lyon) Pierre Maret (Professeur) Jean-Marie Pinon (Professeur) Invit´ e: Jacques Faveeuw (Ancien Directeur Cnedi de Lyon)

Gestion des connaissances pour la maîtrise de la relation ...theses.insa-lyon.fr/publication/2009ISAL0100/these.pdf · Je remercie vivement M. Ioan Roxin et M. Eric Gaussier pour

Embed Size (px)

Citation preview

N d’ordre : 2009-ISAL-0100 Annee 2009

THESE

presentee devant

L’INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON

pour obtenir

LE GRADE DE DOCTEUR

ECOLE DOCTORALE : INFORMATIQUE ET MATHEMATIQUES

SPECIALITE : INFORMATIQUE

par

Ovidiu VASUTIU

Ingenieur en Informatique

GESTION DES CONNAISSANCES POUR LA

MAITRISE DE LA RELATION ENTRE

PATRIMOINE DOCUMENTAIRE ET

SYSTEME D’INFORMATION

Soutenue le : 3 decembre 2009 devant la Commission d’examen

Composition du jury :

Rapporteurs : Eric Gaussier (Professeur)

Ioan Roxin (Professeur)

Examinateurs : Youssef Amghar (Professeur)

David Jouve (Encadrant Cnedi de Lyon)

Pierre Maret (Professeur)

Jean-Marie Pinon (Professeur)

Invite : Jacques Faveeuw (Ancien Directeur Cnedi de Lyon)

Mise en page avec la classe thloria.

Remerciements

Je remercie M. Alain Folliet, Directeur du Systeme d’Information, pour m’avoir

accueilli a la Caisse Nationale des Allocations Familiales afin de participer aux projets de

la Direction du Systeme d’Information.

J’exprime ici toute ma reconnaissance a M. Jacques Faveeuw, ancien Directeur du

Centre National d’Etudes et de Developpement Informatique - Cnedi Rhone-Alpes, pour

avoir lance, encourage et soutenu pendant des nombreuses annees cet ambitieux projet de

recherche auquel cette quatrieme these apporte sa contribution.

Qu’il trouve ici l’expression de ma sincere gratitude pour ses conseils precieux et

pour son accompagnement jusqu’au bout en relisant mon manuscrit et en participant au

jury de la soutenance. Je le remercie aussi pour avoir su me transmettre cette passion et

cette fierte de travailler pour la Branche famille de la Securite Sociale.

Je remercie aussi M. Bertrand Hurel, Directeur du Centre National d’Etudes

et de Developpement Informatique - Rhone-Alpes, et M. Cyrille Broilliard, Responsable

du Secteur Informationnel, pour m’avoir offert la possibilite de realiser mes travaux de

recherche au sein du Cnedi Rhone-Alpes et pour avoir tout mis en oeuvre afin de creer

les conditions necessaires a la reussite de cette these et a la concretisation de mon projet

professionnel. Je leur adresse mes remerciements pour tous nos echanges et pour leurs

remarques et leurs observations interessantes.

Je remercie egalement M. Guy Audibert, Directeur du Centre Regional de Trai-

tement de l’Information Rhone Alpes et Auvergne, pour toute l’attention et tout l’interet

qu’il a porte a mes travaux de recherche.

Je remercie vivement M. Ioan Roxin et M. Eric Gaussier pour l’honneur qu’ils

m’ont fait en acceptant d’etre rapporteurs de cette these et pour toutes les remarques

constructives qu’ils ont formulees sur mon manuscrit.

Je presente mes remerciements a M. Pierre Maret pour avoir accepte de presider

le jury de cette these. Je suis tres honore de l’interet qu’il porte a ce travail.

Je remercie M. Bertrand Chabbat et M. David Jouve pour m’avoir accueilli dans

le cadre du projet Systeme d’Information Documentaire. Je leur remercie pour leur enca-

drement, pour leurs conseils et pour m’avoir associe a cette grande aventure institutionnelle

qu’est le projet SIDoc.

Je tiens a remercier tout particulierement M. Jean-Marie Pinon et M. Youssef

Amghar pour avoir accepte de diriger mes recherches, pour leur encadrement, et pour leur

engagement dans cette these. Merci a eux d’avoir su me faire decouvrir et aimer le metier

de chercheur et d’enseignant. Merci aussi pour leur patience et pour leurs encouragements

dans les moments moins faciles.

i

Je remercie egalement l’ensemble des personnes du Cnedi Rhone-Alpes et du

Liris, avec qui j’ai pu lier des liens d’amitie, pour leur accueil chaleureux et pour tous les

moments sympathiques que nous avons vecus pendant ces annees.

Un grand Merci a Maud et Sabine, les « arbitres des chiffres, des lettres et des

virgules » qui ont eu la patience extraordinaire de relire et de corriger ce manuscrit. Ainsi,

grace a elles, sa qualite s’est amelioree.

Enfin, je tiens a profiter de l’importance de ce manuscrit dans la vie d’un cher-

cheur, pour exprimer mon immense gratitude a tous ceux, famille, amis, collegues, qui

m’ont aide, accompagne et encourage, avec beaucoup de patience et de comprehension,

tout au long de ces longues annees. Les citer ici serait trop long ; ils se reconnaıtront.

Leur presence a mes cote et leur affection est un precieux cadeau de la vie et cette

reussite est aussi la leur. Du fond du coeur, un grand Merci ! Multumesc !

ii

Ce n’est pas parce que les choses

sont difficiles que nous n’osons pas,

c’est parce que nous n’osons pas

qu’elles sont difficiles.

Seneque

iii

iv

Table des matieres

Introduction generale 1

Partie I Contexte et problematique 5

Introduction 7

Chapitre 1 Maıtrise d’un patrimoine des connaissances metier 9

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 La Branche famille de la Securite Sociale . . . . . . . . . . . . . . . . . 10

1.2.1 La Securite Sociale . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.2 Mission de protection sociale de la Branche famille . . . . . . . . 11

1.2.3 Mission de mise en application de la legislation . . . . . . . . . . 11

1.3 Composante documentaire . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3.1 Production et gestion de la composante documentaire . . . . . . 14

1.3.2 Caracteristiques de la composante documentaire . . . . . . . . . 17

1.3.3 Problematiques et enjeux de la maıtrise de la composante docu-

mentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.4 Composante logicielle - le Systeme de gestion des prestations legales . . 21

1.4.1 Production de la composante logicielle . . . . . . . . . . . . . . . 21

1.4.2 Caracteristiques de la composante logicielle . . . . . . . . . . . . 25

v

Table des matieres

1.4.3 Problematiques et enjeux de la maıtrise de la composante logicielle 27

1.5 Services attendus pour la maıtrise du patrimoine des connaissances metier 30

Chapitre 2 Etat des lieux dans la Branche famille 33

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2 Demarche generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.2 Maıtrise des connaissances metier - projet SIDoc/KM . . . . . . 34

2.3 Le referentiel de production et de gestion documentaire . . . . . . . . . 36

2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.3 Fonctions de base . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3.4 Fonctionnalites de gestion et de production documentaire . . . . 46

2.3.5 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . 47

2.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Conclusions 53

Partie II Etat de l’art 55

Introduction 57

Chapitre 3 Structuration de la documentation 59

3.1 Notion de document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2 Structure documentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.3 Langages de structuration documentaire . . . . . . . . . . . . . . . . . 63

3.4 Modelisation documentaire . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.5 Langages d’echanges documentaires . . . . . . . . . . . . . . . . . . . . 66

3.6 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

vi

Chapitre 4 Gestion des Systemes d’Information 69

4.1 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.1 Les cycles de developpement . . . . . . . . . . . . . . . . . . . . 71

4.1.2 Les methodologies de conception et de developpement . . . . . . 71

4.1.3 Formalisation des developpements . . . . . . . . . . . . . . . . . 72

4.1.4 Maıtrise et amelioration de la qualite . . . . . . . . . . . . . . . 73

4.1.5 Programmation des processus . . . . . . . . . . . . . . . . . . . 73

4.2 Modelisation des Systemes d’Information . . . . . . . . . . . . . . . . . 74

4.2.1 Formalismes de modelisation . . . . . . . . . . . . . . . . . . . . 75

4.2.2 Choix du formalisme de modelisation des Systemes d’Information 78

4.2.3 Maıtrise des modeles . . . . . . . . . . . . . . . . . . . . . . . . 79

4.3 Gestion des connaissances et maıtrise des Systemes d’Information . . . 80

4.4 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapitre 5 Analyse des dependances 83

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2 Tracabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3 Analyse des dependances - livrables de conception et de developpement 86

5.4 Analyse des dependances - code source des applications . . . . . . . . . 87

5.4.1 Graphe de dependances . . . . . . . . . . . . . . . . . . . . . . . 87

5.4.2 Decoupage des programmes – Program slicing . . . . . . . . . . 88

5.5 Analyse des dependances - exigences des utilisateurs . . . . . . . . . . . 89

5.6 Analyse des dependances - execution des programmes . . . . . . . . . . 90

5.7 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Conclusion 93

Partie III Propositions pour l’etude d’impact 95

Introduction 97

vii

Table des matieres

Chapitre 6 Cadre pour l’etude d’impact 99

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.2 Modele d’etude d’impact – Niveaux d’abstraction . . . . . . . . . . . . 101

6.2.1 Niveau d’abstraction N 0 – le monde reel et les connaissances

du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.2.2 Niveau d’abstraction N 1 – la representation du monde reel . . . 103

6.2.3 Niveau d’abstraction N 2 – le modele de representation . . . . . 104

6.2.4 Niveau d’abstraction N 3 – le modele d’etude d’impact . . . . . 104

6.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.3 Modele d’etude d’impact - Niveau d’abstraction N3 . . . . . . . . . . . 105

6.3.1 Connaissances d’un domaine . . . . . . . . . . . . . . . . . . . . 105

6.3.2 Structure statique du meta-modele . . . . . . . . . . . . . . . . 107

6.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.3.4 Specialisation du meta-modele - Niveau d’abstraction N2 . . . . 110

6.3.5 Representation des dependances – Niveau d’abstraction N1 . . 111

6.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Chapitre 7 Application du modele generique d’etude d’impact 117

7.1 Modele d’etude d’impact associe aux modeles UML – niveauN2 . . . . 117

7.1.1 Typologie des elements - Concept UML elementaire . . . . . . . 117

7.1.2 Typologie des relations elementaires dans les modeles UML . . . 119

7.1.3 Modele de graphe specifique a UML . . . . . . . . . . . . . . . . 120

7.1.4 Graphe canonique des dependances et etude d’impact – N1 . . . 121

7.2 Modele d’etude d’impact associe aux documents – niveau N2 . . . . . 123

7.2.1 Typologie des elements - Concept documentaire elementaire . . 124

7.2.2 Typologie des relations elementaires documentaire . . . . . . . . 124

7.2.3 Graphe canonique des dependances – etude d’impact – N1 . . . 126

Chapitre 8 Integration du Modele d’etude d’impact 129

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

8.2 Extension du Referentiel SIDoc a la gestion des modeles UML du SI . . 131

8.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.2.2 Gestion des modeles UML du SI . . . . . . . . . . . . . . . . . . 132

8.2.3 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8.2.4 Utilisation des fonctionnalites du referentiel . . . . . . . . . . . . 139

viii

8.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.3 Integration du modele d’analyse des dependances et d’etude d’impact . 142

8.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.2 Representation des dependances – graphe d’analyse des depen-

dances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.3 Algorithme de parcours de graphe . . . . . . . . . . . . . . . . . 147

8.3.4 Integration dans la couche service . . . . . . . . . . . . . . . . . 148

8.3.5 Integration dans la couche presentation . . . . . . . . . . . . . . 149

8.3.6 Bilan de l’integration des modeles UML dans le referentiel SIDoc 152

Conclusion 155

Partie IV Evaluation 157

Chapitre 9 Evaluation et discussions 159

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.2 Rappel des enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.3 Modele d’etude d’impact . . . . . . . . . . . . . . . . . . . . . . . . . . 161

9.3.1 Rappel de la problematique . . . . . . . . . . . . . . . . . . . . . 161

9.3.2 Rappel de la proposition . . . . . . . . . . . . . . . . . . . . . . 161

9.3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.3.4 L’experience de l’utilisateur . . . . . . . . . . . . . . . . . . . . . 165

9.4 Integration dans le referentiel SIDoc . . . . . . . . . . . . . . . . . . . . 166

9.4.1 Rappel de la problematique . . . . . . . . . . . . . . . . . . . . . 166

9.4.2 Rappel de la proposition . . . . . . . . . . . . . . . . . . . . . . 166

9.4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

9.4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Conclusion generale 173

ix

Table des matieres

Annexe A Liste des publications 175

Annexe B Schema XSD de la recommandation XML-Schema 177

Annexe C Exemple d’un docflow 179

Annexe D Recettage fonctionnel de l’application SIDoc - Extraits 181

D.1 Recettage fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Annexe E Le systeme G-Frames 183

E.1 Les G-Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Glossaire 185

Bibliographie 189

x

Introduction generale

Pour les organisations qui ont pour mission la mise en application de la legisla-

tion, les textes reglementaires constituent, a l’image de toute entreprise produisant des

biens de consommation, une matiere premiere specifique : leur activite est fondee sur

l’analyse et le traitement de cette matiere. Mais les textes reglementaires constituent aussi

le vecteur privilegie de la communication et de la diffusion des connaissances juridiques

dans l’ensemble des ramifications de ces organisations. Ces connaissances sont exprimees

au travers de nombreuses ressources critiques pour l’entreprise : documents de reference,

supports de formation, documentation metier, documentation de conception du Systeme

d’Information, etc. Elles sont utilisees au quotidien par les personnes travaillant dans ces

organisations et chargees de mettre en application la legislation. On designe par « patri-

moine documentaire » l’ensemble de ces ressources documentaires.

Par ailleurs, au vu de la quantite massive d’information traitee au sein de l’en-

treprise, le travail depasse tres largement les capacites humaines, l’amenant a solliciter

l’assistance du Systeme d’Information qui met en oeuvre les exigences exprimees par les

textes reglementaires. Celui-ci doit accompagner au quotidien les activites et servir les

objectifs de l’organisation.

Dans le domaine juridique, une des principales caracteristiques des textes regle-

mentaires est que ceux-ci sont en evolution permanente. A chaque evolution reglementaire,

l’ensemble des documents reglementaires doit etre passe en revue et, si necessaire, mis a

jour. Mais l’impact lie a une evolution reglementaire ne se cantonne pas aux seuls docu-

ments reglementaires : il affecte egalement le Systeme d’Information. Assurer la coherence

et la conformite tout au long du processus de mise en application du droit, face aux evo-

lutions reglementaires, devient une problematique strategique et engendre alors un cout

humain et financier important.

Il devient donc necessaire de pouvoir identifier et mesurer les consequences d’une

evolution reglementaire a la fois sur le patrimoine documentaire et sur le Systeme d’Infor-

mation.

Ainsi notre problematique s’exprime sur deux plans :

– mettre en relation le patrimoine documentaire et le Systeme d’Information,

– mesurer les consequences d’une evolution reglementaire : identifier les res-

1

Introduction generale

sources qui sont susceptibles d’etre impactees (au sein du patrimoine docu-

mentaire et du Systeme d’Information) et evaluer l’importance de l’impact

subit.

Repondre a cette problematique permettra une meilleure maıtrise de l’ensemble

des ressources documentaires et du Systeme d’Information, necessaire pour accroıtre la

capacite a reagir aux changements de legislation ce qui constituera un atout strategique

pour l’organisation. On parlera alors de maıtrise du « patrimoine reglementaire » ou du

« patrimoine des connaissances metier ».

Cette problematique puise ses origines dans le contexte de la Branche Famille de

la Securite Sociale. C’est ainsi que la Caisse Nationale des Allocations Familiales (Cnaf)

a servi de cadre aux differents travaux de recherche presentes au cours de cette these.

La Cnaf est en charge de l’une des legislations les plus complexes du droit francais. Les

connaissances juridiques explicitees dans des documents reglementaires et encodees dans le

Systeme d’Information doivent etre parfaitement maıtrisees tout au long de l’elaboration

du produit fini que sont les prestations specifiques.

Ce contexte a ete particulierement utile pour comprendre et analyser les nom-

breuses difficultes liees a la gestion de la matiere reglementaire et a la maıtrise du Systeme

d’Information auxquelles peuvent etre quotidiennement confrontees des entreprises pu-

bliques ou privees. Ces problemes n’ont toutefois pas ete traites uniquement en fonction

du contexte specifique de travail (Cnaf ), mais bien en les considerant comme revelateurs

d’une problematique plus large concernant de maniere generale la gestion documentaire

et la gestion des systemes d’information.

Dans le contexte particulier de ce travail, plusieurs travaux de recherche et de de-

veloppement ont permis de construire un systeme pour la maıtrise des diverses ressources

documentaires de l’organisation : notamment ceux de Bertrand Chabbat [Chabbat 97],

sur la modelisation multiparadigme des textes reglementaires, ceux de Cecile Nicolle

[Nicolle 01] sur l’acces a des bases de donnees heterogenes et ceux de David Jouve [Jouve 03a],

qui s’est interesse a la modelisation semantique de la reglementation. A l’heure actuelle, la

Cnaf souhaite prolonger cette demarche et ce processus de gestion aux composants de son

Systeme d’Information. Ainsi, l’objectif de ce travail de recherche est de proposer les outils

manquants pour une gestion unifiee des deux types de ressources encodant les connais-

sances metier d’une entreprise : les ressources documentaires et les ressources logicielles.

Ces propositions ont ete validees lors de leur integration dans le Systeme d’Information de

[Chabbat 97] Chabbat Bertrand. Modelisation multiparadigme de textes reglementaires. These :

Institut National des Sciences Appliquees de Lyon, Lyon, France, decembre 1997. 389 p.

[Nicolle 01] Nicolle Cecile. Systeme d’acces a des Bases de Donnees Heterogenes reparties en vue

d’une aide a la decision (SABaDH). These : Institut National des Sciences Appliquees de

Lyon, decembre 2001. 125 p.

[Jouve 03a] Jouve David. Modelisation semantique de la reglementation. These : Institut National

des Sciences Appliquees de Lyon, novembre 2003. 270 p.

2

la Cnaf mais leur champ d’application peut-etre elargi a d’autres domaines.

La presente these est decoupee en quatre parties, s’interessant chacune a un aspect

particulier de notre travail de recherche.

Au cours de la premiere partie, Contexte et problematique, nous procedons a

une etude approfondie des differentes caracteristiques du patrimoine documentaire et du

Systeme d’Information de la Cnaf. Nous analysons leur perimetre et le role crucial qu’ils

sont amenes a jouer au cœur de l’activite d’une organisation et plus particulierement au

cœur des processus de mise en application du droit. Nous presentons egalement les diverses

questions que suscitent d’une part la gestion des textes reglementaires et d’autre part celle

du Systeme d’Information.

La conclusion a laquelle nous conduit l’expose de cette problematique est qu’une

maıtrise globale des connaissances metier passe par la mise en relation et par une maı-

trise commune de la composante documentaire et du Systeme d’Information. L’effet de

l’evolution d’une connaissance legislative doit pouvoir etre identifie dans l’ensemble du pa-

trimoine des connaissances metier. Nous devons donc etudier comment representer, mettre

en relation et analyser les dependances entre ces deux ressources complementaires que sont

les documents et le Systeme d’Information.

On poursuit dans la deuxieme partie, consacree a l’Etat de l’art, en etudiant

plus precisement les travaux de recherche et de developpement realises autour de cette

problematique. Nous nous interessons plus particulierement a la gestion et modelisation

documentaire, a la gestion et modelisation des systemes d’information ainsi qu’aux meca-

nismes de representation et d’analyse des dependances.

Dans la troisieme partie de cette these, Propositions pour l’etude d’impact, nous

introduisons, en nous basant sur des principes de la gestion des connaissances, un modele de

representation des dependances que les differentes composantes documentaires et logicielles

entretiennent. Ce modele commun nous permet de mettre en relation les deux composantes

du patrimoine des connaissances metier et de realiser des etudes d’impact. Le modele

propose et son adaptation pour les documents et pour les modeles UML du Systeme

d’Information ont ete implementes dans l’infrastructure du Referentiel de production et

de gestion documentaire de la Cnaf. Au travers de cette phase d’implementation, nous

avons bati une application de gestion capable de repondre aux enjeux de la maıtrise de

la matiere reglementaire, patrimoine documentaire et Systeme d’Information. Par ailleurs

nous avons mis en evidence la pertinence, la fiabilite et la coherence de notre contribution,

tout en verifiant que le modele propose reste realiste et operationnel.

Enfin, la quatrieme et derniere partie, Evaluation, presente une methode d’evalua-

tion ainsi que les resultats obtenus avec nos propositions. Nous presentons une evaluation

de notre modele d’etude d’impact ainsi que les retours des utilisateurs. La discussion,

presente a la fin de ce dernier chapitre, conclue la these en tracant quelques perspectives

academiques et applicatives aux travaux de recherche presentes.

3

Introduction generale

4

Premiere partie

Contexte et problematique

5

Introduction

La partie « Contexte et problematique » de ce manuscrit s’articule autour de

deux chapitres.

Dans le premier chapitre, nous presentons le metier et les missions de la Branche

famille de la Securite Sociale geree par la Caisse Nationale des Allocations Familiales

(Cnaf).

C’est dans ce cadre que nous mettons en evidence l’importance de la matiere

reglementaire et ses caracteristiques sur les deux volets : documentaire et logiciel. Ainsi,

nous analysons les specificites des textes reglementaires, « le patrimoine documentaire »,

en nous interessant d’une part aux flux de textes reglementaires externes et internes (de

l’Assemblee Nationale aux Caisses d’allocations familiales) et d’autre part aux differentes

fonctionnalites de maıtrise des connaissances requises par l’entreprise (consultation de

textes par differents utilisateurs, redaction de textes, recherche d’information, tracabilite

des interventions, etc.). Ce chapitre s’interesse egalement au Systeme d’Information, a sa

structure, aux problematiques de conception, de la composante logicielle, supportant le

metier des organisations telles que la Cnaf. Nous analysons les specificites du Systeme

d’Information et les fonctionnalites necessaires a la conception, au developpement et a la

maintenance des composantes du Systeme d’Information.

Enfin, dans le deuxieme chapitre de cette partie nous presentons la demarche

adoptee au sein de la Branche famille pour apprehender cette problematique complexe

ainsi que l’etat des lieux et le contexte sur lequel se base notre travail.

7

Introduction

8

Chapitre 1

Maıtrise d’un patrimoine des

connaissances metier

Sommaire

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 La Branche famille de la Securite Sociale . . . . . . . . . . . 10

1.2.1 La Securite Sociale . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.2 Mission de protection sociale de la Branche famille . . . . . 11

1.2.3 Mission de mise en application de la legislation . . . . . . . 11

1.3 Composante documentaire . . . . . . . . . . . . . . . . . . . 14

1.3.1 Production et gestion de la composante documentaire . . . . 14

1.3.2 Caracteristiques de la composante documentaire . . . . . . . 17

1.3.3 Problematiques et enjeux de la maıtrise de la composante

documentaire . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.4 Composante logicielle - le Systeme de gestion des presta-

tions legales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4.1 Production de la composante logicielle . . . . . . . . . . . . 21

1.4.2 Caracteristiques de la composante logicielle . . . . . . . . . 25

1.4.3 Problematiques et enjeux de la maıtrise de la composante

logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.5 Services attendus pour la maıtrise du patrimoine des connais-

sances metier . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.1 Introduction

Nous presentons dans ce premier chapitre le metier et les missions de la Branche

famille de la Securite Sociale geree par la Caisse Nationale des Allocations Familiales

(Cnaf). Ce chapitre nous permet d’identifier et de comprendre l’importance des textes

9

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

reglementaires et du Systeme d’Information dans l’exercice metier des institutions telles

que la Cnaf ayant comme mission la mise en application du droit.

Nous analyserons les caracteristiques et les problematiques liees a la gestion des

textes reglementaires et a la gestion du Systeme d’Information.

1.2 La Branche famille de la Securite Sociale

1.2.1 La Securite Sociale

Le systeme francais de protection sociale, institue en 1945, a vocation, des ses de-

buts, a proteger la population francaise, en la couvrant des risques lies aux evenements et

aux situations de la vie. Appele plus communement « la Securite Sociale », le regime general

est forme d’un ensemble d’institutions organisees selon 4 branches [CodeSecuriteSociale 01] :

1. la Branche maladie, maternite, invalidite et deces,

2. la Branche accidents du travail et maladies professionnelles,

3. la Branche vieillesse et veuvage : geree par la Caisse nationale d’assurance vieillesse

des travailleurs salaries (Cnav).

4. la Branche famille : geree par Caisse nationale des allocations familiales(Cnaf).

Les deux premieres branches sont gerees par la Caisse nationale de l’assurance

maladie (Cnam).

Les ressources financieres du regime general sont collectees, centralisees et gerees

par les organismes charges du recouvrement : l’Agence centrale des organismes de secu-

rite sociale (ACOSS) et ses organismes locaux les Urssaf - Union de recouvrement des

cotisations de securite sociale et d’allocations familiales.

Pour mener a bien sa mission, chacune de ces branches est composee de divers

organismes repartis sur tout le territoire francais. Ces organismes materialisent la Securite

Sociale et participent a la mise en œuvre quotidienne de la politique de protection sociale

au plus pres des citoyens.

A titre d’exemple, la Branche famille, geree par la Caisse nationale des allocations

familiales, est formee d’un reseau de 123 Caisses d’allocations familiales (Caf).

Les services de la Direction du Systeme d’Information qui a servi de cadre aux

presents travaux de recherche participent au support de l’activite de la Branche famille.

[CodeSecuriteSociale 01] Secretariat General du Gouvernement, Hotel de Matignon, 57 rue de Varenne, 75007

PARIS. Code de la Securite Sociale – Livre 2 : Organisation du regime general,

action de prevention, action sanitaire et sociale des caisses, 2001. Disponible sur :

http ://www.legifrance.gouv.fr (consulte le 07.07.2008).

10

1.2. La Branche famille de la Securite Sociale

1.2.2 Mission de protection sociale de la Branche famille

La famille est la cellule de base de notre societe et occupe une place preponderante

parmi les preoccupations des Francais. Les transformations de la societe actuelle ainsi que

les nouveaux styles de vie et de travail engendrent diverses difficultes pour les familles

dans les domaines de l’education, du logement, des ressources. Prenant en compte les

aspirations des individus et les besoins de la societe, chaque pays a mis en place des aides

a destination des familles.

En France, depuis plus de 60 ans, dans le cadre d’une forme originale de protection

sociale et de solidarite nationale, la Branche famille de la Securite Sociale, accompagne

les familles dans leur vie quotidienne en les couvrant contre les risques et charges de toute

nature qui menacent leur securite economique et sociale.

La Branche famille, pilotee par la Cnaf, est un reseau de 123 Caisses d’Allocations

familiales presentes sur tout le territoire. Chaque Caisse d’allocations familiales prend en

charge l’attribution des prestations legales et le developpement de l’action sociale sur son

territoire. Elle peut ainsi, dans le cadre legal defini par la Cnaf, mener une politique sociale

mieux adaptee aux besoins locaux et specifiques des populations de sa region.

L’ensemble de l’Institution est mobilise au service des citoyens et des familles et a

pour but d’aider ses allocataires tout au long de leur vie. Par le biais de prestations legales

et d’actions specifiques, elle facilite les differentes etapes de la vie des allocataires : etudes,

installation, accueil d’un nouvel enfant, education des enfants, logement, lutte contre l’ex-

clusion. Ses politiques ont un impact sur plusieurs axes : la natalite, la conciliation de la

vie familiale et vie professionnelle, l’habitat et le logement, l’emploi, la sante, la precarite

et la redistribution des richesses.

Pour parvenir a ces objectifs, des prestations legales adaptees a chaque situa-

tion ont ete mises en place. Actuellement, l’Institution denombre plus de 30 allocations

differentes. Tous les ans, de nouvelles prestations viennent enrichir l’offre globale et des

prestations existantes sont modifiees. Le developpement des prestations familiales s’ac-

compagne donc d’une forte proliferation normative.

Par ailleurs, etant donne le grand nombre d’allocataires (plus de 13 millions,

soit 30 millions de personnes concernees representant 6,5 millions familles et 12 millions

d’enfants), il est nul besoin de souligner l’importance acquise de l’action de la Branche

famille au cœur de la societe francaise.

1.2.3 Mission de mise en application de la legislation

La Caisse Nationale des Allocations Familiales est en charge de l’une des le-

gislations les plus complexes du droit francais et a la delicate mission de la mettre en

application.

11

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

1.2.3.1 Metaphore industrielle

La reglementation, et par extension l’ensemble des documents qui contribue a

son expression, est frequemment percue par les nombreuses composantes de la societe –

les personnes physiques ou morales – comme une somme de contraintes comportemen-

tales auxquelles il faut se conformer. Mais, pour certaines entreprises ou organisations, les

documents reglementaires peuvent etre apprehendes d’une toute autre maniere.

En particulier, pour des organisations telles que la Branche famille dont la mis-

sion est la mise en application de la legislation, les textes reglementaires, support de la

connaissance legislative du domaine, jouent un role essentiel au cœur de leur metier et

constituent, a l’image de toute entreprise produisant des biens de consommation, une

matiere premiere essentielle [Jouve 03a].

C’est ainsi que dans une vision macroscopique, l’activite de la Branche famille

repose sur la manipulation et l’analyse de matieres premieres de deux types : les textes

reglementaires externes et les donnees factuelles (appelees donnees allocataires) 1. A partir

de la transformation et de la confrontation de ces deux types de matieres premieres, la

Branche famille est chargee de determiner les prestations specifiques que percevra l’allo-

cataire. La figure1.1 presente schematiquement le fonctionnement de la Branche famille.

Textes Réglementaires(externes) Données Allocataires

CNAF

CAF

Prestations Spécifiques

Textes Réglementaires(internes)

BRANCHE FAMILLE

Figure 1.1 – Metier de la Branche famille.

Les textes reglementaires constituent egalement le vecteur privilegie de la commu-

nication et de la diffusion de ces connaissances juridiques dans l’ensemble des ramifications

de l’organisation. Ces textes reglementaires supportent l’exercice metier des agents de la

Branche famille pour remplir les missions de l’Institution.

1. Ensemble des donnees relatives a la situation des allocataires ou allocataires potentiels (nom,prenom, age, adresse, ressources,...).

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

12

1.2. La Branche famille de la Securite Sociale

Cependant, la matiere reglementaire fournie en entree se revele etre de trop haut

niveau pour etre reellement applicable par des personnes non-juristes. Pour repondre aux

besoins de chaque profil metier, le processus de creation du droit est prolonge au cœur

meme de l’organisation : la matiere reglementaire est ainsi affinee, enrichie par l’ajout de

nouveaux documents (les textes reglementaires internes). La matiere originale est trans-

formee, distillee pour la rendre plus operationnelle 2 jusqu’aux documents directement

applicables encodant les regles de gestion.

Par ailleurs, le nombre de dossiers d’allocataires etant tres important, il est

evident que le traitement de cette information depasse largement les capacites humaines.

L’Institution s’est donc dotee d’un systeme de gestion des prestations pour l’assister dans

la mission de mise en application du droit. Ce systeme de gestion des prestations accom-

pagne les activites operationnelles de l’organisation. Celui-ci a ete developpe en prenant

en compte les exigences exprimees par les textes reglementaires et a, par consequent,

l’obligation d’assurer un traitement en conformite avec la legislation du domaine.

La metaphore industrielle peut etre parfaitement appliquee a la realite du metier

de la Branche famille. Celle-ci peut en effet etre percue comme une entreprise produisant

des biens de consommation. La matiere premiere (constituee par les textes reglementaires

externes et par les donnees allocataires) est transformee tout au long du processus de crea-

tion des « produits finis », que sont les prestations specifiques. Le Systeme d’Information,

qui vient accompagner les activites operationnelles de l’organisation, aide a automatiser

les taches et les traitements presents dans le processus de production du « produit fini ».

Ainsi, il a l’obligation d’assurer un traitement en conformite avec la legislation du domaine.

1.2.3.2 Patrimoine des connaissances metier

L’activite de l’organisation repose sur l’utilisation des textes reglementaires et des

donnees d’allocataires. Elle est accompagnee au quotidien par le Systeme d’Information.

L’ensemble des textes reglementaires, principal support des connaissances juri-

diques, ainsi que leur implementation dans le Systeme d’Information jouent un role prepon-

derant au cœur du metier des Caf et represente ainsi une veritable richesse : le patrimoine

que nous appelons « patrimoine des connaissances metier ».

Le patrimoine des connaissances metier est forme de deux composantes :

– composante documentaire : ensemble des ressources documentaires supportant

le metier de l’organisation (textes reglementaires, documentation operation-

nelle, etc.),

– composante logicielle : ensemble de ressources logicielles liees au metier de

l’organisation (applications de gestion des prestations, applications de gestion

financiere, etc.).

2. Ce mecanisme est a correler avec la hierarchisation du corpus reglementaire cf. la section 1.3.2.1

13

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

Nous allons decrire, pour chaque composante, les principales caracteristiques, les

problematiques et les enjeux auxquels l’organisation doit faire face pour mener a bien sa

mission.

1.3 Composante documentaire

Par definition, la legislation est l’ensemble des lois d’un pays ou relatives a un

domaine particulier. Dans les gouvernements constitutionnels, la legislation n’appartient

qu’au Parlement. La loi fixe les grandes lignes du plan legislatif et delegue a une autorite

dite « autorite reglementante » (le Premier Ministre, un ministere, un organisme publique.)

la tache d’en regler les details d’application generale en emettant des « reglements ». La

reglementation est formee par l’ensemble de ces reglements et est frequemment percue

comme une somme de contraintes comportementales auxquelles il faut se conformer. Mais,

pour certaines entreprises ou organisations, les documents reglementaires representent un

support essentiel de leur activite pour les accompagner dans leur mission.

1.3.1 Production et gestion de la composante documentaire

Tel que nous l’avons deja vu, les textes reglementaires, internes et externes, consti-

tuent le vecteur privilegie de la communication et de la diffusion de ces connaissances

juridiques dans l’ensemble des ramifications de l’organisation.

1.3.1.1 Textes reglementaires - matiere premiere

Les agents comme le personnel des Caisses d’allocations familiales vont s’y ap-

puyer au quotidien pour traiter des dossiers et conseiller les allocataires. D’autres, comme

les concepteurs du Systeme d’Information, vont encoder les exigences exprimees dans ces

textes reglementaires au niveau des applications du Systeme d’Information. Cependant en

ce qui concerne le niveau d’interpretation, les besoins ne sont pas les memes. Par exemple,

la conception d’une application informatique necessite une interpretation et une compre-

hension plus detaillee du texte que la reponse a une simple interrogation.

Les textes reglementaires doivent donc etre manies pour fournir a chaque compo-

sante de l’organisation l’ensemble de documents reglementaires dont elle a besoin, adaptes

a son profil metier, a ses fonctions et a ses competences.

A l’origine, les textes reglementaires recus proviennent de l’Assemblee Nationale

et des ministeres de tutelle (pour la Cnaf, il s’agit du Ministere du travail, des relations

sociales et de la solidarite).

Chaque composante de l’organisation s’approprie, utilise et transforme a sa ma-

niere une partie du corpus reglementaire en fonction de ses besoins. C’est ainsi que ces

briques organisationnelles produisent a leur tour de nouveaux textes reglementaires utilises

14

1.3. Composante documentaire

pour des objectifs divers tels que : l’implementation dans les systemes experts, la communi-

cation externe, l’elaboration d’autres documents internes, les application de consultation,

l’aide a la decision, les applications de formation et d’apprentissage en ligne, etc.

La qualite du service rendu depend de la bonne maıtrise du processus de produc-

tion et de gestion des textes que l’Institution produit et utilise.

Bertrand Chabbat [Chabbat 97] analyse les circuits des textes reglementaires. La

figure 1.2 montre de maniere globale le cheminement des textes de l’Assemblee Nationale

jusqu’aux applications de consultation ou aux systemes experts de l’organisation (ici, la

Cnaf ) en passant par les differentes briques organisationnelles appelees fonctions.

Assemblée Nationale Ministères

Organisation (Cnaf)

Documents de référence internes

Acquisition 1

Acquisition 2 Acquisition 3

Acquisition 4

Textes législatifsDécrets

Circulaires

Elaboration des règles SI

Communication externe

Documentation technique

Aide à la décision

FormationEnseignement assisté

par ordinateur

Acquisition d’information

Texte réglementaireActeur Fonction

Figure 1.2 – Flux des objets reglementaires au sein de la Cnaf.[Chabbat 97]

1.3.1.2 Ressources de la composante documentaire

Les textes reglementaires sont des objets documentaires specifiques a un domaine

qui entretiennent de nombreux liens.

Nous avons vu que la matiere reglementaire est constituee de differents types

d’objets produits ou manipules par une organisation dans le cadre de sa mission. On

appelle objet reglementaire tout document ou regle (de gestion ou de systeme expert) qui

exprime d’une maniere specifique une legislation ou une reglementation.

Il convient d’etablir une nette distinction entre les documents externes et les

objets internes. Les premiers sont recus par l’organisation qui n’a pas le pouvoir de les

modifier, tandis que les seconds sont produits et geres par l’organisation pour son propre

[Chabbat 97] Voir reference [Chabbat 97] definie page 2.

15

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

usage ou pour sa communication [Chabbat 97]. L’ensemble forme par les textes externes

et les objets internes constitue le corpus reglementaire ou le fonds documentaire reglemen-

taire.

Texte reglementaire externe – Les textes externes comprennent l’ensemble des docu-

ments juridiques applicables par l’organisation tels que le Journal Officiel, les lois,

les decrets, la jurisprudence, etc. Des textes complementaires, tels que les proces

verbaux de l’Assemblee Nationale, qui tendent a prescrire la maniere d’interpreter

la loi, doivent egalement etre pris en consideration.

Objet reglementaire interne – Les objets reglementaires internes comprennent les do-

cuments et les regles produits par les diverses couches de l’organisation. Dans le

contexte de la Branche famille, differentes categories d’objets reglementaires sont

couramment distinguees. A chacune, l’organisation attribue une valeur juridique,

generalement inversement proportionnelle a leur degre d’applicabilite (facilite de la

mise en œuvre) :

– les documents de reference internes sont constitues des circulaires produites par la

Cnaf, appelees circulaires Cnaf, et des Suivis Legislatifs. Ces derniers reprennent

le contenu des textes applicables en le traduisant de maniere a le rendre plus

comprehensible pour des utilisateurs qui ne sont pas specialistes du droit.

– a partir des documents de reference internes, chaque brique de l’organisation de

l’Institution peut etre amenee a produire ses propres objets reglementaires adaptes

a un public specifique. Ces documents ont egalement une vocation reglementaire.

– les regles de gestion sont dotees d’un degre d’applicabilite maximal. Elles sont

egalement utilisees comme base pour la conception et l’implementation de la re-

glementation. Nous detaillerons les problematiques specifiques a la conception du

Systeme d’Information dans la section 1.4 du present chapitre.

Dans le present manuscrit nous employons la notion de textes reglementaires

pour les textes qui expriment une reglementation liee a la legislation, independamment

de leur valeur juridique. Ces documents ont certaines caracteristiques qui les distinguent

des autres types de documents que l’on a pour habitude d’analyser et de gerer dans le

domaine de l’ingenierie documentaire. La matiere reglementaire ne peut etre correctement

maıtrisee qu’en prenant pleinement conscience de ses specificites [Chabbat 97][Jouve 01].

[Chabbat 97] Voir reference [Chabbat 97] definie page 2.

[Jouve 01] Jouve David, Chabbat Bertrand, Amghar Youssef et Pinon Jean-Marie. Structu-

ration semantique de la reglementation. Proc. of the XIXeme Congres INFormatique des

ORganisations et Systemes d’Information et de Decision (INFORSID’2001). Martigny,

Suisse. INFORDSID Editions, 2001, p 5–26.

16

1.3. Composante documentaire

1.3.2 Caracteristiques de la composante documentaire

David Jouve [Jouve 03a] presente en detail les specificites de la matiere regle-

mentaire. Nous nous contenterons, dans les sections suivantes de ce chapitre, de resumer

les caracteristiques de la matiere reglementaire qui interviennent dans la maıtrise du pa-

trimoine reglementaire et qui jouent un role important dans la gestion des composantes

logicielle et documentaire.

1.3.2.1 Structure hierarchisee

La matiere reglementaire est organisee en une structure pyramidale, comme pre-

sente dans la figure 1.3. Les differents niveaux de cette pyramide correspondent aux niveaux

des droits et determinent ainsi la valeur juridique des textes et leur degre d’applicabilite.

Generalement, le degre d’applicabilite est inversement proportionnel a la valeur juridique.

Les lois fondamentales, les plus importantes, sont souvent tres generales. Elles enoncent

des principes difficiles a appliquer en situation de traitement. En France, par exemple,

cette hierarchie presente au sommet : la Constitution suivie de lois parlementaires, des

circulaires ministerielles, des decrets etc.

Une organisation qui a comme mission l’application du droit, peut prolonger

cette pyramide, par des documents internes. A l’origine, les textes reglementaires recus

proviennent de l’Assemblee Nationale et des autorites concernees telles que le Gouver-

nement ou les ministeres de tutelle . Ces textes viennent ensuite alimenter les circuits de

production internes a l’organisation pour affiner et enrichir les textes de lois en fonction de

ses propres problematiques. Nous avons vu que chaque brique fonctionnelle de l’Institution

utilise et transforme ainsi les textes de reference a sa maniere. Les nouveaux documents

produits par l’organisation constituent les trois niveaux inferieurs de la pyramide regle-

mentaire representee dans la figure 1.3. Le niveau le plus bas, le niveau « Organisation

niv. 3 », presente les documents caracterises par un degre d’applicabilite maximal. En

effet, ces derniers sont extremement proches du Systeme d’Information, puisqu’il s’agit

des documents de specification et de conception des regles de gestion implantees dans le

systeme de gestion des prestations de la Cnaf.

Le processus de production des textes et de regles internes est ainsi essentiellement

vertical mais respecte une obligation de conformite : un document present a un certain

niveau doit avoir un contenu conforme aux documents en amont dans la pyramide.

1.3.2.2 Forte redondance

Le processus de creation du droit et de transformation de la matiere reglementaire

introduit une forte redondance dans l’ensemble des textes reglementaires. Comme decrit

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

17

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

Valeur Légale Type de document Origine

ParlementAssemblée Nationale Conseil des MinistresMinistère Organisation niv. 1Organisation niv. 2Organisation niv. 3

Constitution

DécretCirculaire MinistérielleTexte de Référence Int.Instructions Techniques

Loi

Règles de Gestion

Figure 1.3 – Pyramide des ressources reglementaires. [Jouve 03b]

precedemment, de nouveaux documents sont produits en affinant la matiere reglementaire

pour presenter un potentiel operationnel plus fort. Ils doivent cependant preserver un

statut de conformite vis-a-vis des documents originaux. La matiere reglementaire est ainsi

affinee sans en alterer le sens.

Au niveau de la pyramide reglementaire (voir figure 1.3), cet affinage se manifeste

par le fait que chaque document dispose generalement d’un contenu qui vient preciser ceux

des documents de niveau superieur dans la hierarchie juridique. Ainsi, une meme norme

peut faire l’objet de multiples formulations, parfois partielles et complementaires, au sein

du corpus reglementaire et se retrouve ainsi exprimee au travers de plusieurs fragments

documentaires.

Cette caracteristique est qualifiee d’heritage semantique multiple par Bertrand

Chabbat [Chabbat 97]. Son analyse met en evidence la presence de liens de partage d’in-

formation non explicites entre les differents fragments du corpus reglementaire.

1.3.2.3 Forte interconnexion

Au sein d’un ensemble documentaire de nombreux liens sont presents entre les

documents. Ces liens peuvent etre de simples liens de navigations ou porteurs d’une seman-

tique particuliere, par exemple : liens specifiant l’origine d’un document, liens precisant

les impacts d’impact, liens d’equivalence, etc... Par ailleurs lors du processus de produc-

tion documentaire il faut privilegier la reutilisation des contenus (des documents ou de

fragments de documents). Les elements d’un ensemble documentaire sont ainsi fortement

interconnectes.

1.3.2.4 Contenu dynamique

La matiere reglementaire est dynamique. Les textes doivent etre consideres comme

etant issus d’un flux constant, en perpetuelle evolution.

[Chabbat 97] Voir reference [Chabbat 97] definie page 2.

18

1.3. Composante documentaire

L’analyse de David Jouve [Jouve 03a] se focalise sur le fait que les changements

de reglementation constituent l’une des plus importantes barrieres a l’utilisation cou-

rante des techniques de base de connaissances pour les applications de droit pratique

[Bench-Capon 90][Bench-Capon 94]. Sur le plan documentaire, ce phenomene induit des

modes de gestion specifiques, offrant aux utilisateurs la possibilite d’acceder aux differentes

versions d’un texte, aux textes en cours d’application, aux dernieres mises a jour, etc.

La maıtrise de la matiere reglementaire, et notamment celle de sa coherence,

repose essentiellement sur la capacite de l’organisation a gerer correctement cette specificite

notamment en lien avec la redondance semantique.

1.3.3 Problematiques et enjeux de la maıtrise de la composante docu-

mentaire

Les caracteristiques des documents reglementaires, presentees precedemment au

cours de ce chapitre, engendrent un certain nombre de problematiques auxquelles se heurte

la gestion des objets reglementaires. Nous verrons que la matiere reglementaire ne peut

etre veritablement maıtrisee qu’au travers de la prise en compte de ses caracteristiques

intrinseques dans la maniere de representer et de gerer l’information reglementaire.

1.3.3.1 Problematiques de gestion et de production documentaire

Les problematiques de gestion et de production documentaire sont essentiellement

liees a la conception et a la maintenance des objets documentaires.

Conception et production des objets reglementaires

Nous avons vu que les organisations qui fondent leur action sur la matiere regle-

mentaire sont souvent amenees a enrichir le fonds documentaire en redigeant de nouveaux

documents, plus precis, plus lisibles et plus operationnels, a destination du personnel non

juriste. Les contenus alors elabores rassemblent une grande quantite d’informations deja

exprimees au sein des documents originaux.

Le processus d’elaboration des objets reglementaires se manifeste dans le temps

par de nombreux ajouts ou suppressions de portions documentaires.

Maintenance des objets reglementaires

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

[Bench-Capon 90] Bench-Capon Trevor et Coenen Frans. Practical Application of KBS to Law : the

Crucial Role of Maintenance. Legal Knowledge Based Systems, JURIX’90 : Aims for

Research and Development. Edited by Schmidt A.H.J. et Winkels R.G.F. Lelystad.

Koninklijke Vermande, 1990, p 1–17.

[Bench-Capon 94] Bench-Capon Trevor et Coenen Frans. The Maintenance of Legal Knowledge Based

Systems. Computers and Law. Edited by Carr I. et Williams K., p 129–172. Intellect

Books, 1994.

19

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

Les textes reglementaires sont fortement redondants ce qui augmente le risque

d’apparition d’incoherences. Ce risque est amplifie par le caractere changeant de la regle-

mentation.

A chaque modification de reglementation, meme minime, l’ensemble des textes

internes a l’organisation doit potentiellement etre mis a jour de maniere a conserver une

documentation de travail toujours en conformite vis-a-vis de la legislation.

En effet, lorsqu’une modification intervient a un certain niveau de la pyramide,

chacune des ressources en aval peut etre impactee :

– tous les textes de references internes,

– la documentation technique,

– l’ensemble des textes propres a chaque bloc fonctionnel de l’organisation (par

exemple : supports de formation, contenu des portails internet, plaquettes d’in-

formation, documents de travail, etc.).

L’impact a un niveau donne est repercute en cascade, affectant toute la pyramide

jusqu’au niveau inferieur qui est represente par les regles de gestion internes a l’orga-

nisation, impactant ainsi indirectement un certain nombre de composants du Systeme

d’Information lies a la reglementation.

Pour arriver a maıtriser la matiere reglementaire et eliminer tout risque de contra-

diction et d’incoherence, il est necessaire de prendre en compte cette specificite. Par

exemple, dans le contexte de la Cnaf, on observe une moyenne de deux evolutions par

semaine.

Dans ces conditions, les efforts deployes quotidiennement, pour maintenir la ma-

tiere reglementaire a jour et pour produire les nouvelles ressources necessaires a l’exercice

du metier, sont considerables.

1.3.3.2 Enjeux de la maıtrise de la composante documentaire

Pour une organisation qui utilise le droit, la maıtrise de la matiere reglementaire

est accompagnee de divers enjeux : tracabilite et argumentation, maıtrise de la coherence,

decisionnel et statistiques et reactivite.

Tracabilite et argumentation – Lors du processus d’elaboration des prestations spe-

cifiques a chacun des allocataires, les donnees de fait sont analysees au regard de

la legislation en vigueur. Chaque decision presente ou anterieure doit pouvoir etre

justifiee a l’appui d’un texte reglementaire.

Maıtrise de la coherence – Les textes reglementaires constituent le cœur d’un systeme

juridique, ils doivent etre imperativement geres en maıtrisant la coherence des regles

qu’ils expriment.

Decisionnel et statistiques – La reglementation ainsi que son evolution sont etudiees,

des statistiques sont elaborees afin d’alimenter les processus d’aide a la decision et

20

1.4. Composante logicielle - le Systeme de gestion des prestations legales

de nourrir la reflexion legislative. En effet, les statistiques et les indicateurs generes a

l’aide des outils decisionnels permettent de donner une meilleure vision au legislateur

sur les phenomenes de societe, de mieux comprendre les effets des mesures legislatives

passees afin de mieux adapter celles futures.

Reactivite – La capacite de l’organisation a reagir est un facteur strategique. Par exemple,

l’Etat entretient une etroite relation avec la Branche famille notamment lors de l’ela-

boration d’un projet legislatif. Il est difficilement admissible que l’application d’une

nouvelle disposition reglementaire soit entravee par une indisponibilite de l’infra-

structure necessaire a sa mise en application. A chaque evolution de la reglemen-

tation, l’activite de l’organisation doit etre mise a jour pour garder la conformite

avec la legislation. Chaque evolution a ainsi un impact, parfois considerable, sur les

documents internes constituant la composante documentaire du patrimoine regle-

mentaire.

1.4 Composante logicielle - le Systeme de gestion des pres-

tations legales

La Branche famille est en charge de l’une des legislations les plus complexes du

droit francais. Le nombre de dossiers d’allocataires dont elle a la charge depasse la dizaine

de millions. Chaque situation individuelle doit etre analysee conformement au droit afin

de calculer et d’attribuer les Prestations Familiales. La quantite massive de traitement

que requiert une telle activite depasse tres largement les capacites humaines, amenant

l’organisation a solliciter l’assistance de l’ordinateur en se dotant d’un systeme de gestion

des prestations : le systeme CRISTAL developpe et maintenu par la Cnaf.

Nous appelons implementation calculatoire de la reglementation cette composante

du Systeme d’Information batie afin de soutenir une tache de mise en application du droit.

1.4.1 Production de la composante logicielle

Comme nous l’avons deja presente, les textes reglementaires sont une matiere

premiere pour la mission de l’Institution. Ils sont affines, detailles pour obtenir des docu-

ments plus precis, d’un plus bas niveau en importance juridique mais d’un plus haut degre

d’applicabilite - represente par les regles de gestion, le plus bas niveau de la pyramide

reglementaire (le niveau « Organisation – niveau 3 »).

1.4.1.1 Regles de gestion, une matiere premiere

Les regles de gestion, dotees d’un degre d’applicabilite maximal, sont utilisees

comme support pour la conception et l’implementation de la reglementation. Elles re-

21

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

presentent ainsi, a leur tour, une matiere premiere pour la conception de la composante

logicielle du patrimoine reglementaire.

Les regles de gestion embarquees au sein du systeme sont determinees au cours

d’une phase d’analyse de l’ensemble du corpus reglementaire. Elles sont detaillees, la

connaissance exprimee est affinee, interpretee et traduite dans un langage informatique

lors des differentes etapes de conception et de developpement du Systeme d’Information,

en creant ainsi des composants applicatifs. Le processus de creation de droit est ainsi

prolonge par la production de ces nouveaux objets reglementaires.

1.4.1.2 Conception du Systeme d’Information

Les organisations sont de plus en plus dependantes de leur Systeme d’Information.

Actuellement, au sein des organisations, le perimetre couvert par les Systemes d’Informa-

tion est de plus en plus large, les technologies sont de plus en plus complexes ainsi que les

outils et les modeles d’architecture. Dans ce contexte riche, des methodologies de concep-

tion et de developpement des systemes d’information sont employees. Nous ne cherchons

pas a realiser une description detaillee de ces methodologies mais souhaitons juste pointer

quelques unes de leurs caracteristiques communes. Ce travail nous permet d’analyser les

problematiques auxquelles se confrontent les organisations, quelque soit la methodologie

choisie pour la mise en place de leur Systeme d’Information.

La plupart de ces methodologies telles que « RUP - Rational Unified Process » [RUP09 09],

« MSF - Microsoft Solutions Framework » [Turner 06] ou « eXtreme Programming » [Beck 99]

ont ete developpees pour supporter les differentes phases du processus de conception et de

developpement des systemes d’information.

Chacune de ces phases font intervenir nombreux acteurs de l’organisation, chacun

apportant un point de vue different et une connaissance specifique au systeme :

– les utilisateurs et la maıtrise d’ouvrage formulent une exigence des besoins

fonctionnels,

– les concepteurs concoivent et specifient les briques applicatives,

– les architectes techniques et logiciels elaborent l’architecture du systeme,

– les developpeurs realisent l’implementation en suivant les specifications de-

taillees.

Au cours de chacune de ces phases, les acteurs vont s’appuyer sur des ressources

fournies en entree pour produire des livrables specifiques, des documents d’analyse, des

[RUP09 09] IBM Coorporation. Rational Unified Process, 2009. Disponible sur : http ://www-

01.ibm.com/software/awdtools/rup/ (consulte le 24.03.2009).

[Turner 06] Turner Michael S. V. Microsoft Solutions Framework Essentials. Microsoft Press, 2006.

336 p.

[Beck 99] Beck Kent. Extreme Programming Explained : Embrace Change. Addison-Wesley Pro-

fessional, 1999. 224 p.

22

1.4. Composante logicielle - le Systeme de gestion des prestations legales

documents de conception, de specification generale, de specification detaillee, des modeles

d’applications et du Systeme d’Information, des plan de tests, etc..

Par exemple, RUP est une methode iterative et incrementale, guidee par les

besoins des utilisateurs et centree sur l’architecture logicielle. Elle propose un processus et

un cycle de vie pour un projet informatique contenant quatre phases :

– la phase de demarrage (etude des besoins) produit des cas d’utilisation metier

de haut niveau, les principales fonctionnalites, les exigences du systeme ou de

l’application, la planification du projet et les previsions financieres.

– la phase d’elaboration traduit les besoins des utilisateurs en specifications de-

taillees des applications, en s’appuyant sur les documents de la phase prece-

dente et en creant une nouvelle connaissance sur le systeme et de nouveaux

livrables tels que : des cas d’utilisation detailles, des diagrammes de classes,

des definitions des plans de developpement, des prototypes techniques, etc.,

– la phase de construction produit la premiere livraison externe de l’application.

Elle detaille les modeles « UML - Unified Modeling Language » [OMG 07a] de

l’application pour les rendre tres proches du code developpe.

– la phase de transition clot l’activite de developpement et livre l’application

aux utilisateurs en analysant l’impact humain et organisationnel du nouveau

produit logiciel. Les formateurs vont produire la documentation d’utilisation.

Du fait de la complexite des systemes a developper, toutes ces phases peuvent etre ite-

ratives. Par ailleurs, les exigences des utilisateurs et les besoins metier des organisations

evoluent, rendant le cycle entier de ce processus iteratif lui-meme.

Tout au long de ce processus, presente dans la figure 1.4, les documents de

conception, les modeles UML, les documents projet et toutes les autres ressources sont

interconnectees et expriment la meme connaissance mais de points de vue differents. La

connaissance du systeme est ainsi construite toute au long du cycle de conception et de

developpement. Nous pouvons distinguer une hierarchie entre ces ressources de conception

en fonction de la phase ou elles sont produites. Quand les exigences et les besoins des

utilisateurs evoluent, la mise a jour du SI a potentiellement des repercussions sur chacun

des documents de conception et de developpement, y compris sur le code de l’application.

Ces methodologies offrent des regles a suivre et conseillent les meilleures pratiques

a adopter. Neanmoins, elles ne traitent pas la problematique du maintien de la coherence

entre les differents livrables (documents, modeles, code, etc.) et les differentes phases du

processus. Des solutions techniques sont presentes pour la gestion de la documentation,

pour le travail collaboratif et meme pour la gestion des exigences. Mais, comme nous le

verrons dans le chapitre 4, tres peu de solutions s’interessent a la gestion de la coherence

[OMG 07a] Object Management Group (OMG). Unified Modeling Language Specification, Ver-

sion 2.1.2, 2007. Disponible sur : http ://www.omg.org/spec/UML/2.1.2/ (consulte le

04.08.2008).

23

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

Elaboration

Démarrage

Construction

Transition

Allocation

PrestationSoc Montant

PrestationFam

Version de l’application

Condition

Revenus

Quotient

Phases du projet

Livrables

Documents Modèles & autres livrables

nouvelle itération

nouvelle itération

nouvelle itération

nouvelle itération

nouvelle itération

Figure 1.4 – Processus iteratif de conception et developpement d’un SI.

entre les differentes types de ressources, tout au long du processus et a la mise en conformite

avec les exigences des utilisateurs.

Le processus de conception du Systeme d’Information est generique a toute or-

ganisation. Dans le cadre du systeme de gestion des prestations de la Branche famille, le

point de depart de ce processus est represente, comme nous l’avons deja mentionne, par

les regles de gestion.

1.4.1.3 Ressources de la composante logicielle

« Le logiciel » est le terme generique qui designe un ensemble de ressources

ayant trait a la programmation des appareils informatiques. La description detaillee d’un

logiciel et de ses composantes est tres complexe. Nous nous contenterons ici de presenter

brievement les principales ressources qui forment le logiciel.

L’application – Le programme informatique (appele plus communement « l’executable »)

qui peut etre execute directement par l’ordinateur.

Le code source – Le code (generalement sous forme de texte) respectant les regles d’ecri-

ture d’un langage de programmation. L’executable est genere a partir du code source

par un processus de compilation et de construction (dans le cas des langages inter-

pretes, le code source est execute a la lecture).

La documentation d’analyse, de conception et de specification – l’ensemble des

24

1.4. Composante logicielle - le Systeme de gestion des prestations legales

documents issus des activites d’analyse, de specification, de conception et de deve-

loppement, realisees tout au long du processus de creation du logiciel.

Les modeles applicatifs – Ensemble des modeles decrivant le logiciel (cf. les 13 modeles

UML).

La documentation utilisateur, la documentation d’exploitation – l’ensemble des

documents decrivant le fonctionnement du logiciel, offrant de l’aide aux utilisateurs

ou precisant les exigences d’exploitation.

Diverses ressources – D’autres ressources necessaires au bon fonctionnement du logiciel

(fichiers de donnees, ressources graphiques, etc.).

1.4.2 Caracteristiques de la composante logicielle

Par ailleurs, toutes ces ressources de la composante logicielle, bien que de nature

differente, ont des caracteristiques en commun.

1.4.2.1 Structure hierarchisee

Les documents d’analyse, de specification, de conception, les modeles UML, et

toutes les autres ressources, produits tout au long du processus presente dans la figure 1.4,

sont interconnectes et expriment la meme connaissance mais de points de vue differents.

La connaissance du systeme est ainsi construite tout au long du cycle de conception et de

developpement. En fonction des phases ou ces ressources sont produites, nous pouvons les

organiser dans une structure hierarchique, similaire a la pyramide des objets reglementaires

de la figure 1.3.

Dans cette representation hierarchique, les differents niveaux determinent le degre

d’exploitation de la ressource par la machine. Nous retrouvons au niveau le plus haut les

documents d’analyse des besoins et d’expression des exigences qui s’affranchissent des

specificites techniques (systeme d’exploitation, composant de bases de donnees, langage

de programmation), mais qui ne sont pas exploitables par la machine. Ces ressources de

haut niveau sont ensuite detaillees, affinees et traduites dans des langages de plus en plus

exploitables par les appareils informatiques. Ainsi dans une presentation tres schematique,

nous pouvons considerer que les documents d’analyse sont traduits dans des specifications.

Ces dernieres seront affinees pour creer des specifications detaillees qui serviront a la

creation des modeles de l’application. Les modeles vont etre traduits dans du code source

qui, a son tour, sera interprete pour construire des executables. Le niveau le plus bas sera

donc represente par le code executable par la machine (soit le code en langage machine

resultant d’une etape de compilation « langage compile », soit le code source d’un « langage

interprete »).

Les documents d’analyse, le plus haut niveau de cette hierarchie, sont determines

au cours d’une phase d’analyse de l’ensemble du corpus reglementaire. Leur developpement

25

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

vient repondre aux exigences reglementaires. Ainsi, toutes les ressources representant le

systeme de gestion des prestations sont directement dependantes de la legislation et doivent

etre percues comme le fruit du prolongement du processus de creation du droit. Lorsque

les exigences et les besoins des utilisateurs evoluent, la mise a jour a des repercussions sur

l’ensemble des ressources de cette hierarchie, jusqu’au niveau le plus bas represente par le

code de l’application.

1.4.2.2 Forte redondance

Dans le processus de production de la composante logicielle, en vue d’un emploi

distinct, de nombreuses ressources viennent preciser la meme connaissance sur une exigence

ou sur un besoin utilisateur. A chaque etape du processus de conception et de developpe-

ment, les documents sont enrichis, modifies pour devenir de plus en plus exploitables tout

en preservant la coherence avec les exigences initiales.

1.4.2.3 Forte interconnexion

Par nature les applications informatiques sont fortement interconnectees. La reuti-

lisation, l’heritage des fragments applicatifs, le partage des services, des briques applica-

tives font partie des principes de base dans le developpement des Systemes d’Information.

Ainsi, les ressources de conception et de developpement au meme niveau ou a des niveaux

differents de la hierarchie presentee precedemment, entretiennent des nombreux liens : de

reutilisations, d’extensions, de referencements, etc..

1.4.2.4 Contenu dynamique

Les ressources logicielles sont une prolongation du processus de production du

droit et sont donc, par extension, des objets reglementaires qui doivent suivre rigoureu-

sement les evolutions de la legislation. Ainsi, lorsqu’un changement intervient au sein de

la reglementation, il est imperatif que celui-ci leur soit repercute afin de les conformer au

droit. Les processus de conception et de developpement etant iteratifs, l’ensemble de la

hierarchie des ressources logicielles doit etre revu pour integrer les nouvelles exigences ou

l’evolution des besoins des utilisateurs.

Evaluer l’impact d’une modification reglementaire sur des systemes d’information

est un probleme qui prend toute son ampleur lorsque l’on considere le nombre de regles

generalement implantees. A titre d’illustration, le systeme de gestion des prestations Cristal

mis a disposition des Caf 3 integre plus de 15000 regles.

3. Caf – Caisse d’allocations familiales. La Branche famille, pilotee par la Cnaf – Caisse nationaledes allocations familiales, est un reseau de 123 Caf presentes sur tout le territoire.

26

1.4. Composante logicielle - le Systeme de gestion des prestations legales

1.4.2.5 Composante du Systeme d’Information

La composante logicielle du patrimoine des connaissances met en oeuvre les textes

reglementaires (pour la Caf il s’agit du systeme de gestion des prestations Cristal). Elle

represente seulement une partie de tout le Systeme d’information de l’organisation. L’eten-

due de l’impact que peut avoir un changement de reglementation ne se limite generalement

pas au seul composant de gestion des prestations.

Generalement, le chaınage des impacts ne se cantonne pas a ces composants fron-

tieres avec le domaine legislatif. Comme le montre la figure 1.5, le Systeme d’Information

des Caf integre de nombreux autres composants et se caracterise par un tres haut niveau

d’interoperabilite. Eux memes peuvent aussi etre lies, au moyen de relations de depen-

dances, a d’autres composants, induisant ainsi une reaction en chaıne qu’il est necessaire

de maıtriser.

Par exemple, un changement dans les conditions d’attribution d’une allocation

va avoir un impact sur l’ensemble de la composante documentaire, sur le systeme de

gestion des prestations mais aussi sur d’autres composants du SI comme l’application de

gestion des flux comptables, les outils de simulation et de tests ou bien le site internet de

l’Institution.

Niveau hiérarchique Type de texte

Constitution

Loi

Décret

Circulaire ministérielle

Textes de ref. interne

Spécification des règles de gestion

Origine

Parlement

Assemblée nationale

Conseil des ministres

Ministère

Organisation niv. 1

Organisation niv. 2

Implémentation calculatoire de la réglementation

Documents et modèles conception

Dossiers analyse fonctionnelle

Réalisation et développements

Documentation applicative

Comp. SI 1

… … … …

Comp. SI 3 Comp. SI 2

… … … …

… … … …

Comp. SI 4

… … … …

Comp. SI 5

… … … …

Figure 1.5 – Pyramide reglemantaire et impact sur le SI.

1.4.3 Problematiques et enjeux de la maıtrise de la composante logicielle

La gestion de la composante logicielle se heurte a certain nombre de problema-

tiques de production et de gestion.

27

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

1.4.3.1 Problematiques de gestion et de production logicielle

De la meme maniere que pour la composante documentaire, les problematiques de

gestion et de production logicielle sont notamment liees a la conception et a la maintenance

de la composante logicielle.

Conception et production des ressources logicielles

Les ressources logicielles sont concues et developpees en fonction de deux types

d’exigences :

– exigences metier - il s’agit ici des exigences exprimees par les utilisateurs et qui

concernent le fonctionnement de l’application, l’interface utilisateur, la maniere

de l’utiliser, etc. .

– exigences reglementaires - il s’agit dans ce cas des exigences exprimees par

les textes reglementaires et qui visent la mise en conformite des applications

informatiques – la composante logicielle – avec les textes reglementaires. Cela

se traduit par le fait d’encoder en langage informatique les regles de gestion

definies par les textes reglementaire.

Quelque soit les exigences, le processus de prise en compte, de conception et de

developpement presente precedemment est respecte. En revanche, le temps necessaire a

chaque phase depend de la complexite de la demande. A chaque modification, meme mi-

nime, l’ensemble de ressources doit etre verifie afin de conserver un systeme de gestion

toujours conforme avec la legislation. Ainsi la prise en compte d’une evolution reglemen-

taire au niveau du Systeme d’Information peut etre tres couteuse.

Face a la frequence de l’identification des potentiels nouveaux besoins (en moyenne

deux modifications legislatives auxquelles s’ajoutent les nouveaux besoins fonctionnels

d’application metier), il devient indispensable de « fluidifier » le processus de conception.

Ainsi l’organisation mise en place permet de mener simultanement plusieurs chantiers de

conception et de developpement en utilisant les memes ressources logicielles.

Maintenance des ressources logicielles

Puisque les ressources logicielles sont concues et developpees pour repondre aux

exigences exprimees dans les textes reglementaires, elles peuvent etre percues comme le

fruit du prolongement du processus de creation du droit. Les regles, ainsi que la documen-

tation qui leur est associee, sont des objets qui doivent suivre rigoureusement les evolutions

de la legislation. Ainsi, lorsqu’un changement intervient au sein de la reglementation, il

est imperatif que celui-ci soit repercute sur les ressources logicielles afin de les conformer

au droit. Le processus de maintenance des objets reglementaires est semblable a celui de

creation. En effet, compte tenu de la complexite du systeme, le processus de conception

et de developpement est iteratif. La composante logicielle est continuellement enrichie,

amelioree pour repondre aux mieux aux exigences soit emanant des utilisateurs soit des

28

1.4. Composante logicielle - le Systeme de gestion des prestations legales

textes reglementaires. Le travail d’analyse et de maintenance conduit autour d’un tel sys-

teme est d’autant plus important que la reglementation du domaine est particulierement

changeante.

En outre, l’etendue de l’impact que peut avoir un changement de reglementation

ne se limite generalement pas au seul composant de gestion des prestations. Le Systeme

d’Information des CAF integre de nombreux autres composants et se caracterise par un

tres haut niveau d’interoperabilite. Il peut etre percu comme un maillage complexe de com-

posants logiciels dependant les uns des autres, et organises autour du composant central

qu’est le systeme de gestion des prestations. Le corollaire est que lorsque survient un chan-

gement reglementaire, fonctionnel ou technique, l’impact peut s’etendre sur l’ensemble du

Systeme d’Information et concerner des composants aussi divers que : les echanges avec

l’exterieur, les dispositifs d’acces aux donnees, les portails metiers ou public, les chaınes

editiques, la gestion des ressources humaines, la gestion des ressources financieres, la ges-

tion des partenaires, les referentiels des personnes, les applicatifs de gestion de l’action

sociale . . .

1.4.3.2 Enjeux de la maıtrise de la composante logicielle

L’analyse presentee dans cette section nous montre que les caracteristiques de

la composante logicielle et les problematiques de gestion associees sont similaires a celles

de la composante documentaire. Les enjeux associees a sa maıtrise sont par consequent

egalement comparables : tracabilite, maıtrise de la coherence et reactivite.

Tracabilite – Les prestations specifiques a chacun des allocataires sont calculees par

des applications informatiques qui analysent les donnees factuelles de l’allocataire

au regard de regles qui sont codees. Chaque attribution d’une decision presente ou

passee calculee par le systeme de gestion des prestations doit pouvoir etre justifiee a

l’appui du texte reglementaire en vigueur servant de base au calcul. Ainsi, tout code

executable doit pouvoir etre trace jusqu’au texte reglementaire exprimant l’exigence

reglementaire.

Maıtrise de la coherence – Le Systeme d’Information accompagne l’exercice metier de

l’organisation. Son fonctionnement doit etre coherent avec la legislation en vigueur.

Les regles, ainsi que la documentation qui leur est associee, sont des objets qui

doivent suivre rigoureusement les evolutions de la legislation. Lorsqu’un changement

intervient au sein de la reglementation, il est imperatif que celui-ci leur soit repercute

afin de les conformer au droit. L’evaluation de l’impact d’une modification reglemen-

taire sur un tel Systeme d’Information est un probleme qui prend toute son ampleur

lorsque l’on considere le grand nombre de regles implantees (e.g. le systeme de gestion

des prestations Cristal integre plus de 15 000 regles).

Reactivite – La capacite de l’organisation a reagir aux changements de la legislation est

29

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

un facteur determinant. Il est difficilement admissible que l’application d’une nou-

velle disposition reglementaire soit entravee par une indisponibilite de l’infrastructure

informatique necessaire a sa mise en application. Les evolutions de la reglementation

ont un impact parfois considerable sur le Systeme d’Information interne, et le pro-

cessus de mise en conformite de ce dernier n’est pas instantane. Pour ameliorer la

reactivite, il faut etre en capacite d’evaluer l’etendue des impacts afin de fournir une

estimation du temps necessaire a l’administration pour reagir face aux modifications,

et ce, des l’origine du projet legislatif ou reglementaire. Cette evaluation est menee

a partir de l’ensemble des textes reglementaires passes, presents et futurs, depuis les

documents les plus generiques jusqu’aux plus specifiques aux systemes d’information.

Par ailleurs, pour ameliorer le temps necessaire a la prise en compte des evolutions

reglementaires au niveau du Systeme d’Information, il faut etre capable de paralle-

liser les chantiers de conception et de developpement. Maintenir la coherence entre

les differents chantiers est donc une necessite.

Ainsi nous pouvons definir les services attendus pour repondre a l’ensemble des

problematiques de gestion concernant a la fois la composante documentaire et la compo-

sante logicielle.

1.5 Services attendus pour la maıtrise du patrimoine des

connaissances metier

Au cours de ce chapitre, nous avons analyse le role et la place que peut avoir la

matiere reglementaire au coeur d’organisations ou d’entreprises telles que la Cnaf.

La meme connaissance legislative se retrouve exprimee au travers de nombreuses

ressources a differents niveaux de l’entreprise : documents de reference, supports de forma-

tion, documentation metier, regles de gestion, composants du Systeme d’Information, etc.

Toutes ces ressources, qui encodent la connaissance necessaire pour que l’Institution mene

a bien sa mission, representent une reelle richesse pour l’organisation, un vrai patrimoine,

que l’on appelle : « patrimoine des connaissances metier ».

Les deux composantes (composante documentaire et composante logicielle) du

patrimoine des connaissances metier sont en apparence tres differentes. Bien qu’hetero-

genes dans la forme elles ont pourtant des proprietes equivalentes. En effet elles encodent

des connaissances du domaine, en l’occurrence des connaissances legislatives. Par ailleurs

elles sont formees par un ensemble structure et hierarchise de ressources fortement in-

terconnectees. De plus, elles doivent repondre a des problematiques de production et de

gestion semblables.

Apres cette analyse, la solution qui se distingue est de realiser l’unification des

ces deux composantes : composante logicielle et documentaire.

30

1.5. Services attendus pour la maıtrise du patrimoine des connaissances metier

Cette unification des composantes logicielle et documentaire peut etre realisee en

proposant d’une part des mecanismes de mise en relation de certains elements les compo-

sant et d’autre part en proposant des principes de production et de gestion communs.

Nous pouvons ainsi structurer le patrimoine des connaissances metier en un veri-

table referentiel de connaissances de l’organisation et le doter des principes de production

et de gestion capables de repondre aux enjeux institutionnels.

Pour assurer la coherence globale des connaissances exprimees dans l’ensemble des

ressources heterogenes du patrimoine reglementaire, il faut repondre aux problematiques

suivantes :

– la gestion de sa composante documentaire,

– la gestion de sa composante logicielle (l’implementation calculatoire de la re-

glementation),

– la tracabilite des connaissances exprimees tant au niveau documentaire qu’au

niveau logiciel : la meme connaissance se retrouve encodee dans plusieurs res-

sources avec plusieurs niveaux de details, pour plusieurs destinations,

– la maıtrise du lien qu’entretient le reste du Systeme d’Information (autre que

le systeme de gestion des prestations) avec le patrimoine reglementaire,

– identification et evaluation des impacts lies a une evolution reglementaire.

Par ailleurs les phenomenes observes depuis ce contexte particulier ne sont pas

propres au seul domaine des Prestations Familiales. Un grand nombre de ces constatations

peuvent etre generalisees a d’autres entreprises qui fondent leur action sur l’utilisation du

droit.

31

Chapitre 1. Maıtrise d’un patrimoine des connaissances metier

32

Chapitre 2

Etat des lieux dans la Branche

famille

Sommaire

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2 Demarche generale . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2.2 Maıtrise des connaissances metier - projet SIDoc/KM . . . . 34

2.3 Le referentiel de production et de gestion documentaire . 36

2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.3 Fonctions de base . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3.4 Fonctionnalites de gestion et de production documentaire . . 46

2.3.5 Architecture technique . . . . . . . . . . . . . . . . . . . . . 47

2.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.1 Introduction

Dans ce chapitre, nous dressons un etat des lieux de la Branche famille en presen-

tant la demarche adoptee pour apprehender la problematique complexe liee a la maıtrise

de son patrimoine des connaissances metier. Nous detaillons egalement le contexte de

realisation de nos travaux de recherche.

Etant donne le caractere strategique des enjeux auxquels doit repondre la maıtrise

du patrimoine des connaissances metier (documentaire et logiciel) de la Branche famille,

la Cnaf mene un vaste projet de recherche et de developpement visant la gestion des

connaissances pour leur capitalisation et leur partage. Ce projet a abouti a la mise en

place d’un Referentiel de gestion et de production documentaire qui sera decrit en detail

dans la section 2.3 du present manuscrit.

33

Chapitre 2. Etat des lieux dans la Branche famille

2.2 Demarche generale

2.2.1 Introduction

La problematique exprimee ici puise ses origines dans le contexte de la Branche

famille. Elle constitue la principale motivation de notre travail ; la demarche generale

adoptee par les projets de recherche a la Cnaf est presentee dans la figure 2.1.

Suite a une analyse approfondie, cette problematique specifique a notre Institu-

tion se revele egalement appropriee a d’autres organisations ayant la meme mission de

mise en application de la legislation voire plus generalement a tout type de structure. La

generalisation de notre problematique nous permet de nous affranchir des specificites de

notre organisation dans notre travail de recherche.

L’etat de l’art du domaine est analyse pour identifier les travaux susceptibles

d’apporter leur contribution a la consolidation d’une solution. Si l’etat de l’art et les

travaux connexes en cours ne repondent pas completement a notre problematique, une

etape de recherche est engagee.

Les resultats de cette etape de recherche seront formalises dans le cadre d’une

contribution scientifique et valides lors de differentes communications en lien avec la com-

munaute scientifique.

Les principes proposes issus de l’etape de recherche font systematiquement l’objet

d’une validation a l’aide d’un prototype. Celui-ci nous permet de tester la faisabilite de

l’implementation dans le cadre de l’organisation. Le prototype est egalement l’occasion

d’adapter la proposition scientifique generique au cas specifique de notre organisation afin

d’apporter une reponse concrete a la problematique soulevee initialement.

Le prototype est ainsi le support d’une evaluation operationnelle par les futurs

utilisateurs. La proposition ainsi validee donnera suite a un projet institutionnel qui visera

a fournir a l’organisation les services manquants dont elle a besoin.

2.2.2 Maıtrise des connaissances metier - projet SIDoc/KM

Dans ce contexte, plusieurs theses ont ete engagees en partenariat avec l’Association

Nationale de la Recherche Technique - ANRT dans le cadre d’un dispositif contrat CIFRE 4

et avec le laboratoire LIRIS 5.

Comme presente dans la figure 2.2, la Cnaf a applique la demarche dans plusieurs

projets de recherche traitant diverses problematiques :

1. Gestion logique des documents – Les travaux de Bertrand Chabbat portent sur la mo-

delisation multiparadigme des textes reglementaires. Ils proposent une structuration

4. Convention Industrielle de Formation par la Recherche5. Laboratoire d’InfoRmatique en Images et Systemes d’Information (Lyon)

34

2.2. Demarche generale

Analyse de l’état de l’art

Proposition scientifique

Prototype pilote

Contexte de l’organisation

Généralisation de la problématique

Problématique spécifique

Projet institutionnel

Niveau générique

Niveau spécifique

Figure 2.1 – Demarche de recherche a la Cnaf.

des textes reglementaires en utilisant des langages de balisage [ISO 86]. Ces travaux

ont fait l’objet d’une these de doctorat CIFRE soutenue en 1997 [Chabbat 97].

2. Gestion des connaissances et de la composante documentaire – Dans ses travaux sur

la modelisation semantique de la reglementation, David Jouve [Jouve 03a] propose

un systeme base sur la representation des connaissances pour garantir la coherence

des textes reglementaires entre les differents niveaux de la pyramide reglementaire. Il

complete ainsi la maıtrise logique proposee par les travaux de Bertrand Chabbat avec

des mecanismes de maıtrise des connaissances dans la composante documentaire. Ces

travaux ont fait l’objet d’une these de doctorat soutenue en 2003.

3. Maıtrise de la composante logicielle et de la relation avec le patrimoine documen-

taire – Cette problematique a ete traitee par le projet de recherche decrit dans ce

manuscrit. Il ambitionne d’etendre la maıtrise de la composante documentaire, ob-

tenue grace aux precedents travaux, a la composante logicielle, permettant ainsi une

maıtrise globale du patrimoine reglementaire.

Par ailleurs, cette maıtrise des ressources documentaires et du Systeme d’Infor-

mation est necessaire pour accroıtre la capacite de la DSI 6 a reagir aux changements

de legislation et ainsi assurer la coherence globale tout au long du processus de mise en

application de la legislation.

Les resultats des deux premiers travaux de recherche, valides par des prototypes

respectifs, ont donne suite a un projet institutionnel appele SIDoc/KM – Systeme d’In-

6. Direction du Systeme d’Information

[ISO 86] International Organization for Standardization. Standard Generalized Markup Language

(SGML). International Standard ISO 8879 :1986(E), Octobre 1986. 155 p.

[Chabbat 97] Voir reference [Chabbat 97] definie page 2.

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

35

Chapitre 2. Etat des lieux dans la Branche famille

Modélisation sémantique de la réglementation

Modélisation multiparadigme des textes réglementaires

Travail actuel

1997 2000 2003 2005

Démarche projet Pilote Déploiement institutionnel

Démarche projet

Pilote Déploiement institutionnel

Recherche

Recherche Démarche projet

Pilote

Recherche

Déploiement institutionnel

2008 Travaux de recherche

Aujourd’hui

Maîtrise des connaissances et de la composante documentaire

Maîtrise logique

Maîtrise de la composante logicielle et de la relation avec le patrimoine documentaire

Problématique 2009

Figure 2.2 – Projets de recherche a la Cnaf.

formation Documentaire - Knowledge Management. Ce projet vise a la mise en place du

Referentiel de production et de gestion documentaire decrit brievement dans la section 2.3

de ce chapitre. Ce referentiel offre les services necessaires a la maıtrise et a la capitalisation

des connaissances encodees dans des ressources documentaires (composante documentaire

du patrimoine reglementaire). Il adresse des fonctionnalites telles que la gestion de cycle

de vie, la gestion des modes d’acces, la recherche d’information, etc..

L’actuel projet de recherche se deroule en parallele du projet de developpement

institutionnel et participe a son effort de conception. Cette collaboration nous permet de

proposer une demarche coherente du point de vue logique mais egalement technique et

conceptuel entre le projet d’entreprise et le projet de recherche.

Le projet SIDoc/KM repond a une partie de la problematique enoncee precedem-

ment. L’actuel projet de recherche et de prototypage a pour but de preparer les idees et les

principes a mettre en oeuvre pour etendre l’offre de services et pour offrir une couverture

fonctionnelle totale dont l’Institution a besoin :

– etendre la gestion a la composante logicielle du patrimoine reglementaire,

– maıtriser la coherence globale du patrimoine reglementaire et du Systeme d’In-

formation,

– etudier l’impact et estimer les evolutions necessaires.

2.3 Le referentiel de production et de gestion documentaire

Nous avons vu precedemment que les textes reglementaires externes representent

une matiere premiere pour la Branche famille. Une production documentaire interne a

l’Institution vient enrichir l’ensemble des textes reglementaires externes, avec des docu-

ments qui affinent et traduisent ces connaissances juridiques dans un langage metier plus

operationnel. Ces documents explicitent la connaissance metier de l’organisation.

Dans cette section, nous allons presenter le referentiel de production et de gestion

documentaire, infrastructure pour la capitalisation des connaissances.

36

2.3. Le referentiel de production et de gestion documentaire

2.3.1 Introduction

Le processus institutionnel de management des connaissances (dont ce referentiel

est un outil important) vise a maıtriser les risques lies a :

– la complexification des legislations (prestations, action sociale, comptabilite,

etc.) et aux contentieux possibles ;

– la multiplication des vecteurs de diffusion de la connaissance (internet / extra-

net / intranet) ;

– l’evolution rapide de la pyramide des ages presente dans toutes les organisa-

tions ;

– les transformations organisationnelles ou territoriales (mutualisation, externa-

lisation, etc.).

Ainsi, ce referentiel doit pouvoir accueillir l’ensemble des ressources qui ont une

valeur de reference, c’est-a-dire toutes les ressources qui seront par la suite reutilisees et

dont la capitalisation est strategique. De meme, ce referentiel doit offrir les services ne-

cessaires au travail collaboratif de production documentaire. Il doit se positionner comme

un catalyseur pour la transformation de la connaissance tacite en connaissance explicite

(lors du processus de creation de contenu) d’une part, et de la connaissance explicite en

connaissance tacite(lors de la consultation du contenu pour appropriation par des em-

ployes) d’autre part.

Il est dote d’un ensemble de fonctions et de fonctionnalites supportant :

– l’acces a la connaissance ;

– le processus de production collaborative et d’enrichissement des connaissances ;

– les mecanismes pour la maıtrise de la coherence du referentiel.

Dans ce chapitre, nous allons presenter l’architecture du Systeme d’Information

Documentaire – le referentiel de production et de gestion des connaissances metier. Nous

attacherons beaucoup d’importance a la partie structuration des ressources pour pouvoir

integrer le referentiel en detaillant le cas des ressources documentaires textuelles et celui

des ressources de modelisation, modeles UML du Systeme d’Information.

Ce chapitre a pour vocation de presenter un resume synthetique de la demarche

employee et des principales fonctionnalites offertes aux utilisateurs ; nous ne souhaitons pas

etablir une documentation de specification et conception ou une documentation utilisateur

des services et composants du referentiel. Pour une description detaillee de l’implementa-

tion, nous vous proposons de consulter la documentation projet [CNEDI 07a].

[CNEDI 07a] Centre National d’Etudes et du Developpement Informatique Rhone-Alpes, 128 rue ser-

vient, 69003 Lyon. Documentation du projet SIDoc, 2007.

37

Chapitre 2. Etat des lieux dans la Branche famille

2.3.2 Architecture logique

La maıtrise des connaissances hebergees par le referentiel passe par une maı-

trise de la structuration des ressources qui les encodent. Le referentiel de gestion et de

production des connaissances contient ainsi un ensemble de « collections documentaires ».

Definition 2.3.1. Collection documentaire du referentiel de production et de gestion des

connaissances – Une collection documentaire du referentiel SIDoc est definie de la facon

suivante :

– c’est une composante du referentiel de production et de gestion documentaire,

– est formee par un ensemble de contenus non redondant et maintenu en cohe-

rence avec celui des autres collections,

– a une thematique et un perimetre clairement determines,

– s’adresse a un public(s) cible(s) avec une ligne editoriale definie en fonction

d’un usage cible.

La maıtrise du referentiel est egalement assuree par la maıtrise de la production

des connaissances qui y sont deposees. Pour chaque collection du referentiel, en fonction

de son contenu, de sa thematique et du public cible, il faut clairement definir une res-

ponsabilite editoriale et une unite d’organisation. Il s’agit donc d’assurer une production

documentaire respectant la thematique et le perimetre traites ainsi que la ligne editoriale

fixee.

Nous nous inscrivons ainsi dans une tendance de plus en plus presente, notamment

avec la mouvance Web 2.0, qui se caracterise par une facilitation des echanges, du partage

des connaissances et du travail collaboratif. Mais contrairement aux tendances Web 2.0,

une responsabilite redactionnelle forte est necessaire pour chaque contenu afin de garantir

la coherence globale du patrimoine des connaissances et sa diffusion. Le controle de la

communaute des utilisateurs ne suffit pas a lui seul pour satisfaire les contraintes de

conformite liees a un environnement dedie a la mise en application de la legislation.

2.3.2.1 Description d’une collection

Chaque collection, composee d’un ensemble de ressources, est structuree par les

definitions suivantes :

Categories de ressources – Les ressources peuvent appartenir a plusieurs categories.

Elles peuvent etre soit des ressources documentaires, soit des ressources binaires,

soit des ressources applicatives (des services associes a la collection).

Types de ressources – Chaque categorie de ressources a plusieurs types. Pour la cate-

gorie de ressources documentaires, le type de ressources designe le type de document.

Le type d’un document definit a la fois sa structure, son cycle de vie, les fonctions

38

2.3. Le referentiel de production et de gestion documentaire

disponibles et la maniere dont il est accessible (positionnement par defaut dans le

plan de classement, habilitations des utilisateurs).

Types de references – Nous avons vu precedemment que les relations existant entre les

elements composants du referentiel (un document, un fragment de document) sont

variees. La definition de la typologie des liens de reference nous permet d’expliciter

les specificites et les actions particulieres associees a une reference.

Description des taxonomies – L’acces au contenu est facilite par l’utilisation de taxo-

nomies. Elles sont definies au niveau de chaque collection, leur classement s’effectu-

rant par la suite au moment de l’edition de l’objet.

Description des docflows – Les docflows (workflow documentaire) decrivent le cycle de

vie des objets et gerent les fonctions disponibles selon les etats du document.

Description des fonctions – Chaque collection dispose d’un ensemble de fonctions de

gestion et de production documentaire.

Description des modules – Chaque collection dispose d’un ensemble de modules offrant

des fonctionnalites supplementaires de gestion (recherche d’information, tableaux de

bord, tableaux de suivi).

Definition des habilitations – Pour chaque collection, l’acces des utilisateurs et leur

role dans le processus de gestion et de production des connaissances sont definis a

l’aide des habilitations.

La figure 2.3 presente la structure de definition d’une collection.

2.3.3 Fonctions de base

2.3.3.1 Gestion de la persistance

Pour eviter la redondance caracteristique du domaine legislatif, deux structures

sont utilisees : une structure de representation et une structure de presentation des docu-

ments.

La structure de representation d’un document – la maniere dont celui-ci est mo-

delise et stocke par le systeme de gestion documentaire. Cette representation est

importante pour l’archivage, l’indexation et la recherche d’information.

la structure de presentation d’un document – la maniere dont celui-ci est presente

a l’utilisateur. Dans notre cas, les documents presentes aux utilisateurs contiennent

une information plus riche et plus detaillee que celle stockee par le systeme de ges-

tion documentaire. Pour eliminer la redondance, l’information est distribuee dans

le referentiel et des liens de references de plusieurs types sont utilises. La presen-

tation d’un document est donc une agregation des informations issues de plusieurs

representations persistantes.

39

Chapitre 2. Etat des lieux dans la Branche famille

Collection

Type d’objet Module Type de lien Taxonomie

Docflow Groupe de fonction

Règle d’habilitation

Fonction

Association

Agrégation

Légende

Figure 2.3 – Modele logique d’une collection du referentiel de gestion et de productiondes connaissances metiers.

2.3.3.2 Structure de base de stockage des documents

Les documents d’une collection sont types. Neanmoins ils respectent tous, inde-

pendamment de leur type, la meme structure de base decrite par le schema XSD [W3C 01e]

des objets du referentiel. Une forme graphique de ce schema est presentee dans la figure

2.4. Un exemple d’instanciation, pour un objet documentaire du referentiel, de ce schema

XSD est presente dans la figure 2.5.

Pour illustrer nos exemples, nous avons essaye plusieurs produits, mais un seul,

XML Spy, est pleinement exploite dans le present manuscrit. XML Spy [Altova 09] est un

produit evolue et fonctionnellement riche, qui permet d’editer des DTD et des schemas

XML ainsi que des instances XML. Il contient des convertisseurs, notamment en repre-

sentations graphiques et des generateurs automatiques d’instances et de modeles, qui se

revelent pratiques en phase d’etude.

Cet exemple nous permet de presenter les elements les plus importants retrouves

au niveau de la structure de stockage du document.

L’identifiant du document et son type sont specifies par les deux attributs de

plus haut niveau : object-id et type. L’element meta est identique pour tous les documents.

Il contient des informations concernant l’identifiant de version, le numero de revision et

[Altova 09] Voir reference [Altova 09] definie page 40.

40

2.3. Le referentiel de production et de gestion documentaire

Légende

Séquence d’éléments XML

Elément complexe - contient des nœud enfant

Elément texte (type xs:string)

Elément optionnel

Elément obligatoire

Figure 2.4 – Schema d’un objet generique du referentiel SIDoc. Representation graphiquerealisee avec l’editeur XML XMLSpy [Altova 09].

d’edition, l’origine du document (contexte de la creation ou de la suppression du docu-

ment) ainsi que des informations concernant l’etat et l’historique du document. L’element

content contient les informations specifiques a chaque document. L’element meta est uti-

lise par le systeme alors que l’element content contient des donnees necessaires a la pre-

sentation du document (l’identifiant publique, le libelle, la description, etc.). Par ailleurs,

en utilisant des mecanismes de « XML-wrapping », 7 tout autre contenu peut y etre depose.

7. Nous appelons XML-wrapping les mecanismes permettant d’associer a n’importe quel objetune structure XML predefinie - par exemple associer la structure de l’objet definie par le schema 2.4 a une

41

Chapitre 2. Etat des lieux dans la Branche famille

<object object-id="00001221" type="donnee">

<meta>

<version ver="REF" rev="0001" ed="0001" />

<origin>

<creation>

<ref col="sair-daf" kind="docobject" type="tache"

res="00000003" ref-type="originContent"/>

<reason>Reprise de l’existant</reason>

</creation>

</origin>

<current-state uri="integre-reference"/>

<history>

<created user="Administrator" date-time="2006-10-11T16:46:20"/>

</history>

</meta>

<content>

<public-id>C10LN001</public-id>

<label>AS code nature prestation</label>

<autres-elements-specifiques>

. . .

</autres-elements-specifiques >.

.....

</content>

</object>

Figure 2.5 – Exemple d’un objet documentaire de l’infrastructure SIDoc .

Cette structure de base est adaptee en fonction de la categorie et du type de la ressource.

Nous travaillons ainsi avec un ensemble de schemas XML.

2.3.3.3 Gestion des revisions et des versions

Un espace de reference contient l’ensemble de la documentation disponible dans

un etat stable et valide, appele « version de reference ». Pour repondre a chaque evolution

de la documentation, un nouvel espace de travail est cree a partir de la version de reference,

contenant les documents qui doivent etre ajoutes, supprimes ou mis a jour (voir la figure

2.6). Plusieurs demandes d’evolution peuvent etre traitees en meme temps, en creant

plusieurs espaces de travail en parallele. Au sein de chaque espace de travail, les redacteurs

ont acces aux fonctions et fonctionnalites du systeme. Les versions de travail des documents

suivent leur cycle de vie, produisant de multiples revisions successives. A tout moment,

les redacteurs peuvent synchroniser leur version de travail avec la version de reference.

Une fois que la version de travail est validee, toutes les modifications vont etre

integrees dans l’espace de reference. Les autres espaces de travail peuvent alors se synchro-

niser pour beneficier des dernieres contributions.

image dont le code sera stocke sous la balise <content>

42

2.3. Le referentiel de production et de gestion documentaire

Figure 2.6 – Gestion en parallele des espaces de travail et des versions multiples.

2.3.3.4 Identification des ressources

Le referentiel SIDoc propose des mecanismes pour l’identification des documents

et son adressage.

Identification Dans un environnement multi-revisions et multi-versions, il est primor-

dial d’identifier precisement un document. L’identification doit pouvoir :

– identifier de maniere unique un document, une version ou une revision,

– etre independante de l’emplacement physique du document sur le support de

stockage,

– etre independante des informations modifiables dans le document.

Pour ce faire, une solution est l’utilisation des URN Universal Resource Name. Une

revision d’un document est identifiee par un unique URN constitue comme suit :

URN := collection-uri : resource-kind : resource-type : resource-id

[ : version : revision]

ou :

– collection-uri : represente l’identifiant URI Universal Resource Identifier de

la collection ;

– resource-kind : represente la categorie de ressource (e.g. un document, un

service, une resource binaire) ;

– resource-type : chaque categorie de ressources peut avoir plusieurs types de

ressources (e.g. les documents peuvent etre des documents de suivi legislatif,

des documents decrivant une donnee, une classe logicielle) ;

43

Chapitre 2. Etat des lieux dans la Branche famille

– resource-id : chaque ressource est identifiee a l’aide d’un identifiant unique.

Celui-ci est fixe a la creation de la ressource par le systeme afin d’assurer son

unicite. Ce champ de l’URN est renseigne avec la valeur de l’attribut object-id

de chaque document ;

– version : represente l’identifiant de la version de l’objet. Il correspond egale-

ment a l’identifiant de l’espace de travail ou de reference dans lequel se trouve

l’objet documentaire ;

– revision : represente le numero de revision. Une nouvelle revision est creee a

chaque evolution consideree comme importante du document (apres une etape

de validation).

Resolution des URN Considerant le grand nombre de documents, il est essentiel d’as-

surer l’integrite du referentiel. Ce mecanisme d’identification des ressources nous permet

de disposer d’un modele ou chaque ressource est identifiee de maniere unique et ou un

objet peut etre deplace sans affecter son identification et les objets qui le referencent.

La resolution des URN va permettre d’identifier le document physique associe en

prenant en compte l’identifiant unique mais egalement les identifiants de la version et de

la revision demandees.

Une revision precise est identifiee par l’identifiant de la ressource, par sa version,

et par sa revision. Si aucun identifiant de revision n’est specifie, la derniere revision active

est alors selectionnee. Si aucun identifiant de version n’est specifie, le document est alors

choisi dans la version courante ou, a defaut, dans la version de reference.

L’avantage de ce systeme d’interpretation des URNs est la flexibilite d’adressage

des documents. Nous pouvons toujours adresser la derniere revision d’un document, meme

si celui-ci evolue. De la meme maniere, nous pouvons toujours specifier une revision pre-

cise, meme si celle-ci devient obsolete. Ainsi, des documents dans des espaces d’editions

paralleles peuvent etre references sans interference.

2.3.3.5 Gestion des references

Les documents contenus dans le referentiel des connaissances ont une forte valeur

de reference. Leur contenu ne doit pas etre redondant, il faut reutiliser au maximum des

fragments de documents. Ainsi la gestion des liens et des references est un probleme crucial.

Toute l’information concernant un document est stockee avec celui-ci. Toute mise

a jour est alors disponible. Le libelle des liens est recupere au moment de la resolution de

ces liens.

Implementation Une reference est encodee sous forme d’un nœud XML contenant un

ensemble d’attributs dont les valeurs sont liees a l’URN de la ressource cible, presente dans

la figure 2.7.

44

2.3. Le referentiel de production et de gestion documentaire

<ref col="sair-daf" kind="docobject" type="tache" res="00000003"

[ver="REF" rev="0001" nodes="id1 id2" ref-type="originContent"]/>

Figure 2.7 – Exemple d’element XML representant une reference.

Les attributs col, kind, type, res definissent l’URN de la ressource referencee.

L’attribut optionnel nodes nous permet d’adresser un sous-fragment specifique d’un do-

cument.

Resolution des references Le libelle du document reference ainsi que sa description

et son type sont recuperes au moment de la resolution des liens. Si l’attribut nodes est

present, les sous-fragments identifies dans le document cible sont egalement recuperes au

moment de la resolution.

L’attribut ref-type decrit le type de lien de reference et eventuellement les ac-

tions a mener au moment de la restitution de ce lien. Un contenu supplementaire peut

etre recupere et ajoute a la forme de presentation du document appelant.

Types de references :

– references simples : une ressource faisant appel a une autre ressource, lien de

reference de base ;

– reference specialisee : l’attribut ref-type est present et il definit la semantique

de la reference. En fonction de la definition de cette semantique, le systeme va

operer les transformations necessaires pendant la phase de construction de la

forme de presentation du document appelant.

2.3.3.6 Docflow – workflow documentaire

Chaque type de document est caracterise par un cycle de vie. Chaque document

est associe a un moment donne a un etat dans son cycle de vie. Ce-dernier definit les

fonctions dont dispose l’utilisateur selon ses habilitations.

Le moteur docflow ecoute les evenements externes (fonctions actives, appel des

services, etc..) ou internes (envoyes par d’autres ressources suite a des transitions ou des

actions executees). Ces evenements peuvent, si toutes les conditions sont remplies, activer

des transitions vers un autre etat. Des actions peuvent etre executees sur une transition, a

la sortie ou a l’entree, dans un nouvel etat avec eventuellement des impacts sur l’evolution

du docflow des documents connexes. La figure C.1 de l’annexe C presente le docflow de

production d’un document de la collection Dossier d’analyse fonctionnelle. Le cycle de vie

est compose d’une succession d’etats (ex : planifie, En cours, A consolider, Consolide, etc.)

et de transitions entre ces etats. Les etats ainsi que les modalites de transition (declen-

chees par une action de l’utilisateur, par des conditions specifiques ou par des evenements

exterieurs) sont definis apres une analyse fonctionnelle approfondie des besoins en matiere

45

Chapitre 2. Etat des lieux dans la Branche famille

de production documentaire et de travail collaboratif.

2.3.3.7 Indexation et Recherche d’information

La recherche d’information est tres flexible et permet aux utilisateurs d’affiner

l’expression recherchee par un ou plusieurs mots-cles ou phrases. L’utilisateur peut spe-

cifier davantage sa recherche en precisant des informations signaletiques de la ressource :

identifiant, type de document, etat en cours, date de modification, etc.

2.3.3.8 Gestion de l’integrite et des acces

Le systeme doit assurer l’integrite des ressources et reglementer l’acces a celles-ci

en fonction des habilitations definies pour chaque role des utilisateurs.

2.3.3.9 Aide a l’utilisateur

Dans tout systeme de gestion, nous avons besoin d’une gestion de connaissances

sur les taches de l’utilisateur afin de lui faciliter l’appropriation de l’outil.

2.3.4 Fonctionnalites de gestion et de production documentaire

2.3.4.1 Referentiel unique

Le referentiel SIDoc est l’endroit unique pour la production et la gestion do-

cumentaire. De ce fait les connaissances sont gerees a un seul endroit et les differentes

applications puisent dans ce referentiel pour creer un contenu adapte a chaque besoin.

L’information presente dans le referentiel peut eventuellement etre adaptee en fonction du

canal de diffusion (intranet, extranet, internet) ou du profil de l’utilisateur.

Le referentiel introduit alors une nette distinction entre la production documen-

taire et la diffusion. Il offre un environnement de production dote des fonctions et fonc-

tionnalites enrichies visant a ameliorer la capitalisation des connaissances.

Par ailleurs, les fonctions de base d’identification, de referencement et les algo-

rithmes de resolution de liens nous permet de reduire la redondance (tres frequente dans

le cadre des ressources legislatives), sans diminuer les performances globales du systeme.

Un lien peut referencer soit la derniere revision du document, soit une revision

precise meme si celle-ci est obsolete. Le lien peut egalement, en utilisant l’attribut node, ne

referencer qu’une sous-partie d’un document. L’utilisation du type de reference (attribut

ref-type) nous permet d’associer une semantique particuliere a chaque lien (par exemple :

lien de reference vers l’origine du document, lien de dependance dans le processus de

production, lien de similarite, etc. ) et ainsi definir la maniere donc celui-ci est resolu au

moment de la presentation de la ressource (recuperation du contenu supplementaire, etc.).

46

2.3. Le referentiel de production et de gestion documentaire

2.3.4.2 Gestion du processus de production documentaire

Pour garantir la coherence du referentiel, les responsabilites doivent etre claire-

ment definies tout au long du processus de production et de gestion documentaire. Les

fonctions de docflow nous permettent de preciser l’automatisation du processus de produc-

tion, les roles de chaque participant, le flux de documents, de ressources et d’information

d’un etat a un autre.

Pour chaque collection documentaire, les roles de chaque intervenant ainsi que

les circuits de production sont precisement definis. Par exemple nous pouvons avoir des

contributeurs aux documents, des personnes en charge de la relecture, d’autres en charge

de la validation des documents qui vont intervenir tout au long du cycle de vie des objets

(le docflow de l’objet).

2.3.4.3 Tracabilite de l’information et des connaissances

La gestion des liens et de leur semantique nous permet de tracer (en suivant les

liens types) l’utilisation qui est faite d’une connaissance dans tout le referentiel. L’his-

torique des metadonnees nous permettent de tracer l’evolution de ces connaissances, les

mises a jour des ressources ainsi que les differentes contributions des utilisateurs.

Le patrimoine des connaissances est constamment mis a jour pour ameliorer l’exis-

tant ou pour repondre a de nouveaux besoins. L’historique de chaque ressource nous four-

nit les informations necessaires afin de tracer toutes les interventions effectuees sur une

ressource, et de les lier aux expressions d’exigences formulees.

Par exemple, l’application SIDoc permet de saisir les liens de dependances entre

les documents (raison de la creation ou de la modification d’un document, impacts d’un

document sur d’autres documents existants, etc.) Ces liens seront ensuite exploites pour

l’etude d’impact.

2.3.4.4 Analyse des dependances, etude d’impact et estimations des charges

associees aux evolutions

La structuration des ressources et les liens de reference definis entre les elements

du referentiel (inter et intra collections) servent de base pour l’instanciation d’un graphe

d’analyse des dependances et d’etude d’impact. Les mecanismes de raisonnement associes

a ce graphe sont presentes en detail dans [Vasutiu 06] ; ils realisent l’etude d’impact et une

estimation des charges associees aux evolutions.

2.3.5 Architecture technique

Le referentiel de production et de gestion des connaissances a ete developpe selon

une architecture n-tier presentee par la figure 2.8 dont une presentation succincte des

47

Chapitre 2. Etat des lieux dans la Branche famille

differentes couches sera faite dans la suite de ce paragraphe.

Figure 2.8 – Architecture technique n-tier SIDoc.

2.3.5.1 Couche persistance et acces aux donnees

La couche persistance assure la gestion du stockage des ressources et de leur

integrite en vue d’archivage, mise a jour, recherche d’information ou suppression. Suite

aux arguments presentes dans l’etat de l’art, nous avons fait le choix d’une base native

XML 8 accompagnee d’une definition des modeles en utilisant les schemas XSD [W3C 01e].

Les couches superieures de l’application utilisent la couche specialisee d’acces aux

donnees DAO (Data Access Objects) qui realise une abstraction du choix technologique

en matiere de persistance. Cette couche a ete definie lors des phases de conception de

l’architecture de l’application SIDoc (voir figure 2.8).

8. Les bases natives XML se basent sur un modele logique du document pouvant ainsi stockerdirectement tout type de contenu XML [Suciu 01].

48

2.3. Le referentiel de production et de gestion documentaire

2.3.5.2 Couche service

La couche service contient tous les services necessaires a la production et gestion

du referentiel. En plus des services de base comme le chargement et l’enregistrement des

objets, un ensemble de ressources a ete mis en place visant a repondre aux besoins de

gestion plus avances. Ces services correspondent aux implementations des fonctions definies

au paragraphe 2.3.3 : taxonomie, gestion des revisions, docflow, gestion des habilitations,

index et recherche d’information, acces aux ressources.

2.3.5.3 Couche controle et presentation

La couche controle interprete les actions des utilisateurs identifiees au niveau de

la couche presentation et les redirige vers le service approprie.

La couche presentation est composee de differents types de clients, comme par

exemple :

– le client leger - au sens logiciel, il est represente par le navigateur ; il depend

entierement du serveur pour toute la logique applicative et pour toutes les

donnees,

– le client lourd - logiciel qui dispose de toutes les fonctionnalites necessaires ; il

ne depend du serveur que pour l’echange des donnees,

– le client riche - il apporte une plus grande richesse dans les interfaces des clients

legers, le rapprochant du niveau de fonctionnalites des clients lourds,

– les applications externes - d’autres applications du SI qui s’interfacent avec le

serveur de l’application.

La plupart des ressources gerees par le referentiel utilisent actuellement une inter-

face utilisateur de gestion et de production sous forme de client riche. Il s’agit d’un client

web enrichi des fonctionnalites grace aux nouvelles approches telles qu’AJAX – Asynchro-

nous JavaScript and XML. La couche service fournit a la couche presentation le contenu

des objets en format XML. L’ensemble des processeurs de rendu transforme la structure

XML en une forme comprehensible par le client utilisateur. Dans le cadre des navigateurs

Internet, la plupart des interfaces utilisateurs de presentation des ressources du referen-

tiel sont definies a l’aide du langage XForms [W3C 07a]. Des processeurs de rendu tels

que Chiba [Chiba 08] permettent de generer le code source HTML a envoyer aux naviga-

teurs. D’autres clients peuvent eventuellement travailler directement a partir des flux XML

fournis par les services de chargement, par exemple les editeurs XML « client lourd ».

L’image 2.9 montre une copie d’ecran de l’application SIDoc dans un navigateur

Web.

L’ecran de l’application est divise en trois grandes zones :

1. zone de menu - zone en haut, cette zone permet l’acces aux fonctionnalites de l’ap-

plication : choix de la collection documentaire, lancement des outils de suivi de la

49

Chapitre 2. Etat des lieux dans la Branche famille

production documentaire, acces aux fonctions disponibles sur le document courant

(edition, sauvegarde, publication, etc.),

2. plan de classement - zone a gauche, plusieurs taxonomies peuvent etre definies,

permettant de proposer une classification des objets selon des categories definies par

l’utilisateur,

3. zone de visualisation du document - zone centrale, zone dans laquelle le formulaire

du document est affiche soit en consultation soit en edition.

2.3.6 Conclusion

Nous avons presente dans cette section le « Referentiel de gestion et de production

documentaire – SIDoc » de l’Institution. Les fonctionnalites proposees par ce referentiel

permettent de fournir les premiers services necessaires a la gestion et la production du

patrimoine documentaire. En revanche il ne dispose pas des fonctionnalites necessaires

pour l’identification et l’evaluation des impacts liees a une evolution reglementaire. Aussi, il

ne permet pas de fournir les services necessaires pour la gestion du Systeme d’Information.

Dans la partie problematique, nous avons vu que les services necessaires a la gestion du

Systeme d’Information sont similaires a ceux necessaire pour la gestion du patrimoine

documentaire.

50

2.3. Le referentiel de production et de gestion documentaire

Zon

e de

vi

sual

isat

ion

/ éd

ition

du

doc

umen

t

Pla

n de

cla

ssem

ent

Zon

e de

men

u

Figure 2.9 – Capture d’un ecran du referentiel SIDoc.

51

Chapitre 2. Etat des lieux dans la Branche famille

52

Conclusions

Au cours de cette partie, nous avons mis en evidence les caracteristiques de la

matiere reglementaire sur les deux volets : documentaire et logiciel.

Ainsi nous avons identifie les similarites entre ces deux ressources heterogenes

mais comparables du point de vue de leur role joue dans la gestion des connaissances.

Cette analyse nous permet, par la suite lors de la construction de notre proposition, d’ap-

prehender de la meme maniere les deux composantes du patrimoine des connaissances

metier.

Ensuite, le deuxieme chapitre de cette partie a presente un etat des lieux de

la Branche famille en precisant la demarche adoptee pour apprehender cette problema-

tique complexe, les projets engages ainsi que le contexte servant de cadre a notre travail.

Nous avons egalement presente le « Referentiel de gestion et de production documentaire

– SIDoc », l’outil de gestion de la composante documentaire.

La conclusion a laquelle nous a conduit cet expose est qu’une veritable maıtrise

de la matiere reglementaire, pour faire face aux changements recurrents de la legislation,

doit prendre en compte de maniere globale les deux volets : documentaire et logiciel.

Nous devons ensuite etudier comment integrer au sein du referentiel SIDoc les res-

sources du Systeme d’information (les modeles applicatifs, la documentation de conception,

le code source, etc. ) et comment les mettre en relation avec le patrimoine documentaire.

Pour cela il faut pouvoir repondre aux questions suivantes :

– comment representer les ressources du Systeme d’Information afin de les inte-

grer au sein du referentiel SIDoc qui se base sur la norme XML? Comment

trouver une structure commune a ces deux types de ressources ?

– comment unifier les deux composantes (identifier le lien entre les documents et

les composants du SI) ?

– comment identifier les impacts d’une evolution fonctionnelle ou legislative au

sein du referentiel couvrant a la fois la composante documentaire et la compo-

sante logicielle ?

– comment estimer l’etendue d’un impact et des charges associees a une evolu-

tion ?

Nos propositions pour l’etude d’impact, presentees dans la troisieme partie du

53

Conclusions

manuscrit, tentent d’apporter les reponses necessaires a ces interrogations.

54

Deuxieme partie

Etat de l’art

55

Introduction

La problematique exprimee dans la premiere partie de ce manuscrit se situe au

carrefour de plusieurs grands domaines de recherche : la gestion des connaissances, l’in-

genierie documentaire et la conception des Systemes d’Information. Les recherches biblio-

graphiques nous ont permis de couvrir certaines parties de ces domaines.

Nous presentons dans les trois chapitres de cette deuxieme partie une analyse des

travaux de recherche dans ces trois domaines.

Tout d’abord, nous nous interessons au domaine de l’ingenierie documentaire.

Nous presentons les travaux realises pour la structuration documentaire.

Le deuxieme chapitre de cette partie detaille les travaux en cours sur la maıtrise

des Systemes d’Information en analysant les differentes methodologies de conception et

de developpement, les differents formalismes de modelisation et les outils qui leur sont

associes.

Enfin, dans le dernier chapitre, nous passons en revue les principes d’analyse des

dependances entre des ressources differentes telles que les livrables de conception, le code

source des applications, les exigences, etc.

57

Introduction

58

Chapitre 3

Structuration de la documentation

Sommaire

3.1 Notion de document . . . . . . . . . . . . . . . . . . . . . . . 59

3.2 Structure documentaire . . . . . . . . . . . . . . . . . . . . . 62

3.3 Langages de structuration documentaire . . . . . . . . . . 63

3.4 Modelisation documentaire . . . . . . . . . . . . . . . . . . . 64

3.5 Langages d’echanges documentaires . . . . . . . . . . . . . 66

3.6 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.1 Notion de document

Le terme « document » constitue le plus petit denominateur commun trouve pour

classer dans une meme famille des objets aussi varies qu’un courrier, un email, une note, un

texte de loi, une documentation technique, un dossier medical, un dictionnaire, une video,

un passeport, un ouvrage litteraire, un contrat juridique, un manuscrit ancien, un rapport,

une revue, etc. [Jouve 03a]. Le document peut donc etre percu comme le support de la

communication humaine. Il a ete cree pour etre diffuse et interprete par d’autres personnes

que son ou ses auteurs. Il represente ainsi une trace de l’activite humaine. Il est vrai que

l’ensemble de ces objets peut sembler relativement heterogene et disparate. Cependant,

tous ont pour point commun de rassembler une information en un objet unique, de per-

mettre son transport et d’en faciliter si besoin l’identification et le classement [Stern 97].

D’apres Bachimont[Bachimont 99], un document est un contenu exprime sur un

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

[Stern 97] Stern Yves. Les quatre dimensions des documents electroniques. Document Numerique,

1997, vol 1, n 1, p 55–60.

[Bachimont 99] Bachimont B. Bibliotheques numeriques audiovisuelles : des enjeux scientifiques et tech-

niques. Document Numerique, numero special Les bibliotheques numeriques, 1999, vol 2,

n 3-4, p 219–242.

59

Chapitre 3. Structuration de la documentation

support materiel, support d’inscription. Le contenu s’exprime sous une forme interpretable

et comprehensible pour un public donne. Ensuite, un certain nombre de contraintes de-

coulent du support d’inscription et de la forme d’interpretation choisie, contraignant ainsi

l’expression du contenu et ses conditions de reception et d’interpretation. Plusieurs types

de structures emergent traditionnellement dans le domaine de l’ingenierie documentaire

[Bachimont 99] :

– une structure logique qui impose un ordonnancement, une hierarchisation, une

mise en ensemble d’elements de contenus exprimes selon un mode d’expres-

sion donne. Par exemple, un document va etre constitue d’un titre, d’une ou

plusieurs parties, elles-memes composees d’un titre et de sous-parties, etc. Les

structures logiques se formalisent partiellement par les definitions des types de

documents – DTD 9 – que l’on peut rencontrer dans des formalismes comme

SGML, XML.

– une structure materielle ou physique imposant une presentation, une mise en

forme du document. Il s’agit d’une mise en forme de ces elements conformement

a l’ordonnancement prescrit. C’est le choix par exemple d’une typographie,

d’une mise en pages donnee, etc. Celle-ci depend du support de restitution, par

exemple s’il s’agit d’une representation dite « papier », la structure physique

indiquera le format de la feuille (A3, A4, A5,. . .) ainsi que l’organisation des

differentes entites logiques du document en vue de sa presentation (une ou deux

colonnes, etc.).

– une structure semantique qui s’attache a l’explicitation de la signification des

informations vehiculees par le document. A ces fins, des travaux s’interessent

a l’utilisation des ontologies [Erdmann 99] ou a la representations de connais-

sances [Jouve 03a] [Nanard 96].

Generalement, la structure materielle ou physique est calculee automatiquement a partir

de la structure logique par application d’une feuille de style – par exemple les feuilles

9. DTD – Document Type Definition [W3C 08]

[Erdmann 99] Erdmann Michael et Studer Rudi. Ontologies as Conceptual Models for XML Do-

cuments. Twelfth Workshop on Knowledge Acquisition, Modeling and Management

(KAW’99). Alberta, Canada. 1999.

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

[Nanard 96] Nanard Marc, Nanard Jocelyne, Massotte Anne Marie, Chauche Jacques, Jou-

bert Alain et Betaille Henri. Acquisition et ingenierie des connaissances, tendances

actuelles, chapitre La metaphore du generaliste : Acquisition et utilisation de la connais-

sance macroscopique sur une base de documents techniques, p 285–306. Cepadues editions,

1996.

60

3.1. Notion de document

CSS [W3C 99a, W3C 98], XSL [W3C 99b][W3C 01a] pour XML[W3C 08]. La structure

logique est habituellement stockee avec le document, tandis que la structure physique est

obtenue dynamiquement, lors de l’affichage du document a partir de la structure logique.

Bachimont identifie egalement deux contextes de manipulation des documents :

– un contexte de production, ou les differentes structures internes au document

sont mises en place en fonction d’une pratique donnee (par exemple le domaine

legislatif). Ce travail peut donner plusieurs types de documents definissant ainsi

les structures logiques utilisees.

– un contexte de reception, qui determine quant a lui la maniere dont les struc-

tures du document seront utilisees et interpretees.

Un document numerique est encode et enregistre selon un format bien definit. Il

sera presente a l’utilisateur sur un support d’appropriation (ecran, haut-parleur, papier) et

dans une forme lisible ou intelligible pour l’utilisateur (par exemple : le texte, les images

ou les sons). La consultation est realisee apres un mecanisme permettant de passer du

support d’enregistrement au support d’appropriation. Une telle operation est qualifiee de

projection dans [Champin 02].

Le document numerique, considere sur le support d’enregistrement, n’est pas un

document final mais une ressource a partir de laquelle peuvent etre calcules autant de

documents, c’est-a-dire d’instances sur un support d’appropriation. Par exemple, le for-

mat d’enregistrement interne d’un document Word [MSOffice 08] est incomprehensible par

l’utilisateur tandis que le document affiche dans l’interface du logiciel Word est parfaite-

ment comprehensible.

Definir clairement l’unite du document numerique [Bachimont 99, Bargeron 99]

devient difficile et des notions telles que celles de fragment documentaire, de document ou

de corpus tendent a s’estomper. Par exemple, un site Web compose exclusivement de pages

[W3C 99a] World Wide Web Consortium. Cascading Style Sheets, Level 1 (revised 11 Jan 1999),

W3C Recommendation, 1999. Disponible sur : http ://www.w3.org/TR/REC-CSS1

(consulte le 07.08.2009).

[W3C 98] World Wide Web Consortium. Cascading Style Sheets Level 2 Specification, W3C Re-

commendation, 1998. Disponible sur : http ://www.w3.org/TR/REC-CSS2 (consulte le

07.08.2009).

[W3C 99b] World Wide Web Consortium. Transformations XSL (XSLT) Version 1.0, W3C Recom-

mendation, 1999. Disponible sur : http ://www.w3.org/TR/xslt (consulte le 07.08.2009).

[W3C 01a] World Wide Web Consortium. Transformations XSL (XSLT) Version 1.1, W3C Working

Draft, 2001. Disponible sur : http ://www.w3.org/TR/xslt11 (consulte le 07.08.2009).

[Champin 02] Champin Pierre-Antoine. Modeliser l’experience pour en assister la reutilisation : De la

conception assistee par ordinateur au web semantique. These : Universite Claude Bernard

– Lyon 1, Lyon, France, Decembre 2002. 138 p.

[MSOffice 08] Microsoft Coorporation. Microsoft Office, 2008. Disponible sur :

http ://www.microsoft.com/france/office (consulte le 07.08.2009).

[Bargeron 99] Bargeron D., Gupta A., Grudin J., Sanocki E. et Mendelzon A. Annotations for

Streaming Video on the Web : System Design and Usage Studies. Computer Networks,

1999, vol 31, n 11-16, p 1139–1153.

61

Chapitre 3. Structuration de la documentation

HTML peut etre tantot percu comme un seul et meme document, tantot comme un en-

semble de documents plus elementaires. Un document numerique peut etre textuel, sonore,

audiovisuel, mono-media, multimedia, etc. Les supports d’enregistrement et d’appropria-

tion ainsi que les modalites de consultations sont tellement diversifies qu’il devient difficile

de cerner la notion de document. Il est donc essentiel de se munir d’une structuration qui

puisse nous aider a apprehender cette notion de document.

3.2 Structure documentaire

La problematique de la structuration multiple du document a ete abordee dans

le cadre d’un groupe de travail compose de differentes organisations (LIRIS 10, SIMMO 11,

SICOMOR 12, CNAF, etc.). Ces recherches collectives ont ete menees au sein de l’Institut

des Sciences du Document Numerique 13 (ISDN) et ont ete financees par la region Rhone-

Alpes.

David Jouve [Jouve 03a] restitue les travaux menes par ce groupe de travail qui

ont abouti notamment a la definition d’une structure documentaire.

Definition 3.2.1. Structure documentaire – Une structure documentaire est la description

d’un document par un ensemble d’elements en relation les uns avec les autres, au cours

ou en vue d’un usage. Les relations etablies entre les differents elements de structure sont

restreintes aux relations binaires. Une structure documentaire S est un graphe etiquete

connexe Sdoc = (N, R, A, LN , LA, etiq) ou :

– N est l’ensemble d’elements de structure,

– R est l’application definissant la relation binaire entre les membres de l’en-

semble N :

R : N → N, ∀x, y ∈ N, xRy,

– A est un ensemble d’arcs,

– LN est l’ensemble des etiquettes associees aux elements de structure,

– LA est l’ensemble des etiquettes associees aux arcs,

– etiq est une application qui :

1. a tout element de structure, x ∈ N, associe une etiquette dans LN ,

2. a tout arc, a ∈ A, associe une etiquette dans LA.

10. Laboratoire d’InfoRmatique en Image et Systemes d’information, voir http ://liris.cnrs.fr.11. Centre Sciences de l’Informatique, des Mathematiques, du Management et des Organisations

de l’Ecole Nationale Superieure des Mines de Saint-Etienne.

12. Equipe de Recherche sur les Systemes d’Informations et de la Communication des Organisa-tions de l’Universite Jean Moulin Lyon 3, voir http ://iae.univ-lyon3.fr/la-recherche-a-l-iae-de-lyon/centre-de-recherche-magellan/sicomor-recherche-en-systeme-d-information/.

13. Voir, http ://isdn.enssib.fr/institut/institut.html.

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

62

3.3. Langages de structuration documentaire

La notion de structure proposee par cette definition est caracterisee par un haut

degre d’abstraction et de genericite (elle est applicable a tout type de document). Cette

structure a ete elaboree de maniere a etre independante du type de media considere (e.g.

son, image, video, texte) et du type de corpus vise (e.g. documents archeologiques, do-

cuments reglementaires), des usages specifiques (e.g. stockage, recherche d’information,

consultation, navigation, restitutions multiples, edition). Cette structure est ainsi reutili-

sable mais l’abstraction reduit son caractere directement applicable. Le modele propose

doit donc prealablement etre specialise en fonction de divers parametres, tels que le media

utilise, le type de document considere ainsi que son utilisation attendue.

Dans la section suivante nous presentons quelques langages de structuration do-

cumentaire qui respectent les principes generiques enonces par la definition 3.2.1.

3.3 Langages de structuration documentaire

Le Standard Generalized Markup Language – SGML [ISO 86] et l’eXtensible Mar-

kup Language – XML [W3C 08] sont des metalangages de description de documents struc-

tures. SGML est une norme ISO internationale, tandis que XML est une recommandation

du World Wide Web Consortium 14. La norme SGML, anterieure a la specification de

XML, a ete developpee originellement pour l’echange de documents structures et a ete

utilisee notamment dans l’industrie de l’edition. Elle s’est revelee d’une grand complexite,

decourageant son adaptation a d’autres contextes industriels. SGML impose que tout do-

cument soit conforme a une structure de document type, parfaitement specifiee et validee.

SGML n’offre pas en lui-meme de mecanismes de liens bien adaptes a la creation d’un

hypertexte ouvert associant de nombreux documents. Ces liens existent dans une norme

complementaire, nommee HyTime [ISO 92]. Cette derniere, tres complete, mais complexe,

induit a son tour de grandes difficultes d’implementation. Neanmoins, SGML a demontre

que le principe fondamental visant a strictement separer description structurelle du do-

cument et description de sa realisation physique, apporte l’independance maximale entre

la representation informatique du document et les technologies particulieres (materielles

ou logicielles) necessaires a son traitement. C’est ainsi que XML et ses nombreux stan-

dards associes, sont nes de la volonte de capitaliser les acquis de SGML tout en facilitant

son implementation et son usage. Nous concentrons la suite de notre analyse sur le lan-

gage XML. Pour une comparaison plus detaillee entre SGML et XML, nous conseillons

14. World Wide Web Consortium ou W3C est une organisation ou cooperent un grand nombred’entreprises et de chercheurs partenaires.

[ISO 86] Voir reference [ISO 86] definie page 35.

[W3C 08] Voir reference [W3C 08] definie page 60.

[ISO 92] International Organization for Standardization. Hypermedia/Time-based Structuring Lan-

guage (HyTime). International Standard ISO 10744 :1992(E), Decembre 1992. 184 p.

63

Chapitre 3. Structuration de la documentation

[ben Lagha 99].

Le langage XML est fonde sur le meme principe que SGML : decrire la structure

logique des documents, principalement textuels, a l’aide d’un systeme de balises permettant

de marquer les elements qui en composent la structure, ainsi que les relations entre ces

elements. Le concept de balisage structurel consiste a admettre que tout document textuel

est construit selon une structure. Cette derniere est reconnue par les lecteurs humains

grace a des marques typographiques, des conventions de mise en page [Michard 01]. Cette

structure est rendue explicite grace a l’utilisation de balises indiquant le debut et la fin de

chacun des elements qui la composent. Un element est denote par la presence d’une balise

ouvrante – eg. <UnElement> – appariee a une balise fermante – eg. </UnElement>. Un

element peut etre vide, rassembler une portion de texte terminale ou etre compose de divers

autres elements. Les regles syntaxiques qui regissent la composition des balises imposent

aux structures specifiques une organisation arborescente. Pour qu’un document XML soit

qualifie de bien forme il est necessaire qu’il satisfasse a des contraintes syntaxiques (e.g.

balises fermees, noms en majuscule, un seul element racine).

Un exemple de source XML bien forme est fourni dans la figure 3.1. Le document

modelise est une lettre dont la structure fait apparaıtre differents elements consideres

comme constitutifs de cette classe d’objets documentaires. Une lettre est envoyee par un

EXPEDITEUR a l’attention d’un DESTINATAIRE. Elle est datee et possede un champ OBJET

ainsi qu’un CORPS. L’ensemble des elements specifiques identifies par la presence des balises

dans la source XML definit une structure arborescente.

Le langage XML peut etre utilise dans plusieurs intentions : afin de construire

une representation de l’information utile, afin d’expliciter l’interpretation des contenus

documentaires ou de retablir les relations entre les informations modelisees.

3.4 Modelisation documentaire

XML est un metalangage permettant de decrire la structure de tous les docu-

ments d’un meme type a l’aide d’un Document Type Definition ou de schemas. Les DTD

sont pour XML l’un des aspects importants directement herites de SGML. Dans le but

d’obtenir une expressivite plus forte par rapport aux DTD, la norme XML introduit des

mecanismes propres, les schemas, definis au travers de la recommandation XML-Schemas

[ben Lagha 99] b Lagha S., Sadfi W. et b Ahmed M. Une comparaison SGML-XML. Cahiers GUTen-

berg : Actes de la journee XML au Congres GUT99. Lyon, France. mai 1999, p 127–154.

[Michard 01] Michard Alain. XML Langage et Applications. Editions Eyrolles, Paris, 2001. 499 p.

64

3.4. Modelisation documentaire

<LETTRE>

<EXPEDITEUR>

<NOM>Eugene Ionesco</NOM>

<ADRESSE>

<NUMERO>5</NUMERO>

<RUE>rue du Theatre</RUE>

<VILLE>PARIS</VILLE>

</ADRESSE>

</EXPEDITEUR>

<DESTINATAIRE>

<NOM>Constantin Brancusi</NOM>

<ADRESSE>

<NUMERO>6</NUMERO>

<RUE>rue des arts</RUE>

<VILLE>PARIS</VILLE>

</ADRESSE>

</DESTINATAIRE>

<DATE>12-07-1953</DATE>

<OBJET>Journal de bord d’un voyage</OBJET>

<CORPS>

<PARAGRAPHE>Ceci est le premier paragraphe.</PARAGRAPHE>

<PARAGRAPHE>Ceci est le deuxieme paragraphe.</PARAGRAPHE>

<PARAGRAPHE>Ceci est le dernier paragraphe.</PARAGRAPHE>

</CORPS>

<SALUTATIONS>Cordialement.</SALUTATIONS>

</LETTRE>

Figure 3.1 – Document XML ou SGML : exemple d’une lettre.

[W3C 01b][W3C 01c][W3C 01d]. Les schemas sont eux-memes decrits en XML. La defi-

nition de modeles de document au travers des DTD ou des schemas est le mecanisme

par lequel les structures types predefinies, auxquelles les documents valides obeissent, sont

specifiees. Plus precisement, un document bien forme est dit valide lorsqu’il se conforme a

un modele explicitement defini. DTD et schemas rassemblent l’ensemble de toutes les de-

clarations relatives aux elements generiques, aux attributs, aux notations et aux entites qui

seront utilises lors de l’instanciation des documents specifiques. Ils permettent tous deux

la validation de documents XML au moyen d’analyseurs syntaxiques, grammaticaux, ou

autres, qui verifient que le document considere respecte la syntaxe du langage, la structure

de la DTD ou du schema, et que tous les liens faisant reference a des entites peuvent etre

resolus.

Par ailleurs, d’autres langages de description de schemas des documents XML

[W3C 01b] World Wide Web Consortium. XML Schema Part 0 : Primer, W3C Recommendation,

2001. Disponible sur : http ://www.w3.org/TR/xmlschema-0 (consulte le 04.08.2009).

[W3C 01c] World Wide Web Consortium. XML Schema Part 1 : Structures, W3C Recommendation,

2001. Disponible sur : http ://www.w3.org/TR/xmlschema-1 (consulte le 04.08.2009).

[W3C 01d] World Wide Web Consortium. XML Schema Part 2 : Datatypes, W3C Recommendation,

2001. Disponible sur : http ://www.w3.org/TR/xmlschema-2 (consulte le 04.08.2009).

65

Chapitre 3. Structuration de la documentation

ont egalement ete proposes [Lee 00], par exemple : Schematron [Rick 00][ISO 06] et DSD

[Klarlund 02].

La recommandation XML-Schemas peut etre modelisee, a l’aide d’un schema XSD

presente, sous forme graphique, dans l’annexe B.

3.5 Langages d’echanges documentaires

Un autre aspect de XML est a envisager : les documents XML representent une

solution d’echange de donnees tres plebiscitee. En effet, un des buts de XML est de per-

mettre un echange de donnees plus facile et plus transparent qu’avec les moyens existants.

Les efforts d’Object Management Group – OMG ont abouti a la proposition d’XML Me-

tadata Interchange – XMI [OMG 07b].

XMI s’appuie sur un procede de serialisation sous forme XML des objets MOF –

Meta Object Facility, un autre standard de OMG [OMG 05][OMG 06a]. Bien que l’exemple

d’usage le plus commun soit l’echange de modeles UML, l’XMI peut etre employe dans

l’echange de toutes les metadonnees dont le modele peut etre exprime en MOF.

XMI specifie ainsi un modele d’echange d’information ouvert qui est destine a

fournir les capacites d’echanger des donnees d’une facon standardisee.

3.6 Synthese

Le tableau 3.1 presente une synthese des notions presentees dans ce chapitre en

mettant en evidence les avantages et les inconvenients de chaque proposition.

[Lee 00] Lee D. et Chu W.W. Comparative analysis of six xml schema languages. SIGMOD

Record, 2000, vol 29, n 3, p 76 – 87.

[Rick 00] Rick Jellife. The Schematron – An XML Structure Validation Language using Patterns

in Trees, 2000. Disponible sur : http ://xml.ascc.net/resource/schematron/ (consulte le

04.08.2009).

[ISO 06] International Organization for Standardization. Document Schema Definition Language

(DSDL) – Rule-based validation – Schematron. International Standard ISO/IEC 19757-

3 :2006, 2006. 38 p.

[Klarlund 02] Klarlund N., Moller A. et Schwatzbach M. I. Dsd : a schema language for xml.

Automated Software Engineering, 2002, vol 9, n 3, p 285–319.

[OMG 07b] OMG – Object Management Group. XML Metadata Interchange (XMI), v2.1.1, Decem-

ber 2007. Disponible sur : http ://www.omg.org/technology/documents/formal/xmi.htm

(consulte le 03.09.2008).

[OMG 05] Internation Standardisation Organisation (ISO). Meta Object Facility Specification,

Version 1.4.1, 2005. Disponible sur : http ://www.omg.org/docs/formal/05-05-05.pdf

(consulte le 04.08.2008).

[OMG 06a] Object Management Group (OMG). Meta Object Facility Specification, Version 2.0, 2006.

Disponible sur : http ://www.omg.org/spec/MOF/2.0/ (consulte le 04.08.2008).

66

3.6

.Syn

these

Technologie Avantages Inconvenients

Structure documentaire

Definition 3.2.1(groupe de travail) haut degre d’abstraction et de genericite, appli-cable a tout type de document

la forte abstraction reduit son caractere directe-ment applicable

Langages de structuration documentaire(Section 3.3)

SGML [ISO 86] separation du modele et de l’instance complexite de la mise en oeuvre

XML [W3C 08] facilite de mise en œuvre, nombreux standardsassocies, tres repondu dans le milieu industriel

separation incomplete entre modele et le contenu

Modelisation et echanges documentaire (Section 3.4)

DTD - Document Type Definition[Michard 01]

structure precise, assure la validite des docu-ments

complexite de la mise en œuvre

XSD - XML-Schemas [W3C 01b] expressivite plus forte que le DTD, tres repandu

Schematron [ISO 06] validation en utilisant de patterns tres peu d’outils, mise en œuvre difficile

DSD [Klarlund 02] tres peu d’outils, mise en œuvre difficile

XMI [OMG 07b] format ouvert tres volumineux

Table 3.1 – Tableau de synthese des propositions67

Chapitre 3. Structuration de la documentation

68

Chapitre 4

Gestion des Systemes

d’Information

Sommaire

4.1 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.1 Les cycles de developpement . . . . . . . . . . . . . . . . . . 71

4.1.2 Les methodologies de conception et de developpement . . . 71

4.1.3 Formalisation des developpements . . . . . . . . . . . . . . . 72

4.1.4 Maıtrise et amelioration de la qualite . . . . . . . . . . . . . 73

4.1.5 Programmation des processus . . . . . . . . . . . . . . . . . 73

4.2 Modelisation des Systemes d’Information . . . . . . . . . . 74

4.2.1 Formalismes de modelisation . . . . . . . . . . . . . . . . . . 75

4.2.2 Choix du formalisme de modelisation des Systemes d’Infor-

mation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2.3 Maıtrise des modeles . . . . . . . . . . . . . . . . . . . . . . 79

4.3 Gestion des connaissances et maıtrise des Systemes d’In-

formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.4 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.1 Concepts de base

La societe depend de plus en plus de fonctionnalites et de services offerts par des

systemes automatises par l’ordinateur. Des « fragments » de logiciels sont embarques

ou exploites par la plupart des produits modernes, a l’image des ordinateurs de bord

dans les voitures, de l’automatisation des transports, etc. Dans le futur proche, la place

occupee par le logiciel dans notre quotidien sera de plus en plus importante, rendant ainsi

69

Chapitre 4. Gestion des Systemes d’Information

l’informatique omnipresente (les fonctionnalites internet sont d’ores et deja presentes dans

l’electromenager et dans d’autres appareils domestiques).

Malheureusement, les logiciels sont des produits tres complexes, difficiles a de-

velopper et a tester. Souvent, ils se manifestent de maniere inattendue ou non souhaitee.

Chaque nouvelle edition de la newsletter ACM Software Engineering Notes publiee par

ACM SIGSOFT presente, dans une section dediee, quelques exemples d’accidents pro-

voques par les erreurs dans les logiciels. Pour toutes ces raisons, les chercheurs et les

industriels s’interessent tout particulierement a l’amelioration de la qualite des logiciels

developpes. Cet objectif peut etre atteint par plusieurs approches et techniques. Une des

priorites est l’amelioration des processus de conception et de developpement des logiciels :

le « software process »15. L’interet est prouve egalement par la standardisation internatio-

nale dont elle a fait l’objet : les normes ISO 12207 Processus du cycle de vie du logiciel et

ISO 15504 SPICE – Software Process Improvement and Capability dEtermination[ISO 04].

Alfonso Fuggetta propose dans [Fuggetta 00] quelques pistes pour l’amelioration

des processus de developpement logiciel, notamment en prenant en compte l’experience

d’autres domaines et en revisitant les langages de modelisation pour une meilleure coor-

dination des acteurs.

Les processus sont essentiels dans l’industrie car ils assurent un fonctionnement

uniforme des differents projets permettant ainsi d’augmenter la productivite, d’ameliorer

le temps necessaire a l’elaboration du produit et de reduire les couts engendres par son

developpement. Mais les processus sont importants surtout parce que l’experience a montre

qu’en controlant le processus, nous avons un meilleur controle sur la qualite du produit

[Gianpaolo 98].

Plusieurs approches ont ete proposees pour repondre aux problematiques presen-

tees precedemment. Il est difficile de presenter d’une maniere exhaustive les recherches

passees et en cours autour de ce sujet qui passionne depuis de nombreuses annees la com-

munaute scientifique en informatique.

Cependant, il nous semble interessant de dresser une liste des approches propo-

sees. En realite, ces approches ont existe et existent encore sous de nombreuses formes et

variantes. L’experience des annees de developpement logiciel a prouve qu’il n’y a pas de

« solution miracle ». Ainsi, les editeurs logiciels, les industriels choisissent les elements qui

leur semblent utiles n’hesitant pas a faire des « melanges ».

15. Software process - processus logiciel - terme anglais consacre dans la litterature dans les annees1980.

[ISO 04] International Organization for Standardization. ISO/IEC 15504 – SPICE (Software Pro-

cess Improvement and Capability dEtermination, 2004.

[Fuggetta 00] Fuggetta Alfonso. Software process : A roadmap. Proceedings of the 22nd Int. Conf.

on Software Engineering (ICSE’2000) – Future of Software Engineering Track. 2000.

[Gianpaolo 98] Gianpaolo Cugola et Carlo Guezzi. Software processes : a retrospective and a path to

the future. Software Process Improvement and Practice, 1998, vol 4, n 3, p 101–123.

70

4.1. Concepts de base

4.1.1 Les cycles de developpement

Le cycle de developpement logiciel definit une vie standard du logiciel, de sa

conception initiale a la maintenance en passant par le developpement. Le processus est

decompose dans une liste predefinie de phases, chacune etant structuree dans une serie

d’activites. Chaque phase recoit en entree un ensemble de livrables provenant de la phase

precedente et cree des livrables necessaires a la phase suivante.

Le « cycle en cascade » presente au debut des annees 70 [Royce 70] est present sous

differentes formes dans l’industrie. Il se base sur le postulat que l’ensemble des exigences

des utilisateurs sont connues au debut du processus. Il est percu comme une boıte noire

jusqu’a la fin quand il fournit le produit fini. Or, le plus souvent, l’utilisateur n’arrive pas

a bien exprimer ses besoins. Par ailleurs, le processus d’ingenierie logicielle contient des

etapes creatives qui ne peuvent pas etre apprehendees de la meme maniere que les etapes

manufacturieres. Ainsi, le developpement logiciel a besoin de cycles de vie plus flexibles et

adaptables.

La linearite de tels processus est un facteur qui augmente les couts associes aux

evolutions, qu’elles soient correctives (elles corrigent un defaut), adaptatives (elles adaptent

le logiciel a un changement d’environnement) ou perfectionnantes (elles ameliorent les

fonctionnalites existantes ou integrent de nouvelles idees et nouveaux besoins utilisateurs)

[Ghezzi 03].

4.1.2 Les methodologies de conception et de developpement

Une autre approche populaire a ete la definition de methodologies de conception

et de developpement. Les methodologies s’inscrivent dans des approches en s’appuyant sur

les differents cycles de developpement. Ces methodologies offrent des conseils experts et

indiquent les meilleures pratiques pour les processus de conception et de developpement.

Elles sont issues des developpements precedents couronnes de succes et peuvent etre per-

cues comme le fruit d’une distillation des meilleures experiences acquises au cours de la

conception et du developpement. Malgre l’enthousiasme affiche par les createurs de ces

methodologies, elles essuient quelques critiques et doivent faire face a des problemes tels

que [Pfleeger 06] :

– une methodologie est souvent appliquee dans un contexte different de celui

dont elle est issue. Par exemple, la meme methodologie peut etre appliquee

[Royce 70] Royce Winston. Managing the development of large software systems : Concepts and

techniques. In Proceedings of WesCon Conference, August 25-28 1970.

[Ghezzi 03] Ghezzi Carlo, Jazayeri Mehdi et Mandrioli Dino. Fudamentals of Software Enginee-

ring. Prentice Hall, 2003. 624 p.

[Pfleeger 06] Pfleeger Shari Lawrence et Atlee Joanne M. Software Engineering : Theory and

Practice, third edition. Prentice Hall, 2006. 736 p.

71

Chapitre 4. Gestion des Systemes d’Information

pour le developpement d’une application de gestion comme pour celui d’une

application industrielle,

– les developpeurs, en se deresponsabilisant, ont considere les methodologies

comme des « recettes » plutot que comme des conseils generiques,

– les methodologies necessitent beaucoup d’organisation, produisent de nom-

breux documents mais peu d’outils accompagnent efficacement les acteurs dans

ce travail,

– les methodologies sont souvent basees sur des notations non formelles : l’absence

d’une semantique precise a rendu les descriptions ambigues et la verification

de la coherence difficile. Dans d’autres cas, quand des notations formelles sont

utilisees, leur mise en œuvre est tres couteuse.

4.1.3 Formalisation des developpements

Contrastant avec le manque de formalisme des approches precedentes, un autre

axe de recherche a vu le jour a la fin des annees 1960. Il essaie de developper les fonde-

ments d’une approche du developpement logiciel en se basant sur les mathematiques. Ces

approches se basent sur le constat que les programmes sont des elements mathematiques

qui peuvent etre specifies d’une maniere formelle, validee. Les programmes peuvent ensuite

etre developpes correctement a travers une serie de raffinements bien definis [Dijkstra 76]

[Wirth 71] [Dahl 72] [Bauer 89].

Cette approche n’a pas pu trouver sa place comme solution generique au probleme

logiciel. Tout d’abord parce qu’elle suppose qu’une specification formelle des fonctionnalites

requises du logiciel soit disponible des le depart. Or, nous avons vu precedemment que cette

hypothese n’est pas toujours vraie. A cette premiere contrainte s’ajoute le probleme de

la « scalabilite ». En effet, bien que les methodes proposees pour le developpement des

programmes corrects obtenaient de bons resultats avec des programmes de petite taille,

elles etaient difficilement applicables au developpement de systemes complexes. Enfin, ces

methodes ne prennent pas suffisamment en compte les exigences non-fonctionnelles qui

representent une partie fondamentale de toute application complexe.

[Dijkstra 76] Dijkstra Edsger Wybe. A Discipline of Programming. Series in Automatic Computa-

tion. Prentice Hall, 1976. 240 p.

[Wirth 71] Wirth Niklaus. Program development by stepwise refinement. Communications of the

ACM, 1971, vol 14, n 4, p 221–227.

[Dahl 72] Dahl O. J., Dijkstra E. W. et Hoare C. A. R. Structured Programming. Academic

Press, 1972. 234 p.

[Bauer 89] Bauer Friedrich Ludwig, Moller Bernhard, Partsch Helmut et Pepper Peter.

Formal program construction by transformations-computer-aided, intuition-guided pro-

gramming. IEEE Trans. Softw. Eng., 1989, vol 15, n 2, p 165–180.

72

4.1. Concepts de base

4.1.4 Maıtrise et amelioration de la qualite

Dans les annees 1980, le milieu industriel est devenu de plus en plus soucieux de

la qualite. Le chef de file a ete l’industrie japonaise qui a ete tres attentive au processus de

production industrielle pour garantir la qualite des produits. Des standards internationaux

tels que la serie ISO 9000 [ISO 97], elabores pour certifier les organisations, etaient percus

comme une assurance indirecte de la qualite des produits delivres. Ces standards de qualite

se basent sur des procedures de management qui assurent un flux d’activites previsible et

ordonne. Ils ne s’interessent pas a comprendre la performance du processus metier des

organisations. C’est le but des modeles tels que Capability Maturity Model (CMM) de

definir une serie de niveaux de maturite qui caracterise une organisation de developpement

logiciel [Humphrey 89].

Les standards industriels et CMM sont tres utiles car ils prennent en compte le

point de vue de management du processus de developpement. Cependant, dans certains cas,

ceux qui les ont utilises ont pu observer qu’ils ne produisent pas une meilleure organisation

mais, au contraire, augmentent la « bureaucratie ». Les interrogations persistent donc pour

determiner s’ils sont plutot adaptes aux organisations complexes qu’aux organisations

dynamiques, flexibles et innovantes. Leur application ne se traduit pas automatiquement

par la qualite de leur produit : chaque organisation doit les considerer comme un vivier

de bonnes pratiques.

4.1.5 Programmation des processus

Leaon Osterweil a soutenu en 1987 l’idee que le processus de developpement de

logiciel est egalement un logiciel : « Software processes are software too » [Osterweil 87].

Toutes les organisations sont differentes et meme au sein d’une organisation, les divers

projets presentent des caracteristiques specifiques. Le processus doit donc etre adapte en

fonction du probleme a resoudre ; il doit prendre en compte les specificites des acteurs, du

projet et de l’organisation. Ainsi, Osterweil conclut au besoin de langages de description

des processus, de methodes de test et d’execution de ces processus, plus exactement de

definition du modele de processus. Ces langages sont appeles Process Modeling Language

[ISO 97] International Organization for Standardization. ISO 9000-3 task force, Quality mana-

gement and quality assurance standards - Part 3 : guidelines for the application of ISO

9000 to the development, supply and maintenance of software, 1997.

[Humphrey 89] Humphrey Watts S. Managing the Software Process. SEI Series in Software Engineering.

Addison-Wesley, 1989. 512 p.

[Osterweil 87] Osterweil Leaon. Software processes are software too. ICSE ’87 : Proceedings of the

9th international conference on Software Engineering. Los Alamitos, CA, USA. IEEE

Computer Society Press, 1987, p 2–13.

73

Chapitre 4. Gestion des Systemes d’Information

(PML) [Finkelstein 94]. Cette approche est consideree comme une pierre angulaire dans

la recherche moderne sur les processus de conception et de developpement et a donne

suite a la definition des Process-centered Software Engineering Environments (PSEEs)

[Arbaoui 02]. Le PSEE assiste les utilisateurs tout au long d’un processus explicite et

specifique utilise pour concevoir, specifier, developper et maintenir les produits logiciels.

4.2 Modelisation des Systemes d’Information

Les recherches bibliographiques conduites nous ont permis de denombrer deux

grands types d’approches dans la conception des Systemes d’Information :

– L’approche basee sur des langages formels decrivant le systeme a l’aide d’une

semantique parfaitement definie, par exemple : le langage B [Abrial 96], le

langage Z [Z 08], le Z++ [Lano 90], le Object Z [Smith 99], etc.

– L’approche fondee sur des langages moins formels et plus adaptes a l’homme.

Nous pouvons ici citer le standard UML – Unified Modeling Language[OMG 01][OMG 07a]

ou l’approche Merise. Ces langages semi-formels sont souvent enrichis a l’aide

de notations plus formelles, par exemple le langage OCL – Object Constraint

Language[OMG 06b] pour UML.

Notre analyse porte sur deux directions :

– comment modeliser le Systeme d’Information de l’entreprise ?

– comment estimer la capacite de ce modele a realiser des etudes d’impact

[Finkelstein 94] Finkelstein Anthony, Kramer Jeff et Nuseibeh Bashar. Software Process Modelling

and Technology. Research Studies Press Limited (J. Wiley), Taunton, UK, UK, 1994. 362

p.

[Arbaoui 02] Arbaoui Selma, Derniame Jean-Claude, Oquendo Flavio et Verjus Herve. A com-

parative review of process-centered software engineering environments. Annals of Software

Engineering, 2002, vol 14, n 1-4, p 311–340.

[Abrial 96] Abrial Jean-Raymond. The B-book : assigning programs to meanings. Cambridge Uni-

versity Press, New York, NY, USA, 1996. 779 p.

[Z 08] Programming Research Group (PRG), Oxford University. The Z notation, 2008. Dispo-

nible sur : http ://www.comlab.ox.ac.uk/archive/z.html (consulte le 07.08.2009).

[Lano 90] Lano Kevin. Z++ – an object-orientated extension to z. Z User Workshop. Workshops

in Computing, Springer-Verlag, 1990, p 151–172.

[Smith 99] Smith Graeme. The Object-Z Specification Language. Kluwer Academic Publishers,

Norwell, MA, USA, 1999. 160p.

[OMG 01] Object Management Group (OMG). Unified Modeling Language Specification, Version

1.4, septembre 2001. Disponible sur : http ://www.omg.org/spec/UML/1.4/ (consulte le

05.08.2008).

[OMG 07a] Voir reference [OMG 07a] definie page 23.

[OMG 06b] Object Management Group (OMG). Object Constraint Lan-

guage Specification, version 2.0, mai 2006. Disponible

sur :http ://www.omg.org/technology/documents/formal/ocl.htm (consulte le

08.08.2008).

74

4.2. Modelisation des Systemes d’Information

Le modele est une representation du monde reel que l’on simplifie pour mieux l’ap-

prehender dans sa globalite. En consequence, nous pouvons considerer un modele comme

la representation d’un systeme avec un formalisme donne, dans un ensemble de notations

donne.

4.2.1 Formalismes de modelisation

Pour creer le modele du systeme, il faut identifier et choisir un formalisme de

modelisation approprie. La popularite des methodes de conception orientee objet, Object

Oriented Methods (OOMs), a encourage le developpement de nombreux formalismes de

modelisation. Plusieurs langages sont donc utilises pour la modelisation des Systemes

d’Information. Chaque langage a ses points forts et ses points faibles. Les paragraphes

suivants presentent une analyse de plusieurs formalismes afin de choisir celui qui correspond

le mieux a notre problematique.

Pour nous aider a choisir la methode et le formalisme le plus adequat, nous avons

identifie quelques criteres dans un ordre decroissant d’importance :

– capacite de modelisation d’un Systeme d’Information (base sur des technologies

objet),

– appropriation du langage et adoption dans l’entreprise,

– operationnalisation, facilite de mise en œuvre dans un contexte industriel,

– possibilite de mener des etudes d’impact,

– extensibilite et specialisation.

4.2.1.1 Langage Z

Le langage Z [Z 08] a ete cree au debut des annees 1980 par le Programming

Research Group-PRG de l’Universite d’Oxford pour decrire et modeliser des Systemes

d’Information. Il s’agit d’un langage mathematique formel base sur la logique de premier

ordre et sur la theorie des ensembles.

Il a ete enrichi avec des concepts objets et des concepts plus formels : Object-Z

[Duke 00] et Z++[Lano 90].

Le langage Z a ete utilise dans certains projets industriels. Les modeles crees avec

ces notations ne sont pas faciles a lire, a comprendre et a modifier, a cause des differences

entre le concept reel et sa representation dans un langage trop formel. Les charges associees

a la realisation, la maintenance et l’exploitation d’un tel modele sont tres elevees, ce qui

represente un frein a son appropriation par les entreprises.

[Duke 00] Duke Roger et Rose Gordon. Formal Object-Oriented Specification Using Object-Z.

Palgrave Macmillan, 2000. 240 p.

[Lano 90] Voir reference [Lano 90] definie page 74.

75

Chapitre 4. Gestion des Systemes d’Information

La figure 4.1 presente un exemple de la specification en langage Z d’une fonc-

tion permettant d’ajouter une nouvelle entree dans la liste d’anniversaires des personnes

connues. Si la personne est deja connue le resultat est already know sinon, le nouvel anni-

versaire est ajoute a la liste d’anniversaires. La fonction utilise les operateurs ∨ et ∧ pour

realiser une union et respectivement une intersection des resultats des deux predicats.

Figure 4.1 – Exemple de la notation Z [Z 08].

4.2.1.2 Langage B

La methode basee sur le langage B[Abrial 96] est une methode formelle qui s’ap-

plique a toutes les phases de developpement logiciel, de la specification jusqu’a l’implemen-

tation. Elle permet d’exprimer des proprietes sous la forme de predicats de la logique de

premier ordre. Les operateurs utilises par la notation B sont egalement ceux de la theorie

des ensembles. Elle ressemble ainsi a la notation Z. Les proprietes d’un systeme a prouver

en B sont essentiellement des proprietes d’invariance. Contrairement a UML, la notation B

n’est pas orientee objet. De meme, le langage B n’a pas un formalisme graphique, il decrit

le systeme a l’aide des automates abstraits : AMN – AbstractMachine Notation.

La figure 4.2 presente un exemple d’utilisation de la notation AMN. L’exemple

definit une machine avec deux proprietes AA et nbMax : un ensemble de depart et un

intervalle 5..10 pour le nombre maximum. La machine va calculer dans la variable var,

initialement vide, tous les sous-ensemble de AA dont la cardinalite est plus petite que le

nombre maximum. L’exemple utilise la notation ASCII de B (« : » pour l’appartenance

ensembliste, « < : » pour l’inclusion, etc.).

Le langage B peut se voir adresser les memes reproches que le langage Z. Des

travaux sont en cours pour faire evoluer les deux langages qui ont du mal a s’imposer dans

les contextes operationnels des entreprises.

[Abrial 96] Voir reference [Abrial 96] definie page 74.

76

4.2. Modelisation des Systemes d’Information

MACHINE

machineExemple(AA, nbMax)

/* machine parametree par un SET et un nombre scalaire */

CONSTRAINTS

nbMax : 5..10 &

card(AA) >nbMax

VARIABLES

var

INVARIANT

var <: AA &

card(var) < nbMax +1

INITIALISATION

var := {}

OPERATIONS

operationExemple =

ANY ens WHERE ens <: AA & card(ens) < nbMax+ 1 THEN

var := ens

END

END

Figure 4.2 – Representation en langage formel utilise par B

4.2.1.3 Syntropy

Dans Syntropy [Cook 94], les modeles orientes objets sont completes par des an-

notations avec des expressions mathematiques, en utilisant le langage Z. Ces annotations

avec des expressions formelles participent a la realisation de modeles reduisant les ambiguı-

tes et favorisant la precision. Cependant, dans Syntropy, nous beneficions d’un formalisme

graphique pour la partie statique uniquement. La methode se base sur les premiers travaux

de Grady Booch car on y retrouve une demarche proche de certains diagrammes UML. La

methode a ete utilisee dans l’industrie puis remplacee par UML qui fournit une vue plus

complete sur le systeme.

4.2.1.4 MERISE

La methode MERISE est basee sur la separation des donnees et des traitements

a effectuer en plusieurs modeles conceptuels et physiques. La separation des donnees et

des traitements assure une longevite au modele.

Elle fait suite a une consultation nationale lancee en 1977 par le ministere de

l’Industrie dans le but de choisir des societes de conseil en informatique afin de definir une

methode de conception de Systemes d’Information. Les deux principales societes ayant mis

au point cette methode sont le CTI (Centre Technique d’Informatique) charge de gerer le

projet, et le CETE (Centre d’Etudes Techniques de l’Equipement).

[Cook 94] Cook Steve et Daniels John. Designing Object Systems : Object-Oriented Modelling

with Syntropy. Prentice Hall, 1994. 388 p.

77

Chapitre 4. Gestion des Systemes d’Information

Merise est surtout une methode d’analyse qui permet d’aboutir separement aux

modeles conceptuels :

– vue statique des donnees (MCD – Modele Conceptuel de Donnees) = Modele

Entite-Relations (ou Modele Entite-Association),

– vue dynamique des traitements MCT – Modele Conceptuel de Traitements.

Les deux vues, MCD et MCT, sont independantes de toute implementation.

Merise est une methode tres utilisee dans le milieu industriel en France. Nean-

moins, il s’agit d’une methode semi-formelle avec peu de possibilites d’extension.

4.2.1.5 UML – Unified Modeling Language

Le langage UML [OMG 01] [OMG 07a] est constitue des notations semi-formelles :

diagrammes de classes, diagrammes d’etat-transition, diagrammes de cas d’utilisation,

etc... Ces notations combinent une structure a base de graphismes avec des contraintes

OCL [OMG 06b] et des annotations en langue naturelle sous forme de commentaires. La

rapidite de conception, la facilite de lecture et la clarte architecturale des modeles UML

en font une methode populaire tres utilisee. Une des difficultes liee a la conception de

modeles UML fiables reside dans le manque d’outils de validation mathematique des pro-

prietes modelisees.

Par ailleurs, UML est supporte par la plupart des outils de conception et des

Ateliers de Genie Logiciel du marche. Notre reflexion donne priorite a l’etude de la base

commune aux diverses versions du langage UML.

D’autres langages de modelisation existent. Ce sont des langages qui accordent

beaucoup plus d’importance a une semantique tres precise et utilisent souvent des For-

mal Specification Techniques (FSTs). Les langages decrits ci-dessus sont representatifs des

possibilites existantes pour la conception et modelisation des Systemes d’Information.

4.2.2 Choix du formalisme de modelisation des Systemes d’Information

Suite a notre etat de l’art, nous avons identifie deux approches pour la modeli-

sation de Systemes d’Information : les approches formelles et les approches plus proches

du langage humain, approches souvent orientees objet. Les premieres approches, formelles,

sont principalement utilisees a des fins calculatoires (modeles comprehensibles et traitables

par l’ordinateur).

Nous nous interessons plus particulierement au partage de l’information et a la

collaboration des individus pour l’analyse et la conception. Par ailleurs, le but de nos

[OMG 01] Voir reference [OMG 01] definie page 74.

[OMG 07a] Voir reference [OMG 07a] definie page 23.

[OMG 06b] Voir reference [OMG 06b] definie page 75.

78

4.2. Modelisation des Systemes d’Information

travaux est de proposer des mecanismes pour la gestion des Systemes d’Information com-

plexes. Pour cela, nous avons besoin d’un langage qui soit employe tout au long du cycle

de vie du Systeme d’Information. Dans ce contexte, notre choix s’oriente donc plus vers

les langages de la deuxieme categorie.

Par rapport a notre problematique, UML offre tous les avantages et les fonctions

qui sont necessaires pour la modelisation du Systeme d’Information. Ce langage est par

ailleurs un standard de facto dans le milieu des entreprises. UML est par consequent

un bon compromis car il est suffisamment souple pour s’adapter dans le contexte tres

operationnel d’une entreprise tout en permettant d’etre enrichi du point de vue semantique

(avec le langage OCL - Object Constraint Langage [OMG 06b]) et syntaxique (par des

mecanismes tels que les profils, les stereotypes, etc.). Nous considerons aussi ses avantages

lies a la facilite a deployer, tant au niveau materiel (produits logiciel, documentation) qu’au

niveau humain (comprehension facile par les informaticiens ou les non-informaticiens).

4.2.3 Maıtrise des modeles

Au-dela de la conception des Systemes d’Information, plusieurs travaux se sont

interesses au maintien de la coherence, a leur optimisation ou a la retro-conception.

Les editeurs des Ateliers de developpement (Eclipse [Eclipse 08], IBM Rational

Rose [Rose 08]) ont des outils UML integres. Ces outils generent a partir des modeles du

code tres etroitement lie. Les modifications apportees a une partie du code ou du modele

sont tout de suite repercutees sur les elements en relation. Cette fonctionnalite est appelee

re-engineering : elle se base en grande partie sur l’etroite liaison entre le code et le modele

(les changements se propagent par une voie textuelle) [Enss 04] [Ekman 04].

D’autres travaux en cours s’attaquent a des problematiques de refonte des mo-

deles. Ces problematiques sont devenues d’actualite suite a l’interet croissant pour le deve-

loppement par des patterns et pour l’architecture orientee modeles (Model Driven Archi-

tecture - MDA). L’action s’appelle refactoring et elle reste tres compliquee a automatiser

[Eclipse 08] Eclipse Foundation. Eclipse - an open development platform, 2008. Disponible

sur : http ://www-01.ibm.com/software/awdtools/developer/rose/index.html (consulte le

04.08.2009).

[Rose 08] IBM Coorporation. Rational Rose, 2008. Disponible sur : http ://www.eclipse.org/

(consulte le 04.08.2009).

[Enss 04] Enss Raphael. Refactoring in Eclipse. Eclipse Departement of Computer Science Uni-

versity of Manitoba, 2004. Disponible sur : http ://www.cs.umanitoba.ca/ eclipse/13-

Refactoring.pdf (consulte le 04.08.2009).

[Ekman 04] Ekman Torbjorn et Asklund Ulf. Refactoring-aware versioning in eclipse. Proceedings

of the Second Eclipse Technology Exchange : eTX and the Eclipse Phenomenon (eTX

2004). Electronic Notes in Theoretical Computer Science, 2004, p 57–69.

79

Chapitre 4. Gestion des Systemes d’Information

[Opdyke 92] [Roberts 99].

D’autres travaux scientifiques se sont interesses a la verification de la coherence

des modeles UML (consistency of UML models). Chaque diagramme UML represente une

vue sur le systeme et apportant un complement d’information. Le modele est forme de

plusieurs diagrammes, chacun representant une vue differente. Les informations deduites

de ces diagrammes doivent etre coherentes [Sourrouille 02] [Engels 01] [Krishnan 00].

Neanmoins, la problematique de la gestion des changements et des etudes d’im-

pact sur ces modeles nous semble etre peu abordee dans la litterature scientifique.

4.3 Gestion des connaissances et maıtrise des Systemes d’In-

formation

Le developpement des Systemes d’Information est une activite complexe et cou-

teuse. Elle implique la resolution de plusieurs problemes souvent contradictoires concernant

la maıtrise des echeances, la maıtrise des couts, la diminution des risques d’erreurs, la per-

formance etc. La difficulte de repondre a ces problematiques est augmentee par la nature

changeante des exigences et des besoins utilisateurs, par la dynamique interne des equipes

projet et par le changement de personnel. Afin d’ameliorer les activites et le processus de

developpement des Systemes d’Information, des travaux de recherche proposent comme

solution cle le partage des connaissances et la capitalisation de l’experience [Aurum 03].

Par ailleurs, le developpement et la maintenance des Systemes d’Information est

considere comme un effort collectif. Les personnes impliquees partagent, echangent des

informations, apprennent les unes des autres. Des communautes sont ainsi creees ou chaque

membre coopere en partagant ses connaissances autour d’un sujet commun, generant ainsi

[Opdyke 92] Opdyke William F. Refactoring Object-Oriented Frameworks. These :

University of Illinois at Urbana-Champaign, 1992. Disponible sur :

http ://www.laputan.org/pub/papers/opdyke-thesis.pdf (consulte le 04.11.2009).

[Roberts 99] Roberts Donald Bradley. Practical analysis for refactoring. These : University of

Illinois at Urbana-Champaign, Champaign, IL, USA, 1999. Adviser-Ralph Johnson.

[Sourrouille 02] Sourrouille Jean Louis et Caplat Guy. Constraint checking in uml modeling. SEKE

’02 : Proceedings of the 14th international conference on Software engineering and know-

ledge engineering. New York, NY, USA. ACM, 2002, p 217–224.

[Engels 01] Engels Gregor, Kuster Jochem M., Heckel Reiko et Groenewegen Luuk. A me-

thodology for specifying and analyzing consistency of object-oriented behavioral models.

ESEC/FSE-9 : Proceedings of the 8th European software engineering conference held

jointly with 9th ACM SIGSOFT international symposium on Foundations of software

engineering. New York, NY, USA. ACM, 2001, p 186–195.

[Krishnan 00] Krishnan P. Consistency checks for uml. APSEC ’00 : Proceedings of the Seventh

Asia-Pacific Software Engineering Conference. Washington, DC, USA. IEEE Computer

Society, December 2000, p 162–169.

[Aurum 03] Aurum Aybuke, Jeffery Ross, Wohlin Claes et Handzic Meliha. Managing Software

Engineering Knowledge. Springer, 2003. 380 p.

80

4.4. Synthese

un veritable flux de connaissances [Rodrıguez 04b].

Differentes approches ont ete proposees pour le partage et la maıtrise du flux de

connaissances. La plus courante est la mise en place de systemes de gestion de connais-

sances bases sur des « agents » [Rodrıguez 04a].

La maintenance et l’exploitation des Systemes d’Information 16 est egalement une

tache complexe et difficile. Pour une correction, amelioration ou evolution d’une donnee,

il faut savoir quelles modifications apporter au Systeme d’Information, a quel niveau, a

quel module, et comprendre comment ces modifications vont affecter les autres modules du

Systeme d’Information. Souvent, les ingenieurs n’ont pas suffisamment de connaissances

sur le Systeme d’Information pour prendre la decision la plus adaptee. Pour ce faire, ils

ont besoin de connaissances dans de nombreux domaines tels que l’application, l’architec-

ture systeme, les algorithmes utilises, les exigences anciennes et nouvelles, les langages de

programmation et les environnements de developpement, etc. Des recherches ont montre

que 40% a 60% de l’effort necessaire pour la maintenance des Systemes d’Information sont

depenses pour la comprehension du systeme [Pfleeger 06].

4.4 Synthese

Le tableau 4.1 presente une synthese des notions presentees dans ce chapitre en

mettant en evidence les avantages et les inconvenients de chaque proposition.

16. Nous utilisons le terme de maintenance des Systemes d’Information pour designer la phaseposterieure a la mise en exploitation des Systemes d’Information

[Rodrıguez 04b] Rodrıguez Oscar M., Martınez Ana I., Vizcaıno Aurora, Favela Jesus et Piattini

Mario. Identifying knowledge managment needs in software maintenance groups : a qua-

litative approach. Proceedings of the 5th Internationa Conference on Computer Science

(ENC’ 2004). IEEE Computer Society Press, 2004, p 72–79.

[Rodrıguez 04a] Rodrıguez Oscar M., Martınez Ana I., Favela Jesus et Vizcaıno Aurora. Understan-

ding and supporting knowledge flows in a community of software developers. International

Workshop on Groupware (CRIWG’04). 2004, p 56–66.

[Pfleeger 06] Voir reference [Pfleeger 06] definie page 72.

81

Chapitre

4.

Ges

tion

des

Sys

tem

esd’Info

rmation

Technologie Avantages Inconvenients

Conception et developpement du SI

Les cycles linaires de developpement Parfaite maıtrise de chaque etape de conceptionet developpement

Les exigences doivent etre identifiees au debutdu cycle, tres peu flexible et adaptable, n’encou-rage pas la creativite

Formalisation des developpements Developpement valide selon des formules mathe-matiques, diminution des erreurs

Les exigences doivent etre parfaitement identi-fiees des le depart, tres difficile a appliquer pourles applications complexes, ne prennent pas encompte les exigences non-fonctionnelles

Modelisation des Systemes d’information

Langage Z Langage mathematique formel base sur la lo-gique de premier ordre

Charges associees a la realisation, la mainte-nance et l’exploitation d’un tel modele sont treselevees

Langage B Langage formel utile dans certains projets in-dustriels, notation tres precise, pas d’ambiguıte

Langage sans formalisme graphique, difficile amettre en oeuvre

Syntropy Annotations avec des expressions formelles per-mettant de reduire les ambiguıtes et d’une plusgrande precision

La methode a ete utilisee dans l’industrie puiselle a ete remplacee par UML qui fournit unevue plus complete sur le systeme

Merise (MCD et MCT) a Les deux modeles, MCD et MCT, sont indepen-dants de toute implementation.

Methode semi-formelle avec peu de possibilitesd’extension

UML Standard de-facto de l’industrie, supporte parla plupart des outils de conception, rapidite deconception, facilite

Langage semi-formel

Table 4.1 – Tableau de synthese des propositions

a. Merise est une methode d’analyse qui permet d’aboutir separement aux modeles conceptuels : le (MCD – Modele Conceptuel de Donnees) = ModeleEntite-Relations (ou Modele Entite-Association) apportant une vue statique des donnees et le MCT – Modele Conceptuel de Traitements apportant une vuedynamique des traitements.

82

Chapitre 5

Analyse des dependances

Sommaire

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2 Tracabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3 Analyse des dependances - livrables de conception et de

developpement . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.4 Analyse des dependances - code source des applications . . 87

5.4.1 Graphe de dependances . . . . . . . . . . . . . . . . . . . . . 87

5.4.2 Decoupage des programmes – Program slicing . . . . . . . . 88

5.5 Analyse des dependances - exigences des utilisateurs . . . 89

5.6 Analyse des dependances - execution des programmes . . 90

5.7 Synthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.1 Introduction

Les changements dans une application logicielle sont produits par des causes va-

riees comme la correction d’une anomalie, l’ajout d’une fonctionnalite ou l’amelioration de

l’architecture et de la conception. Independamment de leur cause, les changements ne se

cantonnent generalement pas a un seul composant du Systeme d’Information. Un change-

ment peut avoir des effets de bord sur d’autres composants et/ou contredire les conditions

initiales. Par ailleurs, les methodologies d’estimation des changements des logiciels sont

tres importantes dans la maintenance des Systemes d’Information car elles permettent a

chaque evolution de diminuer les charges associees aux modifications.

Les differentes approches sont caracterisees par leur degre d’expressivite et leur

degre d’efficience. Le degre d’expressivite est defini comme la granularite des livrables

logiciels (par exemple : un fichier, une classe, une fonction). Ces derniers sont pris en

83

Chapitre 5. Analyse des dependances

compte dans l’analyse des dependances ainsi que le contexte du changement (par exemple :

un parametre ajoute a une fonction, une variable supprimee d’une classe) ou l’estimation

de l’impact est realisee. Tout comme dans le domaine de la Recherche d’Information,

l’efficience d’une methodologie depend de la precision de l’estimation realisee et du taux

de rappel en prenant en compte le cout calculatoire [Kagdi 07].

Plusieurs approches ont ete developpees pour l’analyse des dependances et l’etude

d’impact en se basant sur la tracabilite ainsi que sur les relations entre les composants

du Systeme d’Information a differents niveaux d’abstraction (executables, code source,

ressources de modelisation, documentation de conception, documentation d’analyse, etc).

5.2 Tracabilite

Les livrables du processus de developpement des applications informatiques (ex-

pression d’une exigence, code source, tests, modeles, rapports, documents de planification,

etc.) sont egalement appeles artefacts. La tracabilite represente la capacite de decrire et

de suivre leur vie dans les deux directions : en allant de l’expression des exigences jus-

qu’au modules de l’architecture logicielle et au code source de l’application et vice-versa

[Gotel 94].

La tracabilite peut nous fournir des renseignements importants pour l’evolution

du Systeme d’Information et nous aider dans sa comprehension top-down ou bottom-up.

Elle fournit egalement des informations sur les relations existantes entre les exigences,

la conception et l’implementation des logiciels etant ainsi un support propice a l’etude

d’impact.

Les outils actuels n’assurent pas de maniere satisfaisante la tracabilite. Cette

inadequation constitue une des causes les plus importantes dans le depassement des delais

et/ou l’echec des projets logiciels [Domges 98].

Quelques outils presents dans le milieu academique ou commercial sont dispo-

nibles pour la gestion de la tracabilite entre les differents livrables des projets de develop-

pement.

[Kagdi 07] Kagdi Huzefa et Maletic Jonathan I. Combining single-version and evolutionary de-

pendencies for software-change prediction. MSR ’07 : Proceedings of the Fourth Interna-

tional Workshop on Mining Software Repositories. Washington, DC, USA. IEEE Com-

puter Society, 2007, p 17.

[Gotel 94] Gotel O. et Finkelstein A. An analysis of the requirements traceability problem. In Pro-

ceedings of 1st International Conference on Requirements Engineering (Colorado Springs,

CO). Los Alamitos, CA,. IEEE Computer Society Press, 1994, p 94–101.

[Domges 98] Domges Ralf et Pohl Klaus. Adapting traceability environments to project-specific

needs. Commun. ACM, 1998, vol 41, n 12, p 54–62.

84

5.2. Tracabilite

DOORS [Doors 08], Rational RequisitePro [Requisite 08] et RDD-100 [RDD 08]

sont des outils commerciaux qui fournissent des fonctionnalites d’enregistrement, d’affi-

chage et de verification de la completude des livrables projets. Ils utilisent des moyens

graphiques pour afficher la maniere avec laquelle chaque donnee est connectee aux autres

et a sa source.

TOOR (Traceability of Object-Oriented Requirements) [Pinheiro 96] est un outil

de recherche qui prend en compte une vision plus large des exigences en y incluant les

facteurs sociaux en plus de ceux techniques ou fonctionnels. Cet outil permet de positionner

entre les livrables des liens personnalisables par les utilisateurs entre deux memes objets

afin de traduire differents types de relations.

La tracabilite entre les artefacts a egalement ete abordee par [Maletic 01] et

[Settimi 04] qui proposent une mise en relation du code source et des elements des modeles

UML en utilisant une representation XML[W3C 08] de ces deux ressources.

Le point faible de tous ces outils est le fait qu’ils ne supportent pas la maintenance

automatique ou semi-automatique des liens de tracabilite et ne prennent pas en compte

les nouvelles versions des artefacts [Alexander 02]. Ainsi, la detection et la maintenance

des liens de tracabilite doivent etre operees de maniere manuelle, engendrant des couts

importants. L’investissement est d’autant plus lourd si nous prenons en consideration la

nature iterative des processus de developpement [Cleland-Huang 03].

Le probleme de l’identification et de la reconstitution des liens de tracabilite a

[Doors 08] Telelogic AB, Telelogic AB, PO Box 4128, Kungsgatan 6, SE-203

12 Malmo, Sweden. Telelogic DOORS, 2008. Disponible sur :

http ://www.telelogic.com/products/doors/index.cfm (consulte le 07.08.2009).

[Requisite 08] IBM Corporation. Rational RequisitePro, 2008. Disponible sur : http ://www-

01.ibm.com/software/awdtools/reqpro/ (consulte le 07.08.2009).

[RDD 08] Holagent Coorporation. RDD-100, 2008. Disponible sur :

http ://www.holagent.com/products/ (consulte le 07.08.2009).

[Pinheiro 96] Pinheiro Francisco A. C. et Goguen Joseph A. An object-oriented tool for tracing

requirements. IEEE Softw., 1996, vol 13, n 2, p 52–64.

[Maletic 01] Maletic Jonathan et Marcus Andrian. Supporting program comprehension using se-

mantic and structural information. ICSE ’01 : Proceedings of the 23rd International

Conference on Software Engineering. Washington, DC, USA. IEEE Computer Society,

2001, p 103–112.

[Settimi 04] Settimi Raffaella, Cleland-Huang Jane, Khadra Oussama Ben, Mody Jigar, Lu-

kasik Wiktor et DePalma Chris. Supporting software evolution through dynamically

retrieving traces to uml artifacts. IWPSE ’04 : Proceedings of the Principles of Software

Evolution, 7th International Workshop. Washington, DC, USA. IEEE Computer Society,

2004, p 49–54.

[W3C 08] Voir reference [W3C 08] definie page 60.

[Alexander 02] Alexander Ian. Towards automatic traceability in industrial practice. Proceedings of

1st International Workshop on Traceability in Emerging Forms of Software Engineering.

2002, p 26–31.

[Cleland-Huang 03] Cleland-Huang Jane, Chang Carl K. et Christensen Mark. Event-based traceability

for managing evolutionary change. IEEE Trans. Softw. Eng., 2003, vol 29, n 9, p 796–810.

85

Chapitre 5. Analyse des dependances

souvent ete aborde dans la litterature specialisee sous l’angle de la relation entre le code

source et les elements de conception associes, en particulier des elements des diagrammes

UML. [Briand 03] utilise des regles de modification specifiees en langage OCL ; [Egyed 02]

recupere les liens de tracabilite en analysant les classes Java employees au moment de

l’execution d’un scenario ; [Richardson 04] s’interesse aux liens de tracabilite dans le cadre

des programmes generes automatiquement a partir de specifications formelles ; [Lucia 07]

emploie des techniques de recherche d’information pour la reconstitution des liens de tra-

cabilite.

5.3 Analyse des dependances - livrables de conception et de

developpement

La plupart des mecanismes d’etude d’impact se situent au niveau du code. Nous

en detaillerons quelques principes dans les sections suivantes de ce chapitre.

Quelques mecanismes d’etude d’impact ont ete proposes au niveau des livrables de

conception, tels que les modeles UML [Briand 03]. Ceux-ci se basent sur des specifications

formelles des regles d’impact, decrites en langage OCL [OMG 06b], entre les elements du

modele.

Des chercheurs se sont interesses a l’analyse des dependances en amont de l’evo-

lution du code (au moment de l’expression des exigences utilisateur) et, en aval, entre les

composants deployes. Le premier cas est detaille dans le paragraphe suivant, 5.4 de ce

chapitre, alors que le second cas ne sera pas traite dans ce manuscrit. Il est presente en

detail dans [Belguidoum 06].

Dans la litterature de specialite, de nombreux travaux s’orientent prioritairement

sur l’estimation des changements au niveau du code source. Neanmoins, l’estimation des

[Briand 03] Briand L. C., Labiche Y. et O’Sullivan L. Impact analysis and change management

of uml models. ICSM ’03 : Proceedings of the International Conference on Software

Maintenance. Washington, DC, USA. IEEE Computer Society, 2003, p 256.

[Egyed 02] Egyed Alexander et Grunbacher Paul. Automating requirements traceability : Beyond

the record & replay paradigm. ASE ’02 : Proceedings of the 17th IEEE international

conference on Automated software engineering. Washington, DC, USA. IEEE Computer

Society, 2002, p 163.

[Richardson 04] Richardson Julian et Green Jeff. Automating traceability for generated software ar-

tifacts. ASE ’04 : Proceedings of the 19th IEEE international conference on Automated

software engineering. Washington, DC, USA. IEEE Computer Society, 2004, p 24–33.

[Lucia 07] Lucia Andrea De, Fasano Fausto, Oliveto Rocco et Tortora Genoveffa. Recove-

ring traceability links in software artifact management systems using information retrieval

methods. ACM Trans. Softw. Eng. Methodol., 2007, vol 16, n 4, p 13.

[OMG 06b] Voir reference [OMG 06b] definie page 75.

[Belguidoum 06] Belguidoum Meriem et Dagnat Fabien. Analysis of deployment dependencies in software

components. SAC ’06 : Proceedings of the 2006 ACM symposium on Applied computing.

New York, NY, USA. ACM, 2006, p 735–736.

86

5.4. Analyse des dependances - code source des applications

impacts sur l’ensemble des livrables du cycle de developpement logiciel reste un axe de

recherche important.

5.4 Analyse des dependances - code source des applications

Deux approches orthogonales se remarquent : celle classee dans le domaine de

recherche Software-Change Impact Analysis (IA) [Bohner 96] et celle du domaine de re-

cherche Mining Software Repositories (MSR) [Gall 03][German 04].

L’approche IA definit des principes d’analyse de dependance entre les artefacts

logiciels au meme niveau d’abstraction (de code source a code source, entre livrables de

conception, etc). Cette analyse de dependance se base sur les relations qu’entretiennent

les livrables ou les elements d’un livrable au meme niveau d’abstraction. Cette approche

utilise generalement une seule version des livrables.

L’approche basee sur MSR prend en compte exclusivement le code source des pro-

grammes. L’avantage de cette approche est que la methodologie prend en compte plusieurs

versions du logiciel. L’analyse d’un ensemble de versions permet de definir des patterns

de modifications qui sont prises en compte pour predire de futurs changements dans les

versions ulterieures. Un autre mecanisme, base sur MSR, analyse des mises a jour reali-

sees de l’entrepot pour identifier des dependances a l’aide des changements concomitants.

[Zimmermann 04].

Kagdi [Kagdi 07] propose de combiner les deux methodes pour ameliorer les per-

formances globales.

5.4.1 Graphe de dependances

Une representation interessante des programmes peut etre realisee a travers le

graphe de dependance du programme, traduction du terme anglais Program Dependence

[Bohner 96] Bohner Shawn et Arnold Robert. Software Change Impact Analysis. Wiley, 1996. 392

p.

[Gall 03] Gall Harald, Jazayeri Mehdi et Krajewski Jacek. Cvs release history data for de-

tecting logical couplings. IWPSE ’03 : Proceedings of the 6th International Workshop on

Principles of Software Evolution. Washington, DC, USA. IEEE Computer Society, 2003,

p 13.

[German 04] German Daniel M. An empirical study of fine-grained software modifications. ICSM

’04 : Proceedings of the 20th IEEE International Conference on Software Maintenance.

Washington, DC, USA. IEEE Computer Society, 2004, p 316–325.

[Zimmermann 04] Zimmermann Thomas, Weisgerber Peter, Diehl Stephan et Zeller Andreas. Mining

version histories to guide software changes. ICSE ’04 : Proceedings of the 26th Internatio-

nal Conference on Software Engineering. Washington, DC, USA. IEEE Computer Society,

2004, p 563–572.

[Kagdi 07] Voir reference [Kagdi 07] definie page 84.

87

Chapitre 5. Analyse des dependances

Graph – PDG introduit dans [Ferrante 87] et [Ottenstein 84]. Le PDG explicite les de-

pendances entre les donnees mais aussi entre les structures de controle. Les dependances

exprimees dans le PDG connectent des parties du programme d’un point de vue calcula-

toire. Il est ainsi plus facile d’identifier des ameliorations possibles au niveau du code telles

que la vectorisation, la reorganisation du code pour eliminer les boucles, pour dedoubler

l’execution des passages, etc... Le PDG est donc largement utilise dans l’optimisation des

compilateurs pour des machines vectorielles ou paralleles.

Le PDG, qui considerait le programme d’une maniere monolithique, a ete etendu

pour prendre en compte les collections de procedures dans le cadre du System Dependence

Graphs – SDG [Binkley 91]. Le SDG, faisant l’objet d’un US-Pattent, utilise dans l’algo-

rithme de construction le contexte d’appel d’une procedure, ameliorant ainsi les techniques

de decoupage des programmes [Horwitz 04].

5.4.2 Decoupage des programmes – Program slicing

Le decoupage des programmes (traduction du terme anglais program slicing) est

une technique qui vise a extraire des parties d’un programme en respectant des regles spe-

cifiques. Depuis que Weiser a propose la notion de program slicing [Weiser 84] [Weiser 81],

de nombreuses variantes de decoupage et d’algorithmes ont ete etudiees. Celles-ci varient

de la notion statique preservant la syntaxe proposee par Weiser a une notion plus amorphe

qui ne preserve pas la syntaxe. Les algorithmes se basent sur des flux de donnees, relations

dans le flux d’information ou des graphes de dependance. L’ensemble de ces algorithmes se

base sur l’analyse du code source des programmes. En partant d’un point p de l’application

et d’une variable x, une decoupe est formee par l’ensemble des declarations et assertions

(statements) qui affectent potentiellement la valeur de x au point p de l’application. Le

programme ainsi reduit a une forme minimale (la decoupe) produit le meme effet.

Ces methodes de decoupage des programmes ont ete developpees pour aider le

debogage des applications. Neanmoins, il s’avere utile dans d’autres aspects du cycle de

developpement tels que le test des applications, la comprehension des applications, leur

[Ferrante 87] Ferrante Jeanne, Ottenstein Karl J. et Warren Joe D. The program dependence

graph and its use in optimization. ACM Trans. Program. Lang. Syst., 1987, vol 9, n 3, p

319–349.

[Ottenstein 84] Ottenstein Karl J. et Ottenstein Linda M. The program dependence graph in a

software development environment. SIGPLAN Not., 1984, vol 19, n 5, p 177–184.

[Binkley 91] Binkley David. Multi-Procedure Program Integration. These : Univ. of Wisconsin, Ma-

dison, WI, August 1991.

[Horwitz 04] Horwitz Susan, Reps Thomas et Binkley David. Interprocedural slicing using depen-

dence graphs. SIGPLAN Not., 2004, vol 39, n 4, p 229–243.

[Weiser 84] Weiser Mark. Program slicing. IEEE Transactions on Software Engineering, July 1984,

vol 10, n 4, p 352–357.

[Weiser 81] Weiser Mark. Program slicing. ICSE ’81 : Proceedings of the 5th international confe-

rence on Software engineering. Piscataway, NJ, USA. IEEE Press, 1981, p 439–449.

88

5.5. Analyse des dependances - exigences des utilisateurs

parallelisation ou leur maintenance. Des methodes (algorithmes et outils facilitant le decou-

page des programmes) ont ete developpees pour une variete de langages de programmation

tels que C [Wisconsin00 00], Java [Hatcliff 99], Oberon-2 [Oberon 08], Ada [Sward 04].

5.5 Analyse des dependances - exigences des utilisateurs

L’ingenierie des exigences (requirements engineering) [Pohl 87] a comme objec-

tif l’amelioration de la conception des systemes, en analysant et comprenant le plus tot

possible les aspects critiques d’un systeme avant meme de le construire. Comme Brooks

[Brooks 87] l’observe, la definition des besoins et des exigences est l’etape du projet la plus

difficile mais egalement celle qui a le plus d’influence negative si elle n’est pas bien realisee.

Parmi les problematiques traitees dans la gestion des exigences, celle de l’analyse

et de la maıtrise des dependances entre les differentes exigences exprimees est essentielle.

Un systeme a de nombreux composants, chacun repondant a une serie d’exigences in-

teragissant avec d’autres exigences ou avec l’environnement. Ainsi, la satisfaction d’une

exigence peut aider ou empecher la satisfaction d’une autre [van Lamsweerde 00].

En effet, les dependances mal gerees peuvent avoir des consequences sur le bon

fonctionnement des applications informatiques et peuvent provoquer le mecontentement

des utilisateurs [Feather 00].

La gestion des interactions fonctionnelles Requirements Interaction Management

[Wisconsin00 00] University of Wisconsin-Madison. The Wisconsin Program-Slicing Tool, Version 1.1,

2000. Disponible sur : http ://www.cs.wisc.edu/wpis/slicing tool/ (consulte le 07.08.2009).

[Hatcliff 99] Hatcliff John, Corbett James, Dwyer Matthew, Sokolowski Stefan et Zheng

Hongjun. A formal study of slicing for multi-threaded programs with jvm concurrency

primitives. Proceedings of the 6th International Static Analysis Symposium (SAS’99).

Springer-Verlag, 1999, p 1–18.

[Oberon 08] Institut fur Systemsoftware, Johannes Kepler Universitat, Institut fur Systemsoft-

ware, Altenbergerstr. 69, A-4040 Linz. Oberon Slicing Tool, 2008. Disponible

sur : http ://www.ssw.uni-linz.ac.at/Research/Projects/ProgramSlicing/ (consulte le

07.08.2009).

[Sward 04] Sward Ricky E. et Chamillard A.T. Adaslicer : an ada program slicer. Ada Lett., 2004,

vol XXIV, n 1, p 10–16.

[Pohl 87] Pohl Klaus. Requirements engineering : An overview. In Encyclopedia of Computer

Science and Technology, 1987, vol 36, n 21.

[Brooks 87] Brooks Frederic. No silver bullet : Essence and accidents of software engineering. Com-

puter, 1987, vol 20, n 4, p 10–19.

[van Lamsweerde 00] v Lamsweerde Axel et Letier Emmanuel. Handling obstacles in goal-oriented requi-

rements engineering. IEEE Transactions on Software Engineering, 2000, vol 26, n 10, p

978–1005.

[Feather 00] Feather Martin, Cornford Steven et Gibbel Mark. Scalable mechanisms for re-

quirements interaction management. Proceedings of the 4th International Conference on

Requirements Engineering –(Schaumburg, Illinois June 2000). IEEE Computer Society

Press, 2000, p 119–129.

89

Chapitre 5. Analyse des dependances

(RIM), proposee par [Robinson 03], est une methode d’analyse et de management des

dependances entre les exigences utilisateurs. Cette analyse est definie plus formellement

comme un ensemble d’activites ayant comme but l’identification et le management des

relations critiques parmi un ensemble d’exigences. L’emploi des ces methodes d’analyse

vise l’amelioration de la satisfaction globale des utilisateurs.

5.6 Analyse des dependances - execution des programmes

L’analyse des dependances telle que decrite precedemment est une technique

d’analyse pour identifier et determiner des types varies de dependances dans le code source

des applications. Elle est utilisee dans les activites de test, de correction, de reverse engi-

neering et de maintenance. Si cette analyse statique des dependances au niveau du code

est relativement bien maıtrisee, l’analyse dynamique des dependances de programmes au

moment de l’execution est bien plus difficile dans la mesure ou l’execution de leurs com-

posantes reste imprevisible. Plusieurs methodes ont ete proposees dans la litterature spe-

cialisee pour l’analyse de ces dependances en fonction des environnements, des langages

de programmation et de la complexite des programmes sequentiels ou concurrents. Une

etude comparative de ces techniques et methodes est proposee dans [Chen 02].

5.7 Synthese

Actuellement, aucune methode n’offre veritablement une analyse des dependances

et une etude d’impact globale prenant en compte les differents niveaux d’abstraction, en

allant de l’expression des exigences jusqu’au code source de l’application et en passant par

les differents phases du processus de developpement.

[Robinson 03] Robinson William N., Pawlowski Suzanne D. et Volkov Vecheslav. Requirements

interaction management. ACM Computing Surveys, 2003, vol 35, n 2, p 132–190.

[Chen 02] Chen Zhenqiang, Xu Baowen et Zhao Jianjun. An overview of methods for dependence

analysis of concurrent programs. SIGPLAN Not., 2002, vol 37, n 8, p 45–52.

90

5.7

.Syn

these

Technologie Avantages Inconvenients

Tracabilite

DOORS [Doors 08], Rational Re-quisitePro [Requisite 08], RDD-100[RDD 08]

Outils commerciaux qui fournissent des fonc-tionnalites d’enregistrement, d’affichage et deverification de la completude des livrables pro-jets.

Ces outils se limitent a la gestion des livrables duprojet en dressant leur liste et leur contenu. Leniveau de detail n’est pas suffisamment precis.Ils ne fournissent pas une gestion des versionsde la documentation de conception.

TOOR (Traceability of Object-Oriented Requirements)[Pinheiro 96]

Outil de recherche des exigences, prend encompte des facteurs sociaux, techniques et fonc-tionnels

Tres peu employe.

Analyse des dependances

Livrables de conception et de deve-loppement 5.3

Plusieurs approches proposees en utilisant delangages formelles tels que OCL[OMG 06b].

Les charges associees a la realisation, la mainte-nance et l’exploitation d’un tel modele sont treselevees.

Code source des applications 5.4 Deux approches proposees Software-Change Im-pact Analysis (IA) et Mining Software Reposi-tories (MSR) pour analyser le code source desapplication et en deduire des dependances.

L’analyse est tres couteuse du point de vue cal-culatoire mais permet de deduire des depen-dances liees a l’architecture des applications :reutilisation du code source, heritage, delega-tion, etc.

Program slicing - Decoupage desprogrammes 5.4.2

Ces methodes permettent d’optimiser le decou-page des applications afin d’harmoniser et opti-miser les flux des donnees ; tres utile dans unedemarche de refonte des applications.

Elles sont moins utiles pour l’analyse des depen-dances.

Execution des programmes 5.6 Analyse dynamique des dependances de pro-grammes au moment de l’execution est tres plusdifficile car l’execution de leurs composantesreste imprevisible .

Champ de recherche encore en exploration.

Table 5.1 – Tableau de synthese des propositions

91

Chapitre 5. Analyse des dependances

92

Conclusion

L’etat de l’art presente dans cette partie nous permet de couvrir une partie de

la problematique exprimee au debut de ce manuscrit, pouvoir repondre aux questions

suivantes :

1. Comment maıtriser la composante documentaire ? Comment modeliser la reglemen-

tation ?

2. Comment maıtriser la composante logicielle ? Comment modeliser les composants du

Systeme d’Information ?

3. Comment unifier les deux composantes de la matiere reglementaire (lien entre les

documents et les composants du SI) ?

4. Comment tracer l’utilisation des connaissances dans l’ensemble de la matiere regle-

mentaire ?

5. Comment analyser les impacts d’une evolution fonctionnelle ou legislative ?

6. Comment estimer l’etendue d’un impact et des charges associees a une evolution ?

1. Comment maıtriser la composante documentaire ? Comment modeliser la re-

glementation ?

En nous interessant au domaine de l’ingenierie documentaire, nous avons pu iden-

tifier une structure documentaire suffisamment generique nous permettant de representer

tout type de document. L’analyse des divers langages de modelisation nous a permis d’iden-

tifier l’opportunite d’utiliser XML pour la structuration des documents et les schemas XSD

pour leur modelisation. Par ailleurs, nous avons identifie d’autres travaux qui se sont in-

teresses a la modelisation de la reglementation.

2. Comment maıtriser la composante logicielle ? Comment modeliser les compo-

sants du Systeme d’Information ?

Cette meme analyse a ete realisee pour le Systeme d’Information. Suite a notre

analyse, UML s’est avere le choix le plus adapte pour la modelisation du Systeme d’In-

formation. Par ailleurs, UML nous permet d’exporter les modeles realises dans un format

XML en utilisant la norme XMI.

93

Conclusion

3. Comment unifier les deux composantes de la matiere reglementaire (lien entre

les documents et les composants du SI) ?

Nous avons identifie differentes manieres de modeliser la composante documen-

taire et la composante logicielle tout en utilisant le meme langage de representation : le

langage XML. Celui-ci represente la base technique de leur mise en relation. En revanche,

il faut identifier les elements a mettre en relation entre les deux composantes. Le chapitre

6 va detailler les mecanismes que nous proposons pour cette mise en relation.

4. Comment tracer l’utilisation des connaissances dans l’ensemble de la matiere

reglementaire ?

5. Comment analyser les impacts d’une evolution fonctionnelle ou legislative ?

6. Comment estimer l’etendue d’un impact et des charges associees a une evolu-

tion ?

Ces questions n’ont trouve que des reponses partielles dans l’etat de l’art.

Pour repondre a cette problematique, nous detaillons dans la partie suivante

nos propositions pour l’etude d’impact. En nous appuyant sur l’etat de l’art en matiere

d’analyse de dependances entre les livrables de conception et entre les exigences des utilisa-

teurs, nous proposons une analyse globale des dependances en considerant simultanement

les differents niveaux d’abstraction : l’expression des exigences, la documentation de spe-

cification, la documentation de conception.

Par ailleurs, les travaux de recherche sur l’analyse des dependances, d’une part,

au sein du code source des applications et, d’autre part au moment de l’execution des

programmes viendront enrichir les perspectives scientifiques de notre travail.

94

Troisieme partie

Propositions pour l’etude d’impact

95

Introduction

Ayn Rand definit la connaissance comme la comprehension mentale d’un fait de

realite, obtenue soit par l’observation perceptuelle directe, soit par un processus de la raison

fonde par l’observation perceptuelle [Rand 79]. La connaissance est une notion abstraite

qui peut englober des informations complexes telles que : les processus, les actions, la

causalite, le temps, les motivations, les hypotheses, les objectifs, etc. Par ailleurs, on peut

considerer comme « connaissance » tout ce qui est connu par un individu ou par une

societe.

Il convient de distinguer : la connaissance, sa formulation et sa representation.

La representation de connaissance est un substitut pour la connaissance elle-meme. Les

personnes ou les applications ont besoin d’utiliser de telles representations lors de l’expres-

sion des connaissances, de leur communication ou d’un raisonnement qui leur est associe.

David Jouve [Jouve 03a] realise une nette distinction entre ces deux formes resultantes :

– la formulation des connaissances est leur representation en langage naturel.

Formuler les connaissances est le moyen le plus employe par les humains dans

la communication. Par exemple, les documents reglementaires sont des objets

offrant une base pour la formulation de certaines connaissances juridiques.

– la representation des connaissances est leur transcription dans un langage for-

mel ou semi-formel. Par exemple, l’expression des normes juridiques entrepo-

sees au sein d’une base de connaissances est une forme de representation des

connaissances.

L’hypothese dans ce travail de recherche se fonde sur la constatation suivante :

des ressources de nature differente et heterogenes (documents reglementaires, Systeme

d’Information, ressources de conception du Systeme d’Information, modeles du Systeme

d’Information) sont des representations variees pour encoder la meme connaissance du

domaine. Dans certains cas, nous sommes en presence d’une formulation de connaissances

et dans d’autre cas, d’une representation plus ou mois formelle. Pour chaque categorie,

plusieurs formalismes sont disponibles.

[Rand 79] Rand Ayn. Introduction to Objectivist Epistemology. New American Library, New York,

USA, 1979. 314 p.

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

97

Introduction

Nous avons montre dans le chapitre « Problematique » qu’un des enjeux majeurs,

auxquels les institutions telles que la Cnaf doivent faire face, est constitue par la nature

changeante de leur patrimoine des connaissances metier. Chaque evolution reglementaire,

fonctionnelle ou corrective a une consequence, directe ou indirecte, sur un ensemble de

ressources du patrimoine reglementaire.

Nous avons presente dans la partie consacree a l’etat de l’art que des recherches

ont abouti a des mecanismes qui offrent des reponses a des problematiques de modelisation

du patrimoine reglementaire. Des formalismes, tels qu’UML, nous permettent de modeliser

le Systeme d’Information (composante logicielle de ce patrimoine reglementaire). D’autres

formalismes ont ete proposes pour la modelisation des documents.

En revanche, nous ne disposons pas des mecanismes pour la definition d’un modele

commun assurant la coherence globale entre les connaissances explicitees soit dans les docu-

ments reglementaires soit dans les composantes du Systeme d’Information (respectivement

la composante documentaire et la composante logicielle d’un patrimoine reglementaire).

Bien que les divers modeles de formulation ou de representation des connaissances

ne soient pas strictement isomorphiques, ils peuvent neanmoins etre mis en relation. Leur

mise en relation et leur maıtrise conjointe passent par la maıtrise des connaissances expri-

mees dans leurs diverses representations.

Dans cette partie, nous proposons un modele generique pour la representation des

relations de dependances, commun a la fois a la composante documentaire et a la compo-

sante logicielle. Ce modele generique est ensuite enrichi avec des mecanismes d’etude d’im-

pact qui, en s’affranchissant des specificites de chacune de ces composantes, nous permet

d’assurer la coherence globale du patrimoine reglementaire et du Systeme d’Information.

La mise en relation des differentes composantes de ce patrimoine (composante

documentaire, composante logicielle) nous permettra :

– de conserver une trace de la provenance des informations a l’origine des even-

tuelles modifications,

– de pouvoir conduire de raisonnements,

– de faciliter la maintenance et d’assurer la coherence des ressources heterogenes,

– d’exploiter les diverses representations pour une meilleure gestion des ressources

documentaires, des ressources de conception d’une organisation,

– d’exploiter les liens entretenus afin d’etablir des etudes d’impact globales.

98

Chapitre 6

Cadre pour l’etude d’impact

Sommaire

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.2 Modele d’etude d’impact – Niveaux d’abstraction . . . . . 101

6.2.1 Niveau d’abstraction N 0 – le monde reel et les connaissances

du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.2.2 Niveau d’abstraction N 1 – la representation du monde reel 103

6.2.3 Niveau d’abstraction N 2 – le modele de representation . . . 104

6.2.4 Niveau d’abstraction N 3 – le modele d’etude d’impact . . . 104

6.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.3 Modele d’etude d’impact - Niveau d’abstraction N3 . . . 105

6.3.1 Connaissances d’un domaine . . . . . . . . . . . . . . . . . . 105

6.3.2 Structure statique du meta-modele . . . . . . . . . . . . . . 107

6.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.3.4 Specialisation du meta-modele - Niveau d’abstraction N2 . 110

6.3.5 Representation des dependances – Niveau d’abstraction N1 111

6.3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.1 Introduction

Un modele est une representation abstraite du monde reel offrant une vision

schematique d’un certain nombre d’elements qui nous interessent. Le modele nous aide

ainsi a mieux comprendre le monde reel en n’y retenant qu’un ensemble de concepts qui

representent mieux la realite selon un point de vue precis.

Par exemple, dans le domaine de l’urbanisme, pour la construction d’un batiment

on va utiliser le meme modele du batiment, le monde reel, mais avec des vues differentes

selon les divers corps de metier. Sur chaque vue on n’y represente que les elements qui

99

Chapitre 6. Cadre pour l’etude d’impact

sont necessaires a un corps metier et en faisant abstraction des autres details. Les electri-

ciens vont utiliser une vue sur le modele du batiment qui represente les murs, les circuits

electriques, les caracteristiques des cables electriques a utiliser tandis que les peintres se-

ront plutot interesses par la nature des murs, les types de peinture a utiliser, etc. Afin de

faciliter les taches de ces deux corps de metiers, ces deux vues (representant pourtant le

meme modele de la meme realite) sont differentes : elles n’emploient pas le meme ensemble

d’elements, ni le meme formalisme.

Par ailleurs, « un dessin vaut mieux qu’un long discours » a-t-on coutume de

dire. Un modele peut egalement servir d’interface commune pour communiquer et pour

echanger des points de vue afin d’avoir une comprehension commune et precise d’un meme

probleme.

Une evolution du monde reel doit etre reportee sur l’ensemble des modeles le

decrivant. Dans l’exemple precedant, une evolution dans la consistance d’un mur affecte le

travail de l’electricien mais pas celui du peintre alors que la position de la fenetre affecte

le travail des deux metiers. Une evolution peut demander a un corps de metier de faire

des choix qui impactent le travail des autres.

Pour avoir une vision claire des effets d’une possible modification nous devons

donc prendre soin de mettre en relation les deux modeles et de raisonner de maniere

globale.

Le cas decrit ci-dessus est revelateur de la problematique plus generale presente

au sein de la Branche Famille, liee a la gestion du patrimoine reglementaire.

Contrairement au domaine de la construction, nous ne disposons pas d’un meme

modele pour representer, meme avec de vues differentes, a la fois la composante logicielle

et la composante documentaire.

Nous avons presente dans la partie « Etat de l’art » que nous disposons de mo-

deles differents pour la representation du Systeme d’Information, pour la modelisation des

documents et pour la representation des connaissances.

Mais la maıtrise du patrimoine reglementaire passe par :

– la mise en relation des deux composantes (logicielle et documentaire) ;

– l’etude d’impact globale, sur les ressources heterogenes presentes dans ces deux

composantes.

Pour pouvoir mettre en relation les deux composantes logicielle et documentaire,

il faut pouvoir s’affranchir des specificites de chaque domaine et des concepts specifiques

employes par les differents modeles et les differentes representations. Cela passe par la

maıtrise des connaissances partagees.

Ainsi, pour une bonne maıtrise du patrimoine reglementaire il faut utiliser un seul

modele commun a toutes ces representations. Chacune de ces representations sera une vue

differente du meme modele. Lors de la definition de ce modele commun nous ne retiendrons

100

6.2. Modele d’etude d’impact – Niveaux d’abstraction

que les concepts de base, elementaires, communs a ces differentes representations et les

relations elementaires qu’ils entretiennent.

Par ailleurs, pour realiser des etudes d’impact sur ce modele commun nous nous

interesserons a la constitution de ces composantes, a leurs sous-ensembles et leurs ele-

ments, et a la maniere dont ceux-ci sont interconnectes. En partant d’une evolution d’un

composant systeme, notre mecanisme doit pouvoir evaluer l’effet qu’elle a sur les autres

constituants du SI.

Nous proposerons un modele generique representant les dependances entre des

concepts du domaine modelise. Nous allons egalement doter ce modele des mecanismes de

raisonnement pour realiser les estimations des effets qu’une modification peut avoir sur

l’ensemble des composants du systeme. L’exploitation des instances de ce modele nous

conduira ainsi a des etudes d’impact.

Les chapitres suivants presenteront l’application de ce modele et son integration

dans le Systeme d’Information et proposera l’application de ce modele a la fois au domaine

logiciel et au corpus documentaire.

6.2 Modele d’etude d’impact – Niveaux d’abstraction

Pour mettre en relation des ressources heterogenes, il faut pouvoir s’affranchir des

modeles qui portent ces ressources en raisonnant sur une structure plus generique com-

mune. Nous proposons le modele d’etude d’impact. Le modele d’etude d’impact jouera

donc le role d’un meta-modele commun pour plusieurs modeles de representation speci-

fiques.

Ainsi, a l’image du domaine de la construction, l’ensemble de ces ressources (les

documents reglementaires, les documents de conception, les composantes du Systeme d’In-

formation) representent des vues de ce meme modele commun d’etude d’impact.

Nous proposons une architecture, en quatre niveaux d’abstraction (voir la figure

6.1). Ensuite nous fournissons les bases pour la mise en relation et l’etude d’impact.

Cette architecture detaillee ci-dessous propose un graphe comme mode de repre-

sentation des connaissances en s’interessant aux dependances. Ce graphe sera le support

de l’analyse des dependances et de l’etude d’impact. Ce mode de representation est definit

par un modele commun aux differentes representations.

6.2.1 Niveau d’abstraction N 0 – le monde reel et les connaissances du

domaine

Dans le niveau d’abstraction le plus bas de cette architecture on retrouve le monde

reel et les connaissances du domaine concerne.

Le metier de la Branche Famille de la Securite Sociale consiste a calculer les

101

Chapitre 6. Cadre pour l’etude d’impact

Modèle d’étude d’impact

Connaissances du domaine N 0

Représentation des dépendances / Graphe canonique d’étude d’impact

Modèle de la représentation A

des connaissances

Modèle d’étude d’impact / Méta-modèle des représentations A, B, C

Modèle de la représentation B

des connaissances

Modèle de la représentation C

des connaissances

N 3

N 2

N 1

Représentation A des connaissances

Représentation B des connaissances

Représentation C des connaissances

Relation « instance de… » 

Relation de traduction

Figure 6.1 – Cadre pour l’etude d’impact - Architecture en 4 niveaux d’abstraction.

prestations specifiques a chaque allocataire en fonction de la connaissance de la situation

de l’allocataire et de la connaissance legislative du domaine de la Securite Sociale. Ces

connaissances forment le premier niveau.

Par exemple a ce niveau d’abstraction, pour un allocataire, on connaıt son nom,

son prenom, sa civilite, ses revenus et ses charges. Les connaissances legislatives nous

indiquent dans quelles conditions l’allocataire a le droit a l’Aide personnalisee au logement.

A ce meme niveau, on retrouve le Systeme d’Information qui, a l’aide de l’ap-

plication de gestion des prestations Cristal et en fonction de la legislation, calcule le

montant exact de l’aide attribuee a chaque allocataire. Le Systeme d’Information est ainsi

dependant de la connaissance legislative du domaine des prestations legales. Ces liens de

dependance font egalement partie de la connaissance du domaine.

Ces connaissances du monde reel sont tacites, appartenant aux individus. Face

a la complexite de la realite et face aux besoins de communication, d’echanges et de

traitement informatise, differentes representations ont ete introduites. Ces representations

sont au niveau N1 d’abstraction.

102

6.2. Modele d’etude d’impact – Niveaux d’abstraction

6.2.2 Niveau d’abstraction N 1 – la representation du monde reel

Un « modele » , ou une representation, est une description d’une realite concue de

telle maniere qu’il soit possible de simuler formellement le fonctionnement de celle-ci. En

fonction des objectifs, differents modeles de representation du monde reel sont proposes.

6.2.2.1 Representation des connaissances legislatives

Comme nous avons deja evoque dans le domaine legislatif nous nous retrouvons

face a l’emploi du langage naturel dans le cadre d’une formulation des connaissances pour

une meilleure communication entre humains. La connaissance legislative est ainsi explicitee

dans des textes reglementaires.

Les connaissances legislatives sont explicitees et communiquees sous forme de

documents reglementaires. Par exemple, les conditions d’attribution de l’Aide personnalise

au logement sont explicitees dans un document de reference de l’Institution [CNAF 08]

dont voici un extrait :

Qualite

Toute personne physique :

– personne seule,

– menage (l’un ou l’autre des deux conjoints ou concubins), quel que soit celui

qui est titulaire du bail ou du contrat de pret.

Remarque :Les partenaires d’un Pacs sont assimiles aux concubins dans toute la

suite du document.

Charges de logement Assumer le paiement d’un loyer prevu par un bail conforme

a la convention ou le remboursement d’emprunts (Cf. paragraphe 42). Exception : La prise

en charge du paiement du loyer par l’aide sociale ne fait pas obstacle au paiement de l’APL.

Les informations concernant l’etat civil d’un allocataire ont une representation

sous forme d’enregistrement dans une base de donnees.

6.2.2.2 Representation des connaissances de la composante logicielle

Les applications du Systeme d’Information telles que le systeme de gestion des

prestations Cristal peuvent disposer d’une representation sous forme de modele UML.

6.2.2.3 Representation des connaissances liees aux dependances

Le Systeme d’Information est dependant de la legislation. Des representations

existent pour expliciter les connaissances legislatives ou les connaissances du Systeme

[CNAF 08] Caisse Nationale des Allocations Familiales, 32, avenue de la Sibelle, 75685 PARIS CEDEX

14. Aide personnalisee au logement - Suivi legislatif, 2008.

103

Chapitre 6. Cadre pour l’etude d’impact

d’Information. Nous ne disposons pas d’une representation commune pour representer les

dependances entre ces connaissances.

Pour des besoins specifiques lies a l’etude d’impact, nous avons besoin d’une

representation des dependances que les connaissances du domaine entretiennent les unes

avec les autres. Une representation sous forme de graphe serait la plus appropriee a ces

besoins car elle nous permet d’appliquer les principes et les algorithmes de parcours de

graphes pour identifier les impacts. Puisqu’un tel graphe represente les elements de base

du domaine modelise, ainsi que les relations qu’ils entretiennent, il sera appele graphe

canonique des dependances ou graphe canonique d’etude d’impact.

Les representations des connaissances specifiques aux differents domaines (e.g.

documentaire, Systeme d’Information) sont traduites dans un graphe de dependances. La

structure de ce graphe, les modalites de creation ainsi que les principes de parcours sont

decrits dans la section suivante.

6.2.3 Niveau d’abstraction N 2 – le modele de representation

L’abstraction realisee en proposant une modelisation de la realite par des forma-

lismes de representation de connaissances peut etre etendue a une abstraction de ceux-ci.

Chaque structure de representation de connaissances du niveau d’abstraction N 1 est, a

son tour, decrite par un modele dans le niveau d’abstraction N 2.

Par exemple, un document legislatif peut etre modelise a l’aide d’un schema

documentaire. Dans la partie Etat de l’art nous avons presente plusieurs langages de mo-

delisation de documents tels que les DTD Document Type Definition et les XML schemas.

Par ailleurs les representations sous forme de modele UML sont definies par le

modele du langage UML, plus communement appele le meta-modele UML [OMG 01].

6.2.4 Niveau d’abstraction N 3 – le modele d’etude d’impact

Le meta-modele est une structure generique a l’aide de laquelle tous les autres

modeles du niveau d’abstraction N 2 peuvent etre derives. L’avantage de l’utilisation de ce

meta-modele est de rendre les definitions des modeles et des representations independantes

des domaines d’application et de fournir ainsi un ensemble de concepts precis et concis

pour la definition de nouveaux modeles. Cette definition nous permet de mettre en relation

des concepts specifiques aux differents domaines presents au niveau N1.

Ce meta-modele d’etude d’impact est en effet le modele d’etude d’impact. L’en-

semble des modeles de representation du monde reel peut etre traduit dans une instance

de ce modele en produisant le graphe canonique des dependances.

La section 6.3.5.2 decrit comment on obtient un modele de graphe canonique

d’etude d’impact a partir d’une analyse du domaine.

[OMG 01] Voir reference [OMG 01] definie page 74.

104

6.3. Modele d’etude d’impact - Niveau d’abstraction N3

Ce meta-modele est commun a toutes les instances de niveau N2. Il definit ainsi

les elements communs a la fois aux differents modeles de representation de connaissances et

au modele de graphe canonique d’etude d’impact. Ainsi ces concepts et les relations qu’ils

emploient nous serviront dans la mise en place des mecanismes et des principes d’etude

d’impact.

6.2.5 Conclusion

L’architecture a quatre niveaux d’abstraction presentee dans la figure 6.1 illustre

comment le principe d’abstraction peut etre etendu a des niveaux superieurs. Tout comme

l’abstraction des langages de programmation facilite l’interoperabilite entre des Systemes

d’Information developpes en utilisant des langages de programmation differents, l’abstrac-

tion des modeles facilite l’interaction entre differents modeles et leur mise en relation.

De la meme maniere qu’UML est specifie en utilisant le formalisme UML (meta-

modele) et que le meta-modele est lui-meme specifie en utilisant les concepts du Meta

Object Facility [OMG 06a], nous allons employer le langage UML pour la description des

differents modeles pour les 3 niveaux d’abstraction (description du graphe, du modele de

graphe ainsi que les modeles specifiques a chaque representation).

La suite de ce chapitre detaillera la structure du meta-modele pour l’etude d’im-

pact (niveau N3 ), la specialisation de ce meta-modele pour la description des modeles

de representation et enfin la structure et la dynamique du modele d’etude d’impact au

niveau N1. Nous presenterons egalement comme exemple l’analyse et la mise en place de

la structure de deux modeles specifiques, l’un propre au domaine documentaire et l’autre

au domaine logiciel (Niveau N2 ).

6.3 Modele d’etude d’impact - Niveau d’abstraction N3

6.3.1 Connaissances d’un domaine

Democrite (460-370 av. J.-C.), philosophe materialiste, a promu la theorie ato-

miste considerant que l’Univers est construit d’atomes et de vide. L’atome, qui en grecque

signifie « indivisible », represente ces blocs de base. Les futures recherches en physique ont

montre que les atomes etaient eux-memes composes de plus petits constituants : l’electron,

le proton, le neutron qui, a leur tour, pouvaient etre percus comme un assemblage d’autres

objets encore plus petits, appeles particules elementaires.

Ainsi, nous avons l’habitude de considerer le monde qui nous entoure, plus genera-

lement l’Univers et plus particulierement chaque objet, comme un assemblage de quelques

uns de ces blocs fondamentaux de base que l’on peut appeler particules.

[OMG 06a] Voir reference [OMG 06a] definie page 67.

105

Chapitre 6. Cadre pour l’etude d’impact

Par ailleurs, une des principales lignes de recherche adoptees dans le cadre de

la representation des connaissances se fonde sur l’idee que les connaissances doivent etre

structurees en caracterisant les classes d’objets et les relations qui les unissent [Jouve 03a].

Ce rapprochement nous permet de considerer, dans la suite de nos travaux, que les

connaissances d’un domaines sont en effet un « assemblage » de connaissances elementaires

qui entretiennent des liens entre elles. Nous proposons ainsi les definitions suivantes.

6.3.1.1 Particules de connaissance

Definition 6.3.1. Particule de connaissances – Pour un domaine D nous considerons que

ses connaissances peuvent etre exprimees par des particules de connaissances. Tout chose

elementaire connue ou sue est particule de connaissance qui apporte sa participation a un

assemblage constituant la connaissance du domaine.

Definition 6.3.2. Ensemble des particules de connaissances – Pour un domaine D nous

considerons que toute la connaissance du domaine est encodee par les elements d’un en-

semble de particules de connaissances, note PCD. Cet ensemble peut etre definit en ex-

tension par la liste de tous ses elements, enumeration des connaissances du domaine :

PCD = {pc1, pc2, pc3, pc4, pc5, ..., pcn} ou pci, i = 1..n represente les particules de connais-

sance du domaine. Nous considerons que, par definition, cet ensemble est toujours denom-

brable.

Par exemple, les connaissances legislatives concernant les prestations legales sont

composees de connaissances specifiques a chaque prestations : aide personnalisee au lo-

gement, aide au parent isole, aide pour l’accueil d’un jeune enfant, etc. A leur tour,

les connaissances sur une prestation legale peuvent etre decomposees dans les connais-

sances reglementaire concernant les conditions d’attribution, les organismes debiteurs, les

montant des aides, etc. Les conditions d’attributions peuvent concerner l’allocataire, le

conjoint, les enfants, les revenus et ainsi de suite.

6.3.1.2 Relations elementaires

Lorsque l’on modelise un ensemble, comme une collection d’elements, on doit

rendre compte d’une correspondance entre ses elements.

Une connaissance est acquise et devient fonctionnelle quand elle fait appel a

d’autres connaissances pour raisonner, resoudre un probleme ou en deduire des nouvelles

connaissances [Vergnaud 90]. Donc lier ou relier les connaissances signifie plus que les

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

[Vergnaud 90] Vergnaud Gilles. La theorie des champs conceptuels. Recherches en didactique des

mathematiques, 1990, vol 10, p 133 – 170.

106

6.3. Modele d’etude d’impact - Niveau d’abstraction N3

mettre ensemble : c’est mettre en reseau des connaissances qui prennent ainsi du sens les

unes par rapport aux autres [Morin 99]. Les relations qu’entretiennent les particules de

connaissances peuvent donc etre tres variees.

Definition 6.3.3. Relation elementaire – Nous appelons une relation elementaire notee

R(x,y), ou x R y, une relation interne a l’ensemble de particules de connaissance PCD

induisant une forme de relation entre deux particules de connaissances x et y. Cette relation

structure notre ensemble du point de vue de la relation entre les particules de connaissances.

R : PCD → PCD , R = {(x, y) ∈ PCD × PCD |x EstEnRelationAvec y }

Proprietes de la relation R(x,y) :

– binaire : la relation elementaire intervient toujours entre deux particules de

connaissances. Donc R : PCD → PCD est par definition une relation binaire

car R ⊆ PCD × PCD . Par la suite, on notera xRy, ou R(x,y) pour signifier

que le couple (x,y) satisfait la relation R,

– interne : la relation elementaire intervient seulement entre les elements de

l’ensemble des particules de connaissances. Donc R : PCD → PCD car PCD ≡

PCD,

– non-reflexive : par convention nous considerons qu’aucune particule de connais-

sances n’est en relation avec elle-meme.

∀x ∈ PCD x¬Rx

La propriete de reflexivite/non-reflexivite est arbitraire car elle est definie par

convention en fonction de l’analyse du domaine. Puisque cette relation sera

notamment utilisee lors de l’analyse des dependances, afin de faciliter l’ex-

ploitation du modele, nous considerons que la relation elementaire n’est pas

reflexive.

– transitive : lorsqu’un premier element de PCD est en relation avec un deuxieme

element lui-meme en relation avec un troisieme, le premier element est aussi en

relation avec le troisieme

∀x, y, z ∈ PCD xRy ∧ yRz → xRz

6.3.2 Structure statique du meta-modele

Les connaissances d’un domaine evoluent. De par leur relation de dependances,

une evolution sur une connaissance a des impacts sur les autres.

[Morin 99] Morin Edgar. Relier les connaissances – Le defi du XXIe siecle. Seuil, 1999. 478 p.

107

Chapitre 6. Cadre pour l’etude d’impact

6.3.2.1 Elements impactables

Definition 6.3.4. Element impactable – Particule de connaissance susceptible d’evoluer

et donc d’etre marquee comme « impactee ». Chaque particule de connaissance peut evo-

luer. Ainsi, pour un domaine donne, l’ensemble des elements impactables est constitue par

l’ensemble des occurrences des particules de connaissance du domaine.

Definition 6.3.5. Element impacte – Un element impacte est un « element impactable »

qui a subit un impact. L’element est ainsi marque de l’etiquette « impacte ». Un element

impacte subit un impact avec un degre et une conviction d’impact superieurs a zero (voir

les definitions 6.3.8 et 6.3.9).

Definition 6.3.6. Evenement impactant – Evenement E ayant pour cible directe un ele-

ment impactable et dont la consequence est de marquer ce dernier de l’etiquette « impacte ».

Les evenements impactants se propagent sur les relations elementaires pour se repercuter

sur d’autres elements impactables (cibles indirectes). Un evenement impactant utilise la

propriete de transitivite de la relation elementaire.

Definition 6.3.7. Impact – designe la consequence de l’occurrence d’un evenement impac-

tant sur l’ensemble PCD des particules de connaissances. Ainsi, l’impact d’un evenement

impactant E sur un domaine correspond a l’ensemble des particules de connaissance du

PCD marques de l’etiquette « impacte» suite a l’occurrence de E.

Definition 6.3.8. Degre d’impact elementaire – represente, sur une echelle de 0 a 100, la

couverture estimee de l’impact sur un element impactable. Le degre d’impact elementaire

permet d’etablir une mesure estimative de l’effort necessaire pour mettre a jour l’element

afin de prendre en compte cet impact. Par exemple, cet effort peut etre traduit en nombre

de jours de travail (redaction ou developpement) necessaires pour la mise a jour du fond

documentaire ou des composants du SI.

Definition 6.3.9. Conviction d’impact elementaire – represente sur une echelle de 0 a

100 la precision avec laquelle nous pouvons affirmer la presence d’un impact elementaire.

La conviction d’impact elementaire permet de prendre en compte les cas ou les

impacts ne peuvent pas etre identifies avec certitude. La valeur 0 correspond au cas ou nous

ne pouvons pas determiner s’il existe un impact. C’est-a-dire que nous n’avons, au vu des

donnees fournies sur le systeme, aucune conviction qu’il n’y ait un impact. La valeur 100

correspond quant a elle au cas ou un impact a ete identifie a l’aide des donnees fournies. Les

valeurs intermediaires peuvent nuancer cette conviction en fonction de notre connaissance

du domaine : 75 montre plus de conviction que 50. Par analogie avec la logique floue

nous essayons ainsi de mesurer avec des heuristiques la certitude qu’un impact ait lieu

ou non. Par exemple, si les conditions d’attributions evoluent, la conviction d’impact sur

108

6.3. Modele d’etude d’impact - Niveau d’abstraction N3

la situation de l’allocataire est proche de 100 alors que sur l’organisme debiteur elle est

nulle. En revanche, nous ne pouvons pas estimer avec certitude l’impact que cela aura sur

le Systeme d’Information car cela dependra de la nature de l’evolution. En effet, s’il s’agit

juste d’une modification de types de revenus pris en compte, l’impact sera nul ; alors que

s’il s’agit de la prise en compte d’une nouvelle information, l’impact sera de 100. Ainsi,

les valeurs intermediaires nous permettent de nuancer la conviction d’impact dans des

situations ambigues.

Les particules de connaissance sont ainsi caracterisees par deux proprietes : le

degre d’impact et la conviction d’impact.

6.3.2.2 Interpretation de la relation elementaire

Du point de vue de la gestion des connaissances, les relations peuvent etre : soit

des relations de mise en commun (constitution de l’ensemble des particules de connais-

sance du domaine), soit des relations de mise en reseau pour en deduire des nouvelles

connaissances.

Du point de vue de l’etude d’impact, la signification de la relation qui lie deux

elements impactables a un role important dans la maniere de propager l’impact d’un

element impactable a un autre.

Definition 6.3.10. Coefficient de propagation – est un indice de 0 a 100, porte par toute

relation elementaire du modele, qui permet d’attenuer l’impact lors de sa propagation de

la particule A vers la particule B.

Ce coefficient depend d’un certain nombre de parametres etablis en fonction du

contexte du domaine, du type et de la signification associes a chaque relation. Dans cer-

tains cas, nous sommes surs que l’impact sera transmis a l’element correspondant, donc le

coefficient de propagation sera egal a 100 alors que, dans d’autres cas, meme s’il y a une

relation, celle-ci ne jouera aucun role dans la propagation de l’impact (coefficient egal a

0). Les valeurs intermediaires nous permettent de nuancer et repondre a des situations ou

la semantique du modele sur lequel porte l’etude n’est pas assez precise pour savoir s’il y

aura ou non une propagation de l’impact.

6.3.3 Conclusion

Les notions de particule de connaissance, « d’element impactable » et de relation

elementaire permettent d’elaborer la statique du meta-modele de representation des de-

pendances presente dans la figure 6.2. L’instanciation de ce meta-modele permet d’obtenir

un modele de graphe de dependances specifique a un domaine donne. Par la suite, une

instance de ce modele est representee par un graphe canonique des dependances qui peut

servir de support pour les etudes d’impacts.

109

Chapitre 6. Cadre pour l’etude d’impact

-degréImpact -convictionImpact

ElementImpactable

-coefficientPropagation

RelationElementaire

EvénementImpactant -degréImpact -convictionImpact

Impact

élémentOrigine

1

relation

relation

élémentCible

élémentImpacté 1

événement impacts

1

impact

0..*

0..*

0..*

0..*

ParticuleElementaire Est une

I m p

a c t

e

S u

b i t

Produit

Participe

Participe

Figure 6.2 – Meta-modele d’etude d’impact, modele du graphe de representation desdependances.

6.3.4 Specialisation du meta-modele - Niveau d’abstraction N2

En fonction du domaine represente (niveau N0 ) et de l’usage souhaite, differents

formalismes pour la representation des connaissances (niveau N1 ) peuvent etre employes.

Le meta-modele (niveau N3 ) definit une structure generique commune aux differents mo-

deles de representation de connaissances. Une instance de ce meta-modele sera alors utilisee

pour la modelisation de la representation ou formulation des connaissances.

Une representation specialisee des connaissances est le graphe canonique des de-

pendances (niveau N1 ). Celui-ci est definit par un modele de graphe definit par la meme

structure generique de niveau N2, le modele generique.

Afin de decrire plus precisement le domaine, une typologie des elements et une

typologie des relations seront definies. Les instances des meta-classes ElementImpactable

et RelationElementaire peuvent ainsi etre specialisees a leur tour en plusieurs types d’ele-

ments et de relations.

Par exemple, dans le domaine de la modelisation documentaire, les elements im-

pactables pourraient etre : le chapitre, la section, le paragraphe et les relations elementaires

(e.g. la composition, l’encapsulation, le referencement).

Les typologies precises d’elements et de relations correspondantes aux domaines

documentaire et logiciel seront definies dans les sections suivantes.

La meme structure est utilisee pour definir tous les modeles de graphe de depen-

dance associes aux differentes representations.

Definition 6.3.11. Type d’element – Pour un domaine D on notera Telem l’ensemble des

types d’elements constituant le domaine. Cet ensemble est decrit lors de la definition du

110

6.3. Modele d’etude d’impact - Niveau d’abstraction N3

modele de graphe de dependances associe au domaine.

Definition 6.3.12. Type de dependance – Pour un domaine D on notera Tdep l’ensemble

des types de dependances entre ses elements. Chaque type de dependance est caracterise

par un coefficient de propagation (voir definition 6.3.10). Cet ensemble est decrit lors de

la definition du modele de graphe de dependances associe au domaine.

Ce niveau N2 nous permet de disposer des elements necessaires pour determiner

le graphe de dependances associe (niveau N1 ), presente dans la section 6.2.2 de ce chapitre.

Les concepts du monde reel caracterises par leur type d’element deviennent des

nœuds de ce graphe. Et les relations qui les unissent, caracterisees par le type de depen-

dance, deviennent des arcs de ce graphe de dependance. Les informations sur le type de

nœud et le type d’arc seront utilisees lors des procedures de raisonnement dans l’evaluation

de la propagation de l’impact.

Les deux dernieres sections presentent quelques exemples de specialisation du

modele generique d’etude d’impacts pour deux formalismes differents et heterogenes :

d’une part, des representations UML du Systeme d’Information, composante logicielle

du patrimoine reglementaire et d’autre part les documents reglementaires, composante

documentaire de ce meme patrimoine.

Pour chaque representation nous nous livrons d’abord a une etude de son modele

definissant sa structure, afin d’y identifier la typologie d’elements elementaires et la ty-

pologie de relations elementaires. Pour la representation a l’aide des modeles UML, cette

etude sera realisee au niveau du meta-modele UML. Pour les documents et les collections

de documents, cet exercice est plus delicat car les documents ont des structures differentes.

6.3.5 Representation des dependances – Niveau d’abstraction N1

6.3.5.1 Introduction

Nous avons presente precedemment que les connaissances d’un domaine peuvent

etre formulees ou representees en utilisant differents formalismes ou langages de formu-

lation ou representation. Le choix du formalisme de representation des connaissances se

fait en fonction du besoin identifie. Pour une interpretation calculatoire nous avons besoin

d’une representation des connaissances avec un degre de formalisation tres eleve alors que

pour supporter la communication humaine, une formulation en langage naturel suffit.

Pour supporter des etudes d’impact nous nous interessons plutot aux liens que

les differentes particules de connaissances entretiennent entre elles. Nous souhaitons ainsi

identifier les dependances entre les differents objets.

« Devant un grand nombre de situations, une vieille habitude pousse l’homme

a tracer sur le papier des points representant des individus, des localites, des corps chi-

111

Chapitre 6. Cadre pour l’etude d’impact

miques, etc., joints entre eux par des lignes ou des fleches symbolisant une certaine rela-

tion. »[Wulf 58].

Ainsi pour mieux apprehender la complexite, nous optons pour une representation

sous forme de graphe. Pour un domaine D donne, l’analyse des particules de connaissances

et des relations elementaires permet d’elaborer un graphe representant les elements et les

relations qu’ils entretiennent.

Ce graphe sera une instance du modele definit au niveau superieur, niveau N2,

de l’architecture multi-niveaux presentee au paragraphe 6.2.

6.3.5.2 Graphe canonique des dependances

Le graphe canonique consolide les informations extraites du domaine et constitue

ainsi un support pour l’etude d’impact et le calcul des degres d’impact et des convictions

d’impact au sein du modele, suite a l’occurence d’un evenement impactant.

Definition 6.3.13. Ensemble des occurrences – Soit un domaine D, nous notons ED

l’ensemble des occurrences des elements impactables apparaissant dans D.

Definition 6.3.14. Graphe canonique – Nous appelons Graphe Canonique des depen-

dances un graphe GCD = (ED, R, I, ϕ) tel que :

– EDest l’ensemble des occurrences considere comme un ensemble de points (ou

sommets du graphe) ;

– R est une application R : ED → ED associant a chaque point de EDcomme ori-

gine, un sous-ensemble eventuellement vide de ED comme image. R represente

ainsi l’ensemble des fleches ou arcs de GCD ;

– I = [0..100] est sous ensemble de valeurs possibles pour la definition des carac-

teristiques des Elements impactables et des Relations elementaires ;

– ϕ est une application ϕ : ED × ED → [0 : 100] telle que ∀x, y ∈ ED :

– x¬Ry → ϕ (R(x, y)) = 0 ;

– xRy → ϕ (R(x, y)) = α ou α est le coefficient de propagation associe a la

relation entre x et y R(x,y) avec αin (0 : 100].

6.3.5.3 Modele generique du graphe canonique des dependances

La definition du graphe canonique des dependances nous permet de definir son

modele generique. L’instanciation des differents modeles definis au niveau N2 se traduit

par un graphe respectant le modele presente dans la figure 6.3.

[Wulf 58] Wulf William A., Shaw Mary, Hilfinger Paul N. et Flon Lawrence. Theorie des

graphes et ses applications. Dunod, 1958.

112

6.3. Modele d’etude d’impact - Niveau d’abstraction N3

-degréImpact -convictionImpact

Noeud

-coefficientPropagation

RelationElementaire

0..*

relation

noeudOrigine

1

relation 0..*

noeudCible

1

Figure 6.3 – Modele generique du graphe des dependances.

6.3.5.4 Chemin de propagation

Traduire les relations qu’entretiennent les elements de connaissance d’un domaine

dans un graphe canonique nous permet d’appliquer les notions et les principes lies a la

theorie des graphes (notamment des mecanismes de parcours de graphes). Chaque arc a

un sens donne par la relation elementaire entre les deux elements adjacents representes

par ses extremites, la propagation des impacts se fait en sens inverse de l’arc. Ainsi un arc

represente une dependance directe.

Definition 6.3.15. Chemin de propagation – Soit le graphe canonique GCD = (ED, R, I, ϕ) ,

on appelle chemin de propagation toute succession d’elements impactes suite a une mo-

dification du domaine, x0, x1, x2, x3, ....., xntelle que chaque couple (xi, xi+1) soit un arc

de R ,c’est-a-dire xiRxi+1. Alors par definition le coefficient de propagation de l’impact

α = ϕ (xi, xi+1) > 0.

6.3.5.5 Recherche de chemins dans un graphe

L’etude d’impact consiste a rechercher les chemins allant d’un sommet x donne a

tout autre sommet y : en partant d’un element impacte donne, represente par le sommet x,

nous construisons tous les chemins possibles vers tout autre sommet y accessible. Toutes

les dependances directes ou indirectes doit etre prise en compte.

Puisque le graphe est susceptible de contenir des boucles, afin d’eviter des chemins

de propagation infinis, l’algorithme de parcours de graphe verifiera a chaque etape si le

nœud a deja ete « visite » dans le chemin de propagation en cours.

6.3.5.6 Inference – Calcul des impacts

Une connaissance fait appel a d’autres connaissances pour raisonner, ou resoudre

un probleme ou en deduire des nouvelles connaissances. Les connaissances sont mises en

reseau et prennent sens les unes par rapport aux autres. Les concepts presentes ci-dessus

113

Chapitre 6. Cadre pour l’etude d’impact

definissent la statique de notre modele d’etude d’impacts. Au cours de cette section, nous

proposons une procedure de raisonnement en exploitant cette structure.

Les regles definies par les relations elementaires et les coefficients de propagation

seront utilisees pour manipuler les connaissances sur un ou plusieurs elements du reseau

(concernant le degre et de la conviction d’impact) et pour realiser une deduction logique

de nouvelles connaissances : l’impact subi par d’autres elements, le degre et la conviction

d’impact.

A la fin de notre procedure de raisonnement, a partir de l’information d’une

evolution d’une particule de connaissance, nous allons obtenir une mesure estimative de sa

portee sur l’ensemble des elements, c’est-a-dire l’ensemble des particules de connaissance

du domaine.

Definition 6.3.16. Etude d’impact – L’etude d’impact suite a la survenue d’un evene-

ment impactant, est le calcul du degre d’impact et de la conviction d’impact pour tous les

elements impactables du modele.

6.3.5.7 Degre elementaire et conviction elementaire de l’impact

Chaque element impactable, xi+1 ∈ ED, du chemin de propagation est caracterise

par le degre elementaire et la conviction elementaire de l’impact, calcules en fonction de

son predecesseur xi ∈ ED, dans le chemin de propagation.

Le degre d’impact elementaire de xi−1 sur xi, note degElem(xi,xi−1), se definit

comme :

degElem (xi, xi−1) =degElem (xi−1, xi−2)

|Exi|

ou :

– xi−2, xi−1, xi sont trois nœuds consecutifs appartenant au meme chemin de

propagation ;

– xi−1 est le predecesseur de xi dans ce chemin de propagation et xi−2 est le

predecesseur de xi−1 dans ce chemin de propagation ;

– Exiest le sous-ensemble contenant les elements de ED dont xi depend, c’est-

a-dire qu’il y a une relation elementaire entre ses elements et xi :

Exi= {∀y ∈ ED |yRxi }

– |Exi| represente la cardinalite de ce sous-ensemble.

Un element peut subir plusieurs impacts provenant des differents chemins de

propagation. L’importance d’un impact subit a partir d’un chemin de propagation est re-

lativisee en fonction de nombre de chemins auxquels participe le noeud (nombre d’elements

114

6.3. Modele d’etude d’impact - Niveau d’abstraction N3

avec lesquels il est en relation). Le degre d’impact est plus important quand l’element n’a

pas beaucoup de « predecesseurs ». De plus si le predecesseur xi−2 de xi−1 n’existe pas, cela

signifie que xi−1 est la source initiale de l’impact, donc convictionElem(xi−1,xi−2) = 100.

De la meme maniere la conviction d’impact elementaire de xi−1 sur xi note

convictionElem(xi,xi−1), se definit comme :

convictionElem (xi, xi−1) =convictionElem (xi−1, xi−2)

|Exi|

Ou :

– xi−2, xi−1, xi sont trois nœuds consecutifs appartenant au meme chemin de

propagation,

– xi−1 etant le predecesseur de xi dans ce chemin de propagation et xi−2 etant

le predecesseur de xi−1 dans ce chemin de propagation,

– Exiest le sous-ensemble contenant les elements de ED dont xi depend, c’est-a-

dire qu’il y a une relation elementaire entre ses elements et xi :

Exi= {∀y ∈ ED |yRxi }

– |Exi| represente la cardinalite de ce sous-ensemble.

6.3.5.8 Consolidation des impacts

Des que le modele contient de multiples elements lies deux a deux par des rela-

tions elementaires, la propagation des impacts devient complexe et induit la creation de

nombreux chemins de propagation. Un meme element peut etre ainsi membre de plusieurs

chemins de propagation et donc etre touche par divers impacts elementaires. Il devient

alors necessaire de consolider les impacts.

Definition 6.3.17. Degre consolide d’impact – Le degre consolide d’impact d’un element

xi appartenant a l’ensemble des elements du domaine ED, note degre(xi), represente, sur

une echelle de 0 a 100, la somme de ses degres d’impact elementaires subis dans les divers

chemins de propagation.

degre(xi) =

xi−1∈Exi

degreElem(xi, xi−1)

|ED|

Definition 6.3.18. Conviction consolidee d’impact – La conviction consolidee d’impact

d’un element xi appartenant a l’ensemble des elements du domaine ED, note conviction(xi),

represente, sur une echelle de 0 a 100, la somme de ses convictions d’impact elementaires.

conviction(xi) =

xi−1∈Exi

conviction(xi, xi−1)

|ED|

115

Chapitre 6. Cadre pour l’etude d’impact

6.3.6 Conclusion

Le cadre pour l’etude d’impact que nous avons presente dans la figure 6.1 se base

sur une architecture a quatre niveaux d’abstraction. Le cadre pour l’etude d’impact utilise

l’abstraction des modeles pour faciliter leur interaction et leur mise en relation.

Nous avons definit un meta-modele commun aux differents modeles de represen-

tation des connaissances en nous interessant en particulier a l’explicitation des elements

constituant le domaine (les particules de connaissances) et des relations de dependances

qu’ils entretiennent. En s’appuyant sur ces meta-modele communs nous avons defini le mo-

dele d’etude d’impact commun a plusieurs modeles de representation des connaissances.

Pour un domaine, une instance de ce modele d’impact est le graphe canonique de repre-

sentation des dependances.

Le chapitre suivant va detailler l’instanciation de ce meta-modele pour d’une part

les modeles UML du Systeme d’Information et d’autre part les modeles des ressources do-

cumentaires de l’Institution. Cette instanciation nous permet de retenir des deux modeles

les seuls concepts communs (definis par le meta-modele) et de les traduire ainsi dans la

meme representation : le graphe canonique des dependances. Ce dernier nous permet ainsi

de mettre en relation les deux composantes (documentaire et logicielle) et de realiser des

etudes d’impact.

116

Chapitre 7

Application du modele generique

d’etude d’impact

Sommaire

7.1 Modele d’etude d’impact associe aux modeles UML – ni-

veauN2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.1.1 Typologie des elements - Concept UML elementaire . . . . . 117

7.1.2 Typologie des relations elementaires dans les modeles UML 119

7.1.3 Modele de graphe specifique a UML . . . . . . . . . . . . . . 120

7.1.4 Graphe canonique des dependances et etude d’impact – N1 . 121

7.2 Modele d’etude d’impact associe aux documents – niveau

N2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

7.2.1 Typologie des elements - Concept documentaire elementaire 124

7.2.2 Typologie des relations elementaires documentaire . . . . . . 124

7.2.3 Graphe canonique des dependances – etude d’impact – N1 . 126

7.1 Modele d’etude d’impact associe aux modeles UML –

niveauN2

L’etude du meta-modele UML nous permet d’identifier les concepts presents dans

le langage UML, leurs proprietes et les relations qu’ils entretiennent.

7.1.1 Typologie des elements - Concept UML elementaire

Suite a l’analyse du meta-modele du langage UML, nous remarquons qu’un mo-

dele UML est compose de plusieurs elements de base tels que les classes, interfaces, types

de donnees, attributs, operations, tous heritant du meme concept ModelElement. Chaque

117

Chapitre 7. Application du modele generique d’etude d’impact

element de base dispose d’un certain nombre de proprietes : name, visibility, multiplicity,

largeScope, initialValue, concurency, kind, defaulValue, etc.

Definition 7.1.1. Concept UML – Nous appelons concept UML tout element present dans

le formalisme UML : les diagrammes, les classes, les attributs, les roles, les operations ainsi

que leurs proprietes telles que le nom, le type, la visibilite, etc.

Dans l’usage des concepts UML on remarque que parfois le meme aspect d’un

modele peut etre represente de manieres differentes avec des concepts UML differents.

L’exemple suivant presente le concept d’attribut et celui de role : d’une part, la figure 7.1a

montre une classe ClasseA avec un attribut de type ClasseB, et d’autre part, la figure 7.1b

montre une association entre deux classes, ClasseA et ClasseB, basee sur un role.

+uneMethode() : void

-unAttribut : ClasseB

ClasseA

+uneMethode() : void

ClasseA ClasseB -unAttribut

0..1

(a) (b)

Figure 7.1 – Relation entre les classes et leurs attributs.

Definition 7.1.2. Concept UML elementaire – L’ensemble de concepts elementaires CE

est un sous-ensemble de concepts UML, compose de telle maniere qu’aucune relation

d’equivalence semantique ne puisse etre definie entre deux de ses elements (c’est-a-dire

qu’il n’existe aucun moyen de representer la meme connaissance avec deux concepts ele-

mentaires differents).

La strategie de construction de cet ensemble de concepts elementaires consiste

a ne conserver, entre deux elements semantiquement equivalents, que l’element le plus

expressif. Par exemple : le concept d’attribut de la partie a de la figure 7.1 peut se rapporter

au concept de role, la partie b de la meme figure. Celui-ci est plus representatif puisqu’il

fait apparaıtre la notion de cardinalite (0..1, ou 1..1). C’est ainsi que le concept UML

d’attribut n’est pas considere comme un concept elementaire a l’inverse du concept UML

de role.

Ces definitions nous permettent de definir en extension l’ensemble EUML d’ins-

tances des concepts ElementsImpactables (voir la figure 6.2). Pour les etudes d’impact nous

nous limitons a cet ensemble de concepts du langage UML. D’autres elements peuvent y

etre ajoutes si le perimetre d’etude est elargi.

Definition 7.1.3. Elements impactables du formalisme UML – L’ensemble des elements

impactables du formalisme UML, pris en compte dans l’etude d’impact, est definit en

118

7.1. Modele d’etude d’impact associe aux modeles UML – niveauN2

extension :

EUML =

ElementClasse,

ElementInterface

ElementRole,

ElementOperation,

ElementParametre,

ElementDataType,

ElementPropriete

∀x ∈ EUML → x :: ElementImpactable

Chaque element impactable du formalisme UML est une instance de la meta-

classe ElementImpactable definie dans le meta-modele d’etude d’impact.

7.1.2 Typologie des relations elementaires dans les modeles UML

Suite a l’analyse du meta-modele du langage UML nous identifions les types de

relations presentes entre les elements d’un modele UML.

A partir du sous-ensemble UML manipule a travers les diagrammes de classe et

de sequence, nous identifions six types de relations elementaires induisant une forme de

dependance entre deux concepts UML elementaires x et y :

– association : association UML entre deux classes,

– generalisation : relation UML de generalisation/specialisation entre deux classes,

– implementation : relation UML d’implementation entre une classe et une de

ses interfaces fournissant une vue totale ou partielle d’un ensemble de services

offerts,

– agregation par valeur, par reference : relation UML de composition de deux

classes,

– dependance : relation UML de dependance entre deux classes,

– relation structurelle d’encapsulation : relation entre une classe et ses membres

(operations, roles, etc.) et entre un membre et ses proprietes (nom, visibilite,

cardinalite, etc.),

– relation d’acces a un membre : relation deduite des diagrammes de sequence

qui offrent une autre perspective sur le modele : une methode invoque une autre

methode, une methode utilise un role, etc.,

– relation de reference : un element du modele reference une cible externe du

modele : soit un autre element d’un autre modele, soit un document ou un

fragment d’un document. Cette relation est employee notamment pour la mise

en relation de la documentation de conception avec les modeles UML.

119

Chapitre 7. Application du modele generique d’etude d’impact

Remarque 7.1.1. Pour des raisons de concision, nous nous sommes limites a l’etude

des diagrammes de classe et de sequence, mais l’ensemble de concepts elementaires et de

relations elementaires peut etre elargi aux autres diagrammes du formalisme UML 1.4.2

(OMG, 2003).

Cette analyse nous permet de definir en extension l’ensemble RUML d’instances

de la meta-classe RelationElementaire.

Definition 7.1.4. Relation elementaire du formalisme UML – L’ensemble des types de

relation elementaires du formalisme UML, pris en compte dans l’etude d’impact, est definit

en extension :

RUML =

RelationAssociation,

RelationAgregationValeur

RelationAgregationReference,

RelationGeneralisation,

RelationImplemantation

RelationDependance,

RelationEncapsulation,

RelationUtilisation

RelationReference

∀y ∈ RUML → y :: RelationElementaire

Chaque relation elementaire presente entre les elements du formalisme UML est

une instance de la meta-classe RelationElementaire definie dans le meta-modele d’etude

d’impact. Pour les etudes d’impact nous nous limitons a cet ensemble de relations pre-

sentes entre les elements du langage UML. D’autres relations peuvent y etre ajoutees si le

perimetre d’etude est elargi.

Chaque instance de la relation entre les elements du formalisme UML est carac-

terisee par la propriete coefficientPropagation. La definition n’est pas munie d’une seman-

tique forte, elle depend d’un certain nombre de parametres etablis en fonction du contexte

du domaine, du systeme represente, des technologies employees, du type et de la signi-

fication associes a chaque relation (par exemple : une relation de composition aura un

coefficient de propagation different d’une relation d’association).

7.1.3 Modele de graphe specifique a UML

L’analyse du formalisme UML et les notions de concept UML elementaire et de

relation UML elementaire, definies ci-dessus, permettent d’elaborer un modele de graphe

de dependance en utilisant le meta-modele decrit dans le chapitre 6. L’instanciation de ce

modele permet d’obtenir un graphe servant de support pour des analyses des dependances

et des etudes d’impacts.

120

7.1. Modele d’etude d’impact associe aux modeles UML – niveauN2

L’instanciation du meta-modele du graphe de dependances pour des modeles

UML nous permet de definir un modele pour les graphes de dependances au sein des mo-

deles UML du Systeme d’Information. Les concepts UML elementaires sont des instances

du concept ElementImpactable du meta-modele d’analyse des dependances. Les relations

UML elementaires sont, quant a elles, des instances du concept RelationElementaire du

meta-modele.

ElémentClasse

ElémentAttribut

ElémentOpération

ElémentParamétre ElémentDataType ElémentPropriété

-degréImpact -convictionImpact

ElémentUML::ElémentImpactable

-coefficientPropagation

RelationUML::RélationElémentaire

RelationAssociation

RelationAgrégation

RelationGénéralisation

RelationDépendance

RelationEncapsulation RelationUtilisation

ElémentRôle

noeudOrigine

1 noeudCible

1 relation

relation

*

*

Figure 7.2 – Modele du graphe d’analyse des dependances et etude d’impact specifiquea l’UML.

7.1.4 Graphe canonique des dependances et etude d’impact – N1

En utilisant les concepts du meta-modele definis au niveau N3 un modele UML

peut ainsi etre traduit dans un graphe de dependances. Les concepts du monde reel repre-

sentes par des elements UML deviennent des nœuds de ce graphe, et les relations qui les

unissent deviennent des arcs de ce graphe de dependances.

En consequence nous pouvons appliquer les procedures de raisonnement associees

au graphe canonique des dependances.

7.1.4.1 Instanciation du graphe canonique

Le type d’element definit les proprietes du nœud du graphe, le type de relation

celles des arcs a utiliser lors des l’etude d’impact.

Pour les modeles UML, nous ne ferons pas de distinction entre les differents types

d’elements et, par consequent, entre les differents nœuds du graphe d’etude d’impact. En

revanche, le type de relation UML sera utilise pour definir les coefficients de propagation

associes a chaque arc du graphe d’etude d’impact.

121

Chapitre 7. Application du modele generique d’etude d’impact

Ce coefficient depend d’un certain nombre de parametres etablis en fonction du

contexte du domaine, du systeme represente, des technologies employees, du type et de la

signification associes a chaque relation (e.g. une relation de composition aura un coefficient

de propagation different d’une relation d’association). Dans la pratique, pour un modele

d’application precis et un domaine specifique, ces parametres peuvent etre ajustes et affines

apres des experimentations afin de s’approcher au mieux de l’impact reel.

7.1.4.2 Exemple d’instanciation

Nous partons d’un exemple UML simple mais representatif pour illustrer notre

proposition (figure 7.3).

Personne Enfant

-asc 2..2 -desc *

Figure 7.3 – Exemple d’un extrait d’un diagramme UML de classe.

Nous en deduisons le graphe canonique associe presente dans la figure 7.1.4.2.

Nous observons que tous les elements UML qu’ils soient une classe, un attribut et une

propriete de l’attribut (e.g. nom, type, etc.) sont representes au meme niveau sur le meme

graphe. Differentes relations sont presentes entre ces elements. Tous ces elements sont en

effet des concepts UML elementaires unis par des relations elementaires. Pour faciliter

la comprehension de la presentation, dans la figure 7.4 nous avons associe des elements

graphiques differents pour chaque type d’element ou de relation represente.

Dans l’exemple de la figure 7.1.4.2, l’occurrence Personne du concept elementaire

Classe est une generalisation de l’occurrence Enfant du meme concept elementaire ce qui

induit que la relation elementaire : R(Enfant, Personne) = α ou α est le coefficient de

propagation associe a la relation de generalisation (un impact de la classe parent risque de

se propager a la classe fils). Par contre, R(Personne, Enfant) = 0 puisqu’une modification

de la classe fils n’affecte pas le parent (la relation elementaire de generalisation n’est pas

symetrique).

La traduction de ce modele UML dans le graphe de dependances est presente

dans la figure 7.1.4.2.

Ainsi en analysant notre graphe nous observons qu’en partant d’un noeud (par

exemple la propriete Name de l’attribut Nom) nous pouvons suivre les differentes relations

de dependances (en suivant les fleches a l’inverse) pour atteindre tous les autres noeuds

du graphe susceptibles d’etre impacte. Ainsi modifier la propriete Name de l’attribut Nom

aura d’abord un impact direct sur l’attribut Nom. Un impact sur l’attribut Nom aura

122

7.2. Modele d’etude d’impact associe aux documents – niveau N2

Figure 7.4 – Exemple d’instanciation du graphe canonique des dependances associe audiagramme precedent.

un impact sur la classe Personne et sur la methode eppelerNom, qui a leur tour vont

propager cet impact vers les autres noeuds dependant. C’est ainsi que la classe Enfant

sera impactee deux fois : par les modifications de la classe Personne dont elle herite et par

les modifications de sa methode eppelerNom.

7.2 Modele d’etude d’impact associe aux documents – ni-

veau N2

Nous avons presente en details, dans la partie Etat de l’art, la definition 3.2.1

d’une structure documentaire.

Nous rappellerons que la notion de structure proposee par cette definition est

caracterisee par un haut degre d’abstraction et de genericite. Cette structure a ete elaboree

de maniere a etre independante du type de media considere, du type de corpus vise, des

usages specifiques.

Pour les documents textuels, cette structure generique se retrouve dans d’autres

modeles qui se sont imposes de facto comme standards.

Par exemple, les schemas XML[W3C 01b], Schematron [ISO 06] , DSD[Klarlund 02],

presentes dans la partie Etat de l’art, proposent une structuration des documents XML

(W3C) qui sont largement utilises dans les Systemes d’Information. Pour mieux decrire la

[W3C 01b] Voir reference [W3C 01b] definie page 65.

[ISO 06] Voir reference [ISO 06] definie page 66.

[Klarlund 02] Voir reference [Klarlund 02] definie page 66.

123

Chapitre 7. Application du modele generique d’etude d’impact

structure et le contenu des documents XML ces langages de schema proposent une serie

de concepts, d’elements documentaires.

On peut donc considerer le document comme une composition de concepts ele-

mentaires, la plus petite structure indivisible du document.

L’analyse de la recommandation des schemas XSD nous permet de definir :

– la typologie d’elements presents dans un document

– la typologie des relations que les elements documentaires entretiennent

7.2.1 Typologie des elements - Concept documentaire elementaire

L’analyse du schema des documents presentes dans la partie Etat de l’art nous

permet de definir, pour les documents textuels, les concepts generiques presents au niveau

du meta-modele de documents ou modele des schemas de documents et ensuite de definir en

extension l’ensemble d’instances d’elements ElementsImpactables (EDoc). Pour les etudes

d’impact nous nous limitons a cet ensemble de concepts de modelisation documentaire.

D’autres concepts peuvent y etre ajoutes si le perimetre d’etude est elargi.

Definition 7.2.1. Concept documentaire elementaire – Nous appelons concept documen-

taire elementaire tout element faisant partie d’une structure de document (e.g. les elements,

les attributs, les annotations, les proprietes des elements).

EDoc =

ElementDocumentaire

ElementAttribute

ElementContenu

ElementPropriete

∀x ∈ EDoc → x :: ElementImpactable du meta-modele

7.2.2 Typologie des relations elementaires documentaire

L’analyse du schema des documents presentes dans la partie Etat de l’art, pour

les documents textuels, nous permet de definir les types de relations presentes entre les

elements constituant des documents textuels.

Deux grandes categories de relations elementaires peuvent etre identifiees indui-

sant une forme de dependance entre deux concepts documentaires : relations logiques et

relations semantiques.

Les relations logiques sont des relations liees a la structure documentaire :

– Relations d’encapsulation : relation entre un element documentaire et ses pro-

prietes (e.g. nom, type, commentaire) ;

124

7.2. Modele d’etude d’impact associe aux documents – niveau N2

– Relations de reference : un element documentaire (document ou fragment de

document) peut faire reference a un autre element documentaire ;

– Relations de composition : un element documentaire est compose d’autres ele-

ments documentaires (e.g. une section d’un document est composee de plusieurs

fragments).

Les relations semantiques sont des relations liees a l’expression des connaissances

dans les documents :

– Relations d’implementation des exigences : relation qui permet de tracer l’ori-

gine de la mise en place d’un element documentaire. Dans le domaine des textes

juridiques, pour modifier un texte existant, il est imperatif de promulguer un

nouveau texte. Ainsi, on garde le lien d’implementation des exigences ce qui

nous permet de retrouver le texte demandant la creation ou la mise a jour.

– Relations de partage d’information : un texte peut clarifier le contenu d’un

autre texte (specificite egalement presente dans le domaine juridique). Donc,

deux elements documentaires expriment differemment la meme connaissance

[Chabbat 97].

Cette analyse nous permet de definir en extension l’ensemble d’instances d’ele-

ments RelationElementaire (RDoc). Pour les etudes d’impact nous nous limitons a cet

ensemble de types de relations entre les elements de modelisation documentaire. D’autres

types de relation peuvent y etre ajoutes si le perimetre d’etude est elargi.

Definition 7.2.2. Relation elementaire documentaire – Nous definissons ainsi l’ensemble

de relations elementaires documentaires

RDoc =

RelationEncapsulation,

RelationReference,

RelationComposition,

RelationExigences,

RelationPartageInfo

∀y ∈ RDoc → y :: RelationElementaire

Chaque relation elementaire presente entre les elements documentaires est une

instance de la meta-classe RelationElementaire definie dans le meta-modele d’etude d’im-

pact.

Chaque instance de la meta-classe RelationElementaire (voir figure 6.2) est ca-

racterisee par la propriete coefficientPropagation. La definition n’est pas munie d’une se-

mantique forte ; elle depend d’un certain nombre de parametres etablis en fonction du

contexte du domaine, du type de document, du type de contenu et de la signification as-

[Chabbat 97] Voir reference [Chabbat 97] definie page 2.

125

Chapitre 7. Application du modele generique d’etude d’impact

socies a chaque relation (par exemple : une relation de composition aura un coefficient de

propagation different d’une relation de reference).

7.2.2.1 Modele de graphe specifique aux documents

L’analyse du modele generique des documents et les elements decrits ci-dessous

nous permettent de realiser le modele de graphe d’analyse des dependances et etude d’im-

pact specifique a un ensemble de documents.

L’instanciation de ce modele, definit a l’aide du meta-modele du niveau N3, nous

permet d’obtenir un graphe servant de support pour des analyses des dependances et des

etudes d’impact dans un ensemble de documents.

ElémentDocumentaire

ElémenetAttribut

ElémentContenu

ElémenetPropriété

-degréImpact -convictionImpact

ElémentDoc::ElémentImpactable

-coefficientPropagation

RelationDoc::RelationElémentaire

-élémentOrigine

*

*

*

-élémentCible *

RelationEncapsulation

RelationRéférence

RelationComposition

RelationExigences

RelationPartageInfo

Figure 7.5 – Modele de graphe d’analyse des dependances et d’etude d’impact specifiqueaux documents

7.2.3 Graphe canonique des dependances – etude d’impact – N1

En utilisant les concepts du meta-modele definis au niveau N3 un document peut

ainsi etre traduit dans un graphe de dependances. Les concepts du monde reel representes

par des elements constituant le document deviennent des nœuds de ce graphe, et les

relations qui les unissent deviennent des arcs de ce graphe de dependance.

Ainsi nous pouvons appliquer les procedures de raisonnement associees au graphe

canonique des dependances.

7.2.3.1 Instanciation du graphe canonique

De la meme maniere que pour les modeles UML, le type d’element definit les pro-

prietes du nœud du graphe et le type de relation celles de l’arc associe. Cette instanciation

est utilisee lors des procedures d’etude d’impact.

126

7.2. Modele d’etude d’impact associe aux documents – niveau N2

Pour les etudes au sein de collections documentaires nous ne ferons pas de distinc-

tion entre les differents types d’elements ainsi il n’y a pas de difference entre les nœuds du

graphe d’etude d’impact. Nous utiliseront les types de relation elementaire presente entre

les concepts documentaires pour definir les coefficients de propagation associes a chaque

arc du graphe d’etude d’impact.

Ce coefficient depend d’un certain nombre de parametres etablis en fonction du

contexte du domaine, du type de document et du type de contenu et de la signification

associes a chaque relation (par exemple : une relation de composition aura un coefficient

de propagation different d’une relation d’association). Dans la pratique, pour un modele

documentaire precis, un domaine specifique et des regles de redaction bien etablies, ces

parametres peuvent etre ajustes et affines apres des experimentations afin de mieux s’ap-

procher de la realite.

127

Chapitre 7. Application du modele generique d’etude d’impact

128

Chapitre 8

Integration du Modele generique

d’etude d’impact dans le

Referentiel de production et de

gestion des connaissances de la

Cnaf

Sommaire

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

8.2 Extension du Referentiel SIDoc a la gestion des modeles

UML du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.2.2 Gestion des modeles UML du SI . . . . . . . . . . . . . . . . 132

8.2.3 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8.2.4 Utilisation des fonctionnalites du referentiel . . . . . . . . . 139

8.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.3 Integration du modele d’analyse des dependances et d’etude

d’impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.2 Representation des dependances – graphe d’analyse des de-

pendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.3.3 Algorithme de parcours de graphe . . . . . . . . . . . . . . . 147

8.3.4 Integration dans la couche service . . . . . . . . . . . . . . . 148

8.3.5 Integration dans la couche presentation . . . . . . . . . . . . 149

8.3.6 Bilan de l’integration des modeles UML dans le referentiel

SIDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

129

Chapitre 8. Integration du Modele d’etude d’impact

8.1 Introduction

Nous avons presente dans la partie Problematique les enjeux auxquels un Systeme

d’Information doit repondre afin d’assurer la maıtrise du patrimoine reglementaire.

L’evolution legislative ne se cantonne pas aux seules connaissances presentes dans

les documents reglementaires, elles ont le plus souvent un impact direct sur le Systeme

d’Information, outil d’application du droit. Il devient necessaire d’avoir une maıtrise glo-

bale des ressources documentaires et du Systeme d’Information pour accroıtre la capacite

de la DSI 17 a reagir aux changements de legislation et ainsi assurer la coherence tout au

long du processus d’application du droit.

C’est ainsi que le systeme de gestion et de production des connaissances doit gerer

l’ensemble de ces ressources heterogenes.

La section 2.3 de la partie Problematique presente le Referentiel de production et

de gestion des connaissances SIDoc. Ce referentiel est dote d’un ensemble de fonctionnalites

pour la gestion et la production des documents textuels. Les fonctionnalites offertes par

le referentiel SIDoc permettent d’assurer une maıtrise de la composante documentaire :

gestion des revisions et de versions, gestion des cycles de vie, recherche d’information,

tracabilite de l’information, etc.

Pour repondre a cette problematique nous apporterons deux contributions : etendre

les services de gestion offerts par le referentiel SIDoc a la composante logicielle et enri-

chir ces services avec des fonctionnalites permettant d’assurer la maıtrise commune de ses

ressources.

D’abord, nous souhaitons etendre les services de gestion offerts par le referentiel

SIDoc a la composante logicielle de maniere similaire aux services qu’il offre pour la com-

posante documentaire. La maıtrise de la composante logicielle passe par la maıtrise des

ressources de conception : documents d’analyse, documents de specifications, modeles de

conception, etc. Si les premieres categories de ressources s’apparentent a des documents

textuels et sont donc integrees naturellement dans les services de gestion SIDoc, c’est

moins le cas des modeles UML.

Nous allons nous interesser plus precisement dans ce chapitre a la maniere dont

nous integrons les modeles UML dans l’infrastructure de gestion et de production des

connaissances de l’Institution.

L’integration des modeles du Systeme d’Information nous permet egalement d’etendre

le perimetre couvert par le referentiel et d’offrir ainsi le cadre necessaire pour une mise en

relation des ces ressources heterogenes.

17. DSI : Direction du Systeme d’Information

130

8.2. Extension du Referentiel SIDoc a la gestion des modeles UML du SI

Ensuite, nous souhaitons enrichir les services de gestion du referentiel avec des

fonctionnalites permettant d’assurer la maıtrise commune de ses ressources face aux diffe-

rentes evolutions.

Notre contribution, presentee dans ce chapitre, se situe donc sur deux volets :

– integrer les modeles UML du Systeme d’Information au referentiel de gestion

et de production des connaissances,

– mettre en place le modele d’analyse des dependances et d’etude d’impact ca-

pable d’identifier et d’evaluer les impacts.

Cette double contribution nous permettra d’offrir aux modeles UML l’acces aux

outils de gestion du referentiel SIDoc ainsi que l’integration dans l’architecture du re-

ferentiel SIDoc des principaux composants lies a l’analyse des dependances et a l’etude

d’impact.

Nous tenons a preciser que ce chapitre n’a pas pour vocation d’etablir une docu-

mentation de specification et conception ou une documentation utilisateur des nouveaux

services et composants du referentiel mais plutot de presenter un resume synthetique de

la demarche employee et des principales nouvelles fonctionnalites offertes aux utilisateurs.

Pour une description detaillee de l’implementation et de l’utilisation des evolutions pro-

posees ainsi que de l’ensemble du referentiel SIDoc, nous vous proposons de consulter la

documentation du projet [CNEDI 07a].

8.2 Extension du Referentiel SIDoc a la gestion des modeles

UML du SI

8.2.1 Introduction

L’ensemble des modeles UML represente un des livrables le plus important dans

le processus de conception du Systeme d’Information. Il permet de modeliser le systeme

d’une facon standard d’un point de vue informatique.

Les modeles UML representent ainsi une vue sur le systeme et ont, par conse-

quent, une vocation de reference. Par ailleurs, ils entretiennent des liens etroits avec des

documents d’expression de besoins, d’analyse et de conception. Enfin, ils n’introduisent

pas de redondance avec d’autres elements du referentiel. Les modeles UML font donc par-

tie des documents de reference et ont, par consequent, vocation a integrer le Referentiel

de gestion et de production des connaissances de l’Institution.

Nous presentons dans les paragraphes suivants les elements mis en place pour

mener a bien cette integration. Nous allons nous interesser a la representation des modeles

UML dans un format compatible avec l’infrastructure du referentiel, aux mecanismes de

[CNEDI 07a] Voir reference [CNEDI 07a] definie page 37.

131

Chapitre 8. Integration du Modele d’etude d’impact

mise en relation avec les autres composants du referentiel ainsi qu’aux evolutions apportees

a l’interface utilisateur pour une restitution conviviale, ergonomique adaptee aux besoins

de l’utilisateur.

8.2.2 Gestion des modeles UML du SI

8.2.2.1 Representation XML des modeles UML

Afin de pouvoir integrer les modeles UML du SI dans le referentiel SIDoc et

beneficier des fonctions proposees par celui-ci, nous avons besoin de representer ces modeles

UML dans un format comprehensible par l’infrastructure SIDoc. Cette representation nous

permettra une gestion avancee des connaissances representees au sein meme de ces modeles.

Nous avons decrit dans le paragraphe 2.3 l’infrastructure du referentiel SIDoc basee sur

une representation en langage XML de ces ressources . Par ailleurs, la norme XMI – XML

Metadata Interchange [OMG 07b] definit, en utilisant le langage XML, la serialisation

des objets MOF [OMG 05][OMG 06a] et donc, entre autres, des modeles UML. Nombreux

ateliers de genie logiciel et outils de modelisation disposent de fonctionnalites pour l’export

des modeles UML en utilisant une representation XMI.

Le contenu XMI ainsi cree est forme de deux grandes partie :

– un element <UML:Model> contenant la description des elements du modele,

des types de donnees et des associations. Cet element incarne ainsi toutes les

connaissances apportees par la modelisation UML du systeme.

– une serie d’elements <UML:Diagram> contenant la description des differentes dia-

grammes associes dans la modelisation, chacun representant une vue differente

sur le modele.

L’element <UML:Model> contient toutes les informations necessaires pour la gestion du mo-

dele et pour les etudes d’impact. Cependant, nous gardons egalement l’element <UML:Model>

qui offre les informations graphiques sur chaque diagramme, interessantes au moment de

la restitution a l’utilisateur.

La representation des modeles UML en utilisant la norme XMI genere une tra-

duction du modele UML dans le langage XML rendant ainsi possible son integration dans

le referentiel SIDoc.

8.2.2.2 Integration dans le referentiel SIDoc

La representation XMI d’un modele UML est une traduction dans un format XML

du contenu du modele. Pour beneficier des services de gestion SIDoc, il est necessaire de

[OMG 07b] Voir reference [OMG 07b] definie page 66.

[OMG 05] Voir reference [OMG 05] definie page 66.

[OMG 06a] Voir reference [OMG 06a] definie page 67.

132

8.2. Extension du Referentiel SIDoc a la gestion des modeles UML du SI

doter ce contenu de « l’enveloppe SIDoc » standard representant la structure des objets

du referentiel (la structure des objets SIDoc est decrite dans le paragraphe 2.3.3.2). Ce

procede, que nous appelons « SIDoc-wrapping », se traduit par la creation d’un nouveau

type d’objet SIDoc : object-model. Le systeme associe ainsi au contenu XMI, l’ensemble

des metadonnees necessaires a l’identification, a la gestion de revisions et versions, du cycle

de vie, de l’historique, etc.

La figure 8.1 presente le schema XSD de la representation XML d’une ressource

de type model-object.

Légende

Séquence d’éléments XML

Elément complexe - contient des nœud enfant

Elément texte (type xs:string)

Elément optionnel

Elément obligatoire

Figure 8.1 – Schema de la representation XML d’une ressource de type modele UML.

Nous observons (sur fond jaune a l’ecran ; grise dans la version imprimee) les ele-

ments standards de « l’enveloppe » SIDoc, decrits dans la section 2.3, <meta>, <content>,

avec leurs sous-elements respectifs.

L’element <content> est specifique a chaque type d’objet. Pour les objets de type

object-model il contient, en plus de quelques elements d’information sur le modele (nom-

concepteur, package, commentaire), un nœud <xmi-description> et <external-links>.

133

Chapitre 8. Integration du Modele d’etude d’impact

Nous ne nous attarderons pas ici en detaillant la structure du nœud <xmi-

description> car celui-ci contient la description XMI du modele, exportee par l’outil

de modelisation. Cette description, respectant la norme OMG, a ete presentee dans la

partie Etat de l’art, paragraphe 3.5.

En revanche, la structure du nœud <external-links>, contenant la definition

des liens que les elements du modele entretiennent avec les autres ressources du referentiel,

sera detaillee dans la section suivante.

8.2.2.3 Representation des liens

L’integration des modeles UML dans le referentiel nous permet de mettre en

relation (en positionnant des liens) les elements du modele UML et les autres ressources

du referentiel (par exemple : documents ou fragments de documents).

Ne voulant pas denaturer la representation normalisee XMI des modeles UML

avec des elements specifiques a notre infrastructure, les definitions des liens seront sau-

vegardees dans un element specifique <external-links>. Ce mecanisme nous permet de

preserver dans l’element <xmi-description>, un contenu XML normalise qui peut etre

exporte et reutilise par les outils de modelisation.

La figure 8.2 realise un zoom sur la figure precedente, montre le schema XSD de

l’objet model-object, et presente en detail la structure de l’element <external-links>.

L’element <external-links> est une sequence vide ou non-limitee d’elements

<link>. Chaque element <link> possede un attribut optionnel node-xmi renseigne avec

la valeur de l’identifiant du nœud XMI, l’attribut xmi.id, correspondant a l’element du

modele porteur du lien. Cet element du modele porteur du lien est defini dans le corps de

la description XMI du modele, element <xmi-description> presente precedemment. Si

l’attribut node-xmi n’est pas present, cela signifie que le modele entier est le porteur du

lien.

L’element <link> contient un et seulement un nœud <ref>, element standard de

l’infrastructure SIDoc defini dans la section 2.3.3.5. Ainsi notre modele beneficie de tous

les mecanismes de resolution de liens proposes par l’infrastructure SIDoc.

L’exemple d’instance d’un element <external-links>, presente dans la figure

8.3, met en evidence trois instances differentes de liens :

1. un lien entre un element du modele (identifie par l’attribut node-xmi) et un autre

element d’un autre modele UML (modele identifie par l’attribut res et element

identifie par l’attribut nodes),

2. un lien entre un element du modele (identifie par l’attribut node-xmi) et un docu-

ment de type type=’donnee’ (document identifie par l’attribut res),

3. un lien entre le modele (attribut node-xmi absent) et un autre document de type

type=’parametre’ (document identifie par l’attribut res).

134

8.2. Extension du Referentiel SIDoc a la gestion des modeles UML du SI

Légende

Séquence d’éléments XML

Elément complexe - contient des nœud enfant

Elément texte (type xs:string)

Elément optionnel

Elément obligatoire

Figure 8.2 – Schema XSD de l’element <external-links> definisant les liens entre ele-ments du modele et elements du referentiel.

8.2.3 Presentation

Dans le cadre d’une exploitation courante, les outils de gestion sont caracterises

par une interface conviviale et ergonomique pour la communication homme/machine. Nous

presentons dans les deux sections suivantes, deux formes de presentation des modeles UML

au sein de l’interface utilisateur du referentiel SIDoc : une presentation sous forme de

formulaire et une presentation graphique sous forme de diagrammes.

Notons toutefois que l’infrastructure du referentiel SIDoc a ete concue dans un

souci d’evolutivite et de modularite permettant de facilement l’enrichir avec des nouveaux

composants aux differentes couches applicatives sans aucun impact sur l’existant du sys-

teme. Ainsi, des nouveaux modes de presentation pourront y etre integres.

135

Chapitre 8. Integration du Modele d’etude d’impact

<external-links>

<link node-xmi="63--112-2-71--32bad2ff:1134d518fcb:-8000:000000000000077C">

<ref col="uml-doc" kind="docobject" type="modele-uml" res="00000003"

nodes="I88ee03m104d161ab3bmm7f2b"/>

</link>

<link node-xmi ="63--112-2-71--32bad2ff:1134d518fcb:-8000:0000000000000781">

<ref col="sair" kind="docobject" type="donnee" res="00002703"/>

</link>

<link>

<ref col="sair" kind="docobject" type="parametre" res="00002801"/>

</link>

</external-links>

Figure 8.3 – Exemple de l’element XML <external-links>.

8.2.3.1 Presentation sous forme de formulaire

Nous avons montre dans le chapitre 2 que les ressources du referentiel SIDoc

disposaient de differentes formes de presentation. Compte tenu de la structuration des

objets en format XML, la presentation plus communement utilisee est celle definie a l’aide

des formulaires XForms [W3C 07a].

Le langage XForms nous permet de specifier l’interface utilisateur associe a un

modele de donnees. Les services de presentation de l’infrastructure SIDoc generent le

formulaire correspondant a partir d’une instance de donnees representant un modele UML

et en fonction de la definition de l’interface utilisateur en XForms. Ce formulaire est

disponible en deux etats : consultation et edition.

Le but de l’infrastructure SIDoc n’est pas l’edition des modeles UML, les outils

disponibles sur le marche offrent des fonctionnalites tres avancees dans ce sens. Cependant,

il s’avere utile de disposer d’une interface de mise a jour fournie a l’aide de l’etat en edition

du formulaire XForms.

La figure 8.4, presente une capture d’ecran d’une presentation sous forme de

formulaire d’un modele UML.

La presentation XForms nous permet d’avoir une integration homogene et har-

monieuse dans l’interface utilisateur globale du referentiel SIDoc.

8.2.3.2 Presentation sous forme de diagramme

Le modele UML est constitue des diagrammes, chacun representant une vue dif-

ferente sur le systeme. Les connaissances (e.g. elements, associations, types de donnees,

proprietes) definies dans chaque diagramme viennent enrichir le meme modele.

Bien que l’infrastructure SIDoc ait pour vocation de recenser les connaissances

faisant partie du referentiel, perspective dans laquelle une presentation sous forme de

[W3C 07a] World Wide Web Consortium. XForms 1.0 (Third Edition), October 2007. Disponible

sur : http ://www.w3.org/TR/xforms (consulte le 10.08.2009).

136

8.2. Extension du Referentiel SIDoc a la gestion des modeles UML du SI

Figure 8.4 – Formulaire en consultation presentant un modele UML.

137

Chapitre 8. Integration du Modele d’etude d’impact

formulaire suffit, il est egalement opportun de retrouver la presentation familiere d’un

modele UML sous forme d’un ou plusieurs diagrammes pour faciliter la communication

avec les utilisateurs.

Considerant la nature changeante du domaine et des ressources le representant,

y compris des modeles UML, une presentation dynamique s’imposait a la place des pre-

sentations sous forme des images issues des exports graphiques a partir des outils de

modelisation.

La recommandation SVG – Scalable Vector Graphics [W3C 03] specifie un lan-

gage XML de definition des dessins vectoriels. Les diagrammes UML sont facilement pre-

sentables sous forme d’un dessin vectoriel et la norme XMI leur fournit une definition en

XML.

Nous avons ainsi developpe et integre dans l’infrastructure SIDoc un processeur de

presentation (voir section 2.3.5.3) supportant le dessin vectoriel SVG des diagrammes defi-

nis dans les modeles UML. Pour cela, l’outil met en œuvre un ensemble de transformations

XSLT [W3C 99b] et XPath [W3C 99c] afin d’enrichir le document XMI et d’en obtenir

une presentation graphique : notation UML encodee en SVG. Ce procede est transparent

pour l’utilisateur qui aura acces aux diagrammes definis par un nœud <UML :Diagram> de

la representation XMI des modeles UML.

Les diagrammes peuvent ainsi etre visualises dans n’importe quel navigateur web.

La plupart des navigateurs internet [Mozilla 08][Microsoft 06][Microsoft 07] interpretent

soit nativement soit a l’aide d’un plugin, le contenu SVG de la page. Ils offrent des fonc-

tionnalites de agrandissement, de navigation et d’impression.

Le nouveau processeur de presentation nous permet d’offrir une vue sur le modele

UML sous forme de diagramme tel que presente par la copie d’ecran de la figure 8.5.

Cette presentation est similaire a celle offerte par les outils de modelisation. Ce-

pendant, quelques differences peuvent apparaıtre concernant notamment les elements gra-

phiques (e.g. icones, format des polices et des traits) employes par chaque outil pour les

elements d’un modele UML.

[W3C 03] World Wide Web Consortium. Scalable Vector Graphics (SVG) 1.0. Specification, January

2003. Disponible sur : http ://www.w3.org/TR/svg (consulte le 10.08.2009).

[W3C 99b] Voir reference [W3C 99b] definie page 61.

[W3C 99c] World Wide Web Consortium. XML Path Language (XPath), Version 1.0, W3C Recom-

mendation, 1999. Disponible sur : http ://www.w3.org/TR/xpath (consulte le 07.08.2009).

[Mozilla 08] Fondation Mozilla. Le projet Firefox de la fondation Mozilla, 2008. Disponible sur :

http ://www.mozilla-europe.org/fr/firefox/ (consulte le 07.08.2009).

[Microsoft 06] Microsoft Coorporation. Le navigateur Microsoft Internet Explorer, version 6, 2006.

Disponible sur : http ://www.microsoft.com/windows/ie/ie6/default.mspx (consulte le

07.08.2009).

[Microsoft 07] Microsoft Coorporation. Le navigateur Microsoft Internet Explorer, version 7, 2007.

Disponible sur : http ://www.microsoft.com/windows/internet-explorer/ie7/ (consulte le

07.08.2009).

138

8.2. Extension du Referentiel SIDoc a la gestion des modeles UML du SI

Cette presentation sous forme de diagramme, en utilisant un langage de dessin

vectoriel, ne dispose pas de fonctionnalites d’edition.

La presentation SVG nous permet de retrouver une visualisation des diagrammes

integree de maniere homogene dans l’interface utilisateur globale du referentiel SIDoc.

8.2.4 Utilisation des fonctionnalites du referentiel

Nous avons presente au cours des premieres sections de ce chapitre que l’integra-

tion des modeles UML dans le referentiel de production et de gestion des connaissances

vient enrichir le referentiel avec les connaissances issues des modeles UML et permet la

mise en relation des documents avec des modeles.

Nous avons montre dans la partie Etat de l’art que la plupart des outils de mo-

delisation offrent des fonctionnalites de modelisation tres riches et avancees. En revanche,

ils ne disposent pas toujours de fonctionnalites de referentiel :

– de gestion du cycle de vie,

– de management des revisions et des versions,

– de gestion de la tracabilite,

– d’analyse des dependances et de gestion de la coherence avec la documentation

associee.

Ainsi, ce travail ne vise pas a remplacer les outils de modelisation mais seulement a integrer

les modeles UML dans le referentiel des connaissances pour beneficier de ses fonctionnalites

de gestion. L’utilisation de la norme XMI assure une independance vis-a-vis de l’outil

de modelisation. Des fonctions d’import/export du referentiel manipulant la norme XMI

permettent de realiser l’interface entre les outils employes dans les phases de modelisation

et le referentiel SIDoc.

L’integration des modeles UML nous permet egalement de beneficier des fonc-

tionnalites de gestion offertes par l’infrastructure SIDoc.

8.2.4.1 Referentiel unique

Les modeles UML sont stockes dans un seul endroit accessible par tous, evitant

ainsi le risque de doublures et d’incoherences. Cette fonctionnalite regle egalement le pro-

bleme de la concurrence d’acces dans un environnement multi-utilisateurs.

8.2.4.2 Gestion du processus de production de connaissance

La responsabilite dans le processus de production et de gestion des modeles est

partagee entre plusieurs acteurs. Les fonctions de docflow 18 nous permettent de definir

l’automatisation du processus de production et les roles de chaque participant.

18. Par convention, nous appelons docflow un workflow de gestion documentaire

139

Chapitre 8. Integration du Modele d’etude d’impact

Figure 8.5 – Presentation a l’aide des images SVG des diagrammes UML.

140

8.2. Extension du Referentiel SIDoc a la gestion des modeles UML du SI

Les fonctions de docflow identifient et de gerent les etapes de validation des mo-

deles, envoient des messages aux autres objets et declenchent des actions pour automatiser

la gestion du referentiel.

La gestion des revisions et des versions multiples d’une meme ressource du referen-

tiel SIDoc appliquee aux modeles UML permet a tout moment de disposer d’une revision

en particulier et de l’associer, a travers les mecanismes de tracabilite, a l’expression des

exigences associees. Par ailleurs, la gestion des versions et les fonctions de synchronisa-

tion entre les differentes versions offre la possibilite de lancer en parallele des chantiers de

modelisation, portant sur les memes composants. Cette fonctionnalite offre la possibilite

d’anticiper les futures evolutions du Systeme d’Information et d’obtenir ainsi un gain de

temps pendant la phase de modelisation.

8.2.4.3 Tracabilite de l’information et des connaissances

La gestion des liens et de leur semantique nous permet de tracer (en suivant

les liens types) l’utilisation qui est faite d’une connaissance dans tout le referentiel. Les

meta-donnees sont utilisees pour retrouver les documents a l’origine de cette evolution.

Par ailleurs, l’historique de chaque ressource modele nous fournit les informations

necessaires pour tracer toutes les interventions effectuees et les acteurs qui sont intervenus.

8.2.4.4 Analyse des dependances, etude d’impact et estimations des charges

associees aux evolutions

L’integration des modeles UML dans le referentiel SIDoc en lien avec les docu-

ments de conception sert de base a l’instanciation d’un graphe d’analyse des dependances

et d’etude d’impact. La section suivante decrit plus en detail cette fonctionnalite.

8.2.5 Conclusion

Au cours de cette section nous avons presente l’integration des modeles UML au

referentiel SIDoc. Nous avons associe aux modeles UML une representation en utilisant un

langage et une structure homogene avec le reste du referentiel : « l’enveloppe SIDoc » et le

langage XML. Cette integration permet de definir des liens entre les elements du referentiel

et mettre ainsi en lien la composante documentaire avec celle logicielle. Cette nouvelle

structure est la base de notre modele d’etude d’impact decrit dans la section suivante.

141

Chapitre 8. Integration du Modele d’etude d’impact

8.3 Integration du modele d’analyse des dependances et

d’etude d’impact

8.3.1 Introduction

Nous allons presenter d’abord les principes d’instanciation du modele de graphe

des dependances pour les differents types de ressources du referentiel. Nous poursui-

vrons par la presentation de l’algorithme d’etude d’impact et son implementation dans

les couches persistance et service de l’application. Enfin, nous presenterons l’interface uti-

lisateur enrichie pour mettre en evidence les resultats de l’etude d’impact.

8.3.2 Representation des dependances – graphe d’analyse des depen-

dances

Nous identifions les references en analysant les objets presents dans la base.

La premiere etape est l’identification des elements impactables, structures de base

de chaque ressource. Les sections suivantes de ce chapitre montrent les mecanismes mis

en place pour chaque type de ressource. Pour les documents textuels, nous allons prendre

en compte des unites de base comme le document ou le fragment de document. Pour des

ressources telles que les modeles UML, ces unites seront plutot les concepts du formalisme

UML.

La deuxieme etape, l’identification des dependances est realisee en deux phases :

– l’analyse de la structure : pour identifier les dependances internes specifiques

a chaque ressource et celles liees a la construction des elements du referentiel

(e.g. un document est compose de plusieurs fragments, une classe possede des

operations) ;

– l’analyse des liens de reference : en suivant les elements <ref> qui representent

un lien entre des objets du referentiel, induisant une forme de dependance.

Puisque les dependances sont representees dans la base, l’analyse du referentiel

est realisee en utilisant une procedure implementee en langage XQuery – XML Query Lan-

guage [W3C 07b] et XPath – XML Path Language [W3C 99c] dans la couche persistance.

L’exploitation de cette structure nous permet de construire une representation du graphe

d’analyse des dependances.

[W3C 07b] World Wide Web Consortium. XML Query Language (XQuery), Version 1.0, W3C Re-

commendation, January 2007. Disponible sur : http ://www.w3.org/TR/xquery (consulte

le 07.08.2009).

[W3C 99c] Voir reference [W3C 99c] definie page 138.

142

8.3. Integration du modele d’analyse des dependances et d’etude d’impact

8.3.2.1 Instanciation pour les modeles UML

Le modele de graphe presente dans le chapitre 6 sera instancie pour chaque modele

UML en analysant ses elements.

La representation XMI contenue a l’interieur de l’objet SIDoc est analysee en

identifiant les nœuds correspondant aux types d’ElementImpactable definis par le meta-

modele (chapitre 6). Pour chaque element de l’ensemble EUML de concepts UML, le tableau

8.1 presente l’element de representation XMI correspondant.

Element Impactable Instance de representation

ElementClasse Element : <UML:Class>ElementRole Elements : <UML:AssociationEnd>, <UML:Attribute>ElementOperation Element : <UML:Operation>ElementParametre Element : <UML:Parameter>ElementDataType Element : <UML:DataType>ElementPropriete Par exemple pour un attribut : la visibilite, le nom, et l’ele-

ment <UML:Multiplicity>

Table 8.1 – Table de correspondance entre les concepts UML et les elements de represen-tation XMI

Nous appliquons la meme demarche pour l’identification des relations de depen-

dance entre les concepts UML elementaires. Pour chaque element de l’ensemble RUML de

relations definies pour les modeles UML, le tableau 8.2 presente l’element de representation

correspondant.

Relation elementaire Instance de representation

RelationAssociation Element : <UML:Association> avec l’attributaggregation=”none”

RelationGeneralisation Element : <UML:Generalization>RelationAgregationValeur Element : <UML:Association> avec l’attribut

aggregation= ”composite”RelationAgregationReference Element : <UML:Association> avec l’attribut

aggregation=”aggregate”RelationDependance Element : <UML:Dependency>RelationEncapsulation Hierarchie des nœuds et attributs dans XMIRelationUtilisation Element : <UML:Interaction> dans les diagrammes de se-

quenceRelationReference Elements <content>/<external-links> des objets SIDoc.

Table 8.2 – Table de correspondance entre les relations UML et les elements de represen-tation XMI

Pour les modeles UML nous ne ferons pas de distinction entre les differents types

143

Chapitre 8. Integration du Modele d’etude d’impact

d’elements et, par consequent, entre les differents nœuds du graphe d’etude d’impact. En

revanche, le type de relation UML sera utilise pour definir les coefficients de propagation

associes a chaque arc du graphe d’etude d’impact.

Parametrage des coefficients de propagation

Dans nos experimentations realisees sur un modele UML correspondant au mo-

dele de gestion des prestations familiales de la Cnaf, nous avons defini les coefficients de

propagation presentes dans le tableau 8.3.

Relation elem. Coeff. Relation elem. Coeff.

Association 100 Dependance 50Generalisation 75 Relation structurelle 100Agregation par valeur 100 Relation d’utilisation 100Agregation par reference 100

Table 8.3 – Table de parametrage des coefficients de propagation employes pour unmodele UML

Dans la pratique, pour un modele d’application precis et un domaine specifique,

ces parametres peuvent etre encore ajustes et affines apres des experimentations de plus

longue duree afin de mieux s’approcher de la realite.

8.3.2.2 Instanciation pour les documents

De la meme maniere que pour les modeles UML, l’analyse des ressources docu-

mentaires au regard des principes definis par le modele de graphe associe aux documents

(voir chapitre 6) definit les modalites d’instanciation du graphe d’analyse des dependances

associe aux documents.

Le schema XML decrit le modele des documents XML : il definit le vocabulaire

employe dans les documents XML permettant de decrire leur structure. En consequence le

vocabulaire definit par un schema XML ne peut etre mis en œuvre qu’en suivant des regles

rigoureuses d’agencement de ses elements. Pour un document XML precis, le schema XML

edicte ces regles en respectant la recommandation definie dans « XML Schema ».

L’enveloppe SIDoc presentee dans la section 2.3.3.2 definit les elements communs

a tous les documents XML du referentiel tels que l’element <meta>. Le contenu de l’ele-

ment <content> est, quant a lui, defini par une structure(vocabulaire et agencement des

elements) specifique a chaque type de document. Le referentiel dispose ainsi d’un ensemble

de schemas de documents XML et d’une application qui associe un document a un schema

donne.

L’element <content> encode les connaissances de la ressource du referentiel. Nous

nous y referons donc en vue de l’instanciation du graphe des dependances . Les nœuds

144

8.3. Integration du modele d’analyse des dependances et d’etude d’impact

encodant une connaissance du referentiel sont identifies par un attribut « id ».

Pour l’exemple specifique des nœuds contenant des extraits des textes legislatifs,

nous proposons le schema de la figure 8.6.

Légende

Séquence d’éléments XML

Elément complexe - contient des nœud enfant

Elément texte (type xs:string)

Elément optionnel

Elément obligatoire

Figure 8.6 – Schema d’une section de texte reglementaire.

Le but du schema presente dans la figure 8.6 est de definir le vocabulaire a

employer pour structurer une narration legislative afin de pouvoir identifier les parties

importantes du texte dans le cadre de l’analyse des dependances, tout en gardant une

maıtrise de sa structure et de sa mise en forme.

Ces elements sont les nœuds <section> et <bloc-element> munis d’un identi-

fiant. Ainsi les mecanismes de referencement du referentiel SIDoc pourront etre utilises.

L’element <section> correspond aux sections d’un document legislatif alors que l’element

<bloc-element> correspond a des elements de structure (e.g. le paragraphe, item d’une

liste a puces, cellule, ligne ou colonne d’un tableau). L’element <inline-element> permet

de disposer d’informations concernant la forme de la narration(la definition des styles) qui

importe dans le processus d’appropriation des connaissances.

De la meme maniere que pour les representations UML, la representation des don-

nees textuelles est analysee en identifiant les nœuds correspondant aux types d’ElementImpactable

145

Chapitre 8. Integration du Modele d’etude d’impact

definis pour les documents par le meta-modele d’etude d’impact (chapitre 6). Pour chaque

element de l’ensemble EDoc des elements documentaires, le tableau 8.4 presente l’element

de representation XML correspondant.

Element Impactable Instance de representation

ElementDocumentaire Toutes les elements du nœud <content>

(munis d’un attribut ’id’ ) : instances de xs:ElementExemple : <section> ou <block-element>

ElementContenu Le contenu texte d’un nœud XMLElementAttribut Les attributs des nœuds XMLElementPropriete Le nom des elements

Table 8.4 – Table de correspondance entre les objets documentaires et les elements derepresentation XML

Nous appliquons la meme demarche pour l’identification des relations de depen-

dance entre les elements documentaires. Pour chaque element de l’ensemble RDoc de re-

lations definies pour les documents, le tableau 8.5 presente l’element de representation

correspondant.

Relation elementaire Instance de representation

RelationEncapsulation Relation entre nœuds XML et ses attributsRelationComposition Relation de composition entre le document,

les sections, sous sections <section> etles blocs d’elements <block-element>

RelationReference Presence d’un element <ref> simpleRelationExigences Presence de l’element <ref> type dans les elements utilises

pour la tracabilite (par exemple : element <meta>/<origin>)RelationPartageInfo Presence de l’element <ref> avec le ref-type=’partage-info’

Table 8.5 – Table de correspondance entre les relations documentaires et les elements derepresentation XML

Comme pour les modeles UML, dans cette premiere version de l’analyse nous ne

ferons pas de distinction entre les differents types d’elements constituant les documents

et, par consequent, entre les differents nœuds du graphe d’etude d’impact. En revanche,

le type de relation entre les elements du document sera utilise pour definir les coefficients

de propagation associes a chaque arc du graphe d’etude d’impact.

Parametrage des coefficients de propagation

Dans nos experimentations realisees sur une collection documentaire representant

la documentation de conception du modele de gestion des prestations familiales de la Cnaf,

nous avons defini d’une maniere empirique les coefficients de propagation presentes dans

146

8.3. Integration du modele d’analyse des dependances et d’etude d’impact

le tableau 8.6.

Relation elem. Coeff. Relation elem. Coeff.

RelationEncapsulation 75 RelationExigences 100RelationComposition 100 RelationPartageInfo 100RelationReference 50

Table 8.6 – Table de parametrage des coefficients de propagation employes pour un corpus

Dans la pratique, pour un modele de document precis, pour un domaine specifique

et pour un style de redaction particulier, ces parametres peuvent etre ajustes et affines

apres des experimentations afin de mieux s’approcher de la realite.

8.3.2.3 Instanciation pour les objets binaires

Comme decrit dans le paragrape 2.2.2, les objets binaires representent une autre

categorie de ressources du referentiel SIDoc. Ils constituent des ressources diverses, ayant

une valeur pour le referentiel, telles que des ressources binaires, images, documents issus

des outils de bureautiques classiques, etc. Ils sont integres dans le referentiel a l’aide d’une

enveloppe SIDoc specifique et beneficient ainsi de tous les outils et principes de gestion

globale de celui-ci. Ils peuvent ainsi participer aux liens de reference qui se tissent au sein

du referentiel.

La gestion des objets binaires se fait d’une maniere globale, ainsi, aucune specia-

lisation du modele de graphe de dependances n’est prevue pour ce domaine. Leur instan-

ciation utilise le modele generique :

– nœuds du graphe : les objets binaires sont instancies dans le graphe d’analyse

des dependances en tant qu’instances du concept generique ElementImpactable,

– arcs du graphe : l’analyse des liens de reference entre les elements du referentiel

et les ressources binaires instancient les arcs du graphe avec un coefficient de

propagation fixe a 75% pour notre domaine.

8.3.3 Algorithme de parcours de graphe

Le graphe de dependances ainsi cree (regroupant les instances issues de l’analyse

des ressources UML, des ressources documentaires et des objet binaires) constitue la base

de l’etude d’impact. Cette section decrit l’algorithme d’etude d’impact et de calcul du

degre et de la conviction d’impact pour chaque element du referentiel.

Au niveau algorithmique, le graphe etant susceptible de contenir des cycles et

afin d’eviter des chemins de propagation infinis, nous verifions a chaque etape si le nœud

a ete deja visite dans le chemin de propagation en cours.

147

Chapitre 8. Integration du Modele d’etude d’impact

Algorithme general de propagation est presente dans la figure 8.7. La fonction

calculImpact permet de calculer de maniere recursive a partir d’un element impacte initial

unElement tous les degres et toutes les convictions d’impact (calcules a l’aide des fonctions

caculDegreImpact et calculConvictionImpact) de tous ses successeurs et d’en deduire tous

les chemins de propagation. En effet, lorsqu’un element a plusieurs successeurs, l’impact

va prendre plusieurs chemins de propagation (methode bifurquer(chemin)). Le parcours

du graphe produit ainsi une liste de chemins de propagation qui seront consolides par des

algorithmes de consolidation.

Pour des raisons de performance l’algorithme decrit dans cette section est imple-

mente en utilisant les langages XQuery et XPath et il est execute par le serveur de gestion

de la base de donnees.

Fonction calculImpact(unElement, unCheminPropagation)

Pour chaque p, successeur d’unElement

Si p n’a pas ete visite dans ce chemin alors

calculDegreImpact(p, unElement)

calculConvictionImpact(p, unElement)

ajouter p dans unCheminPropagation

calculImpact(p, unCheminPropagation)

si unElement a un autre successeur : p’ alors

//on cree un autre chemin de propagation

nouveauChemin=bifurquer(unCheminPropagation)

calculImpact(p’, nouveauChemin)

fin si

fin si

fin pour

fin fonction

Figure 8.7 – Algorithme general de propagation.

8.3.4 Integration dans la couche service

8.3.4.1 Appel du service

Le service d’analyse des dependances est implemente en tant que service web. A

partir d’une requete recue precisant le point de depart (identification du nœud de depart

et de l’impact subi), il demande a la couche d’acces aux donnees de creer, en analysant les

contenus du referentiel, les objets metier representant les ressources impactees.

Le flux XML entrant est une instance du schema presente dans la figure 8.8.

8.3.4.2 Resultat de l’analyse

Les resultats de l’analyse des dependances enrichis avec les resultats de l’etude

d’impact sont renvoyes comme reponse a l’invocation du service d’analyse des dependances

et d’etude d’impact.

148

8.3. Integration du modele d’analyse des dependances et d’etude d’impact

Légende

Séquence d’éléments XML

Elément complexe - contient des nœud enfant

Elément texte (type xs:string)

Elément optionnel

Elément obligatoire

Figure 8.8 – Schema du flux entrant du service d’analyse des dependances et d’etuded’impact, developpe pour le referentiel SIDoc .

Le flux XML sortant est une instance du schema presente dans la figure 8.9.

8.3.5 Integration dans la couche presentation

Les connaissances deduites de l’etude d’impact seront restituees a l’utilisateur

dans la couche presentation, de maniere harmonieuse avec la charte graphique de toute

l’application.

8.3.5.1 Le module d’etude d’impact

Le point d’acces a l’outil d’etude d’impact et d’analyse des dependances est le

Module d’analyse des dependances. L’interface utilisateur du module d’analyse des depen-

dances, presentee dans la figure 8.10, est constituee de quatre zones importantes : zone

de recherche, zone d’identification de l’origine, zone d’identification du fragment, zone de

resultats.

Zone de recherche – permet de rechercher la ressource qui subit l’impact d’origine et

de saisir un ensemble de criteres pour faciliter l’acces a cette ressource.

Zone d’identification de l’origine – identifie la ressource choisie comme origine de

l’impact.

Zone d’identification du fragment – offre la possibilite, a partir de la ressource choi-

sie, d’identifier de maniere plus precise l’origine de l’impact. Par exemple : une sec-

tion, paragraphe d’un document, un element d’un modele UML, etc.

149

Chapitre 8. Integration du Modele d’etude d’impact

Légende

Séquence d’éléments XML

Elément complexe - contient des nœud enfant

Elément texte (type xs:string)

Elément optionnel

Elément obligatoire

Figure 8.9 – Schema du flux sortant du service d’analyse des dependances et d’etuded’impact, developpe pour le referentiel SIDoc .

Zone de resultats – presente les resultats de l’impact sous forme d’un tableau. Celui-ci

presente les ressources du referentiel impactees (e.g. liste de documents, de modeles).

Pour avoir des details sur les sous-elements, des presentations des impacts objet par

objet sont proposees, comme celle pour les modeles UML (voir la section suivante).

8.3.5.2 Detail de la presentation des impacts sur les modeles UML

Certains types de ressources beneficient des representations specifiques. Nous

avons vu que dans le cas d’UML, le systeme permet une presentation XForms mais egale-

ment une presentation sous forme de diagramme UML.

Les resultats sont reportes sur les memes diagrammes UML fournis en entree grace

a un mecanisme d’annotation visuelle (e.g. jeu de couleurs, info-bulles) comme presente

dans la figure 8.11.

Nous souhaitons faciliter ainsi l’utilisation de l’outil et eviter l’appropriation d’un

nouveau formalisme de presentation tel que le graphe canonique.

150

8.3

.In

tegratio

ndu

mod

eled’a

nalyse

des

depen

dances

etd’etu

de

d’im

pact

Identification de la ressource origine de l’impact

Identification du fragment origine de l’impact

Résultat de l’étude d’impact

Zone de recherche

Fig

ure

8.10–

Le

module

d’an

alyse

des

dep

endan

ceset

presen

tationdes

resultats.151

Chapitre 8. Integration du Modele d’etude d’impact

8.3.6 Bilan de l’integration des modeles UML dans le referentiel SIDoc

Le referentiel de production et de gestion des connaissances gere d’ores et deja

une partie des documents a vocation de reference de l’Institution. Des nombreux chantiers

sont en perspective pour l’integration dans le referentiel d’autres ressources.

Notre contribution liee au travail de recherche s’inscrit directement au cœur de

ce projet institutionnel. Elle a ete initiee dans l’intention de repondre a deux principaux

enjeux :

– completer l’infrastructure du referentiel SIDoc par des mecanismes manquants

pour la rendre capable de repondre aux enjeux d’une maıtrise globale du pa-

trimoine reglementaire

– valider par l’experimentation les diverses propositions emises dans le cadre de

la presente these.

Nous avons presente au cours de cette section la maniere dont les modeles UML

d’une part et le modele d’etude d’impact d’autre part, ont ete integres au referentiel de

production et de gestion des connaissances SIDoc developpe au sein de la Branche famille

de la Securite Sociale.

Pour integrer les modeles UML, nous avons utilise des representations conformes

a la norme XMI et mis en place une structure XML respectant le modele du referentiel

qui enveloppe cette representation. Une telle integration a un double benefice :

– elle nous permet d’enrichir le referentiel avec les connaissances issues des mo-

deles UML et de realiser ainsi des references entre celles-ci et les autres elements

du referentiel,

– elle nous permet de beneficier, au niveau des modeles UML, de l’ensemble des

services de gestion qu’offre le referentiel SIDoc : gestion du travail collaboratif,

du cycle de vie, de revisions et versions, et de la tracabilite.

Nous avons egalement presente dans ce chapitre les principes d’instanciation du

graphe d’analyse des dependances, en presentant la maniere d’explorer des ressources

documentaires, des modeles UML et des ressources binaires. Nous avons egalement presente

l’implementation de l’etude d’impact ainsi que son integration dans la couche services

(section 8.3.4) et dans la couche presentation (section 8.3.5) de l’application.

152

8.3. Integration du modele d’analyse des dependances et d’etude d’impact

Figure 8.11 – Enrichissement de la presentation d’un diagramme UML avec les resultatsdes etudes d’impact.

153

Chapitre 8. Integration du Modele d’etude d’impact

154

Conclusion

La problematique des etudes d’impact est tres simple dans les cas minimalistes

mais elle peut s’averer tres difficile dans les cas plus compliques. Des lors que nous sommes

en presence de plusieurs elements lies par plusieurs relations, la propagation des im-

pacts devient complexe et surtout definie par des nombreux chemins de propagation. La

consolidation de ces resultats est tres difficile. Face a cette problematique le modele gene-

rique d’etude d’impacts devient necessaire pour automatiser cette etude et nous permettre

d’identifier l’ampleur de l’impact.

Par ailleurs, la notion de probabilite est tres importante et repond au manque de

semantique precise dans les modeles UML. Ainsi, une etude d’impact, realisee a l’aide de

notre modele, peut predire les nombreux impacts mais avec des probabilites tres differentes.

Le modele generique peut ensuite etre specialise avec des profiles specifiques a un

domaine et a l’aide des coefficients de propagation probabiliste associes a chaque type de

relation. Ces moyens de specialisation nous permettent de realiser une etude d’impact plus

proche de la realite.

Le meta-modele d’etude d’impact a ete concu de telle maniere qu’il puisse integrer

dans le graphe d’analyse des dependances des instances issues de futurs types de ressources.

Un modele de graphe specifique au niveau N2 nous permettra de definir les modalites

d’instanciation de ce graphe (e.g. typologie d’elements, typologie de relations).

Une premiere piste d’integration serait la prise en compte du code source pre-

sent dans des applications, code source qui lui-meme represente une autre vue sur les

connaissances du Systeme d’Information.

Par ailleurs, au niveau des documents reglementaire nous utilisons les liens po-

sitionnes au niveau des documents pour l’identification des dependances. Le systeme G-

Frames propose une representation des connaissances dotee de mecanismes d’inference.

Une integration des representations G-Frames nous permettra d’atteindre un niveau supe-

rieur dans la maıtrise des connaissances et du corpus reglementaire. L’annexe E presente

le systeme de G-Frames.

155

Conclusion

156

Quatrieme partie

Evaluation

157

Chapitre 9

Evaluation et discussions

Sommaire

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.2 Rappel des enjeux . . . . . . . . . . . . . . . . . . . . . . . . 159

9.3 Modele d’etude d’impact . . . . . . . . . . . . . . . . . . . . 161

9.3.1 Rappel de la problematique . . . . . . . . . . . . . . . . . . 161

9.3.2 Rappel de la proposition . . . . . . . . . . . . . . . . . . . . 161

9.3.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.3.4 L’experience de l’utilisateur . . . . . . . . . . . . . . . . . . 165

9.4 Integration dans le referentiel SIDoc . . . . . . . . . . . . . 166

9.4.1 Rappel de la problematique . . . . . . . . . . . . . . . . . . 166

9.4.2 Rappel de la proposition . . . . . . . . . . . . . . . . . . . . 166

9.4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

9.4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.1 Introduction

Cette derniere partie a pour but d’effectuer une synthese et une evaluation de

differentes propositions que nous avons faites au cours de cette these. Nous evaluons chaque

proposition au regard des besoins initialement exprimes dans la partie problematique de

ce manuscrit.

9.2 Rappel des enjeux

La meme connaissance legislative se retrouve exprimee au travers de nombreuses

ressources a des niveaux differents de l’entreprise : documents de reference, supports de

formation, documentation metier, regles de gestion, composants du Systeme d’Information,

159

Chapitre 9. Evaluation et discussions

etc. Toutes ces ressources (e.g. textes reglementaires, les objets du Systeme d’Information)

qui encodent la connaissance necessaire pour que l’Institution mene a bien sa mission

representent une vraie richesse pour l’organisation, un vrai patrimoine, que l’on a appele

patrimoine des connaissances metier.

Ce patrimoine des connaissances metier doit toujours etre conforme a la legisla-

tion. La nature changeante de la legislation rend la maintenance d’un tel dispositif parti-

culierement difficile.

La composante documentaire ainsi que la composante logicielle doivent suivre

rigoureusement les evolutions de la legislation. Ainsi, lorsqu’un changement intervient au

sein de la reglementation, il est imperatif que celui-ci leur soit repercute afin que ces deux

composantes restent conformes au droit.

Comme presente dans la partie Problematique, afin d’assurer cette coherence glo-

bale des connaissances exprimees dans l’ensemble des ressources heterogenes du patrimoine

reglementaire, nous avons propose d’apporter une reponse aux problematiques suivantes :

– la tracabilite des connaissances exprimee tant au niveau documentaire qu’au

niveau logiciel : la meme connaissance se retrouve encodee dans plusieurs res-

sources avec plusieurs niveaux de details pour plusieurs destinations,

– la maıtrise de la coherence de sa composante documentaire,

– la maıtrise de la coherence de sa composante logicielle (l’implementation cal-

culatoire de la reglementation),

– l’identification le lien qu’entretient le reste du Systeme d’Information avec le

patrimoine reglementaire.

Notre proposition s’est articulee en trois temps.

Tout d’abord, nous avons analyse les caracteristiques des deux composantes du

patrimoine des connaissances metier (composante documentaire et composante logicielle).

Bien qu’en apparence differentes et heterogenes, ces deux composantes ont des proprietes

equivalentes. Toutes les deux encodent les connaissances metier de l’entreprise. Par la suite

nous avons vu que ces deux composantes peuvent etre apprehendees comme des ensembles

de ressources structures, hierarchises et fortement interconnectes. Par ailleurs, ces deux

composantes doivent repondre a des problematiques de production et de gestion semblables

visant a capitaliser les connaissances metier qu’elles encodent.

C’est dans cet esprit que, dans un deuxieme temps, nous avons propose et mis

en place les mecanismes pour une gestion unifiee de la composante logicielle et de la

composante documentaire. Nous avons propose une structure specifique de representation

des modeles UML a l’aide du langage XML, en utilisant la norme XMI, nous permettant de

les integrer dans le referentiel SIDoc de production et gestion documentaire de l’Institution.

Enfin, dans un troisieme temps, nous avons propose un meta-modele d’etude

d’impact visant a fournir les concepts et les mecanismes necessaires pour les etudes d’im-

pact dans un ensemble de particules de connaissances. Ce meta-modele peut etre specialise

160

9.3. Modele d’etude d’impact

pour differents domaines. Deux specialisations de ce meta-modele ont ete decrites en de-

tail. L’une s’interesse au domaine documentaire et l’autre au domaine des modeles UML

des Systemes d’Information. Le meta-modele propose nous permet de nous affranchir des

specificites de chaque type de ressource pour realiser des analyses de dependances et des

etudes d’impact a travers des ensembles de ressources heterogenes.

Dans les sections suivantes de ce chapitre nous allons evaluer en detail ces pro-

positions.

9.3 Modele d’etude d’impact

9.3.1 Rappel de la problematique

Lorsqu’une modification intervient a un certain niveau de la pyramide reglemen-

taire, l’ensemble des ressources en aval peut etre impacte. L’impact a un niveau donne est

repercute en cascade affectant toute la pyramide jusqu’au niveau de base qui est represente

par les regles de gestion, internes a l’organisation impactant ainsi directement un certain

nombre de composants du Systeme d’Information lies a la reglementation. L’impact peut

ensuite etre propage a d’autres composants du SI induisant ainsi une reaction en chaıne

qu’il est necessaire de maıtriser.

Par exemple, un changement dans les conditions d’attribution d’une allocation

va avoir un impact sur l’ensemble de la composante documentaire, sur le systeme de

gestion des prestations mais aussi sur d’autres composants du SI comme l’application de

gestion des flux comptables, les outils de simulation et de tests ou bien le site internet de

l’Institution.

9.3.2 Rappel de la proposition

Documents legislatifs, documents de conception, documents de specification, di-

vers livrables du cycle de conception et de developpement, tous sont des ressources qui

encodent la connaissance metier autour du Systeme d’Information. La proposition d’un

meta-modele definissant pour chaque type de ressource un modele de representation des

elements elementaires encodant des connaissances metier et des relations que ces elements

elementaires entretiennent, nous permet d’apprehender de la meme maniere ces ressources,

bien qu’elles soient differentes et heterogenes.

Leur mise en relation nous permet de garantir la tracabilite de l’utilisation qui est

faite des connaissances a travers l’ensemble des ressources de l’organisation qu’elles soient

documentaires ou logicielles. En se basant sur la representation des dependances issues de

cette tracabilite, l’etude d’impact nous renseigne sur l’effet qu’une evolution d’un element

du referentiel (par exemple une connaissance legislative) aura sur l’ensemble du referentiel.

161

Chapitre 9. Evaluation et discussions

Nos travaux proposent un mecanisme generique pour l’etude d’impact au sein

d’un modele d’un Systeme d’Information nous permettant d’identifier l’ensemble des com-

posants impactes a partir d’une modification survenue. Notre contribution a permis d’eta-

blir un support essentiel et necessaire pour l’instauration d’un controle de la coherence et

de la conformite de la composante logicielle du patrimoine reglementaire.

C’est ainsi que, suite a une analyse de la structure des modeles UML, dans la

section 7.1 nous avons introduit la notion de concept UML elementaire et de relation UML

elementaire. Nous avons egalement propose les mecanismes d’instanciation du meta-modele

d’etude d’impact pour les modeles UML. Nous avons aussi detaille la maniere d’analyser

les modeles pour l’instanciation du graphe canonique des dependances associe. Le travail

equivalent a ete fait pour les collections documentaires, dans la section 7.2 en proposant les

notions de concept documentaire elementaire et relation documentaire elementaire. Nous

avons egalement propose les modalites d’instanciation du meta-modele d’etude d’impact

pour les documents reglementaires.

9.3.3 Evaluation

9.3.3.1 Demarche

L’etude d’impact est basee sur l’analyse des dependances dans les graphes ca-

noniques de dependances, instances du niveau N1 du modele d’etude d’impact. Chacune

de ces representations est une instance du niveau superieur N2. Nous avons presente les

modeles d’etude d’impact associes a UML, dans la section 7.1 et aux documents, dans

la section 7.2. La granularite la plus fine utilisee pour l’etude d’impact est celle prise en

compte dans les modeles d’etude d’impact N1.

9.3.3.2 Methode d’evaluation

En partant d’un element impacte nous utilisons notre implementation afin de

calculer, pour chaque element du referentiel SIDoc, son degre 19 et sa conviction d’im-

pact 20. Nous considerons un element comme impacte a partir du moment ou sa conviction

d’impact a une valeur superieure a zero.

Cette estimation a ete realisee en trois phases :

– une estimation sur l’ensemble documentaire seul : le Dossier d’analyse fonction-

nelle specifiant les exigences de l’application de gestion des prestations Cristal,

– une estimation sur un modele UML seul,

19. Le degre d’impact represente la couverture estimee de l’impact sur un element impactable. Voirla definition 6.3.8.

20. La conviction d’impact represente la precision avec laquelle nous pouvons affirmer la presenced’un impact elementaire. Voir la definition 6.3.9.

162

9.3. Modele d’etude d’impact

– une estimation sur un ensemble de documents de conception associes au modele

UML.

Pour mesurer les resultats de l’etude d’impact, nous utilisons la methode proposee

dans [Kagdi 07]. Il s’agit de comparer les evolutions realisees par l’utilisateur pour palier

un impact (les documents ou les modeles UML modifies) avec les resultats de l’etude

d’impact.

A chaque fois, les resultats estimes ont ete proposes aux utilisateurs en charge

de la maintenance des ressources, afin qu’ils soient confrontes a leur propre perception :

un groupe de redacteurs dans la premiere phase, les concepteurs et developpeurs dans les

deux dernieres pases.

9.3.3.3 Mesures d’evaluation

Deux mesures largement utilisees, issues du domaine de la Recherche d’Informa-

tion, le taux de precision et le taux de rappel, seront employees dans la mesure de l’efficacite

des mecanismes d’etude d’impact. En effet, notre etude d’impact peut etre apprehendee

comme une recherche d’information qui, a la place des mots-cles et de l’indexation, utilise

l’algorithme de calcul d’impacts presente dans cette these.

En partant d’un impact identifie nous definissons :

– l’ensemble Ei des impacts estimes par notre mecanisme d’etude d’impact. Nous

considerons un element impacte a partir du moment ou la confiance de l’impact

est superieure a un certain seuil ǫ positif,

– l’ensemble Ci des impacts reels, concretement identifies par une analyse ma-

nuelle des ressources.

– l’ensemble Pi des impacts pertinents, c’est a dire le nombre d’impacts identifies

par notre etude d’impact qui sont egalement des impacts reels. Il s’agit de

l’intersection des deux ensembles Ei et Ci.

Pour chaque evaluation, le taux de precision et le taux de rappel sont definis de

la maniere suivante :

Definition 9.3.1. Taux de precision – Rapport du nombre d’elements pertinents identifies

au nombre total d’elements trouves.

P =1

n

n∑

i=1

card(Pi)

card(Ei)=

1

n

n∑

i=1

card(Ei

Ci)

card(Ei)

Definition 9.3.2. Taux de rappel – Rapport du nombre de documents pertinents trouves

au nombre total de documents pertinents.

[Kagdi 07] Voir reference [Kagdi 07] definie page 84.

163

Chapitre 9. Evaluation et discussions

P =1

n

n∑

i=1

card(Pi)

card(Ci)=

1

n

n∑

i=1

card(Ei

Ci)

card(Ci)

D’une maniere plus intuitive nous pouvons considerer que le taux de precision

represente la pertinence du systeme et le taux de rappel represente sa couverture.

Dans certaines applications, le taux de rappel est beaucoup plus important que le

taux de precision. Par exemple, lorsqu’il s’agit de trouver les courriels qui ne sont pas des

pourriels, il est tres important de trouver tous les courriels qui ne sont pas des pourriels ;

il est cependant moins grave que certains pourriels survivent au filtrage.

Par ailleurs, le contraire peut etre egalement vrai : quand la precision est plus

importante que le taux de rappel. Supposons qu’on doive attribuer a des documents des

mots-cles pour faciliter la recherche. Si les mots cles ne sont pas suffisamment precis le bruit

est trop important et l’information utile risque d’etre noyee dans de nombreux resultats.

Par exemple, une recherche sur le mot-cle « avocat » peut trouver des reponses lies aussi

bien au domaine juridique qu’aux recettes de cuisine de la belle saison.

Nous pouvons jouer sur la valeur de la confiance d’impact pour faire varier les

taux de precision et les taux de rappel. En choisissant d’ignorer les impacts deceles avec

une confiance tres faible, nous prenons le risque de passer a cote d’impacts pertinents ; le

taux de precision est plus eleve au risque de voir diminuer celui de rappel. En revanche,

en acceptant tous les impacts deceles, y compris ceux dont la confiance est tres faible, le

taux de rappel est tres bon, le systeme est certain d’avoir identifie le maximum d’impacts

pertinents mais la precision diminue et l’utilisateur est confronte a une multitude d’impact

potentiels dont seule une partie est pertinente.

9.3.3.4 Resultats

Cette estimation a ete realisee en trois scenarios :

1. une estimation sur l’ensemble documentaire forme de plus de 7000 elements docu-

mentaires de conception du systeme de gestion des prestations Cristal 21

2. une estimation sur un modele UML contenant plus de 340 elements (e.g. classes,

attributs, methodes)

3. une estimation sur l’ensemble de documents de conception et des modeles UML

associes ; soit un total de 7340 elements.

Chaque scenario est repete plusieurs fois avec des evenements impactants diffe-

rents. Les resultats sont synthetises dans le tableau 9.1 disponible a la fin du chapitre.

Nous observons que, dans la composante documentaire, nous disposons de re-

lations dont la conviction d’impact est plus importante (relations de composition, de

21. Ces documents font partie du Dossier d’Analyse Fonctionnelle de Cristal

164

9.3. Modele d’etude d’impact

reutilisation ou meme d’interpretation), donc la precision est toujours tres importante.

Les impacts remontes sont pertinents mais le risque est d’en oublier certains : le taux de

rappel est diminue par rapport a la valeur maximale.

En revanche, au niveau des modeles UML, la presence de relations dont le coef-

ficient de propagation est plus petit (telles que la relation d’association, de generalisation

ou de dependance) fait que la precision est plus petite. Le systeme a tendance a remonter

beaucoup plus d’impact qu’en realite. Le taux de rappel est maximal car tous les ele-

ments du modele UML pertinents sont trouves meme si des resultats non-pertinents sont

egalement presentes.

Les resultats sur un ensemble combinant a la fois les modeles UML et les docu-

ments de specification sont largement influences par les caracteristiques de la composante

documentaire (une tres bonne valeur de la precision).

9.3.3.5 Observations

Cette experimentation s’est basee sur les coefficients de propagation, associes aux

differents types de relations entre les elements, definis dans le tableau 8.3 pour la compo-

sante logicielle et dans le tableau 8.6 pour la composante documentaire. L’experimentation

montre que ces coefficients sont importants dans l’evolution du taux de precision et de

rappel du modele decrit. Les valeurs de ces coefficients doivent etre affinees en fonction

d’une analyse plus approfondie des habitudes de modelisation documentaire et logicielle

correlee avec des experimentations enrichies et en utilisant des principes statistiques de

determination d’echantillons representatifs.

Ceci constitue une perspective a court terme de nos travaux de recherche.

Par ailleurs, la qualite des resultats de l’etude d’impact depend beaucoup des liens

de dependance positionnes par les utilisateurs dans les modeles documentaire et logiciel.

Ceux-ci seront ensuite traduits en tant que relations au sein du modele d’etude d’impact.

Ainsi, pour de meilleurs resultats, les utilisateurs doivent etre sensibilises a l’importance

d’expliciter le plus grand nombre de liens de dependances entre les elements du referentiel

des connaissances metier.

9.3.4 L’experience de l’utilisateur

Malgre la complexite de ces mesures, il n’est pas certain qu’elles refletent l’ef-

ficacite du systeme du point de vue de l’utilisateur. En fait, il a ete demontre que les

differentes tentatives faites pour apprecier l’experience de l’utilisateur avec des mesures

mathematiques echouent [Turpin 06]. Seule une mesure qualitative de l’experience des

[Turpin 06] Turpin Andrew et Scholer Falk. User performance versus precision measures for simple

search tasks. SIGIR ’06 : Proceedings of the 29th annual international ACM SIGIR

conference on Research and development in information retrieval. New York, NY, USA.

ACM, 2006, p 11–18.

165

Chapitre 9. Evaluation et discussions

utilisateurs peut etre revelatrice de l’appropriation de l’outil propose.

L’appropriation de l’outil par les utilisateurs a ete evaluee en meme temps que

l’integration dans le referentiel SIDoc et est presentee dans la section suivante.

9.4 Integration dans le referentiel SIDoc

9.4.1 Rappel de la problematique

Le referentiel de production et de gestion des connaissances gere d’ores et deja

une partie des documents de reference de l’Institution. De nombreux chantiers sont en

perspective pour l’integration d’autres ressources.

La maıtrise du Systeme d’Information est strategique pour les organisations ayant

comme mission la mise en application de la legislation. Le processus de conception et

de developpement est tres complexe et fortement collaboratif. Un des plus importants

projets d’integration dans le referentiel de production et de gestion des connaissances est

l’integration des ressources d’analyse et de conception du Systeme d’Information.

9.4.2 Rappel de la proposition

L’integration des modeles UML dans le referentiel SIDoc nous a permis de faire

beneficier les modeles UML des fonctionnalites de gestion et production offertes par le

referentiel SIDoc.

Par ailleurs, la structuration XML et la gestion des references specifiques au

referentiel SIDoc nous ont permis la mise en relation des elements des deux composantes

du patrimoine reglementaire et la maıtrise de la tracabilite entre eux.

9.4.3 Evaluation

L’efficacite d’une application de gestion est difficile a mesurer et a quantifier.

Nous devons nous fier au ressenti des utilisateurs.

Le ressenti des utilisateurs a ete analyse a l’aide des fiches d’evaluation lors de la

phase de recette fonctionnelle de l’application SIDoc. Nous reproduisons ici les conclusions

concernant le module d’analyse des dependances. Pour plus de details, veuillez consulter

les dossiers de recette technique et fonctionnelle du projet [CNEDI 07b][CNEDI 07c].

[CNEDI 07b] Centre National d’Etudes et du Developpement Informatique Rhone-Alpes, 128 rue ser-

vient, 69003 Lyon. SIDoc - Systeme d’Aide a l’Implementation de la Reglementation -

Recettage fonctionnel de la V0, 2007.

[CNEDI 07c] Centre National d’Etudes et du Developpement Informatique Rhone-Alpes, 128 rue ser-

vient, 69003 Lyon. SIDoc - Systeme d’Aide a l’Implementation de la Reglementation -

Recettage technique de la V0, 2007.

166

9.4. Integration dans le referentiel SIDoc

9.4.3.1 Retour sur l’experimentation avec les utilisateurs

Dans ce contexte nous avons souhaite proceder a une evaluation par l’experimen-

tation de cette contribution afin d’identifier et de valider :

– les difficultes d’appropriation du nouveau mode de gestion des ressources,

– l’interface utilisateur proposee,

– l’acuite des analyses des dependances et des etudes d’impact,

– l’importance et l’utilite de ces etudes dans le processus de maıtrise du patri-

moine des connaissances.

Constitution de l’equipe d’evaluation

Les avis ont ete recueillis aupres d’un groupe d’utilisateurs forme de personnes

ayant differents profils (developpeurs, concepteurs et responsables d’equipe). N’ayant pas

toujours la possibilite de definir des mesures quantifiables, leurs avis sont recueillis sous

forme de sondage.

Le groupe realisant la validation fonctionnelle est composee de 12 personnes avec

les profils suivants :

– responsable d’equipe de conception ou de developpement, responsable du suivi

et de la coordination (3 personnes)

– personne exercant une activite principale d’analyse fonctionnelle (2 personnes)

– personne exercant une activite principale de conception (4 personnes)

– personne exercant une activite principale de developpement (3 personnes)

Leurs appreciations, consolidees a la fin du chapitre dans le tableau 9.2, sont

detaillees dans les sections suivantes. Quelques extraits de la synthese des evaluation sont

presentes dans l’annexe D.

La validation des principes mis en œuvre par le referentiel SIDoc permet d’envi-

sager sereinement son extension a d’autres ressources strategiques de l’organisation, nous

assurant l’adhesion future de l’ensemble des utilisateurs.

9.4.3.2 Nouveau mode de gestion des modeles UML

La phase de modelisation est toujours realisee par les outils de modelisation tres

avances en fonctionnalites de modelisation, seule la gestion est confiee au referentiel SIDoc.

Les fonctions d’import/export faisant le lien entre les deux environnements intro-

duisent une etape supplementaire dans le processus de gestion. Une meilleure integration

des outils de modelisation et du referentiel serait un plus. Par exemple : l’utilisation directe

a partir de l’outil de modelisation, des services de chargement et de sauvegarde des objets

du referentiel sans passer par des fichiers d’export/import.

La gestion mise en place au niveau des representations XMI issues des outils

de modelisation permet de supporter certaines specificites. Malgre cela nous souhaitons

167

Chapitre 9. Evaluation et discussions

introduire le respect de la norme XMI afin d’assurer la prise en compte de toutes les

connaissances issues de la phase de modelisation.

Dans un environnement multi-utilisateurs avec des equipes nombreuses, les utili-

sateurs apprecient particulierement de pouvoir disposer d’un seul endroit de stockage des

modeles UML et d’autres ressources et livrables produits tout au long du processus de

conception et developpement.

Toujours dans ce contexte riche, ils apprecient de disposer d’un referentiel ras-

semblant l’ensemble des ressources et des connaissances produites a partir de l’expression

des besoins, des documents d’analyse jusqu’a la documentation utilisateur en passant par

la conception et le developpement.

Les fonctionnalites phares qui reviennent souvent dans les reponses des utili-

sateurs sont liees a la gestion des cycles de vie, de la concurrence d’acces et des revi-

sions/versions, fonctionnalites qui leur permettent de mieux apprehender la complexite

des applications a developper.

En effet, la gestion des revisions et des versions multiples d’une meme ressource

du referentiel SIDoc appliquee aux modeles UML permet de disposer a tout moment

d’une revision en particulier et de l’associer, a travers les mecanismes de tracabilite, a

l’expression des exigences associees. Par ailleurs, la gestion des versions et les fonctions de

synchronisation entre differentes versions, permet de lancer en parallele des chantiers de

modelisation, portant sur les memes composants. Cette fonctionnalite offre la possibilite

d’anticiper les futures evolutions du Systeme d’Information et d’obtenir ainsi un gain de

temps pendant la phase de modelisation.

9.4.3.3 Interface utilisateur

L’integration dans le referentiel a donne la possibilite aux utilisateurs de beneficier

des services SIDoc. Ainsi, ils apprecient les services de recherche d’information, la facilite

d’acces par le plan de classement, les modules et les tableaux de bord de suivi de la

production de contenu du referentiel.

Les nouvelles technologies employees dans les approches telles qu’AJAX 22 per-

mettent de creer des interfaces utilisateurs plus riches et plus reactives.

La presentation sous forme d’XForms des modeles UML a connu un bon accueil,

les utilisateurs appreciant la vue globale, depourvue de tout artifice visuel, qu’elle offre

sur l’ensemble des elements du modele. Cependant, la vue sous forme de diagramme a ete

preferee car elle permet de retrouver la presentation familiere de l’outil de modelisation.

Les utilisateurs estiment que la presentation des impacts reportee sur la version

SVG 23 des diagrammes UML par un mecanisme d’annotation visuelle (jeu de couleurs,

22. AJAX – Asynchronous JavaScript and XML permet d’enrichir les fonctionnalites d’un clientweb

23. SVG – Langage XML de definition des dessins vectoriels [W3C 03].

168

9.4. Integration dans le referentiel SIDoc

info-bulles) donne un bon apercu de l’etendu de l’impact. Mais ils preferent la presentation

sous forme de tableau de bord qui synthetise les resultats de cette etude en fournissant

une estimation des charges associees.

La norme XMI etant particulierement verbeuse, les temps de reponse necessaires a

la creation du dessin vectoriel SVG associe a chaque diagramme ne respectent pas toujours

les principes d’ergonomie definis dans l’Institution (a savoir le temps de chargement d’une

page qui peut etre trop important).

9.4.3.4 Analyse des dependances et etude d’impact

Par ailleurs, les resultats de l’etude d’impact estimes ont ete proposes a un groupe

de developpeurs en charge de l’application afin qu’ils soient confrontes a leur propre per-

ception. Les resultats ont ete juges assez proches de la realite (de ceux obtenus par une

estimation manuelle). Neanmoins, une limite a ete identifiee : le systeme dans sa ver-

sion actuelle ne permet pas de moduler l’estimation du nombre ou l’etendu de l’impact

en fonction du respect des bonnes regles de developpement (comme l’encapsulation). Ces

regles permettent de reduire les impacts reels par rapport aux impacts estimes seulement

en regardant le modele UML. Par consequent, le modele d’estimation est qualifie comme

pessimiste ; dans la situation actuelle, il detecte plus d’impacts que dans la realite.

L’ajustement des coefficients de propagation associes a chaque type de depen-

dance present dans les modeles UML (cf. 7.1.4.2), nous permet d’approcher l’interpretation

donnee a la realite par notre procedure d’etude d’impact.

Ce service nous permet d’ouvrir des pistes pour la mise en place d’autre fonc-

tionnalites telles que l’estimation des charges associees aux evolutions du referentiel et du

Systeme d’Information [Vasutiu 08].

9.4.4 Conclusions

La validation des nos contributions par les utilisateurs nous permet d’integrer les

nouveaux services dans le referentiel SIDoc enrichissant ainsi son offre de service a l’aube

de son extension, nous assurant l’adhesion future de l’ensemble des utilisateurs.

La problematique des etudes d’impact est tres simple dans les cas minimalistes

mais elle peut s’averer tres difficile dans des cas plus compliques. Des lors que nous sommes

en presence de plusieurs elements lies par plusieurs relations, la propagation des impacts

devient tres compliquee et surtout est definie par des nombreux chemins de propagation.

La consolidation de ces resultats est tres difficile. Face a cette problematique le modele

[Vasutiu 08] Vasutiu Ovidiu, Jouve David, Amghar Youssef et Pinon Jean-Marie. Knowledge ma-

nagement in information system design and delivery process. Proc. of the Xth Internation

Congres On Enterprise Information Systems (ICEIS’2008). Barcelona, Spain. INSTICC,

2008, p 5–26.

169

Chapitre 9. Evaluation et discussions

generique d’etude d’impacts devient necessaire pour automatiser cette etude et nous per-

mettre d’identifier l’ampleur de l’impact.

Par ailleurs, la notion de probabilite est tres importante et repond au manque de

semantique precise dans les modeles UML. Ainsi, une etude d’impact realisee a l’aide de

notre modele peut predire des nombreux impacts mais avec des probabilites tres differentes.

Le modele generique peut ensuite etre specialise avec des profils specifiques a un

domaine et a l’aide des coefficients de propagation probabilistes associes a chaque type

de relation. Ces moyens de specialisation nous permettent de realiser une etude d’impact

plus proche de la realite.

Le meta-modele d’etude d’impact a ete concu de maniere qu’il puisse integrer dans

le graphe d’analyse des dependances des instances issues de futurs types de ressources. Un

modele de graphe specifique au niveau N2 (modele de graphe d’analyse des dependances)

nous permettra de definir les modalites d’instanciation de ce graphe (typologie d’elements,

typologie de relations).

Une premiere piste d’integration serait la prise en compte du code source present

dans les applications, code source qui lui-meme represente une autre vue sur les connais-

sances du Systeme d’Information.

170

9.4

.In

tegratio

ndans

lereferen

tielSID

oc

Perimetre Nombre Evenement a Impacts Impacts Impacts Preci- Rappel

scenario d’elem b identifies c reels d pertinents e -sion

Dossier DAF f 7000

Modif. chapitre « Condition alloca-taire Paje »

31 30 29 0,93 0.96

Modif. tout le document Paje g 37 41 37 1 0,90

Modif. chapitre « Principe de non-cumul »

20 23 20 1 0,86

Modele UML du DAF 340

Re-nommage classe « CanevasMAP »

17 10 10 0,58 1

Suppression classe « CanevasMAP »

21 16 15 0,71 0,75

Suppression classe « DonneeD710M »

13 8 8 0.61 0,93

Ensemble des deux 7340

Modif. chapitre « Condition alloca-taire Paje »

53 54 52 0,97 0.95

Modif. tout le document Paje 47 50 45 0,94 0.89

Modif. chapitre « Principe de non-cumul »

61 61 57 0,93 0,93

Table 9.1 – Table de resultats de l’experimentation.

a. Evenement impactant un element du perimetre.b. Nombre d’elements constituant le perimetre du scenario. Pour une collection documentaire il s’agit du nombre de concepts documentaires :docu-

ments, fragments de documents. Pour un modele UML il s’agit du nombre de concepts UML elementaires : classe, attribut, methode, propriete, etc.c. Nombre d’impacts identifies par notre etude d’impact suite a l’analyse des ressources.d. Nombre des impact reels sur le domaine, ces impacts sont identifies par les utilisateurs.e. Nombre d’impacts identifies par notre etude d’impact qui sont egalement des impacts reels. Il s’agit de l’intersection des deux ensembles.f. DAF - Dossier d’analyse fonctionnelle specifiant le systeme de gestion des prestations Cristalg. Paje – Prestation Accueil Jeune Enfant

171

Chapitre 9. Evaluation et discussions

Fonctionnalite Appreciation Commentaire

(min 0 - max 5)

Gestion des modelesUML

4 Une meilleure integration avec les outilsde modelisation est necessaire. Voir la dis-cussion dans le paragraphe 9.4.3.2

Interface utilisateur 3 La presentation des impacts sous formede jeu de couleurs est tres appreciee. Lestemps de reponse sont tres longs et lesdiagrammes complexes ne sont pas tres li-sibles dans le navigateur. Voir la discus-sion dans le paragraphe 9.4.3.3

Etude d’impact 4 Les resultats de l’analyse sont pertinents.Il faut ameliorer la presentation des resul-tats nombreux ; les regrouper en fonctiondes chantiers. Voir la discussion dans leparagraphe 9.4.3.4

Table 9.2 – Tableau validation fonctionnelle.

172

Conclusion generale

Les travaux de recherche exposes au cours de la presente these ont ete menes

autour d’une problematique qui trouve son origine dans le contexte de la Branche Famille

de la Securite Sociale. C’est ainsi que la Caisse Nationale des Allocations Familiales a

servi de cadre pour l’elaboration de nos propositions. Ce contexte a ete particulierement

utile pour comprendre et analyser les nombreuses difficultes liees a la gestion de la matiere

reglementaire et a la maıtrise du Systeme d’Information, auxquelles peuvent etre quoti-

diennement confrontees des entreprises publiques ou privees. Ces problemes n’ont toutefois

pas ete traites uniquement en fonction du contexte specifique de travail (Cnaf), mais bien

en les considerant comme revelateurs d’une problematique plus large concernant la ges-

tion documentaire et la gestion des Systemes d’Information. Ainsi, notre modele generique

a ete illustre et teste dans le cadre specifique de la Cnaf mais son champ d’application

peut-etre elargi a d’autres domaines.

Apres avoir procede a une etude approfondie des differentes caracteristiques du

patrimoine documentaire, du Systeme d’Information et du role crucial que ces deux com-

posantes sont amenees a jouer au cœur de l’activite d’une organisation et, plus particuliere-

ment, au cœur des processus de mise en application du droit, nous nous sommes interesses

aux diverses problematiques et enjeux que suscitent la gestion des textes reglementaires

d’une part et celle du Systeme d’Information d’autre part.

Afin d’assurer la maıtrise du patrimoine des connaissances face aux evolutions

liees a la legislation, nous proposons d’utiliser une representation des dependances et des

methodes d’analyse et d’etude d’impact communs a la composante documentaire et logi-

cielle. C’est ainsi que, afin de constituer un modele adapte, tout en aspirant a la genericite,

nous introduisons le « modele d’etude d’impact » et « le graphe canonique de depen-

dances ». Ce modele nous permet de representer de la meme maniere les dependances

qu’entretiennent les elements de la composante documentaire et ceux de la composante

logicielle ainsi que de les mettre en relation.

Le modele propose a donc ete adapte pour les documents et pour les modeles

UML du Systeme d’Information. Il a ete implemente dans l’infrastructure du referentiel de

production et de gestion documentaire de la Cnaf. A travers cette phase d’implementation,

nous avons bati une infrastructure de gestion capable de repondre aux enjeux de la maıtrise

173

Conclusion generale

de la matiere reglementaire, patrimoine documentaire et Systeme d’Information. Nous

avons mis en evidence la pertinence, la fiabilite et la coherence de notre contribution, tout

en verifiant que le modele propose est realiste et operationnalisable.

Enfin, dans la derniere partie de la these nous avons presente une evaluation des

resultats de nos propositions, plus particulierement une evaluation des resultats de notre

modele d’etude d’impact et les retours des utilisateurs. La discussion qui clot le present

manuscrit est l’occasion de tracer quelques perspectives applicatives et scientifiques suite

aux travaux de recherche presentes.

Perspectives

Perspectives applicatives

La maıtrise du Systeme d’Information passe par la maıtrise des ressources de

conception : documents d’analyse, documents de specifications, modeles de conception,

code source des applications, etc. Nous avons propose les modalites necessaires pour inte-

grer les modeles UML dans l’infrastructure de gestion et de production des connaissances

de l’Institution.

Une autre piste d’integration serait la prise en compte du code source des applica-

tions du SI, representant une autre vue sur le Systeme d’Information. Ainsi l’integration des

modeles et du code des applications du Systeme d’Information nous permettra d’etendre

le perimetre couvert par le referentiel et d’offrir ainsi le cadre necessaire pour la maıtrise

des evolutions de l’ensemble des ressources de l’Institution.

Enfin, un travail de parametrage des coefficients de propagation pour le modele

documentaire et le modele logiciel est necessaire pour accorder au mieux les resultats des

estimations des impacts avec le domaine modelise et les habitudes de modelisation des

utilisateurs.

Perspectives scientifiques

Le systeme G-Frames [Jouve 03a] propose une modelisation semantique de la re-

glementation et une representation des connaissances dotee de mecanismes d’inference.

Une integration des representations G-Frames nous permettra d’atteindre un niveau su-

perieur dans la maıtrise du patrimoine des connaissances et du corpus reglementaire.

Lors de l’extension des services d’analyse des dependances et d’etude d’impact a

d’autres ressources institutionnelles, un nouveau terrain de recherche qui doit etre explore

consiste a adapter notre modele aux difficultes d’analyse d’un referentiel tres volumineux.

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

174

Annexe A

Liste des publications

1. Vasutiu O., Amghar Y., Jouve D., « Gestion des changements et etude d’impact

dans un systeme d’information reglementaire». Actes du XXIVeme Congres INFor-

matique des Organisations et Systemes d’Information et de Decision (INFORSID

2006), p. 1007-1022.

2. Vasutiu O., Vasutiu F., « Database Design Patterns for multi-language support in

software applications». Conference of PhD Students in Computer Science (CSCS

2006), p. 99-100.

3. Vasutiu O., Jouve D., Amghar Y., Pinon J.-M. «XML based Legal Document Draf-

ting Environement», Workshop on Legislative XML, 20th Aniversary Annual JURIX

Conference, 12-15 December 2007, CityplaceLeiden, Netherland

4. Vasutiu O., Jouve D., Amghar Y., Pinon J.-M. «Knowledge Management in In-

formation System Design and Delivery Process», 10th International Conference on

CityEnterprise Information Systems, 12-16 June 2008, CityplaceBarcelona, country-

regionSpain

175

Annexe A. Liste des publications

176

Annexe B

Schema XSD de la

recommandation XML-Schema

La recommandation XML-Schemas peut etre modelisee, a l’aide d’un schema XSD

presente, sous forme graphique par la figure B.1

Remarque : Pour illustrer nos exemples, nous avons essaye quelques produits,

mais un seul, XML Spy, est pleinement exploite dans le present manuscrit. XML Spy

[Altova 09] est un produit evolue et fonctionnellement riche, qui permet d’editer des DTD

et des schemas XML ainsi que des instances XML. Il contient des convertisseurs, notam-

ment en representations graphiques et des generateurs automatiques d’instances et de

modeles, qui se revelent pratiques en phase d’etude.

[Altova 09] Voir reference [Altova 09] definie page 40.

177

Annexe B. Schema XSD de la recommandation XML-Schema

Figure B.1 – Schema de la recommandation XML-Schemas. Representation graphiquerealisee par l’editeur de schemas XML XMLSpy [Altova 09].

178

Annexe C

Exemple d’un docflow

179

Annexe C. Exemple d’un docflow

Figure C.1 – Docflow d’un document de analyse et de conception du systeme de gestiondes prestations - Cristal.

180

Annexe D

Recettage fonctionnel de

l’application SIDoc - Extraits

D.1 Recettage fonctionnel

L’objet de cette demarche a ete de dresser un bilan fonctionnel des composants

mis a disposition dans le cadre de la premiere version du Referentiel de production et de

gestion documentaire au vu des criteres suivants :

– reponse au besoin,

– ergonomie,

– performances.

Parmi les differentes fonctionnalites proposees, l’analyse des dependances et l’etude

d’impact ont egalement ete evaluees. Les tableaux suivants presentent quelques extraits

de la synthese des evaluations des utilisateurs. Pour plus de details veuillez consulter le

compte-rendu des journees de recette fonctionnelle [CNEDI 07b].

[CNEDI 07b] Voir reference [CNEDI 07b] definie page 166.

181

Annexe D. Recettage fonctionnel de l’application SIDoc - Extraits

1.1. P érimètre de la V0

Fonctionnalités

Cah

ier

des

ch

arge

s

initi

al

Mis

en

pl

ace

en V

0

Observations / Appréciation (min 0 - max 5)

Accès possible à de multiples collections documentaires

Oui Oui 5

Consultation des objets documentaires /UML Oui Oui 4 – formulair es très riches

Consultation sous forme graphique Non Oui 3 - temps de réponse

Navigation dans la documentation viens des liens hypertexte Oui Oui 4

Edition des objets documentaires Oui Oui 5

Edition des objets UML Non Oui 3 – édition formulaire très difficile. Prévoir l’interfaçage avec des AGL UML

Gestion du multi - fenêtrage pour la consultation et l’édition des objets documentaires

Non Oui 5

Affichage d’une table des matières pour les documents volumineux

Non Oui 5

Plans de classement multiples ( consultation) Oui Oui 5

….. .... ….. ……

1.2. Gestion de la traçabilité

Fonctionnalités

Cah

ier

des

ch

arge

s

initi

al

Mis

en

plac

e

en V

0

Observations / Appréciation (min 0 - max 5)

Mise en corrélation des documents du DAF et des documents de la DPF Oui Oui

4 - P ermettre une mise en relation élémentaire d’une planification de révision/création/suppression avec un ou plusieurs paragraphes des documents associés à la Demande de modification Mise en corrélation des documents du

DAF et des documents UML N on Oui 4 – G ranularité suffisamment fine.

…. …. … ……

1.3. Gestion des impacts

Fonctionnalités

Cah

ier

des

ch

arge

s

initi

al

Mis

en

plac

e

en V

0

Observations / Appréciation (min 0 - max 5)

Etude d’impact Oui Oui 4 – Résultats pertinents. La liste des résultats devra faire a pparaître des regroupement de références par Tache.

Etude d’impact – forme graphique Non Oui 3 – chargement difficile de l’interface utilisateur.

…….. …… ……. ………

Figure D.1 – Extrait de la synthese d’evaluation

182

Annexe E

Le systeme G-Frames

E.1 Les G-Frames

David Jouve [Jouve 03a] realise un couplage du formalisme des frames et du

formalisme des graphes conceptuels, base sur la logique du 1er ordre, pour composer le

systeme primitif des G-Frames. Ainsi il beneficie des avantages de chacune de ces deux

structures : l’expressivite des langages de frames et la semantique forte des graphes concep-

tuels. La figure E.1 nous montre un exemple de traduction d’un acte juridique a l’aide de

G-Frame.

David Jouve definit egalement l’operation fondamentale de raisonnement du do-

maine, la projection G-Projection qui permet de calcul de la relation de specialisation/generalisation

sur les G-Frames. Le modele de G-Frames ainsi que les mecanismes de raisonnements at-

taches repondent dans le domaine juridique a des problematiques liees a la representation

de la legislation et a la detection des incoherences et des conflits au sein d’une base de

normes reglementaires.

[Jouve 03a] Voir reference [Jouve 03a] definie page 2.

183

Annexe E. Le systeme G-Frames

Livre 5: Prestations Familiales et prestations assimilées

Titre I: Champ d’application - Généralités...

Chapitre II: Champ d’application

art. L. 512-1 Toute personne française ou étrangère résidant en France, ayant à sa chargeun ou plusieurs enfants...

Code de la Sécurité Sociale... Suivi Législatif : CEE

I - Allocataire

I.1 Conditions généralesI.1.a Personne

I.1.c Résidence

...

I.1.d Enfants à charge...

Allocataire

Paramétre

Condition derésidence

Condition d’activité

Personne Physique : *x

Type

Activité

France réside

exerce France loc

Enfant

Union Européenne

résideaChargeCondition de charge d’enfant

I.1.b Activité...

Champ Prestations Familiales

......

... réside en ...

FS SNN

Personne Physique : ?x

Personne Physique : ?x

Personne Physique : ?x

Figure E.1 – Exemple de G-Frames. Extrait de [Jouve 03a].

184

Glossaire

AJAX : Asynchronous JavaScript and XML - approche permettant d’enrichir les fonc-

tionnalites des clients Web

CAF : Caisse d’Allocation Familiales.

CNAF : Caisse Nationale des Allocations Familiales.

CNEDI : Centre National d’Etudes et de Developpements Informatiques.

Collection documentaire : Composante du referentiel de production et de gestion docu-

mentaire qui est formee par un ensemble de contenus non redondant et maintenu

en coherence avec celui des autres collections. Voir definition 2.3.1

Consistance (modeles UML) : Propriete des modeles UML qui disposent d’un ensemble

de diagrammes coherent explicitant des proprietes du domaine correctes les unes

avec les autres.

Contexte de production : Il s’agit du contexte dans lequel les differentes structures

internes au document sont mises en place en fonction d’une pratique donnee (par

exemple le domaine legislatif). Les acteurs intervenant dans le contexte de pro-

duction sont les redacteurs (producteurs de contenu) des documents

Contexte de reception : Le contexte de reception determine la maniere dont les struc-

tures du document seront utilisees et interpretees par les lecteurs.

Conviction : Propriete d’un impact, represente sur une echelle de 0 a 100 la precision

avec laquelle nous pouvons affirmer la presence d’un impact elementaire.

CRISTAL : Systeme dedie a la gestion des prestations pour la Branche Famille de la

Securite Sociale.

Degre : Propriete d’un impact, represente, sur une echelle de 0 a 100, la couverture estimee

de l’impact sur un element impactable.

Docflow : Cycle de vie du document dans le cadre d’un processus de production docu-

mentaire.

Document multistructure : Voir Document polystructure.

Document polystructure : Document caracterise par la presence de plusieurs structures

concurrentes correspondant a des usages varies du document.

185

Glossaire

DSI : Direction du Systeme d’Information.

DTD : Document Type Definition – definit la structure d’un document.

Frame : Structure de donnees pour la representation d’une situation stereotypee.

G-Frame : Primitive fournie par le systeme des G-Frames afin d’exprimer des connais-

sances de nature assertionnelle.

HyTime : Hypermedia/Time-based Structuring Language.

ISDN : Institut des Sciences du Document Numerique.

Livrable logiciel : Livrable issus d’une des etapes d’un des processus de conception et

de developpement logiciel.

OCL : Object Constraint Language.

Ontologie : Dans le domaine de l’intelligence artificielle, une ontologie est frequemment

consideree comme la specification explicite d’une conceptualisation.

Organisation : Entreprise publique, entreprise privee ou institution publique (ministere,

tribunal, etc.).

PF : Prestation(s) Familiale(s).

Projection : Mecanisme permettant de passer du support d’enregistrement au support

d’appropriation

Raisonnement : Processus permettant, a partir de connaissances encodees de facon expli-

cite, de mettre en lumiere des connaissances qui n’etaient alors qu’implicitement

connues.

RDF : Resource Description Framework.

SGML : Standard Generalized Markup Language.

SI : Systeme d’Information.

SIDoc : Systeme d’Information Documentaire - le projet informatique qui a cree le Refe-

rentiel de gestion et de production documentaire.

Structure generique : Un document generique correspond a une classe de document.

Des langages de structuration documentaire tels que XML associent a cette notion

celle de DTD ou de schema.

Structure materielle : Structure imposant une presentation, une mise en forme du

document conformement a l’ordonnancement prescrit. Par exemple : un choix des

polices, de mise en page, etc.

Structure physique : Voir structure materielle

Structure semantique : Structure qui s’attache a l’explicitation de la signification des

informations vehiculees par le document

186

Structure specifique : Un document specifique est une instance d’un document ge-

nerique. Des langages tels que XML font correspondre a cette notion celle de

document valide. Un document valide est un document specifique conforme aux

contraintes structurelles imposees par le document generique dont il est l’exem-

plification.

Support d’appropriation : Support sur lequel le document est presente a l’utilisateur

lecteur.

Support d’enregistrement : Support sur lequel le document numerique est enregistre

selon un format de codage predefinit.

SVG : Langage XML de definition des dessins vectoriels.

Systeme Primitif des G-Frames : Systeme des G-Frames denue de toute extension

ontologique.

Taux de precision : Rapport du nombre d’elements pertinents identifies au nombre total

d’elements trouves. En anglais precision.

Taux de rappel : Rapport du nombre de documents pertinents trouves au nombre total

de documents pertinents. En anglais recall.

XML : eXtensible Markup Language.

XSD : Schema XML d’un document – tout comme les DTD definit la structure d’un

document. Les schemas sont eux-memes decrits en XML

187

Glossaire

188

Bibliographie

[Abrial 96] Abrial Jean-Raymond. The B-book : assigning programs to

meanings. Cambridge University Press, New York, NY, USA,

1996. 779 p.

[Alexander 02] Alexander Ian. Towards automatic traceability in industrial

practice. Proceedings of 1st International Workshop on Traceabi-

lity in Emerging Forms of Software Engineering. 2002, p 26–31.

[Altova 09] Altova, Rudolfsplatz 13a/9, A-1010 Wien, Austria. Al-

tova XMLSpy Schema Editor, 2009. Disponible sur :

http ://www.altova.com (consulte le 07.08.2009).

[Arbaoui 02] Arbaoui Selma, Derniame Jean-Claude, Oquendo Fla-

vio et Verjus Herve. A comparative review of process-

centered software engineering environments. Annals of Software

Engineering, 2002, vol 14, n 1-4, p 311–340.

[Aurum 03] Aurum Aybuke, Jeffery Ross, Wohlin Claes et Handzic

Meliha. Managing Software Engineering Knowledge. Springer,

2003. 380 p.

[Bachimont 99] Bachimont B. Bibliotheques numeriques audiovisuelles : des

enjeux scientifiques et techniques. Document Numerique, nu-

mero special Les bibliotheques numeriques, 1999, vol 2, n 3-4, p

219–242.

[Bargeron 99] Bargeron D., Gupta A., Grudin J., Sanocki E. et Men-

delzon A. Annotations for Streaming Video on the Web :

System Design and Usage Studies. Computer Networks, 1999,

vol 31, n 11-16, p 1139–1153.

[Bauer 89] Bauer Friedrich Ludwig, Moller Bernhard, Partsch

Helmut et Pepper Peter. Formal program construction by

transformations-computer-aided, intuition-guided programming.

IEEE Trans. Softw. Eng., 1989, vol 15, n 2, p 165–180.

189

Bibliographie

[Beck 99] Beck Kent. Extreme Programming Explained : Embrace

Change. Addison-Wesley Professional, 1999. 224 p.

[Belguidoum 06] Belguidoum Meriem et Dagnat Fabien. Analysis of deploy-

ment dependencies in software components. SAC ’06 : Procee-

dings of the 2006 ACM symposium on Applied computing. New

York, NY, USA. ACM, 2006, p 735–736.

[ben Lagha 99] b Lagha S., Sadfi W. et b Ahmed M. Une comparaison

SGML-XML. Cahiers GUTenberg : Actes de la journee XML au

Congres GUT99. Lyon, France. mai 1999, p 127–154.

[Bench-Capon 90] Bench-Capon Trevor et Coenen Frans. Practical Appli-

cation of KBS to Law : the Crucial Role of Maintenance. Legal

Knowledge Based Systems, JURIX’90 : Aims for Research and

Development. Edited by Schmidt A.H.J. et Winkels R.G.F.

Lelystad. Koninklijke Vermande, 1990, p 1–17.

[Bench-Capon 94] Bench-Capon Trevor et Coenen Frans. The Maintenance

of Legal Knowledge Based Systems. Computers and Law. Edited

by Carr I. et Williams K., p 129–172. Intellect Books, 1994.

[Binkley 91] Binkley David. Multi-Procedure Program Integration. These :

Univ. of Wisconsin, Madison, WI, August 1991.

[Bohner 96] Bohner Shawn et Arnold Robert. Software Change Impact

Analysis. Wiley, 1996. 392 p.

[Briand 03] Briand L. C., Labiche Y. et O’Sullivan L. Impact analysis

and change management of uml models. ICSM ’03 : Procee-

dings of the International Conference on Software Maintenance.

Washington, DC, USA. IEEE Computer Society, 2003, p 256.

[Brooks 87] Brooks Frederic. No silver bullet : Essence and accidents of

software engineering. Computer, 1987, vol 20, n 4, p 10–19.

[Chabbat 97] Chabbat Bertrand. Modelisation multiparadigme de textes

reglementaires. These : Institut National des Sciences Appliquees

de Lyon, Lyon, France, decembre 1997. 389 p.

[Champin 02] Champin Pierre-Antoine. Modeliser l’experience pour en as-

sister la reutilisation : De la conception assistee par ordinateur

au web semantique. These : Universite Claude Bernard – Lyon

1, Lyon, France, Decembre 2002. 138 p.

[Chen 02] Chen Zhenqiang, Xu Baowen et Zhao Jianjun. An over-

view of methods for dependence analysis of concurrent programs.

SIGPLAN Not., 2002, vol 37, n 8, p 45–52.

190

[Chiba 08] Chiba project. Chiba, 2008. Disponible sur :

http ://chiba.sourceforge.net/ (consulte le 10.09.2008).

[Cleland-Huang 03] Cleland-Huang Jane, Chang Carl K. et Christensen

Mark. Event-based traceability for managing evolutionary

change. IEEE Trans. Softw. Eng., 2003, vol 29, n 9, p 796–810.

[CNAF 08] Caisse Nationale des Allocations Familiales, 32, avenue de la Si-

belle, 75685 PARIS CEDEX 14. Aide personnalisee au logement

- Suivi legislatif, 2008.

[CNEDI 07a] Centre National d’Etudes et du Developpement Informatique

Rhone-Alpes, 128 rue servient, 69003 Lyon. Documentation du

projet SIDoc, 2007.

[CNEDI 07b] Centre National d’Etudes et du Developpement Informatique

Rhone-Alpes, 128 rue servient, 69003 Lyon. SIDoc - Systeme

d’Aide a l’Implementation de la Reglementation - Recettage

fonctionnel de la V0, 2007.

[CNEDI 07c] Centre National d’Etudes et du Developpement Informatique

Rhone-Alpes, 128 rue servient, 69003 Lyon. SIDoc - Systeme

d’Aide a l’Implementation de la Reglementation - Recettage tech-

nique de la V0, 2007.

[CodeSecuriteSociale 01] Secretariat General du Gouvernement, Hotel de Matignon, 57

rue de Varenne, 75007 PARIS. Code de la Securite Sociale –

Livre 2 : Organisation du regime general, action de prevention,

action sanitaire et sociale des caisses, 2001. Disponible sur :

http ://www.legifrance.gouv.fr (consulte le 07.07.2008).

[Cook 94] Cook Steve et Daniels John. Designing Object Systems :

Object-Oriented Modelling with Syntropy. Prentice Hall, 1994.

388 p.

[Dahl 72] Dahl O. J., Dijkstra E. W. et Hoare C. A. R. Structured

Programming. Academic Press, 1972. 234 p.

[Dijkstra 76] Dijkstra Edsger Wybe. A Discipline of Programming. Series

in Automatic Computation. Prentice Hall, 1976. 240 p.

[Domges 98] Domges Ralf et Pohl Klaus. Adapting traceability environ-

ments to project-specific needs. Commun. ACM, 1998, vol 41,

n 12, p 54–62.

[Doors 08] Telelogic AB, Telelogic AB, PO Box 4128, Kungsgatan 6, SE-203

12 Malmo, Sweden. Telelogic DOORS, 2008. Disponible sur :

191

Bibliographie

http ://www.telelogic.com/products/doors/index.cfm (consulte

le 07.08.2009).

[Duke 00] Duke Roger et Rose Gordon. Formal Object-Oriented Spe-

cification Using Object-Z. Palgrave Macmillan, 2000. 240 p.

[Eclipse 08] Eclipse Foundation. Eclipse - an open develop-

ment platform, 2008. Disponible sur : http ://www-

01.ibm.com/software/awdtools/developer/rose/index.html

(consulte le 04.08.2009).

[Egyed 02] Egyed Alexander et Grunbacher Paul. Automating re-

quirements traceability : Beyond the record & replay paradigm.

ASE ’02 : Proceedings of the 17th IEEE international conference

on Automated software engineering. Washington, DC, USA.

IEEE Computer Society, 2002, p 163.

[Ekman 04] Ekman Torbjorn et Asklund Ulf. Refactoring-aware ver-

sioning in eclipse. Proceedings of the Second Eclipse Technology

Exchange : eTX and the Eclipse Phenomenon (eTX 2004). Elec-

tronic Notes in Theoretical Computer Science, 2004, p 57–69.

[Engels 01] Engels Gregor, Kuster Jochem M., Heckel Reiko et

Groenewegen Luuk. A methodology for specifying and

analyzing consistency of object-oriented behavioral models.

ESEC/FSE-9 : Proceedings of the 8th European software engi-

neering conference held jointly with 9th ACM SIGSOFT interna-

tional symposium on Foundations of software engineering. New

York, NY, USA. ACM, 2001, p 186–195.

[Enss 04] Enss Raphael. Refactoring in Eclipse. Eclipse Departement

of Computer Science University of Manitoba, 2004. Disponible

sur : http ://www.cs.umanitoba.ca/ eclipse/13-Refactoring.pdf

(consulte le 04.08.2009).

[Erdmann 99] Erdmann Michael et Studer Rudi. Ontologies as Concep-

tual Models for XML Documents. Twelfth Workshop on Know-

ledge Acquisition, Modeling and Management (KAW’99). Al-

berta, Canada. 1999.

[Feather 00] Feather Martin, Cornford Steven et Gibbel Mark.

Scalable mechanisms for requirements interaction management.

Proceedings of the 4th International Conference on Requirements

Engineering –(Schaumburg, Illinois June 2000). IEEE Compu-

ter Society Press, 2000, p 119–129.

192

[Ferrante 87] Ferrante Jeanne, Ottenstein Karl J. et Warren Joe D.

The program dependence graph and its use in optimization.

ACM Trans. Program. Lang. Syst., 1987, vol 9, n 3, p 319–349.

[Finkelstein 94] Finkelstein Anthony, Kramer Jeff et Nuseibeh Bashar.

Software Process Modelling and Technology. Research Studies

Press Limited (J. Wiley), Taunton, UK, UK, 1994. 362 p.

[Fuggetta 00] Fuggetta Alfonso. Software process : A roadmap. Pro-

ceedings of the 22nd Int. Conf. on Software Engineering (IC-

SE’2000) – Future of Software Engineering Track. 2000.

[Gall 03] Gall Harald, Jazayeri Mehdi et Krajewski Jacek. Cvs

release history data for detecting logical couplings. IWPSE ’03 :

Proceedings of the 6th International Workshop on Principles of

Software Evolution. Washington, DC, USA. IEEE Computer

Society, 2003, p 13.

[German 04] German Daniel M. An empirical study of fine-grained soft-

ware modifications. ICSM ’04 : Proceedings of the 20th IEEE

International Conference on Software Maintenance. Washing-

ton, DC, USA. IEEE Computer Society, 2004, p 316–325.

[Ghezzi 03] Ghezzi Carlo, Jazayeri Mehdi et Mandrioli Dino. Fu-

damentals of Software Engineering. Prentice Hall, 2003. 624

p.

[Gianpaolo 98] Gianpaolo Cugola et Carlo Guezzi. Software processes : a

retrospective and a path to the future. Software Process Impro-

vement and Practice, 1998, vol 4, n 3, p 101–123.

[Gotel 94] Gotel O. et Finkelstein A. An analysis of the requirements

traceability problem. In Proceedings of 1st International Confe-

rence on Requirements Engineering (Colorado Springs, CO). Los

Alamitos, CA,. IEEE Computer Society Press, 1994, p 94–101.

[Hatcliff 99] Hatcliff John, Corbett James, Dwyer Matthew, Soko-

lowski Stefan et Zheng Hongjun. A formal study of slicing

for multi-threaded programs with jvm concurrency primitives.

Proceedings of the 6th International Static Analysis Symposium

(SAS’99). Springer-Verlag, 1999, p 1–18.

[Horwitz 04] Horwitz Susan, Reps Thomas et Binkley David. Interpro-

cedural slicing using dependence graphs. SIGPLAN Not., 2004,

vol 39, n 4, p 229–243.

193

Bibliographie

[Humphrey 89] Humphrey Watts S. Managing the Software Process. SEI

Series in Software Engineering. Addison-Wesley, 1989. 512 p.

[ISO 86] International Organization for Standardization. Standard Gene-

ralized Markup Language (SGML). International Standard ISO

8879 :1986(E), Octobre 1986. 155 p.

[ISO 92] International Organization for Standardization.

Hypermedia/Time-based Structuring Language (HyTime).

International Standard ISO 10744 :1992(E), Decembre 1992.

184 p.

[ISO 97] International Organization for Standardization. ISO 9000-3 task

force, Quality management and quality assurance standards -

Part 3 : guidelines for the application of ISO 9000 to the de-

velopment, supply and maintenance of software, 1997.

[ISO 04] International Organization for Standardization. ISO/IEC 15504

– SPICE (Software Process Improvement and Capability dEter-

mination, 2004.

[ISO 06] International Organization for Standardization. Document

Schema Definition Language (DSDL) – Rule-based validation

– Schematron. International Standard ISO/IEC 19757-3 :2006,

2006. 38 p.

[Jouve 01] Jouve David, Chabbat Bertrand, Amghar Youssef et Pi-

non Jean-Marie. Structuration semantique de la reglemen-

tation. Proc. of the XIXeme Congres INFormatique des OR-

ganisations et Systemes d’Information et de Decision (INFOR-

SID’2001). Martigny, Suisse. INFORDSID Editions, 2001, p 5–

26.

[Jouve 03a] Jouve David. Modelisation semantique de la reglementation.

These : Institut National des Sciences Appliquees de Lyon, no-

vembre 2003. 270 p.

[Jouve 03b] Jouve David, Amghar Youssef, Chabbat Bertrand et Pi-

non Jean-Marie. Conceptual Framework for Document Se-

mantic Modelling : an Application to Document and Knowledge

Management in the Legal Domain. Data & Knowledge Enginee-

ring, 2003, vol 46, n 3, p 345 – 375.

[Kagdi 07] Kagdi Huzefa et Maletic Jonathan I. Combining single-

version and evolutionary dependencies for software-change pre-

diction. MSR ’07 : Proceedings of the Fourth International

194

Workshop on Mining Software Repositories. Washington, DC,

USA. IEEE Computer Society, 2007, p 17.

[Klarlund 02] Klarlund N., Moller A. et Schwatzbach M. I. Dsd :

a schema language for xml. Automated Software Engineering,

2002, vol 9, n 3, p 285–319.

[Krishnan 00] Krishnan P. Consistency checks for uml. APSEC ’00 : Procee-

dings of the Seventh Asia-Pacific Software Engineering Confe-

rence. Washington, DC, USA. IEEE Computer Society, Decem-

ber 2000, p 162–169.

[Lano 90] Lano Kevin. Z++ – an object-orientated extension to z. Z User

Workshop. Workshops in Computing, Springer-Verlag, 1990, p

151–172.

[Lee 00] Lee D. et Chu W.W. Comparative analysis of six xml schema

languages. SIGMOD Record, 2000, vol 29, n 3, p 76 – 87.

[Lucia 07] Lucia Andrea De, Fasano Fausto, Oliveto Rocco et

Tortora Genoveffa. Recovering traceability links in soft-

ware artifact management systems using information retrieval

methods. ACM Trans. Softw. Eng. Methodol., 2007, vol 16, n 4,

p 13.

[Maletic 01] Maletic Jonathan et Marcus Andrian. Supporting pro-

gram comprehension using semantic and structural information.

ICSE ’01 : Proceedings of the 23rd International Conference on

Software Engineering. Washington, DC, USA. IEEE Computer

Society, 2001, p 103–112.

[Michard 01] Michard Alain. XML Langage et Applications. Editions Ey-

rolles, Paris, 2001. 499 p.

[Microsoft 06] Microsoft Coorporation. Le navigateur Microsoft In-

ternet Explorer, version 6, 2006. Disponible sur :

http ://www.microsoft.com/windows/ie/ie6/default.mspx

(consulte le 07.08.2009).

[Microsoft 07] Microsoft Coorporation. Le navigateur Microsoft In-

ternet Explorer, version 7, 2007. Disponible sur :

http ://www.microsoft.com/windows/internet-explorer/ie7/

(consulte le 07.08.2009).

[Morin 99] Morin Edgar. Relier les connaissances – Le defi du XXIe

siecle. Seuil, 1999. 478 p.

195

Bibliographie

[Mozilla 08] Fondation Mozilla. Le projet Firefox de la fondation

Mozilla, 2008. Disponible sur : http ://www.mozilla-

europe.org/fr/firefox/ (consulte le 07.08.2009).

[MSOffice 08] Microsoft Coorporation. Microsoft Office, 2008. Dispo-

nible sur : http ://www.microsoft.com/france/office (consulte le

07.08.2009).

[Nanard 96] Nanard Marc, Nanard Jocelyne, Massotte Anne Ma-

rie, Chauche Jacques, Joubert Alain et Betaille Henri.

Acquisition et ingenierie des connaissances, tendances actuelles,

chapitre La metaphore du generaliste : Acquisition et utilisation

de la connaissance macroscopique sur une base de documents

techniques, p 285–306. Cepadues editions, 1996.

[Nicolle 01] Nicolle Cecile. Systeme d’acces a des Bases de Donnees He-

terogenes reparties en vue d’une aide a la decision (SABaDH).

These : Institut National des Sciences Appliquees de Lyon, de-

cembre 2001. 125 p.

[Oberon 08] Institut fur Systemsoftware, Johannes Kepler Universitat, Insti-

tut fur Systemsoftware, Altenbergerstr. 69, A-4040 Linz. Oberon

Slicing Tool, 2008. Disponible sur : http ://www.ssw.uni-

linz.ac.at/Research/Projects/ProgramSlicing/ (consulte le

07.08.2009).

[OMG 01] Object Management Group (OMG). Unified Modeling Language

Specification, Version 1.4, septembre 2001. Disponible sur :

http ://www.omg.org/spec/UML/1.4/ (consulte le 05.08.2008).

[OMG 05] Internation Standardisation Organisation (ISO). Meta Ob-

ject Facility Specification, Version 1.4.1, 2005. Disponible

sur : http ://www.omg.org/docs/formal/05-05-05.pdf (consulte

le 04.08.2008).

[OMG 06a] Object Management Group (OMG). Meta Object Faci-

lity Specification, Version 2.0, 2006. Disponible sur :

http ://www.omg.org/spec/MOF/2.0/ (consulte le 04.08.2008).

[OMG 06b] Object Management Group (OMG). Object Constraint

Language Specification, version 2.0, mai 2006. Disponible

sur :http ://www.omg.org/technology/documents/formal/ocl.htm

(consulte le 08.08.2008).

[OMG 07a] Object Management Group (OMG). Unified Modeling

Language Specification, Version 2.1.2, 2007. Disponible

196

sur : http ://www.omg.org/spec/UML/2.1.2/ (consulte le

04.08.2008).

[OMG 07b] OMG – Object Management Group. XML Metadata In-

terchange (XMI), v2.1.1, December 2007. Disponible sur :

http ://www.omg.org/technology/documents/formal/xmi.htm

(consulte le 03.09.2008).

[Opdyke 92] Opdyke William F. Refactoring Object-Oriented Frame-

works. These : University of Illinois at Urbana-Champaign, 1992.

Disponible sur : http ://www.laputan.org/pub/papers/opdyke-

thesis.pdf (consulte le 04.11.2009).

[Osterweil 87] Osterweil Leaon. Software processes are software too. ICSE

’87 : Proceedings of the 9th international conference on Software

Engineering. Los Alamitos, CA, USA. IEEE Computer Society

Press, 1987, p 2–13.

[Ottenstein 84] Ottenstein Karl J. et Ottenstein Linda M. The program

dependence graph in a software development environment. SIG-

PLAN Not., 1984, vol 19, n 5, p 177–184.

[Pfleeger 06] Pfleeger Shari Lawrence et Atlee Joanne M. Software

Engineering : Theory and Practice, third edition. Prentice Hall,

2006. 736 p.

[Pinheiro 96] Pinheiro Francisco A. C. et Goguen Joseph A. An object-

oriented tool for tracing requirements. IEEE Softw., 1996, vol 13,

n 2, p 52–64.

[Pohl 87] Pohl Klaus. Requirements engineering : An overview. In En-

cyclopedia of Computer Science and Technology, 1987, vol 36,

n 21.

[Rand 79] Rand Ayn. Introduction to Objectivist Epistemology. New Ame-

rican Library, New York, USA, 1979. 314 p.

[RDD 08] Holagent Coorporation. RDD-100, 2008. Disponible sur :

http ://www.holagent.com/products/ (consulte le 07.08.2009).

[Requisite 08] IBM Corporation. Rational RequisitePro, 2008. Disponible sur :

http ://www-01.ibm.com/software/awdtools/reqpro/ (consulte

le 07.08.2009).

[Richardson 04] Richardson Julian et Green Jeff. Automating traceabi-

lity for generated software artifacts. ASE ’04 : Proceedings of

the 19th IEEE international conference on Automated software

197

Bibliographie

engineering. Washington, DC, USA. IEEE Computer Society,

2004, p 24–33.

[Rick 00] Rick Jellife. The Schematron – An XML Structure Va-

lidation Language using Patterns in Trees, 2000. Disponible

sur : http ://xml.ascc.net/resource/schematron/ (consulte le

04.08.2009).

[Roberts 99] Roberts Donald Bradley. Practical analysis for refactoring.

These : University of Illinois at Urbana-Champaign, Champaign,

IL, USA, 1999. Adviser-Ralph Johnson.

[Robinson 03] Robinson William N., Pawlowski Suzanne D. et Vol-

kov Vecheslav. Requirements interaction management. ACM

Computing Surveys, 2003, vol 35, n 2, p 132–190.

[Rodrıguez 04a] Rodrıguez Oscar M., Martınez Ana I., Favela Jesus

et Vizcaıno Aurora. Understanding and supporting know-

ledge flows in a community of software developers. International

Workshop on Groupware (CRIWG’04). 2004, p 56–66.

[Rodrıguez 04b] Rodrıguez Oscar M., Martınez Ana I., Vizcaıno Au-

rora, Favela Jesus et Piattini Mario. Identifying know-

ledge managment needs in software maintenance groups : a quali-

tative approach. Proceedings of the 5th Internationa Conference

on Computer Science (ENC’ 2004). IEEE Computer Society

Press, 2004, p 72–79.

[Rose 08] IBM Coorporation. Rational Rose, 2008. Disponible sur :

http ://www.eclipse.org/ (consulte le 04.08.2009).

[Royce 70] Royce Winston. Managing the development of large software

systems : Concepts and techniques. In Proceedings of WesCon

Conference, August 25-28 1970.

[RUP09 09] IBM Coorporation. Rational Unified Process, 2009. Dispo-

nible sur : http ://www-01.ibm.com/software/awdtools/rup/

(consulte le 24.03.2009).

[Settimi 04] Settimi Raffaella, Cleland-Huang Jane, Khadra Ous-

sama Ben, Mody Jigar, Lukasik Wiktor et DePalma

Chris. Supporting software evolution through dynamically re-

trieving traces to uml artifacts. IWPSE ’04 : Proceedings of the

Principles of Software Evolution, 7th International Workshop.

Washington, DC, USA. IEEE Computer Society, 2004, p 49–54.

198

[Smith 99] Smith Graeme. The Object-Z Specification Language. Kluwer

Academic Publishers, Norwell, MA, USA, 1999. 160p.

[Sourrouille 02] Sourrouille Jean Louis et Caplat Guy. Constraint che-

cking in uml modeling. SEKE ’02 : Proceedings of the 14th in-

ternational conference on Software engineering and knowledge

engineering. New York, NY, USA. ACM, 2002, p 217–224.

[Stern 97] Stern Yves. Les quatre dimensions des documents electro-

niques. Document Numerique, 1997, vol 1, n 1, p 55–60.

[Suciu 01] Suciu Dan. On database theory and xml. SIGMOD Rec., 2001,

vol 30, n 3, p 39–45.

[Sward 04] Sward Ricky E. et Chamillard A.T. Adaslicer : an ada

program slicer. Ada Lett., 2004, vol XXIV, n 1, p 10–16.

[Turner 06] Turner Michael S. V. Microsoft Solutions Framework Es-

sentials. Microsoft Press, 2006. 336 p.

[Turpin 06] Turpin Andrew et Scholer Falk. User performance versus

precision measures for simple search tasks. SIGIR ’06 : Procee-

dings of the 29th annual international ACM SIGIR conference

on Research and development in information retrieval. New

York, NY, USA. ACM, 2006, p 11–18.

[van Lamsweerde 00] v Lamsweerde Axel et Letier Emmanuel. Handling obs-

tacles in goal-oriented requirements engineering. IEEE Transac-

tions on Software Engineering, 2000, vol 26, n 10, p 978–1005.

[Vasutiu 06] Vasutiu Ovidiu, Jouve David et Amghar Youssef. Gestion

des changements et etude d’impact dans un Systeme d’Informa-

tion reglementaire. INFORSID’2006 - Informatique des ORga-

nisations et Systemes d’Information et de Decision 2006. Edited

by Inforsid . Actes du XXIVeme Congres. Association Inforsid,

juin 2006, p 1007–1022.

[Vasutiu 08] Vasutiu Ovidiu, Jouve David, Amghar Youssef et Pinon

Jean-Marie. Knowledge management in information system

design and delivery process. Proc. of the Xth Internation Congres

On Enterprise Information Systems (ICEIS’2008). Barcelona,

Spain. INSTICC, 2008, p 5–26.

[Vergnaud 90] Vergnaud Gilles. La theorie des champs conceptuels. Re-

cherches en didactique des mathematiques, 1990, vol 10, p 133 –

170.

199

Bibliographie

[W3C 98] World Wide Web Consortium. Cascading Style Sheets Level

2 Specification, W3C Recommendation, 1998. Disponible sur :

http ://www.w3.org/TR/REC-CSS2 (consulte le 07.08.2009).

[W3C 99a] World Wide Web Consortium. Cascading Style Sheets, Level

1 (revised 11 Jan 1999), W3C Recommendation, 1999. Dis-

ponible sur : http ://www.w3.org/TR/REC-CSS1 (consulte le

07.08.2009).

[W3C 99b] World Wide Web Consortium. Transformations XSL (XSLT)

Version 1.0, W3C Recommendation, 1999. Disponible sur :

http ://www.w3.org/TR/xslt (consulte le 07.08.2009).

[W3C 99c] World Wide Web Consortium. XML Path Language (XPath),

Version 1.0, W3C Recommendation, 1999. Disponible sur :

http ://www.w3.org/TR/xpath (consulte le 07.08.2009).

[W3C 01a] World Wide Web Consortium. Transformations XSL (XSLT)

Version 1.1, W3C Working Draft, 2001. Disponible sur :

http ://www.w3.org/TR/xslt11 (consulte le 07.08.2009).

[W3C 01b] World Wide Web Consortium. XML Schema Part 0 :

Primer, W3C Recommendation, 2001. Disponible sur :

http ://www.w3.org/TR/xmlschema-0 (consulte le 04.08.2009).

[W3C 01c] World Wide Web Consortium. XML Schema Part 1 :

Structures, W3C Recommendation, 2001. Disponible sur :

http ://www.w3.org/TR/xmlschema-1 (consulte le 04.08.2009).

[W3C 01d] World Wide Web Consortium. XML Schema Part 2 :

Datatypes, W3C Recommendation, 2001. Disponible sur :

http ://www.w3.org/TR/xmlschema-2 (consulte le 04.08.2009).

[W3C 01e] World Wide Web Consortium. XML Schema,

W3C Recommendation, 2001. Disponible sur :

http ://www.w3.org/XML/Schema (consulte le 04.08.2009).

[W3C 03] World Wide Web Consortium. Scalable Vector Graphics

(SVG) 1.0. Specification, January 2003. Disponible sur :

http ://www.w3.org/TR/svg (consulte le 10.08.2009).

[W3C 07a] World Wide Web Consortium. XForms 1.0 (Third Edition), Oc-

tober 2007. Disponible sur : http ://www.w3.org/TR/xforms

(consulte le 10.08.2009).

[W3C 07b] World Wide Web Consortium. XML Query Language (XQuery),

Version 1.0, W3C Recommendation, January 2007. Disponible

sur : http ://www.w3.org/TR/xquery (consulte le 07.08.2009).

200

[W3C 08] World Wide Web Consortium. Extensible Markup Language

(XML) 1.0 (Fifth Edition), W3C Recommendation, August

2008. Disponible sur : http ://www.w3.org/TR/REC-XML

(consulte le 11.08.2009).

[Weiser 81] Weiser Mark. Program slicing. ICSE ’81 : Proceedings of the

5th international conference on Software engineering. Piscata-

way, NJ, USA. IEEE Press, 1981, p 439–449.

[Weiser 84] Weiser Mark. Program slicing. IEEE Transactions on Soft-

ware Engineering, July 1984, vol 10, n 4, p 352–357.

[Wirth 71] Wirth Niklaus. Program development by stepwise refinement.

Communications of the ACM, 1971, vol 14, n 4, p 221–227.

[Wisconsin00 00] University of Wisconsin-Madison. The Wisconsin Program-

Slicing Tool, Version 1.1, 2000. Disponible sur :

http ://www.cs.wisc.edu/wpis/slicing tool/ (consulte le

07.08.2009).

[Wulf 58] Wulf William A., Shaw Mary, Hilfinger Paul N. et Flon

Lawrence. Theorie des graphes et ses applications. Dunod,

1958.

[Z 08] Programming Research Group (PRG), Oxford Uni-

versity. The Z notation, 2008. Disponible sur :

http ://www.comlab.ox.ac.uk/archive/z.html (consulte le

07.08.2009).

[Zimmermann 04] Zimmermann Thomas, Weisgerber Peter, Diehl Stephan

et Zeller Andreas. Mining version histories to guide software

changes. ICSE ’04 : Proceedings of the 26th International Confe-

rence on Software Engineering. Washington, DC, USA. IEEE

Computer Society, 2004, p 563–572.

201

Bibliographie

202

Resume

L’activite des organisations qui ont pour mission la mise en application de la le-

gislation est fondee sur l’analyse et la manipulation des textes reglementaires. Par ailleurs,

au vu de la quantite massive d’information traitee au sein de ces organisations, le travail

depasse tres largement les capacites humaines, les amenant a solliciter l’assistance du Sys-

teme d’Information. Une des principales caracteristiques des textes reglementaires est que

ceux-ci sont en perpetuelle evolution. Leur mise en œuvre au sein du Systeme d’Informa-

tion doit etre reexaminee a chacune de ces evolutions afin d’en assurer la coherence et la

conformite. Pour cela nous proposons un modele commun pour la mise en relation des

textes reglementaires et des composants du Systeme d’Information. Ce modele commun

est ensuite enrichi des mecanismes d’analyse des dependances et d’etude d’impact per-

mettant d’identifier et d’evaluer les consequences d’une modification reglementaire sur les

textes reglementaires et sur le Systeme d’Information. Ces problemes, issus du contexte

de la Caisse Nationale des Allocations Familiales (Cnaf), n’ont toutefois pas ete traites

uniquement en fonction du contexte specifique de travail, mais bien en les considerant

comme revelateurs d’une problematique plus large concernant de maniere generale la ges-

tion documentaire et la gestion des Systemes d’Information. Ainsi ces propositions ont ete

validees lors de leur integration dans le Systeme d’Information Documentaire de la Cnaf

mais leur champ d’application peut-etre elargi a d’autres domaines.

Mots-cles: Mesure d’impact, Analyse des dependances, Gestion des connaissances, Sys-

teme d’Information, Document Reglementaire, XML, UML.

Abstract

The activity of organization whose mission is the application of the legislation is

based on analyzing and treatment of legal documents. Considering the enormous quantity

of information that has to be processed by theses organizations, their work overwhelms

human’s capacities making them use the assistance of an Information System. One of the

most important properties of the legal documents is that they are constantly evolving.

Their implementation within the Information System must be updated with each one of

the legal evolution. Therefore our objective is to propose un common model to be used to

manage the relation between legal documents and Information System components. This

model will be enriched by procedures to analyze dependencies and impact studies in order

203

to identify and evaluate all the impacts that a legal update has on the organization : on the

legal documents and on the Information System. This issues initially originated at the Cnaf

– French National Family Benefits Office but were be treated as more general problems

concerning document management and Information System management. Therefore our

proposition was tested while being integrated in the Information System of the Cnaf but

their application field can be enlarged to other organizations.

Keywords: Knoledge Management, Impact study, Collaborative work, Legal document,

Web 2.0, XML, UML

204