Escolar Documentos
Profissional Documentos
Cultura Documentos
THESE
presentee devant
L'INSTITUT NATIONAL DES SCIENCES APPLIQUEES DE LYON
pour obtenir
LE GRADE DE DOCTEUR
en
INFORMATIQUE ET AUTOMATIQUE APPLIQUEES
par
Christian CADIVEL
CONTRIBUTION A LA SPECIFICATION
DES
SYSTEMES D'INFORMATION
Les Rseaux Formels pour la spcification des traitements et application la
rtro conception de codes.
Soutenu le 23/05/1997 devant la Commission d'Examen
Jury :
M
r
Jacques KOULOUMDJIAN, ProIesseur, INSA de LYON, President
M
r
Franois ODIN, P.D.G., Societe SOPRA-G.M.T.
M
r
Bernard ESPINASSE, ProIesseur, Universite AIX-MARSEILLE III, Rapporteur
M
r
Jean-Jacques LESAGE, ProIesseur, ENS CACHAN, Rapporteur
M
r
Yves MARTINEZ, ProIesseur, INSA de LYON
M
r
Claude-Alain SABATIER, Directeur de Projet, Societe DECAN
M
me
Beatrice RUMPLER, Matre de ConIerences, INSA de LYON
M
r
Pascal YIM, Matre de ConIerences, Ecole Centrale de LILLE
M
r
Guy BOULAYE, ProIesseur, INSA de LYON
A ceux qui m'ont instruit.
Liste des enseignants 1
Liste des enseignants 2
Liste des Iormations de DEA
Liste des ecoles doctorales
Remerciements
L'aboutissement d'une these est le succes de toute une equipe. Au cours de cette longue
periode passee au sein de l'equipe de speciIication, maquettage et prototypage de logiciels, le
memoire reIlete peu l'enrichissement retire au contact de chacun. L'enseignement acquis au
sein de cette equipe a ete encore plus precieux que les techniques que l'on saura toujours
retrouver dans les livres et Iait que les anciens ressentent toujours le besoin de revenir
regulierement s'y ressourcer ou y apporter leurs experiences. C'est en ce sens une veritable
Iamille qu'a su creer Monsieur BOULAYE, en privilegiant toujours l'intert de l'equipe, en
partageant ses merites, en diIIusant ses conseils experimentes et visionnaires et aussi en
distillant ses critiques. Qu'il trouve ici les plus sinceres remerciements, pour sa conIiance sans
Iaille, ses encouragements et son soutien Iidele.
J'adresse aussi mes remerciements a :
Monsieur Bernard ESPINASSE, ProIesseur a l'Universite d'AIX-MARSEILLE, qui m'a
spontanement accorde sa conIiance et qui m'a grandement aide a la redaction Iinale de cette
these.
Monsieur Jean-Pierre KELLER qui m'a Iait l'amitie de lire ma these et de me Iaire part de
ses remarques qui m'ont beaucoup eclairees.
Monsieur KOULOUMDJIAN, Directeur du Laboratoire d'InIormatique et de Systeme
d'InIormation de l'INSA de Lyon, qui a accepte de presider le jury de cette these et qui m'a
toujours apporte son soutien durant mes annees d'etude et dont l'equipe m'a toujours reserve
un accueil Iormidable.
Monsieur Jean-Jacques LESAGE, Directeur de recherche a l'Ecole Nationale Superieure
de Cachan, pour avoir accepte de rapporter cette these et dont l'intert pour ces travaux aura
ete pour moi determinant.
Monsieur Yves MARTINEZ, ProIesseur a l'INSA de Lyon, de participer a ce jury.
Monsieur Franois ODIN, President Directeur General de SOPRA GMT, qui m'a Iait
l'honneur de participer au jury de cette these.
Monsieur Daniel PASCOT, ProIesseur a l'Universite LAVAL a Quebec, pour m'avoir reu
et m'encourage dans mes travaux.
Madame Beatrice RUMPLER, Matre de ConIerences a l'INSA de Lyon, pour ses
encouragements et de participer a ce jury.
Monsieur Claude-Alain SABATIER, Directeur de projets, Societe DECAN, qui a guide
mes premiers pas dans le monde proIessionnel et qui a ete a l'origine de ce travail et qui l'a
suivi avec un intert constant malgre nos parcours separes.
Monsieur Hubert TARDIEU, Directeur, Societe SEMA-Group, pour le temps qu'il a
consacre a la lecture de cette these et a me recevoir.
J'adresse un remerciement particulier a Monsieur Pascal YIM, Matre de ConIerences a
l'Ecole Centrale de Lille, qui m'a suivi depuis mon DEA, qui a souvent sacriIie son temps
Iamilial pour m'apporter l'aide la plus concrete dans la Iormalisation de cette idee qui allait
devenir les reseaux Iormels.
Mes pensees vont aussi a ceux qui m'ont ouvert les portes du monde proIessionnel, parmi
lesquels je voudrai citer Monsieur Philippe CHARLOT, Societe ORACLE a Lyon et
Monsieur Robert REGEFFE, President Directeur General de la Societe ADX SoItware.
Je voudrais aussi remercier ma Iamille, ma Mere, mon Pere, mes Freres et Soeurs, ma
Marraine, mes Tantes et Oncles, mes cousins et cousines a qui j'ai beaucoup manque durant
ces longues et eloignees annees d'etudes et dont la conIiance a pour moi ete le plus grand
soutien.
Je remercie aussi mes amis et collegues que la chance m'a Iait rencontrer : Agata,
Chrystele, Isabelle, Sylvie, Jean-Jacques, Isabelle, Abdes, Isabelle, Stephane, Serge, Isabelle,
Michel, Bruno, Beatrice, Jean-Louis, Valerie, Olivier, Agnes, Christophe, Veronique,
Sandrine, Brigitte, John, Corinne, Rolland, Roumila, Kirsty, Guylaine, Patrick, Miryam,
Olivier, Serge, Beatrice, Slim, Jo
e, Philippe, Patrick, Lydie, Pierre-Yves, Frederic, Claude, Philippe, Catarina, Jean-Marie,
Fred, Dominique, Bruno, David, Roman, Bozena, Sylvie, Jonhny, Mohamed, Tahar, Nane,
Pierre, Pierre, Olivier, Jean-Franois, Gyslaine, Gabriel, Daniel, Michel, Paul, Elisabette,
Frederique, Jean-Paul, Eliane, Sylvestre, Helene, Dominique, Christian, Robert, Phillipe,
Michel, Dominique, Guy, Sylvie, Michel, Beatrice, Mario, Benjamin, Anne, Pierre, Johnny,
Samira, Tulio, Franoise, Sad, Christine, Sophie, Jean-Marc, Christophe.
Ma gratitude va aussi aux membres personnels du departement inIormatique de l'INSA,
Madame MARTINEZ, Messieurs Jean LAUTESSE et Robert BALLY, Madame GUILLOT
et Mademoiselle ZAMIT du DED, Mademoiselle PRUD'HOM et Madame BURLAT de
DOC'INSA, que j'ai du mettre a contribution a divers moments de cette these, pour regler des
problemes logistiques de photocopie, de salle, de connexion, de documentation, de carte
d'acces, d'inscription, de logiciels ou de machines ... Je n'oublie pas ceux qui sont restes
anonymes et dont les visages sont en ce moment presents dans mes pensees.
J'adresse enIin un remerciement chaleureux a Madame Christiane RIPON qui a toujours su
arrose la graine d'inIormaticien qui sommeille en nous, en nous rappelant parIois que
l'inIormatique est aussi destine aux utilisateurs.
8
Rsum
La modelisation des systemes d'inIormation distingue classiquement les donnees et les
traitements. En analysant les outils de modelisation des traitements les plus courants on
s'aperoit que ceux-ci s'appliquent mieux aux phases d'analyse et de realisation ou sont trop
ardus pour tre valides par l'utilisateur. Notre objectiI est de chercher un modele de
speciIication de systeme d'inIormation comprehensible par l'utilisateur, mieux adapte a
l'expression des traitements et reutilisable par l'inIormaticien dans le processus de conception.
Nous proposons un modele baptise reseau formel qui tire les avantages graphiques des
reseaux de Petri pour servir de support de dialogue avec l'utilisateur, et qui herite de la
rigueur des langages de programmation par contraintes en decrivant sans ambigute les regles
de gestion du systeme d'inIormation. Les principaux concepts du reseau Iormel sont les
places, les transitions et les contraintes. Les contraintes s'expriment sur les places (qu'on peut
rapprocher de la notion de type abstrait), sur les marquages (deIinissant les contraintes
d'integrites entre les places) et sur les transitions (decrivant les transIormations dynamiques).
Nous illustrons les concepts des reseaux Iormels sur le celebre cas IFIP.
Nous montrons aussi une utilisation des reseaux Iormels dans une demarche de retro
conception de codes decomposee en deux etapes. La premiere etape consiste a traduire les
instructions du programme en elements de reseau Iormel en respectant des schemas de
transIormation elabores pour le langage source. La deuxieme etape consiste a simpliIier le
reseau issu de l'etape precedente en se basant sur des simpliIications Iormelles des contraintes
et sur les connaissances contextuelles d'un expert du domaine. L'application sur une chaine de
3000 lignes de programme en langage RPS a permis d'obtenir une speciIication purgee des
preoccupations techniques introduites lors de la codiIication.
Mots-cls : SpeciIication programme; Reseaux Petri; Langage Formel; Contrainte; Systeme
InIormation; Modelisation; Retro Ingenierie;
9
Abstract
Classically, InIormation System modelling separates data and processes. By analysing the
most commonly used tools oI process modelling, we realize that these models are more
adapted to the analysis and design stage or are too diIIicult to be validated by an end user.
Our aim is to Iind an inIormation system speciIication model understandable Ior the end user,
more suitable Ior process description and reusable by computer practitioners in the design
stages.
We propose a model called formal net which has the graphic advantages oI Petri Net to
support the dialogue with the user, and which inherits the exactness oI constraint
programming by describing without any ambiguity the management rules oI the inIormation
system. The main concepts oI the Iormal net are places, transitions and constraints.
Constraints may be expressed about places (which can approach the notion oI abstract data
type), marking (deIining integrity constraints between places) and transitions (describing
dynamic transIormations). We illustrate the concepts oI Iormal nets on the Iamous case IFIP.
We show the utility oI Iormal nets through the proposition oI a reverse engineering method
broken down into two steps. The Iirst step consists oI translating the instructions oI a
programme into Iormal net elements according to transIormation schemas elaborated Ior the
programming language. The second step consists oI simpliIying the net stemmed Irom the
previous step, based on Iormal constraint simpliIications and on the contextual knowledge oI
an expert in the domain. The application on a chain oI 3000 programme lines in RPS
language led to a speciIication puriIied oI technical aspects introduced during the
programming.
Key words : Programme SpeciIication; Petri Net; Formal Language; Constraint; InIormation
System; Modeling; Reverse Engineering;
10
Sommaire
1. Introduction 12
2. SpeciIication et systeme d'inIormation 14
2.1. La notion de systeme d'inIormation 14
2.1.1. InIormation et donnees 14
2.1.2. Systemes 15
2.1.3. Systemes d'inIormation 16
2.2. Notion de speciIication dans le processus de conception 17
2.2.1. Cycle de vie 18
2.3. Modeles de speciIication 21
3. Evaluation des modeles existants pour la speciIication des systemes d'inIormation 24
3.1. Modeles structures 24
3.1.1. Modele entite association 24
3.1.2. Modele binaire 26
3.1.3. Diagramme de Ilux de donnees 27
3.1.4. SADT 30
3.2. Modeles orientes objet 32
3.2.1. OOA 34
3.2.2. Classe Relation 39
3.2.3. BOOCH 43
3.3. Modeles evenementiels 47
3.3.1. REMORA 47
3.3.2. MCT de Merise 49
3.3.3. Reseaux de Petri a objet 51
3.3.4. Reseaux de Petri de haut niveau 55
3.3.5. CEM 56
3.4. Langages Iormels 59
3.5. Bilan 61
4. Les Reseaux Formels 64
4.1. Un exemple pedagogique : le probleme des reservoirs 65
4.2. DeIinition Iormelle avec le langage Z 67
4.3. SpeciIication du cas IFIP 74
4.4. Conclusion sur les reseaux Iormels 79
5. Une application des RF a la retro conception de codes 81
5.1. La retro conception : introduction 81
5.2. La retro conception de codes 82
5.2.1. Le langage source 83
5.3. Etape 1 : transIormation d'un programme en reseau Iormel. 84
5.3.1. Donnees et variables 84
5.3.1.1. Tables 84
5.3.1.2. Variables 84
5.3.2. Structures de contrle 85
5.3.2.1. Actions 85
5.3.2.2. Sequence 85
5.3.2.3. Si-null 86
5.3.2.4. Si-alors 86
5.3.2.5. Si-alors-sinon 86
5.3.2.6. Branchement 87
5.3.2.7. Edition 88
11
5.3.2.8. Etiquette 88
5.3.3. Instructions elementaires 89
5.3.3.1. AIIectations 89
5.3.4. Instructions relationnelles 90
5.3.4.1. Insertion 90
5.3.4.2. Selection 91
5.3.4.3. ModiIication 91
5.3.4.4. Suppression 92
5.3.5. Marquage initial du reseau 92
5.3.6. Equivalence du programme et du reseau 93
5.4. Etape 2 : simpliIication du reseau 95
5.4.1. EIIets de bord 95
5.4.2. Reduction des sequences simples 95
5.4.3. Autres reductions de sequences 96
5.4.4. SimpliIications basees sur la connaissance du systeme 96
5.5. Conclusion 97
6. Conclusion 99
7. ReIerences Bibliographiques 100
8. Index 114
9. Annexe 1 : Extraits du cas IFIP 117
10. Annexe 2 : Le langage Iormel Z 119
10.1. Types, declarations et ensembles 119
10.2. Relations binaires 120
10.3. Fonctions et expressions 122
10.4. Semantique, liens et schemas 122
10.5. Schemas 124
10.6. Exemple : elements de speciIication d'une bibliotheque 126
10.7. Schemas generiques 129
11. Annexe 3 : Elements de theorie des reseaux 131
11.1. Rdp place/transition 131
11.2. RdP de haut niveau 134
12. Annexe 4 : Schemas d'arcs 138
12.1. Places "Multi-Ensembles" 138
12.1.1. Consommation 138
12.1.2. Production 138
12.1.3. InIormation 139
12.2. Places "Ensembles" 139
12.2.1. Consommation 139
12.2.2. Production 140
12.2.3. InIormation 140
13. Annexe 5 : Grammaire d'un extrait du langage rps 141
14. Annexe 6 : Programme source 144
15. Annexe 7 : Contraintes du reseau Iormel initial 150
16. Annexe 8 : Contraintes du reseau Iormel Iinal 154
Introduction 12
1. Introduction
La modelisation des donnees dans les systemes d'inIormation est un sujet bien connu, avec
des modeles et des outils eprouves, bases aujourd'hui pour la plupart sur le modele relationnel
(|Bouzeghoub 83|, |Finance 86|, |Paul 86|, |Tardieu 89|). En revanche, la speciIication des
traitements et la modelisation de la dynamique restent des problemes diIIiciles, et les
solutions proposees sont diverses |Davis 90|, |Dileva& 88|, |Guyot 86|. Il Iaut bien
reconnatre que la plupart des speciIications de ce type se limitent dans la pratique a un cahier
des charges en langage naturel plus ou moins Iormalise (|Meyer 79|). Un tel cahier des
charges pour le cas IFIP, qui nous servira de reIerence, est donne en annexe 1. Cet exemple
traite la gestion de l'organisation d'une conIerence internationale, et les diIIerentes clauses
precisent les regles de selection des articles, d'attribution a des lecteurs, et de repartition des
sessions. La speciIication rigoureuse du cas IFIP pose des problemes non triviaux, et a ete
abordee par de nombreux auteurs, sous des angles diIIerents (|Sibertin-Blanc 91a|, |Pascot&
88|, |Pascot& 91|, |Rolland 82|, |Perrin& 90|, |Paraire 91|).
Les modeles semi Iormels, pour la plupart graphiques, sont tres utilises dans la pratique :
diagrammes de Ilux de donnees (|Gane& 79|), SADT |IGL 89|, |Lissandre 90|, |Lissandre
86|, REMORA |Rolland 86|. Le succes de ces modeles est principalement d a leur simplicite
: la lisibilite d'un modele graphique simple est une excellente base de dialogue entre les
utilisateurs et les inIormaticiens, plus structuree qu'un cahier des charges en langage naturel.
Neanmoins, un travail important reste a Iaire, notamment sur les traitements qui sont souvent
eux-mmes speciIies inIormellement par une simple annotation en langage naturel sur le
schema, ou parIois dans un pseudo code structure. Les methodes basees sur les objets
permettent d'atteindre un degre de precision plus Iin, et une uniIication du modele des
donnees et des traitements. Ainsi, BOOCH |Booch 91| et HOOD |Courvoisier& 90|, pour ne
citer qu'elles, ont suscite un intert croissant ces dernieres annees. Neanmoins, ces methodes
semblent se positionner dans le cycle de vie du logiciel plus pres de la conception que de la
speciIication : en eIIet, le niveau de detail doit prendre en compte des aspects de
l'implantation eIIective pour tre complet, et la nature du langage inIormatique choisi
intervient a une certaine etape de la methode. A l'inverse, les langages Iormels bases sur la
theorie des ensembles comme Z |Abrial 84| ou VDM |Jones 93| autorisent un tres haut
niveau d'abstraction. Il Iaut cependant reconnatre que les bases mathematiques requises ne
sont pas negligeables, et qu'un utilisateur non initie aura du mal a saisir les subtilites d'une
speciIication Iormelle.
D'un autre cte, la plupart des modeles ne sont pas capables de decrire dans un Iormalisme
unique (un seul schema) a la Iois les donnees et les contraintes associees, les traitements
modiIiant ces donnees, et le comportement dynamique du systeme en reaction a des
evenements. Typiquement, Merise regroupe trois modeles correspondant chacun a l'un de ces
aspects du systeme d'inIormation. Le probleme de cette approche multi-modeles reside dans
l'integration des modeles entre eux pour obtenir une speciIication coherente. Cette integration
n'est pas toujours deIinie precisement, ou repose sur un langage imperatiI sous-jacent.
L'objectiI que nous allons poursuivre dans ce travail consiste a deIinir un modele
permettant de speciIier dans un formalisme unique et lisible les composantes donnees,
processus et dvnamique dun svsteme dinformation. Nous souhaitons egalement que ce
modele presente les qualites d'abstraction, de precision et de richesse Ionctionnelle requises
pour un outil de specification. Notre but ici n'est donc pas de decrire une methode globale
prenant en compte les aspects organisationnels ou physiques, ni de deIinir un outil complet de
conception ou d'implantation.
Introduction 13
La puissance de notre approche reside dans l'integration de l'integration des aspects a la Iois
statiques et dynamiques d'un systeme d'inIormation dans une Iormalisme homogene. En eIIet,
en exprimant des contraintes sur les places, les marquages et les transitions et en distinguant
les types d'arc, nous decrivons precisement et completement les structures et comportements
du systeme. La parente des reseaux Iormels avec les reseaux de Petri de Haut Niveau est
claire, neanmoins notre but principal est de speciIier de la maniere la plus simple et precise
possible un systeme d'inIormation. Aussi, on trouvera une plus grande variete d'arcs dans les
reseaux Iormels, et nous generons une speciIication complete en langage Z, sans nous
attacher a l'analyse structurelle du reseau (invariants, ...).
AIin de comprendre des applications ecrites dans un langage diIIere rps associe au
SGBDR Oracle, nous deIinissons une demarche de retro conception des traitements
s'appuyant sur les reseaux Iormels, aIin de produire des speciIications abstraites purgees des
instructions liees a leur mise en oeuvre. Cette demarche qui admet l'existence du modele de
donnees est decomposee en deux etapes. La premiere consiste a retranscrire
systematiquement les instructions du programme en elements de reseau Iormel selon des
schemas de transIormation elabores pour le langage source. Dans le deuxieme temps
l'intervention d'un expert permet de simpliIier le reseau Iormel en resolvant Iormellement les
contraintes et en apportant des connaissances contextuelles. Mme si les aspects d'ergonomie,
de dialogue, de perIormance et d'organisation disparaissent dans le reseau Iormel Iinal, celui-
ci est suIIisant pour redevelopper entierement les applications dans un nouveau langage selon
de nouvelles conventions.
En proposant les reseaux Iormels pour la speciIication de systeme d'inIormation, nous
contribuons par la mme occasion a une demarche de retro conception de code supportee par
notre Iormalisme.
Dans un premier temps, nous deIinirons les trois composantes d'un systeme d'inIormation,
ainsi que les qualites attendues d'un modele de speciIication, en situant la phase de
speciIication dans le cycle de vie du systeme d'inIormation. Nous deIinirons deux reIerentiels
d'evaluation aIin de comparer les modeles classiques dans le contexte particulier de la
speciIication d'un systeme d'inIormation.
Les modeles structures, orientes objets, evenementiels et les langages Iormels seront
ensuite decrits et evalues dans nos reIerentiels, en mettant en valeur leurs Iorces et leurs
Iaiblesses pour la speciIication d'un systeme d'inIormation. Le cas IFIP (ou un sous-
ensemble) sera traite dans diIIerents de ces Iormalismes.
Cette etude nous amenera a deIinir les reseaux formels, bases sur les reseaux de Petri de
haut niveau, etendus par de nouvelles varietes d'arcs, et des contraintes sur les places, les
marquages et les transitions. Le comportement et la semantique de ce nouveau modele seront
deIinies Iormellement, et une procedure de generation d'une speciIication Z a partir d'un
reseau Iormel sera decrite. Nous donnerons le reseau Iormel correspondant a la speciIication
complete du cas IFIP.
Nous decrirons enIin une application des reseaux Iormels a un cas reel de retro conception
(orientee surtout sur les traitements) d'un systeme d'inIormation. A partir d'un programme
ecrit en RPS/SQL, nous retrouverons une speciIication Iormelle a l'aide de regles de
transIormation syntaxiques simples que nous justiIierons. Nous simpliIierons ensuite cette
speciIication par des regle de pliage sur le reseau.
SpeciIication et systeme d'inIormation 14
2. Spcification et systme d'information
Le systeme d'inIormation est de plus en plus le coeur vital des entreprises |Tardieu& 91|. Il
ne doit pas cependant tre conIondu avec le systeme inIormatique qui n'est qu'un composant
d'un systeme complexe organise en vu de repondre a un objectiI. Du point de vue de
l'utilisateur, il importe avant tout que ce systeme intervienne de Iaon adequate au sein de son
organisation. Le systeme d'inIormation est a la Iois modele et partie integrante de
l'organisation, et du point de vue du concepteur du systeme inIormatique ce qui importe c'est
l'etude de la correspondance complexe de l'inIormation et de l'organisation. C'est la
complexite de cette organisation qu'il importe en priorite de comprendre avant de se precipiter
pour resoudre inIormatiquement un probleme qui peut-tre ne se pose pas si l'on se reIere aux
projets de cette organisation. Cette conIusion entre systeme d'inIormation et systeme
inIormatique nous amenera donc a deIinir ce que l'on entend par la notion de systeme
d'inIormation. Nous presenterons ensuite la notion de cycle de vie et les diIIerentes phases
intervenant dans la conception d'un systeme d'inIormation. Ainsi nous introduirons notre
objectiI de rechercher un modele de speciIication, particulierement adapte pour la description
des traitements, en vu de concevoir, a travers l'etude du langage naturel avec le cas IFIP.
2.1. La notion de systme d'information
DeIinir ce qu'est un systeme d'inIormation est une entreprise delicate car il semble que la
deIinition varie chez chaque auteur, en Ionctions des choix personnels, en privilegiant
certains aspects. AIin de preciser notre objet, nous abordons la notion de systeme
d'inIormation a travers les diIIerents termes qui le composent et courants qui l'etudient. Cette
presentation nous conduira a deIinir un reIerentiel d'evaluation pour les modeles de
description que nous etudierons par la suite.
2.1.1. Information et donnes
Une donnee peut tre vue simplement comme un element d'un ensemble de valeurs. Cet
ensemble peut tre structure de diIIerentes manieres : par exemple le produit cartesien
d'ensemble conduit a la notion usuelle de tuple et de relation. D'un point de vue inIormatique,
un modele de donnees comporte habituellement deux aspects |Aho& 89|:
les valeurs pouvant tre attribuees aux objets. Par exemple, bon nombre de modeles de
donnees contiennent des objets qui ont des valeurs entieres. Cet aspect du modele de donnees
est statique; il nous inIorme sur les valeurs que peuvent prendre les objets.
les operations sur les donnees. Par exemple, nous appliquons habituellement aux
entiers des operations telles que l'addition. Cet aspect du modele est dynamique; il nous
inIorme sur les moyens mis a notre disposition pour changer des valeurs et pour creer de
nouvelles valeurs.
Plus generalement l'information constitue la matiere premiere des SI et sa deIinition se
conIond parIois avec celle de donnees. Si nous prenons l'etymologie du mot inIormation, du
latin informatio, qui designe l'action de donner une Iorme, l'usage des mots donnee et
information est comprehensible en inIormatique au sens ou l'inIormation traite par un
ordinateur est denuee de sens.
SpeciIication et systeme d'inIormation 15
Du point de vue de la theorie de l'inIormation, nee aux Etats-Unis vers 1940, deux visions se
distinguent a l'origine par leurs motivations. Les travaux de base ont ete l'oeuvre de C.E.
Shannon, mais ses travaux etaient domines par des considerations tres materielles de
telecommunication. Le mathematicien Wiener a aborde la question de maniere plus
desinteressee (c'est-a-dire independante d'une application) en introduisant pour la premiere
Iois le mot cybernetique exprimant le lien avec la notion d'autoregulation (Ieedback) de
l'inIormation. C'est ce paradigme energetique, qui servit de reIerence aux premiers pas des
sciences de l'inIormation, de la communication et de l'organisation |Le Moigne 77|,
symbolise par la Iormule :
i Log
2
(1/p(e)) ou i est la quantite d'inIormation, e un evenement et p(e) la probabilite de
realisation de cet evenement.
Ainsi est inIormation pour un systeme tout evenement reconnu par lui. La notion
d'inIormation est aussi liee a celle de communication : elle ne peut tre deIinie
independamment de celle d'un systeme recepteur (humain ou Iormel).
Ainsi contrairement a une donnee, une inIormation modiIie l'etat du systeme. Nous allons
donc maintenant developper cette notion de systeme.
2.1.2. Systmes
Il convient de distinguer clairement l'approche Iormelle (analytique) et l'approche systemique
de la deIinition d'un systeme.
Un svsteme formel |Benzaken 91|, |Delahaye 88| est donne par un langage sous-jacent (un
mecanisme svntaxique de construction de phrases), un ensemble particulier de phrases (les
axiomes) et un processus de generation qui construit de nouvelles phrases a partir d'un
ensemble de phrases (regles dinference). Les phrases generees a partir des axiomes par le
processus de generation (en une ou plusieurs etapes) sont appelees les theoremes. Un systeme
Iormel peut modeliser une certaine interpretation de la "realite". Une interpretation consiste a
aIIecter a chaque phrase bien Iormee du systeme Iormel une valeur de verite. Un systeme
Iormel est correct si tous les theoremes sont des phrases vraies dans l'interpretation.
Dualement, il est complet si toutes les phrases vraies sont des theoremes. EnIin il est
decidable s'il existe un algorithme permettant de decider en un temps Iini si une phrase est un
theoreme ou non. Par exemple le systeme Iormel modelisant la logique est un archetype
classique. Malgre le nombre de systemes Iormels existant, il est diIIicile de modeliser les
interactions dynamiques dans un systeme "reel" : la notion d'interpretation elle mme ne
capture pas ce type d'inIormation.
Si du point de vue analytique, un systeme est un assemblage structure, d'un point de vue
systemique, c'est une totalite dvnamique d'elements dont l'interaction produit des proprietes
d'integration nouvelles, non reductibles a celles de ses composants pris isolement |Walliser
77|. De plus, un systeme est organise dans un but |Le Moigne 77|, |De Rosnay 75|, |Pascot
95|. L'approche systemique s'oppose donc a une vision trop atomistique ou statique de l'objet
etudie. Elle vise une meilleur adequation des moyens aux objectiIs par une approche plus
synthetique dans un langage unitaire. A un instant donne le systeme est dans un etat qui
evolue dynamiquement en Ionction des evenements. Ces evenements peuvent provenir de
l'environnement du systeme (systemes ouverts) ou des interactions internes entre les
diIIerents constituants du systeme (systemes Iermes).
Un modele est un systeme abstrait dont la structure et le comportement sont en
correspondance avec le systeme concret a modeliser. Une propriete du systeme concret est
dite reelle tandis qu'une propriete du systeme reel est dite Iormelle. Un modele est parfait si et
SpeciIication et systeme d'inIormation 16
seulement si toute propriete du modele est reelle et il est complet si et seulement si toute
propriete du systeme est Iormelle.
L'approche systemique se caracterise donc par la demarche qu'elle propose et non par
l'objet etudie. Elle s'applique aussi bien a des systemes sociologiques, economiques,
industriels ou inIormatiques. Dans le contexte des systemes inIormatiques, nous nous
interessons plus particulierement aux systemes d'inIormation.
2.1.3. Systmes d'information
Dans l'etude de la construction des programmes, |Finance 79| utilise la notion de systeme
d'inIormation comme un calcul des predicats du premier ordre, egalitaire et type. L'intert de
cette deIinition reside dans l'existence d'un cadre Iormel reposant sur des bases theoriques
classiques et solides associe a un langage de description et de construction de l'univers de
resolution des problemes. Neanmoins, plutt que de nous interesser aux concepts d'ensembles
structures de donnees statiques par une approche analytique comme les systemes Iormels,
nous choisirons dans la suite une approche plus systemique prenant en compte les aspects
dynamiques de l'inIormation. Dans ce sens nous nous rapprochons des hypotheses de base de
la methode Merise |Espinasse& 93|, |Tardieu& 95|.
Plus precisement nous considererons trois composantes principales des systemes
d'inIormation :
La composante statique represente la structure et la composition des donnees du
systeme d'inIormation ainsi que les contraintes qu'elles doivent respecter. Elle Iournit
une image d'un etat coherent du systeme a un instant donne.
La composante dvnamique modelise les changements d'etat du systeme en reaction
aux evenements.
La composante des processus decrit les traitements permettant de modiIier ou de
calculer de nouvelles valeurs dans le systeme.
Certains auteurs regroupent la composante dynamique et la composante des processus. Nous
conserverons cette distinction aIin de discriminer les diIIerents modeles que nous etudierons.
Dans ce but, nous representerons chaque modele dans un espace a trois dimensions ou chaque
axe correspond a une des composantes precedentes. L'eloignement de la projection d'un point
sur un axe par rapport a l'origine denote l'ecart entre le modele associe au point et son
adequation a la composante representee par l'axe. L'origine represente donc le point ideal
presentant la plus Iorte interaction avec les trois axes. Par exemple, on peut situer le langage
naturel assez eloigne de l'origine dans le sens ou il permet de decrire les trois composantes
mais avec un degre de pertinence relativement Iaible.
SpeciIication et systeme d'inIormation 17
processus
donnes
dynamique
Langage Naturel
Figure 1: Evaluation du langage naturel sur le reIerentiel dobfectif.
Une telle Iigure resulte Iorcement d'une evaluation qualitative que nous discuterons en detail
plus loin. Notre objectiI est d'exhiber un modele qui soit le plus proche possible de l'origine,
c'est-a-dire, adequat par rapport aux trois composantes. Nous placerons sur cette Iigure de
maniere un peu abusive aussi bien des modeles que des noms de methodes : dans ce dernier
cas nous nous interessons essentiellement au modele sous-jacents a la methode.
D'autre part notre objectiI est speciIiquement de trouver un modele approprie a la phase de
speciIication dans le processus de conception d'un systeme d'inIormation (et non une methode
generale) |Abrial 85|. Nous allons maintenant preciser ce concept de speciIication.
2.2. Aotion de spcification dans le processus de conception
La methode Merise |Tardieu& 95| distingue trois cycles dans la construction d'un systeme
d'inIormation. Le cycle d'abstraction isole a un niveau speciIique les elements signiIicatiIs
contribuant a la description d'un systeme coherent, en ignorant les details. On trouve sur cet
axe les niveaux conceptuel, organisationnel et physique aussi bien pour les traitements que
pour les donnees. Le cycle de decision regroupe les choix qui doivent tre pris a certaines
etapes determinantes de la construction du systeme. Par exemple l'aIIectation des ressources
precede le planning du deroulement du chantier. Le cycle de vie decrit les etapes qui
permettent de passer d'une description de ce qui doit tre Iait a la realisation Iinale.
SpeciIication et systeme d'inIormation 18
ABSTRACTON
DECSON
VE
conceptuel
organisationnel
physique
technique
organisation
gestion
identification
conception
mise en exploitation
dcoupage en lots
affectation de ressources
planning
dveloppement
contenu
donnes traitements
gestation dveloppement exploitation
schma directeur
tude pralable
tude dtaille
tude technique
production de logiciels
mise en oeuvre
maintenance
Figure 2 : Cycles du SI.
AIin de situer precisement la demarche de speciIication, nous allons maintenant developper
plus particulierement l'axe du cycle de vie.
2.2.1. Cycle de vie
Le modele en cascade |Boehm 76| a ete l'une des premieres Iormalisations decrivant de
maniere detaillee le cycle de vie d'un logiciel. A chaque etape correspond une activite precise
accompagnee d'une procedure de validation. Si la validation reussit, on passe a l'etape
suivante, sinon on revient a l'etape precedente.
tude pralable
validation
spcification
validation
conception
prliminaire
vrification
conception
dtaille
vrification
codage
tests unitaires
intgration
vrification
installation
recette
exploitation
maintenance
revalidation
Figure 3 : Cycle de vie en cascade.
SpeciIication et systeme d'inIormation 19
Dans un systeme d'inIormation, l'etude prealable comprend le recueil des processus de
gestion et des operations associees, une identiIication des objets et de leurs relations aIin de
Iormaliser le niveau conceptuel des donnees et des traitements. Il a aussi pour objectiI de
cerner les dysIonctionnements aussi bien sur le plan de gestion, que sur celui de
l'organisation, que sur celui des solutions techniques. La phase de specification est a la
charniere de l'etude prealable et de la conception preliminaire. Elle decrit le plus precisement
possible le probleme (et non la solution). Nous reviendrons plus loin en detail sur cette phase
et sa mise en oeuvre speciIique au systeme d'inIormation. Nous ne detaillons pas les etapes
suivantes qui sont d'un intert moins direct dans notre contexte.
Cependant, cette demarche purement descendante n'est pas adaptee a des retours arrieres
sur plusieurs niveaux et entrane de ce Iait un cot des corrections d'autant plus eleve que
l'origine de l'erreur se situe dans les premieres etapes. Les developpements importants ne sont
que tres rarement realises de Iaon lineaire. Pour optimiser le temps de realisation, on a
recours a un decoupage permettant de Iinaliser les composants logiciels en parallele plutt
qu'en serie.
Dans cet esprit, le "cycle de vie en V" est une proposition pour limiter l'aspect lineaire du
cycle de vie en cascade et reprend ses phases en mettant Iace a Iace et a un mme niveau les
phases de speciIication et validation, conception et integration, realisation et test.
spcification
conception
ralisation
codage
test
intgration
recette
DSB : Document de Spcification des Besoins
MU : Manuel d'Utilisation
PV : Plan de Validation
DCP : Document de Conception Prliminaire
P : Plan d'ntgration
DTV : Document de Tests de Validation
DCD : Document de Conception Dtaille
DT : Document de Tests d'ntgration
DTU : Document de Tests Uitaires
DCP
P
DTV
MU mis jour
SPG : Spcification du Procd de Gnralisation
DSB
MU
PV
DCD
DT
DTU
Listages
PV
DTV
P
DT
DTU complt
Listages mis jour
DT complt
SPG
DTV complt
DTU
DCD
DCP, MU
DSB, MU
Figure 4 : Cycle de vie en "V'.
Cette representation a l'avantage de mettre en evidence pour chaque niveau un parallelisme
entre les objectiIs de proposition et de satisIaction, par exemple la speciIication et la recette
Iinale. Forse considere que le degre de diIIiculte decrot progressivement de haut en bas sur le
modele |Forse 89| : dans ce contexte, comme dans celui du modele en cascade, la phase de
specification est donc determinante pour la reussite du profet. D'autres modeles comme le
cycle de vie en spirale |Williams 88| ont ete proposes : on pourra trouver une bonne synthese
sur ce theme dans |Calvez 91|.
Dans un point de vue tout a Iait diIIerent, on peut s'interesser plus particulierement aux
interactions entre le "client" et le "prestataire de services" dans le cycle de vie. Le modele
contractuel |Cohen& 86| considere chaque phase de developpement comme un contrat entre
ces 2 parties, et le passage d'une phase a la suivante est caracterise par un accord du client.
SpeciIication et systeme d'inIormation 20
informeI
besoin
formeIIe
spcifciation
de conception
proposition
analyse
modle formel
analytiquement
adquat
besoins du client
acceptable
comportement
besoin conception
d'impImentation
proposition
quivalent ?
comportement
conception
et ralisable ?
adquate
fonctionnelle
architecture
construction
schma
reproductible ?
ralisable ?
besoin ralisation
adquat ?
comportement
CLENT FOURNSSEUR PHASE
CONCEPTON
ANALYSE
REALSATON
oui
preuve
non
oui
preuve
non
preuve
oui
non
oui
non
non
oui
non
oui
Figure 5 : Modele contractuel.
Ce modele se base avant tout sur un cadre juridique de prestation et non sur une technique
de realisation. Il est interessant de souligner que la specification peut tre vue comme une
etape contractuelle entre lanalvse et la conception.
Quel que soit le cycle de vie, nous voyons qu'une phase intermediaire de speciIication
apparat au tout debut du cycle de production de logiciel, entre l'expression des besoins,
domaine d'intervention de l'utilisateur, et la conception, domaine d'intervention de
l'inIormaticien |Habrias 93|. Cette phase est capitale admettent la plupart des auteurs, car plus
l'origine d'une erreur se situe en amont du cycle de vie, plus le cot de correction est eleve
|Habrias 94|. Ainsi la qualite de la phase de speciIication determine a la Iois l'eIIicacite de
realisation des etapes suivantes et les interaction entre le client et le Iournisseur, ce qui justiIie
notre intert particulier pour cette etape |Gonin& 92|, |Gogue& 83|, |Soberman 92|,
|Sommerville 88|, |Theron 88|. Bien que le modele en V soit le plus largement reconnu, il
existe une certaine inconsistance dans la terminologie pour caracteriser les activites, les
ressources en entree, les produits en sortie et les limites des phases d'un cycle de vie. La phase
de speciIication ne designe pas toujours la mme chose d'un auteur a l'autre et s'etend de
l'analyse a la conception selon la deIinition que chacun lui donne |Davis 90|, |Blank& 83|.
Nous allons donc examiner maintenant ces notions plus precisement, independamment d'un
cycle de vie particulier.
SpeciIication et systeme d'inIormation 21
2.3. Modles de spcification
Nous avons dit qu'un modele de speciIication ne doit en aucun cas decrire la maniere de
realiser la solution aIin de laisser a ce stade le plus grand nombre de choix possibles pour la
conception et d'tre independant d'une technologie. Une speciIication doit donc tre abstraite.
Par contre il est utile pour preparer eIIicacement la phase de conception d'avoir la plus grande
richesse fonctionnelle possible, au sens de la Iinesse du niveau de detail atteignable dans le
modele. On souhaite pouvoir deduire de la speciIication le maximum d'inIormations utiles
pour la conception : il est donc important de ne pas laisser dans l'ombre certains traitements
(calculs, transIormations, etc.). EnIin il ne semble pas acceptable de laisser subsister dans la
speciIication de trop grandes ambigutes. Dans ce sens, la speciIication doit tre precise
|Acsiome 89|, |Souquieres 89|. On peut donc construire un outil d'evaluation similaire a celui
de la Iigure 6 ou l'eloignement sur un axe par rapport a l'origine denote le deIaut d'un modele
par rapport a la qualite correspondante.
Abstraction
Prcision
Richesse fonctionnelle
Langage Naturel
Pseudo-code
Figure 6 : Evaluation du langage naturel et pseudo code sur le referentiel qualitatif.
Ainsi un modele qui se trouverait trop eloigne du centre dans ce repere ne pourrait tre
considere comme un bon modele de speciIication. A titre d'exemple, nous allons detailler la
justiIication de la position du langage naturel (LN) vu comme modele dans ce repere.
Le langage naturel est encore tres utilise pour decrire un probleme pour des raisons a la Iois
culturelles (tout le monde comprend le LN, aussi bien l'inIormaticien que l'utilisateur) et
pragmatiques (on a la liberte du degre de detail desire et l'emploi du LN dans un corps de
metier respecte souvent un style qui limite les interpretations ambigues). Nous trouverons des
tentatives pour exploiter des expression en LN dans |Belkhouche 91|, |Bouzeghoub 86a, b|,
|Rolland& 91b|, |Deweze 81|.
La theorie des grammaires casuelles, popularisee par Fillmore dans le domaine
inIormatique, tente de structurer les phrases du LN par le concept de cas selon lequel la
representation proIonde d'une phrase est composee d'une modalite et d'une proposition. La
modalite contient des inIormations sur le temps, le mode, la negation et l'aspect. La
proposition s'articule autour du verbe, considere comme element central de la phrase et
porteur des relations semantiques qui relient les autres elements. On note :
S M P et P J C
1
C
2
... C
n
ou M est le mode et P une proposition et J est un
verbe et
Ci
est un complement du verbe.
SpeciIication et systeme d'inIormation 22
Apres l'engouement rencontre pour les grammaire casuelles dans les etudes de genie
logiciel pour oIIrir aux inIormaticiens des outils plus perIormants pour cerner les expressions
des besoins des utilisateurs, certains auteurs ont montre les limites de cette technique liee au
caractere subjectiI des concepts mis en oeuvre |Serbat 81|.
La methode KOD |Vogel 88| permet d'elaborer un modele objet a partir d'entretiens avec des
utilisateurs. Plus precisement, elle propose d'eliciter la connaissance d'un domaine autour de
trois modeles nommes modele pratique, cognitiI et inIormatique, correspondant
respectivement a trois paradigmes : representation, action et interpretation. Le schema ci-
dessous represente les trois etapes de la methode ainsi que les composants respectiIs de
chacune des etapes.
base d'noncs
base de connaissances
base d'informations
EXTRACTION DES
INFORMATIONS
EXTRACTION DES
CONNAISSANCES
EXTRACTION DES
ENONCES
dclaration action description
base de protocoles
rgles
mthodes
objets
schma
d'interprtation
actinomies taxinomies
schmmes actmes taxmes
Figure 7 : Les trois niveaux de representation de la connaissance.
Neanmoins, Bertrand Meyer dans |Meyer 79| et |Meyer 85| a propose une classiIication des
principaux ecueils rencontres dans la speciIication en LN :
le bruit : element du texte n'apportant d'inIormation sur aucune des caracteristiques du
probleme.
le silence : caracteristique du probleme a laquelle ne correspond pas d'element du
texte.
la contradiction : element du texte deIinissant de Iaon incompatible une mme
caracteristique du probleme.
la surspeciIication : element du texte ne correspondant pas a une caracteristique du
probleme mais a des caracteristiques d'une solution possible.
l'ambigute : element du texte permettant de comprendre une caracteristique du
probleme de plusieurs Iaons possibles.
l'anticipation : element du texte utilisant des caracteristiques du probleme deIinies plus
loin dans le texte (appele aussi reIerence en avant).
la realisabilite : element du texte deIinissant des caracteristiques idealistes,
diIIicilement atteignables ou presentant un cot de realisation excessiI.
Sur le repere d'evaluation, le LN est donc proche de l'origine sur l'axe de l'abstraction mais
eloigne sur les axes de richesse Ionctionnelle et precision (voir Iigure 6). Il nous semble donc
SpeciIication et systeme d'inIormation 23
clair qu'il ne peut pas tre retenu comme modele de speciIication respectant les qualites
voulues. Nous le situons donc plutt comme un outil privilegie dans l'etude prealable. On
pourra trouver en annexe 1 l'etude prealable en LN correspondant au cas IFIP qui servira
d'exemple type pour illustrer les modeles que nous developperons dans le prochain chapitre.
A l'oppose, la description d'un probleme dans un pseudo code imperatiI manque clairement
de la qualite d'abstraction telle que nous l'avons deIinie. Une telle description se situe donc
plutt dans l'etape de conception preliminaire.
Dans la suite nous situerons les modeles classiques dans notre repere d'evaluation d'une
maniere similaire a celle que nous avons suivi pour le LN. Cette evaluation nous permettra de
comparer ces modeles par rapport a notre objectiI de speciIication des systemes
d'inIormation.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 24
3. Evaluation des modles existants pour la spcification
des systmes d'information
Notre objectiI Iinal est de proposer un modele de speciIication global. Nous allons ici
examiner l'adequation de modeles connus pour ce probleme. Bien entendu, il ne s'agit pas ici
de juger ces modeles dans l'absolu : la plupart n'ont pas ete conus dans ce but speciIique.
Notamment, plusieurs de ces modeles Iont partie de methodes d'analyse et de conception, et
leur eloignement du centre de nos reIerentiels d'evaluation est donc normal.
La redaction d'un texte etant Iorcement lineaire, nous avons d choisir un ordre arbitraire
pour la presentation des modeles. Nous distinguerons donc trois categories : les modeles
"structures", les modeles orientes objet et les modeles evenementiels, pour la plupart bases
sur les reseaux de Petri. Cette distinction est pratique pour notre expose, bien que
l'intersection entre ces categories ne soit pas vide. Pour chaque categorie, nous examinerons
en general les modeles du plus simple au plus sophistique.
Pour chaque modele, nous decrirons brievement son Iormalisme et son principe de
Ionctionnement que nous illustrerons par une application au cas IFIP, puis nous le situerons
dans nos deux reIerentiels d'evaluation. Repetons que cette evaluation est qualitative et sujette
a discussion. Neanmoins, nous tenterons de justiIier au maximum notre point de vue. Pour
certains Iormalismes particulierement simples ou classiques ou similaires a un autre
Iormalisme developpe en detail, notre expose sera plus rapide (en particulier, nous ne
decrirons pas le cas IFIP) aIin de ne pas alourdir la presentation.
3.1. Modles structurs
Les modeles structures adoptent pour la plupart une approche analytique. Nous regroupons
dans cette categorie des modeles bases sur la decomposition des donnees comme le modele
entite association ou bases sur la decomposition des traitements comme les schemas SADT.
3.1.1. Modle entit association
Les donnees sont par deIinition les elements les plus stables des systemes d'inIormation, elles
sont souvent de ce Iait les premieres modelisees. Les premiers modeles de donnees
provenaient de la reproduction directe des systemes de Iichiers utilises dans les entreprises.
Ceux-ci etaient Iortement lies a des considerations materielles : modele reseau (CODASYL)
et modele hierarchique (IMS) |Pichat& 90|, |Delobel& 82|, |Miranda& 86|. Le souci de
maintenir la coherence des inIormations manipulees a conduit a la recherche de modeles plus
eIIicaces. Des representations plus proches de l'utilisateur ont vu le jour avec les modeles
relationnels |Codd 70|, |Chen 76|. Ces modeles permettent une richesse de representation qui
depasse le cadre purement statique car les contraintes qu'ils permettent de representer
interagissent avec les traitements a tel point que certaines demarches preconisent de conduire
la modelisation des traitements a partir des donnees. Un grand nombre de concepts relatiIs
aux donnees (dependance Ionctionnelle, cardinalite, unicite, ...) sont integres sur un mme
schema tout en oIIrant un cadre operationnel (SGBD), ce qui les Iait assimiler a de veritables
modeles semantiques |Tabourier 88|, |Bres 90|, |Huang 93|, |Kouloumdjian& 89|, |Le& 88|,
|Morejon 95|, |Paraire 92|, |RochIeld 88|, |RochIeld 90|, |Sibertin-Blanc 88|, |Mounyol 95|.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 25
Le modele relationnel utilise la notion mathematique de relation pour decrire les elements
du systeme reel. Le Iormalisme individuel s'articule autour de trois concepts Iondamentaux :
l'entite, l'association et l'attribut. Un attribut est une inIormation elementaire conIorme au
choix de gestion d'une entreprise. Une entite est un element de l'entreprise pourvue une
existence propre. EnIin, une association est une relation entre entites depourvue d'existence
propre. Les attributs sont regroupes de maniere a Iormer des ensembles independants. Un
attribut ne doit Iigurer que sur une entite et une seule. La notion d'identiIiant permet de
designer sans ambigute une occurrence d'une relation.
Les contraintes statiques (contraintes d'inclusion, d'exclusion, de totalite, de
partitionnement, d'egalite, ...) ne sont pas toujours representees graphiquement ; elles doivent
tre respectees par tous les etats du systeme |Habrias& 88|, |Morejon 95|, |Tabourier 90b|.
Nous presentons le Iormalisme graphique du modele conceptuel de donnees (MCD) de
Merise (version etendue |Panet& 94|, |RochIeld& 88|, |Tabourier 90a|, |RochIeld& 89|,
|Morand& 92|) pour representer le modele entite association du cas IFIP. Une entite est
representee par un rectangle et une association par un ovode. Une entite et une association
peuvent tre reliees par un arc dont l'annotation denote la cardinalite minimale et maximale
de l'entite dans l'association. Deux associations peuvent tre reliees par un arc special
exprimant l'exclusion : par exemple un Auteur ne peut pas tre Referee de son propre
Papier. De plus, on peut avoir des liens de sous typage entre deux entites et des liens
d'inclusion entre deux associations ...
NumroPapier
DateRception
Papier
Auteur
Confrence
StatutPapiernvit
DateRemiseDfinie
Papiernvit
StatutPapierSoumis
PapierSoumis
Numro
Nom
Prnom
AdressePersonnelle
AdresseProfessionnelle
E-mail
Personne
NoteSujet
NoteBibliographie
NotePapier
Referee
MembreComitPGM
3,n
0,n
1,n
0,n
Prsentateur
0,n
1,1
1,n
0,n
Figure 8 : MCD (etendu) Merise.
Il est clair que le modele entite association ne modelise ni les aspects dynamiques, ni les
processus (bien que les contraintes d'integrite aient un impact sur la dynamique du systeme,
puisqu'elles deIinissent les etats admissibles). Nous situons donc ce modele (represente ici par
le MCD Merise) dans le plan dynamique / processus, puisque son adequation aux donnees est
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 26
maximale (rappelons que la coordonnee d'un point sur un axe represente l'ecart du modele
avec sa capacite a representer la composante associee a l'axe).
processus
donnes
dynamique
MCD Merise
Figure 9 : Evaluation du MCD Merise sur le reIerentiel d'objectiI.
En tant que modele de speciIication, le MCD de Merise permet de representer les donnees
avec un bon degre de precision, et une abstraction satisIaisante. Il existe des outils qui
permettent de generer automatiquement le schema de description d'une base de donnees
(AMC*Designer par exemple, ...). On ne peut donc pas mettre en cause la richesse
Ionctionnelle au sens ou nous l'avons deIinie.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
Figure 10 : Evaluation du MCD Merise sur le reIerentiel qualitatiI.
Il ressort donc de cette analyse que les modeles entite association sont de bons modeles de
speciIication, mais malheureusement tres orientes par rapport aux donnees.
3.1.2. Modle binaire
Le modele binaire utilise comme le modele relationnel le concept de relation en se limitant
aux relations binaires (un relation binaire est un ensemble de couples). Plus precisement, on
deIinit une relation binaire comme deux Ionctions (multivoques) inverses l'une de l'autre.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 27
Deux Iormalismes existent pour le modele binaire, celui de J.R. Abrial |Abrial& 70| auteur
du langage Z et celui de G.M. Nijssen |Nijssen 89| auteur de la methode NIAM. Nous
presentons le modele de NIAM qui a l'avantage d'tre graphique et normalise ISO.
La methode NIAM propose une demarche d'analyse du discours de l'utilisateur suivant une
classiIication qui consiste a mettre en evidence les concepts suivants :
les objets non lexicaux (NOLOT) qui sont des objets reels ou abstraits perus dans
l'univers du discours (Ex : PERSONNE, PAPIER, CONFERENCE, ...)
les objets lexicaux (LOT) qui sont des caracteristiques des NOLOTs (Ex : NOM,
PRENOM, NUMEROPAPIER, NUMEROCONFERENCE, ...)
les idees (IDEA) qui sont des Iaits ou phrases simples (sujet verbe complement)
perus dans l'univers du discours et qui associent deux NOLOTs (Ex : un papier est
ecrit par un auteur).
les ponts de denomination (BRIDGE) qui sont des Iaits ou phrases associant un
NOLOT et un LOT (Ex : une personne a un nom, une personne a un prenom, ...).
les sous types (SUBTYPE) qui traduisent une relation entre deux NOLOT et qui
indiquent que l'un possede les caracteristiques de l'autre (Ex : un lecteur est une
personne, un auteur est une personne).
les contraintes qui permettent de prendre en compte des regles de gestion et de
coherence. Parmi ces contraintes on note la contrainte d'identiIication, d'unicite, de
totalite, d'inclusion, d'exclusion, ...
Un avantage du modele binaire est de disposer d'une demarche systematique d'analyse du
discours en langage naturel pour obtenir une Iormalisation a travers la methode NIAM.
Pour ne pas alourdir la presentation, nous ne developperons pas ici le Iormalisme
graphique associe. De mme, nous ne reproduisons pas les reperes d'evaluation. Ce modele se
situant clairement tres pres du modele entite association dans les deux reperes. Nous pourrons
cependant trouver une etude du cas IFIP dans |Verheijen& 82|
3.1.3. Diagramme de flux de donnes
Plutt que de se concentrer sur la representation statique des donnees, on peut s'interesser plus
particulierement aux echanges d'inIormation dans le systeme.
Le diagramme de Ilux de donnees (DFD) |Gane& 79| est compose de 3 concepts de base
(processus, entite externe et dept de donnee) et d'un seul type de lien (Ilux de donnees). Le
modele conceptuel de communication de Merise (MCC) est similaire, nous ne le
developperons donc pas ici. Un flux de donnees represente la circulation des donnees (simples
ou groupees) entre des transIormations. Chaque donnee peut tre le support d'une
inIormation, ou d'elements physique du systeme (energie, matiere). Le Ilux de donnees est
etiquete par une expression ne comportant que des noms ou adjectiIs. Le processus est une
unite de traitement realise par le systeme qui transIorme les Ilux de donnees entrant en Ilux de
donnees sortant. Le processus comporte un numero qui le caracterise de maniere unique et il
comporte aussi une etiquette Iormee d'un verbe a l'inIinitiI suivi eventuellement d'un
complement d'objet direct qui concerne la donnee sur laquelle porte la transIormation. Un
depot de donnee est une donnee primitive ou un groupement de donnees maintenu disponible
pour tout processus. Il est etiquete de la mme maniere qu'un Ilux de donnees. Une entite
externe permet de representer des regroupements logiques de notions du systeme etant
sources ou destinataires des transactions. Le tableau suivant deIinit les connexions autorisees
entre les diIIerents concepts du diagramme de Ilux.
Commentaire [CC1] : Page:
27
Symbolisme NIAM
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 28
processus dept de
donnee
entite externe
processus X X X
dept de donnee X
entite externe X
Figure 11 : Regle de connexion des concepts du DFD.
Nous resumons le Iormalisme graphique associe au diagramme de Ilux de donnees de Gane et
Sarson |Gane& 79| a l'aide d'un petit exemple extrait du cas IFIP.
Auteurs Susciter
Papier
papier sollicit
localisation
de lactivite
nom du
processus
numero du
processus
nom du flux
de donnees
nom du depot
de donnee
nom de
lentite externe
date ngocie
Papier
D1
104
Figure 12 : Symbolismes Gane&Sarson de DFD.
Des simpliIications de la notation sont introduites pour Iaciliter la lisibilite comme la
duplication des dept de donnee et d'entite externe.
Le declenchement d'un processus ne peut tre eIIectue que lorsque les Ilux de donnees
entrant necessaires a la production de Ilux de donnees sortant sont disponibles. Le
declenchement d'un processus consiste a consommer les donnees des Ilux entrants dans
l'ordre de leur arrivee. Un DFD est une representation idealisee ou les processus se
declenchent des que les donnees necessaires a leur activite sont presentes en entree,
instantanement et simultanement, si la disponibilite des donnees est assuree pour chacun
d'eux. La regle d'activation et de consommation induisent une relation causale : si deux
processus sont relies directement par un Ilux de donnee, la production de Ilux par le processus
emetteur provoque le declenchement du processus utilisateur alors que si deux processus sont
connectes par un dept de donnee, la production du processus emetteur n'a pas d'inIluence sur
le processus utilisateur.
Le diagramme de Ilux de donnees correspondant au cas IFIP est relativement concis
comme on peut le voir sur la Iigure suivante.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 29
Comit
Organisation
Participant
Comit
Programme
Auteurs
nitier
Confrence
105
PapierSlectionn
Nommer
Prsident
Session
112
dates et
comit programme
ComitProgramme
DateConfrence
Planifier
Autres
Activits
113
Diffuser
Programme
Confrence
114
Programme
Dfinir
Programmes
Sessions
111
Planifier
Sessions
110
membres
dates
confrence
dates
confrence
programme
programme
final
programme
PapiersRpartis
papiers
slectionns
Annuler
Papiers
106
Comit
Programme
drogation
Auteurs
papiers
annuls
Valider
Auteur
101
Valider
Date
Papier
102
Papier
DateConfrence
Susciter
Papier
104
auteur
papier sollicit
date ngocie
courrier
papier
nouvel auteur
auteur
lettre ou papier
dates limites
drogation
auteur
papier
annul
papier
papier sollicit
papier
papier
annul
DateConfrence dates
confrence
D12
D3
D13
D12
D2
D1
D12
D11
D4
Figure 13 : DFD du cas IFIP.
Un DFD ne decrit ni les modes operatoires des donnees, ni la composition precise des
donnees, pas plus que les types d'acces aux depts, les decisions et boucles internes au
systeme, ou la realisation des entrees/sorties physiques. DiIIerentes extensions des DFD ont
ainsi ete proposees |Lissandre 90b|, |Perez 90|, |Theron 88|, |Calvez 91|. On remarquera
aussi la proposition d'une speciIication executable avec les DFD dans |Fuggetta& 93|.
Nous situons donc le modele DFD assez eloigne sur l'axe des donnees et plus proche de la
dynamique et des processus.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 30
processus
donnes
dynamique
MCD Merise
DFD
Figure 14 : Evaluation de DFD sur le reIerentiel d'objectiI.
Le modele DFD presente un niveau d'abstraction comparable a celui du MCD Merise |Quang
89|. D'un autre cote, le contenu des processus est exprime de maniere inIormelle, ce qui le
rend sujet a de multiples interpretations et reduit donc la precision. En plus de ce manque de
precision dans la description des processus, on manque aussi de moyens pour decrire les
contraintes de declenchement dynamique des actions. On situe donc le modele assez loin sur
l'axe de la richesse Ionctionnelle egalement.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
Figure 15 : Evaluation de DFD sur le reIerentiel qualitatiI.
On peut donc voir les diagrammes de Ilux comme de bons modeles d'analyse orientes
dynamique des processus plutt que comme des outils de speciIication globale.
3.1.4. SADT
Le diagramme SADT (Structured Analysis and Design Technique) est un diagramme de Ilux
ou l'on distingue quatre types de Ilux (entree, sortie, contrle et mecanisme) par rapport a leur
utilisation dans le processus |IGL 89|, |Lissandre 90|, |Vautrin& 86|, |Lissandre 86|. Le
processus est represente par une bote dont chaque cote possede une signiIication particuliere
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 31
(voir Iigure suivante). Un diagramme est constitue d'un nombre limite de botes (3 a 6)
pouvant chacune tre decomposee de Iaon hierarchique.
2
3
1
contrles
sorties
ressources
entres
bote SADT Diagramme SADT
Figure 16 : Formalisme SADT
Un diagramme SADT peut tre lu comme un Actigramme pour decrire l'enchanement des
activites ou comme un Datagramme pour representer la transIormation des donnees. Le
Datagramme n'est pas une representation duale de l'Actigramme, il n'est pas construit a partir
de ce dernier mais de Iaon independante, de maniere a permettre sa veriIication ulterieure.
Donnes de
contrles
Donnes de
sortie
ressources
actives
Donnes
d'entre
Activits de
contrles
Activits
utilisatrices
Support de
la donne
Activits
cratrices
(a) Actigramme (b) Datagramme
Figure 17 : Representation duale.
La distinction donnee/contrle indique d'une part les inIormations qui ne sont pas
transIormees (contrle) et d'autre part permet d'evaluer le degre de cohesion dans un
diagramme donne.
Le diagramme SADT structure davantage les transIormations des inIormations
(datagramme) que le diagramme de Ilux de donnees, il aura donc une meilleure representation
sur l'axe des processus. De mme on ameliore la dynamique a l'aide des actigrammes. Par
contre la speciIication des donnees en tant que telles reste comparable a ce que l'on rencontre
dans le DFD.
Commentaire [C.C.2] : PAGE
: 31
Voir |Vautrin& 86|
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 32
processus
donnes
dynamique
MCD Merise
DFD
SADT
Figure 18 : Evaluation de SADT sur le reIerentiel d'objectiI.
Comparativement aux remarques que nous avons pu Iaire sur le modele DFD, on peut dire
que la precision et la richesse Ionctionnelle sont ameliorees, grce a l'introduction de Ilux de
contrle et la distinction entre les datagrammes et les actigrammes.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
Figure 19 : Evaluation de SADT sur le reIerentiel qualitatiI.
Le modele SADT est souvent utilise pour la speciIication, neanmoins, on peut encore
deplorer la philosophie de "bote noire" pour la description des processus et des contrles.
3.2. Modles orients objet
Le principal probleme des modeles structures est dissocier la structure des donnees de celle
des traitements, ce qui conduit dans les modeles que nous avons etudies jusqu'ici a Iinalement
negliger la description precise de l'un ou l'autre aspect. On compense en general ce deIaut en
developpant deux modeles structures separes, ce qui necessite un eIIort d'integration
supplementaire pas toujours Iacilement realisable. Le concept d'objet pallie en partie ce deIaut
en integrant les donnees et les traitements associes |Massini& 90|, |RochIeld 92|,
|Waserman& 90|, |Derniame& 90|, |DixneuI& 90|.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 33
Le concept d'objet est a la conIluence des recherches en simulation avec les langages de
classes, en psychologie cognitive avec les langages de Irames et en robotique avec les
langages d'acteurs |Hill 93|, |KrieI 92|. Conu a des Iins de modelisation de systemes
physiques, en recherche nucleaires notamment, et specialise dans les traitement de problemes
de simulation, Simula I |Dahl& 66| servit de modele a toute une lignee de langages de
classes (Ada |Booch 87|, C |Stroustrup 86|, EiIIel |Meyer 90| et Smalltalk |Goldberg&
89| entre autres). Les langages de frames apparaissent comme une synthese des diIIerents
Iormalismes de representation de la connaissance tels que les reseaux semantiques et les
prototypes, et sont surtout employes dans des domaines aussi varies que la vision par
ordinateur, le traitement du langage naturel ou encore la comprehension de recits. Le concept
d'acteurs se rapproche des objets en se basant sur la notion d'activite qui est diIIerente de la
notion de classe-instance. La delegation de message est le seul mecanisme de contrle. Les
langages d'acteurs se sont reveles tre tres adaptes a la conception des systemes distribues ou
paralleles (Plasma |Hewitt 77|, Act1 |Agha 86|, |Love 86|).
Les deIinitions d'objet rencontrees dans la litterature revelent souvent du choix a priori
d'un langage de reIerence particulier, Smalltalk le plus souvent. Cela entrane souvent des
conIusions, aussi il nous semble important de preciser les termes employes aIin comprendre
son intert en inIormatique de gestion. Un objet est un concept regroupant a la Iois des
proprietes declaratives et des proprietes actives, representant une abstraction d'elements du
monde reel. Cette deIinition, peu Iormelle, mais la plus largement rencontree, semble
convenir a certains domaines d'activite, tels que ceux ou sont parus le concept pour la
premiere Iois, et ou l'identiIication d'un tel objet est simple. En inIormatique de gestion, un
veritable debat se deroule autour de la maniere d'identiIier les bons elements du monde reel,
candidats aux objets. Actuellement, aucune methode ne Iournit de criteres objectiIs
d'identiIication des objets. On ne dispose pas de critere de decomposition tel que le concept
de dependance Ionctionnelle dans la modelisation des donnees.
Les proprietes declaratives d'un objet, que l'on nomme le plus souvent attributs, sont des
valeurs caracterisant l'etat de l'objet. Cette valeur se caracterise soit par une variable dans les
langages de classe, soit par un slot dans les langages de Irame, soit par un "accointance" dans
les langages d'acteur. La diIIerence entre ces trois notions se situe plus au niveau conceptuel
qu'au niveau de l'implementation. Un slot est noeud terminal dans la hierarchie des relations
qui deIinit un Irame, auquel est associe un certain nombre de Iacettes possedant des valeurs.
Les Iacettes servent a decrire aussi bien la nature de l'inIormation que contient le slot, qu'a
preciser comment la calculer ou l'utiliser. Dans les langages d'acteur, les accointances sont les
connaissances declaratives designant les autres acteurs que l'acteur connat directement. Ce
sont des donnees locales d'un acteur, correspondant aux variables d'instance d'une classe.
Les proprietes actives d'un objet, que l'on nomme le plus souvent methodes, deIinissent
leurs comportements. Un objet est caracterise par les actions qu'il subit et qu'il demande aux
autres objets |Booch 91|. Les methodes peuvent admettre une liste de parametres et ont un
corps de Ionction. Dans les langages de Irame, les proprietes actives de l'objet sont realisees
par des reIlexes attaches aux attributs de l'objet. Un Irame n'a pas de comportement propre, ce
sont des reIlexes qui s'activent par reaction aux operations d'acces, alors que les methodes
sont actives explicitement par envoi de messages. Dans les langages d'acteur, le
comportement est deIinit par les actions que l'acteur entreprend au cours de son existence, en
Ionction des evenements qui surviennent. Contrairement a une classe, le comportement n'est
pas deIinit par des methodes, mais par un script unique qui Iiltre les messages reus par
l'acteur et active la partie appropriee du comportement.
L'envoi de message peut tre vu comme la seule structure de controle autorisee par les
objets |Hewitt 77|. Un message est un ordre d'activation d'une methode. Un message est
speciIie par l'expediteur, le destinataire, le selecteur du service demande et une liste de
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 34
parametres. De ce Iait, un envoi de message peut s'interpreter comme un appel de procedure,
mais il se distingue d'un appel de procedure par le Iait que la methode a appliquer est
determinee a l'execution. Lorsque la methode delivre un resultat, celui-ci est retourne a
l'expediteur. C'est dans les langages d'acteur que la notion d'envoi de message prend tout son
sens, dans la mesure ou le resultat peut tre retourne a un autre acteur par continuation,
permettant ainsi la communication asynchrone. Dans les langages de Irame, l'envoi de
message n'existe pas reellement, la communication est dirigee par les acces et non par
transmission, et le choix d'une bonne semantique de declenchement des reIlexes est une
aIIaire delicate.
L'heritage permet de deIinir a partir d'un objet, un nouvel objet comportant des proprietes
similaires, en explicitant uniquement les diIIerences du nouvel objet. La representation
courante permet de deIinir un graphe d'heritage, eventuellement multiple, mais dans ce cas,
chaque langage adopte une strategie particuliere pour regles les conIlits possibles. L'heritage
est dynamique dans les langages de representation de connaissances, et s'eIIectue par copie,
eventuellement diIIerentielle, d'un prototype, en particulier lors de la delegation de message
d'acteurs. Ces deux aspects de l'heritage se retrouvent dans le typage des variables plus ou
moins restrictiI.
La genericite est une notion permettant de deIinir conceptuellement un ensemble de types
d'objets en parametrant par d'autres classes d'objets. Il est des lors possible de deIinir une
classe qui sera instanciee en diIIerentes autres classes par la precision du type d'elements. La
pile est un exemple classique d'objet generique, qui permet d'obtenir une gestion de pile
independamment du type d'element contenu dans la pile (entier, chane de caracteres, date,
...).
Le polvmorphisme est la capacite de surcharger les methodes d'un objet, c'est-a-dire de les
appliquer a des arguments de types diIIerents. On distingue le polymorphisme parametrique
qui s'apparente a la genericite, le polymorphisme d'heritage oIIrant a l'utilisateur une
souplesse syntaxique, celui-ci pouvant avoir a decrire les methodes speciIiques
correspondantes, et le polymorphisme ad hoc qui donne a l'utilisateur l'impression d'utiliser
une mme Ionction lorsque des methodes appartenant a des classes diIIerentes ont le mme
selecteur.
L'instanciation est l'action consistant a construire un nouvel exemplaire d'un objet a partir
d'un modele, qui peut tre une classe, ou l'objet lui-mme, comme dans les langages d'acteur.
Dans les langages de representation, les objets sont consideres eux-mmes comme des
prototypes : il n'y a plus de dualite classe-instance et l'heritage est completement dynamique.
Les modeles utilisant le concept d'objet ont generalement pour origine les langages de
programmation par objets |Bouzeghoub& 95|, les modeles de donnees |RochIeld& 93|,
|Delobel& 91|, les bases d'objets ou une combinaison des trois |Rolland 93|, |Jacobson& 92|.
Nous presentons maintenant des Iormalismes representatiIs de cette classiIication adaptes aux
systemes d'inIormation.
3.2.1. OOA
Le Iormalisme OOA (Object Oriented Analysis) propose dans le cadre de la methode Coad &
Yourdon |Coad& 91a,b| decrit la structure des objets et des relations entre les classes, le
cycle de vie des objets ainsi que les changements d'etat en Ionction des evenements.
Une classe modelise des objets ayant des proprietes identiques. Un attribut represente les
proprietes propres d'un objet ou la connaissance dont a besoin un objet des autres objets pour
assurer les services sous sa responsabilite. L'heritage deIinit une relation de
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 35
generalisation/specialisation, de hierarchie ou encore de sous typage entre les classes.
L'agregation deIinit une relation de composition entre les objets.
Le schema suivant deIinit les structures du cas IFIP. Les noms d'attributs Iigurent a
l'interieur des rectangles arrondis representant les objets. On peut voir que les objets Papier et
PapierSoumis heritent de l'objet Papier exprimes par le lien d'heritage. De mme une
ConIerence est composee d'une a n Session et une Session Iait partie d'une ConIerence et une
seule. Cette relation est exprimee par un lien d'agregation.
Papiernvite
Statut
PapierSoumis
Numro
Papier
Titre
ntention
ntrt,
ntgration,
Originalit
Rapport
DateEnvoie
Type
Texte
LettreType
Numro
Titre
DateDbut
Dure
Session
Numro
Dure
Expose
Numro
Titre
Lieu
DateDbut
DateFin
DateLimite
Conference
1
1,n
1
1,n
confrence
confrence
confrence confrence
intention intention
intention intention
papier
papier
papier
papier
lettre type lettre type
lettre type lettre type
rapport rapport
rapport rapport
Figure 20 : IdentiIication des structures.
Un sujet est un principe d'organisation des classes de maniere a guider l'utilisateur a travers
la lecture d'un modele complexe. Un sujet constitue alors une bibliotheque de classes. Le
sujet est une construction utile pour clariIier le schema de conception mais cette construction
n'apparat pas directement dans le texte des programmes. Sur les schemas, les sujets sont
representes par des rectangles grises. On aIIine le schema precedent en regroupant certains
sujets. On observe un changement de la structure de l'objet Papier qui herite maintenant de
l'objet Intention.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 36
Papiernvite
Statut
PapierSoumis
Numro
Papier
Lettrentention
Titre
ntention
ntrt,
ntgration,
Originalit
Rapport
DateEnvoie
Type
Texte
LettreType
Numro
Titre
DateDbut
Dure
Session
Numro
Dure
Expose
Numro
Titre
Lieu
DateDbut
DateFin
DateLimite
Conference
1
1,n
1
1,n
Figure 21 : IdentiIication des sujets.
On a parIois besoin d'etablir des connexions dinstance entre objets pour resoudre les besoins
d'inIormations lors de l'activation des services. Par exemple un Papier est connecte a 0 ou 1
Expose (dans une Session) et un Expose est connecte a un Papier et un seul.
Papiernvite
Statut
PapierSoumis
Numro
Papier
Titre
ntention
ntrt,
ntgration,
Originalit
Rapport
DateEnvoi
Type
Texte
LettreType
Numro
Titre
DateDbut
Dure
Session
Numro
Dure
Expose
Numro
Titre
Lieu
DateDbut
DateFin
DateLimite
Conference
1
1,n
1
1,n
1
0,1
1,n
1,n
1
0,1
1,n
1
Lettrentention
Figure 22 : DeIinition des connexions d'instances.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 37
Un service deIinit le comportement dont est responsable un objet. Une communication
modelise les dependances Ionctionnelles d'un objet en indiquant un besoin de service pour
remplir ses Ionctionnalites. Les services peuvent tre speciIies par un numero de sequence ou
par une Iorme algorithmique. Par exemple un PapierSoumis utilise les services d'un Rapport
pour modiIier son Statut.
Papiernvite
Statut
PapierSoumis
Numro
Papier
ntention
Titre
ntention
ntrt,
ntgration,
Originalit
Rapport
DateEnvoie
Type
Texte
LettreType
Numro
Titre
DateDbut
Dure
Session
Numro
Dure
Expose
Numro
Titre
Lieu
DateDbut
DateFin
DateLimite
Conference
1
1,n
1
1,n
Figure 23 : DeIinitions des services et connexions de messages.
Le cycle de vie d'un objet represente les sequences d'activations possibles de ses services. Par
exemple, les sequences possibles d'appel des methodes de l'objet Papier sont representees par
le diagramme suivant.
crer
modifier, accder
supprimer
crer
modifier, rpartir, enregistrer_rsultat_slection,
accder, lister_papier, relancer_lecteur
supprimer
Figure 24 : DeIinition du cycle de vie de l'objet Papier.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 38
Un tableau d'etats / evenements decrit les transitions d'etats possibles d'un objet en Ionction
des services actives ou evenement interceptes. Ce diagramme suppose que les etats sont Iinis.
Etat Avant Evenement / Service Active Etat Apres
CreerPapierSoumis present
present Acceder(ListePapierSoumis) arepartir
arepartir AIIecterLecteur enlecture
enlecture CalculerSynthese note
note PrendreEnCompteResultat (ballottage / accepte / rejete )
ballotage AIIecterLecteur enlecture
accepte ou rejete DonnerResultatSelection
Tableau 1 : Tableau des Etats/Evenements de PapierSoumis
EnIin Coad & Yourdon proposent un Iormalisme structure pour decrire les services. Ce
Iormalisme repose sur un certain nombre de structures de contrle de base classiques comme
l'iteration, l'alternative ou la sequence. Les actions elementaires sont simplement des
descriptions inIormelles sous Iorme de blocs de textes.
Icxt |loc|
loo ;t:iggc:tc:ui:atc, :ccat, co, w|ilc,
o:citio: ;ii, :cco:citio:, t:iggc:, tc:ui:atc,
o::ccto:
Figure 25 : Symbolisme utilise pour l'algorithme des services.
Les representations du cycle de vie des objets ainsi que des evenements sont assez
sommaires. La structure des objets et de leurs relations statiques est decrite avec un bon
niveau de detail, bien que les contraintes prises en compte soient un peu moins riche que dans
le modele conceptuel de donnees. La description des methodes est realisee a l'aide de
diagrammes structures qui assure la prise en compte des processus.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 39
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Figure 26 : Evaluation de OOA sur le reIerentiel d'objectiI.
Par contre, l'utilisation des diagrammes structures pour la deIinition des methodes reduit le
niveau d'abstraction (expression du "comment Iaire"). De ce Iait, malgre une bonne precision
et une richesse Ionctionnelle importante, le modele OOA presente un deIaut pour la
speciIication des processus.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Figure 27 : Evaluation de OOA sur le reIerentiel qualitatiI.
3.2.2. Classe Relation
La methode Classe-Relation creee par |DesIray 90|, |DesIray 92| decrit une application a
l'aide de trois modeles. Le modele obfet permet de deIinir les notions d'une application en
terme de classe, de leurs structures et des liens existants entre elles. Le modele reprend la
notion classe, methode, attribut et heritage en introduisant la notion de relation entre les
classes. Le modele operatoire decrit les services oIIerts par chacune des classes en
Iournissant leur mode d'emploi et un automate de contrle au niveau de chaque classe. Le
modele dvnamique utilise la notion d'evenement pour decrire le sequencement des traitements
a l'aide d'un automate de declenchement. Le modele dynamique consiste aussi a realiser un
diagramme de Ilux.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 40
Le modele obfet de la methode Classe-Relation decrit diIIerentes relations entre des classes
en introduisant la notion de visibilite (public, protected ou private) sur ses membres (attributs,
methodes et relations) pour limiter leur acces. Classe-Relation admet aussi une notion de
classe generique. Un attribut deIinit une propriete d'une classe correspondant a une valeur
attachee a chacune de ses instances. Un attribut est caracterise par sa classe ainsi que ses
valeurs par deIaut. Pour Classe-Relation, un attribut equivaut a une methode. Un attribut peut
tre peru comme la realisation particuliere d'une relation dagregation, mais Classe-Relation
n'admet que des attributs de classe elementaire. Une methode est un service que peuvent
Iournir toutes les instances d'une classe. Elle speciIie la nature des messages que pourront
traiter ces instances. Chaque methode peut avoir des parametres munis d'un mode de passage
in, out et inout, ainsi qu'une valeur de retour. Un lien dheritage exprime que toutes les
proprietes deIinies pour une classe demeurent vraies pour ses heritieres. L'heritage deIinit
toujours une relation d'inclusion entre classes, par ajout ou precision des proprietes des
classes meres. L'ensemble des instances possibles d'une classe heritiere est inclus dans
l'ensemble des instances possibles de sa (ses) classe(s) mere(s). Classe-Relation admet la
notion dheritage multiple, mais ne precise pas la maniere de regler les eventuels conIlits.
L'invariant d'une classe est l'ensemble des proprietes que doivent veriIier toutes les instances
de la classe a chaque instant.
Le Iormalisme graphique du modele objet permet de representer notamment les concepts
de relation entre les classes d'objets. La relation deIinit un lien stable entre deux classes
diIIerentes, qui permet a tout moment, connaissant un representant d'une des deux classes, de
connatre les representants de l'autre classe qui lui sont associes. Les cardinalites peuvent
prendre les valeurs dans l'ensemble des entiers naturels, * et all. Une relation est orientee par
un rle caracteristique. L'orientation des relations Iournit un sens de navigation dans un
graphe Classe-Relation, et determine aussi les utilisations entre les classes. Par exemple, sur
le modele objet du cas IFIP, la relation Soumettre est orientee de ConIerence vers Papier, ce
qui signiIie que la classe ConIerence accedera aux services de la classe Papier et non
l'inverse. Les liens dheritage sont representes par des arcs annotes par le texte "is_a".
Conference
Session
Adherent
Papier
PapierSoumis
Papiernvite
Presentateur
AdherentAuteur
AuteurSollicite Auteurnvite
Comporter
Exposer
Comporte
Rediger
Rediger
Presider
Soumettre
is_a
is_a
is_a
is_a
is_a is_a
1-1
1-1
1-1
1-1
1-n
1-n
1-1 1-1 1-n
1-1
1-1
1-1
Figure 28 : Schema de soumission de communication a une conIerence.
Ci-dessous nous representons une vue detaillee des classes Papier et ConIerence. Nous
remarquerons la separation des membres des classes pour indiquer leur visibilite ordonnee de
haut en bas selon l'ordre public, protected et private. Les methodes sont distinguees
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 41
syntaxiquement par la presence de parentheses. Une etoile (*) caracterise un attribut
identiIiant de l'occurrence.
nitialiser()
Structurer()
Titre
Lieu
Date
NombrePersonnesPrevues
*NumeroConference
EtatConference
Conference
mprimer()
Titre
Rdiger()
Modifier()
Annuler()
*NumroPapier
EtatPapier
Papier
DateEnvoiLecture
DateLimiteEnvoi
EtatPapier
PapierSoumis
DateRemisePapier
EtatPapier
Papiernvite
Soumettre
is_a
is_a
1-n
1-1
DateRception
Figure 29 : Vue detaillee de la classe Papier et ConIerence.
Le modele operatoire consiste a decrire chaque methode par les operations qu'il reoit et emet
en indiquant les parametres et leur mode de passage, son rle et sa Ionction de maniere
textuelle, les preconditions (ensemble des conditions prealables et necessaires a son
execution) et les postconditions (ensemble des conditions qui deIinissent le resultat correct de
l'execution d'une methode) et ses automates de contrle. Un automate de contrle permet
d'exprimer les sequences autorisees entre des etats deIinis pour les instances de la classe.
Provisoire
Definitive
Annulee
Solicite
Modifier() Modifier()
Creer()
Modifier()
<DateLimiteEnvoiPapier>
Annuler()
<DateLimiteEnvoiPapier>
Annuler()
Figure 30 : Automate de contrle de la classe PapierInvite.
Un etat est une valeur predeIinie caracterisant une des situations stables possibles. Les
elements modelises sont supposes posseder un nombre Iini d'etats. Il y a des etats qui sont
speciIiques (initial, Iinal) et sont entoures par un double trait (voir Iigure suivante). Un etat
resume est une vision imprecise ou macroscopique d'une situation. Elle est representee par un
ombrage. Une transition est un changement d'etat provoquee par une methode.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 42
Etatnitial
Etat i
Etat spcifique
Un tat
Une transition
<condition>mthode()
EtatRsum
Etat rsum
Figure 31 : Symbolisme utilise pour l'automate de contrle.
Le modele dvnamique consiste a decrire l'enchanement des traitements suivant un modele
Ionctionnel et un modele evenementiel. Le modele fonctionnel utilise une pseudo syntaxe en
langage naturel reutilisant la terminologie de la modelisation, des structures de contrle si-
alors-sinon, des envois de messages et des manipulations d'ensembles grces aux methodes
predeIinies sur les relations et sur les classes. On peut egalement integrer un diagramme de
flux de donnees du genre DFD ou SADT ou les processus sont assimiles a des methodes et les
stockages sont assimiles aux ensembles, aux classes ou aux relations. L'automate de
declenchement s'apparente a l'automate de contrle en introduisant la notion d'evenement.
Etat j
Etat i
<<Evnement>><condition>mthode()
Figure 32 : Symbolisme pour l'automate de declenchement.
Par exemple, sur l'automate de declenchement de la classe PapierSoumis, a l'arrivee de
l'evenement Communication>> on declenche la methode Enregistrer() qui Iait
passer l'etat de l'attribut EtatPapier de Intention a Provisoire.
Provisoire
EnLecture Annulee
ntention
<<Communication>>
Enregistrer()
<<DemandeLecture>>
SelectionnerLecteur()
<<ntentionPapier>>
Creer()
<<VersionPapier>>
Modifier()
<DateLimiteReceptionPapier>
Annuler()
<<DateLimiteEnvoiPapier>>
Annuler()
NoteGlobale
Ballotage
Refuse
<<DemandeAnnulationntention>>
Annuler()
Accepte
Refuse
<<DemandeLecture>>
SelectionnerLecteur()
<<NoteMinimale>>
<<LectureComplete>>
EnregistrerNotation()
<<NoteSatisfaisante>>
<<Notensufisante>>
<<DemandeAnnulation>>
Annuler()
<<DemandeProgrammation>>
Programmer()
Programme
<<DemandeAnnulation>>
Annuler()
<<DateReceptionPapierFinalDepassee>>
Annuler()
VersionFinale
<<EnvoiPapierFinal>>
EnregistrerPapierFinal()
Figure 33 : Automate de declenchement de la classe PapierSoumis.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 43
Les modeles de la methode Classe-Relation peuvent tre mis en parallele etroit avec ceux de
la methode OOA. Les notions de protection des membres d'une classe et d'orientation des
relations ameliorent le niveau de detail global du modele. L'introduction d'automates de
contrle et de declenchement precisent le comportement dynamique du systeme.
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Figure 34 : Evaluation de Classe-Relation sur le reIerentiel d'objectiI.
Ces notions speciIiques au modele Classe-Relation deteriorent encore son niveau
d'abstraction dans le sens ou certains choix supplementaires sur la maniere de concretiser la
structure des donnees et du contrle sont operes. En realite ce modele est plutt conu dans
le but d'une implantation directe dans un langage de programmation oriente objet speciIique
(comme C). Il est donc plus approprie dans le cadre de la phase de conception plutt que
celle de speciIication.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Figure 35 : Evaluation de Classe-Relation sur le reIerentiel qualitatiI.
3.2.3. BOOCH
La methode Booch |Booch 91| comporte plusieurs types de diagrammes : classes, objets,
transitions d'etats, modules et processus. Les diagrammes du niveau physique (modules et
processus) decrivent des elements de l'architecture du systeme, a laquelle nous ne nous
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 44
interessons pas directement dans le cadre de notre etude. Nous allons decrire brievement les
diagrammes du niveau logique sans entrer dans tous les details du Iormalisme pour ne pas
alourdir notre expose.
Le diagramme de classes reprend avec un Iormalisme diIIerent, les concepts classiques
(classe, objet, heritage, attribut, service, relation, ...) deja rencontres dans les schemas
correspondants dans les methodes OOA et Classe-Relation.
Gestionnaire
Confrence
Papier
Soumis Papier
Rapport
Lecture
Lettre
Type
Lecteur
Lecteur
Potentiel
Document
Auteur
Potentiel
Membre
Comit
Programme
Prsident
Session
Potentiel
Membre
Groupe
Travail
Membre
Comit
Technique
Confrence
Prsident
Session
Expos
Session
Domaine
1
1
1
*
1
1
1
1
1
1
1
1
1
1
1
*
*
*
*
*
*
*
*
*
*
*
1
1
1
1
1
?
+
+
+
+
regroupe
1
Figure 36 : Diagramme des classes de la categorie ConIerence.
Le diagramme des objets reprend la structure du diagramme des classes. Il permet de cerner la
semantique dynamique du systeme en indiquant les messages echanges avec les autres objets,
mais aussi la classe mere de l'objet et la duree de vie (persistant, statique, dynamique). Les
arcs peuvent tre de diIIerents types indiquant une liaison simple, synchrone, asynchrone,
avec delai, avec reIus. On peut egalement annoter chaque arc avec les modes d'acces
autorises. Par exemple l'objet Session peut acceder a l'objet Expose en Lecture ou en
ModiIication. Les objets et les messages du diagramme des objets peuvent tre completes par
des Iormulaires textuels mais aussi par trois autres moyens pour indiquer la chronologie des
evenements : indiquer un N ordre relatiI sur chaque message, utiliser un langage structure ou
Iaire un diagramme chronologique (de type Pert).
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 45
Gestionnaire
Confrence
Papier
Soumis Papier
Rapport
Lecture
Lettre
Type
Lecteur
Lecteur
Potentiel
Document
Membre
Comit
Programme
Prsident
Session
Potentiel
Membre
Groupe
Travail
Membre
Comit
Technique
Confrence
Prsident
Session
Expos
Session
Domaine
Auteur
Auteur
Potentiel
Soumissionnaire
M L
M L
M L
M L
C S
M L
C S
M L
C
S
M
L
C
S
M
L
C
S
M
L
C
S
M
L
C
S
M
L
C
S
M
L
CS M L
C
S
M
L
C
S
M
L
C
S
M
L
C
S
M
L
C
S
M
E
C
S
M L
C S M L
C
S
M
L
E
E
Lgende : C : Crer, S : Supprimer, M : Modifier, L : Lire, E : Editer
Figure 37 : Diagramme des objets de la categorie ConIerence.
Le diagramme de transition d'etat complete la description de chaque classe en presentant les
evenements provoquant les changements d'etats et les actions induites par ces changements.
Chaque action peut tre decrit dans un langage structure.
Papier En
Examen
Papier En
Lecture
Papier
Not
Papier En
Ballotage
Papier
Accept
Papier
Rejet
Papier En
Projet
rception
papier
rpartition
rapport
lecture
transmis
rejet
comit
programme
regroupement
en session
accord
comit
programme
relecture
Figure 38 : Diagramme d'etats de transition de la classe Papier.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 46
La richesse des types de message permise par la modele de Booch contribue a lui accorder
une meilleur expressivite pour la dynamique que celle des modeles des methodes OOA et
Classe-Relation. L'expression des processus a l'aide de langages structures lui conIere une
bonne position sur l'axe des processus. Quand a la representation des donnees, elle reste
comparable a celle des deux autres modeles objets etudies.
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
Figure 39 : Evaluation de Booch sur le reIerentiel d'objectiI.
Ici nous avons mme plus un Iormalisme structure, mais explicitement un langage de
programmation pour decrire les traitements, ce qui disqualiIie, a notre sens, le modele comme
outil de speciIication.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
Figure 40 : Evaluation de Booch sur le reIerentiel qualitatiI.
On pourrait renouveler des etudes similaires sur d'autres Iormalismes objets comme OMT,
OOM |RochIeld& 93|, Objets naturels |Bres 90|, |Jocteur 90|, |Gendre& 90|, ... Neanmoins
leurs positions sur nos reIerentiels d'evaluation est semblable a celle des methodes que nous
avons etudiees.
On constate en Iait que les Iormalismes bases sur les objets sont plus appropries a une
phase de conception preliminaire a cause de leur manque d'abstraction d a des choix lies
notamment a la realisation des traitements et des contrles. Nous allons donc dans la suite
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 47
envisager des modeles plus Iormels du point de vue de la representation du comportement
dynamique ou de la description des Ionctionnalites.
3.3. Modles vnementiels
3.3.1. REMORA
Les trois concepts de bases de la methode REMORA |Rolland& 82|, |Rolland& 91a|sont
l'objet, l'evenement et l'operation. Un obfet est un element du systeme reel qui possede une
duree de vie non nulle. Un evenement est une observation d'un changement d'etat d'objet du
systeme d'inIormations que l'on peut considerer comme un phenomene de duree nulle. Une
operation permet d'exprimer une action elementaire permettant de modiIier l'etat d'un objet du
SI. Le niveau conceptuel est decrit en termes de categorie d'objets (C-Objet), de categorie
d'evenements (C-Evenement) et de categorie d'operations (C-Operation) qui sont des relations
particulieres integrant le temps dans leur representation.
Un C-Obfet est decrit sous la Iorme d'une relation en troisieme Iorme normale
accompagnee d'eventuelles contraintes d'integrite. Une C-Operation est une operation
s'appliquant a un et un seul C-Objet. La description de l'action correspond a un texte associe.
Un C-Evenement represente un changement d'etat atomique remarquable d'un et un seul C-
Objet qui declenche l'execution d'une ou de plusieurs C-Operations. Il est speciIie par les
deux predicats de pre et post condition, la liste des C-Operations declenchees et le texte des
conditions et des Iacteurs de declenchement.
Les textes de speciIication peuvent tre decrits soit d'une maniere inIormelle en langage
naturel, soit dans le langage PROQUEL (PROgramming QUEry Language) |Benci& 89|.
Cette derniere solution etant preconisee en phase de speciIication par les auteurs de la
methode, nous la choisirons pour notre evaluation. Le langage PROQUEL est un langage de
manipulation et de programmation compatible avec SQL integrant des notions de variable
(simple ou structuree), de boucle, de procedure, de "trigger". Il permet de decrire des
algorithmes iteratiIs ou recursiIs ainsi que des calculs et des editions.
Les diIIerents concepts sont representes dans un Iormalisme graphique particulier :
C-Objet C-Evnement C-Opration
relation de modification
entre une C-Opration et
un C-Objet
relation de dclenchement
entre un C-Evnement et
une C-Opration
relation d'observation
d'un C-Evnement et
d'un C-Objet
C-Opration
itrative
C-Opration
conditionnelle
C
Figure 41 : Elements du schema conceptuel de REMORA
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 48
Le schema conceptuel regroupe les dependances mutuelles des C-Objets, C-Operations et C-
Evenements. La Iigure suivante |Rolland& 82| donne une representation graphique du sous
schema statique du cas IFIP ou les objets sont representes dans des cercle, les evenements
dans des triangles et ou les operations annotent les arcs.
Par exemple, la decision de Iaire une conIerence est un evenement (EV1) qui produit
l'identiIication de la conIerence (OP1), la deIinition d'un comite technique (OP2), la
deIinition d'un comite de programme (OP3) et d'un comite d'organisation (OP4), le choix des
presidents de session (OP5, OP6, OP7), la selection de la liste des personnes invitees (OPW)
et le choix de la date de reunion (OP8).
OB4
OB5 OB6 OB7 OB8 OB9 OB10 OB11 OB13
EV1
OB32
EV2
OP1
OP2
OP3
OP4
OP5
OP6 OP7
OP8
OP5
OP6
OP7
OP8
OB12
OB23
OB28
OB14
OB24
OB26
EV8
OB30 OB37
OB19
OB16
OB18
OB17
OB27
OB21
EVA
EV4 EV5
OB22
EV5'
OB20
EV4'
OB15
EV8
EV9
OPD
OPE
OPF
OPG
OPM
OPO
C4
OPQ
C4
OPP
C4
OPR
OPV
OPU
OPS
C5
OPT
C5
OPL
C3
OPK
OPH
C1 ^ C2
C2
EV7 EV3
EV6
OPN
Figure 42 : Schema dynamique du cas IFIP selon Remora.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 49
Nous ne developpons pas ici au sous schema conceptuel "dynamique" qui s'interesse aux
transactions. Nous considerons en eIIet que ce concept depasse le cadre de la speciIication
que nous nous sommes Iixe.
Une representation en troisieme Iorme normale des donnees, la prise en compte de la notion
d'evenement d'une maniere speciIique et la description des operations dans le langage
PROQUEL positionnent le modele de la methode REMORA tres proche de l'origine sur notre
premier reIerentiel.
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
Figure 43 : Evaluation de Remora sur le reIerentiel d'objectiI.
Malheureusement, l'amelioration de la richesse Ionctionnelle se Iait encore au prix du recours
a un langage imperatiI. De Iait, l'outil RUBIS |Benci& 89| permet de generer directement un
prototype operationnel a partir du modele et REMORA doit tre vue plus comme une
methode de developpement de systemes d'inIormation actiIs qu'en tant que Iormalisme de
speciIication au sens ou nous l'entendons.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
Figure 44 : Evaluation de Remora sur le reIerentiel qualitatiI.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 50
3.3.2. MCT de Merise
La modelisation des evenements par REMORA est interessante, neanmoins un Iormalisme
bien etabli pour modeliser le comportement d'un systeme soumis a des evenements a connu
des developpements Ieconds et constants depuis plus d'une trentaine d'annees : les reseaux de
Petri (RdP). Ils permettent non seulement une modelisation Iormelle abstraite des systemes a
evenements mais egalement une analyse poussee de proprietes diverses (vivacite,
reversibilite, invariants, ...). De plus un grand nombre d'extensions ont ete apportees au RdP
originel avec notamment les RdP de haut niveau capables de manipuler des donnees
structurees et sur lesquels nous reviendrons plus loin. Pour une synthese sur les Iondements
des RdP, le lecteur interesse pourra se reporter a l'annexe 3.
Le modele conceptuel des traitements (MCT) de Merise utilise des RdP place / transition
(a capacite) ou les transitions sont annotees par des predicats de pre et post condition et par la
reIerence a une operation.
Plus precisement, un evenement est modelise par l'occurrence d'un jeton dans une place.
On distingue levement externe qui se produit dans l'environnement du systeme reel et
levenement interne qui se produit dans le systeme d'inIormation. La capacite d'un type
d'evenement indique le nombre maximum d'occurrences d'un type d'evenement que le
moniteur dynamique peut accepter : elle est modelisee par la capacite associee a une place du
RdP. L'operation est une unite de traitement qui se deroule en un temps unitaire et qui
conserve l'integrite du systeme d'inIormation. Ces operations sont decrites en marge du reseau
dans un pseudo code structure Iaisant intervenir des elements de la modelisation des donnees
et des actions elementaires sur la base d'inIormation (insertion, eIIacement, recherche).
Une transition est annotee par une precondition, appelee regle de svnchronisation, et un
ensemble de postconditions, appelees regles demission. Chaque regle d'emission est associee
a un arc de sortie de la transition. Le declenchement d'une transition est conditionne par la
veriIication de la regle de synchronisation. Ce declenchement a pour eIIet de produire un
nouveau jeton dans une place de sortie a condition que la regle d'emission associee soit
veriIiee. De plus, une temporisation peut tre introduite au niveau de la regle de
synchronisation. En eIIet, celle-ci peut avoir duree limite d'attente au dela de laquelle les
evenements sont reinitialises si tous les evenements contributiIs ne sont pas arrives. par
deIaut la duree limite est inIinie. Un delai de svnchronisation est un temps d'attente entre
l'instant ou la synchronisation devient activable et ou elle est activee. Cette regle de tir Iait
intervenir plusieurs notions externes au reseau lui mme. Il est donc diIIicile d'appliquer au
RdP du MCT les proprietes comportementales habituelles des reseaux de Petri.
La description des processus par un pseudo code est relativement marginale dans le modele.
On Iait le choix de ne pas la prendre en compte dans notre evaluation aIin de preserver le
niveau d'abstraction du modele. De mme on convient que la description des donnees est
reportee sur le MCD. Par contre, on peut considerer que le MCT de Merise decrit de maniere
tres precise la dynamique du systeme d'inIormation.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 51
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
Figure 45 : Evaluation de MCT Merise sur le reIerentiel d'objectiI.
Si on considere le MCT comme un modele speciIique de description de la dynamique du
systeme, on peut considerer qu'il a un bon niveau d'abstraction et de precision. Par contre le
choix que nous avons Iait d'ignorer la description en pseudo code des operations reduit la
richesse Ionctionnelle. Si nous avions Iait un choix contraire, la position du modele serait
alors plutt du cote de l'axe d'abstraction.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
Figure 46 : Evaluation de MCT Merise sur le reIerentiel qualitatiI;
3.3.3. Rseaux de Petri objet
L'approche BIER (Behavior Integrated Entitv Relationship) combine les concepts du modele
entite-association avec les RdP de haut niveau, dans le but de traduire plus Iacilement le
modele conceptuel en un schema conceptuel d'une base de donnees a objets |Kappel& 88|.
Chaque place est liee a un type d'objet du schema statique, et chaque transition est liee a un
evenement qui modiIie l'etat d'un objet dans son cycle de vie.
C. Sibertin-Blanc |Sibertin-Blanc 91a|, |Sibertin-Blanc& 91b| propose un modele des
systemes base sur les objets. Dans ce cadre, un svsteme est un ensemble d'objets cooperatiIs.
Un obfet est deIini par sa structure, ses operations et son comportement. Le comportement
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 52
dvnamique des objets, ainsi que leurs interactions mutuelles sont modelisees Iormellement
par des RdP a objets.
Un RdP a obfets est un RdP de haut niveau ou l'ensemble des couleurs est un ensemble de
types elementaires ou de classes d'objets. Chaque place est annotee par un produit cartesien
de n types, n etant l'arite associee a la place. Chaque transition est annotee par une
precondition (Iormule booleenne dont les variables sont de type elementaire) et une suite
d'actions (aIIectations et/ou appels de procedures publiques d'un objet). Les arcs sont annotes
par des tuples de variables colorees et de constantes. Un item est une constante, ou un nom
d'objet. Un feton est un tuple d'items. Un marquage du reseau est donne par une Ionction de
distribution qui attribue un multi-ensemble de jetons a chaque place (respectant le typage de
la place), et par une Ionction d'evaluation qui attribue une valeur a chacun de ces jetons.
Une transition est validee si il existe une substitution des tuples annotant les arcs en entree
par les jetons presents dans les places d'entree qui valide la precondition de la transition. Le
tir d'une telle transition a pour eIIets de retirer des places d'entree les jetons lies aux variables
d'entree, d'executer en priorite les actions de creation d'objets, puis en parallele les autres
actions de la transition, et enIin d'afouter dans les places de sortie les jetons lies aux variables
de sortie. La communication entre reseaux permet une Iorme de hierarchisation. Les places
d'entree et de sortie du reseau permettent d'echanger des jetons avec l'environnement (ce
concept est comparable a la Iusion des places dans les reseaux colores hierarchiques |Jensen
92|). De maniere duale, les transition d'entree et sortie d'un reseau permettent d'echanger des
jetons avec les places d'entree/sortie d'autres reseaux. Le temps est pris en compte par
l'intermediaire de places particulieres, qui jouent le rle d'horloges. De plus, une Ientre
temporelle admissible peut tre associee a certains arcs.
Un systeme en general etant considere comme une collection d'objets cooperatiIs, la
demarche s'applique en particulier aux svstemes dinformation. Les phases organisationnelle,
conceptuelle et technique suivent donc chacune une demarche de conception orientee objet,
avec pour originalite le souci de la prise en compte du comportement dynamique. Pour la
modelisation conceptuelle, on distingue les objets actiIs (acteurs) et les objets passiIs
(entites). Les reseaux a objets sont ecrits sous une Iorme similaire a celle des reseaux de
Merise |Tardieu& 83|, avec pre et post conditions et suite d'actions annotant les transitions.
Considerons l'exemple de la description d'un ReIeree dans le cas IFIP. L'objet ReIeree
oIIre deux services : bemember et review. bemember est toujours disponible et retourne
true ou false. review est disponible pour les papiers de la conIerence si bemember retourne
true. Ainsi l'OBCS associe a l'objet ReIeree est compose de 2 transitions bemember et
review. bemember ne possede pas de place d'entree, il est toujours autorise et peut survenir
des qu'il est sollicite. La Ileche brisee a l'entree de la transition represente l'appel du service
associe a cette transition ayant pour parametre les variables indiquees. une Ileche brisee en
sortie represente la conIirmation de l'execution retournee au client etiquetee par les variables
de sortie. Les transitions comportant une Ileche d'entree possede le mme nom que le service
visible par le client. Selon la regle de declenchement de la transition, un element (le titre de la
conIerence) est place dans la place de sortie member a la seule condition que bemember
retourne true. Dans ce cas, la transition review est autorisee aussitt qu'elle reoit un jeton
paper, conIerence~.
La description de la classe ReIeree est Iaite dans un langage de programmation.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 53
Class ReIeree speciIication;
attributes
name : string;
adress : string;
busy : boolean;
colleague : Release;
operations
bemember(conIerence : string) return boolean;
receive(p : Paper);
examine(p : Paper) return Reviewsheet;
return() return Reviewsheet;
review(paper : Paper) return Reviewsheet;
OBCS
variable
conIerence : string;
OK : boolean;
paper : Paper;
eval : Revewsheet;
eval := review(paper)
OK := be_member(conference)
OK
not OK
conference
<paper, conference>
review
be_member
OK
conference
conference
close
conference
eval := examine(paper)
return(eval)
eval := colleague.review(paper, conference)
busy
eval
eval
eval
paper
eval
paper
paper
end_review
help
Figure 47 : OBCS de l'objet reIeree
La speciIication de l'OBCS d'un objet decrit completement son comportement externe
(services pour les clients) et interne (services pour lui mme). Ainsi review est une operation
decomposee en 3 etapes : recevoir le papier (transition receive), examiner le papier (transition
examine) et retourner le resultat de l'evaluation (transition endreview). Si un reIeree est
occupe (busv), il peut demander a un collegue d'examiner le papier a sa place (transition
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 54
help). Le reIeree agit ainsi comme un client. La transition close qui supprime un reIeree n'est
pas un service visible pour les autres objets, mais il s'agit d'un service pour les besoins
internes de l'objet.
Le cycle de vie d'un objet indique comment ses clients agissent sur son etat. Il ne Iait pas
partie de la deIinition de l'objet, mais peut tre considere comme un commentaire. Dans le cas
du papier, le papier est reu (transition receive) par le secretariat du comite de programme et
il est enregistre (transition register) s'il est arrive avant la date limite. Ensuite il peut tre revu
par 3 reIerees (transition review). Le comite de programme selectionne (transition select) les
papiers acceptes et rejetes, inIorme (transition notifv) les auteurs et programme (transition
form session) le papier dans une session s'il est accepte.
receive
PC meeting
date
else
dead_line > today
register
select
accepted rejected
form session
notify
review
created
Figure 48 : Cycle de vie de l'objet papier.
Les traitements, relatiIs a chaque entite sont decrits en termes de procedures. Une procedure
est decrite comme un RdP a objets, ou une place d'entree (ou plusieurs) reoit les messages
des autres objets, et ou les places de sortie memorisent les resultats de la procedure. Les
transitions representent les diIIerentes operations intervenant dans la realisation de la
procedure, et les arcs lies a une transition sont annotes par des variables de la mme classe
que les parametres de l'operation.
La prise en compte des objets dans le RdP lui mme permet une meilleure synergie entre la
description de la dynamique, des processus et des donnees, comparativement a d'autres
methodes basees sur les objets.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 55
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
Figure 49 : Evaluation de RdP Objet sur le reIerentiel d'objectiI.
Seule la description du comportement du systeme par le reseau de Petri preserve une part
d'abstraction. Les autres composantes sont directement decrites dans un langage de
programmation objet.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
Figure 50 : Evaluation de RdP Objet sur le reIerentiel qualitatiI.
3.3.4. Rseaux de Petri de haut niveau
Neanmoins, mme les RdP de haut de niveau habituels ne disposent pas de tous les concepts
utiles pour une modelisation naturelle des systemes d'inIormation. Notamment, la
manipulation d'ensembles comme parametres et une Iorme de negation existentielle semblent
indispensables. Malheureusement, mme si les reseaux CEM par exemple ont une base
Iormelle relativement simple et bien deIinie, il devient tres diIIicile d'adapter de maniere
realiste les methodes classiques d'analyse de proprietes Iormelles (analyse d'invariants, ...).
Or, une analyse des 'bonnes' proprietes est essentielle dans une demarche de modelisation
Iormelle. Il semble donc souhaitable d'adapter des methodes adequates a cette nouvelle
generation de reseaux de haut niveau.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 56
Les methodes basees sur les RdP a objets sont par nature liees aux mecanismes des
langages sous-jacents ('triggers', heritage, messages, ...). De mme, les reseaux de traitements
intervenant dans la phase conceptuelle de la methode M
*
Iont appel a plusieurs concepts
particuliers des langages relationnels. Cette contrainte conditionne la reutilisabilite, la Iacilite
de concretisation de la speciIication et d'une certaine maniere la puissance d'expression du
Iormalisme. Neanmoins, on peut souhaiter une plus grande independance du modele par
rapport au Iormalisme d'implantation, tout en gardant le souci d'un modele operationnel, voire
executable.
3.3.5. CEM
Plusieurs auteurs ont utilise les reseaux de Petri de haut niveau pour speciIier le
comportement dynamique du systeme d'inIormation, conjointement avec ses proprietes
statiques. Cette approche depasse la simple utilisation d'un reseau de Petri place-transitions
pour modeliser l'apparition d'evenements simples. Il s'agit ici de decrire precisement les
contraintes d'apparition de ces evenements et leurs eIIets sur les donnees, d'ou l'idee d'utiliser
des fetons individuels avec attributs des RdP de haut niveau pour modeliser ces changements
intervenant sur les donnees. Neanmoins, on peut ressentir le besoin de modiIier le Iormalisme
habituel des RdP de haut niveau (predicats-transitions, colores) dans le cadre speciIique de la
conception de systemes d'inIormation |Richter& 82|, |Richter& 92|.
Heuser, Peres et Richter |Richter& 93| proposent une integration dans le mme modele a
la Iois des proprietes statiques et du comportement dynamique du systeme, par la
combinaison du modele entite-association et des RdP de haut niveau. Ils utilisent une
extension des RdP colores, les Reseaux CEM ("compact Condition/Event Modeling Nets" en
version originale), qui autorisent notamment des annotations d'arcs a l'aide d'ensembles, et
des transitions "mortes" pour modeliser des contraintes statiques sur les marquages.
Plus precisement, les places sont annotees par un produit cartesien de noms de domaines,
qui deIinit le type des jetons apparaissant dans la place. De plus, chaque place peut tre
annotee par un ensemble de tuples denotant le marquage initial de la place. Chaque transition
est annotee par une Iormule de la logique du premier ordre, de maniere similaire a celle des
RdP a predicats-transitions. Les arcs sont annotes par des termes denotant des ensembles (de
cardinalite variable) ; pour representer des singletons, on utilise des accolades }. Dans ce
modele, on utilise des ensembles de preIerence aux multi-ensembles. Sur la Iigure 51, la
transition Rpartir Papier est annote par la contrainte CARD(refs) > 3], ou refs est un
sous-ensemble du domaine Ref, issu de la place Referee avec thme comme l'indique
l'annotation refs x th] sur l'arc allant vers la transition. On traduit ainsi qu'un papier doit tre
distribue a trois reIerees au moins.
On distingue deux types d'arcs : les arcs habituels des RdP, et les arcs "de restauration",
qui ne modiIient pas le marquage du reseau, et sont utilises pour simplement acceder a une
inIormation contenue dans une place, identiIies par une double Ileche (comme l'arc allant de
Referee avec thme vers Rpartir papier). De mme, il existe deux types de transitions : les
transition habituelles, dites "vivantes", et les transitions "mortes". Un marquage accessible ne
doit jamais valider une transition morte. Autrement dit, l'annotation d'une transition morte est
une Iormule du premier ordre dont la negation doit toujours tre veriIiee. Ainsi, la transition
tat2, annotee par la contrainte AUTEUR(pap)ref] traduit que le reIeree d'un papier ne
doit pas tre son auteur.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 57
Referee avec
thme
(ReI x Th)
tat1
|pap1 pap2|
etat2
|AUTEUR(pap)reI|
etat3
Rpartir
papier
|CARD(reIs)~3|
Papier avec
thme
(Pap x Th)
tat4
Fin rapport
(ReI x Pap x Rap
Rendre
rapport
Referee avec
papier
(ReI x Pap)
refs x pap]
Papier
identifi
(Pap x "Distribue","ADistribuer})
<ref,pap1>,
<ref,pap2>]
refs x th]
<ref,pap>]
<ref,pap>]
<ref,pap,rap>]
<ref,pap>]
<ref,pap,rap>]
<ref,pap>]
pap] x Th
<pap,th>]
<pap,"ADistribuer"]
<pap,
"Distribu">]
Figure 51 : reseau CEM du cas IFIP.
L'usage des transitions mortes permet de transIormer les schemas entite-association en
reseaux CEM : il suIIit en eIIet de traduire la contrainte statique sur les donnees exprimee par
le lien entite-association en Iormule du premier ordre, et d'annoter une transition morte avec
la negation de cette Iormule. Ainsi, on peut traduire la contrainte de cardinalite entre Papier
et Referee :
Papier
(Entite)
Distribution
(Entite)
Referee
(Entite)
tm1
tm2
tm3
p1 p2]
pap] <ref,pap>] ref]
<r,p1>,<r,p2>]
<ref,pap>]
Papier Distribution Referee
1 n
Figure 52 : exemple de transIormation de schema entite-association en reseaux CEM.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 58
Cette transIormation systematique donne un sens a la combinaison des schemas entite-
association et des reseaux CEM. La methode proposee consiste alors a enrichir le modele
entite-association avec des transitions vivantes, pour y ajouter des proprietes dynamiques du
systeme, et enIin les transitions mortes pour modeliser des proprietes statiques impossibles a
traduire en termes de contraintes entite-association.
Il est remarquable que les reseaux CEM modelisent dans un mme Iormalisme des
inIormations pertinentes et precises sur les donnees (contraintes d'integrite par les transitions
mortes), les processus (actions elementaires par les types d'arcs conditionnees les contraintes
de transition) et bien entendu, le comportement du systeme par le reseau lui mme.
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM
Figure 53 : Evaluation de CEM sur le reIerentiel d'objectiI.
Aucun compromis n'est Iait dans ce modele au niveau de l'abstraction. La richesse
Ionctionnelle et la precision sont bonnes. Nous pensons neanmoins qu'il est possible de les
ameliorer comme on le verra avec la presentation de notre modele base sur les reseaux
Iormels.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM
Figure 54 : Evaluation de CEM sur le reIerentiel qualitatiI.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 59
3.4. Langages formels
Nous n'avons pas jusqu'ici evoque les langages Iormels en tant qu'outils de speciIication
|Finance 79|, |Habrias 93|, |Levy& 86|, |Meyer& 81|, |Meyer 85|, |Monin 96|, |Partridge
90|, |Wirsing 93|. Nous ne detaillerons pas du tout la logique des predicats |Benzaken 91|,
|Levi& 93|, |Delahaye 88|, |Yim 89| qui ne prend pas en compte les aspects dynamiques
|Bellot& 95|, |BestougeII& 89|. Par contre il est interessant d'examiner plus en detail des
langages Iormels comme Z |Abrial 84|, |LightIoot 91|, |LightIoot 94|, RAISE |Prehn& 93|
ou VDM |Jones 93|. Le langage Z n'a pas ete conu dans un objectiI particulier et n'est pas
executable. Base sur la theorie des ensembles et le calcul des predicats et dote d'une qualite
d'abstraction, nous nous interesserons donc plus particulierement a Z. On pourra trouver une
comparaison en Z et VDM dans |Jones& 93|.
Le schema est la structure Iondamentale de Z. Syntaxiquement un schema se presente sous
la Iorme d'un cadre ouvert a droite et divise en deux parties horizontalement. On deIinit dans
la premiere partie les composants a l'aide des types (types elementaires, types de base ou
types construits). La deuxieme partie contient les contraintes logiques sur les composantes
precedemment deIinies. Le nom du schema apparat sur la ligne superieure du cadre
Periode
debut, fin :
debut fin
Figure 55 : Exemple de schema Z.
Ce schema deIinit en Iait un ensemble en comprehension, comme nous le voyons ci-
dessous.
Periode = {debut, fin | debut fin}
Figure 56 : Representation d'un schema Z sous la Iorme d'un ensemble en comprehension.
Une speciIication en Z comporte la deIinition de l'ensemble des etats susceptibles d'tre
pris par un systeme en donnant les contraintes qui s'appliquent aux composantes des schemas.
L'homogenete des concepts utilises dans le langage Z est une qualite remarquable. La notion
d'ensemble est le moyen d'expression universel : l'espace des etats du systeme est un
ensemble, les types sont des ensembles et mme les operations sont des ensembles, c'est-a-
dire des sous-ensembles du produit cartesien de l'ensemble des etats. Ainsi il est possible
d'eIIectuer sur les schemas des calculs comme pour les ensembles, ce qui oIIre une solution
elegante pour la decomposition d'un probleme.
Pour decrire une operation, Z utilise une notation decoree pour distinguer l'etat apres
l'operation de l'etat avant. La mise en relation de deux etats successiIs utilise la composition
des schemas. Par exemple, si Periode est l'etat avant, Periode' decrit l'etat apres, et la
contrainte Iigurant dans la deuxieme partie du schema decrit la relation entre les deux etats.
On remarquera l'expression Periode dans la premiere partie du schema Decaler10 qui est
une notation simpliIiee pour declarer Periode et Periode'. Cette operation consiste a decaler
la periode de 10.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 60
Decaler10
Periode
Periode'.debut = Periode.debut + 10
Periode'.fin = Periode.fin + 10
Figure 57 : Exemple d'expression d'une operation en Z avec changement d'etat.
La methode utilisee pour ecrire une speciIication en Z est incrementale. A partir d'un
cahier des charges, le speciIieur ecrira des clauses Z, representant chacune une Iormalisation
partielle d'une petite partie de ce document. Une Iois la Iormalisation du cahier des charges
terminee, des transIormations permettent de concretiser la speciIication en regroupant les
relations, en eliminant l'indeterminisme, ...
Les outils s'appliquant au langage Z ont tardivement Iait leur apparition. Les plus anciens
consistent a veriIier les types, mais depuis ces dernieres annees on observe un certain
engouement pour les langages Iormels, et en particulier pour Z. Aussi voit-on apparatre des
outils tels que l'atelier B |Keno 96|, des extensions objet de Z, Object-Z |Duke& 91|, |Smith
92|, dont la principale caracteristique est l'introduction de la notion de classe qui regroupe un
etat unique et des schemas d'operations pouvant l'aIIecter. |Laleau& 95| indique les points
delicats pour la generation d'une speciIication VDM a partir d'un schema conceptuel de
donnees. On peut trouver dans |Johnston& 93| un guide de conversion d'une speciIication en
Object-Z vers C. On pourra aussi trouver un point de vue sur les methodes Iormelles a
objets dans |Andre& 96|. Dans |West& 92| nous trouverons une proposition d'animation de
speciIication Z a l'aide de PROLOG
Nous reportons la description detaillee du langage Z en annexe 2 aIin de ne pas alourdir
notre propos. On trouvera dans cet annexe un exemple de speciIication d'un petit systeme
d'inIormation.
Les schemas Z sont capables d'exprimer des changements d'etats et peuvent donc rendre
compte du comportement dynamique d'un systeme. Neanmoins, on n'a pas de mecanisme
speciIique de gestion du contrle des evenements. Malgre d'excellentes capacites a modeliser
les evenements et les processus, Z ne se situe donc pas au centre de notre premier reIerentiel.
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM
Z
Figure 58 : Evaluation de Z sur le reIerentiel d'objectiI.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 61
Par contre le langage Z est l'archetype du langage de speciIication combinant a la Iois une
abstraction maximale avec une grande richesse Ionctionnelle et une absence d'ambigute.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM Z
Figure 59 : Evaluation de Z sur le reIerentiel qualitatiI.
Citons egalement l'existence d'extensions orientees objet de Z |Smith 92|, |Johnston& 93| et
VDM |Drr& 92|.
3.5. Bilan
La speciIication des traitements et la modelisation de la dynamique restent des problemes
diIIiciles, et les solutions proposees sont diverses. Nous avons passe en revu les principaux
modeles usuels. Le traitement du cas IFIP dans chacun de ces modeles permet de se Iaire une
idee des diIIerences d'esprit et de niveau de detail entre ces modeles.
Il Iaut bien reconnatre que la plupart des speciIications de traitements se limitent dans la
realite a un cahier des charges en langage naturel plus ou moins Iormalise. Elles ne permettent
ni une precision, ni une structuration suIIisantes pour la phase de conception.
Les modeles semi Iormels, pour la plupart graphiques, sont aussi tres utilises dans la
pratique : diagrammes de Ilux de donnees, SADT, JSD, Remora ... Le succes de ces modeles
est principalement d a leur simplicite : la lisibilite d'un modele graphique simple est une
excellente base de dialogue entre les utilisateurs et les inIormaticiens, plus structuree qu'un
cahier des charges en langage naturel. Neanmoins, un travail important reste a Iaire,
notamment sur les traitements qui sont souvent eux-mmes speciIies inIormellement par une
simple annotation en langage naturel sur le schema.
Les methodes basees sur les objets permettent d'atteindre un degre de precision plus Iin, et
une uniIication du modele des donnees et des traitements. Ainsi, OMT |Rumbaugh& 91| et
HOOD |Lai 90| ont suscite un intert croissant ces dernieres annees. Neanmoins, ces
methodes semblent se positionner dans le cycle de vie du logiciel plus pres de la conception
que de la speciIication : en eIIet, le niveau de detail doit prendre en compte des aspects de
l'implantation eIIective pour tre complet, et la nature du langage inIormatique choisi
intervient a une certaine etape de la methode |Pittman 93|.
A l'inverse, les langages Iormels bases sur la theorie des ensembles comme Z ou VDM
autorisent un tres haut niveau d'abstraction. La methode B decrit diIIerentes etapes de
concretisation aIin d'aboutir a une implantation Iinale certiIiee par rapport a la speciIication
initiale, ce qui est tres precieux pour des applications 'sensibles' sur le plan de la securite
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 62
|Boulanger& 95|. Il Iaut cependant reconnatre que les bases mathematiques requises ne sont
pas negligeables, et qu'un utilisateur non initie aura du mal a saisir les subtilites d'une
speciIication Iormelle.
En somme, parmi les qualites attendues d'un modele des traitements, on peut souligner
l'expressivite (au sens lisibilite et concision), la precision du Iormalisme, et la clarte de la
semantique sous-jacente. Les reseaux de Petri (RdP) ont Iait la preuve de telles qualites,
notamment pour la modelisation de systemes concurrents. Le modele conceptuel des
traitements de Merise utilise une extension simple des RdP.
On observe sur le reIerentiel d'evaluation lie aux qualites de speciIication un groupe de
modeles situe sur la droite de l'axe d'abstraction. Il s'agit donc de modeles ayant un bon degre
de precision et de richesse Ionctionnelle, mais dont la description des traitements est basee sur
un pseudo code, voire un langage de programmation. Typiquement, on retrouve ici les
methodes objets.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM Z
Figure 60 : Regroupement des modeles sur le reIerentiel d'objectiI.
Ce groupe de modeles se retrouve assez pres du centre de notre autre repere d'evaluation. Si
donc ces modeles rendent bien compte de la globalite du systeme, ils ne peuvent
malheureusement pas tre retenu comme de bons outils de speciIication a cause de leur
manque d'abstraction.
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 63
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM
Z
Figure 61 : Dispersion des modeles sur le reIerentiel qualitatiI.
L'homogenete est un critere qui n'apparat pas dans nos reIerentiels. La plupart des points qui
apparaissent sur nos schemas regroupent en Iait plusieurs modeles dont l'integration n'est pas
toujours clairement decrite. Seuls les modeles de Merise ont ete etudies separement. Le
regroupement du MCD, du DFD (MCC) et du MCT positionnerait Merise plus au centre des
diagrammes |RochIeld& 91|. La conjonction des trois modeles de Merise pourrait donc tre
utilisee dans la phase de speciIication malgre deux inconvenients : l'integration des modeles
n'est pas deIinie Iormellement, et la description du texte des processus et des traitements
manque d'abstraction (pseudo code).
Deux modeles ressortent de cette etude : d'une part l'extension CEM des RdP de haut niveau
pour son Iort niveau d'integration et d'abstraction, et d'autre part le langage Z pour son
adequation a la speciIication.
En eIIet, le modele RdP oIIre un Iormalisme graphique lisible d'une speciIication, et une
adequation naturelle pour l'expression des aspects dynamiques d'un systeme. De plus, le cadre
general de la description du comportement d'un RdP permet une grande souplesse d'une
integration de concepts de haut niveau |Jensen 90|, |Shapiro& 90|, |Sibertin-Blanc 90a|,
|LeIort 93|, comme la logique du premier ordre dans les RdP predicats/transitions |Genrich
87|. Pour une speciIication complete d'un SI, nous avons besoin d'un Iormalisme plus riche
que les RdP de haut niveau. Nous avons vu que les reseaux CEM sont une tentative dans ce
sens, malgre une expressivite Ionctionnelle encore un peu insuIIisante pour exprimer
completement les traitements. Nous introduirons dans les RF des contraintes a trois niveaux,
et de nouveaux types d'arcs.
L'enrichissement de la semantique des RdP pose un probleme important : mme si les
extensions semblent naturelles, et simples a saisir intuitivement, il devient diIIicile de decrire
rigoureusement le comportement correspondant. Nous pourrions utiliser des techniques de
semantique operationnelle de la theorie des langages. Neanmoins, ces techniques sont souvent
obscures pour le non-specialiste, et nous souhaitons proposer un outil certes rigoureux, mais
aussi largement accessible. Nous contournerons donc la diIIiculte en decrivant des schemas
de transIormation permettant d'interpreter un RF comme une speciIication Z. Insistons sur le
Iait que les speciIications Z sont totalement transparentes, et n'interviennent explicitement a
aucun endroit du RF. Nous esperons ainsi tirer proIit de la puissance et de la rigueur d'un
Evaluation des modeles existants pour la speciIication des systemes d'inIormation 64
langage Iormel, tout en evitant l'aspect parIois ardu et peu lisible des schemas Z par l'usage
d'un Iormalisme graphique simple, et d'annotations par des contraintes elementaires.
Nous nous baserons sur le cas IFIP pour illustrer la capacite de notre Iormalisme a prendre
en compte l'expression des besoins du cahier des charges de maniere precise et abstraite.
Ensuite nous montrerons une utilisation des reseaux Iormels pour supporter une demarche de
retro conception d'une application. Celle-ci validera la capacite de notre modele a supporter
une abstraction et aussi son utilite dans la phase de developpement.
Les Reseaux Formels 65
4. Les Rseaux Formels
Nous avons decrit les qualites d'un Iormalisme de speciIication selon un axe d'abstraction, un
axe de precision et un axe de richesse Ionctionnelle, et nous recherchons un tel Iormalisme
pour decrire les trois composantes statique, dynamique et processus d'un systeme
d'inIormation. Nous introduisons donc les reseaux Iormels, un modele convivial
particulierement adapte a la speciIication des traitements des systemes d'inIormation et
exploitable par l'inIormaticien pour les phases de production de logiciel.
Les reseaux Iormels enrichissent le Iormalisme des RdP de haut niveau en introduisant de
nouveaux types d'arcs aIin traduire l'eIIet d'actions elementaires, comme l'insertion, la
consultation, la suppression, etc. ainsi que des contraintes sur les places, les marquages et les
transitions |Cadivel& 95a, b|.
Indiquons qu'une contrainte est en Iait une Iormule entre les variables d'un probleme qui
est dite satisIiable s'il existe une liaison qui la rende vraie. Les contraintes permettent
d'exprimer toute sortes de relations sans presager d'une implementation particuliere. La
diIIerence entre une expression dans un langage imperatiI et une expression sous Iorme
contrainte est mise en evidence par le traitement de l'egalite. Les langages imperatiIs utilisent
generalement deux operateurs distincts pour l'aIIectation et l'egalite (: et en pascal par
exemple). Dans une expression de contrainte, l'operateur d'aIIectation n'est pas necessaire, on
n'utilise que l'operateur d'egalite, et c'est la resolution de contraintes qui "aIIecte" les valeurs
des variables qui rendent les relations d'egalite vraies. En particulier, l'expression x: x1
d'un langage pascal par exemple est a distinguer avec la contrainte x x 1 qui est toujours
Iausse. Une expression dans les langages imperatiIs sont orientees, c'est-a-dire qu'on Iait une
diIIerence entre les arguments en entree et les resultats en sortie. En revanche, cette
distinction n'existe pas dans une contrainte. Par exemple, la contrainte de conversion de
degres Celsius en Fahrenheit (F 9/5 C 32) permet de calculer aussi bien F en Ionction de
C que C en Ionction de F. L'ordre d'apparition des instructions dans une expression de
contraintes n'a pas d'importance contrairement au cas d'une expression dans un langage
imperatiI. Par exemple, l'expression imperative Y : 2; X : Y; Y : 2 1; n'est pas
equivalente a Y : 2; Y : 2 1, X : Y. Mais, bien que les contraintes permettent une
speciIication du probleme, il est tentant d'exprimer directement les contraintes dans le
Iormalisme des outils existants. Il peut alors y avoir conIusion entre speciIication et
implementation. Notre but n'est pas ici de deIinir des speciIications executables, nous
utiliserons donc les contraintes dans un cadre moins Iormels, avec pour objet de Iaire des
transIormations plutt que pour rechercher des solutions ou Iaire des simulations.
Notre utilisation des contraintes dans les reseaux Iormels est celle correspondant a
l'utilisation du langage Z. Il s'agit d'une Iorme d'expression naturelle pour representer un
probleme. En eIIet, les contraintes permettent des representions implicites des ensembles. Par
exemple E x : salaire(x) ~ 35000 et poste(x) cheI } est l'ensemble de tous les x cheI
ayant un salaire plus grand que 35000. Les contraintes peuvent ainsi tre structurelles, c'est-a-
dire decrire la structure des objets, ou Ionctionnelles, c'est-a-dire decrire le comportement du
systeme. Pour une presentation plus rigoureuse de la semantique des contraintes, on pourra se
reporter a l'annexe 2 ou a |Fron 94|, |Cadivel 89|.
Ces deux aspects se retrouvent dans notre Iormalisme de reseau Iormel respectivement sur
les places et sur les transitions. Quant aux contraintes de marquage, elles s'appliquent aux
contenus des places et peuvent tre vu comme la caracterisation d'une structure ou d'un
comportement selon le point de vue de l'utilisateur. L'abstraction du modele est garantie par
une deIinition purement Iormelle du comportement du reseau en utilisant une semantique
Les Reseaux Formels 66
basee sur le langage Z. Soulignons neanmoins que la syntaxe Z n'apparat a aucun moment
sur le reseau et que les annotations se limitent a des ensembles de contraintes elementaires.
4.1. Un exemple pdagogique : le problme des rservoirs
Avant de deIinir precisement la semantique des reseaux Iormels, il nous parat utile
d`introduire les concepts essentiels du modele en speciIiant un petit exemple. Dans l`enonce
habituel du probleme des reservoirs, on dispose de deux reservoirs, l`un de cinq litres, l`autre
de sept litres. On peut remplir ou vider un reservoir, ou transvaser le contenu de l`un dans
l`autre. Le but du jeu est d`arriver a un etat Iinal ou l`un des reservoirs contient exactement
quatre litres.
Les inIormations necessaires pour deIinir un reservoir sont donc le contenu et la capacite,
qu`ont peut representer comme des valeurs reelles. De plus, il est evident que le contenu d`un
reservoir doit toujours tre positiI, et inIerieur a la capacite. On deIinit donc Iormellement la
place Reservoir par le schema :
Reservoir
contenu, capacite :
contenu capacite
contenu 0
ou, sous une Iorme plus concise :
Reservoir == contenu, capacite : | contenu capacite contenu 0
Ce schema deIinit un tvpe, qui est l`ensemble de toutes les liaisons possibles respectant le
schema. Si maintenant on deIinit la place Reservoir comme une place 'sac, un marquage de
cette place, note Reservoir ```````` , sera un multi-ensemble de liaisons du type Reservoir. Pour notre
probleme, les deux reservoirs sont vides a l`origine, on a donc deux liaisons pour l`etat initial,
qu`on peut nommer M
0
:
M
0
Reservoir ```````` = [ contenu0, capacite5 , contenu0, capacite7 ]
Si le nombre de liaisons pour un marquage est important, il peut tre pratique d`adopter
une notation sous Iorme de table :
M
0
.Reservoir :
contenu capacite
0
0
5
7
Dans le cas general, on doit deIinir autant de tables que de places non vides. Le lecteur
habitue au calcul relationnel peut se demander, au vu de cette notation, quelle est la diIIerence
entre une liaison et une relation. D`une part, les liaisons doivent veriIier la contrainte du
schema auxquelles elles se rapportent (ici Reservoir). D`autre part, les variables ne sont pas
necessairement liees a une valeur : elle peuvent tre liees a une autre variable, ou simplement
contraintes.
Les Reseaux Formels 67
AIin de speciIier les actions, nous conviendrons de noter Reservoir une variable
representant une liaison avant l`action, et Reservoir apres l`action. Ainsi, vider un reservoir
revient a lier son contenu a 0 :
Reservoir.contenu 0
la capacite restant bien sr la mme :
Reservoir.capacite Reservoir.capacite
De la mme maniere, remplir un reservoir vide consiste a ajuster le contenu a la capacite :
Reservoir.contenu 0
Reservoir.contenu Reservoir.capacite
Reservoir.capacite Reservoir.capacite
Transvaser un reservoir dans un autre est un peu plus complexe. Il y a deux manieres de
proceder. Ou bien on verse le contenu du premier jusqu`a ce que celui-ci soit vide, et le
contenu du second est bien sr la somme du contenu des reservoirs avant l`action :
Reservoir
1
.contenu 0
Reservoir
2
.contenu Reservoir.contenu
1
Reservoir.contenu
2
Ou bien, on transvase jusqu`a ce que le second soit plein :
Reservoir
1
.contenu Reservoir.contenu
1
- (Reservoir.capacite
2
- Reservoir.contenu
2
)
Reservoir
2
.contenu Reservoir.capacite
2
Dans l`un et l`autre cas, les capacites restent comme toujours constantes. Une action
s`applique a condition que les contraintes sur la place soit respectees : par exemple, on ne
peut pas vider completement un reservoir dans un autre si on depasse la capacite de ce
dernier.
La Iigure 62 represente un reseau Iormel resumant la speciIication du probleme des
reservoirs. Les annotations sur les arcs representent le nombre de variables en jeu dans
l`action associee. Les contraintes ont ete portees directement sur la Iigure, en annotations des
transitions et de la place. Pour des problemes plus complexes, ces annotations pourront tre
ecrites separement du dessin, sous la Iorme qu`on a utilisee precedemment.
Les Reseaux Formels 68
Rservoir
Transvaser
Rempli
r
Vider
Rservoir.contenu = 0
Rservoir.capacit = Rservoir.capacit
Rservoir.contenu = 0
Rservoir.contenu = Rservoir.capacit
Rservoir.capacit = Rservoir.capacit
contenu, capacit : R
contenu capacit ^ contenu 0
(Rservoir1.contenu = 0 ^
Rservoir2.contenu = Rservoir1.contenu + Rservoir2.contenu ^
Rservoir1.capacit = Rservoir1.capacit ^
Rservoir2.capacit = Rservoir2.capacit )
v
(Rservoir1.contenu = Rservoir1.contenu - (Rservoir2.capacit - Rservoir2.contenu) ^
Rservoir2.contenu = Rservoir2.capacit ^
Rservoir1.capacit = Rservoir1.capacit ^
Rservoir2.capacit = Rservoir2.capacit )
Figure 62 : Reseau Iormel pour le probleme des reservoirs.
Sur ce reseau, l`outil NetSpec, base sur des techniques de PLC (Programmation Logique a
Contraintes), permet de resoudre le probleme sans diIIiculte, en enumerant toutes les
sequences de tirs respectant les contraintes depuis un marquage initial jusqu`a un marquage
Iinal.
4.2. Dfinition formelle avec le langage Z
Un reseau formel est construit graphiquement en reliant des places et des transitions par des
arcs, comme un reseau de Petri habituel. La puissance d`expression du modele reside dans les
annotations et decorations de ces diIIerents elements. Le comportement attendu d`un reseau
Iormel, s`il demeure intuitiI pour l`utilisateur, devient diIIicile a deIinir rigoureusement avec
les methodes habituelles des reseaux de Petri. Apres avoir examine plusieurs Iormalismes, il
nous a semble que le langage Z soit le plus adapte a notre probleme. En eIIet, nous avions
besoin a la Iois d`operateurs ensemblistes puissants, de variables logiques, et de changements
d`etats et ces trois points sont rarement traites ensemble dans le mme Iormalisme. Chaque
annotation du reseau est associee a un schema Z, donc le reseau complet est associe a une
speciIication Z. Cette speciIication pourra ensuite tre analysee, enrichie et concretisee avec
les outils disponibles pour le langage Z. Nous donnons dans cette partie les principaux
modeles de schemas Z correspondant aux annotations de places, d`arcs et de transitions. La
signiIication des elements de Z utilises sera brievement expliquee quand elle n`est pas
evidente. Il convient de souligner que ces modeles de schemas ne sont pas eux-mmes des
Les Reseaux Formels 69
schemas Z : par exemple, certaines variables sont representees comme des decorations de
noms de places, et ne deviennent donc des variables Z que pour un nom concret de place (la
genericite de Z ne s`applique pas dans ce cas).
Dfinition 1
Un tuple (P,T,A,N,W,D,S
P
,C
T
,C
M
,M
0
) est un reseau formel si :
(i) P,T et A sont des ensembles Iinis et disjoints denotant respectivement les places, les
transitions et les arcs du reseau
(ii) N : A (P T ) (T P ) est une Ionction qui a chaque arc associe son noeud
d'entree et son noeud de sortie.
(iii) W : A N est une Ionction qui a chaque arc associe une ponderation
(iv) D : A consommation, production, information, information negative, information
etoile, consommation etoile, production etoile, par defaut } est une Ionction qui a
chaque arc associe une decoration (un type d'arc)
(v) entre deux noeuds, il n'y a pas plus d'un arc de chaque type
(vi) S
P
: P Z
,J
est une Ionction qui associe a chaque place du reseau un schema Z
(vii) C
T
: T L
,J
associe a chaque transition une Iormule de premier ordre, appelee
contrainte de transition
(viii) C
M
est une Iormule de L
,J
, appelee contrainte de marquage
(ix) M
0
est une Ionction d'initialisation, qui a chaque place p associe un multi-ensemble
de liaisons note M
0
.p coherent avec le schema de la place p et avec la contrainte de
marquage C
M
Remarques
(i),(ii) On revient ici au point de vue de Jensen |Jensen 92|, qui autorise plusieurs arcs entre
deux noeuds. En Iait, l'existence de plusieurs types d'arcs oblige cette convention : il
n'est pas possible de contracter les arcs en un seul par sommation des expressions sur
les arcs, comme dans les RdP colores.
(iii) La ponderation d'un arc denote en Iait le nombre de variables qui seront generees pour
cet arc.
(iv) La decoration des arcs permet une grande souplesse dans la deIinition du
comportement des reseaux Iormels. On retrouve certaines des annotations des reseaux
CEM |Richter& 93|, a quelques nuances pres.
(v) Il est necessaire d'interdire la presence de plusieurs arcs du mme type entre deux
noeuds, aIin d'eviter des conIusions au niveau du nommage automatique des variables
locales aux arcs.
(vi) Le schema Z revient d'une certaine maniere a deIinir le tvpe des liaisons admises par
la place. Neanmoins la deIinition d'un schema est plus Iine que la declaration d'une
couleur associee a une place, notamment grce aux contraintes qui peuvent annoter le
schema. D'autre part, la notion de liaison est dynamique, et permet par exemple
l'usage de valeurs incompletement connues. Les variables locales a un schema de
place peuvent tre vues comme des attributs de la place. La variable x de la place p est
notee p.x a l'exterieur de la place. Les mmes noms de variables peuvent donc tre
utilises dans des places diIIerentes sans risque de conIusion.
(vii) Les diIIerentes annotations sur les arcs, et les contraintes de transition permettront de
generer automatiquement les schemas Z associes, qui deIiniront le comportement du
reseau.
Les Reseaux Formels 70
(viii) La contrainte de marquage est une contrainte globale, qui s'applique a tous les
marquages possibles du reseau. Ce type de contrainte permet par exemple d'exprimer
des interactions entre diIIerentes places.
(ix) Le marquage initial associe des liaisons aux variables declarees dans les schemas de
place. Un marquage n'est donc pas necessairement clos.
La declaration d`une place est un schema simple, declarant les variables (attributs) de la place
P et les contraintes sur ces variables C
P
(cI. la place Reservoir de l`exemple precedent) :
P
declaration des variables de la place
C
P
On distingue graphiquement les places 'sacs, representees par un cercle simple, et les places
'ensembles, representees par un cercle double :
* *
Clients
Clients_sans_doublons
Enlever_doublons
Clients_sans_doublons = Clients
Figure 63 : exemple de places 'sac et 'ensemble
Les diIIerents etats du reseau respectent le schema Marquages, dans lequel P` denote l`etat
d`une place P. Si P est une place 'sac, P est un multi-ensemble construit sur l`ensemble des
parties des liaisons possibles de la place P. Dans le cas d`une place 'ensemble, P` est
simplement un sous-ensemble des liaisons possibles :
Marquages
P
1; ...
S
1; ...
P`
1
: bag P
1
...
S `
1
: bag S
1
...
C
Marquages
Dans la description d`un reseau, on omettra en general la partie declaration de ce schema
(deIinie implicitement par le dessin du reseau) : seule la contrainte CMarquage apporte une
inIormation supplementaire. Supposons que pour le probleme des reservoirs, nous voulions
empcher deux reservoirs diIIerents d`avoir la mme capacite :
Les Reseaux Formels 71
Marquages
Reservoir ````````
1
: bag P
f
1
; f
2
: Reservoir , f
1
Reservoir ```````` , f
1
Reservoir ```````` f
1
f
2
f
1
.capacite f2.capacite
Cette contrainte est tres courante dans la speciIication de systemes d`inIormation par exemple
(contrainte de cle). Aussi, nous adoptons une convention pour la rendre implicite : tout
attribut souligne dans la declaration d`une place est soumis a cette contrainte de marquage
(deux liaisons diIIerentes doivent avoir un lien diIIerent pour cet attribut). On pourrait ainsi
reecrire la declaration de Reservoir :
Reservoir
contenu, capacite :
contenu capacite
contenu 0
Une action sur une place 'sac avec contrainte de cle n`a pas le mme comportement qu`une
action sur une place 'ensemble : dans le premier cas, si elle ne respecte pas la contrainte de
cle, elle ne pourra tre executee, dans l`autre cas, elle sera executee, mais l`etat ne changera
pas. AIin de modeliser plus precisement les changements d`etat, il est necessaire d`introduire
les schemas d`arcs.
Considerons par exemple un arc avec Ileche, partant d`une place 'sac P vers une
transition T, annote par un label l, avec l ~ 0. Un tel arc denote la consommation de l jetons
dans la place :
o|
l
P
T
Marquages
P
1
, . , P
l
: P
P
1
E P` ; . ; P
l
E P`
P`` P` | P
1
, . , P
l
|
Dans la declaration de ce schema, la notation Marquages indique en Z qu`il y a changement
d`etat de Marquages vers Marquages (toutes les variables de Marquages` etant elles-mmes
decorees par `). Les variables P
1
, . , P
l
sont du type deIini par le schema de P, et la
contrainte precise qu`elles representent des liaisons contenues dans le multi-ensemble P ,
dans l`etat Marquages. L`etat P ` est obtenu en retranchant de l`etat P les liaisons satisIaisant
les contraintes portant sur P
1
, . , P
l
(l`operateur
-
denote en Z la diIIerence sur les multi-
ensembles). Il est important de noter ici que ce changement d`etat est non-deterministe : il
peut clairement y avoir plusieurs liaisons satisIaisant les contraintes portees sur une variable
d`arc. Remarquons egalement que ces contraintes sont principalement deIinies dans le schema
de la transition, que nous etudierons plus loin.
Sur notre exemple, l`arc allant vers la transition Transvaser est deIini implicitement par le
schema :
Les Reseaux Formels 72
o|
2
Reservoir
Transvaser
Marquages
Reservoir
1
, Reservoir
2
: Reservoir
Reservoir
1
Reservoir ````````
Reservoir
2
Reservoir ````````
Reservoir ```````` ` Reservoir ```````` | Reservoir
1
, Reservoir
2
|
Dans le cas ou l 1, on peut omettre le label :
o|
Reservoir
Remplir
Marquages
Reservoir : Reservoir
Reservoir Reservoir ````````
Reservoir ```````` ` Reservoir ```````` | Reservoir |
Le label, s`il n`est pas un entier strictement positiI, peut tre une etoile. Dans ce cas, on
introduit une variable supplementaire P
*
qui represente le (multi-)ensemble des liaisons
possibles de la variable P . Cette variable peut tre Iort utile pour exprimer par exemple une
contrainte sur la cardinalite d`un ensemble veriIiant une certaine condition, ou la somme des
valeurs d`un attribut... Le schema d`un arc consommation 'etoile sur une place 'sac a la
Iorme suivante :
o|
*
P
T
Marquages
P : P
P
*
: bag P
P P`
P
`
= P
P` P` P
*
On deIinit de maniere similaire les arcs de production, en introduisant les variables P
1
, . ,
P
l
. L`operateur + deIinit l`addition de multi-ensembles. Un tel arc ajoute donc des liaisons
dans la place.
|o
l
T
P
Marquages
P
1
, . , P
l
: P
P`` P` | P
1
, . , P
l
|
Sur notre exemple, le schema implicite deIini par l`arc de Remplir a Reservoir a la Iorme :
Les Reseaux Formels 73
|o
Remplir
Reservoir
Marquages
Reservoir : Reservoir
Reservoir ```````` ` Reservoir ```````` | Reservoir |
Les arcs d`information ne modiIient pas le marquage, ce qu`on exprime en Z par la notation
Marquages.
o|
l
P
T
Marquages
P
1
, . , P
l
: P
P
1
P` ; . ; P
l
P`
Les arcs d`information negative posent a l`inverse une contrainte de non-appartenance a la
place :
o |
l
P
T
Marquages
P
1
, . , P
l
: P
P
1
P` ; . ; P
l
P`
Les arcs par defaut ne modiIient pas le marquage non plus. Ils introduisent une nouvelle
variable qui prend la valeur par deIaut '' dans le cas ou la contrainte d'appartenance au
marquage n'est pas satisIaite :
o|
P
T
Marquages
P : P
P
: P }
( P P` ; P
P ) ( P P` ; P
)
Chacun des schemas d`arcs precedemment decrits a un equivalent immediatement
transposable pour les places 'ensembles. Les quatorze schemas d`arcs sont listes en annexe
4.
Une transition est deIinie comme la composition respectivement des arcs d`inIormation, de
consommation et de production. Attention, l`ordre de cette composition est important : les
arcs de consommation doivent preceder les arcs de production. De plus, le schema d`une
transition integre la contrainte relative a cette transition. Sur notre exemple, le schema de la
transition Remplir est donc :
Les Reseaux Formels 74
|
Remplir
Marquages
o|
Reservoir
Remplir
; |o
Remplir
Reservoir
Reservoir.contenu Reservoir.capacite
Reservoir.capacite Reservoir.capacite
Reservoir.contenu 0
Dans la suite, nous ecrirons plus volontiers tir d`une transition qu`execution d`une
transition.
Les Reseaux Formels 75
4.3. Spcification du cas IFIP
Nous pouvons d'apres les speciIications en langage naturel (voir annexe 1) du cas IFIP,
extraire du texte les noms de place, accompagnees des attributs, des cles de contrainte des
jetons, et des contraintes de place, dont la liste est donnee par le tableau 2.
Apres la lecture du texte, nous voyons que pour un courrier quelconque, il Iaut memoriser
le nom de lauteur, la date darrivee, ainsi que la version (lettre, provisoire, ou deIinitiI), car
ces inIormations sont souvent reIerencees dans les speciIications. Un courrier est donc une
place du reseau Iormel, et un jeton de cette place possede au moins les trois attributs cites,
dont le typage est evident. L'hypothese que nous pouvons Iaire sur un courrier, est qu'il nous
Iaut un moyen simple et eIIicace de l'identiIier; etant donne que ses attributs ne le peuvent
pas, nous avons decide de creer un quatrieme attribut, qui n'apparat pas dans le texte, sous la
Iorme d'une reference (cette technique est tres classique en MERISE). Nous pouvons bien sr
Iaire Iigurer d'autres attributs si necessaire, mais dans notre cas, ces derniers seraient
superIlus.
Toujours d'apres le texte (clause C1), nous voyons que les auteurs inconnus doivent tre
memorises: nous creerons donc une place auteur, dont le seul attribut est le nom de lauteur.
Comme un auteur ne peut tre enregistre plus d'une Iois, cet attribut est donc un identiIiant
(au sens MERISE du terme) et devient une cle de contrainte: toute tentative d'enregistrement
d'un auteur deja connu devra se solder par un echec.
D'autre part, nous serons egalement amene a creer des contraintes de cle multiples pour
certaines place (par exemple pour la place note): en eIIet, la reference ne suIIit pas pour
identiIier a coup sr un jeton de cette place, puisque les notes d'un courrier sont attribuees par
plusieurs reIerees, et le veritable identiIiant est la concatenation de la reference et du nom du
referee.
Finalement, et pour rendre le systeme plus robuste, certains attributs se verront associer
des contraintes de place: un jeton ne pourra tre produit que si l'un ou plusieurs de ses
attributs possedent des valeurs permises: c'est le cas pour la place profet, dans laquelle seuls
les courriers provisoires ou les lettres d'intention peuvent exister (les courriers deIinitiIs sont
produits dans une autre place).
Les Reseaux Formels 76
place attribut(s) et cle(s) de contrainte des jetons
contrainte de place
courrier reIerence: entier
nomauteur: chane de caracteres
datearrivee: date
version: chane de caracteres
version 'lettre','provisoire','deIinitiI'}
auteur nom: chane de caracteres
derogation reIerence: entier
accord:'oui','non'}
projet reIerence: entier
nomauteur: chane de caracteres
datearrivee: date
version: chane de caracteres
version 'lettre','provisoire'}
papier reIerence: entier
nomauteur: chane de caracteres
membre nom: chane de caracteres
repartition reIerence: entier
nomreIeree: chane de caracteres
reIeree reIerence: nom
nom: chane de caracteres
renommage reIerence: nom
anciennomreIeree: chane de caracteres
nouveaunomreIeree: chane de caracteres
Iinnotation etat: chane de caracteres etat 'oui','non'}
notation reIerence: entier
nomreIeree: chane de caracteres
notesujet: reel
notequalite: reel
notebiblio: reel
0.0 notesujet 10.0
0.0 notequalite 10.0
0.0 notebiblio 10.0
note reIerence: entier
nomreIeree: chane de caracteres
notesujet: reel
notequalite: reel
notebiblio: reel
moyenne reIerence: entier
nomauteur: chane de caracteres
valeur: reel
reIus reIerence: entier
nomauteur: chane de caracteres
ballottage reIerence: entier
nomauteur: chane de caracteres
acceptation reIerence: entier
nomauteur: chane de caracteres
deIinitiI reIerence: entier
nomauteur: chane de caracteres
datearrivee: date
decision reIerence: entier
accord: chane de caracteres
accord 'oui','non'}
avis reIerence: entier
accord: chane de caracteres
accord 'oui','non'}
session reIerence: entier
nompresentateur: chane de caracteres
invitation reIerence: entier
nominvite: chane de caracteres
datelimite: date
reponse reIerence: entier
dateremise: date
Tableau 2 : Places, attributs, et contraintes de place
Les contraintes de transitions, egalement derivees des speciIications, sont regroupees dans le
tableau 3.
Le probleme a resoudre est ici de trouver le moyen par lequel un jeton d'une place donnee,
peut donner naissance a un jeton dans une autre place. Une Iois ce moyen decouvert, une
transition est creee, associee a des arcs partant des places concernees, ou arrivant aux places
concernees.
Les Reseaux Formels 77
D'apres la clause C1 du texte, chaque nouveau courrier dont l'auteur est inconnu implique
la memorisation du nom de l'auteur dans la place auteur. Il existe donc une transition entre les
places courrier et auteur, dont les arcs sont une inIormation depuis la place courrier et une
production vers la place auteur.
Pour indiquer la maniere dont est produit un jeton dans une place, des actions seront
speciIiees, qui sont destinees a donner des valeurs aux attributs du jeton produit. Ces actions
peuvent utiliser tout ou partie des valeurs des attributs des jetons circulant sur les arcs
inIormation ou consommation.
L'action associee a la transition enregistrerauteur indique que la valeur de l'attribut nom
du jeton produit dans la place auteur provient de la valeur de l'attribut nomauteur du jeton
concerne dans la place courrier. Cette action est donnee sous la Iorme
auteur.nomcourrier.nom_auteur et sa signiIication est: l'attribut nom du jeton dans la
place auteur apres la transition est egal a l'attribut nomauteur du jeton dans la place courrier
avant la transition.
Le Iait que l'attribut nom d'un jeton de la place auteur soit cle de contrainte, nous interdit
de Iaire transiter un jeton entre les places courrier et auteur si l'auteur est deja connu,
puisqu'une cle de contrainte doit tre unique par deIinition. Le probleme d'enregistrement
multiple d'un auteur trouve donc une solution immediate. Cependant une cle de contrainte ne
regle pas tous les problemes et nous devons imposer dans la plupart des cas des contraintes de
transition.
Un courrier reu donne lieu a la creation d'un projet, uniquement si ce courrier arrive avant
la date de clture, et si celui-ci est soit une lettre d'intention, soit un courrier provisoire. Ces
deux conditions sont regroupees en une contrainte de transition (recevoircourrier) dont la
Iorme est (courrier.date_arrive date_clture) (courrier.version 'dfinitif'). De plus
on ajoute la contrainte auteur.nom courrier.nom_auteur pour speciIier que l'auteur doit
tre connu ou ait ete prealablement enregistre. Cette contrainte de transition sera evaluee
avant le Iranchissement de la transition par un jeton, et donnera lieu a une production si et
seulement si elle est veriIiee.
Les contraintes de transitions peuvent donner lieu a une expression plus ou moins
complexe: dans le cas IFIP, la transition renommerreferee regroupe tous les cas de Iigure
(arc inIormation, arc consommation, arc inIormation negative, arc etoile, contrainte sur les
cardinalites). Nous pouvons renommer un reIeree si et seulement si:
la Iin de la notation est active
1
(Iinnotation.etat'oui')
le renommage concerne un reIeree existant
2
(renommage.reIerencereIeree.reIerence)
(renommage.anciennomreIereereIeree.nom)
le reIeree n'a pas donne sa note
3
(reIeree.reIerencenote.reIerence)
(reIeree.nomnote.nomreIeree)
il y a moins de 3 notes pour le papier
4
(reIeree.reIerencenote*.reIerence) CARD(note*)3
1
arc inIormation.
2
arc consommation.
3
arc inIormation negative.
4
arc inIormation etoile.
Les Reseaux Formels 78
Le tableau 3 regroupe l'ensemble des contraintes de transition du reseau donne a la Iigure 64.
transition contrainte action(s)
enregistrerauteur auteur.nom courrier.nomauteur
recevoircourrier (courrier.datearrivee dateclture)
(courrier.version 'deIinitiI')
auteur.nom courrier.nomauteur
projet.reIerence courrier.reIerence
projet.nomauteur courrier.nomauteur
projet.datearrivee courrier.datearrivee
projet.version courrier.version
derogerretard (courrier.datearrivee > dateclture)
(courrier.version 'deIinitiI')
(courrier.reIerence derogation.reIerence)
(derogation.reponse 'oui')
projet.reIerence courrier.reIerence
projet.nomauteur courrier.nomauteur
projet.datearrivee courrier.datearrivee
projet.version courrier.version
recevoirpapierdirect (projet.version 'provisoire') papier.reIerence projet.reIerence
papier.nomauteur projet.nomauteur
recevoirpapierlettre (courrier.version 'provisoire')
(projet.version 'lettre')
(courrier.reIerence projet.reIerence)
papier.reIerence projet.reIerence
papier.nomauteur projet.nomauteur
recevoirdeIinitiI (courrier.version 'deIinitiI') deIinitiI.reIerence courrier.reIerence
deIinitiI.nomauteur courrier.nomauteur
deIinitiI.datearrivee courrier.datearrivee
nommerreIeree (repartition.reIerence papier.reIerence)
(repartition.nomreIeree membre.nom)
(repartition.nomreIeree papier.nomauteur)
reIeree.reIerence repartition.reIeree
reIeree.nom repartition.nomreIeree
renommerreIeree (Iinnotation.etat 'oui')
(renommage.reIerence reIeree.reIerence)
(renommage.anciennomreIeree reIeree.nom)
(reIeree.reIerence note.reIerence)
(reIeree.nom note.nomreIeree)
(note*.reIerence reIeree.reIerence) CARD(note*)<
3
repartition.reIerence renommage.reIerence
repartition.nomreIeree
renommage.nouveaunomreIeree
annuler (projet.reIerence reIeree*.reIerence)
(projet.reIerence papier.reIerence)
(projet.datearrivee > datelimite)
(projet.version 'lettre')
noter (notation.reIerence reIeree.reIerence)
(notation.nomreIeree reIeree.nom)
note.reIerence notation.reIerence
note.nomreIeree notation.nomreIeree
note.notesujet notation.notesujet
note.notequalite notation.notequalite
note.notebiblio notation.notebiblio
calculermoyenne (Iinnotation.etat 'oui')
(note*.reIerence papier.reIerence) CARD(note*)
3
moyenne.reIerence papier.reIerence
moyenne.nomauteur papier.nomauteur
moyenne.valeur
MOY(note*.notesujet) coeIsujet
MOY(note*.notequalite) coeIqualite
MOY(note*.notebiblio) coeIbiblio
classerreIus (moyenne.valeur < seuilreIuse) reIus.reIerence moyenne.reIerence
reIus.nomauteur moyenne.nomauteur
classerballottage (moyenne.valeur seuilreIuse)
(moyenne.valeur < seuilaccepte)
ballottage.reIerence moyenne.reIerence
ballottage.nomauteur moyenne.nomauteur
classeracceptation (moyenne.valeur seuilaccepte) acceptation.reIerence moyenne.reIerence
acceptation.nomauteur
moyenne.nomauteur
traiterballottageaccept
e
(ballottage.reIerence decision.reIerence)
(decision.accord 'oui')
acceptation.reIerence ballottage.reIerence
acceptation.nomauteur
ballottage.nomauteur
traiterballottagereIuse (ballottage.reIerence decision.reIerence)
(decision.accord 'non')
reIus.reIerence ballottage.reIerence
reIus.nomauteur ballottage.nomauteur
organisersessiondeIinit
iI
(acceptation.reIerence deIinitiI.reIerence)
(deIinitiI.datearrivee dateretard)
session.reIerence deIinitiI.reIerence
session.nomauteur deIinitiI.nomauteur
organisersessionretard (acceptation.reIerence deIinitiI.reIerence)
(deIinitiI.datearrivee > dateretard)
(deIinitiI.reIerence avis.reIerence)
(avis.accord 'oui')
session.reIerence deIinitiI.reIerence
session.nompresentateur deIinitiI.nomauteur
inviter (invitation.reIerence
reponse.reIerence)
(reponse.dateremise invitation.datelimite)
session.reIerence invitation.reIerence
session.nompresentateur
invitation.nominvite
Tableau 3 : contraintes de transition.
Les Reseaux Formels 79
courrier
drogation
auteur
projet
papier
membre
rpartition
rfre
notation
note
renommage
fin_notation
moyenne
ballottage refus
dcision
acceptation
dfinitif
avis
invitation rponse
session
droger_retard
recevoir_courrier
enregistrer_auteur
nommer_rfre
renommer_rfre
annuler
calculer_moyenne
noter
recevoir_dfinitif classer_refus classer_ballottage classer_acceptation
traiter_ballottage_accept
organiser_session_retard organiser_session_dfinitif
inviter
recevoir_papier_lettre
recevoir_papier_direct
*
*
traiter_ballottage_refus
*
Figure 64 : Reseau Iormel complet du cas IFIP.
Les Reseaux Formels 80
4.4. Conclusion sur les rseaux formels
Mme si les reseaux Iormels s'inspirent des reseaux de Petri de haut niveau pour la structure
des places et des transitions, l'introduction des arcs de types varies nous en eloigne. Seuls les
arcs de consommation et de production sont comparables a ceux qu'on retrouve dans les
reseaux de Petri. L'arc d'information negative peut aussi tre comparable a l'arc d'inhibition
ou des transitions mortes des reseaux CEM. Par contre, les arcs "etoile" ou de "modiIication"
ou de "lecture" n'ont pas d'equivalence dans les reseaux de Petri habituels. On perd ainsi
certaines techniques d'analyse habituelles des reseaux de Petri, mais notre objectiI est plus de
decrire aussi precisement que possible un probleme en vu de concretiser une solution
|Lemoine& 95| que d'analyser les proprietes du systeme.
Il est possible de voir dans les reseaux Iormels un diagramme de Ilux de donnees, des
reIerences croisees donnees / traitements ou un support graphique du langage Z, mais il ne
Iaut pas se tromper, la combinaison de la notion de contrainte avec la regle de declenchement
d'une transition conIere a l'ensemble une interpretation rigoureuse prenant en compte tous les
aspects dynamiques et Ionctionnels de la modelisation des systemes d'inIormation. Les regles
de construction d'un reseau Iormel guident dans la pratique a une structuration Iacilitant la
comprehension du probleme. Mais il apparat aussi que la structuration des donnees, c'est-a-
dire des places, inIluence l'expression des contraintes. En eIIet on constate qu'une
structuration des donnees issue d'une modelisation relationnelle normalisee conduit a des
expression de contraintes plus simple. Il serait alors utile de deIinir un guide methodologique
de speciIication a l'aide des reseaux Iormels aIin mettre en evidence l'intert du modele en
isolant la part d'intuition et d'expertise |Flory& 95|, |Jaulent 90|, |Tessier 90|, |Raskin& 96|,
|Olle& 90|, |Morand 91|, |Castellani 92|. Cet aspect n'est pas aborde dans le cadre de cette
these et Iait partie des voies d'exploration a suivre. La representation des donnees est
graphiquement moins riche qu'une representation particulierement destinee a ce probleme
comme MCD ou NIAM, mais les reseaux Iormels permettent d'en capturer toute la
speciIication.
Comme nous l'avons constate dans notre experience appliquee a la retro conception, le Iait
d'avoir un modele Iormel de speciIication tend a deplacer la charge d'etude dans les phases
hautes du cycle de vie et limite la phase de test. Mais cette derniere est quand mme
necessaire pour s'assurer de l'adequation des besoins avec le resultat. On s'est aperu par
exemple qu'une speciIication complete d'un probleme a conduit a une solution contraignante
d'utilisation, ce qui nous a conduit a assouplir les contraintes pour permettre a l'utilisateur
plus de marge de manoeuvre sous sa responsabilite. Les aspects ergonomie et perIormance
n'etant pas pris en compte par le Iormalisme, la phase de test s'avere d'autant plus necessaire a
moins d'adopter une phase de maquettage ou prototypage |Lausen& 86|, |Cazin& 86|, |KrieI
92|, |Montero 91|, |Brissaud 93|. L'analyse des contraintes nous a aussi permis de generer des
jeux d'essais en prenant des valeurs aux conditions limites des domaines des variables
apparaissant dans les clauses logiques. Ce type de contrle permet surtout de veriIier les
erreurs de codage et s'avere aussi tres utile pour les tests d'integration avec les autres modules
du systeme d'inIormation.
AIin d'exploiter automatiquement la speciIication du systeme d'inIormation en vu de
l'inIormatiser, des outils de generation de code et de genie logiciel de maniere generale sont
etudies |Kahn 93|, |Djorno& 93|, |Coulette& 90|, |AInor 92|, |Habbra 90|, |Janiaux 91|. Le
reseau Iormel du cas IFIP a ete compile directement en C-SQL a l'aide de l'outil developpe
par Laurent ALLAIN dans le cadre de sa these en cours. La precision et la richesse
Ionctionnelle du modele sont a notre avis d'un degre comparable a celui atteint par un langage
Les Reseaux Formels 81
de programmation de haut niveau tout en conservant un niveau d'abstraction maximale. Notre
modele prend clairement en compte dans un cadre unitaire les donnees (avec leurs
contraintes), le comportement dynamique et une description assez Iine des processus. On peut
donc le situer proche du centre sur nos deux reIerentiels d'evaluation.
processus
donnes
dynamique
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM
Z
RF
Figure 65 : Evaluation des reseaux Iormels sur le reIerentiel d'objectiI.
Les reseaux Iormels apportent une meilleure precision par rapport a Z grce a sa capacite a
prendre en compte l'aspect dynamique.
Abstraction
Prcision
Richesse fonctionnelle
MCD Merise
DFD
SADT
OOA
Classe-relation
Booch
REMORA
MCT Merise
RdP Objet
CEM Z
RF
Figure 66 : Evaluation des reseaux Iormels sur le reIerentiel qualitatiI.
Une application des RF a la retro conception de codes 82
5. Une application des RF la rtro conception de codes
Nous avons illustre au chapitre precedent la precision et la richesse Ionctionnelle de notre
modele sur un cas d'ecole classique a des Iins d'evaluation et de comparaison. Nous
proposons ici une etude basee sur un cas reel de retro conception a partir d'une application
ecrite a partir d'un langage d'edition (RPS) associe au SGBDR Oracle. La composante
dynamique est ici moins presente. Nous nous concentrons sur les aspects donnees et
traitements.
5.1. La rtro conception : introduction
On peut lier l'apparition de la retro conception au souci de vouloir ameliorer la maintenance
des applications inIormatiques. En eIIet, depuis des decennies, des nombreuses applications
inIormatiques se sont developpees. On observe au Iil du temps une degradation de la
connaissance globale du systeme d'inIormation liee aux maintenances successives selon des
methodes inIormelles et heterogenes (parce qu'elles n'existaient pas ou etaient peu connues et
a cause de la rotation des personnels). Les developpements inIormatiques sont devenus vitaux
pour les entreprises. Mais avec l'apparition des restrictions des budgets des entreprises, la
mesure des cots des services inIormatiques participent desormais a leur perIormance. Aussi,
en vue de migrer vers des environnements plus modernes ou en vue de Iiabiliser l'integration
de nouvelles Ionctionnalites ou d'un audit en vue d'une meilleure utilisation des ressources, la
retro conception s'est developpee et propose des solutions interessantes.
S'il est clair que la retro conception peut tre deIinie comme un processus s'appliquant a
des logiciels existants, il est important de connatre les activites de genie logiciel pour
apprehender le processus de retro conception. En eIIet, comme le montre |Abran& 95| sur la
Iigure 67 la deIinition que chaque auteur donne de la retro conception est dependante de
l'objectiI vise. Ainsi du point de vue de developpement d'un nouveau logiciel, le terme de
retro conception regroupe des activites telles que la restructuration de logiciels, la renovation,
la migration vers de nouveaux environnements technologiques ou l'extraction de composants
reutilisables. Du point de vue de la gestion de projet, le terme retro conception designe un
audit ou une documentation d'un logiciel existant. Du point de vue de la validation, la retro
conception consiste a appliquer une mise aux normes d'un logiciel existant et a la generation
de jeux de test.
rfrentiel
et bases de
donnes
gestion de projet
spcification
analyse / conception
programmation
amlioration
conditionnement
valuation
essais / validation
Logiciels existants Nouveaux logiciels
Figure 67 : Activites de genie logiciel.
Une application des RF a la retro conception de codes 83
Notre objectiI initial etant de comprendre des applications existantes et d'ajouter de nouvelles
Ionctionnalites a aux programmes existants, nous considerons par la suite la retro conception
comme un processus d'abstraction consistant Iournir une representation abstraite d'un
programme existant.
Les deux principales voies de la retro conception sont celle des donnees et celle des
traitements. Nos retrouvons la demarche classique de conception represente sur la Iigure 68
dans |Petit 96| qui consiste a etudier les donnees et les traitements separement.
Analyse du Domaine
Schma conceptuel
Schma logique
Schma physique
mplantation des
transactions
Analyse Fonctionnelle
Conception des
programmes
Programmes d'applications
Domaine d'application
indpendant de
la technique
dpendant
de la technique
Figure 68 : Processus de conception.
La retro conception des donnees est plus largement etudie (|Hainaut& 93|, |Hainaut& 94|,
|Hainaut& 95|, |Hainaut 96b|, |Facon& 95|, |Laleau& 95| et |Petit 96|) et constitue une voie
de recherche a part entiere. On peut distingue deux categories de retro conception de donnees
: celle qui vise a traduire les ordres de manipulation de donnees (d'un langage de type cobol
vers un langage de type SQL par exemple) et celle qui vise a Iournir une abstraction des
donnees mettant en evidence leurs liens d'heritage avec les objets du monde reel en vue de
comprendre leur semantique. Les hypotheses posees par les methodes sont souvent Iortes
(respect de regles de nommage des attributs ou normalite du schema relationnel par exemple)
et la migration d'un schema vers un autre est generalement basee sur des regles de
transIormation. En Ionction des proprietes que l'on desire veriIier, la validation peut tre
Iormelle ou humaine (de type lecteur / redacteur). Bien qu'une bonne retro conception des
donnees soit une condition necessaire pour une bonne retro conception des traitements, nous
ne traiterons pas plus cet aspect, etant donnee que l'environnement que nous disposons avec le
SGBDR Oracle est suIIisamment Iiable (relations normales) et riche pour representer des
contraintes sur les donnees (identiIiant, reIerentiel, ...).
5.2. La rtro conception de codes
La retro conception des traitements, au sens d'en obtenir une representation abstraite d'un
programme existant est un probleme diIIicile et peu traite. Les etudes les plus connues visent
Une application des RF a la retro conception de codes 84
a obtenir une structure logique des unites logiciels, ou une reIerence croisee des acces aux
donnees a des Iins de maintenance |Lelievre& 95|, |Favre 95|. Signalons les travaux de J.-L.
Hainaut dans |Hainaut& 96a| qui consistent a analyser le code source des programmes en
isolant les codes servant a veriIier le respect des regles stables aIin d'extraire les contraintes
d'integrite. Notre objectiI etant d'obtenir une representation abstraite d'un programme aIin
d'integrer de nouvelles Ionctionnalites, nous procederons en deux etapes :
Transformation du langage source en un reseau formel. Cette etape est realisee
systematiquement a l'aide d'un ensemble de regles de transIormation simples. Le reseau
obtenu a un comportement equivalente au programme initial dans un sens que l'on
precisera.
Simplification du reseau. Cette simpliIication est systematique dans un premier temps.
Une simpliIication supplementaire de la structure et des contraintes peut Iaire intervenir
une connaissance plus Iine du comportement attendu et des donnees.
Transformation
d'un programme
en rseau formel
Etape 1
Simplification
du rseau
Etape 2
Etape systmatique
Etape manuelle
Figure 69 : Les etapes de notre demarche de retro conception.
Notre demarche s'applique dans le contexte d'applications ecrites en langages rudimentaires
pour des bases de donnees relationnelles. Les schemas de transIormations qui illustrent notre
demarche sont elabores pour le langage source en question. D'autre part, nous disposons de la
description du dictionnaire physique des donnees (c'est-a-dire les noms des tables et de leurs
colonnes associees), et nous ne traitons pas la retro conception des donnees.
5.2.1. Le langage source
On considere un sous-ensemble du langage RPS qui Iait partie de la Iamille des langages
d'edition (report en anglais) largement associes aux SGBDR. Les concepts du langage source
de l'application etudiee comportent des structures de contrles elementaires (sequence,
alternative et branchement) et les ordres du langage SQL. Precisions que cette combinaison
de SQL avec un langage de commandes conduit a occulter le caractere ensembliste de celui-la
et a le considerer comme une Iacilite d'extraction de donnees. Les variables de ce langage
source ont une structure elementaire de type NUMBER (nombres entiers) ou CHAR (suite de
caracteres) sur lesquelles on peut appliquer des Ionctions d'une bibliotheque standard (il n'y a
pas de structure composee telle que le tableau ou l'enregistrement par exemple). Ces variables
Une application des RF a la retro conception de codes 85
sont accessibles a la Iois par des ordres SQL et par des instructions procedurales et sont
caracterisees par une syntaxe particuliere qui consiste a Iaire preceder le nom par le symbole
"&" en cas d'ambigute (par exemple dans l'instruction select count(1) into
nbelem from adresse where nom = ¶m, nom designe une colonne de la
table adresse et param designe une variable. Par contre nbelem bien que non precede
de "&" designe une variable car il n'y a pas d'ambigute). Il n'y a pas de niveau de protection
de visibilite des variables, la Iactorisation de codes est eIIectuee sous Iorme de substitution de
macros et non d'appel de procedure.
Le comportement de l'instruction report .report select edition debut fin
consiste a executer en premier la macro debut, puis a executer la sequence edition pour
tous les choix possibles de la macro select. EnIin on execute la macro fin.
La grammaire d'un extrait du langage source ainsi qu'un exemple de programme sont donnes
en annexe 5.
5.3. Etape 1 : transformation d'un programme en rseau formel.
Les schemas de transIormation suivants associent a chaque structure syntaxique elementaire
du langage source un element de reseau Iormel ayant un comportement equivalent. Le reseau
associe au programme dans son ensemble est obtenu par composition des elements de reseau
a l'aide des regles de transIormation des structures de contrle. Les noms de place utilises
dans les schemas sont "muets" et peuvent tre substitues par n'importe quel nom dans le
reseau Iinal a condition que le mme nom ne soit pas utilise pour nommer des places ou
transitions diIIerentes.
Avant la transIormation du programme source, nous substituons les appels de macro par le
corps des macros deIinies dans le programme.
EnIin nous ne traduirons pas les eIIets de bord (comme les aIIichages) dans le reseau.
5.3.1. Donnes et variables
5.3.1.1. 1ables
A chaque table du dictionnaire de donnees (suppose connu d'apres les hypotheses de depart),
nous associons une place dont les composantes sont les colonnes de la table. Les indexes
primaires sont exprimes par des contraintes de cle sur les composantes concernees. Les
contraintes d'integrite sont regroupees dans la contrainte de place.
5.3.1.2. Jariables
A chaque place que nous introduirons dans le reseau Iormel (ne correspondant pas a une
table), nous donnerons pour composantes les noms des variables deIinis dans le programme
source. Ces places auront une contrainte de place toujours vraie.
Commentaire [P3] : PAGE:
84
NB : Cela nous permet de Iaire
quelques simpliIications.
Une application des RF a la retro conception de codes 86
5.3.2. Structures de contrle
5.3.2.1. Actions
Chacune des transIormations suivantes concernera une action a laquelle nous associerons un
reseau. Ce reseau comportera toujours une place d'entree et une seule et une place de sortie au
plus. Les noms que nous utiliserons pour denoter ces places sont "muets" : on pourra les
remplacer par un nom quelconque dans la construction du reseau. Nous symbolisons ici le
corps de l'action par une "bote noire" :
E_action
S_action
Figure 70 : Schema de transIormation d`une action.
5.3.2.2. Squence
Nous transIormerons une sequence de deux actions en regroupant la place de sortie de la
premiere avec la place d'entree de la deuxieme (concretement on leur aIIecte le mme nom
dans le reseau).
E_action1
S_action2
S_action1 E_action2
.action1
.action2
Figure 71 : Schema de transIormation d`une sequence.
Une application des RF a la retro conception de codes 87
Nous considerons l'instruction report .report sel edt deb fin comme une
sequence deb sel edt fin. Nous expliquerons plus loin de quelle maniere le reseau
obtenu a un comportement equivalent.
5.3.2.3. Si-null
L'instruction .ifnull x etiquette consiste a continuer l'execution du programme a
l'adresse etiquette si la variable x possede la valeur predeIinie NULL. Le schema de
transIormation correspondant est le suivant :
E_if
S_if
x null
Etiquette
x = null
.ifnull x Etiquette
Figure 72 : Schema de transIormation de l`instruction iInull.
5.3.2.4. Si-alors
L'instruction .if "Condition" then etiquette consiste a continuer l'execution du
programme a l'adresse etiquette si la condition Condition est VRAIE. Nous
transIormons cette alternative simple par le schema :
E_if
S_if
C'
Etiquette
C' .if "C" then Etiquette
Figure 73 : schema de transIormation d`une alternative simple.
C' resulte de la transIormation de la condition C en substituant chaque occurrence d'une
variable x dans C par E_if.x.
5.3.2.5. Si-alors-sinon
De maniere similaire, une alternative SI-ALORS-SINON est transIormee comme ci-apres :
Une application des RF a la retro conception de codes 88
E_if
Etiquette1
C'
Etiquette2
C'
.if "C" then Etiquette1
else Etiquette2
Figure 74 : Schema de transIormation d`une alternative.
C' resulte de la transIormation de la condition C en substituant chaque occurrence d'une
variable x dans C par E_if.x.
Remarquons que cette action n'a pas de place de sortie.
5.3.2.. Branchement
Une instruction .goto etiquette consiste a continuer l'execution du programme a partir
de la ligne indiquee par .&etiquette. Sa transIormation est eIIectuee de la maniere
suivante :
E_goto
S_goto
.goto Etiquette
Etiquette
Figure 75 : Schema de transIormation du branchement.
Il n'y a pas de contrainte sur la transition.
Une application des RF a la retro conception de codes 89
5.3.2.7. Edition
E_d
S_s
S_d
E_s
.report s e d f
S_f
S_e
E_f
E_e
Tr
Figure 76 : schema de transIormation de l'instruction report.
5.3.2.8. Etiquette
Une etiquette designe une ligne dans le programme source. Elle est representee par une place.
Une etiquette est generalement suivie d'une action, dans ce cas, nous pouvons conIondre la
Une application des RF a la retro conception de codes 90
place d'entree de l'action avec l'etiquette. Nous transIormons cette conIiguration par le schema
suivant :
E_action
S_action
E_etiquette
.&Etiquette
.action
Figure 77 : Schema de transIormation d`une etiquette suivie d`une action.
5.3.3. Instructions lmentaires
5.3.3.1. Affectations
Il y a deux Iormes d'aIIectation d'une variable dans le langage source que nous etudions,
l'aIIectation par une constante caracterisee par .set <nom_variable> <constante>
(exemple .set x 123), et l'aIIectation par une variable, caracterisee par .equal
<nom_variable_destination> <nom_variable_source> (exemple .equal
x y, ou x et y sont deux variables de mme type). Les composantes des places sont
constituees par les noms de l'ensemble des variables du programme.
Le schema de transIormation d'une aIIectation est composee d'une place d'entree et d'une
place de sortie reliees par une transition comportant une contrainte d'egalite :
E_equal
S_equal
S_equal.x = E_equal.y
.equal x y
Figure 78 : Schema de transIormation d`une aIIectation de deux variables.
L'instruction set est une aIIectation d'une variable par une valeur constante. Le schema
pour cette instruction est similaire a la precedente :
Une application des RF a la retro conception de codes 91
E_set
S_set
S_set.x = Cte
.set x Cte
Figure 79 : Schema de transIormation de l`aIIectation d`une variable par une constante.
L'instruction .add z a b consiste a aIIecter a la variable z le resultat de l'operation
a + b, ou a et b sont soit une variable, soit une constante. Le schema de transIormation est
similaire a celui de l'aIIectation :
E_add
S_add
S-add.z = E_add.a + E_add.b
.add z a b
Figure 80 : Schema de transIormation d`une addition.
Nous n'explicitons pas les schemas pour .mult, .div, .sub qui sont similaires.
5.3.4. Instructions relationnelles
5.3.4.1. Insertion
L'instruction
INSERT INTO T (C1, C2, ..., Cn) VALUES (expr1, expr2, ..., expr
n)
consiste a ajouter une occurrence dans la table T dont les colonnes C1, C2, ..., Cn possedent
les valeurs expr1, expr2, ..., exprn respectives. Le schema de transIormation est :
E_insert
S_insert
T.C1 = expr1'
T.C2 = expr2'
...
T.Cn = exprn'
T
INSERT INTO (C1, C2, ..., Cn)
VALUES (expr1, expr2, ..., exprn)
Figure 81 : Schema de transIormation de l`instruction INSERT.
Une application des RF a la retro conception de codes 92
Les expressions expr' resultent de la transIormation des expressions expr en substituant
chaque occurrence d'une variable x dans expr par E_insert.x.
5.3.4.2. Slection
Une instruction SELECT consiste a aIIecter les expressions expr1, ..., exprn aux variables
x1, x2, ..., xn respectives, s'il existe une occurrence dans chaque table T1, T2, ..., Tm
veriIiant la condition C. Nous transIormons une telle instruction selon le schema suivant :
E_select
S_select
C' ^
S_select.x1 = expr1
^ S_select.x2 = expre2
^ ...
^ S_select.xn = exprn
...
T1 T2
Tm
SELECT expr1, expr2, ..., exprn
INTO x1, x2, ..., xn
FROM T1, T2, ..., Tm
WHERE C
Figure 82 : Schema de transIormation de l`instruction SELECT.
C' resulte de la transIormation de la condition C en substituant chaque occurrence d'une
variable x dans C par E_select.x et chaque occurrence d'une colonne de table T.C par
T.C.
Les expressions expr' resultent de la transIormation des expressions expr en substituant
chaque occurrence d'une variable x dans expr par E_select.x. et chaque occurrence
d'une colonne de table T.C par T.C.
5.3.4.3. Modification
Une instruction UPDATE consiste a modiIier les colonnes C1, C2, ..., Cn de toutes les
occurrences de la table T veriIiant la condition C par les expressions respectives expr1,
expr2, ..., exprn. Nous transIormons cette instruction selon le schema suivant :
Une application des RF a la retro conception de codes 93
E_update
S_update
C' ^
T.C1 = expr1
^ T.C2 = expr2
^ ...
^ T.Cn = exprn
T
*
UPDATE T
set C1 = expr1,
C2 = expr2,
...,
Cn = exprn
WHERE C
Figure 83 : Schema de transIormation de l`instruction UPDATE.
C' resulte de la transIormation de la condition C en substituant chaque occurrence d'une
variable x dans C par E_update.x et chaque occurrence d'une colonne de table T.C par
T.C.
Les expressions expr' resultent de la transIormation des expressions expr en substituant
chaque occurrence d'une variable x dans expr par E_update.x. et chaque occurrence
d'une colonne de table T.C par T.C.
5.3.4.4. Suppression
Une instruction DELETE consiste a supprimer de la table T toutes les occurrences veriIiant la
condition C. Une telle instruction est transIormee selon le schema :
E_delete
S_delete
C'
T
*
DELETE FROM T
WHERE C
Figure 84 : Schema de transIormation de l`instruction DELETE ;
C' resulte de la transIormation de la condition C en substituant chaque occurrence d'une
variable x dans C par E_delete.x et chaque occurrence d'une colonne de table T.C par
T.C.
5.3.5. Marquage initial du rseau
La premiere place d'entree du reseau est marquee par un jeton. Les liens des composantes de
ce jeton sont quelconques. Le marquage de toutes les autres places, hormis celles
correspondant aux tables, est vide.
Une application des RF a la retro conception de codes 94
Le marquage d'une place correspondant a une table est tel que a chaque occurrence dans la
table est associe un jeton dont les composantes sont liees aux valeurs des colonnes de
l'occurrence.
5.3.6. Equivalence du programme et du rseau
Proposition
L'etat Iinal du systeme apres l'execution du programme est un etat accessible du reseau a
partir du marquage initial correspondant a l'etat initial du systeme.
Elments de preuve
En eIIet, on veriIie sans diIIiculte la proposition pour chacune des transIormations
d'actions elementaires.
Considerons par exemple le schema de transIormation de l'aIIectation. On marque la place
d'entree avec un jeton dont les liaisons des composantes correspondent a l'etat des variables
du programme ; il suIIit alors d'appliquer le schema Z correspondant au reseau pour constater
que les liaisons du jeton de la place de sortie correspondent a l'etat Iinal des variables apres
execution de l'instruction d'aIIectation.
Les instructions relationnelles se traitent de la mme maniere a partir d'un marquage initial
des tables correspondant a l'etat initial de la base de donnees. Il Iaut neanmoins tenir compte
du non-determinisme dans le comportement du reseau. On peut donc seulement aIIirmer que
l'etat Iinal du programme correspond a un des etats accessibles du reseau.
D'autre part, on veriIie de la mme maniere que le marquage du reseau comporte a tout
instant un seul jeton, hormis bien entendu dans les places correspondant aux tables (il Iaut le
veriIier point par point pour les instructions relationnelles).
Cette propriete est encore veriIiee pour le schema de reseau correspondant a l'alternative,
puisque les contraintes sur les transitions sont toujours exclusives.
Considerons le reseau correspondant a la sequence de deux actions. Si le marquage initial
de la place d'entree de la premiere action contient un jeton et que le marquage des deux autres
places (cI. schema) est vide, il est clair que le reseau correspondant a la premiere action sera
toujours declenche avant le reseau correspondant a la deuxieme action puisque le marquage
du reseau comporte a toute instant un seul jeton.
Le comportement du report est plus delicat a justiIier. On voit sur le schema un
indeterminisme au niveau de la place S_e. Le jeton peut tre consomme et reintroduit dans la
place E_s ou consomme par la transition correspondant a l'entree de la macro de fin. Dans
les deux cas, on conserve un marquage contenant un unique jeton. L'etat Iinal correspondant a
l'execution de la sequence s e pour les N choix possibles pour s est accessible dans le reseau
en choisissant une sequence de tirs ou la transition Tr est declenchee N Iois et ou le choix
eIIectue pour chaque tir de la transition correspondant a la selection s est diIIerent des
precedents choix.
Une application des RF a la retro conception de codes 95
q42
qfd
ctlcom
ctlbdd
rchfub
fub
insq42
-C updqdq
delq42
updqfd
rchefc6
efi
ipt
uef
nbm
*
*
selfmn
P1
P2
P3
P3
P4
P5
P6
P7
P8
P10
P11
P9
P12
P13
P14
P15
P16
P17
P18
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
P19
P20
qdq
T11
Figure 85 : Reseau Iinal correspondant a la transIormation du programme source.
Une application des RF a la retro conception de codes 96
La Iigure represente le reseau Iormel obtenu apres transIormation du programme source
donne en annexe 6.
5.4. Etape 2 : simplification du rseau
AIin de rendre le reseau plus compacte et plus lisible, on eIIectue certaines simpliIications sur
le reseau obtenu. Plusieurs etudes sur les transIormations des reseaux de Petri de haut niveau
ont ete developpees |Genrich 90|, |Haddad 90|, essentiellement dans un objectiI de
veriIication plus aisee de proprietes structurelles. Dans notre cas, nous tirons proIit de la
structure particuliere du reseau obtenu dans le contexte precedent |Berlioux& 89|.
5.4.1. Effets de bord
Nous supprimons dans le reseau les branches correspondant a des eIIets de bord (sans eIIet
sur les liaisons du marquage). Dans notre exemple, nous supprimons ainsi les branches
partant des places P7 et P12.
5.4.2. Rduction des squences simples
Dans le cas d'une sequence de deux transitions sans lien a d'autre place, nous appliquons le
schema suivant :
P1
P2
P3
T1
T2
P1
P3
T1'
Figure 86 : Reduction de sequences simple.
Ou si C1 et C2 sont les contraintes respectives des transitions T1 et T2 alors la contrainte
de la transition T1' est la conjonction de C1, C2, et des contraintes de la Iorme P2.x =
P2.x ou x est une composante de P2 ayant une occurrence dans C1 ou C2. On veriIie sans
diIIiculte la correction de cette transIormation a l'aide des schemas de deIinition des arcs de
consommation et de production dans les reseaux Iormels.
Remarquons qu'un tel regroupement de contraintes permet souvent des simpliIications de
la contrainte obtenue.
Une application des RF a la retro conception de codes 97
5.4.3. Autres rductions de squences
Dans le schema suivant, a1 et a2 denotent les annotations des arcs correspondants
(inIormation, consommation, modiIication, ...).
P1
P2
P3
T1
T2
P1
P3
T1'
a1
a2
a1
a2
P4
P5
P4
P5
Figure 87 : Exemple de reduction particuliere.
Nous appliquons la mme regle de transIormation des contraintes que dans la simpliIication
precedente.
D'apres les proprietes de comportement du reseau, nous avons toujours un seul jeton en P1
ou P2 ou P3. L'elimination de la place P2 ne modiIie donc pas le comportement du reseau.
Dans le cas ou P4 et P5 representent la mme place, il est necessaire que a1 et a2
denotent des types d'arc diIIerents aIin d'eviter les problemes de renommage des variables.
5.4.4. Simplifications bases sur la connaissance du systme
Nous pouvons aussi eIIectuer des simpliIications a partir de la connaissance des contraintes
du modele conceptuel de donnees. Par exemple nous eliminons l'etoile sur l'arc entre la place
pec et la transition updpec car la place pec contient une occurrence unique.
Une application des RF a la retro conception de codes 98
q42
qfd
delq42
updqfd
qdq
efi
iqt
uef
nbm
*
fub
q42
P'1
P'2
P'3
P'4
T1
T2
Figure 88 : Reseau simpliIie Iinal.
Nous considerons le reseau Iormel simpliIie ci-dessus comme une speciIication de
l'application que nous utiliserons aIin de reconcevoir le programme. Sur l'exemple traite nous
avons obtenu un programme dont le nombre de lignes est dans un rapport de 1 a 4 avec le
programme initial. D'autre part nous avons pu tres simplement rajouter les nouvelles
Ionctionnalites souhaitees par les utilisateurs ainsi qu'une mise a jour des regles qui ont
evolue.
5.5. Conclusion
L'application de cette demarche dans le contexte que nous avons decrit a permis d'obtenir une
description de plusieurs programmes d'une chane de traitements diIIeres representant un total
de 3000 lignes soit 50 pages ou encore 110 KO. En reliant chacune des representations
obtenues, puis en les simpliIiant, nous avons pu isole plusieurs reseaux Iormels connexes
correspondant chacun a une alternative de traitement non reductible. Chacune correspondait
en Iait a des Ionctionnalites distinctes de l'application qui avaient ete Iactorise lors du codage.
Mme si l'experience que nous avons mene se situe dans le cadre d'un langage source
particulier associe a un SGBDR, nous pouvons deja remarquer que la representation Iinale de
l'application presente un degre de concision Iacilitant comprehension. En eIIet, la structure de
representation graphique des reseaux Iormels Iournit dans un premier temps les inIormations
suIIisantes pour apprehender globalement un probleme, les arcs entre les places et une
transition pouvant tre perus comme des reIerences croisees donnees X traitements avec en
plus une deIinition du comportement rigoureuse. La description sous la Iorme de contraintes
Une application des RF a la retro conception de codes 99
apporte la precision necessaire quand on veut examiner certains points particuliers de la
dynamique du systeme.
A partir de cette description issue de la retro conception, nous avons eIIectivement pu
utiliser le reseau Iormel comme support de dialogue avec l'utilisateur (en traduisant les
clauses logiques sous Iormes textuelles utilisant son vocabulaire), et ajouter de nouvelles
contraintes pour prendre en compte les nouveaux besoins. Le reseau Iormel s'est alors illustre
comme une aide eIIicace. En traduisant de maniere interactive les besoins des utilisateurs
sous Iorme de contrainte, nous evaluons en premiere approximation leur impact sur les
contraintes existantes et proposons diIIerents scenarios de Ionctionnements possibles aIin de
conIirmer notre interpretation. Le redeveloppement de l'application a ainsi pu se Iaire dans un
autre langage et rassembler dans une seule unite interactive ce qui etait auparavant eclate en
plusieurs programmes dans une chane de traitements diIIeres.
En tentant de generaliser notre demarche de retro conception a d'autres langages source
comme le C, nous nous heurtons a la diIIiculte d'elaborer des schemas de transformation pour
certaines structures, comme par exemple, la traduction des Ionctions recursives. La charge de
la phase de simpliIication devient alors predominante et l'intervention d'un expert du domaine
est incontournable. Cela revient en Iait a reexprimer le probleme pour le traduire directement
dans les concepts du reseau Iormel. Une autre voie que nous avons commence a experimenter
est la generation de jeux de test. En eIIet, une premiere tentative a consiste a produire des
jeux d'essai en se basant sur les valeurs limites des domaines des variables apparaissant dans
un sous-ensemble de contraintes. Cette phase de test s'avere en Iait necessaire pour contrler
la correction des codages. Mais c'est surtout lors de l'integration de la partie developpee avec
d'autres applications existantes que le jeu de test genere a montre toute son utilite par la
variete des situations proposees. Des remises en cause du Ionctionnement du logiciel ont aussi
eu lieu et traduisaient pour les plus importantes une trop grande rigueur de la speciIication.
Cela a conduit par la suite a enlever certaines contraintes aIin d'apporter plus de souplesse
d'utilisation. Les anomalies liees aux erreurs d'interpretation d'une regle de gestion ont ete
inexistantes. Nous pouvons aussi signaler qu'en aIIectant des ponderations aux contraintes
elementaires et aux structures, nous avons Iait une premiere evaluation des charges de
developpement. Mais cette tentative doit tre encore aIIinee en etalonnant nos valeurs sur une
base de mesures issues des experiences passees.
Les quelques prospections eIIectuees sur cette experience de retro conception concernant
l'utilisation des reseaux Iormelles ont montre leur intert aussi bien pour la speciIication que
pour la retro conception et nous encouragent a continuer dans ces voies.
Conclusion 100
6. Conclusion
Les modeles de description des systemes d'inIormation que nous rencontrons dans la
litterature s'inserent en Iait la plupart dans un cycle de vie supporte dans une methode de
conception |Tardieu& 83|, |Tardieu& 85|, |Tardieu 86|, |Pellaumail 86|, |Neel& 90|,
|Pascot& 93| et la speciIication, description d'un probleme independamment de sa solution,
est un sujet peu traite, particulierement en ce qui concerne les traitements. Notre objectiI a
donc ete de chercher un modele de speciIication plus adapte pour les traitements dans le but
de concevoir des applications.
Dans notre proposition des reseaux Iormels comme Iormalisme unitaire de description de
systeme d'inIormation, nous ameliorons particulierement la speciIication des traitements avec
une grande qualite d'abstraction, de precision et de convivialite, et nous proposons aussi une
demarche de retro conception de codes supportee par notre Iormalisme.
En eIIet, l'integration des contraintes a tous les niveaux des concepts de base issus des
reseaux de Petri de haut niveau oIIre une maniere naturelle et precise pour decrire a la Iois la
structure du systeme et son comportement. De plus, la Iorme graphique des reseaux Iormels
permet eIIectivement d'utiliser le modele comme support de dialogue avec les utilisateurs
sans que les speciIications Iormelles sous-jacentes n'apparaissent explicitement a un moment.
Nous n'avons pas aborde le probleme de la modelisation des donnees, mais nous avons
observe la capacite des reseaux Iormels a s'inserer dans une modelisation des donnees
existantes a travers le traitement du cas IFIP ou la demarche de retro conception.
En nous appliquant a obtenir une qualite descriptive du modele, nous ne nous sommes pas
interesse aux proprietes d'analyse habituels sur les reseaux de Petri (invariants, ...). Leur
adaptation aux reseaux Iormels, qui serait tres interessante du point de vue de la validation de
la speciIication, demande encore un travail non negligeable, et depasse le cadre de cette these.
Mais, d'un autre cote, le modele permet deja a l'inIormaticien de reutiliser directement la
speciIication en mettant en oeuvre des choix de conception et d'implantation, tels que la levee
du non-determinisme, l'ergonomie ou l'optimisation de l'eIIicacite de l'application. Mme si la
structuration de la speciIication semble intuitive, il serait quand mme utile d'accompagner le
Iormaliste dans une demarche methodologique d'analyse a la realisation, en s'inspirant par
exemple de la methode B |Keno 96|.
En utilisant les reseaux Iormels pour supporter une demarche de retro conception sur un
cas reel, nous avons montre un autre aspect de la richesse Ionctionnelle de notre modele et
valide sa qualite d'abstraction. La reconception d'un cas reel a l'aide des reseaux Iormels a
permis d'obtenir un document de speciIication Iormelle et graphique du probleme. Nous
avons ensuite pu valider l'intert de notre Iormalisme en ajoutant de nouvelle speciIication a
partir d'entretiens avec l'utilisateur et redevelopper une nouvelle application dans un autre
langage source. La tentative de generalisation de notre demarche de retro conception a des
langages sources plus evolues s'est heurte a la diIIiculte d'elaborer des schemas de
transIormation pour les structures et instructions du langage source vers les concepts de
reseau Iormel. Notre demarche semble donc trouver des applications dans l'environnement
des programmes ecrits dans des langages peu evolues, dans un objectiI de documentation, de
normalisation ou de migration.
Dans le cadre des suites que nous pouvons donner a notre etude, l'exploitation des reseaux
Iormels dans une demarche methodologique pourrait tre interessant du point de vue de la
gestion de projet et de la qualite, avec par exemple les possibilites d'evaluation de charge, de
generation de jeu de test, de documentation, de normalisation et de maquettage.
ReIerences Bibliographiques 101
7. Rfrences Bibliographiques
|Abran& 95| Abran, A., Bourque, P., Brisebois, R., Cte, V. "La reingenierie du logiciel . un
bref tour dhori:on". in actes des 8
emes
journees internationales Le Genie Logiciel & ses
Applications, Paris, 15-17 Novembre 1995, p. 495-504.
|Abrial& 70| Abrial, J.R., Bas, J., Beaume, G., Henneron, G., Morin, R., and Vigliano, G.
"Profet SOCRATE . Specification Generale". Grenoble : IMAG, Aot 1970, 353 p. Rapport
RU 34583.
|Abrial 84| Abrial, J.R. "Specifier, ou comment materialiser labstrait". Techniques et
Sciences InIormatiques, 1984. Vol. 3, N 3, p 201-219.
|Abrial 85| Abrial, J. R. "Specification ou prototvpage" in Bigre, Juillet 1985, n43-44, p. 42-
54.
|Acsiome 89| Heydemann, M.C., Prince, V., Reynaud, C. Schlienger, F., Schliender, D.
"Modelisation dans la conception des svstemes dinformation". Paris : Masson, 1989. 318 p.
|AInor 92| AInor. "Les ateliers de genie logiciel". Paris : AInor, 1992. 81 p.
|Agha 86| Agha, G. "ACTORS, A Model of Concurrent Computation in Distributed Svstems".
Cambridge (Massachusetts) : MIT Press, 1986. 140 p.
|Aho& 89| Aho, A., HopcroIt, J., Ullman, J. "Structures de donnees et algorithmes". Paris :
Inter Editions, 1989. 449 p.
|Andre& 96| Andre, P., Royer, J.-C. "Un point de vue sur les methodes formelles a obfets". in
L'Objet : Logiciel, Bases de Donnees, Reseaux, Fevrier 1996, Vol. 2, N 4, p.5-12.
|Belkhouche 91| Belkhouche, B. "Analvse orientee obfets de specifications informelles". in
Genie Logiciel & Systemes Experts, 1991, N 23, p. 84-90.
|Bellot& 95| Bellot, P., Cottin, J.-P., Zarpas, E. "Methodes formelles et protocoles .
proposition pour une logique des actions". in actes des 8
eme
journees internationales Le
Genie Logiciel & ses Applications, Paris, 15-17 Novembre 1995, p. 267-277.
|Benci& 89| Benci, G., Lingat, J-Y., Rames, J-R. "Conception et prototvpage des svstemes
dinformation . la methode REMORA et ses outils logiciels RUBIS et REMOGRAPH". in
Genie Logiciel & Systemes Experts, 1989, N 15, p. 54-65.
|Benzaken 91| Benzaken, Cl. "Svsteme formels . introduction a la logique et a la theorie des
langages". Paris : Masson, 1991. 166 p.
|Berlioux& 89| Berlioux, P., Bizard, Ph. "Algorithmique . 1 construction, preuve et
evaluation des programmes". Paris : Dunod, 1989. 181 p.
|BestougeII& 89| BestougeII, H., Ligozat, G. "Outils logiques pour le traitement du temps".
Paris : Masson, 1989. 272 p.
Commentaire [C.C.4] : PAGE
: 100
BML 415 CHO
Commentaire [CC5] : Page:
100
techreportAbrial1970,
Author Abrial,J.R., Bas,J.,
Beaume,G., Henneron,G.,
Morin,R., and Vigliano,G.},
Title Data Base Structure
(Design and Implementation)},
Institution International
Summer School, Copenhagen,
pub.IMAG, Dep. Mathematique
Applique, Grenoble, France.},
Year 1970,
Class ~
DBDschema~x7book,
HF5548.2 D325I at Math Science
Lib.},
Annote Detailed description
oI SOCRATE schema driven data
base system under CP67, and
concepts and techniques suitable
Ior data bases.}
}
inproceedingsAbrial1974,
Author Abrial,Jean-
Raymond},
Title Data Semantics},
Booktitle Klimbie74 and
KoIIeman (IFIP TC-2).},
Year 1974,
Month Mar,
Loc IMAG (Grenoble)},
Class ~ DBDobject~
DBDschema~Abrial74},
Annote Database model and
concepts. Binary relations. oI
relationships / It seems amazing
that a lot oI concepts in modeling
which are only now being
implemented (or even discussed)
were in this paper back in 1973. A
must Ior anyone interested in data
models. Only pages 1-17 are
relevant to database modeling.
The rest oI the paper deals manily
with speciIying procedures in
databases. To quote the author ...
this paper belongs to the
'structured programming' area
more than to the 'Database'
literature... . The Iirst part brings
out the need Ior independence oI
querying Irom the mechanism used
to get the answer -- semantic data
independence. Notions oI binary
relations and objects and access
Iunctions. The idea oI constraints
associated with operations on
objects seems a lot like the ideas oI
Abstract Data Types.---Maier}
}
ReIerences Bibliographiques 102
|Blank& 83| Blank, J., Krijger, M.J. "Software engineering . methods and techniques". La
Hague : John Wiley & sons, 1983. 241 p.
|Boehm 76| Boehm, B.W. "Software Engineering". in IEEE Transactions on Computers,
Decembre 1976, Vol. C-25, N 12, p. 1226-1241.
|Booch 87| Booch, G. "Software engineering with ADA". Menlo Park (CaliIornie) : Benjamin
Cummings, 1987. 580 p.
|Booch 91| Booch, G. "Conception orientee obfets et applications". Paris : Addison-Wesley,
1992. 588 p.
|Boulanger& 95| Boulanger, JL., Waeselynck, H. "The role of testing in the B formal
development process". Valenciennes (Fr.) : INRETS, Avril 1995. 19 p. Rapport Interne ReI.
9504/01.
|Bouzeghoub 83| Bouzeghoub, M. "Une svnthese des methodes et outils daide a la
conception de svstemes dinformation". Le Chesnay (France) : Institut National de Recherche
en InIormatique et en Automatique, 1983, 64 p. Rapport de Recherche N 258.
|Bouzeghoub 86a| Bouzeghoub, M. "SECSI . Un svsteme expert en conception de svstemes
dinformations". These de Doctorat specialite Mathematique mention InIormatique :
Universite de Paris VI, 18 Mars 1986, 189 p.
|Bouzeghoub& 86b| Bouzeghoub, M., Metais, E. "SECSI . an expert svstem approach for
database design". Paris : Universite P. et M. Curie Laboratoire MASI, Octobre 1986, 12 p.
RR 86/160.
|Bouzeghoub& 95| Bouzeghoub, M., Gardarin, G., Valduriez, P. "Du C a Merise Obfet".
Paris : Eyrolles, 1995. 344 p.
|Bres 90| Bres, P.-A. "Extension dun formalisme pour la modelisation de svstemes
dinformation". In : Le Iormalisme de donnees Merise - Extension du pouvoir d'expression -
Journee d'etude organisee par le groupe de travail 135 "Conception des systemes
d'inIormation" (college AFCET-GID), Paris, 15 Novembre 1990. Paris : AFCET, 1990. p. 5-
20. ISBN 2-90367791-9
|Brissaud 93| Brissaud, F. "Contribution a la conception logicielle de svstemes dapplications
. la methode mosac dans le profet Aristote". These : Universite Joseph Fourier - Grenoble I,
1993. 213 p.
|Cadivel 89| Cadivel, C., "Svnthese sur la programmation logique avec contraintes et
applications". Memoire de DEA d'InIormatique soutenu a l'insa de Lyon en Octobre 1989. 81
p.
|Cadivel& 95a| Cadivel, C., LeIort, A., Yim, P. "Les reseaux formels . un outil graphique de
specification des traitements pour les svstemes dinformations". in Le Genie Logiciel et ses
Applications, Paris, 15-17 Novembre 1995. 15 p.
ReIerences Bibliographiques 103
|Cadivel& 95b| Cadivel, C., LeIort, A., Yim, P. "Process modelling in Information Svstem bv
Formal net". in IEEE International ConIerence on Systems, Man and Cybernetics, Vancouver
(Canada), October 22-25 1995. 7 p.
|Calvez 91| Calvez, J.-P. "Specification et conception des svstemes . une methodologie". Paris
: Masson, 1991. 614 p.
|Castellani 92| Castellani, X. "Methodologie generale danalvse et de conception des
svstemes dobfets". Paris : Masson, 1992. 402 p.
|Cazin& 86| Cazin, J., Michel, P. "F1 . un langage pour le prototvpage de svstemes
dinformation". in Genie Logiciel, Janvier 1986, N 3, p. 61-63.
|Chen 76| Chen, P.P.S. "The Entitv-Relationship Model . Toward a unified view of data". in
ACM, Transactions on database Systems, March 1976, Vol. 1, N 1, p. 9-36.
|Coad& 91a| Coad, P., Yourdon, P. "Obfect oriented analvsis". Englewood CliIIs : Prentice
Hall, 1991. 223 p.
|Coad& 91b| Coad, P., Yourdon, P. "Obfect oriented design". Englewood CliIIs : Prentice
Hall, 1991. 197 p.
|Codd 70| Codd, E.F. "A relational model data for large shared data banks". in
Communication oI the ACM, Juin 1970, Vol. 13, N 6, p. 377-387.
|Cohen& 86| Cohen, B., Harwood, W.T., Jackson, M.I. "The Specification of Complex
Svstems". Londres : Addison-Wesley, 1986. 143 p.
|Coulette& 90| Coulette, B., Medallel, R. "Le profet IPHIGENIE . conception doutils
didactique intelligents en methodologie de developpement de profets logiciels". in Genie
logiciel & systemes experts, juin 1990, N 19. p. 57-63.
|Courvoisier& 90| Courvoisier, M., Paludetto, M., Valette, R. "Generation de code ADA a
partir dune approche orientee obfets HOOD/Reseaux de Petri". in actes des 3emes journees
internationales Le Genie Logiciel & ses Applications, Toulouse, 3-7 Decembre 1990.
Nanterre : EC2, 1990, p. 795-826.
|Dahl& 66| Dahl, O.J., Nygaard, K. "Simula . An Algol-Based Simulation Language". in
Communications oI the ACM, 1966, Vol. 9, N 9, p. 671-678.
|Davis 90| Davis, A.M. "Software requirement . analvsis & specification". Englewood CliIIs
: Prentice-Hall, 1990. 516 p.
|De Rosnay 75| De Rosnay, J. "Le Macroscope. Jers une vision globale". Paris : Editions du
Seuil, 1975. 249 p.
|Delahaye 88| Delahaye, J.-P. "Outils logiques pour lintelligence artificielle". Paris :
Eyrolles, 1988. 247 p.
|Delobel& 82| Delobel, C., Adiba, M. "Bases de donnees et svstemes relationnels". Paris :
Bordas, 1982. 449 p.
ReIerences Bibliographiques 104
|Delobel& 91| Delobel, C., Lecluse, C. Richard, P. "Bases de donnees . des svstemes
relationnels aux svstemes a obfets". Paris : InterEditions, 1991. 460 p.
|Derniame& 90| Derniame, J.C., Khammaci, T., Boudjlida, N. "Un modele obfet-relation
pour la modelisation du procede de developpement de logiciel". in actes des 3emes journees
internationales "Le genie logiciel & ses applications", Toulouse, 3-7 Decembre 1990, Vol. 1,
p. 353-364.
|DesIray 90| DesIray, P. "Une methode de developpements de logiciels dediee a la
programmation par obfets . la methode Classe-Relation". in Actes des Journees nationales de
Prototypage et SpeciIication de Logiciels, AFCET GID, INSA-Lyon, 30 Mai 1990, p. 19-33.
|DesIray 92| DesIray, P. "Ingenierie des obfets . approche Classe-Relation. Application a
C". Paris : Masson, 1992. 230 p.
|Deweze 81| Deweze, A. "Reseaux semantiques . essai de modelisation - application a
lindexation et a la recherche de linformation documentaire". These de doctorat en
mathematique a l'Universite Claude Bernard, Lyon I, 1981. 514 p.
|Dileva& 88| Dileva, A., Giolito, P. "Information svstem dvnamics representation in
production environments". in Data & Knowledge Engineering, 1988, N 3, p. 149-161.
|DixneuI& 90| DixneuI, P., Aubert, J.P. "Une methode de conception & de programmation
par obfets". in Genie Logiciels & Systemes Experts, Juin 1990, N 19, p. 32-42.
|Djorno& 93| Djorno, Y., Cassius de Linval, I. "Generation dateliers de conception .
metamodelisation orientee obfet. Coherence incementale de vues de modeles". These
Doctorat : universite de Paris IX - Dauphine, 1993. 199 p.
|Duke& 91| Duke, R., King, P., Rose, G., Smith, G.M. "The Obfect-Z Specification
Language". Brisbane, University oI Queensland, 1991, 61 p. Technical Report 91-1
|Drr& 92| Drr, E., Katwijk, J.-V. "JDM . a formal specification langage for obfect-
oriented designs". in TOOLS 7 : actes de la 7eme conIerence internationale, Dortmund
(Germany). Edited by G. Heeg, B. MagnusB. Meyer. HertsIorshire : Prentice Hall, 1992. p.
63-77
|Espinasse& 93| Espinasse, B., Nanci, D., Cohen, B., Heckenroth, H. "Ingenierie des
svstemes dinformation avec Merise". Paris : Sybex, 1993. 650 p.
|Facon& 95| Facon, P., Laleau, R. "Des specification informelles aux specifications formelles
. compilation ou interpretation". in actes INFORSID 95, Grenoble, Mai 95, p. 47-62.
|Favre 95| Favre, J-M. "Maintenance et reingenierie globale en presence de preprocesseurs".
in actes des 8
emes
journees internationales Le Genie Logiciel & ses Applications, Paris, 15-
17 Novembre 1995, p. 507-517.
|Finance 79| Finance, J-P. "Etude de la construction des programmes . methodes et langages
de specification et de resolution de problemes". These de doctorat es science mathematique
de l'Universite de Nancy I, soutenue le 11 Octobre 1979, 482 p.
ReIerences Bibliographiques 105
|Finance& 86| Finance, J-P., Bubois, E., Levy, N., Souquieres, J. "SACSO . un svsteme daide
a la construction de specifications fonctionnelles pour les svstemes dinformation". in Genie
Logiciel, Janvier 1986, N 3, p. 63-65.
|Flory& 95| Flory, A., Ayache, M. "Etude comparative des methodes de conception". in
L'objet : Logiciel, bases de donnees, reseaux, Octobre 1995, Vol. 1, N 3, p. 15-19.
|Forse 89| Forse, T. "Qualimetrie des svstemes complexes". Paris : Les editions
d'organisation, 1989. 259 p.
|Fron 94| Fron, A. "Programmation par contraintes". Paris : Addison-Wesley France, 1994.
393 p.
|Fuggetta& 93| Fuggetta, A., Ghezzi, C., Mandrioli, D., Morzenti, A. "Executable
specification with data-flow diagrams". in SoItware Practice and Experience, 1993, Vol. 23,
N 6, p. 629-653.
|Gane& 79| Gane, C., Sarson, T. "Structured svstem analvsis . tools and techniques".
Englewood CliIIs : Prentice Hall, 1979. 241 p.
|Gendre& 90| Gendre, P., Bitteur, H. "HOOD version 3.0 . lage de raison". in Genie
Logiciel & Systemes Experts, N 19, Juin 1990, p. 44-48.
|Genrich 87| Genrich, H.J. "Predicate/Transition Nets". in Advances in Petri Nets 1986, part.
I, LNCS 254, Brauer, W. Reisig, G. Rozenberg (Eds). Berlin : Springer, 1987, p. 207-247.
|Genrich 90| Genrich, H.J. "Equivalence Transformations of PrT-Nets". in Advances in Petri
nets 1989, Lecture Notes in Computer Science, High-Level Petri Nets : Theory and
Applications, Vol. 424, Edited by G. Rozenberg. Berlin : Springer, 1990, p. 179-208.
|Gogue& 83| Gogue, J.M., Fey, R. "La gestion de la qualite administrative en informatique".
Paris : Les editions d'organisation, 1983. 225 p.
|Goldberg& 89| Goldberg, A., Robson, D. "SMALLTALK-80. The language and its
implementation". Murray Hill (New Jersey) : Addison-Wesley, 1983. 585 p.
|Gonin& 92| Gonin, J.J., Quang, P.T. "Reussir la conduite de profets informatiques". Paris :
Eyrolles, 1992. 202 p.
|Gray 88| Gray, D. "The Formal Specification of a Small Bookshop Information Svstem". in
IEEE transactions on SoItware Engineering, Ieb. 1988, vol.14, n 2. p. 263-272.
|Guyot 86| Guyot, J. "Un modele de traitements pour les bases de donnees . un formalisme
pour la conception, la validation et lexecution de la specification". Geneve : Le concept
Moderne Edition, 1986. 285 p.
|Habra 90| Habra, N. "A transformational method for functional prototvping". These de
Doctorat en Science Option Computer Science des Facultes Universitaires Notre-Dame de la
Paix, Namur (Belgique), Septembre 1990, 278 p.
|Habrias 93| Habrias, H. "Introduction a la specification". Paris : Masson, 1993, 347 p.
ReIerences Bibliographiques 106
|Habrias 94| Habrias, H. "La mesure du logiciel". Toulouse : Teknea, 1994. 194 p.
|Habrias& 88| Habrias, H., Bogdaniuk, D. "Lexpression des contraintes dunicite et de
totalite dun schema conceptuel de donnees binaire de tvpe IA". in Modele et Bases de
Donnees, Juillet 1988, N 10, p. 37-57.
|Haddad 90| Haddad, S. "A Reduction Theorv for Coloured Nets". in Advances in Petri nets
1989, Lecture Notes in Computer Science, High-Level Petri Nets : Theory and Applications,
Vol. 424, Edited by G. Rozenberg. Berlin : Springer, 1990, p. 209-235.
|Hainaut 96b| Hainaut, J.L. "Specification preservation in schema transformation -
Application to semantics and statistics". Namur (Belgique) : Facultes Universitaires Notre-
Dame de la Paix - Institut d'InIormatique, July 1996, 4 p. RP-96-012.
|Hainaut& 93| Hainaut, J.L. Chandelon, M., Tonneau, C., Joris, M. "Contribution to a Theorv
of Database Reverse Engineering". Namur (Belgique) : Facultes Universitaires Notre-Dame
de la Paix - Institut d'InIormatique, 1993, 10 p. RP-93-003. in IEEE Computer Society Press,
Working ConIerence on Reverse Engineering, Baltimore, May 1993.
|Hainaut& 94| Hainaut, J.L. Chandelon, M., Tonneau, C., Joris, M. "Transformation-based
Database Reverse Engineering". Namur (Belgique) : Facultes Universitaires Notre-Dame de
la Paix - Institut d'InIormatique, January 1994, 12 p. RP-94-017.
|Hainaut& 95| Hainaut, J.L., Henrard, J., Hick, J-M., Roland, D., Englebert, V.
"Requirements for Information Svstem Reverse Engineering Support". Namur (Belgique) :
Facultes Universitaires Notre-Dame de la Paix - Institut d'InIormatique, 1995, 10 p. RP-95-
013.
|Hainaut& 96a| Hainaut, J.L. Henrard, J., Hick, J-M., Roland, D., Englebert, V. "Techniques
danalvse de programmes pour la retro-ingenierie de bases de donnees". Namur (Belgique) :
Facultes Universitaires Notre-Dame de la Paix - Institut d'InIormatique, July 1996, 19 p. RP-
96-018.
|Hewitt 77| Hewitt, C. "Jiewing control structures as patterns of passing messages" in
ArtiIicial Intelligence, 1977, N 8, p. 323-364.
|Hewitt& 82| Hewitt, C., Barber, G. "Foundations for office semantics". Cambridge
(Massachusetts) : Laboratory For Computer Science (MIT), 1982, 22 p. ReIerence
MIT/LCS/TM-25.
|Hill 93| Hill, D.R.C. "Analvse orientee obfets & modelisation par simulation". Paris :
Addison-Wesley, 1993. 362 p.
|Huang 93| Huang, W. "La programmation relationnelle" in L'inIormatique proIessionnelle,
Mai 1993, N 114, p. 9-15.
|IGL 89| IGL Technology. "SADT . Un langage pour communiquer". Paris : Eyrolles, 1989.
336 p.
|Jacobson& 92| Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G. "Le genie logiciel
orientee obfet". Paris : Addisson-Wesley, 1992. 536 p.
ReIerences Bibliographiques 107
|Janiaux 91| Janiaux, P. "Ateliers de genie logiciel . obfectif :ero defaut". in 01 InIormatique,
1991, N 1176, 06/09/91, p. 29-32.
|Jaulent 90| Jaulent, P. "Genie Logiciel . les methodes". Paris : Armand Colin,, 1990, 288 p.
|Jensen 90| Jensen, K. "Coloured Petri Nets . A High Level Language for Svstem Design and
Analvsis". in Advances in Petri Nets 1990, LNCS 483, G. Rozenberg (Ed.). Berlin : Springer,
1990, p. 342-416.
|Jensen 92| Jensen, K. "Coloured Petri Nets", Berlin : Springer, vol.1, 1992. 234 p.
|Jensen& 91| Jensen, K., Rozenberg, G. (Eds), "High-level Petri Nets". Berlin : Springer,
1991. 724 p.
|Jocteur 90| Jocteur, H. "La methode HOOD". in INTERFACES (AFCET), Juillet 1990, N
93, p. 21-23.
|Johnston& 93| Johnston, W., Rose, G. "Guidelines for the Manual Conversion of Obfect-Z
to C". Brisbane : University oI Queensland, 1993. 96 p. Technical Report 93-14
|Jones 93| Jones, C.B. "JDM : une methode rigoureuse pour le developpement du logiciel".
(traduit par M. Lemoine), Paris : Masson, 1993. 290 p.
|Jones& 93| Hayes, I.J., Jones, C.B., Nicholls, J.E. "Understanding the differences between
JDM and Z". Manchester : University oI Manchester, 1993. 25 p. Technical Report UMCS-
93-8-1
|Kahn 93| Kahn, G. "Les environnements de programmation". in Le courrier du CNRS : la
recherche en inIormatique, Fevrier 1993, N 80. p. 40.
|Kappel& 88| Kappel, G. SchreIl, M. "A design Method for Obfect-Oriented Databases".
Arbeitspapiere der GMD 287, Feb. 1988, GMD, Darmstadt (Allemagne)
|Keno 96| Keno, K. "The B Language and Method". Londres : Springer Verlag, 1996. 232 p.
ISBN 3-540-76033-4
|Kouloumdjian& 89| Kouloumdjian, J., Nurcan, S., Moll, G-H. "Lapport de la
programmation logique et de la structuration orientee obfet aux bases de donnees". in
Modeles et Bases de Donnees, janvier 1989, N 11, p. 21-47.
|KrieI 92| KrieI, P. "Utilisation des langages obfets pour le prototvpage". Paris : Masson,
1992. 248 p.
|La 91|, La; M. "Conception Orientee Obfet . pratique de la methode HOOD". Paris :
Dunod, 1991. 322 p.
|Laleau& 95| Laleau, R., Hadj-Rabia, N. "Generation automatique de specification JDM a
partir dun schema conceptuel de donnees". in actes INFORSID 95, Grenoble, Mai 95. p. 63-
78.
|Lausen& 86| Lausen, G., Oberweis, A., Schnthaler, F., Stucky, W. "Modelisation
conceptuelle basee sur les reseaux de Petri et construction rapide de prototvpes avec
ReIerences Bibliographiques 108
Income". in actes des 3eme du Colloque-Exposition de Genie Logiciel, Versailles, 27-30 Mai
1986, p. 165-176.
|Le Moigne 77| Le Moigne, J.L. "Theorie du svsteme general . theorie de la modelisation".
Paris : PUF, 1977. 258 p.
|Le& 88| Le, F., Peugeot, C. "Quelques problemes lies a lintroduction du concept de
generalisation/specialisation dans le modele entite-relation". in Modeles et Bases de
Donnees, N 10, Juillet 1988, p. 3-16.
|LeIort 93| LeIort, A., Yim, P. "Reseaux de Petri a contraintes". Memoire de DEA, Lille,
L.A.I.L., 1993. 144 p.
|Lelievre& 95| Lelievre, A., Narat, V. "La retro-conception de codes scientifiques . retour
dexperience". in actes des 8
emes
journees internationales Le Genie Logiciel & ses
Applications, Paris, 15-17 Novembre 1995, p. 519-528.
|Lemoine& 95| Lemoine, M., Vignes, S. "Le developpement de logiciels traditionnels peut-il
saccommoder profitablement des methodes formelles ?" in actes des 8
eme
journees
internationales Le Genie Logiciel & ses Applications, Paris, 15-17 Novembre 1995, p. 241-
250.
|Levi& 93| Levi, G., Ciancarini, P. "What is logic programming good for in software
engineering ?". Bologna (Italy) : Laboratory Ior computer science, University oI Bologna,
Italy. 23 p.TR UBLCS-93-09.
|Levy& 86| Dubois, E., Levy, N., Souquieres, J. "SACSO . Methodes et outils de construction
de specifications des svstemes". in 3emes colloque-exposition de Genie Logiciel, 27-30 Mai
1986, Versailles, p. 177-188.
|LightIoot 91| D. LightIoot, "Formal Specification Using Z". Londres : The Macmillan Press,
1991. 191 p.
|LightIoot 94| D. LightIoot, "La specification formelle avec Z (traduit par H. Habrias, P-M
Delpech)". Toulouse : Teknea, 1994. 191 p.
|Lissandre 86| Lissandre, M. "La methode SADT". in Genie Logiciel, Avril 1986, N 4, p. 58-
62.
|Lissandre 90| Lissandre, M. "Maitriser SADT". Paris : Armand Colin, 1990. 219 p.
|Lissandre 90b| Lissandre, M. "Panorama des methodes de conception temps reel". in actes
des 4emes journees de Pratique des methodes et outils logiciels d'aide a la conception des
systemes d'inIormation, Nantes, 25-27 Septembre 1990. p. 25-51.
|Love 86| Love, T. "La programmation par manipulation dobfets et de messages". in Genie
Logiciel, Janvier 1986, N 3, p. 50-55.
|Masini& 90| Masini, G., Napoli, A., Leonard, D., Tombre, K. "Les langages a obfets". Paris
: InterEditions, 1990. 584 p.
ReIerences Bibliographiques 109
|Mazigh 95| Mazigh, B. "Repartition des donnees dans un svsteme distribue temps reel par
les reseaux de Petri stochastiques generalises". in actes des 8
eme
journees internationales Le
Genie Logiciel & ses Applications, Paris, 15-17 Novembre 1995, p. 279-289.
|Meyer 85| Meyer, B. "On formalism in specifications". in IEEE SoItware, January 1985,
Vol. 2, N 1, p. 6-26.
|Meyer 90| Meyer, B. "Conception et Programmation par Obfet". Paris : Inter Editions, 1990.
534 p.
|Meyer& 79| Meyer, B., Demuynck, M. "Les langages de specification". in EDF, bulletin de
la direction des etudes et recherches, serie C, mathematique, inIormatique. N 1, 1979. pp.
39-60.
|Meyer& 81| Meyer, B., Demuynck, M. "La specification . un outil pour linformaticien". in
01 InIormatique, Avril 1981, N 149, p. 62-67.
|Miranda& 86| Miranda, S.M., Busta, J.M. "Lart des bases de donnees . les bases de donnees
relationnelles". Paris : Eyrolles, 1986. Tome 2, 354 p.
|Monin 96| Monin, J.-F. "Comprendre les methodes formelles". Paris : Masson, 1996. 306 p.
|Montero 91| Montero, S. "Prototvpage . methodes et outils daide a la conception et a la
realisation des svstemes dinformation". These de doctorat en inIormatique soutenu a l'INSA
de Lyon le 17/12/1991. 322 p.
|Morand 91| Morand, B. "Faut-il renouveler les methodes de conception des svstemes
dinformation ?". in INTERFACES/AFCET, mai/juin 1991, N special 103/104, p. 59-66.
|Morand& 92| Morand, B., Nicolle, A. "Afouter un niveau dabstraction aux modeles de
donnees". in actes IFORSID, Clermont-Ferrand, 22 mai, 1992. 18 p.
|Morejon 95| Morejon, J. "Merise vers une modelisation oriente obfet". Paris : les editions
d'organisation. 253 p.
|Mounyol 95| Mounyol, R. "Merise etendue . cas professionnels de svnthese". Paris : Ellipes,
1995. 238 p.
|Murata 89| Murata, T. "Petri Nets . Properties, Analvsis and Applications". in Proceedings
oI the IEEE , April 1989, Vol. 77, N 4, p. 541-580.
|Neel& 90| Neel, J., Hillion, J.-C. "La methode danalvse NEEL". Paris : Lavoisier, 1990. 213
p.
|Nicholls& 92| Brien, S.M., Nicholls, J.E. "Z Base Standard". OxIord : OxIord University
Computing Laboratory, 1992. 202 p. Technical Monograph PRG107.
|Nijssen 86| Nijssen, G.M. "La methode danalvse IA-NIAM". in Genie Logiciel, Avril 1986,
N 4, p. 49-52.
ReIerences Bibliographiques 110
|Olle& 90| Olle, T.W., Hagelstein, J., MacDonald, I.G., Rolland, C., Sol, H.G., Van Assche,
F.J.M., Verrijn-Stuart, A.A. "Methodologies pour les svstemes dinformation". Paris, Dunod
InIormatique AFCET IFIP, 1990, 345 p.
|Panet& 94| Panet, G., Letouche, R. "Merise/2 . Modeles et techniques MERISE avances".
Paris : Les Editions d'Organisation, 1994. 366 p.
|Paraire 91| Paraire, M. "Presentation du cas IFIP - Modelisation des flux primaires". Paris :
AFCET, 4 Octobre 1991. 24 p. Communication au groupe de travail AFCET 135 -
Conception des systemes d'inIormations, sous-groupe traitements - le 04/10/91.
|Paraire 92| Paraire, M. "Merise, les obfets et la complexite". Paris : AFCET, 16 Juin 1992.
34 p. Communication au groupe de travail AFCET Conception Orientee Objets le
16/06/1992.
|Partridge 90| Partridge, D. "Apports de lintelligence artificielle au genie logiciel". Paris :
Masson, 1990. 243 p.
|Pascot& 88| Pacot, D., Ridjanovic, D., Legendre, B. "EXPRESS-MLD . Une approche de
developpement rapide centre sur le modele logique de donnees". in Modeles et Bases de
Donnees, Juillet 1988, N 10. p 17-35.
|Pascot& 91| Pacot, D., Ridjanovic, D. "DATARUN . la modelisation des traitements au sein
des modeles de donnees. Application au cas IFIF". Paris : AFCET, 4 Octobre 1991. 37 p.
Document de travail Groupe AFCET 135 - conception des systemes d'inIormations, sous-
groupe traitements le 04/10/91.
|Pascot& 93| Pascot, D., Bernadas, C. "Lessence des methodes . etude comparative de six
methodes de conception des svstemes dinformation informatises". in actes
INFORSID/AFCET 93, Systemes d'inIormation, systemes a base de connaissances, Lille, 11-
14 Mai 1993, p.65-84.
|Paul 86| Paul, E. "OASIS . un outil daide a la specification". in Genie Logiciel, Janvier
1986, N 3, p. 53-58.
|Pellaumail 86| Pellaumail, P. "La methode AXIAL". in Genie Logiciel, Avril 1986, N 4, p.
22-24.
|Perez 90| Perez, J-P. "Svsteme Temps Reel". Paris : Bordas, 1990. 243 p.
|Perrin& 90| Perrin, Ph., LE, F. "Illustration des extensions pour le formalisme entite-relation
. cas de lorganisation de conferences". In : Le Iormalisme de donnees Merise - Extension du
pouvoir d'expression - Journee d'etude organisee par le groupe de travail 135 "Conception des
systemes d'inIormation" (college AFCET-GID), Paris, 15 Novembre 1990. Paris : AFCET,
1990. p. 77-102. ISBN 2-90367791-9
|Petit 96| Petit, J-M. "La retroconception des bases de donnees". These de doctorat en
InIormatique : INSA de Lyon, 15/07/1996. 150 p.
|Pichat& 90| Pichat, E., Bodin, R. "Ingenierie des donnees . svsteme dinformation, modeles
et bases de donnees". Paris : Masson, 1990, 428 p.
ReIerences Bibliographiques 111
|Pittman 93| Pittman, M. "Lessons learned in managing obfect-oriented development". in
IEEE SoItware, jan. 1993, Vol. 23, N 1, p. 43-53.
|Prehn& 93| Prehn, S., Haxthausen, A.-E., Pedersen, J.-S. "RAISE . a product supporting
industrial use of formal methods". in Techniques et Sciences InIormatiques, 1993, Vol. 12,
N 3, p. 319-346.
|Quang 89| Quang, P.T. "Merise / Yourdon". in genie Logiciel & Systemes Experts,
Septembre 1989, N 15, p. 22-39.
|Raskin& 96| Raskin, J-F., Tan, Y-H., Van der Torre, L.W.N. "How to Model Normative
Behavior in Petri Nets". Namur (Belgique) : Facultes Universitaires Notre-Dame de la Paix -
Institut d'InIormatique, January 1996, 17 p. RP-96-001.
|Reisig 85| Reisig, W. "Petri Nets, an Introduction". Berlin : Springer, 1985. 161 p.
|Reisig 91| Reisig, W. "Petri Nets and Algebraic Specifications". in Theoretical Computer
Science, 1991, vol. 80. pp. 1-34.
|Richter& 82| Richter, G., Durcholz, R. "IML - Inscribed Hight Level Petri Net". in
proceedings oI IFIP WG 8.1, Working conIerence on comparative review oI InIormation
Systems Design Methodologies, Edited by Olle, T.W., Sol, H.G., Verrijn-Stuart, A.A..
Noordwijkerhout (North-Holland), 10-14 May 1982, 648 p. pp. 335-368.
|Richter& 92| Heuser, C.A. Richter, G. "Constructs for Modeling Information Svstems with
Petri Nets". in K. Jensen (Ed.), Application and Theory oI Petri Nets 1992, Lecture Notes in
Computer Science 616. Berlin : Springer, 1992. pp 224-243.
|Richter& 93| Heuser, C.A. Peres, E.M. Richter, G. "Towards a Complete Conceptual Model
. Petri Nets and Entitv-Relationship Diagrams". InIormation Systems, 1993, Vol.5. pp 275-
298.
|RochIeld 90| RochIeld, A. "Lheritage . tvpe et sous-tvpe". In : Le Iormalisme de donnees
Merise - Extension du pouvoir d'expression - Journee d'etude organisee par le groupe de
travail 135 "Conception des systemes d'inIormation" (college AFCET-GID), Paris, 15
Novembre 1990. Paris : AFCET, 1990. p. 21-44. ISBN 2-90367791-9
|RochIeld 92| RocheIeld, A. "Les methodes de conception orientees obfet". in Actes congres
INFORSID 92, Clemont-Ferrand, 19-22 Mai 1992, p. 563-593.
|RochIeld& 88| RocheIeld, A., Morejon, J. "Extension au modele conceptuel de donnees". in
Modeles et Bases de Donnees, Fevrier 1988, N 8. p. 37-56.
|RochIeld& 89| RocheIeld, A., Tardieu, H. "Les dix premieres annees de Merise ... et les
suivantes". in 01 InIormatique, 23 Janvier 1989. p 21-22.
|RochIeld& 91| RocheIeld, A., Mehl, C., Malbosc, G., Follot, J.-M. "Retombees dune
modelisation E-R sur des modeles de traitements Merise". in Genie Logiciel et Systemes
Experts, Dec. 1991, N 25. p. 54-60.
|RochIeld& 93| RocheIeld, A., Bouzeghoub, M. "From Merise to OOM". in Ingenierie des
systemes d'inIormation, 1993, Vol. 1, N 2. p 151-176.
ReIerences Bibliographiques 112
|Rolland& 82| Rolland, C., Richard, C. "The Remora Methodologv for Information Svstems
Design and Management" in proceedings oI IFIP WG 8.1, Working conIerence on
comparative review oI InIormation Systems Design Methodologies, Edited by Olle, T.W.,
Sol, H.G., Verrijn-Stuart, A.A. Noordwijkerhout (North-Holland), 10-14 May 1982, 648 p. p.
369-426.
|Rolland 86| Rolland, C. "REMORA . une methode de conception des svstemes
dinformation". in Genie Logiciel, Avril 1986, N 4, p. 36-43.
|Rolland& 91a| Rolland, C., Foucaut, O., Benci, G. "Conception des svstemes dinformations.
La methode REMORA". Paris : Eyrolles, 1991. 351 p.
|Rolland& 91b| Rolland, C., Proix, C. "Une approche linguistique pour la conceptualisation
des svstemes dinformations". Genie Logiciel & Systeme Experts, 1991, N 23, p. 42-48.
|Rolland 93| Rolland, C. "Adapter les methodes a lobfet . challenges et embuches". in actes
AIcet des journees de synthese Methodes d'analyse et de conception orientees objet des
systemes d'inIormation. Paris, 22-23 Novembre 1993. p 1-23.
|Rumbaugh& 91| Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W. "Obfect
Oriented Modelling and Desing". Englewood CliIIs (Neyw Jersey). 500 p.
|Serbat 81| Serbat, G. "Cas et fonctions . etude des principales doctrines casuelles du moven
age a nos fours". Paris : PUF, 1981. 209 p.
|Shapiro& 90| Shapiro, R.M., Pinci, V. "An integrated software development methodologv
based on hierarchical colored Petri nets". in High-level petri nets : theory and application. K.
Jensen & G. Rozenberg Eds.Berlin : Springer-Verlag, 1990, p. 649-666.
|Sibertin-Blanc 88| Sibertin-Blanc , C. "Le modele de donnees obfet comme formalisme de
modelisation dune base de donnees". Toulouse : Universite des Sciences Sociales, 1988, 23
p.
|Sibertin-Blanc 90a| Sibertin-Blanc, C. "La modelisation du fonctionnement des svstemes
dinformation par reseaux de Petri a obfets". Paris : AFCET, 2 Avril 1990, 15 p. Document
de travail Groupe AFCET 135 - conception des systemes d'inIormations, sous-groupe
traitements le 02/04/1990.
|Sibertin-Blanc 91a| Sibertin-Blanc, C. "Cooperative Obfects for the Conceptual Modelling
of Organi:ational Information Svstems". in Proceedings oI IFIP TC8 Working ConIerence on
The Object Oriented Approach in InIormation Systems, Quebec City (Canada), October 28-
31, 1991. 26 p. Edited by F. van Assch et al., Elsevier Science Publishers.
|Sibertin-Blanc& 91b| Sibertin-Blanc, C., Bastide, R. "Obfect-Oriented Structuring Using
High-Level Petri Nets". in Advances in Petri Nets'91, 1991, 24 p. Berlin : Springer-Verlag,
1991. Edited by G. Rozenberg.
|Smith 92| Smith, G.M. "An Obfect-Oriented Approach to Formal Specification", PhD
Thesis, University oI Queensland, Brisbane, 1993, 238 p.
ReIerences Bibliographiques 113
|Soberman 92| Soberman, M. "Genie logiciel en informatique de gestion". Paris : Eyrolles,
1992. 243 p.
|Sommerville 88| Sommerville, I. "Le genie logiciel et ses applications". Paris : Inter
Editions, 1988. 330 p.
|Souquieres 89| Souquieres, J. "Quelques elements dun langage de construction de
specifications". le Chesnay (Ir.) : INRIA, 1989, 14 p. Rapport de Recherche N 1053.
|Spivey 94| Spivey, J.M. "La notation Z". Paris : Masson, 1994. 155 p. Traduction de |Spivey
92| par M. Lemoine.
|Stroustrup 86| Stroustrup, B. "The C programming language". Murray Hill (New Jersey)
: Addison-Wesley, 1986. 328 p.
|Tabourier 88| Tabourier, Y. "Du modele entite-relation e un veritable reseau semantique". in
Modeles et Bases de Donnees, Fevrier 1988, N 8. p 51-70.
|Tabourier 90a| Tabourier, Y. "Formalisme de donnees individuel (entite-relation) . attention
travaux '". in AFCET/INTERFACES, Mai/Juin 1990, N 91/92. p 34-43.
|Tabourier 90b| Tabourier, Y. "Formalisme de donnees individuel (entite-relation) .
extension des contraintes". In : Le Iormalisme de donnees Merise - Extension du pouvoir
d'expression - Journee d'etude organisee par le groupe de travail 135 "Conception des
systemes d'inIormation" (college AFCET-GID), Paris, 15 Novembre 1990. Paris : AFCET,
1990. p. 45-55. ISBN 2-90367791-9
|Tardieu 86| Tardieu, H. "La methode MERISE". in Genie Logiciel, Avril 1986, N 4, p. 25-
29.
|Tardieu 89| Tardieu, H. "De Merise a Metratech". in Genie Logiciel & Systemes Experts,
Septembre 1989, N 15, p. 40-52.
|Tardieu 91| Tardieu, H. "Svsteme dinformation-strategique et svsteme-dinformation
strategiques". in actes du congres AFCET 91 Autour et a l'entour de MERISE : les methodes
de conception en perspective, Nice, 18-19 Avril 1991, p. 43-64.
|Tardieu& 83| Tardieu, H., RocheIeld, A., Colletti, R. "La methode MERISE - T1 . principes
et outils". Paris : Les Editions d'Organisation, 1983, 318 p.
|Tardieu& 85| Tardieu, H., RocheIeld, A., Colletti, R. Pannet, G., Vahee, G. "La methode
MERISE - T2 . demarche et pratique". Paris : Les Editions d'Organisation, 1985, 461 p.
|Tardieu& 91| Tardieu, H., Guthmann, B. "Le triangle strategique". Paris : Les Editions
d'Organisation, 1991. 304 p.
|Tessier 90| Tessier, C. "Analvse critique des methodologies dinformatisation des svstemes
dinformation en gestion". These de doctorat en inIormatique a l'Universite de Paris IX
Dauphine, Juin 1991, 593 p.
|Theron 88| Theron, P. "Guide pratique du genie logiciel". Paris : Eyrolles, 1988. 367 p.
ReIerences Bibliographiques 114
|Vautrin& 86| Vautrin, J.-P., Vogrig, R., Dei-Svaldi, D. "Contribution a lanalvse dun
svsteme automatise par SADT". Nancy : Centre de Recherche de l'INRS, 1986. Cahiers de
notes documentaires, N 123, ND 1579-123-86, p. 175-192.
|Verheijen& 82| Verheijen, G.M.A., Van Bekkum, J. "NIAM . An Information Analvsis
Method" in proceedings oI IFIP WG 8.1, Working conIerence on comparative review oI
InIormation Systems Design Methodologies, Edited by Olle, T.W., Sol, H.G., Verrijn-Stuart,
A.A. Noordwijkerhout (North-Holland), 10-14 May 1982, 648p. p 537-589.
|Vogel 88| Vogel, C. "Genie cognitif". Paris : Masson, 1988. 196 p.
|Walliser 77| Walliser, B. "Svstemes et modeles . introduction critique a lanalvse de
svsteme". Paris : Seuil, 1977. 247 p.
|Waserman& 90| Wasserman, A.I., Pircher, P.A., Muller, R. "The obfetct-oriented structured
design notation for software design representation". in IEEE Computer, March 1990, Vol. 22,
N 3, p. 50-63.
|West& 92| West, M., Eaglestone, M. "Software development . two approaches to animation
of Z specifications using Prolog". in SoItware Engineering Journal, July 1992. p. 264-276.
|Wirsing 93| Wirsing, M. "Developpement de logiciel et specification formelle". in
Techniques et Sciences InIormatiques, 1993, Vol. 12, N 4. p 413-431.
|Yim 89| Yim, P. "Resolution dans les svstemes formels abstraits . application a la
programmation en logique, aux svstemes de reecriture et aux grammaires formelles". these
de doctorat en inIormatique soutenu a l'insa de Lyon le 15/09/1989. 146 p.
Index 115
8. Index
Abran& 95, 85
Abrial 84, 12; 62; 126
Abrial 85, 17
Abrial& 70, 27
Acsiome 89, 22
AInor 92, 83
Agha 86, 34
Aho& 89, 14
Andre& 96, 63
Belkhouche 91, 22
Bellot& 95, 62
Benci& 89, 50; 52
Benzaken 91, 15; 62
Berlioux& 89, 100
BestougeII& 89, 62
Blank& 83, 21
Boehm 76, 18
Booch 87, 34
Booch 91, 12; 34; 46
Boulanger& 95, 65
Bouzeghoub 83, 12
Bouzeghoub 86a, b, 22
Bouzeghoub& 95, 35
Bres 90, 25; 49
Brissaud 93, 83
Cadivel 89, 68
Cadivel& 95a, b, 68
Calvez 91, 20; 30
Castellani 92, 83
Cazin& 86, 83
Chen 76, 25
Coad& 91a,b, 35
Codd 70, 25
Cohen& 86, 20
Coulette& 90, 83
Courvoisier& 90, 12
Dahl& 66, 34
Davis 90, 12; 21
De Rosnay 75, 15
Delahaye 88, 15; 62
Delobel& 82, 25
Delobel& 91, 35
Derniame& 90, 33
DesIray 90, 41
DesIray 92, 41
Deweze 81, 22
Dileva& 88, 12
DixneuI& 90, 33
Djorno& 93, 83
Duke& 91, 63; 137
Drr& 92, 64
Espinasse& 93, 16
Facon& 95, 86
Favre 95, 86
Finance 79, 16; 62
Finance 86, 12
Flory& 95, 83
Forse 89, 20
Fron 94, 68
Fuggetta& 93, 30
Gane& 79, 12; 28; 29
Gendre& 90, 49
Genrich 87, 66; 141
Genrich 90, 100
Gogue& 83, 21
Goldberg& 89, 34
Gonin& 92, 21
Gray 88, 133
Guyot 86, 12
Habbra 90, 83
Habrias 93, 21; 62; 133; 137
Habrias 94, 21
Habrias& 88, 26
Haddad 90, 100
Hainaut 96b, 86
Hainaut& 93, 86
Hainaut& 94, 86
Hainaut& 95, 86
Hainaut& 96a, 87
Hewitt 77, 34
Hill 93, 34
Huang 93, 25
IGL 89, 12; 31
Jacobson& 92, 35
Janiaux 91, 83
Jaulent 90, 83
Jensen 90, 66
Jensen 92, 55; 72; 141; 143; 144
Jocteur 90, 49
Johnston& 93, 63; 64; 137
Jones 93, 12; 62; 137
Jones& 93, 62; 137
Kahn 93, 83
Kappel& 88, 54
Keno 96, 63; 104
Kouloumdjian& 89, 25
Index 116
KrieI 92, 34; 83
Lai 90, 65
Laleau& 95, 86
Lausen& 86, 83
Le Moigne 77, 15
Le& 88, 25
LeIort 93, 66
Lelievre& 95, 86
Lemoine& 95, 83
Levi& 93, 62
Levy& 86, 62
LightIoot 91, 62
LightIoot 94, 62; 137
Lissandre 86, 12; 31
Lissandre 90, 12; 31
Lissandre 90b, 30
Love 86, 34
Massini& 90, 33
Mazigh 95, 139
Meyer 79, 12; 23
Meyer 85, 23; 62
Meyer 90, 34
Meyer& 81, 62
Miranda& 86, 25
Monin 96, 62
Montero 91, 83
Morand 91, 83
Morand& 92, 26
Morejon 95, 25; 26
Mounyol 95, 25
Murata 89, 138
Neel& 90, 104
Nicholls& 92, 126; 137
Nijssen 89, 27
Olle& 90, 83
Panet& 94, 26
Paraire 91, 12
Paraire 92, 25
Partridge 90, 62
Pascot& 88, 12
Pascot& 91, 12
Pascot& 93, 104
Paul 86, 12
Pellaumail 86, 104
Perez 90, 30
Perrin& 90, 12
Petit 96, 86
Pichat& 90, 25
Pittman 93, 65
Prehn& 93, 62
Quang 89, 31
Raskin& 96, 83
Reisig 85, 140; 141
Reisig 91, 141
Richter& 82, 59
Richter& 92, 59
Richter& 93, 59; 72
RochIeld 88, 25
RochIeld 90, 25
RochIeld 92, 33
RochIeld& 88, 26
RochIeld& 89, 26
RochIeld& 91, 66
RochIeld& 93, 35; 49
Rolland 82, 12
Rolland 86, 12
Rolland 93, 35
Rolland& 82, 50
Rolland& 91a, 50
Rolland& 91b, 22
Rumbaugh& 91, 65
Serbat 81, 23
Shapiro& 90, 66
Sibertin-Blanc 88, 25
Sibertin-Blanc 90a, 66
Sibertin-Blanc 91, 141
Sibertin-Blanc 91a, 12; 54
Sibertin-Blanc& 91b, 54
Smith 92, 63; 64; 137
Soberman 92, 21
Sommerville 88, 21
Souquieres 89, 22
Spivey 94, 126; 132; 137
Stroustrup 86, 34
Tabourier 88, 25
Tabourier 90a, 26
Tabourier 90b, 26
Tardieu 86, 104
Tardieu 89, 12
Tardieu& 83, 55; 104
Tardieu& 85, 104
Tardieu& 91, 14
Tardieu& 95, 16; 17
Tessier 90, 83
Theron 88, 21; 30
Vautrin& 86, 31
Verheijen& 82, 28
Vogel 88, 23
Walliser 77, 15
Waserman& 90, 33
Index 117
West& 92, 63
Williams 88, 20
Wirsing 93, 62
Yim 89, 62
118
9. Annexe 1 : Extraits du cas IFIP
C1: Lorsqu'une lettre d'intention ou un article est reu, si les auteurs ne sont pas deja connus
de l'organisme scientiIique, celui-ci les enregistre.
C2: Seules les lettres d'intention ou bien les articles arrives avant la date de clture de la
remise des papiers seront pris en compte, sauI derogation accordee par le comite de
programme.
C3: Les projets papiers (lettre d'intention ou bien version provisoire) sont repartis entre les
membres du comite de programme qui deviennent alors "reIerees" des papiers qui leur sont
attribues.
C4: Dans le cas d'une lettre d'intention, si la version provisoire du papier n'arrive pas dans le
mois qui suit la date de la remise des papiers, alors le projet de communication est annule.
C5: Les membres du comite de programme doivent noter les papiers qui leur ont ete soumis:
a travers une note allant de 0 a 10
pour les criteres suivants: intert du papier, qualite du papier, qualite de la bibliographie
C6: Apres notation, les papiers sont classes en 3 categories: les papiers acceptes, les papiers
reIuses, et les papiers en ballottage. Les regles de classement sont deIinies par le comite de
programme de chaque conIerence. On souhaite que ces regles puissent tre memorisees par le
systeme d'inIormation, aIin de pouvoir elaborer suivant un processus algorithmique, le
classement des papiers. Les regles de classement sont de type moyenne ponderee: note
moyennea1(note moyenne critere 1)a2(note moyenne critere 2)...an(note moyenne
critere n) tel que a1a2...an1. Suivant la categorie du papier, celui-ci est accepte, accepte
avec des reserves (corrections demandees, et soumis a decision du comite de programme), ou
reIuse.
C7: Les papiers acceptes Iont l'objet de communications dans le cadre de sessions. Le comite
de programme se reunit pour: arrter deIinitivement la selection des papiers, planiIier les
sessions, deIinir le programme des sessions (aIIecter les papiers), nommer les presidents de
sessions, planiIier les autres activites de la conIerence.
C8: Le comite de programme veillera a ce que le presentateur d'un papier en soit bien l'auteur.
C9: On notera que le "reIeree" d'un papier ne peut en tre l'auteur ou le coauteur. Par contre,
les membres du comite de programme peuvent soumettre des projets de communication.
C10: Le comite de programme suscite des papiers invites. Les papiers invites ne sont pas
revus par les "reIerees", cependant une date limite de remise du papier invite est negociee
avec chaque auteur. Si celui-ci ne remplit pas ses engagements, alors le papier invite ne sera
pas programme. Un papier invite repondant aux conditions requises pour tre programme, le
sera suivant les mmes regles qu'un papier accepte.
C11: Si par suite d'une deIaillance d'un ou de plusieurs membres du comite de programme, un
papier etait note par moins de 3 "reIerees", alors un ou plusieurs autres "reIerees" devraient
tre nommes.
119
C12: Dans ce cas, si l'incident touche un nombre signiIicatiI de papiers, la date de reunion du
comite de programme pourrait tre decalee de quelques jours sur decision du comite de
programme.
C13: Si l'auteur d'un papier accepte ne remet pas la version deIinitive de son papier dans les
delais imposes par le comite de programme, alors ce papier pourra tre reIuse apres decision
du comite de programme.
C14: La version deIinitive d'un papier doit integrer les corrections demandees par le comite
de programme. Les demandes de correction sont etablies sur la base du papier dans sa version
provisoire. Les papiers deIinitiIs pourront tre revus par le comite de programme si celui-ci le
juge necessaire. Une regle generale est Iixee a ce sujet pour chaque conIerence.
120
10. Annexe 2 : Le langage formel Z
Le langage Z, cree par J.R. Abrial |Abrial 84|, et perIectionne au PRG d'OxIord |Spivey
94|, permet la speciIication statique et dynamique des systemes a l'aide d'un vocabulaire
mathematique standard, emprunte a l'axiomatisation de Zermelo-Fraenkel. Nous introduisons
ici le materiel necessaire pour la deIinition ulterieure des reseaux Iormels, et donner un
aperu des possibilites des methodes Iormelles pour la modelisation des systemes
d'inIormation.
1.1. 1ypes, dclarations et ensembles
La notation Z utilise la notion de types aIin d'eviter les paradoxes mathematiques connus de la
theorie des ensembles (l'ensemble de tous les ensembles qui ne se contiennent pas eux-mmes
est-il un ensemble ?), et dans le but d'une veriIication ulterieure de la coherence d'une
deIinition. On distingue les types construits, les types de base, et les types composes.
Les tvpes construits sont des types predeIinis, dont la signiIication mathematique est
claire, comme l'ensemble des entiers, l'ensemble des entiers naturels (deIini en Iait a
partir de ), l'ensemble
1
des entiers naturels non nuls, ou l'ensemble des chanes de
caracteres (dans le standard |Nicholls& 92|). Les tvpes de base sont des ensembles donnes a
priori ("given sets" en anglais) : Tvpe est deIini par l'interpretation de l'ensemble |Tvpe| de
tous ses elements. Par exemple, pour deIinir le type Personne on peut interpreter |Personne|
comme l'ensemble des individus connus.
Les types composes peuvent tre construits par enumeration, produit cartesien, ou par un
ensemble de declarations. Les types libres sont donnes par l'enumeration de tous leurs
elements. Le type Jersion qui denote le genre d'une soumission a une conIerence s'ecrira ainsi
:
Jersion :: lettre , provisoire , deIinitiI
Chaque variable doit appartenir a un type. Une declaration Z exprimant l'appartenance des
variables var
1
, ... , var
n
au type Tvpe est de la Iorme :
var
1
, ... , var
n
: Tvpe
Par exemple, on peut declarer un auteur du type Personne :
auteur : Personne
Une variable peut tre liee a une valeur ou a une autre variable par une egalite :
auteur Cadivel
L'egalite est interpretee par son sens mathematique habituel. Autrement dit, l'expression
precedente ne doit pas tre consideree comme une aIIectation, et ne peut tre distinguee d'un
test d'egalite, si par exemple la variable est liee a une autre valeur. On dispose aussi de
l'operateur different de, note , et des operateurs usuels deIinis sur les types construits : , ~,
, .
Une variable peut egalement representer un ensemble de valeurs. Un comite par exemple
est un ensemble de personnes, autrement dit comite appartient au type construit comme
lensemble des parties du type Personne, et note Personne :
121
comite : Personne
Pour tre plus precis, comite appartient a un ensemble de parties finies, qu'on note :
comite : Personne
La notation usuelle est utilisee pour representer un ensemble en extension :
comite Abrial , Gondran , Habrias , Lemoine , LightIoot}
L'ensemble vide est note (parIois }). Les intervalles de nombres sont condenses sous la
Iorme n
1
..n
2
:
0..3 denote l'ensemble 0 , 1 , 2 , 3}
La notion de n-uplet est liee a celle de produit cartesien de n ensembles : le n-uplet
x
1
, ... , x
n
appartient au type X
1
... X
n
ssi x
1
est de type X
1
, ... , x
n
est de type X
n
. En
particulier, un couple est un 2-uplet. Les ensembles de n-uplets permettent notamment de
construire des relations. Nous allons nous interesser plus particulierement aux relations
binaires.
1.2. Relations binaires
Nous decrivons plus en detail les operations sur les relations, tres utiles pour la
speciIication des systemes d'inIormation. Une relation binaire est un ensemble de couples de
valeurs. Par exemple, la relation liant un article a un auteur peut tre deIinie par :
EcritPar : (ReIDocument Personne)
EcritPar Abr84 , Abrial , Hab93 , Habrias , BN92 , Brien , BN92 , Nicholls , Lig91
, LightIoot}
La notation Z permet d'abreger (X Y) en X Y, et le couple x , v en x v :
EcritPar : ReIDocument Personne
EcritPar Abr84 Abrial , Hab93 Habrias , BN92 Brien , BN92 Nicholls ,
Lig91 LightIoot}
Le domaine d'une relation R : X Y, note dom R, est l'ensemble des elements de
l'ensemble de depart qui ont une image par la relation R, i.e. des x X tels que x v R .
dom EcritPar Abr84 , Hab93 , BN92 , Lig91}
De mme, le co-domaine d'une relation R : X Y, note ran R, est l'ensemble des v Y tels
que x v R :
ran EcritPar Abrial , Habrias , Brien , Nicholls , LightIoot}
La composition de deux relations R : X Y et S : Y Z est notee R ; S. On a x : R ;
S ssi il existe un v Y tel que x v R et v : S. Pour le besoin de l'exemple, on deIinit
une relation Nationalite :
Nationalite : ReIDocument Personne
Nationalite Abrial F , Habrias F , Brien GB , Nicholls GB , LightIoot GB}
122
EcritPar ; Nationalite Abr84 F , Hab93 F , BN92 GB , Lig91 GB}
On appelle parIois cette operation composition avant, par opposition a la composition
arriere deIinie par S R R ; S (S R peut tre lu aussi S suivie de R).
La relation identite sur l'ensemble A est la relation qui a tout element de A Iait
correspondre lui-mme : x x 1
A
ssi x A. Cette relation permet de deIinir simplement la
restriction de domaine A R d'une relation R comme 1
A
; R, c'est-a-dire la partie de la
relation dont le domaine est limite a A. Si on considere l'ensemble |Livre| des publications qui
sont des livres edites, la restriction de la relation EcritPar aux livres est :
Livre EcritPar Hab93 Habrias , Lig91 LightIoot}
La restriction de co-domaine est deIinie par R A R ; 1
A
. On ecrit donc la restriction de
la relation EcritPar aux auteurs Iranais par :
EcritPar Franais Abr84 Abrial , Hab93 Habrias}
Dualement, l'anti-restriction (ou soustraction) de domaine d'une relation est la partie de
cette relation dont le domaine est hors de l'ensemble. On obtient de cette maniere notre
relation sur le domaine des documents qui ne sont pas des livres :
Livre EcritPar Abr84 Abrial , BN92 Brien , BN92 Nicholls}
et par anti-restriction de co-domaine, la relation pour les auteurs qui ne sont pas franais :
EcritPar Franais BN92 Brien , BN92 Nicholls , Lig91 LightIoot}
La relation inverse de R, notee R
NomSchema
Declaration
Contrainte
Le schema suivant deIinit une publication recente, dont la date est contrainte a tre
posterieure a 1993 :
PublicationRecente
ref : RefDocument
auteur : Personne
date :
date 1993
ou sous Iorme textuelle :
PublicationRecente |ref : RefDocument ; auteur : Personne ; date : , date 1993|
L'alphabet du schema est l'ensemble des noms de variables introduits par la signature du
schema :
(PublicationRecente ) ref , auteur , date}
126
Le n-uplet caracteristique d'un schema est le n-uplet construit a partir de son alphabet. Le
n-uplet caracteristique du schema precedent est donc ref , auteur , date.
L'expression des ensembles en comprehension Definition , Contrainte Expression} peut
se reecrire NomSchema Expression} d'apres la deIinition d'un schema :
PublicationRecente date-1900} 93 , 94 , 95}
Si l'Expression est omise, on utilise par deIaut le n-uplet caracteristique du schema :
PublicationRecente} Hab93 , Habrias , 1993 , HJN93 , Hayes , 1993 , ...}
Une reIerence a un schema de ce style peut intervenir au sein d'une expression de schema
dans la partie declaration, contrainte ou comme expression. En general, les operations de
manipulation de schemas necessitent certaines precautions, notamment en cas de renommage
ou de decorations de variables. Nous ne nous attarderons pas sur ces aspects, le lecteur
interesse pouvant par exemple se reporter a |Spivey 94|. Nous nous contentons donc de
donner des deIinitions rapides des operations sur les schemas, que nous illustrerons par des
exemples dans le paragraphe suivant.
La negation S d'un schema S a la mme signature que S, et sa propriete est la negation de
la propriete de S :
PublicationAncienne PublicationRecente
PublicationAncienne
ref : RefDocument
auteur : Personne
date :
date < 1993
La signature de la conjonction S
1
S
2
est la jonction des signatures des deux schemas. La
propriete de S
1
S
2
est vraie pour un lien ssi la propriete de S
1
est vraie pour la restriction de
ce lien a la signature de S
1
et de mme pour la propriete de S
2
. On interprete de maniere
similaire l'application des operateurs logiques , , aux schemas.
Le masquage d'un schema S (x
1
, ... , x
n
) consiste a supprimer du schema S les
composants x
1
, ... , x
n
. La profection d'un schema S sur un schema T, notee S T, masque les
composants de S qui ne sont pas aussi composants de T.
La speciIication d'une transition d'un etat a un autre utilise intensivement la decoration des
variables et des schemas. Une variable x' denote l'etat de la variable x apres une operation. La
decoration par un point d'interrogation x? exprime que x est une entree de l'operation, et x!
une sortie (ces deux decorations ont un rle simplement inIormatiI dans une speciIication).
La decoration d'un schema consiste simplement a decorer chacune de ses composantes : le
schema S' est le schema S ou on a substitue chaque composante x par x'. La notation S
indique un changement d'etat du schema S, en introduisant implicitement le schema decore
S' :
S
S
S
La notation S indique que l'etat n'a pas ete modiIie par la transIormation :
127
S
S
x : Identificateur , x (S) x x
La contrainte indique que chaque composante x de S a la mme valeur que sa composante
decoree x' dans S'. Ces notations sont extrmement utiles pour exprimer la dynamique des
traitements d'un systeme. Sans entrer dans les details, l'operateur de composition sequentielle
S ; T de deux schemas permet d'enchaner les transIormations d'etat de S avec celle de T.
EnIin, dans la deIinition d'un schema, il est utile de disposer de variables ou de Ionctions
globales. La deIinition de tels objet est permise par des descriptions axiomatiques, qui
peuvent tre vues comme de schemas sans nom, et sont notees sous la Iorme :
Declaration
Contrainte
La portee des variables deIinies dans une declaration axiomatique s'etend de leur deIinition
a la Iin de la speciIication. Ces variables Iont parties de la signature globale de la
speciIication, et l'ensemble des contraintes des descriptions axiomatiques Iorme la propriete
globale de la speciIication. Par exemple, on peut deIinir :
MaxInt :
Carre :
Double :
MaxInt 65535
x : Carre x x*x
x : Double x 2*x
1.. Exemple : lments de spcification d'une bibliothque
L'exemple de la speciIication d'une bibliotheque illustre egalement les presentations de |Gray
88| et |Habrias 93|, auxquelles on pourra se reporter pour plus de details, notre but etant plus
ici d'illustrer concretement les notions precedemment deIinies que d'exposer la maniere
d'ecrire une speciIication en Z (|Habrias 93| utilise de plus conjointement des speciIications
Niam pour preciser la structure relationnelle des donnees).
Le premier schema decrit les copies des livres dont dispose la bibliotheque :
LivresBiblio
Exemplaire : Document Livre
EcritPar : Livre Auteur
TraiteDe : Livre Sufet
dom EcritPar
ran Exemplaire
dom TraiteDe
ran Exemplaire
128
|Livre| denote l'ensemble des livres (au sens d'ouvrage publie, et non d'exemplaire
concret). Le sens des autres types de base utilises est suIIisamment clair pour que nous
omettions leur deIinition. Exemplaire est une Ionction partielle qui, a un document possede
par la bibliotheque, associe un livre. Bien entendu, cette Ionction est partielle puisque la
bibliotheque ne possede pas Iorcement tous les ouvrages publies. Cette Ionction n'est pas
injective, puisque la bibliotheque peut posseder plusieurs exemplaires d'un mme livre. La
Ionction EcritPar donne le ou les auteurs d'un livre. Son domaine est limite aux livres dont la
bibliotheque possede (au moins) un exemplaire. Les inIormations disponibles concernent
donc uniquement les livres dont dispose la bibliotheque.
Le schema suivant concerne l'activite de prt de la bibliotheque :
ActiviteBiblio
Emprunteurs, Personnel : Personne
Disponible, Sorti : Document
AeteEmpruntePar, EmpruntePar : Document Personne
Emprunteurs Personnel
Disponible Sorti
dom EmpruntePar Sorti
ran EmpruntePar Emprunteurs
dom AeteEmpruntePar Sorti Disponible
ran AeteEmpruntePar Emprunteurs
p : Personne , p Emprunteur # EmprunteParp} Max
Un emprunteur ne peut pas tre membre du personnel, et un exemplaire sorti n'est plus
disponible. Les exemplaires sortis ont ete empruntes par un emprunteur enregistre.
L'historique du prt d'un exemplaire est modelise par la Ionction EmpruntePar. La derniere
contrainte exprime le Iait qu'un mme emprunteur ne peut conserver qu'un nombre limite
d'exemplaires en mme temps. Max est une variable globale deIinie par une description
axiomatique du style :
MaxInt :
MaxInt 3
L'etat courant de la bibliotheque peut tre modelise (approximativement!) par la Iusion des
deux schemas precedents.
EtatBiblio
LivresBiblio
ActiviteBiblio
dom Exemplaire Sorti Disponible
La contrainte supplementaire Iait intervenir un composant du premier schema, Exemplaire,
et deux composants du second, Sorti et Disponible. Elle exprime simplement qu'un
exemplaire de la bibliotheque est soit sorti, soit disponible au prt (pour aIIiner la
speciIication, on aurait pu introduire le Iait qu'un livre peut tre en rangement). Ce schema
utilise une reIerence aux deux autre schemas dans sa partie declaration. Une telle fusion de
129
schemas revient a ecrire de Iaon moins concise un regroupement des declarations et des
contraintes des deux schemas :
EtatBiblio
Exemplaire : Document Livre
EcritPar : Auteur Auteur
TraiteDe : Livre Sufet
Emprunteur, Personnel : Personne
Disponible, Sorti : Document
AeteEmpruntePar, EmpruntePar : Document Personne
Emprunteur Personnel
Disponible Sorti
dom EcritPar
ran Exemplaire
dom TraiteDe
ran Exemplaire
dom EmpruntePar Sorti
ran EmpruntePar Emprunteur
dom AeteEmpruntePar Sorti Disponible
ran AeteEmpruntePar Emprunteur
dom Exemplaire Sorti Disponible
p : Personne , p Emprunteur # EmprunteParp} Max
Les modiIications de l'etat courant lors d'un prt est modelisee par le schema :
SortieDocument
EtatBiblio
LivresBiblio
e? : Personne
c? : Document
e? Emprunteur
c? Disponible
# EmprunteParp} Max
Disponible Disponible \ c?}
Sorti Sorti c?}
EmpruntePar EmpruntePar c? e?}
AeteEmpruntePar AeteEmpruntePar
Emprunteur Emprunteur
Personnel Personnel
La notation EtatBiblio exprime que l'etat courant change avec la sortie d'un exemplaire,
qui n'est plus disponible. On note l'emprunteur dans la Ionction EmpruntePar. Les
decorations de e? et c? indiquent que ces variables sont des entrees de l'operation. Les trois
dernieres contraintes precisent que les composantes concernees n'ont pas ete modiIiees.
Le retour d'un exemplaire suit une demarche semblable :
130
Retour
EtatBiblio
LivresBiblio
c? : Document
c? Sorti
Disponible Disponible c?}
Sorti Sorti \ c?}
EmpruntePar c?} EmpruntePar
AeteEmpruntePar AeteEmpruntePar c? EmpruntePar(c?)}
Emprunteur Emprunteur
Personnel Personnel
On notera le rle de l'operateur qui permet la mise a jour de l'historique des prts d'un
exemplaire.
1.7. Schmas gnriques
Il est possible de parametrer la deIinition de schema par des parametres generiques :
NomSchemaGenerique|X
1
, ... , X
n
| | Declaration , Contrainte |
ou les X
1
, ... , X
n
sont des noms de type generiques intervenant dans la Declaration ou la
Contrainte.
On utilise plus couramment les constantes generiques, qui correspondent aux descriptions
axiomatiques dans le cas non generique. La plupart des operateurs Ionctionnels et relationnels
de Z peuvent deIinis en Z a l'aide de constantes generiques. Nous illustrons le concept de
constante generique a l'aide des deIinitions relatives aux multi-ensembles, qui nous seront
utiles dans la suite.
Un multi-ensemble (bag en anglais) est un ensemble ou chaque valeur peut avoir plusieurs
occurrences. Plus precisement, on construit un multi-ensemble a partir d'un ensemble en
associant a chaque element une Ionction a valeurs entieres (non nulles) qui donne son nombre
occurrences. Si l'occurrence d'un element dans le multi-ensemble est nulle, la Ionction n'est
pas deIinie.
bag X X
1
|X|
# : bag X X
x : X ; B : bag X B # x a : X a 0} B x
Le nombre occurrences de x dans le multi-ensemble B est note B # x (on utilise l'operateur
de surcharge aIin de prendre en compte le cas ou l'occurrence est nulle). Le multi-ensemble
a
1
k
1
, .... , a
n
k
n
} est note plus simplement a
1
, .... , a
n
.
Les relations et operations sur les multi-ensembles (appartenance, non-appartenance,
inclusion, inclusion stricte, addition, soustraction) se deIinissent tres simplement :
131
|X|
: X bag X
: X bag X
: bag X bag X
: bag X bag X
: bag X bag X bag X
: bag X bag X bag X
x : X ; B : bag X (x B x dom B)
x : X ; B : bag X (x B x dom B)
B,C : bag X B C (x : X B#x C#x)
B,C : bag X B C (x : X B#x < C#x)
x : X ; B,C : bag X (B C)#x B#x + C#x
x : X ; B,C : bag X (B C)#x B#x - C#x
Le lecteur interesse par la speciIication Iormelle avec Z pourra utilement se reporter a
l'ouvrage de LightIoot |LightIoot 94| pour une introduction pedagogique, ou celui de Spivey
|Spivey 94| pour les aspects semantiques plus precis. Habrias consacre a Z et a la methode B
quelques chapitres de son introduction a la speciIication |Habrias 93|. Le standard ISO de la
notation Z est paru sous la Iorme d'un rapport technique |Nicholls& 92| : l'abord plutt ardu
du document est compense par la grande precision de la deIinition des notions. La
speciIication en Z se rapproche par bien des aspects de VDM |Jones 93|, |Jones& 93|. Les
extensions orientees objet de Z sont un centre d'intert croissant |Smith 92|, |Johnston& 93|,
|Duke& 91|.
132
11. Annexe 3 : Elments de thorie des rseaux
11.1. Rdp place/transition
Un reseau est un graphe biparti (c'est-a-dire avec deux types de noeuds) oriente :
Dfinition 2
Un reseau R est un triplet (P,T,A) tel que :
(i) P et T sont des ensembles Iinis non vides et disjoints
(ii) A (P T ) (T P )
P est un ensemble de places, T un ensemble de transitions et A un ensemble d'arcs. Un
arc peut relier une place a une transition ou une transition a une place (dans le Iormalisme
initial deIini par Petri, on parle de conditions et d'evenements plutt que de places et
transitions). Graphiquement, on represente en general les places par des cercles, et les
transitions par des barres |Murata 89|.
Dfinition 3
Soit un reseau R (P,T,A). Pour x P T , on note :
x v (v,x) A} , l'ensemble des predecesseurs de x (ou entrees de x)
x v (v,x) A} , l'ensemble des successeurs de x (ou sorties de x)
x peut tre soit une place, soit une transition. Un reseau est un graphe detats si chaque
transition a exactement une place d'entree et une place de sortie. On parle de graphe
devenements si chaque place a exactement une transition d'entree et une transition de sortie,
et si le reseau est marque :
Dfinition 4
Soit un reseau R (P,T,A). On appelle marquage une application M : P N } qui a
chaque place de P associe le nombre de fetons presents dans cette place ( denote un
marquage infini ).
Dans le Iormalisme des reseaux condition/evenement, le marquage de chaque place
contient au plus un jeton. Dans le cas general, on autorise des marquages quelconques, et
mme les marquages inIinis, pour des raisons techniques. Par abus de langage, on appelle
reseau de Petri tout reseau marque (et pas seulement les reseaux condition/evenement) :
Dfinition 5
Un tuple (P,T,A,M
0
) est un reseau de Petri si :
(i) (P,T,A) est un reseau
(ii) M
0
: P N } , est un marquage initial du reseau
Dans la suite, on abregera souvent "Reseau de Petri" par RdP. Le franchissement (ou tir)
d'une transition permet de passer d'un marquage a un autre par une regle tres simple : une
transition est validee si toutes ses places en entree ont au moins un jeton, et le marquage
133
resultant est obtenu en retirant un jeton de chacune des places d'entree, et en ajoutant un jeton
a chacune des places de sortie.
Dfinition
Soit (P,T,A,M
0
) un reseau de Petri :
(i) une transition t T est dite validee pour le marquage M ssi p t , M(p) 1
(ii) le marquage M resultant du tir de la transition t validee pour M est tel que p P :
(iii)
M p
M p p t p t
M p p t p t
M p
' ( )
( )
( )
( )
=
+
1
1
si et
si et
sinon
(iv) on note alors M|t~M
Les Iigures suivantes illustrent un systeme d'un producteur et de 2 consommateurs utilisant
une memoire tampon. Le producteur genere des elements (representee par des jetons), qui
sont places dans la memoire tampon |Mazigh 95|. Les consommateurs peuvent enlever les
elements qui sont produits.
producteur
consommateur
consommateur
mmoire
tampon
Figure 89 : Reseau de Petri d'un systeme d'un producteur et de deux consommateurs.
134
producteur
consommateur
mmoire
tampon
Figure 90 : representation des producteurs et consommateurs par des jetons .
Dans le cas ou une place est a la Iois en entree et en sortie de la transition, le marquage ne
change pas, puisque le jeton est retire, puis ajoute. La notion de temps n'intervient pas
explicitement dans cette deIinition. Neanmoins, si on considere un reseau de Petri comme un
modele du comportement dynamique d'un systeme, les notions de sequentialite et de
parallelisme par exemple induisent une dimension temporelle. Dans un reseau de Petri
ordinaire, le tir d'une transition est instantane, mais rien n'oblige a tirer une transition des
qu'elle est validee. Mais d'autre part, rien n'interdit de tirer simultanement plusieurs
transitions validees, sauI dans le cas ou une transition ne serait plus validee apres le tir d'une
autre transition validee : on parle alors de conflit. Un conIlit ne peut se produire que si une
place a plus d'une transition en sortie. Un RdP est donc dit sans conflit si toute place a au plus
une transition de sortie. On parle de RdP a choix libre si pour toute place p ayant plus d'une
transition en sortie, chacune de ces transitions admet uniquement la place p en entree.
Dans la deIinition que nous avons donnee d'un reseau, il ne peut y avoir plus d'un arc entre
une place et une transition, on entre une transition et une place. Les reseaux place/transition
autorisent des arcs multiples. Pour ne pas alourdir la representation graphique, on conserve un
arc unique entre deux noeuds, qu'on annote par un poids, representant le nombre d'arcs entre
ces noeuds :
Dfinition 7
Un tuple (P,T,A,M
0
,W) est un reseau place/transition si :
(i) (P,T,A,M
0
) est un reseau de Petri
(ii) W : A N 0} , est une Ionction qui a chaque arc associe une ponderation non
nulle.
On adapte Iacilement la regle de tir au comportement des reseaux place/transition :
Dfinition 8
Soit (P,T,A,M
0
,W) un reseau place/transition :
(i) une transition t T est dite validee pour le marquage M ssi p t , M(p) W(p,t)
(ii) le marquage M resultant du tir de la transition t validee pour M est tel que p P :
M p
M p W p t p t p t
M p W t p p t p t
M p W p t W t p p t p t
M p
' ( )
( ) ( , )
( ) ( , )
( ) ( , ) ( , )
( )
=
+
+
si et
si et
si et
sinon
Certains auteurs integrent dans les RdP place/transition la notion de capacite : le tir d'une
transition ne doit pas conduire au marquage d'une place qui excederait sa capacite. En Iait, il
est toujours possible de se ramener au cas precedent par une transIormation simple du reseau
Commentaire [CC6] : Page:
133
(* Iigure : correspondant a
l'exemple pour les RdP simples ...
*)
135
(en rajoutant en parallele a chaque place une nouvelle place avec un nombre de jetons egal a
la capacite de la premiere place |Reisig 85|). L'ajout d'arcs inhibiteurs apporte aux RdP la
puissance d'expression d'une machine de Turing : la presence d'un arc inhibiteur entre une
place et une transition bloque le tir de celle-ci dans le cas ou la place n'est pas vide. Dans un
esprit similaire, l'ajout dans un reseau condition/evenement de transitions "mortes", qui ne
doivent jamais tre validees, autorise la transIormation des Iormules de la logique des
propositions en reseaux condition/evenement |Reisig 85|.
11.2. RdP de haut niveau
La modelisation de systemes reels par des RdP conduit souvent a une explosion
combinatoire de la taille du reseau. De plus, il semble naturel de travailler avec des jetons
qu'on puisse distinguer (jetons individuels), voire structurer et transIormer. Dans un cadre
general, on a besoin pour cela d'un langage autorisant les notions de tvpes, de variables, et
d'expressions bien formees pouvant tre instanciees et evaluees.
Dfinition 9
On deIinit un langage tvpe L (,J,L
,L
,J
,Jar,Tvpe,,Eval) tel que :
(i) est un ensemble Iini de tvpes, c'est a dire d'ensembles Iinis non vides. On note ~
l'ensemble des elements des types de
(ii) J est un ensemble Iini de variables, disjoint de ~
(iii) L
(iv) L
,J
est un ensemble d'expressions bien formees, tel que L
L
,J
et J L
,J
(v) Jar : L
,J
J est une Ionction qui associe a chaque expression bien Iormee
l'ensemble de ses variables
(vi) Tvpe : L
,J
est une Ionction qui associe un type a chaque expression bien
Iormee
(vii) est un ensemble de Ionctions d'instanciation (ou liens, ou substitutions closes), tel
que et e L
,J
l'expression close e L
~ est une Ionction qui a chaque expression close associe une valeur
du type de l'expression : Eval(e) Tvpe(e)
Cette deIinition d'un langage type donne les outils suIIisants pour deIinir des RdP de haut
niveau manipulant des jetons structures, sans qu'il soit necessaire d'expliciter le mecanisme de
construction des expressions, ou la methode d'evaluation. Comme exemple de tels langages,
on peut citer la logique du premier ordre (RdP predicat/transition |Genrich 87|), les types
abstraits algebriques (RdP algebriques |Reisig 91|), l'algebre des relations (RdP relationnels
|Reisig 85|), les langages Ionctionnels comme ML (RdP colores |Jensen 92|) ou les langages
orientes objet (RdP a objets |Sibertin-Blanc 91|)...
Exemple de reseau de Petri colore |Jensen 92|
L'exemple ci-dessous decrit la synchronisation de n (n 3) bases de donnees DBM { d1,
..., dn} contenant chacune une replique des mmes donnees. Le probleme consiste a maintenir
la coherence de l'ensemble des bases quand on eIIectue une mise a jour sur l'une d'entre elle.
Pour cela la base qui eIIectue la mise a jour envoie un message (MES {(s,r) tel que s, r
DBM s r}) a toutes les autres bases aIin de reproduire la mme mise a jour (Mes(s)
{ }
1' ( , ) s r
r DBM s
variables s, r . DBM
mettre jour
et envoyer
messages
attente actif passif inactif ex cution libre re u
recevoir toutes
les
confirmations
recevoir un
message
envoyer une
confirmation
Mes(s)
(s, r)
MES
DBM
MES
E E
MES
Mes(s)
(s, r)
r
r
r
r
MES
(s, r)
(s, r)
s
s
s
s
e
e
e
e Mes(s)
Mes(s)
MES
DBM
e
Figure 91 : Reseau de Petri colore d'une base de donnees distribuee.
La Iigure montre que chaque base peut tre dans les etats : inactif, attente (c'est-a-dire en
attente de conIirmation) et execution (c'est-a-dire en cours de traitement du message - mise a
jour de la base). Chaque message peut tre dans les etats : libre, envove, reu et confirme.
EnIin le systeme peut tre passif ou actif. Initialement, tous les messages sont dans l'etat
libre et les bases dans l'etat inactif. Quand une base s, declenche la transition mettre a four
et envover messages, son etat passe de inactif a actif et l'etat de son message passe de
libre a envove. La base doit alors attendre que toutes les autres bases declenchent la
transition envover confirmation.
Quand une des autres bases reoit un message, elle passe de l'etat inactif a execution, et
l'etat du message (s,r) passe de envove a reu. Ensuite la base r peut activer la transition
Envover une confirmation et son etat passe de l'etat execution a inactif, alors que l'etat du
message (s, r) passe de reu a confirme. Apres que tous les messages Mes(s) qui etaient
envoyes par la base s aient ete conIirme, la base s peut declencher la transition recevoir
137
toutes les confirmations et son etat passe de attente a inactif alors que l'etat des messages
Mes(s) passe de confirme a libre.
AIin d'assurer l'integrite entre les diIIerentes bases, la synchronisation represente par la
place passif ne permet qu'une mise a jour a la Iois. Cette place contient initialement un jeton
"incolore" note e (sans inIormation rattachee) et indique que le systeme est passiI.
On peut voir a travers cet exemple les concepts de conIlit, de concurrence et de
dependance causale. Initialement la transition Mettre a four et envover messages est
autorisee pour toutes les bases, mais elle ne peut tre declenchee que par une seule base a la
Iois (a cause du jeton unique dans la place passif). La transition Mettre a four et envover
messages est en conflit avec elle mme, la transition Recevoir un message est en
concurrence avec elle mme et le Iait que la transition recevoir toutes les confirmations
n'est autorisee que quand la transition Mettre a four et envover un message et Envover une
confirmation aient ete declenchees pour toutes les bases autres que s, est appele dpendance
causale.
Maintenant nous donnons la deIinition Iormelle des reseaux de Petri de haut niveau.
Dfinition 1
Un tuple (R,L,C,G,W,I) est un reseau de haut niveau si :
(i) R (P,T,A) est un reseau
(ii) L (,J,L
,L
,J
,Jar,Tvpe,,Eval) est un langage type, tel que le type booleen
Jrai,Faux} soit dans
(iii) C : P est une Ionction qui associe a chaque place du reseau un type, appele
couleur de la place.
(iv) Le langage L est tel que p P, les multi-ensembles Bags(C(p)) construits sur la base
de C(p) sont des types de
(v) G : T L
,J
associe a chaque transition une expression booleenne, appelee garde (ou
selecteur) :
t T, Tvpe(G(t)) Jrai,Faux}
(vi) W : A L
,J
est une Ionction qui a chaque arc associe une expression de type multi-
ensemble :
(p,t) A, Tvpe(W(p,t)) Bags(C(p))
(t,p) A, Tvpe(W(t,p)) Bags(C(p))
(vii) I : P L
est une Ionction d'initialisation, qui a chaque place associe une expression
close de type multi-ensemble :
p P, Tvpe(I(p)) Bags(C(p))
La deIinition originale de Jensen |Jensen 92| autorise plusieurs arcs entre deux noeuds, mais
on peut toujours se ramener a la deIinition precedente par somme symbolique des expressions
sur les arcs (qui sont des multi-ensembles). On peut toujours "deplier" un RdP de haut niveau
en un RdP place/transition equivalent (puisque les couleurs sont des ensembles Iinis |Jensen
92|). Evidemment, une telle transIormation n'est en general pas envisageable en pratique,
mais permet d'utiliser certains resultats theoriques obtenus pour les RdP ordinaires.
138
Dfinition 11
Soit (R,L,C,G,W,I) un reseau de haut niveau :
(i) un marquage M est une application qui a chaque place du reseau associe un multi-
ensemble :
p P , M(p) Bags(C(p))
En particulier, le marquage initial M
0
est donne par l'evaluation de la Ionction
d'evaluation
p P , M
0
(p) Eval(I(p))
(ii) une transition t T est dite validee pour le marquage M et le lien ssi :
p t , M(p) Eval(W(p,t))
(iii) le marquage M resultant du tir de la transition t validee pour M et est tel que p
P :
M p
M p Eval W p t p t p t
M p Eval W t p p t p t
M p Eval W p t Eval W t p p t p t
M p
' ( )
( ) ( ( , ))
( ) ( ( , ))
( ) ( ( , )) ( ( , ))
( )
=
+
+
si et
si et
si et
sinon
Un RdP, mme colore, devient rapidement diIIicile a dessiner sur une seule "page" pour la
modelisation d'un systeme complexe. De plus, la comprehension d'un reseau de grande taille
peut tre problematique. Les RdP colores hierarchiques permettent une structuration des
reseaux, a l'aide de deux mecanismes de base : la substitution de transitions et la Iusions des
places. La substitution des transitions permet de representer un sous-reseau par une transition,
et de renvoyer a la "page" ou est represente celui-ci, un peu a la maniere d'un module en
programmation structuree. Une mme place peut avoir plusieurs representations dans le
reseau, par le principe de fusion des places : lorsque des jetons sont retires ou ajoutes dans
une des instances de la place, ils le sont de mme dans toutes les autres instances. On peut
toujours transIormer un RdP colore hierarchique en RdP non hierarchique. Pour plus de
details sur les reseaux colores, et l'outil Design/CPN qui leur est consacre, on pourra se
reporter a |Jensen 92|.
139
12. Annexe 4 : Schmas d'arcs
12.1. Places "Multi-Ensembles"
12.1.1. Consommation
l
P
T
Marquages
P
1
, , P
l
: P
P
1
P`; ; P
l
P`
P` = P` [ P
1
, , P
l
]
*
P
T
Marquages
P : P
P
*
: bag P
P P`
P
*
= P
P` = P` P
*
12.1.2. Production
l
T
P
Marquages
P
1
, , P
l
: P
P` = P` [ P
1
, , P
l
]
*
T
P
Marquages
P : P
P
*
: bag P
P
*
= P
P` = P` P
*
140
12.1.3. Information
l
P
T
Marquages
P
1
, , P
l
: P
P
1
P`; ; P
l
P`
*
P
T
Marquages
P : P
P
*
: bag P
P P`
P
*
= P
l
P
T
Marquages
P
1
, , P
l
: P
P P`; ; P P`
12.2. Places "Ensembles"
12.2.1. Consommation
l
P
T
Marquages
P
1
, , P
l
: P
P
1
P`; ; P
l
P`
P` = P` \ [ P
1
, , P
l
]
*
P
T
Marquages
P : P
P
*
: P
P P`
P
*
= P
P` = P` \ P
*
141
12.2.2. Production
l
T
P
Marquages
P
1
, , P
l
: P
P` = P` [ P
1
, , P
l
]
*
T
P
Marquages
P : P
P
*
: P
P
*
= P
P` = P` P
*
12.2.3. Information
l
P
T
Marquages
P
1
, , P
l
: P
P
1
P`; ; P
l
P`
*
P
T
Marquages
P : P
P
*
: P
P P`
P
*
= P
l
P
T
Marquages
P
1
, , P
l
: P
P
1
P`; ; P
l
P`
142
13. Annexe 5 : Grammaire d'un extrait du langage rps
<programme> ::=
[<declaration>|<action>|<etiquette>]*
<declaration> ::=
<declaration_variable> |
<declaration_macro>
<declaration_variable> ::=
.declare <nom_var> <type>
<type> ::=
A<nombre> |
9
<declaration_macro>::=
.define <nom_macro> [<etiquette> | <action>]* ..
<etiquette> ::=
.&<nom_etiquette>
<action> ::=
<affectation> |
<branchement> |
<alternative> |
<action_sql> |
<action_elementaire> |
<edition> |
<macro>
<affectation> ::=
.set <nom_variable> <constante> |
.equal <nom_var> <nom_var> |
.add <nom_var> <operande> <operande> |
.sub <nom_var> <operande> <operande> |
.mult <nom_var> <operande> <operande> |
.div <nom_var> <operande> <operande>
<operande> ::=
<nom_variable> |
<constante>
<branchement> ::=
.goto <nom_etiquette>
<alternative> ::=
.if "<condition>" then <nom_etiquette> [else
<nom_etiquette>] |
.ifnull <nom_variable> <nom_etiquette>
143
<action_sql> ::=
<sql_insert> |
<sql_select> |
<sql_update> |
<sql_delete>
<sql_insert> ::=
INSERT INTO <nom_table> (<liste_nom_col>) VALUES
(<liste_expression_var>)
<liste_nom_col> ::=
<nom_col> |
<nom_col>,<liste_nom_col>
<liste_expression_var> ::=
<expression_var> |
<expression_var>,<liste_expression_var>
<expression_var> ::=
<constante> |
<variable> |
nvl( <nom_variable>, <expression_var> ) |
decode( <liste_expression_var> ) |
to_date( <expression_var>, <format_date> ) |
substr( <expression_var>, <entier>, <entier>) |
to_char( <expression_var>[, <format> ])
<sql_select> ::=
SELECT <liste_expression_col> INTO <liste_nom_var> FROM
<liste_nom_tab> WHERE <expression_where>
<liste_nom_var> ::=
<nom_var> |
<nom_var>,<liste_nom_var>
<liste_expression_col> ::=
<expression_col> |
<expression_col>,<liste_expression_col>
<expression_col> ::=
<constante> |
<nom_var> |
<nom_tab>.<nom_col> |
nvl( [<nom_variable>|<nom_col>], <expression_col> ) |
decode( <liste_expression_col> ) |
to_date( <expression_col>, <format_date> ) |
substr( <expression_col>, <entier>, <entier>) |
to_char( <expression_col>[, <format> ])
<liste_nom_tab> ::=
<nom_tab> |
<nom_tab>,<liste_nom_tab>
144
<expression_where> ::=
<expression_col> < <expression_col> |
<expression_col> <= <expression_col> |
<expression_col> = <expression_col> |
<expression_col> >= <expression_col> |
<expression_col> > <expression_col> |
<expression_col> between <expression_col> and
<expression_col> |
<expression_col> in (<liste_constante>)
<expression_where> and <expression_where> |
<expression_where> or <expression_where> |
not (<expression_where> )
<liste_constante> ::=
<constante> |
<constante>, <liste_constante>
<sql_update> ::=
UPDATE <nom_tab> SET <liste_equalite> WHERE
<expression_where>
<equalite> ::=
<nom_col> = <expression_col>
<liste_egalite> ::=
<egalite> |
<egalite>, <liste_egalite>
<sql_delete> ::=
DELETE FROM <nom_tab> WHERE <expression_where>
<edition> ::=
.report <sql_select> <nom_macro> <nom_macro> <nom_macro>
<macro> ::=
.execute <nom_macro>
145
14. Annexe 6 : Programme source
.set nbinsq42 0
.execute delq42
.report selfmn edtmjr debelm finelm
.execute updqfd
.define delq42
delete from q42
..
.define selfmn
select qdq.nopcqd, qdq.nodeqd, qdq.etatqd, qdq.tauxqd,
qdq.noceqd,
qdq.noetqd, qdq.rissqd, qdq.forjqd,
efi.nodeef, efi.nocdef, efi.rangef, efi.noimef,
efi.cleaef, efi.beneef,
substr(efi.nomuef || ' ' || efi.prenef,1,25),
efi.pjusef, efi.rissef, efi.cpreef,
ipt.nohoip, ipt.clisip, ipt.etatip,
to_char(ipt.dtenip,'YYYYMMDD'), ipt.moenip,
ipt.nodoip, ipt.tyadip, ipt.acciip, ipt.nogeip,
ipt.coetip,
substr(nbm.nomunb||' '||nbm.prennb,1,25),
nbm.nomunb, nbm.prennb, nbm.nopanb,
to_char(nbm.dnainb,'YYYYMMDD'), nbm.sexenb,
nbm.adl1nb, nbm.adcpnb, substr(nbm.bdisnb,1,25),
substr(uef.nomcue,1,25),
uef.nomrue, uef.gregue, uef.caprue, uef.cepaue,
uef.clcnue
into nopcqd, nodeqd, etatqd, tauxqd, noceqd,
noetqd, rissqd, forjqd,
nodeef, nocdef, rangef, noimef, cleaef, beneef,
wnopref, pjusef, rissef, cpreef,
nohoip, clisip, etatip, wdtenip, moenip,
nodoip, tyadip, acciip, nogeip, coetip,
wnomunb,
nomunb, prennb, nopanb, wdnainb, sexenb,
adl1nb, adcpnb, bdisnb,
nomcue, nomrue, gregue, caprue, cepaue,
clcnue
from qdq, efi, uef, ipt, nbm
where qdq.noprqd = 99
and qdq.noreqd = 9
and qdq.denpqd is null
and qdq.daedqd <= to_date(&pjbwdtelmt,'DD-MM-YYYY')
and qdq.nodeqd between '100000' and '2zzzzz'
and efi.nohoef = qdq.nohoqd
and efi.nocdef = qdq.nodeqd
and efi.typeef = qdq.typeqd
and nvl(efi.bapcef,'N') = 'N'
and (efi.pjusef < '51' or efi.pjusef > '60')
146
and uef.notdue = qdq.nodeqd
and nvl(uef.gedeue,'*') not in ('CI','CE')
and uef.typeue = qdq.typeqd
and qdq.daedqd between uef.daefue and nvl(uef.dafiue,
to_date('20991231', 'yyyymmdd'))
and uef.valiue = 'V'
and ipt.nohoip = qdq.nohoqd
and nbm.nomanb = ipt.nomaip
and ipt.tyadip != 'PA'
and ipt.etatip = 'H'
..
.define debfmn
.execute rchdbj
.execute rchfiness
..
.define rchdbj
select uef.gregue, uef.caprue
into wgregue, wcaprue
from uef, ndi
where uef.notdue = ndi.cpivnd
and uef.typeue = 'R'
and to_date(&pjbwdtelmt,'DD-MM-YYYY') between uef.daefue
and uef.dafiue
and uef.valiue = 'V'
..
.define rchfiness
select ndi.nofind
into nofind
from ndi
..
.define finfmn
#t 5
.set wrecap "Nombre d'insertions dans Q42 :"
.print wrecap
#nc
.print nbinsq42
#te
#b
..
.define edtmjr
.set wflag 0
.set werr ""
.execute ctlcom
.ifnull werr edt1
.goto nonedt1
.&edt1
.set wmessag "Incompatibilite entre le grand regime et la
caisse"
.affmsg
.goto fin
.&nonedt1
147
.set werr ""
.execute ctlbdd
.ifnull werr edt8
.goto nonedt8
.&edt8
.set wmessag "Si code accident est '2', le code
presomption doit etre > '32'"
.affmsg
.goto fin
.&nonedt8
.execute rchefc6
.execute rchfub
.execute insq42
.execute updqdq
.&fin
..
.define ctlcom
select '1'
into werr
from sys.dual
where (&gregue = '01' and &caprue between '001' and '999')
or (&gregue = '02' and &caprue between '001' and '999')
or (&gregue = '03' and &caprue between '001' and '999')
or (&gregue = '04'
and (&caprue = '110' or &caprue = '120' or &caprue
= '130'
or &caprue = '140' or &caprue = '150' or &caprue =
'400'))
or (&gregue = '05'
and (&caprue = '051' or &caprue = '052' or &caprue
= '053'))
or (&gregue = '06' and &caprue between '000' and '999')
or (&gregue = '07' and &caprue between '000' and '999')
or (&gregue = '08' and (&caprue = '100' or &caprue =
'200'))
or (&gregue = '09' and (&caprue = '000' or &caprue =
'200'))
or (&gregue = '10' and &caprue = '000')
or (&gregue = '11' and &caprue = '000')
or (&gregue = '12' and &caprue between '000' and '999')
or (&gregue = '13' and &caprue = '000')
or (&gregue = '14' and &caprue between '000' and '999')
or (&gregue = '15' and &caprue between '000' and '999')
or (&gregue = '16' and &caprue between '000' and '999')
or (&gregue = '17' and &caprue = '770')
or (&gregue = '90' and &caprue = '100')
or (&gregue = '91' and &caprue between '000' and '999')
or (&gregue = '92' and &caprue between '000' and '999')
or (&gregue = '93' and &caprue between '000' and '999')
or (&gregue = '94' and &caprue between '000' and '999')
or (&gregue = '95' and &caprue between '000' and '999')
148
or (&gregue = '96' and &caprue between '000' and '999')
or (&gregue = '99' and &caprue between '000' and '999')
..
.define ctlbdd
select '1'
into werr
from sys.dual
where (&moenip = '5' and &cpreef > '32')
or (nvl(&moenip,'*') != '5')
..
..
.define rchefc6
select '1'
into windic
from qdq
where qdq.nohoqd = &nohoip
and substr(qdq.nodeqd,1,1) = '6'
..
.define rchfub
select fub.caetfu
into caetfu
from fub
where fub.noetfu = &noetqd
and fub.invafu = 'V'
and to_date(&pjbwdtelmt,'DD-MM-YYYY') between fub.datdfu
and fub.datffu
..
.define insq42
insert into q42
(c1tr42, c2tr42, nofi42, nosi42, dten42,
nmaj42,
grpi42, capi42, grge42, cage42, cege42,
clge42,
tydo42,
nape42, dtem42, caet42, noce42, noss42,
clss42, npas42, npma42, rang42, bene42,
dnai42,
sexe42,
pjus42, adma42, cpma42, bdma42,
aipr42,
typa42,
dtai42,
risq42, taux42,
mode42, nodo42, notd42,
notd42, ando42)
values (&pjbentete1, &pjbentete2, &nofind, &nohoip,
to_char(to_date(&wdtenip,'yyyymmdd'),'YYMMDD'),
decode(&etatqd,'A','10','M', '12', '11'),
&wgregue, &wcaprue, &gregue, &caprue, &cepaue,
&clcnue,
decode(&windic,'1','5','4'),
'2', &wdatejr, &caetfu,'', &noimef,
149
&cleaef, &wnopref, &wnomunb, &rangef, &beneef,
to_char(to_date(&wdnainb,'yyyymmdd'),'YYMMDD'),
decode(&sexenb,'M','1','2'),
&pjusef, &adl1nb, &adcpnb, &bdisnb,
decode(&acciip,
'N','0',
'O','1',
decode(&moenip,
'4','1',
'5','2',
'0')),
'',
decode(&acciip,
'O', &dtenip,
'N',''),
decode(&wrisq42,'18','18',&rissqd),
decode(&wrisq42,'18','080',
decode(&rissqd, '30','100',
'40','100',
'50','100',
lpad(ltrim(rtrim(to_char(&tauxqd))),3,'0'))),
&moenip,
decode(&moenip, '0',&nodoip, '3',&nodoip, ''),
&nocdef, &nomcue,
substr(&wdatejr,1,1)||substr(&nohoip,2,1))
..
.define updqdq
update qdq
set denpqd = trunc(sysdate),
henpqd = to_char(sysdate, 'HH24MI'),
noreqd = 0,
daedqd = to_date('31122099', 'DDMMYYYY'),
rideqd = decode(&wrisq42,'18','18', &rissqd),
txdeqd = decode(&wrisq42,'18','080',
decode(&rissqd,'30','100',
'40','100',
'50','100',
lpad(ltrim(rtrim(to_char(&tauxqd))),3,'0')))
where qdq.nohoqd = &nohoip
and qdq.nsdeqd = &nodeef
and qdq.noqdqc = &nopcqd
..
.define updqfd
update qfd
set qfd.cpbcqf = 'N',
qfd.cdbcqf = 'N',
qfd.dapbqf = to_date(&pjbdtelan,'DD-MM-YYYY'),
qfd.hepbqf = substr(&pjbhrelan,1,2)
||substr(&pjbhrelan,4,2),
qfd.reelqf = &pjbwtyptrt,
qfd.dtliqf = to_date(&pjbwdtelmt,'DD-MM-YYYY')
150
..
.define ctlq42
select '1', nmaj42
into werr, etat42
from q42
where q42.nosi42 = &nohoip
and q42.dten42 =
to_char(to_date(&wdtenip,'yyyymmdd'),'YYMMDD')
151
15. Annexe 7 : Contraintes du rseau formel initial
--T1
P2.nbinsq42 = 0
--delq42
TRUE
--selfmn
qdq1.nopcqd = P4.nopcqd
qdq1.nsdeqd = P4.nsdeqd
qdq1.nodeqd = P4.nodeqd
qdq1.etatqd = P4.etatqd
qdq1.tauxqd = P4.tauxqd
qdq1.noceqd = P4.noceqd
qdq1.noetqd = P4.noetqd
qdq1.rissqd = P4.rissqd
qdq1.forjqd = P4.forjqd
efi1.nocdef = P4.nocdef
efi1.rangef = P4.rangef
efi1.noimef = P4.noimef
efi1.cleaef = P4.cleaef
efi1.beneef = P4.beneef
substr(efi1.nomuef || ' ' || efi1.prenef,1,25) =
P4.wnopref
efi1.pjusef = P4.pjusef
efi1.rissef = P4.rissef
efi1.cpreef = P4.cpreef
ipt1.nohoip = P4.nohoip
ipt1.clisip = P4.clisip
ipt1.etatip = P4.etatip
to_char(ipt1.dtenip,'YYYYMMDD') = P4.wdtenip
ipt1.moenip = P4.moenip
ipt1.nodoip = P4.nodoip
ipt1.tyadip = P4.tyadip
ipt1.acciip = P4.acciip
ipt1.nogeip = P4.nogeip
ipt1.coetip = P4.coetip
substr(nbm1.nomunb||' '||nbm1.prennb,1,25) = P4.wnomunb
nbm1.nomunb = P4.nomunb
nbm1.prennb = P4.prennb
nbm1.nopanb = P4.nopanb
to_char(nbm1.dnainb,'YYYYMMDD') = P4.wdnainb
nbm1.sexenb = P4.sexenb
nbm1.adl1nb = P4.adl1nb
nbm1.adcpnb = P4.adcpnb
substr(nbm1.bdisnb,1,25) = P4.bdisnb
substr(uef1.nomcue,1,25) = P4.nomcue
uef1.nomrue = P4.nomrue
uef1.gregue = P4.gregue
uef1.caprue = P4.caprue
uef1.cepaue = P4.cepaue
uef1.clcnue = P4.clcnue
152
qdq1.noprqd = 99
qdq1.noreqd = 9
qdq1.denpqd is null
qdq1.daedqd <= to_date(P4.pjbwdtelmt,'DD-MM-YYYY')
qdq1.nodeqd between '100000' and '2zzzzz'
efi1.nohoef = qdq1.nohoqd
efi1.nocdef = qdq1.nodeqd
efi1.typeef = qdq1.typeqd
nvl(efi1.bapcef,'N') = 'N'
(efi1.pjusef < '51' or efi1.pjusef > '60')
uef1.notdue = qdq1.nodeqd
nvl(uef1.gedeue,'*') not in ('CI','CE')
uef1.typeue = qdq1.typeqd
qdq1.daedqd between uef1.daefue and nvl(uef1.dafiue,
to_date('20991231', 'yyyymmdd'))
uef1.valiue = 'V'
ipt1.nohoip = qdq1.nohoqd
nbm1.nomanb = ipt1.nomaip
ipt1.tyadip != 'PA'
ipt1.etatip = 'H'
--T2
P5.wflag = 0
--T3
P6.werr = ""
--ctlcom
P7.werr = '1'
((P6.gregue in ('01', '02', '03', '06', '07', '12', '14',
'15', '16', '91', '92', '94', '95', '96', '99')
and P6.caprue between '001' and '999')
or (P6.gregue in ( '09', '10', '11', '13') and P6.caprue =
'000')
or (P6.gregue in ('08', '90') and P6.caprue = '100')
or (P6.gregue = '04' and P6.caprue in ('110', '120',
'130', '140', '150', '400'))
or (P6.gregue = '05' and P6.caprue in ('051', '052',
'053'))
or (P6.gregue in ('08', '09') and P6.caprue = '200')
or (P6.gregue = '17' and P6.caprue = '770'))
--T4
not(P7.werr is null)
--T5
P7.werr is null
--T6
P10.werr = ""
--T7
--affichage d'un message d'erreur
--ctlbdd
P12.werr = 1
((P10.moenip = '5 and P10.cpreef > '32')
or (nvl(P10.moenip,'*') != '5')
--T8
non(P12.werr is null)
153
--T9
P12.werr is null
--rchefc6
P15.windic = 1
qdq.nohoqd = P13.nohoip
substr(qdq.nodeqd,1,1) = '6'
--T10
--affichage d'un message d'erreur
--rchfub
fub1.caetfu = P17.caetfu
fub.noetfu = P15.noetqd
fub.invafu = 'V'
fub.datdfu <= to_date(P15.pjbwdtelmt,'DD-MM-YYYY')
to_date(P15.pjbwdtelmt,'DD-MM-YYYY') <= fub.datffu
--insq42
q42.c1tr42 = P17.pjbentete1
q42.c2tr42 = P17.pjbentete2
q42.nofi42 = P17.nofind
q42.nosi42 = P17.nohoip
q42.dten42 =
to_char(to_date(P17.wdtenip,'yyyymmdd'),'YYMMDD')
q42.nmaj42 = decode(P17.etatqd,'A','10','M', '12', '11')
q42.grpi42 = P17.wgregue
q42.capi42 = P17.wcaprue
q42.grge42 = P17.gregue
q42.cage42 = P17.caprue
q42.cege42 = P17.cepaue
q42.clge42 = P17.clcnue
q42.tydo42 = decode(P17.windic,'1','5','4'),
q42.nape42 = '2'
q42.dtem42 = P17.wdatejr
q42.caet42 = P17.caetfu
q42.noce42 = ''
q42.noss42 = P17.noimef
q42.clss42 = P17.cleaef
q42.npas42 = P17.wnopref
q42.npma42 = P17.wnomunb
q42.rang42 = P17.rangef
q42.bene42 = P17.beneef
q42.dnai42 =
to_char(to_date(P17.wdnainb,'yyyymmdd'),'YYMMDD')
q42.sexe42 = decode(P17.sexenb,'M','1','2')
q42.pjus42 = P17.pjusef
q42.adma42 = P17.adl1nb
q42.cpma42 = P17.adcpnb
q42.bdma42 = P17.bdisnb
q42.aipr42 =
decode(P17.acciip,'N','0','O','1',decode(P17.moenip,'4','1
','5','2','0'))
q42.typa42 = ''
q42.dtai42 = decode(P17.acciip,'O', P17.dtenip,'N','')
154
q42.risq42 = decode(P17.wrisq42,'18','18',P17.rissqd)
q42.taux42 =
decode(P17.wrisq42,'18','080',decode(P17.rissqd,
'30','100','40','100','50','100',lpad(ltrim(rtrim(to_char(P
17.tauxqd))),3,'0')))
q42.mode42 = P17.moenip
q42.nodo42 = decode(P17.moenip, '0',P17.nodoip,
'3',P17.nodoip, '')
q42.notd42 = P17.nocdef
q42.notd42 = P17.nomcue
q42.ando42 =
substr(P17.wdatejr,1,1)||substr(P17.nohoip,2,1))
--updqdq
qdq.denpqd = trunc(sysdate)
qdq.henpqd = to_char(sysdate, 'HH24MI')
qdq.noreqd = 0
qdq.daedqd = to_date('31122099', 'DDMMYYYY'),
qdq.rideqd = decode(P18.wrisq42, '18', '18', P18.rissqd),
qdq.txdeqd = decode(P18.wrisq42, '18', '080',
decode(P18.rissqd, '30', '100', '40', '100', '50', '100',
lpad( ltrim( rtrim( to_char( P18.tauxqd))), 3, '0')))
qdq.nohoqd = P18.nohoip
qdq.nopcqd = P18.nopcqd
qdq.nsdeqd = P18.nsdeqd
--updqfd
qfd.cpbcqf = 'N'
qfd.cdbcqf = 'N'
qfd.dapbqf = to_date(P19.pjbdtelan,'DD-MM-YYYY'),
qfd.hepbqf = substr(P19.pjbhrelan,1,2)
||substr(P19.pjbhrelan,4,2),
qfd.reelqf = P19.pjbwtyptrt,
qfd.dtliqf = to_date(P19.pjbwdtelmt,'DD-MM-YYYY')
155
16. Annexe 8 : Contraintes du rseau formel final
Transition delq42
TRUE
Transition selImn
qdq.nopcqd = P'3.nopcqd
qdq.nsdeqd = P'3.nsdeqd
qdq.nodeqd = P'3.nodeqd
qdq.etatqd = P'3.etatqd
qdq.tauxqd = P'3.tauxqd
qdq.noceqd = P'3.noceqd
qdq.noetqd = P'3.noetqd
qdq.rissqd = P'3.rissqd
qdq.forjqd = P'3.forjqd
efi.nocdef = P'3.nocdef
efi.rangef = P'3.rangef
efi.noimef = P'3.noimef
efi.cleaef = P'3.cleaef
efi.beneef = P'3.beneef
efi.pjusef = P'3.pjusef
efi.rissef = P'3.rissef
efi.cpreef = P'3.cpreef
ipt.nohoip = P'3.nohoip
ipt.clisip = P'3.clisip
ipt.etatip = P'3.etatip
ipt.moenip = P'3.moenip
ipt.nodoip = P'3.nodoip
ipt.tyadip = P'3.tyadip
ipt.acciip = P'3.acciip
ipt.nogeip = P'3.nogeip
ipt.coetip = P'3.coetip
nbm.nomunb = P'3.nomunb
nbm.prennb = P'3.prennb
nbm.nopanb = P'3.nopanb
nbm.sexenb = P'3.sexenb
nbm.adl1nb = P'3.adl1nb
nbm.adcpnb = P'3.adcpnb
substr(nbm.bdisnb,1,25) = P'3.bdisnb
substr(uef1.nomcue,1,25) = P'3.nomcue
uef1.nomrue = P'3.nomrue
uef1.gregue = P'3.gregue
uef1.caprue = P'3.caprue
uef1.cepaue = P'3.cepaue
uef1.clcnue = P'3.clcnue
qdq.noprqd = 99
qdq.noreqd = 9
qdq.denpqd is null
qdq.nodeqd between '100000' and '2zzzzz'
efi.nohoef = qdq.nohoqd
efi.nocdef = qdq.nodeqd
efi.typeef = qdq.typeqd
156
nvl(efi.bapcef,'N') = 'N'
(efi.pjusef < '51' or efi.pjusef > '60')
uef1.notdue = qdq.nodeqd
nvl(uef1.gedeue,'*') not in ('CI','CE')
uef1.typeue = qdq.typeqd
qdq.daedqd between uef1.daefue and nvl(uef1.dafiue,
to_date('20991231', 'yyyymmdd'))
uef1.valiue = 'V'
ipt.nohoip = qdq.nohoqd
nbm.nomanb = ipt.nomaip
ipt.tyadip != 'PA'
ipt.etatip = 'H'
-- ctlcom
((uef1.gregue {'01', '02', '03', '06', '07', '12', '14',
'15', '16', '91', '92', '94', '95', '96', '99'}
et uef1.caprue <= '001' et uef1.caprue <= '999')
ou (uef1.gregue { '09', '10', '11', '13'} et uef1.caprue
= '000')
ou (uef1.gregue {'08', '90'} et uef1.caprue = '100')
ou (uef1.gregue = '04' et uef1.caprue {'110', '120',
'130', '140', '150', '400'})
ou (uef1.gregue = '05' et uef1.caprue {'051', '052',
'053'})
ou (uef1.gregue {'08', '09'} et uef1.caprue = '200')
ou (uef1.gregue = '17' et uef1.caprue = '770'))
-- ctlbdd
((efi.moenip = '5 et efi.cpreef > '32')
ou (nvl(ipt.moenip,'*') != '5')
-- rchefb6
qdq2.nohoqd = ipt.nohoip
substr(qdq2.nodeqd,1,1) = '6'
-- rchfub
fub.caetfu = P'3.caetfu
fub.noetfu = qdq.noetqd
fub.invafu = 'V'
-- insq42
q42.nofi42 = ndi.nofind
q42.nosi42 = ipt.nohoip
q42.dten42 = ipt.dtenip
q42.nmaj42 = decode(qdq.etatqd,'A','10','M', '12', '11')
q42.grpi42 = uef1.gregue
q42.capi42 = uef1.caprue
q42.grge42 = uef1.gregue
q42.cage42 = uef1.caprue
q42.cege42 = uef1.cepaue
q42.clge42 = uef1.clcnue
157
q42.nape42 = '2'
q42.dtem42 = P'2.wdatejr
q42.caet42 = fub.caetfu
q42.noce42 = ''
q42.noss42 = efi.noimef
q42.clss42 = efi.cleaef
q42.npas42 = efi.nomuef||efi.prenef
q42.npma42 = nbm.nomunb
q42.rang42 = efi.rangef
q42.bene42 = efi.beneef
q42.dnai42 = nbm.dnainb
q42.sexe42 = decode(nbm.sexenb,'M','1','2')
q42.pjus42 = efi.pjusef
q42.adma42 = nbm.adl1nb
q42.cpma42 = nbm.adcpnb
q42.bdma42 = nbm.bdisnb
q42.aipr42 = decode(ipt.acciip,'N', '0', 'O', '1', decode(
ipt.moenip, '4', '1', '5', '2', '0'))
q42.typa42 = ''
q42.dtai42 = decode(ipt.acciip,'O', ipt.dtenip,'N','')
q42.risq42 = decode(efi.rissef,'18','18',qdq.rissqd)
q42.taux42 =
decode(efi.rissef,'18','080',decode(qdq.rissqd,
'30','100', '40', '100', '50','100', lpad( ltrim( rtrim(
to_char( qdq.tauxqd))), 3, '0')))
q42.mode42 = ipt.moenip
q42.nodo42 = decode(ipt.moenip, '0',ipt.nodoip,
'3',ipt.nodoip, '')
q42.notd42 = efi.nocdef
q42.notd42 = uef1.nomcue
q42.ando42 =
substr(P'2.wdatejr,1,1)||substr(ipt.nohoip,2,1))
-- updqdq
qdq.denpqd = trunc(sysdate)
qdq.henpqd = to_char(sysdate, 'HH24MI')
qdq.noreqd = 0
qdq.daedqd = to_date('31122099', 'DDMMYYYY'),
qdq.rideqd = decode(efi.rissef, '18', '18', qdq.rissqd),
qdq.txdeqd = decode(efi.rissef, '18', '080',
decode(qdq.rissqd, '30', '100', '40', '100', '50', '100',
lpad( ltrim( rtrim( to_char( qdq.tauxqd))), 3, '0')))
Transition updqId
qfd.cpbcqf = 'N'
qfd.cdbcqf = 'N'