Methodes D Analyse

H.E.M.E.S.
Informatique
Andr CLARINVAL
Mthodes dAnalyse
dition : septembre 2002
A. CLARINVAL Analyse Introduction 1-1
Chapitre 1. Introduction aux mthodes d'analyse
La matire qui va nous occuper relve de la mthodologie d'analyse des systmes d'information. Ce premier
chapitre introduit brivement les trois termes dfinissant ce contexte : systme d'information, analyse, mtho-
dologie.
1. Systmes d'information
1.1. Le concept d'information
L'information est reprsente par des donnes, c'est--dire des formes crites (textes, nombres ...), picturales
(graphiques, dessins, photos, vidos ...) et sonores. Ces donnes sont matrialises sur des supports (papier,
crans, bandes magntiques, disquettes, CD ...). A ces reprsentations, un tre humain, une organisation ou
une machine (ordinateur, robot ...) attache une signification susceptible d'entraner une modification, imm-
diate ou diffre, de son comportement.
ex.: un automobiliste voyant les lettres STOP sur un panneau rouge octogonal [donnes] arrte sa
voiture [comportement]
ex.: un client ayant reu une facture [donnes] prend son tlphone [comportement] pour donner
un ordre de virement sa banque [donnes]; l'ordinateur de la banque recevant de la ligne tlpho-
nique les chiffres composant le virement [donnes] effectue diverses oprations [comportement]
ex.: aprs avoir accumul des donnes statistiques relatives ses ventes, la concurrence, etc., la di-
rection d'une firme commerciale dcide de changer sa politique et de modifier son catalogue : elle en
retire certains produits et en introduit d'autres ...
On peut dfinir une information comme tant l'accroissement de connaissance dcoulant de l'interprtation
d'un ensemble de donnes. Cette interprtation est le fait d'un acteur humain ou mcanique.
1.2. Applications de l'informatique la gestion des organisations humaines
L'activit d'une entreprise ou d'une organisation humaine manipule de l'information : devis, commandes, fac-
tures, ordres de paiement; fiches de paie, fiches fiscales; critures comptables; plannings; etc. Cette infor-
mation reflte les flux de matires (fabrications, achats, ventes ...), les flux financiers, les changes de servi-
ces ... qui forment la matire de l'activit de l'entreprise. Reue par les acteurs de l'organisation, elle com-
mande leur comportement. Echantillonne et synthtise, elle claire et supporte les dcisions aux diffrents
niveaux de responsabilit dans l'organisation.
Si, d'aprs J. de ROSNAY
1
, "un systme est un ensemble d'lments en interaction dynamique, organiss en
fonction d'un but", on peut, la suite notamment des auteurs de la mthode MERISE
2
, distinguer au sein du
systme qu'est toute entreprise ou organisation les trois sous-systmes schmatiss sur la figure suivante.

1
J. de ROSNAY : Le macroscope; d. du Seuil, 1975.
2
H. TARDIEU, A. ROCHFELD, R. COLLETTI : La mthode MERISE; d. d'Organisation, 1983.
SYSTEME DE
DECISION/PILOTAGE
SYSTEME
D'INFORMATION
SYSTEME OPERANT
support
reflet
commande
Les fonctions d'un systme d'information sont de conserver (mmoriser), crer (transformer) et communi-
quer (diffuser) de l'information, plus prcisment : des donnes que les acteurs interprtent.
De nos jours, les acteurs du traitement de l'information sont les hommes et les machines, et un systme d'in-
formation est partiellement automatis; les oprations sont "programmes" sur des ordinateurs, "manuelles"
(sic) ou "interactives" (c'est--dire mettant en communication immdiate les acteurs humains et mcani-
ques) ... Nous appellerons applications informatiques "applications de l'informatique" serait plus correct
les parties automatises d'un systme d'information.
1.3. Applications techniques et scientifiques de l'informatique
La figure ci-dessus, schmatisant le rle du systme d'information dans une organisation humaine, est transpo-
sable au monde de la technique.
De l'information circule entre les organes d'un appareillage (par exemple, les signaux lectriques l'intrieur
d'un tlviseur) ou d'une machinerie complexe (une centrale lectrique) qui, la fois, en reflte l'tat et en
commande le fonctionnement (l'information affiche sur les tableaux de contrle d'une centrale lectrique sert
la piloter ...). Nous donnerons plus loin le nom de modle d'un phnomne une reprsentation abstraite de
ce phnomne; le rle de l'informatique dans une application de robotisation consiste maintenir, analy-
ser et manipuler un modle mathmatique du processus.
Relevons un usage particulier de l'informatique dans les domaines de la science et de la technique. Alors que
l'on pourrait considrer que le systme d'information d'une organisation telle qu'une entreprise commer-
ciale, un club ou une association, un hpital ou une cole constitue une sorte de simulation en temps rel de
son fonctionnement, les techniciens et les scientifiques ralisent trs couramment des programmes de simula-
tion " l'avance" d'une ralit future, voire purement hypothtique. En recherche mdicale, la simulation in-
formatique commence timidement remplacer l'exprimentation animale ...
Des progrs rcents dans les mthodes de calcul permettent la simulation de beaucoup de structures
physiques sans avoir les construire. La simulation n'est pas seulement moins chre, elle permet
aussi de fournir de l'information qui, sur les modles physiques, est soit trop insaisissable, soit diffi-
cile mesurer. La construction de modles physiques ou informatiques revient gnralement moins
cher que la construction du systme complet et permet de corriger plus tt les dficiences.
1

1
J. RUMBAUGH, al. : OMT Modlisation et conception orientes objet, trad. franaise; Masson, 1995.
2. Analyse des systmes d'information
Comme tout phnomne humain, un systme d'information volue et est priodiquement atteint d'obsoles-
cence. Il est alors ncessaire d'en dvelopper un nouveau ou, du moins, une nouvelle version. Cette ide de
dvelopper ou fabriquer est videmment particulirement pertinente pour la partie "programme" du systme,
c'est--dire pour les applications informatiques.
Dans le dveloppement d'un projet informatique, on donne le nom gnral d'analyse l'ensemble des dmar-
ches accomplies avant de rdiger et mettre au point les programmes.
L'analyse se droule en plusieurs tapes et elle procde diffrents niveaux ou de diffrents points de vue.
2.1. Etapes de l'analyse
La tradition amricaine, foncirement pragmatique, distingue deux tapes : l'analyse ("analysis") des be-
soins puis la conception ("design") de la solution technique. Aux premiers temps de l'informatique (1965-
1975), ces deux tapes taient, dans nos contres, dsignes sous les noms d'analyse fonctionnelle (= tude
des fonctionnalits, c'est--dire de l'utilit, du systme mettre en place) et analyse organique (= description
des organes composant la solution).
Habituellement, une tude pralable d'opportunit part d'une critique du systme d'information
existant, qu'elle dcrit plus ou moins exhaustivement, avec plus ou moins de dtail. Elle justifie une
nouvelle solution, qu'elle recommande et laquelle elle assigne des objectifs. L'tude d'opportunit
dit le "pourquoi"; elle motive la dcision de mettre un projet en chantier.
L'analyse fonctionnelle dtaille le "quoi" de la solution, pas encore le comment : "abstraction
prcise du but de l'application et non de la faon dont elle sera btie".
1
Elle dcrit compltement le
contenu smantique et logique du nouveau systme mettre en place, sans prendre en considration
les moyens mettre en uvre pour le faire fonctionner.
"Comment ?" L'tape de conception dfinit la ralisation de ce systme sous la forme de cons-
tructions programmes et procdures utilisant au mieux les ressources techniques et organisa-
tionnelles : logiciels, quipements, personnel, locaux, horaires, etc.
De manire gnrale [...], le dveloppement d'une application rpond quatre questions :
Application = Quoi + Dans quel domaine + Comment + Avec quelles comptences
Ces questions correspondent diffrents points de vue et concernent diffrents intervenants. Elles
peuvent tre tudies selon des techniques varies, mais doivent dans tous les cas tre considres
pour dvelopper une application :
Quoi faire ? La rponse est exprime par l'utilisateur qui dcrit ce qu'il attend du systme, com-
ment il entend interagir avec lui et quels sont les diffrents intervenants. Il s'agit d'une description
fonctionnelle qui ne rentre pas dans les dtails de la ralisation : le quoi faire est purement des-
criptif.

1
J. RUMBAUGH, al. : op. cit.
Dans quel domaine ? La rponse doit dcrire le domaine (l'environnement) dans lequel l'appli-
cation va exister et prciser quels sont les lments pertinents dans ce domaine pour l'application.
L'tude du domaine est le fruit d'une analyse, totalement dconnecte de toute considration de r-
alisation. Le domaine est analys par un analyste et doit pouvoir tre compris par un utilisateur.
Comment ? Il faut le dterminer lors de la conception. Le comment est le fruit de l'exprience et
du savoir-faire du concepteur. La conception est l'art de rendre possible les dsirs de l'utilisateur
exprims dans le quoi faire en considrant le domaine de l'application et en tenant compte des
contraintes de ralisation.
Avec quelles comptences ? Il faut dterminer tout ce qui est ncessaire la fabrication de l'ap-
plication. Ce point repose sur des comptences techniques pour le dveloppement [...], sur des
comptences d'animation pour l'encadrement des quipes et sur des comptences d'organisation
pour assurer la logistique gnrale.
1
2.2. Niveaux de modlisation
Le texte reproduit ci-dessus souligne la multiplicit des points de vue dvelopps lors de l'analyse (au sens
large) d'une application informatique.
Et, en effet, l'analyse d'un systme d'information consiste pour l'essentiel en tablir diffrents modles, c'est-
-dire diffrentes reprsentations abstraites et rductrices, selon divers points de vue qui se compltent pro-
gressivement.
Les modles mathmatiques mis au point par les astronomes leur permettent de prvoir des annes
l'avance les phnomnes clestes tels que les clipses; leurs abstractions mathmatiques s'avrent
d'une efficacit infaillible. Pour tablir leurs prvisions, plus alatoires, les mtorologues se fondent
sur des modles probabilistes.
Nous l'avons dj voqu : dans les applications industrielles, l'ordinateur qui "pilote" un proces-
sus manipule en ralit un modle mathmatique de ce processus.
Le systme comptable d'une entreprise est un modle de celle-ci, fortement rducteur puisqu'il ra-
mne tous les vnements de la vie de cette entreprise de pures quantifications montaires; il est
nanmoins trs efficace pour la gestion et la conduite de l'entreprise.
Mais on ne recourt pas des modles que pour prvoir ou piloter, on en utilise aussi beaucoup dans les d-
marches de cration. C'est dans ce but que les informaticiens laborent des modles avant de programmer.
Un modle est une abstraction de quelque chose de rel qui permet de comprendre avant de cons-
truire. Parce qu'il ne tient pas compte des lments qui ne sont pas essentiels, le modle est plus fa-
cile manipuler que l'entit originale. L'abstraction est une capacit fondamentalement humaine
qui nous permet de grer la complexit. Depuis des milliers d'annes, les ingnieurs, artistes et arti-
sans construisent des modles pour tester leurs concepts avant de les excuter. Le dveloppement du
matriel informatique et du logiciel ne fait pas exception. Pour construire des systmes complexes,
le dveloppeur doit abstraire diffrentes vues du systme, construire des modles en utilisant une
notation prcise, vrifier que les modles satisfont aux spcifications du systme, et progressivement
ajouter des dtails pour transformer les modles en une implmentation.
2

1
P.A. MULLER : Modlisation objet avec UML; Eyrolles, 1997.
2
Dans le sillage de la mthode MERISE ( 1980), la tradition franaise, plus spculative, distingue des ni-
veaux de modlisation : les niveaux conceptuel, logique et physique.
Ambiguts terminologiques
Conception. Comme traduction du terme amricain "design", le mot conception dsigne le fait d'laborer une
architecture; dans la dmarche franaise, il dsigne le fait de conceptualiser, de rduire l'tat notionnel.
Modle. Lorsqu'ils emploient une expression du genre "le modle relationnel" ou "le modle EntitAsso-
ciation", les informaticiens dsignent une thorie sur laquelle ils se fondent pour structurer leurs propres des-
criptions, qu'ils appellent alors des schmas. (Ajoutons qu'un schma peut tre celui d'un programme de si-
mulation, c'est--dire le modle d'un modle !) Si ces thories de la dcennie 1970 avaient vu le jour dix an-
nes plus tard, sans doute les appellerait-on "paradigme relationnel" et "paradigme EntitAssociation"
comme, en programmation, on parle aujourd'hui du "paradigme Objet".
1
Un schma conceptuel exprime la smantique du systme qu'il reprsente : il fait apparatre les
concepts, avec leurs relations et contraintes. Il a vocation d'tre un instrument d'change comprhen-
sible par l'utilisateur "client" ou "commanditaire" du systme d'information.
Exemples de spcifications :
types d'objets ou concepts : CLIENT, COMMANDE
associations entre types d'objets : 1 CLIENT n COMMANDE
prdicats restrictifs (contraintes) : Qt commande > 0
quations (rgles de calcul) : Qt livre = MIN (Qt commande, Qt en stock)
mthodes abstraites : enregistrer une commande, tablir une facture
2
Un schma logique est la traduction d'un schma conceptuel en termes de composants program-
mables ou, plus largement, ralisables. Refltant le plus directement qu'il se peut la fois la spcifi-
cation conceptuelle et l'tat (la modernit) des ressources et techniques que l'on souhaite mettre en
uvre, il sert de rfrence pour les techniciens du systme d'information.
cls d'accs : rfrence du CLIENT dans l'enregistrement COMMANDE
tables de codification : code Catgorie-Client
actions de vrification des contraintes : si Qt commande = 0 message "cde nulle"
sous-programmes de calcul : Calcul-Echance (date-dpart, dlai) date-chance
Transformation finale d'un schma logique, un schma physique doit prendre en compte les para-
mtres de performance du systme selon diffrents points de vue conomique, technique, scuri-
taire, ergonomique, etc. : configurations matrielles ncessaires, charge et cot d'utilisation des
rseaux de tlcommunication, dlais d'attente des rsultats, protection contre les intrusions et mal-
veillances, etc.

1
Paradigme [logique] : modle thorique de pense qui oriente la recherche et la rflexion scientifiques.
Petit Larousse 1997.
2
Mthode abstraite = prendre note de telle donne, retrouver telle autre information, calculer tel rsultat, etc.
regroupements de donnes (fusion de types d'objets ...)
cryptage des donnes sensibles
ddoublement des contrles de validit dans une architecture dcentralise
choix des polices de caractres pour les affichages lcran
variantes d'une tche : rception des commandes au comptoir, par courrier, par tlphone
2.3. Articulation gnrale de la dmarche
L'tude du texte ci-dessous montrera que les deux dmarches, l'amricaine et la franaise, ne sont pas antino-
miques.
Mais le mrite principal de ce texte (sur lequel il vaut la peine de revenir souvent pour le mditer) est de
mettre en vidence le "souffle" qui doit inspirer l'analyste concepteur.
L'analyse [...]
L'analyse [au sens amricain] remonte de la consquence vers le principe : elle essaie de com-
prendre, d'expliquer et de reprsenter la nature profonde du systme qu'elle observe. L'analyse ne
se proccupe pas de solutions mais de questions; elle identifie le quoi faire et l'environnement d'un
systme, sans dcrire le comment, qui est le propre de la conception.
L'analyse commence par la dtermination du quoi faire, c'est--dire des besoins de l'utilisateur.
Bien souvent, l'utilisateur n'est pas capable d'exprimer clairement ses attentes, de sorte que le cahier
des charges n'est qu'une reprsentation approximative de ses besoins rels. La prsence d'un impo-
sant cahier des charges n'est pas toujours de bon augure. [...] Trop souvent, les cahiers de charges
sont touffus, confus, contiennent des points contradictoires et ne refltent pas les vrais besoins des
utilisateurs. [...]
L'analyse se poursuit par la modlisation du domaine de l'application, c'est--dire par l'identifica-
tion des objets [...] qui appartiennent fondamentalement l'environnement de l'application, et par
la reprsentation des interactions entre ces objets. [...]
L'assise sur les lments du monde rel facilite le dpart de la dmarche car elle concentre la pense
sur des lments concrets. Elle doit imprativement tre poursuivie par une dmarche d'abstraction
qui vise faire oublier les contingences du monde rel et dterminer les concepts fondateurs qui
sont leurs origines. Si la rflexion se focalise trop sur l'existant, les risques sont grands de repro-
duire une solution au lieu d'identifier le problme pos [...].
L'analyse est l'antithse de la conformit. L'analyse est souvent surprenante car elle demande de
changer de point de vue, d'oublier ce qui est connu, ce qui s'impose de prime abord, afin de retrou-
ver l'essentiel, la nature cache des choses. Le propre de l'analyse est de trouver une description
laquelle personne n'avait jamais pens jusqu'alors, mais qui une fois dtermine s'impose au point
d'tre vidente.
Pour prendre une image, analyser c'est regarder un point, un cercle, une ellipse, une droite, deux
droites scantes, une hyperbole et une parabole et reconnatre que toutes ces formes peuvent tre
obtenues par l'intersection d'un plan et d'un cne. Dans ce cas, le principe gnrateur peut tre ex-
prim par une quation de la forme ax
2
+ by
2
+ 2cx + 2dy + e = 0. Cette reprsenta-
tion est conome car elle dcrit l'essentiel. L'analyse va l'essentiel et recherche un modle gnri-
que plus abstrait.
La consquence immdiate d'une analyse bien mene est toujours une grande conomie dans la r-
alisation qui s'ensuit. [...]
Paralllement l'analyse de l'environnement, se droule parfois une analyse de l'existant et des
contraintes de ralisation. L'objet de cette analyse est de comprendre parfaitement les caractristi-
ques et les contraintes de l'environnement de ralisation afin de pouvoir prendre lors de la concep-
tion des dcisions motives et rflchies. [...]
La conception [...]
Comme l'analyse et la conception, la conception et la ralisation se chevauchent en partie. Il est
rare de savoir comment tout faire; pour cette raison, il faut essayer des techniques alternatives,
comparer les rsultats puis choisir en faisant des compromis. La conception et la ralisation se
compltent. La conception a besoin d'exprimenter, la ralisation a besoin de principes directeurs.
Afin de maintenir le plus longtemps possible les bnfices de l'abstraction, la conception est gn-
ralement subdivise en deux tapes : une tape logique indpendante de l'environnement de rali-
sation et une tape physique qui se proccupe de l'ordonnancement des ressources et des particula-
rits des langages de programmation ou de l'environnement d'excution.
La conception est souvent considre, tort, comme un simple enrichissement des rsultats obtenus
durant l'analyse. Il s'agit l d'une vision fortement rductrice qui ignore tout simplement que la
conception est le temps de la mise en uvre du savoir-faire. Ce savoir-faire peut tre interne au
projet ou acquis l'extrieur sous la forme d'outils, de composants rutilisables ou plus largement
de cadres de dveloppement.
1
[...]
La conception dbute par la dtermination de l'architecture du logiciel, c'est--dire par l'labora-
tion des structures statiques et dynamiques qui serviront de charpente pour l'ensemble du dvelop-
pement. L'architecture dfinit la forme gnrale de l'application; de sa qualit dpendent le dve-
loppement et l'volution du logiciel. L'architecture est la consquence de dcisions stratgiques ar-
rtes lors de la conception et de dcisions tactiques prises en cours de ralisation.
Se donner une stratgie informatique, c'est considrer le logiciel comme un lment dterminant du
dveloppement de l'entreprise; c'est aussi chercher s'assurer une avance technologique par des
choix d'architecture qui dpassent le cadre des besoins immdiats, lis une application particu-
lire.
Se donner une stratgie informatique, c'est par exemple choisir :
l'internationalisation, autrement dit, concevoir le logiciel de telle manire que le dialogue avec
l'utilisateur puisse tre men dans toutes les langues;
la rutilisation qui n'est pas le fruit du hasard, mais le rsultat d'une adhsion forte de toute une
organisation, depuis la dfinition de la ligne de produits jusqu'au dveloppement de ces produits;
l'unicit de langage pour l'ensemble des dveloppements (Ada dans le cas du ministre de la d-
fense amricain);
l'indpendance par rapport aux dispositifs d'affichage, autrement dit, le dcouplage entre l'in-
formation afficher et la manire de l'afficher;
la portabilit des sources, voire des excutables, qui rduit notablement les cots de dveloppe-
ment et surtout de maintenance dans le cas d'un logiciel multicibles.
[...]

1
"Frameworks".
L'effort dvelopp en conception est plus ou moins important selon la nature de l'application et la ri-
chesse de l'environnement de ralisation. Il est de plus en plus possible d'effectuer un transfert de
complexit des applications vers les environnements [de dveloppement], grce une factorisation
des lments et des mcanismes communs. C'est le cas dans les familles d'applications bien cibles
dans un domaine donn, comme les logiciels clients qui interagissent avec des serveurs de bases de
donnes. Inversement, plus une application est technique, plus elle interagit avec des matriels par-
ticuliers et plus l'effort de conception est important.
Les outils RAD dveloppement rapide d'applications
1
proposent une voie bien trace.
2
[...]
Il faut suivre les rgles du jeu fixes l'avance : au bnfice de la simplicit mais au dtriment de
l'originalit. Toutes les applications finissent par se ressembler, ce qui est bien et mal la fois. Le
travers des outils RAD est d'encourager faire vite et salement quick and dirty plutt que vite
et bien.
Curieusement, le RAD est un mlange de gnie logiciel dans sa conception et d'horreur informatique
dans son utilisation. Ceci est la consquence d'une vision court terme des utilisateurs pour qui
seul l'aspect rapidit compte bien souvent. Comme le RAD n'encourage pas particulirement la mo-
dularit et les abstractions en couches, trs rapidement c'est le cas de le dire le code d'inter-
face utilisateur et le code de l'application se retrouvent intimement mlangs. Le logiciel construit
de cette manire est difficile maintenir et quasiment impossible rutiliser pour une autre appli-
cation.
Le propre de la conception est de rechercher l'quilibre entre vitesse de ralisation et possibilit de
rutilisation, ouverture et solution cl en main, vision court terme (la tactique) et vision long
terme (la stratgie).
3
3. Mthodologie de l'analyse
3.1. Contenu d'une mthodologie
Une mthode d'laboration de logiciels dcrit comment modliser et construire des systmes logi-
ciels de manire fiable et reproductible.
De manire gnrale, les mthodes permettent de construire des modles partir d'lments de mo-
dlisation qui constituent des concepts fondamentaux pour la reprsentation de systmes ou de ph-
nomnes. Les notes reportes sur les partitions sont des lments de modlisation pour la musique.
L'approche objet propose l'quivalent des notes ce sont les objets pour la reprsentation des
logiciels.

1
RAD "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il prconisa, en
1991 (d. MacMillan Publishing), une nouvelle stratgie pour le dveloppement des projets informatiques :
au lieu du comportement traditionnel consistant dfinir d'abord les limites de l'application raliser et voir
ensuite les quipes de dveloppeurs accumuler les retards et dpasser toutes les prvisions budgtaires ... fixer
le budget au dpart et demander aux quipes de dveloppement de raliser "ce qu'elles peuvent" dans ce cadre,
en crant des prototypes au moyen d'outils de programmation sophistiqus et rapides. Bref, au lieu de faire
exploser les budgets, restreindre s'il le faut les ambitions du projet ... Le temps ayant pass, on a oubli cette
proposition "rvolutionnaire" pour ne retenir que la suggestion de choisir des outils performants.
2
Les outils de dveloppement rapide (ex.: WinDev, PowerBuilder, Delphi, C++ Builder, ViewAge et d'in-
nombrables autres "studios" de "visual programming") jouissent actuellement d'une grande vogue, qu'expli-
que le seul qualificatif "rapide". On en indique ici les limites et les piges.
3
P.A. MULLER : op. cit.
Les mthodes dfinissent galement une reprsentation, souvent graphique, qui permet d'une part de
manipuler aisment les modles, et d'autre part de communiquer et d'changer l'information entre
les diffrents intervenants. Une bonne reprsentation recherche l'quilibre entre la densit d'infor-
mation et la lisibilit.
En plus des lments de modlisation et de leurs reprsentations graphiques, une mthode dfinit
des rgles de mise en uvre qui dcrivent l'articulation des diffrents points de vue, l'enchanement
des actions, l'ordonnancement des tches et la rpartition des responsabilits. Ces rgles dfinissent
un processus qui assure l'harmonie au sein d'un ensemble d'lments coopratifs et qui explique
comment il convient de se servir de la mthode.
1
Une mthodologie d'analyse propose au concepteur des modles, des mthodes et des outils.
Un modle, au sens d'une thorie de la modlisation, est un ensemble de concepts et de lois (de
compltude, de cohrence, de transformation ...) unissant ces concepts. Concepts et lois qui per-
mettent de dcrire "intelligemment" une ralit. A titre subsidiaire, un modle comporte des forma-
lismes, qu'il ne faut pas croire limits aux seuls schmas graphiques ou diagrammes dont, l'instar de
tout concepteur, les informaticiens sont friands.
Une mthode propose des dmarches et des rgles de bon usage. Idalement, elle se fonde sur
des modles prouvs et vise en exploiter les potentialits en vue de fabriquer des objets rpondant
certains critres de qualit (comme, par exemple, les options stratgiques listes dans le texte cit
plus haut).
Depuis la fin de la dcennie 1980-90 sont apparus sur le march des outils logiciels d'aide l'ana-
lyse. Ces outils ont reu le nom de "CASE tools" ("Computer Aided Software Engineering") ou, en
franais, d'ateliers de gnie logiciel. Gradation des tches effectues par ces outils :
support (enregistrement et restitution) des formalismes, particulirement des dessins;
application (vrification) des rgles de syntaxe, de cohrence, de compltude ...;
exploitation des lois de transformation spcifiques des modles,
se basant sur les proprits des objets dj dfinis pour dfinir de nouveaux objets ...
3.2. Utilit d'une mthode
[Une] mthode est ncessaire :
pour matriser la complexit du problme informationnel rsoudre;
pour sortir la construction des systmes d'information de l'empirisme individuel et la fonder sur
une coopration efficace entre informaticiens et gestionnaires;
pour permettre la communication entre individus de l'quipe de conception;
pour construire des systmes pertinents, fiables, flexibles et adaptatifs;
pour permettre d'valuer le systme tout moment de son cycle, tant sur le plan de son efficacit
technique que sur celui de sa pertinence par rapport aux besoins des gestionnaires;
pour amliorer les cots, les dlais et la productivit des activits de dveloppement.
2

1
2
C. ROLLAND : Introduction la conception des systmes d'information et panorama des mthodes dispo-
nibles; in Gnie Logiciel, n 4.
Watts S. Humphrey a propos cinq niveaux de maturit des processus de dveloppement de logiciel :
initial : le dveloppement n'est pas formalis, l'quipe ragit au jour le jour et choisit des solu-
tions au cas par cas, de sorte que le succs dpend fortement des personnes impliques dans le pro-
jet;
reproductible : l'organisation est capable d'tablir des plans raisonnables en termes de budget et
de vrifier l'tat d'avancement du projet par rapport ces plans;
dfini : le processus de dveloppement est bien dfini, connu et compris par tous les intervenants
du projet;
encadr : les performances du processus de dveloppement sont mesurables objectivement;
optimisant : les donnes de contrle des performances du processus permettent l'amlioration du
processus.
[...]
Le diagramme suivant reprsente les cinq niveaux de maturit des processus.
1
optimisant
encadr
dfini
reproductible
initial
Les quipes de dveloppement ont besoin dune mthode de travail contrle, dun processus int-
grant les diverses facettes du dveloppement et dune approche commune, cest--dire dun pocessus
capable :
de dicter lorganisation des activits de lquipe;
de diriger les tches de chaque individu et de lensemble de lquipe;
de spcifier les artefacts produire;
de proposer des critres pour le contrle et lvaluation des produits et des activits du projet.
2
3.3. Schmas et Maquettes
"Un modle est une description abstraite d'un systme ou d'un processus, une reprsentation simplifie qui
permet de comprendre et de simuler."
3
Un schma, dress dans les formes fixes par un paradigme thorique,
constitue une sorte de "discours" sur le domaine dcrit, dont l'ambition est double :
discours expliquant que le domaine tudi est intelligible, un schma sert faire partager d'au-
tres (et l'ordinateur ?) la connaissance relative ce domaine;
image simulant la ralit venir, un schma permet galement de vrifier, l'avance, la pertinence
de cette ralit future.

1
2
I. JACOBSON, G. BOOCH, J. RUMBAUGH : Le processus unifi de dveloppement logiciel, trad. fran-
aise; Eyrolles, 2000.
3
Les informaticiens recourent de plus en plus souvent la ralisation (au moyen d'outils RAD de dveloppe-
ment rapide) de maquettes, "modles rduits" utiliss pour vrifier exprimentalement l'adquation de leurs
hypothses de travail.
Avant la construction proprement dite, les concepteurs laborent de nombreux types de modles
pour des besoins divers; par exemple, des maquettes architecturales l'intention du client, des
prototypes d'avions pour les tests en soufflerie, des esquisses au crayon avant le tableau dfinitif, des
plans techniques, des scnarimages publicitaires, des maquettes de livres, etc. Les modles visent
diffrents objectifs :
tester une entit physique avant de la construire. Les maons du Moyen Age ne connaissaient
pas la physique moderne, mais ils construisaient des modles l'chelle des cathdrales gothiques
afin de tester les forces intervenant dans la structure. Les modles rduits d'avions, de voitures ou
de bateaux sont tests en soufflerie ou en bassin pour amliorer l'arodynamique ou l'hydrodynami-
que. Des progrs rcents dans les mthodes de calcul permettent la simulation de beaucoup de
structures physiques sans avoir les construire. La simulation n'est pas seulement moins chre, elle
permet aussi de fournir de l'information qui, sur les modles physiques, est soit trop insaisissable,
soit difficile mesurer. La construction de modles physiques ou informatiques revient gnrale-
ment moins cher que la construction du systme complet et permet de corriger plus tt les dficien-
ces.
communiquer avec le client. Les architectes et les concepteurs de produits construisent des mo-
dles de dmonstration. Les maquettes sont des modles imitant tout ou partie du comportement
extrieur du systme.
visualiser. Les "scnarimages" de films, tlfilms et publicits permettent aux scnaristes de voir
l'articulation de leurs ides. Les transitions brutales, les dnouements qui n'en finissent pas, et les
passages inutiles peuvent tre modifis avant l'criture du script final. Les croquis permettent aux
artistes de jeter leurs ides et de les modifier avant de passer l'huile ou la pierre.
rduire la complexit. La principale raison, sans doute, de la modlisation, et qui englobe toutes
les autres, est la possibilit qu'elle donne d'apprhender des systmes qui seraient trop complexes
comprendre directement. Le cerveau humain ne peut travailler qu'avec une somme limite d'infor-
mations la fois. Les modles rduisent la complexit dans la mesure o ils isolent un petit nombre
de choses importantes examiner la fois.
1
Le domaine privilgi de la ralisation de maquettes est celui du dialogue de l'interface entre l'homme et
la machine.
La conception de l'interface est une nouveaut pour la majorit des informaticiens. Autrefois, l'ac-
cent tait mis sur la conception et le dveloppement de l'application, principalement sur les donnes
et les traitements. Une application juge convenable tait avant tout une application sans anoma-
lies, livre temps et qui comportait peu prs les fonctionnalits dcrites dans le cahier des char-
ges. L'aspect interface tait trs limit : seuls taient prsents, sur papier, et dans le meilleur des
cas, quelques crans ou tats [imprims] de la future application. Les outils utiliss ne permet-
taient pas de crer rapidement une maquette complte de l'application.

1
En raison du peu de moyens disponibles, la diffrence entre un design soign et un mdiocre tait
quasiment inexistante. Les erreurs de prsentation taient certainement moins nombreuses et moins
pnalisantes. Aujourd'hui, le dveloppement d'une application en mode graphique passe ncessai-
rement par la fabrication d'une interface de qualit. La cration systmatique d'une maquette de la
future application est incontournable. La conception de l'interface de l'application devient la nou-
velle pierre angulaire de la phase de conception d'un projet. Une prsentation peu soigne, une
conception inadquate, et c'est l'chec. Il convient donc de se pencher avec attention sur le pro-
blme pos par la relation avec l'utilisateur au travers de l'interface.
[...]
L'interface graphique, avec ses fentres multiples, ses objets hauts en relief et en couleur icnes,
images, barres d'outils, ascenseurs ... offre des possibilits immenses pour les dveloppeurs d'ap-
plications. Mais les risques d'erreurs ont grandi d'autant : les variations possibles sont si nombreu-
ses et si subtiles que l'on frle constamment "l'explosion combinatoire" !
1
3.4. Modlisation et Programmation
La plupart des paradigmes d'analyse "Structured Analysis", modle en rseau, modle relationnel, con-
ception oriente objet, etc. sont des modles initialement mis au point pour la programmation, dont on a
par la suite largi le champ d'application, de faon telle que leurs concepts puissent dcrire d'autres ralits
que des composants de programmes. Aprs avoir outill l'tape finale de ralisation des systmes d'informa-
tion, les mthodologues largissent leur vision pour remonter vers la source : ils s'intressent l'tape de
conception, puis l'tape d'analyse.
On peut donc affirmer qu'un programme est lui-mme un schma ou/et une maquette, puisqu'il se fonde sur
des concepts de modlisation.
Soulignons alors le paradoxe de la programmation traditionnelle : elle modlise l'ordinateur plus que l'appli-
cation ! En effet, elle se rfre explicitement la structure matrielle de l'ordinateur; le programmeur dcrit
la mmoire centrale comme un ensemble d'emplacements au contenu modifiable les variables et il im-
pose au processeur un plan d'action le programme qui utilise les oprations de base de ce processeur :
l'enchanement squentiel, les tests de conditions, l'appel de procdure et, surtout, l'opration fondamentale de
l'ordinateur : l'affectation d'un contenu une variable. Pour certains, ce paradoxe explique la difficult de la
programmation, son cot exorbitant ... et la lancinante recherche de nouvelles manires d'aborder c'est--
dire de penser et de modliser la programmation et, par extension, l'analyse.
3.5. L'quipe de dveloppement
Pour terminer, voquons les rles qui doivent tre remplis au sein d'une quipe attele la ralisation d'un
projet informatique, et qu'une dmarche mthodique doit coordonner.
Il existe quelques rares informaticiens virtuoses, mais quelles que soient les qualits des individus, il
arrive un moment o l'ampleur de la tche accomplir est telle que l'effort individuel ne suffit plus.
Il convient alors de travailler de concert, de coordonner les efforts et de rechercher la performance
collective partir des capacits moyennes de chacun.

1
J.M. GILLET : L'interface graphique; InterEditions, 1995.
Le choix des personnes qui constituent une quipe de dveloppement dtermine fortement le drou-
lement du projet. Au-del des aspects techniques, le succs d'un projet dpend en grande partie des
facteurs humains. Un bon processus de dveloppement permet prcisment de retirer la quintes-
sence d'une quipe de dveloppement, de manire reproductible et contrle. Les membres d'une
quipe efficace doivent d'une part tre complmentaires, et d'autre part tre bien conscients de leur
rle dans le processus de dveloppement. Il appartient au chef de projet de mettre sur pied cette
quipe de personnes, puis d'entretenir le moral des troupes pendant l'ensemble du dveloppement.
De manire gnrale, un processus de dveloppement de logiciel peut se dcomposer en trois sous-
processus :
le dveloppement informatique proprement dit,
la logistique qui pourvoit aux besoins du dveloppement informatique,
l'interface avec le reste du monde, qui isole le dveloppement des perturbations externes.
[...]
Le dveloppement informatique
Le dveloppement informatique est conduit par les trois acteurs suivants :
l'architecte dfinit la forme gnrale du logiciel [...];
les abstractionnistes (de l'anglais abstractionist) identifient les objets et les mcanismes qui
permettront de satisfaire les besoins de l'utilisateur;
les dveloppeurs matrisent les technologies et ralisent les abstractions identifies par les abs-
tractionnistes.
La logistique
La logistique interagit avec les acteurs suivants :
le chef de projet compose l'quipe, gre le budget et les personnes, et coordonne les diverses acti-
vits;
l'analyste est un expert du domaine, charg de comprendre les besoins des utilisateurs;
l'intgrateur assemble les lments produits par les dveloppeurs [...];
le qualiticien value tous les lments produits par le dveloppement et dirige les tests du sys-
tme;
le documentaliste rdige la documentation destination de l'utilisateur;
l'administrateursystme gre et entretient le parc matriel utilis par le projet;
l'outilleur construit et adapte les outils logiciels qui forment l'environnement de dveloppement;
le bibliothcaire assure l'archivage et la prservation de tous les artefacts du dveloppement et de
leurs rgles de production.
L'interface
L'interface interagit avec les acteurs suivants :
le chef de projet assure l'interface entre l'quipe de dveloppement et le reste du monde;
le chef de produit supervise une ligne de produits; il coordonne les activits de marketing, de
formation et de support technique;
le financier contrle l'allocation du budget et sa bonne utilisation;
l'utilisateur/client participe des revues de prototypes;
le support technique rsout ou contourne les problmes rencontrs par les utilisateurs.
Les rles dcrits prcdemment peuvent tre jous par la mme personne. Dans les petites organi-
sations, il est frquent que le chef de projet remplisse galement les rles d'architecte et d'analyste.
De mme, les dveloppeurs et les abstractionnistes sont souvent confondus.
1
4. Contenu du cours : Modlisation des applications informatiques
L'objet de ce cours est la modlisation des applications informatiques. En principe, nous restreindrons no-
tre propos la partie automatise des systmes d'informations.
Notre ambition est de fournir des techniques d'analyse, ainsi que l'armature intellectuelle qu'implique leur
mise en uvre. Dans ce but, nous nous attacherons dcrire diffrents modles d'analyse, en nous attardant
particulirement aux rgles et critres de manipulation de ces modles. Dans ce premier cours, nous ne traite-
rons pas explicitement de l'intgration de ces modles une dmarche globale d'analyse et de conception ce
sera l'objet d'un second cours.
Une thorie n'est videmment pas n'importe quel texte grammaticalement correct utilisant un ensem-
ble de termes symboliquement relis la ralit. C'est un agrgat systmatique d'noncs de lois.
Son contenu, sa valeur mme en tant que thorie, repose au moins autant sur la structure des inter-
connexions liant les lois que dans les lois elles-mmes. (Il arrive que des tudiants prparant leurs
examens de physique en apprennent par cur des listes d'quations. Ils peuvent parfaitement russir
leurs examens avec de tels exploits de mmoire, sans que l'on puisse pour autant dire qu'ils com-
prennent la physique, autrement dit qu'ils en matrisent les thories.) Une thorie, du moins une
thorie valable, n'est donc pas simplement une sorte de banque de donnes dans laquelle on peut
"rechercher" ce qui se passerait dans telles et telles conditions. C'est plutt une sorte de carte d'un
territoire partiellement explor. Sa fonction est souvent heuristique, c'est--dire qu'elle guide l'ex-
plorateur vers d'autres dcouvertes. Les thories sont donc remarquables [non pas] en ce qu'elles
donnent des rponses des questions, mais [en ce qu'elles] guident et stimulent une recherche in-
telligente. Et il n'y a pas qu'une seule carte "correcte" d'un territoire. Une photographie arienne
d'un territoire sert une fonction heuristique diffrente de celle de la carte dmographique de ce
mme territoire. Un usage de la thorie est donc de prparer les catgories conceptuelles dans les-
quelles les thoriciens et les praticiens poseront leurs questions et concevront leurs exprimenta-
tions.
2
Aux tudiants qui craindraient et tout autant ceux qui espreraient que ce cours leur propose un outil-
lage rendant inutiles les efforts de crativit, nous livrons cette dernire citation.
Une mthode d'analyse doit tre un facteur de crativit pour les analystes et pas le contraire, elle
reprsente un catalyseur de leur savoir-faire mais ne remplace pas celui-ci. Le propre d'une m-
thode de conception n'est pas de rendre ceux qui la pratiquent moins intelligents comme en donnent
l'impression les mthodes formulaires qui affectionnent le style "Petit catchisme" ou le style "pro-
cdure militaire", ainsi que semblent le souhaiter des "responsables mthodes" dans certaines orga-
nisations.
3

1
P.A. MULLER : op. cit
2
J. WEIZENBAUM : Puissance de l'ordinateur et raison de l'homme, trad. franaise; d. d'Informatique,
1981.
3
F. BODART, Y. PIGNEUR : Conception assiste des systmes d'information; Masson, 1989.
Nous nous trouvons aujourd'hui (19952000) une poque d'mergence de nouvelles mthodologies, nces-
sites et entranes par le succs de la programmation par objets. La culture des informaticiens reste nan-
moins imprgne des mthodologies prcdentes, mme s'ils reconnaissent volontiers que leurs modles, outils
et dmarches ne suffisent plus. Les mthodes "orientes objets" elles-mmes n'ont pas soudain fleuri au milieu
d'un dsert culturel; en particulier, leurs modles reprennent leur compte nombre d'acquis des thories ant-
rieures.
Ce cours senracine donc dans ltude des "classiques" que nous ont laisss les mthodes anciennes et dont on
retrouve des traces plus que des traces dans les mthodes nouvelles. Ils sont constitus de quelques
modles (les dmarches s'avrent assurment plus phmres) : modles de donnes et modles des syst-
mes de traitement de l'information. Imitant la programmation de son poque, cette analyse traditionnelle s-
pare nettement la description des donnes et celle des oprations. (Une manire plus moderne de prsenter
cette dichotomie consiste distinguer lanalyse dun domaine dapplication et la spcification des applica-
tions qui seront ralises dans ce domaine.
1
)
Mais on y intgre l'apport du paradigme Objet l'analyse.
2
En effet, ainsi que nous aurons loccasion de le
montrer, le concept dObjet ne contredit pas les notions anciennes; il les unifie.
Pour lanalyse "oriente objets", nous utiliserons un sous-ensemble dUML (Unified Modeling Lan-
guage), "langage de modlisation unifi" mis au point par la socit amricaine Rational Software.
UML a t adopt comme standard par lOMG (Object Management Group) en 1997 et, de ce fait,
simpose de plus en plus rapidement toutes les quipes adeptes des mthodes "Objet".
Pourtant, UML nest pas exempt de dfauts, dont le principal est sans doute de vouloir en faire trop
(ce langage a pour ambition de pouvoir formaliser tout ce que souhaiterait exprimer nimporte quel
analyste !) et le second, de manquer quelquefois de prcision. Cest pour ces motifs que nous nen
exposerons quun sous-ensemble. Nous nous baserons principalement sur les ouvrages suivants :
P.A. MULLER : Modlisation objet avec UML; Eyrolles, 1997.
OMG : Unified Modeling Language Specification, vers. 1.4; www.omg.org, 2002.
Le second de ces ouvrages constitue la dfinition officielle dUML.

1
Voir notamment P.A. MULLER : op. cit. et I. JACOBSON, al.: op. cit.
2
On suppose l'tudiant initi la programmation par objets.
A. CLARINVAL Analyse Modlisation des donnes 2-1
Chapitre 2. Introduction la modlisation des donnes
L'essor des modles de donnes est intimement li celui des bases de donnes.
La premire section de ce chapitre montre quels besoins de modlisation sont ns de l'avnement des systmes
de gestion de bases de donnes (SGBD).
La deuxime section dfinit quelques concepts fondamentaux, communs tous les systmes de modlisation
des donnes.
La troisime section dresse un panorama historique des principaux modles de donnes et de leur utilisation
par les SGBD et les mthodes d'analyse.
1. Bases de donnes et Modlisation
1.1. Le concept de Systme de Gestion de Bases de Donnes (SGBD)
Le concept de base de donnes (en anglais : data base) est apparu au milieu des annes 60, comme palliatif
aux inconvnients des fichiers spcialiss que l'on dfinissait pour couvrir les besoins particuliers de chaque
programme.
Dans ces accumulations de fichiers disperss, il tait frquent que les mmes informations fussent reproduites
plusieurs endroits et de diverses manires : diffrents fichiers dcrivant les clients ou les produits, par
exemple. Dfauts de ces systmes : la redondance (rptition des mmes informations), l'incohrence des
mises jour (les fichiers redondants n'tant mis jour ni en mme temps ni par les mmes responsables), le
partage limit des informations (les divers utilisateurs potentiels ne retrouvant pas leur "point de vue" dans la
manire dont les autres reprsentaient les informations) ...
L'ide premire fut celle d'un stockage intgr, en une seule collection cohrente, des donnes d'une applica-
tion, voire d'une entreprise. L'expression base de donnes est entendre dans le sens de base minimale cou-
vrant la totalit des besoins en information d'une application ou d'une organisation.
Le principe d'intgration entranait de nombreuses consquences : la ncessit de supprimer la redondance ou
du moins de la rduire au minimum, la ncessit de structurer avec rigueur, c'est--dire de modliser, la nces-
sit de stocker en dehors de chaque programme utilisateur une dfinition commune des donnes, la ncessit
de langages de manipulation de donnes adapts, la ncessit de permettre un accs simultan plusieurs
utilisateurs ou programmes, la ncessit de mcanismes garantissant la confidentialit des informations ...
Une base de donnes suppose donc un ensemble de logiciels aptes assurer ces multiples fonctions, qui com-
posent ce qu'on appelle un systme de gestion de bases de donnes, en abrg : SGBD (en anglais : Data
Base Management System ou DBMS).
1.2. Niveaux de modlisation
a) Vues externes
Chaque utilisateur d'une base de donnes a de celle-ci une connaissance partielle et s'en fait une "reprsenta-
tion" personnelle, en a une "vue" particulire. On appelle vues externes ces reprsentations propres aux diff-
rents utilisateurs de la base de donnes.
Exemple.
Une entreprise commerciale possde une base de donnes couvrant tous les besoins en information
des dpartements impliqus dans son activit de vente. Les vendeurs se font l'ide suivante d'un pro-
duit : identification du produit, prix de vente unitaire, taux de TVA applicable, quantit en stock ...
Les responsables de la gestion des stocks en ont la vue suivante : identification du produit (pas n-
cessairement la mme que celle utilise par les vendeurs), stock actuel, stock plancher (minimum),
stock plafond (maximum), identit du fournisseur, dlai de rapprovisionnement ...
b) Vue conceptuelle
En vertu du principe de stockage intgr des donnes, il est ncessaire de concilier les diffrentes vues exter-
nes en une seule vue conceptuelle.
Exemple.
Pour l'entreprise, la dfinition commune du concept de produit est la suivante : identification du pro-
duit (numro et dnomination), prix de vente unitaire, taux de TVA (en % du prix de vente), nu-
mro de fournisseur, dlai de rapprovisionnement (en jours), stock actuel ("quantit en stock" dans
la terminologie des vendeurs), stock plancher, stock plafond.
c) Vue interne
Jusqu'ici, on n'a considr que des notions, des concepts. Pour pouvoir raliser une base de donnes effective,
on doit encore s'en donner une vue interne qui intgre la dfinition conceptuelle les aspects techniques du
stockage des donnes.
Exemple.
Pour faciliter la recherche des produits, on crera un index sur les numros de produits et un autre in-
dex sur les dnominations. En vue de pouvoir lister rapidement les produits livrs par un fournisseur
quelconque, on crera peut-tre un index sur le numro de fournisseur. On choisira de stocker les in-
formations relatives aux produits sur un seul ordinateur ou de les rpartir sur plusieurs ordinateurs ...
vue externe
vue externe
vue externe
vue externe
vue interne
vue conceptuelle
Ce modle de dmarche, trois niveaux de reprsentation, est connu sous le nom de modle ANSI/SPARC
(American National Standard Institute, Standards Planning and Requirements Committee). Il a t publi en
1975-78.
1

1
D. TSICHRITZIS, A. KLUG : The ANSI/X3/SPARC DBMS Framework in Information Systems, 1978.
1.3. Langage de description de donnes Schmas
Un SGBD doit fournir un langage de description de donnes (DDL Data Definition Language) permettant
de cataloguer la dfinition de chacune de ces vues sous une forme exploitable par les ordinateurs.
On donne le nom de schma la dfinition "programme" d'une vue : schma conceptuel, schma interne ou
physique, (sous-)schmas externes. Le schma interne aussi bien que les sous-schmas externes oprationnels
sont des variations drives du schma conceptuel; celui-ci joue le rle de rfrence commune.
2. Fondements des techniques de modlisation des donnes
2.1. Les mcanismes d'abstraction
L'abstraction est l'examen slectif de certains aspects d'un problme. L'objectif de l'abstraction est
d'isoler les aspects importants et de supprimer ceux qui ne le sont pas. L'abstraction se rfre tou-
jours un but prcis, car c'est le but qui permet de dterminer ce qui est important et ce qui ne l'est
pas. Selon le but recherch, il est possible de construire de nombreuses abstractions partir d'une
mme ralit.
Toute abstraction est incomplte et imprcise. La ralit est une toile sans couture. Tout ce qu'on
peut en dire, toute description qu'on peut en faire est un raccourci. Le langage, les mots humains
sont forcment des abstractions, descriptions incompltes du monde rel. Leur utilit n'est toutefois
pas remise en question. Le but de l'abstraction est de limiter l'univers afin de pouvoir agir. Dans la
construction de modles, on ne recherche pas la vrit absolue, mais l'adquation un but donn. Il
n'y a pas de modle "correct" unique d'une situation, seulement des modles adquats ou inad-
quats.
1
a) Classification : Type, Classe, Occurrence, Collection
Dans un processus de modlisation, on ne s'intresse gnralement pas chaque objet particulier de la ralit
dcrite, mais on envisage des classes d'lments. Ainsi, parlant de "CLIENT", on dsignera par exemple
"toute personne physique ou morale ayant pass notre firme au moins un ordre de commande qui a permis de
l'identifier". On dfinit de cette manire le type commun de tous les lments de la classe.
Dans la littrature informatique, par un abus de langage qui complique quelquefois la comprhension des cho-
ses, les deux termes classe et type sont employs l'un pour l'autre : une classe nomme ("CLIENT") et dfi-
nie ("toute personne ayant ...") est galement appele un type. Plus prcisment, une classe est l'ensemble
concret de tous les lments qui vrifient la dfinition d'un type, ensemble abstrait d'lments "imaginables".
Le type est une cration pure de l'esprit, qui n'existe que par sa dfinition.
Tout lment appartenant une classe ou un type est une occurrence (en anglais : "instance") de cette
classe ou de ce type.
Exemples : type occurrences
ETUDIANT Jean, Jacques, Emile
NOMBRE ENTIER 1, 3, 37, 1236, 3217
SEXE masculin, fminin
COMMANDE la-commande-reue-aujourd'hui-du-client-X
FICHIER DE COMMANDES fichier-des-commandes-reues-ce-jour
Le type "FICHIER DE COMMANDES" est un type dont chaque occurrence (par exemple, le "fichier-des-
commandes-reues-ce-jour") constitue un sous-ensemble de la classe "COMMANDE", ce que nous appelle-
rons une collection. Cet exemple illustre la manire de modliser un ensemble : l'ensemble et l'lment font
tous deux l'objet d'une dfinition de type, chaque occurrence d'ensemble (ou collection) est un sous-ensemble
du type de l'lment. Quant au type d'une collection, c'est un ensemble puissance.

1
occurrence
collection
classe
type
La dfinition d'un type est une dfinition d'ensemble, le plus souvent en comprhension ("toute personne
ayant ..."), d'autres fois en extension ("masculin, fminin").
Remarque. Le contexte du discours dispense souvent de prciser si l'on parle de types (par exemple, dans
l'expression abstraite "toute COMMANDE mane d'un et un seul CLIENT") ou d'occurrences ("ma com-
mande du 29/08/2000"). La prsence de quantificateurs "tout, toujours, certains, parfois, un et un seul, un ou
plusieurs, au moins un, un au plus..." est le signe d'un discours abstrait, portant sur les types.
Il est essentiel de fournir la dfinition constitutive des types reconnus; c'est elle qui en exprime la significa-
tion. (Un "CLIENT" est-il "toute personne ayant pass au moins une commande, etc." ou, plus largement,
"tout client ou prospect" ? Les "SEXEs" possibles sont-ils "masculin et fminin" ou plutt "masculin, fminin
et inconnu" ? ...)
b) Spcialisation, Gnralisation
La spcialisation distingue des sous-classes l'intrieur d'une classe, des sous-types l'intrieur d'un type
(ex.: la spcialisation de NOMBRE en ENTIER, REEL, etc.; la spcialisation du PERSONNEL en
OUVRIER et EMPLOYE; la spcialisation des CLIENTS en clients PRIVES et PROFESSIONNELS).
Toute occurrence d'une sous-classe "hrite" des proprits dfinies dans le sur-type (un OUVRIER possde
toutes les proprits d'un membre du PERSONNEL ... plus certaines proprits spcifiques; un CLIENT-
PROFESSIONNEL possde toutes les proprits d'un CLIENT, plus un numro de TVA). Remarquons que
toute dfinition en comprhension ("CLIENT = [1] toute personne [2] ayant ...") relve de la spcialisation.
Pierre
Paul
Jacques
Andr
OUVRIERS EMPLOYES
PERSONNEL
CLIENT
nom
adresse
PRIVE PROFESS.
nTVA
hrite hrite
La gnralisation est une abstraction globalisant (mettant "en vidence") dans un sur-type les proprits
communes de diffrents types (ex.: l'abstraction MOUVEMENT DE STOCK cre sur la base des types
ENTREE EN STOCK et SORTIE DE STOCK, pour laquelle il faut crer artificiellement la proprit SIGNE-
DU-MOUVEMENT).
Grce la non duplication des proprits "mises en vidence" au niveau du sur-type et dont "hritent" auto-
matiquement les sous-types, spcialisation et gnralisation sont des procds conomiques prcieux, permet-
tant de construire des modles plus compacts.
2.2. Mcanisme de dsignation des occurrences
a) La relation de dpendance fonctionnelle
On dit qu'un type d'objet B dpend fonctionnellement d'un type d'objet A si, chaque occurrence de A,
correspond au plus une occurrence de B. Ce qui se note A B. On dit aussi que l'objet B est dtermin par
le dterminant A : connaissant une occurrence de A, on peut retrouver l'occurrence de B correspondante.
Exemples : n national personne
n de TVA firme
n de commande nom du client dont elle mane
La dfinition s'tend facilement au cas des dterminants ou dtermins constitus de groupements d'objets.
Exemples : n national (nom, date de naissance, sexe)
(barme, anciennet) salaire mensuel
La relation de dpendance fonctionnelle est asymtrique. Il n'est pas vrai qu'un client puisse transmettre une
commande au plus; s'il est vrai qu' une personne correspond un seul numro national, cette relation n'est plus
vraie si pour rester pratique on la reformule par rapport aux noms (et prnoms) de personnes ...
b) Le concept d'identifiant
La relation de dpendance fonctionnelle fonde le mcanisme qui permet de distinguer sans ambigut les oc-
currences : le dterminant d'une dpendance fonctionnelle (ex.: n national, n de TVA, le couple barme +
anciennet) sera choisi pour "dsigner" les occurrences. On dira alors qu'il constitue l'identifiant des occur-
rences (ex.: "l'occurrence de COMMANDE dont le n de commande est 00317").
2.3. Dimensions temporelles de l'information
Bien qu'il soit impossible d'tablir un bon schma de donnes sans prendre en compte les proprits tempo-
relles de l'information, les modles courants ne fournissent pas de concept particulier pour dcrire cet aspect
des choses ... devant lequel l'analyste se sent donc plus d'une fois mal l'aise.
Les paragraphes suivants introduisent le problme, en distinguant des dimensions temporelles multiples.
a) Dure de vie
Les objets par rapport auxquels on enregistre de l'information ont une dure de vie dtermine.
On a dfini plus haut le type CLIENT comme l'ensemble de "toutes les personnes physiques ou morales ayant
pass au moins un ordre de commande"; ne faudrait-il pas ajouter "depuis moins de deux ans" ?
b) Priode de validit
L'information relative un objet possde une priode de validit. (N.B. Une dure est une "longueur" de
temps; une priode est une dure "localise" dans le cours du temps.)
Une priode de validit est un intervalle compris entre deux dates de dbut (incluse) et de fin (exclue) : [d-
but, fin[.
1
(Selon la vitesse d'volution du systme dcrit, il peut tre ncessaire de mentionner l'heure.) Les
positions de cette priode par rapport la date du jour dfinissent diffrents tats de l'information :
aujourd'hui < date de dbut < date de fin : information dtenue mais non encore valide,
date de dbut aujourd'hui < date de fin : information actuellement active,
date de dbut < date de fin aujourd'hui : information passe (historique).
Dans les deux premires situations, la date de fin de validit est le plus souvent inconnue.
L'identification complte d'une occurrence d'information, par exemple telle quelle figure sur un formulaire ou
un document, comporte donc en principe :
le nom d'un type (ex.: "le SOLDE DU COMPTE"),
une valeur d'identifiant (ex.: "de numro 000-00000002-02"),
l'indication d'une priode de validit (ex.: "au 01/09/2000").
Cependant, la dernire de ces indications (la date) est souvent omise, ce qui est possible lorsque, dans la col-
lection vise, on ne distingue pas diffrentes priodes de validit (on tient pour actuelles toutes les informa-
tions dtenues).
c) Priode de mmorisation, Dure de rtention
Quelle que soit la priode de validit d'une information, celle-ci est connue et "enregistre" un certain mo-
ment, et conserve en mmoire un certain temps. On parle ce propos de priode de mmorisation et de
dure de rtention.
Une information peut tre enregistre avant de devenir valide; elle peut tre ignore, c'est--dire non enregis-
tre, aux premiers temps de sa priode de validit; dans de trs nombreux cas, elle est conserve en mmoire,
dans des fichiers historiques ou d'archives, bien au del de sa priode de validit ...
2.4. Contraintes d'intgrit
Les contraintes d'intgrit sont des prdicats ou assertions intgres au schma de la base de donnes, que
celle-ci doit vrifier pour tre considre valide on dit cohrente. Les contraintes d'intgrit sont formu-
les par rapport l'existence des (occurrences d') objets ou aux valeurs des donnes.
Exemples.
le nom de jeune fille n'existe que pour les femmes maries (existence)
mais on accepte qu'il soit inconnu (valeurs)
la date de mariage d'une personne est postrieure sa date de naissance (valeurs)

1
Dfinie de cette manire, la date de fin est en ralit la date de dbut de la priode suivante.
toute commande concerne au moins un produit (existence)
toute ligne de commande indique une quantit commande > 0 (valeurs)
le montant factur est gal au prix unitaire multipli par la quantit livre (valeurs)
un membre du personnel a soit le statut d'employ, soit le statut d'ouvrier; (existence)
aucun n'est de statut inconnu (existence)
(les sous-types OUVRIER et EMPLOYE sont disjoints
et forment une partition du type PERSONNEL)
Un SGBD vrifie lui-mme le respect des contraintes formules dans le schma de la base de donnes.
2.5. Aspects dynamiques des donnes
L'information possde un aspect dynamique : elle volue en passant par diffrents tats. Ainsi, une
FACTURE est successivement "mise", "rappele", "paye" ou "annule". La transition d'un tat un autre
rsulte d'une certaine action.
Ignorant tout des oprations et actions du systme de traitement de l'information, les modles de donnes tra-
ditionnels donnent de celles-ci une vue exclusivement statique. Pour obtenir une vision dynamique, il est n-
cessaire de passer du concept de donne celui d'objet, avec le sens qu'accordent ce terme les mthodolo-
gies "orientes objets" : un objet est caractris la fois par des attributs, donnes qui dcrivent son tat, et
par des oprations portant sur cet tat.
Exemple. Un objet solde est caractris par le nombre indiquant sa valeur actuelle et la date de sa
dernire mise jour, ainsi que par les oprations de mise jour et de consultation de cet tat. Trois
classes d'tats remarquables sont intressantes distinguer : solde positif, nul ou ngatif.
3. Panorama historique
3.1. Les SGBD oprationnels
Nous avons dfini un modle comme tant la thorie et le formalisme employs pour crer un schma de don-
nes. Les SGBD se diffrencient principalement par le modle thorique sur lequel ils s'appuient.
On le notera rien qu' leurs noms : tous les modles s'intressent principalement aux relations exis-
tant entre les donnes ... mais, comme diraient les musiciens, chacun joue sur ce thme sa propre va-
riation.
Les SGBD relationnels, mis au point dans les annes 80, sont les plus utiliss aujourd'hui. Ils s'appuient sur
le modle relationnel des donnes dfini par E. CODD chez IBM en 1970.
1
La gnration prcdente fut celle des bases de donnes en rseau, apparues la fin des annes 60. Le mo-
dle en rseau avait t cr par Ch. BACHMAN chez General Electric en 1963;
2
il a t standardis par
CODASYL partir de 1971.
3
Ces systmes sont encore utiliss sur certains gros ordinateurs, mais on les a
souvent recouverts d'une "couche" de fonctions d'accs relationnelles.
Cas particulier : le systme IMS (Information Management System) d'IBM, cr en 1968, repose
sur un modle hirarchique, moins puissant qu'un modle en rseau.
Depuis les annes 90, commencent apparatre des SGBD que l'on qualifie d'orients objets. Il n'est pas en-
core possible de savoir sous quelle forme ils s'imposeront.
3.2. Les mthodes d'analyse
a) Modles d'analyse des donnes
D'autres modles de donnes, qualifis de smantiques, sur lesquels ne s'appuie directement aucun SGBD,
sont couramment utiliss dans les dmarches pralables d'analyse d'une base de donnes.
Le modle entitassociation a t dfini aux alentours de 1975 par l'Amricain P. CHEN.
4
Une variante de
ce modle a t adopte en France par la mthode d'analyse MERISE.
5
Parce que le gouvernement franais
obligeait les informaticiens de ses administrations pratiquer la mthode MERISE, le modle entitassocia-
tion est le plus utilis dans les rgions francophones.
Les anglo-saxons utilisent plutt une variante du modle en rseau de BACHMAN, mise au point par
J. MARTIN dans sa mthode IEM (Information Engineering Methodology).
6

1
E. CODD : A Relational Model of Data for Large Shared Data Banks in Communications ACM, 1970.
2
Ch. BACHMAN : Data Structure Diagrams in Data Base, 1969.
3
CODASYL : Data Base Task Group Report, ACM 1971. CODASYL (COnference on DAta SYstems Lan-
guages) est l'organisme crateur du langage COBOL.
4
P. CHEN : The Entity-Relationship Model Toward a Unified View of Data in ACM TODS, 1976.
5
H. TARDIEU, A. ROCHFELD, R. COLLETTI : La mthode MERISE, d. d'Organisation, Paris 1983.
6
J. MARTIN : Diagramming Techniques for Analysts and Programmers, Prentice Hall.
Le modle des rseaux smantiques propos par SMITH et SMITH en 1977 constitue un des fondements
thoriques des modles orients objets.
1
Ses apports ont t intgrs une deuxime gnration du modle
relationnel et une deuxime gnration des modles entitassociation.
A la suite de la programmation, les mthodes d'analyse se veulent aujourd'hui "orientes objets". En 1997,
lObject Management Group (OMG) a adopt comme standard lUnified Modeling Language (UML).
2
Le
schma central produit par une analyse axe sur les objets est le diagramme des classes d'objets; il s'agit ni
plus ni moins que d'un schma de donnes, muni d'oprations. Le formalisme propos par UML est celui d'un
schma EntitAssociation.
3
b) Outils d'aide la conception
Depuis la fin des annes 80 se sont rpandus des outils logiciels d'aide la conception (CASE tools Com-
puter Aided Software Engineering).
Actuellement, l'efficacit de ces outils est beaucoup plus grande dans l'analyse des donnes que dans l'analyse
des oprations. S'appuyant sur l'un ou l'autre modles de donnes, ces outils grent la documentation crite et
graphique des schmas et effectuent des vrifications de compltude et de cohrence.
Ils oprent aussi des transformations de schmas aboutissant la dfinition "programme" d'une base de don-
nes. En effet, les schmas produits partir des modles d'analyse doivent subir des transformations pour tre
convertis dans le formalisme du modle adopt par le SGBD.
c) Plan du cours
Les trois chapitres suivants, en se servant des modles les plus couramment employs dans les rgions franco-
phones, prsentent les transformations successives d'un schma de base de donnes.
Le chapitre 3 traite de l'laboration du schma conceptuel, dans les formes du modle EntitAssociation
enrichi des apports du paradigme objet.
Le chapitre 4 dcrit la confection du schma logique de la base de donnes, transposition du prcdent dans
les formes du modle en Rseau.
Le chapitre 5 dcrit le schma physique de la base de donnes driv du schma logique. Deux standards y
sont prsents : le systme CODASYL et le systme SQL.

1
J. SMITH, D. SMITH : Data Base Abstractions : Aggregation and Generalization in ACM TODS, 1977.
2
UML a t mis au point par la socit amricaine Rational Software, fruit de la rencontre de trois pionniers
des mthodes danalyse et conception "orientes objets" : les Amricains G. BOOCH et J. RUMBAUGH et le
Sudois I. JACOBSON. Cf. OMG : Unified Modeling Language Specification, vers 1.3.; www.omg.org,
1999. Voir aussi P.A. MULLER : Modlisation objet avec UML; Eyrolles, 1997.
3
UML a repris ce formalisme la mthode OMT (Object Modeling Technique) de J. RUMBAUGH. Cf. J.
RUMBAUGH, al. : Modlisation et conception orientes objet, trad. franaise; Masson, 1995.
A. CLARINVAL Analyse Schma conceptuel 3-1
Chapitre 3. Le schma conceptuel des donnes
Le premier rsultat important produit par l'analyse prparatoire la ralisation d'une base de donnes est le
schma conceptuel de cette base de donnes. A cette tape, l'analyste ne s'intresse qu' la smantique des
donnes, c'est--dire leur contenu informationnel.
En laborant ce schma, l'analyste dcrit un domaine d'application.
1
La dmarche suppose la coopration des
utilisateurs commanditaires du projet d'informatisation. Ces utilisateurs apportent l'uvre commune leur
connaissance du domaine; l'informaticien, spcialiste de la modlisation, apporte la structure. Le rsultat,
c'est--dire le schma, doit entre autres choses dmontrer que les deux parties se sont comprises.
La dmarche prconise est la suivante :
1) laboration de sous-schmas bruts (sur la base d'interviews, d'examen de documents, etc.),
2) consolidation en un schma global brut,
3) validation du schma global,
4) correction des sous-schmas en fonction du schma global valid.
Nous commencerons par dcrire le contenu du schma conceptuel de la base de donnes. Ce contenu com-
porte deux volets : d'abord, une description structure de l'ensemble des donnes dtenues; ensuite, une liste
de contraintes de validit. Nous laborerons la description structure en utilisant un modle aujourd'hui clas-
sique, le modle EntitAssociation, enrichi des apports pertinents du paradigme Objet. Quant aux rgles de
validit, nous les noncerons au moyen d'un langage exprimental.
La fin du chapitre est consacre la validation des descriptions fournies.

1
"Dcrire le domaine (l'environnement) dans lequel l'application va exister et prciser quels sont les l-
ments pertinents dans ce domaine pour l'application. L'tude du domaine est le fruit d'une analyse, totale-
ment dconnecte de toute considration de ralisation. Le domaine est analys par un analyste et doit pou-
voir tre compris par un utilisateur." (P.A. MULLER : Modlisation objet avec UML; Eyrolles, 1997.)
1. Le modle EntitAssociation
Le modle EntitAssociation exprime la smantique des donnes l'aide des concepts d'entit, d'association
entre entits, d'attribut dcrivant les entits et les associations.
1
Dfini aux alentours de l'anne 1975 par les travaux de CHEN aux Etats-Unis, de l'quipe de TARDIEU ayant
cr en France la mthode MERISE, de l'quipe de BODART ayant cr aux Facults de Namur l'atelier logi-
ciel IDA, le modle EntitAssociation est aujourd'hui le plus communment utilis dans les rgions franco-
phones.
2
Avec plus ou moins de bonheur, ce modle a t adopt et adapt par certaines mthodes "orientes objets",
notamment UML ("Unified Modeling Language").
3
Au lieu de parler de types d'entits, ces mthodes parlent
de classes d'objets. Le concept d'objet complte celui d'entit : un objet est caractris, non seulement par
des attributs qui en dcrivent l'tat, mais galement par des oprations ou "mthodes" utilises principale-
ment pour modifier ou afficher la valeur de ses attributs.
1.1. Contenu du modle EntitAssociation
a) Entit
Une entit est une chose de la ralit perue par l'analyste, concrte ou abstraite, durable ou momentane,
laquelle on reconnat une existence autonome, indpendante de celle de tout autre objet dans son environne-
ment.
Exemples : le vendeur Luc, la cliente Annie, le type de produit en vente "jupe cossaise" Luc et
Annie sont des objets concrets, "jupe cossaise" est une entit abstraite qui dcrit les proprits
communes toutes les jupes cossaises. Un poste du plan comptable est aussi une entit ...
Les entits sont classes par types d'entits ou, selon la terminologie plus en vogue aujourd'hui, par classes
d'objets
On reprsente habituellement par un rectangle un type d'entits ou une classe d'objets.
Exemples.
VENDEUR CLIENT
PRODUIT
Les types d'entits ne forment pas ncessairement des classes disjointes; une mme personne pourrait tre
vendeuse et cliente de la mme firme.
Le modle EntitAssociation a t tendu de manire permettre la reprsentation de sous-types d'entits
ou sous-classes d'objets.

1
La mthode MERISE parle d'individu, de relation et de proprit.
2
Voir les rfrences bibliographiques au chapitre 2. Pour l'expos qui suit, nous nous baserons principale-
ment sur l'ouvrage de F. BODART, Y. PIGNEUR : Conception assiste des systmes d'information : m-
thode, modles, outils, Masson, 1989.
3
Voir les rfrences bibliographiques au chapitre 2.
Exemples. Une firme commerciale tablit une distinction entre ses clients privs et professionnels;
elle vend des produits qu'elle fabrique elle-mme et des produits d'un fournisseur dont elle est "dis-
tributrice".
VENDEUR
CLIENT PRODUIT
PRODUIT
FABRIQUE
PRODUIT
DISTRIBUE
CLIENT
PRIVE
CLIENT
PROFESS.
Il est possible deffectuer diffrentes rpartitions en sous-types lintrieur dun mme super-type, chaque
rpartition se fondant sur un critre particulier.
Exemple.
CLIENT
CLIENT
NATIONAL
CLIENT
ETRANGER
CLIENT
PRIVE
CLIENT
PROFESS.
Un mme sous-type peut faire partie de plusieurs super-types.
Exemple. Dans une librairie, la classe des outils didactiques comporte la fois notamment les ma-
nuels scolaires et les CD-ROM ducatifs.
MATERIEL
DIDACTIQUE
CD-ROM LIVRE
LIVRE
D'ART
MANUEL
SCOLAIRE
CD-ROM
EDUCATIF
JEU
VIDEO
..... .....
b) Association
Le concept d'Association
Une association ("relationship", en anglais) est une correspondance reconnue entre des entits, de types non
ncessairement distincts, o chacune assume un rle particulier. Son existence est contingente celle des
entits concernes; sa priode d'existence est incluse dans l'intersection des priodes d'existence des entits
participantes et sa dure de vie peut tre infrieure la dure de vie de ces entits.
Exemples : le lien conjugal unissant Monsieur X et Madame X,
dans lequel l'un joue le rle d'poux et l'autre, celui d'pouse
le lien parental ou de filiation existant entre deux personnes,
dans lequel l'une joue le rle de parent et l'autre, celui d'enfant
la fourniture
de tel produit
par tel fournisseur
le stockage
de tel produit
dans tel magasin
l'enseignement
de la matire "radiesthsie"
par le professeur Tournesol
la classe de Posie
Les associations sont classes par types d'associations, dfinis sur des types d'entits. D'un point de vue ma-
thmatique, un type d'association est une relation.
Exemples : ASSOCIATION (ENTITE rle, ...)
CONJOINT (HOMME mari, FEMME pouse)
FILIATION (PERSONNE enfant, PERSONNE parent)
FOURNITURE (PRODUIT-DISTRIBUE livr, FOURNISSEUR livrant)
STOCK (PRODUIT entrepos, MAGASIN contenant)
COMPOSITION (PRODUIT compos, PRODUIT composant)
ENSEIGNEMENT (MATIERE dispense, PROFESSEUR titulaire, CLASSE suivant)
A la suite de la mthode MERISE, nous reprsenterons un type d'association par un ovale. (D'autres repr-
sentations utilisent l'hexagone ou le losange.) Les rles sont reprsents par les arcs reliant le type d'associa-
tion aux types d'entits participantes.
PERSONNE
HOMME FEMME
CONJOINT
FILIATION
parent
enfant
mari
pouse
PRODUIT
MAGASIN
PRODUIT
FABRIQUE
PRODUIT
DISTRIBUE
FOURNISSEUR
FOURNITURE
STOCK
COMPOSITION compos
composant
livrant
livr
contenant
entrepos
MATIERE
PROFESSEUR CLASSE
ENSEIGNEMENT
dispense
titulaire suivant
Remarques
Le nom (d'un type) d'association doit tre un substantif qui peut tre "lu" dans tous les sens, comme ci-
dessus dans notre exemple des PRODUITs : [FOURNISSEUR] (FOURNITURE) [PRODUIT-
DISTRIBUE] ou [PRODUIT-DISTRIBUE] (FOURNITURE) [FOURNISSEUR], [PRODUIT]
(STOCK) [MAGASIN] ou [MAGASIN] (STOCK) [PRODUIT] ... Contrairement aux recomman-
dations de certains auteurs, on vitera de nommer un type d'association par un verbe, car un verbe se lit tou-
jours dans un seul sens : sujet verbe complment.
Dans le cas des associations cycliques, c'est--dire dfinies sur un seul type d'entit (l'association FILIATION
entre PERSONNEs, l'association de COMPOSITION entre PRODUITs), les noms de rles sont ncessaires
pour pouvoir distinguer les occurrences participantes : dans telle occurrence de l'association COMPOSITION
de PRODUITs, "vitrage" et "chssis" sont les composants du compos "fentre"; dans telle occurrence de
l'association FILIATION, Jsus est l'enfant et Marie est le parent.
Dans les autres cas, les noms de rles apparatront souvent redondants. Cependant, nous verrons plus loin
l'intrt qu'ils offrent pour l'expression des rgles de validit. De plus, afin d'augmenter la lisibilit des ex-
pressions de la forme ENTITErle qui y font rfrence, on choisira en guise de noms de rles, si c'est possi-
ble, des participes prsents (rles actifs) ou passs (rles passifs).
On appelle degr d'une association le nombre d'entits participantes. Les associations sont pour la plupart
binaires (c'est--dire de degr 2), moins souvent ternaires (de degr 3), exceptionnellement de degr plus
lev. (N.B. Une association cyclique, unissant des entits d'un mme type, est de degr au moins gal 2.)
Plusieurs types d'associations peuvent tre dfinis sur les mmes types d'entits.
Exemples : COMPOSITION (EQUIPE comprenant, PERSONNE membre)
DIRECTION (EQUIPE dirige, PERSONNE dirigeant)
PROPRIETE (PERSONNE possdant, VOITURE possde)
PILOTAGE (PERSONNE conduisant, VOITURE conduite)
Le modle n'autorise pas la reprsentation de sous-types d'associations.
Notation UML
Dans les diagrammes de classes d'UML, les associations sont simplement figures par les traits qui relient les
symboles des classes d'objets participants; dans le cas d'une association de degr suprieur 2, un petit lo-
sange est utilis pour connecter les traits.
PERSONNE
HOMME FEMME
parent
enfant
mari pouse
FILIATION
CONJOINT
PRODUIT
MAGASIN
PRODUIT
FABRIQUE
PRODUIT
DISTRIBUE
FOURNISSEUR
compos
composant
livrant
livr
contenant
entrepos
FOURNITURE
STOCK
COMPOSITION
MATIERE
PROFESSEUR
CLASSE
dispense
titulaire
suivant
ENSEIGNEMENT
Connectivit des associations
Soit un type d'association A (E
i
r
i
, ...).
A chaque association du type A participe sous chacun des rles r
i
une entit exactement.
A chacun des rles r
i
mis en jeu est attach un couple d'entiers (min
i
, max
i
), qui en dfinissent la
connectivit (on dit aussi : la cardinalit) et qui, dans les mthodes de tradition franaise, signi-
fient :
min
i
le nombre minimum d'occurrences de A auxquelles,
tout moment, participe toute occurrence de E
i
;
max
i
le nombre maximum d'occurrences de A auxquelles,
tout moment, participe toute occurrence de E
i
.
Les valeurs habituelles sont :
min
i
= 0 ou 1 signifiant une participation facultative ou obligatoire,
max
i
= 1 ou N ou * signifiant une participation unique ou multiple
(N ou * reprsente l'infini).
Exemples : CONJOINT (HOMME mari-de 0:1, FEMME pouse-de 0:1)
il existe des clibataires !
FILIATION (PERSONNE enfant-de 0:2, PERSONNE parent-de 0:N)
le nombre d'enfants d'une personne est quelconque (de 0 N)
chaque personne est enfant de deux parents mais certains parents sont inconnus
PERSONNE
HOMME FEMME
CONJOINT
FILIATION
parent
enfant
0,N
0,2
mari pouse
0,1 0,1
FACTURATION (COMMANDE facture-en 0:1, FACTURE mise-pour 1:1)
une commande existe un certain temps sans tre lie une facture
COMMANDE
FACTURE FACTURATION
facture mise
0,1 1,1
FOURNITURE (PRODUIT-DISTRIBUE livr-par 1:1, FOURNISSEUR livrant 1:N)
tout fournisseur d'un type de produit est un fournisseur exclusif
STOCK (PRODUIT entrepos-dans 0:1, MAGASIN contenant 0:N)
certains produits ne sont pas stocks
aucun produit n'est stock dans plusieurs magasins
COMPOSITION (PRODUIT compos-de 0:N, PRODUIT composant 0:N)
il existe ncessairement des produits non composites
certains produits n'entrent dans aucune composition
PRODUIT
MAGASIN
PRODUIT
FABRIQUE
PRODUIT
DISTRIBUE
FOURNISSEUR
FOURNITURE
STOCK
COMPOSITION compos
composant
livrant
livr contenant
entrepos
0,N
0,N
1,N
1,1
0,1
0,N
ENSEIGNEMENT (MATIERE dispense-dans 1:1, PROFESSEUR titulaire-de 1:N,
CLASSE suivant 1:N)
une matire fait l'objet d'un seul enseignement
un professeur peut tre titulaire de plusieurs enseignements
une classe suit au moins un enseignement
MATIERE
PROFESSEUR CLASSE
ENSEIGNEMENT
dispense
titulaire suivant
1,1
1,N 1,N
Les connectivits dans la notation UML
Dans la reprsentation UML d'un type d'association, seuls les types des entits participantes sont montrs. La
connectivit (ou "multiplicit") mentionne chaque extrmit de l'arc reprsentant une association binaire
indique combien d'entits de cette extrmit est associe chaque entit du type situ l'autre extrmit, ce
qui revient dire : combien d'associations participe chaque entit du type situ l'extrmit oppose.
1
Voici l'quivalent UML des exemples donns au paragraphe prcdent. Comparez attentivement les deux
versions.
PERSONNE
HOMME FEMME
parent
enfant
mari pouse
FILIATION
CONJOINT
0..2
0..*
0..1 0..1
COMMANDE FACTURE
facture mise
0..1 1..1 FACTURATION
PRODUIT
MAGASIN
PRODUIT
FABRIQUE
PRODUIT
DISTRIBUE
FOURNISSEUR
compos
composant
livrant
livr
contenant
entrepos
FOURNITURE
STOCK
COMPOSITION
1..1
1..*
0..*
0..1
0..*
0..*

1
Cette disposition, typique des mthodes amricaines, provient du modle en rseau, que nous dcrirons au
chapitre suivant.
Le procd n'est pas transposable aux types d'associations d'un degr suprieur 2 ( moins que les connecti-
vits soient les mmes sur tous les rles). Les auteurs d'UML prconisent dans ce cas de reprsenter le type
d'association sous les traits d'un type d'entit !
1
MATIERE
PROFESSEUR CLASSE
dispense
titulaire suivant
1..1
1..* 1..*
<<association>>
ENSEIGNEMENT
Ce mode de reprsentation est galement applicable aux associations binaires.
Remarquer que les connectivits se placent ici de la mme manire
que dans la reprsentation franaise.
La mention association signale une variante standardise du concept danalyse employ,
ce que, en UML, on appelle un strotype.
NOTE. En UML, la connectivit 1..1 peut tre laisse implicite; elle peut aussi s'crire 1.
c) Attribut
Attribut et Domaine
Un attribut est une caractristique descriptive d'une entit ou d'une association, qui prend une valeur dans un
domaine, c'est--dire un ensemble de valeurs admises. L'analyste, comme toujours, gnralise et dfinit des
types d'attributs.
Exemples : type d'entit/association attribut domaine exemples de valeurs
EMPLOYE nom-employ NOM Fantasio, Lagaffe
adresse-employ ADRESSE chteau-de-Champignac
photo-employ image N&B
CLIENT nom-client NOM Dupont, Dupond
adresse-client ADRESSE chteau de et Moulinsart
PRODUIT nom-produit LIBELLE chaussettes, jupe, draps
prix-de-vente PRIX 89, 879, 2299
quantit-en-stock QUANTITE 433 lots,2500 pices,1000 paires
COMMANDE qt-commande QUANTITE 1 lot, 1 pice, 3 paires
date-d'mission DATE 20 avril 1995
date-de-livraison DATE 30 avril 1995
CONJOINT date-de-mariage DATE 04/10/40, 03/05/57, 19/03/62

1
Il existe encore en UML d'autres lments, par exemple le langage OCL ("Object Constraint Language"),
qui ne sadaptent pas aux associations de degr suprieur 2. Cest sans doute pour ces raisons que les outils
d'aide la conception qui se fondent sur la notation UML n'acceptent, en pratique, que les associations binai-
res.
Sur les diagrammes, le nom des attributs peut tre inscrit l'intrieur du symbole reprsentant le type d'entit
ou d'association. La documentation doit en outre indiquer quel est le domaine de chaque type dattribut.
Ent/Ass
PERSONNE
nom
dat e naissance
HOMME
FEMME
nom de jeune fille
CONJOINT
dat e mariage
mari
pouse
0,1 0,1
UML
PERSONNE
nom
dat e naissance
HOMME
FEMME
nom de jeune fille
mari pouse
0..1 0..1
CONJOINT
dat e mariage
REMARQUE. Dans le cas d'une entit participant une association avec une connectivit 1:1, on peut hsiter
attacher certains attributs soit au type d'entit, soit au type d'association.
Exemple : PASSATION (CLIENT passant 0:N, COMMANDE passe-par 1:1)
la date-de-commande peut tre attribut de COMMANDE ou de PASSATION
Ent/Ass

COMMANDE
n commande
CLIENT
nom client
adresse client
PASSATION
dat e commande
passant
passe
0,N
1,1
UML

COMMANDE
n commande
CLIENT
nom client
adresse client
passant passe
0,N
1,1
PASSATION
dat e commande
En mathmatique, une relation est une partie du produit cartsien de plusieurs domaines. Exemple :
domaine 1 domaine 2 produit cartsien relation
"masculin" "male" ("masculin", "male") ("masculin", "male")
"fminin" "female" ("masculin", "female") ("fminin", "female")
("fminin", "male")
("fminin", "female")
Un type d'attribut est une relation faisant correspondre chaque lment d'un ensemble d'entits ou d'associa-
tions un lment d'un domaine de valeurs

(de la mme manire quun type dassociation est une relation fai-
sant correspondre chaque occurrence dun ensemble dassociations une occurrence du domaine que constitue
un type dentits), ce que suggre bien la reprsentation graphique prconise par CHEN.
Entit
Assoc.
PERSONNE
FEMME HOMME
CONJOINT
Domaine
nom
date
naissance
mariage
de jeune fille
mari
pouse
patronyme
entier
jour
mois
anne
prnom
Date (Entier jour, Entier mois, Entier anne)
PERSONNE [Nom patronyme, Nom prnom, Date naissance]
HOMME [PERSONNE] -- le sous-type "hrite" de la dfinition de PERSONNE
FEMME [PERSONNE, Nom jeune-fille]
CONJOINT <Date mariage, HOMME mari, FEMME pouse>
Noms d'attributs
Ce point de vue suggre une mthode pour nommer les attributs. Le nom d'un attribut sera form par la
concatnation :
soit du nom de domaine et du nom du type d'objet dcrit, entit ou association (ex.: nom-client, nom-
produit, numro-de-commande); le nom de domaine peut souvent tre abrg (ex.: "no" pour "numro", "lib"
pour "libell", "qt" pour "quantit", etc);
soit du nom de domaine et d'un qualificatif de rle (ex.: prix-de-vente, quantit-en-stock, date-de-mariage);
la prsence d'un qualificatif de rle est indispensable dans le cas o plusieurs attributs d'un mme type d'objet
partagent un domaine commun (ex.: les attributs date-d'mission et date-de-livraison-souhaite du type d'ob-
jet COMMANDE);
soit du nom de domaine, d'un qualificatif de rle et du nom du type d'objet dcrit (ex.: date-d'mission-de-
la-commande).
Proprits des attributs
Un attribut peut tre lmentaire (ex.: nom-client, nom-produit) ou structur (ex.: date-de-commande, d-
composable en jour + mois + anne).
Un attribut peut tre simple (ex.: EMPLOYE : nom) ou rptitif (ex.: EMPLOYE : prnoms) certains
auteurs emploient les qualificatifs mono-valu et multi-valu.
Lorsque la valeur d'un attribut est une grandeur mesure (QUANTITE, PRIX), l'unit de mesure doit tho-
riquement tre indique (ex.: lot, pice, paire, FB, $); cette mention ne peut tre omise que si l'unit de me-
sure est constante. Il convient d'tre prudent face de telles omissions (par exemple, celle de la devise mo-
ntaire dans laquelle s'effectuent les paiements) et d'tre attentif, par exemple, au fait que le march purement
national d'une entreprise pourrait demain s'largir une dimension internationale ...
En thorie, tout attribut est obligatoire; en effet, par dfinition, toutes les occurrences d'un type partagent
toutes les proprits de celui-ci. Par gnralisation, on pourra cependant inclure une valeur "inexistant" dans
le domaine d'un attribut que l'on dsire rendre facultatif; grce cet artifice, il est possible d'attacher la notion
de nom-de-jeune-fille toute personne plutt que de distinguer le sous-type des FEMMES-MARIEES. Dans
le mme ordre d'ides, on peut inclure dans tout domaine de valeurs, la valeur "inconnu".
Dfinition des domaines de valeurs
Dans un systme crit, la valeur d'un attribut est reprsente par une suite de caractres.
1
A ce niveau, un do-
maine lmentaire est redfini comme faisant lui-mme partie d'un type de valeur, du genre de ceux que
proposent les langages de programmation.
2
(Si le domaine contient les valeurs spciales "inexistant" ou "in-
connu", on n'oubliera pas de prvoir la mthode de codification de ces valeurs.)
Exemples : domaine type de valeur
QUANTITE nombre entier
PRIX nombre dcimal en COBOL : PICTURE 9(4)V99
NOM CHAR(20) en COBOL : PICTURE X(20)
Un domaine structur (ex.: DATE) est redfini comme une relation entre sous-domaines (JOUR, MOIS,
ANNEE).
d) Identifiants
Le concept gnral d'identifiant a t introduit au chapitre 2, en mme temps que celui de dpendance fonc-
tionnelle. Quelle forme prend un identifiant dans le modle EntitAssociation ?
Identifiant d'un type d'entit
L'identifiant d'une entit est le plus souvent form d'attributs propres cette entit. Dans les exemples ci-
dessous, le nom des attributs identifiants est soulign.
Exemples : EMPLOYE [n matricule, nom, adresse]
PRODUIT [n code, nom produit, prix de vente]
CLASSE [section, anne, nombre d'tudiants]

1
On parle de plus en plus aujourd'hui de bases de donnes gnralises, o les attributs peuvent prendre la
forme d'images, de textes quelconques, de squences sonores ...
2
La locution "type d'un attribut" est habituellement comprise dans ce sens de type de la valeur de lattribut.
Si un type d'entit E participe ncessairement une association, c'est--dire avec une connectivit minimale de
1 (connectivit 1:1 ou 1:N), l'identifiant du type E peut tre entirement ou partiellement form de l'identi-
fiant des entits auxquelles il est ncessairement associ. On appelle identifiant tranger l'identifiant ainsi
"import" d'une entit associe. Nous reprsenterons la chose en soulignant la connectivit 1:? du rle de E
dans l'association par laquelle il reoit cet identifiant tranger.
1
Dans l'exemple suivant, l'identifiant de COMMANDE, quel qu'il soit, peut identifier l'unique
FACTURE et faire partie de l'identifiant des BORDEREAUx d'expdition dcoulant de cette com-
mande.
FACTURE
dat e de fact ure
COMMANDE
n commande
dat e de commande BORDEREAU
n de livraison
dat e d'expdit ion
FACTURATION
LIVRAISON
0,1
0,N
1,1
1,1
C'est toujours le cas des immatriculations hirarchiques.
Exemple. Le numro d'affiliation d'un employeur une Caisse d'Allocations Familiales dpend du
bureau rgional de cette caisse qui gre le dossier; le numro d'affiliation est form par la concat-
nation du numro de bureau et d'un numro d'inscription ce bureau.
BUREAU
REGIONAL
n bureau
localit
........
EMPLOYEUR
n inscript ion
........
AFFILIATION
dat e d'enregist r.
0,N
1,1
Toute entit occurrence d'un sous-type (ex.: HOMME ou FEMME) appartient galement au sur-type (ex.:
PERSONNE); elle hrite donc de l'identifiant dfini pour le sur-type (ex.: numro au Registre National).
Identifiant d'un type d'association
L'identifiant d'une association est en principe form d'identifiants trangers. Nous reprsenterons la chose en
soulignant le nom des rles des types d'entits associs dont l'identifiant est utilis.
PRODUIT
id produit
prix unit aire
COMPOSITION
quant it
compos
composant 0,N
0,N

1
L'expression identifiant tranger provient de la thorie du modle relationnel. Dans le cas du modle Enti-
tAssociation, certains parlent d'identification par les rles.
MATIERE
PROFESSEUR CLASSE
ENSEIGNEMENT
dispense
titulaire suivant
1,N
1,N 1,N
en supposant que toute matire est enseigne par un seul professeur
Quelquefois, les identifiants des entits associes ne suffisent pas identifier l'association. On supplera en
crant pour l'association un attribut identifiant.
Exemple. Un mme CLIENT assur peut, par le truchement du mme COURTIER, obtenir plusieurs
contrats dans une mme branche d'ASSURANCE (notamment, une assurance incendie pour chacun
de ses immeubles btis); un "numro de police" est ncessaire l'identification complte du CON-
TRAT.
CLIENT
COURTIER
ASSURANCE
CONTRAT
n police
assur
branche
intermdiaire
1,N
0,N
0,N
Identifiants multiples
Plusieurs identifiants peuvent exister pour le mme type d'objet. Exemples : le travailleur EMPLOYE par une
entreprise peut tre identifi par son numro au Registre National et par un numro de matricule interne; si
une FACTURE est toujours relative une et une seule COMMANDE, le numro de commande est un identi-
fiant de FACTURE, aussi bien que le numro de facture. On choisit habituellement un identifiant primaire,
privilgi; les autres sont qualifis de candidats ( devenir primaires).
1
REMARQUE. Un sous-type d'entit hrite des identifiants de son sur-type. Mais ceux-ci n'ont pas ncessai-
rement le mme statut dans le sur-type et le sous-type. Exemple : l'identifiant unique et donc primaire du type
d'entit PERSONNE est le numro du Registre National; pour le sous-type EMPLOYE, dont l'identifiant pri-
maire est un numro de matricule propre l'entreprise, l'identifiant hrit n'est que candidat.
Dans les reprsentations graphiques d'un type d'entit, les composants de l'identifiant primaire peuvent tre
souligns et les composants d'un mme identifiant candidat, prfixs par un numro distinctif commun.

1
La ncessit de choisir un identifiant primaire sera surtout le fait des techniques informatiques de stockage
des donnes, qui se donneront pour objectif d'acclrer l'accs slectif par le biais de cet identifiant privilgi.
EMPLOYE
n mat ricule
nom
prnom
(1) n nat ional
Les reprsentations graphiques habituelles d'un type d'association ne permettent malheureusement pas de si-
gnaler les composants de ses identifiants (ce qu'on devra faire par le dtour d'un commentaire); on pourra
cependant, comme nous l'avons fait jusqu'ici, reprsenter l'identifiant primaire en soulignant le nom des rles
fournissant l'identifiant ou en le prfixant par un astrisque.
Proprits des identifiants
Un identifiant doit tre minimal, c'est--dire qu'il ne doit pas exister de sous-groupe de composants de cet
identifiant qui soit lui-mme identifiant; en d'autres termes, aucun des composants d'un identifiant ne doit
dpendre fonctionnellement des autres.
Supposons que l'identifiant d'un EMPLOYE soit compos de son numro de matricule (unique dans
l'ensemble de l'entreprise) et du numro du dpartement qui l'occupe; cet identifiant n'est pas mini-
mal, car le numro de matricule est lui seul identifiant et le numro de dpartement dpend fonc-
tionnellement de ce numro : n matricule n dpartement.
Dans les exemples suivants d'associations, seuls les rles souligns composent l'identifiant; on re-
marquera que, dans le cas o la connectivit maximale d'un rle est 1, ce rle lui seul est auto-
matiquement identifiant du type d'association.
PUBLICATION (LIVRE publi-par 1:1, EDITEUR publiant 0:N)
STOCK (PRODUIT entrepos-dans 0:1, MAGASIN contenant 1:N)
Soit l'association ENSEIGNEMENT (MATIERE dispense-dans 1:N, classe suivant 1:N,
PROFESSEUR titulaire-de 1:N);
elle peut tre identifie de diffrentes manires et le choix de l'identifiant complte et prcise la d-
finition smantique de ce type d'association :
ENSEIGNEMENT (MATIERE dispense-dans 1:N, CLASSE suivant 1:N,
PROFESSEUR titulaire-de 1:N)
toute matire est enseigne par un seul professeur, ventuellement plusieurs classes :
(matire, classe) professeur
ENSEIGNEMENT (MATIERE dispense-dans 1:N, CLASSE suivant 1:N,
plusieurs professeurs enseignent la mme matire, mais pas dans la mme classe :
(matire, professeur) classe
Les attributs entrant dans la composition de l'identifiant primaire ne peuvent prendre les valeurs "inconnu" ou
"inexistant" (le numro de carte d'identit serait un mauvais identifiant pour les HABITANTs d'une com-
mune, car certains habitants les enfants ne possdent pas de carte d'identit). De plus, la valeur de
l'identifiant primaire doit tre stable, c'est--dire non sujette modification; cette dernire condition est n-
cessaire la continuit de l'identification de chaque occurrence d'objet, en dpit des modifications qu'elle peut
subir pendant sa dure de vie.
C'est en particulier pour rpondre des situations o un identifiant "naturel" n'apparat pas stable, notamment
lorsque la valeur peut en tre inconnue, qu'on utilise parfois des identifiants internes de substitution, attribus
par le systme (automatique ou manuel) de mmorisation de l'information; il s'agira par exemple d'un com-
postage, attribution d'un simple numro de suite.
e) Dimension historique
L'insertion de la dimension historique dans le modle EntitAssociation s'opre en incluant l'indication des
priodes de validit dans l'identifiant des entits ou associations.
1
TARIF
priode
n produit
prix de vent e
Soit le type d'association OCCUPATION (OUVRIER travaillant- 0:1, CHANTIER ralis-par 0:N). Si l'en-
trepreneur veut garder trace de l'occupation successive de ses ouvriers diffrents chantiers, le type d'associa-
tion devient :
CHANTIER
OUVRIER
ralis
travaillant
0,N
0,N
CHANTIER
OUVRIER
OCCUPATION
ralis
travaillant
0,N
0,1
OCCUPATION
priode
REMARQUES. L'identifiant minimal d'un lment (entit ou association) historique est le mme que celui
de cet lment s'il ne possdait pas la dimension historique, augment de l'indication de priode. L'insertion
de la dimension historique au sein d'un type d'association transforme les ventuelles connectivits ?:1 en
connectivits ?:N.
Si la priode de validit, au lieu d'tre rduite un point dans le temps (comme la "date d'envoi" d'une
FACTURE), forme un intervalle continu, la reprsentation et la manipulation de cette indication posent quel-
ques problmes spcifiques.
1) Pour fournir une identification certaine des occurrences successives, les priodes dfinies pour un
mme type d'lment doivent tre disjointes.
2) La mention d'une priode se fait thoriquement par la double indication d'une date ou heure de
dbut et d'une date ou heure de fin. La fin d'une priode de validit est le plus souvent inconnue tant
que la priode n'est pas rvolue; pour cette raison, la date (ou heure) de fin se prte mal faire par-
tie d'un identifiant.
3) Si l'on conserve toutes les versions successives de chaque entit ou association, la date de fin des
diffrentes priodes de validit est une mention redondante, dont on pourra faire l'conomie pourvu
que l'ensemble des occurrences successives soit ordonn selon les dates.

1
A dire vrai, la mention d'une priode de validit pourrait galement tre attache la valeur d'un attribut.
Mais, ds que l'on veut garder trace de l'histoire de cet attribut, il devient ncessaire de mmoriser les versions
(occurrences) successives du type d'objet qui possde cet attribut. De ce fait, l'indication de priode devient
identifiante de l'entit ou de l'association mmorise.
4) La recherche d'une occurrence mmorise portera d'ordinaire sur l'occurrence "valide telle
date", la date indique n'tant pas ncessairement la date de dbut (ni l'ventuelle date de fin) ins-
crite dans l'identifiant de l'occurrence cherche; on devra donc parcourir l'ensemble ordonn de tou-
tes les occurrences mmorises, les comparant deux deux, pour savoir sur quelle occurrence "s'ar-
rter" (comme les accs les plus frquents visent les occurrences les plus rcentes, on aura avantage
classer la collection historique par ordre de dates dcroissantes) : "lire-suivant jusqu' ce que date-
de-dbut-de-validit date-cherche".
Exemple : dbut de validit date cherche
04/02/2002
28/11/2001
17/03/2001 20/09/2001
03/06/2000
NOTE. En ralit, toute information possde une dimension historique, et l'analyste devrait systmatique-
ment chercher quelles consquences exactes entrane le fait de la masquer.
f) Discussion
Revenons la reprsentation originale de CHEN.
Entit
Assoc.
PERSONNE
FEMME HOMME
CONJOINT
Domaine
nom
date
naissance
mariage
de jeune fille
mari pouse
patronyme
entier
jour
mois
anne
prnom
compositon
relations
identifiants
On voit que, au total, le procd est uniforme : la modlisation des donnes se rduit la composition de
relations. Les niveaux de composition se distinguent de la faon suivante :
une entit (ex.: PERSONNE) se diffrencie dune valeur structure (ex.: DATE) par le fait qu'elle pos-
sde un identifiant qui permet de la dsigner, tandis qu'une valeur se "dsigne" elle-mme;
une association (ex.: CONJOINT) se diffrencie dune entit (ex.: PERSONNE) en ce qu'elle relie des
entits; de ce fait, comme l'association FACTURATION ci-dessous, elle peut ne pas avoir dattributs.
COMMANDE
n commande
CLIENT
nom client
adresse client
FACTURE
n fact ure
dat e fact ure
FACTURATION
PASSATION
dat e commande
passant
passe
facture
mise
0,N 1,1
0,1
1,1
Plus significativement, l'analyste considre que les entits constituent la matire spcifique et "vivante"
de l'application qu'il dcrit, tandis qu'il tient pour prexistants, "donns tels quels" ou "inertes" les
domaines de valeurs. Les frontires entre les concepts d'entit associe et valeur caractristique ne sont
donc pas fixes; elles dpendent de la perception de l'analyste.
Exemple. Pour toute firme effectuant une gestion de clients, le client est, entre autres choses, une en-
tit associe des commandes; pour le commerant dtaillant qui "ne fait pas crdit" mais qui ac-
cepte de "prendre des commandes", l'identit du client est un attribut de la commande.
1.2. Structures particulires
a) Compositions smantiquement quivalentes
Si tous les rles assums par un type d'entit ont la connectivit 1:1, la composition de ce type d'entit et de
tous les types d'associations auxquels il participe est quivalente un type d'association. Si tous les rles
jous dans un type d'association ont la connectivit 1:1, la composition de ce type d'association avec tous les
types d'entits participants est quivalente un type d'entit.
1,1 1,1
1,1 1,1
Cette proprit d'quivalence smantique sera exploite par certaines transformations de schmas.
b) Associations non reprsentables
Un contrat est typiquement une association; un avenant fait rfrence un contrat.
CONTRAT-BAIL (LOCATAIRE preneur-de 0:N, PROPRIETAIRE bailleur-de 0:N)
AVENANT (CONTRAT-BAIL modifi-par 0:N)
Les conventions graphiques du modle EntitAssociation ne permettent pas de reprsenter sous ces termes le
concept d'avenant un contrat. D'une part, cet avenant est prsent comme une association de degr 1, pour
laquelle existe un seul rle (CONTRAT modifi); or toute association est de degr au moins gal 2. D'au-
tre part, il est prsent comme une association d'associations; or une association (CONTRAT) ne peut pas
assumer un rle au sein d'une autre association.
1

1
Pour passer outre cette limitation, il suffirait que tout arc symbolisant un rle soit orient par une flche
partant de l'association vers le membre.
Solution : toute association non reprsentable, association rfrence (ex.: CONTRAT) ou association
incomplte (ex.: AVENANT), peut tre transforme en pseudo-entit et chacun de ses rles en pseudo-
association sans attributs, laquelle la pseudo-entit participe avec une connectivit 1:1. Cette transforma-
tion exploite la proprit d'quivalence smantique dfinie au paragraphe prcdent.
AVENANT
MODIFICATION
LOCATAIRE
PROPRIETAIRE
CONTRAT
1,1
1,1 1,1
0,N
0,N
0,N
Critique du modle EntitAssociation
Cette limitation du modle, qui conduit reprsenter une association sous les traits d'une entit, vhicule donc
une contradiction smantique : le formalisme nie sa propre dfinition !
A cause de cette mme limitation, un schma EntitAssociation est instable, en ce sens que certains enrichis-
sements d'information (par exemple, la prise en compte des avenants) induisent une modification de nature
des composants sur lesquels porte l'accroissement d'information (les contrats passent du statut d'associations
celui d'entits).
Un schma EntitAssociation n'est pas exempt de constructions parasites. Telles sont, comme dans les
transformations voques ici, les pseudo-associations sans attributs ayant une connectivit 1:1.
2. Apports du paradigme Objet
2.1. Classes d'objets
a) Les concepts
Au lieu de parler de types d'entits, les adeptes de l'orientation objet parlent de classes d'objets.
Comme la dfinition d'une entit, la dfinition d'un objet mentionne les attributs qui dcrivent son tat et les
associations auxquelles il participe; elle ajoute les oprations que cet objet peut effectuer, essentiellement
pour modifier ou faire connatre son propre tat. Tout objet est en effet responsable de son propre tat.
Exemple. Un COMPTE CLIENT est un objet. Il est caractris par des attributs et des associations :
identit du client, tat dbiteur ou crditeur, montant du solde, date du dernier mouvement ... Les
oprations possibles sont : ouvrir le compte, le dbiter du montant d'une facture, le crditer du mon-
tant d'un paiement ou d'une note de crdit, consulter l'tat du compte, clturer le compte ...
COMPTE
tat
solde
date dernier mouvt
ouvrir( )
dbiter( )
crditer( )
consulter( )
clturer( )
CLIENT
nom
adresse
1 1..* 1 1..*
titulaire
POSSESSION
UML : diagramme de classes
Des objets et classes dobjets peuvent tre dcouverts diffrents stades de lanalyse. Les plus "es-
sentiels" dentre eux, la fois les plus significatifs et les moins contingents, le sont lors de ltude
dun domaine dapplication, lors de llaboration du schma conceptuel de ce domaine. Les opra-
tions en font-elles partie ? Assurment. En effet, autant que les attributs, les oprations possibles
telles celles que nous avons identifies pour un compte client manifestent la nature intime des ob-
jets du domaine. (Ce qui sera le propre des applications futures, ce sera la rpartition, la mise en u-
vre de ces oprations dans diffrents scnarios dactivation.
1
)
Particularit remarquable : en principe, les utilisateurs d'un objet ne connaissent que les oprations qu'ils peu-
vent demander cet objet et, proprement parler, en ignorent les attributs et associations. Les donnes d'un
objet sont prives ou caches (elles ne sont accessibles qu'aux oprations de l'objet), tandis que les oprations
sont publiques, c'est--dire utilisables par n'importe quel objet ou programme. On donne ce procd le nom
de masquage (en anglais : "encapsulation"); ce principe a t formalis dans la thorie des types de don-
nes abstraites.
2

1
Cest parce quelles ne faisaient pas la distinction entre les oprations proprement dites et leur mise en uvre
que les mthodes danalyse anciennes, MERISE par exemple, dcrtaient que les oprations ne possdent pas
le caractre quasi immuable des choses "conceptuelles", mais sont "contingentes" et sujettes dassez fr-
quentes rvisions.
2
B. LISKOV, J. GUTTAG : Abstraction and Specification in Program Development; M.I.T. Press, 1988.
Exemple. Les utilisateurs d'un objet COMPTE CLIENT ignorent si l'identit du client est enregistre
sous la forme d'un attribut ou d'une association, si le montant du solde est effectivement enregistr
dans la base de donnes ou s'il est recalcul chaque fois que cest ncessaire ...
Dans un type de donnes abstraites, le concept dattribut est redfini de la faon suivante : un couple
doprations set et get transmettant une valeur. Lutilisateur ignore si lattribut est enregistr tel quel ou
virtuel, cest--dire calcul chaque accs.
Les oprations mentionnes dans la dfinition dun type abstrait se rpartissent en trois catgories :
crateurs ou constructeurs doccurrences,
modificateurs de ltat dune occurrence,
observateurs ou rapporteurs renseignant sur ltat des occurrences.
Les oprations set et get de mise jour et consultation dun attribut constituent un cas particulier
des deux dernires catgories.
Donnes prives, oprations publiques ... A dire vrai, seule est publique la signature des oprations, c'est--
dire la forme du message qui les invoque (nom de lopration, description des paramtres et du rsultat). La
ralisation interne des oprations (en anglais : "implementation"), c'est--dire la mthode utilise, demeure
cache, tout comme les donnes.
1
L'ensemble des signatures publiques d'un objet compose ce qu'on appelle
son interface.
b) Spcification des oprations
Au mme titre quun attribut, une opration caractristique dun type dobjet doit tre dfinie.
Spcification externe
La spcification externe dune opration nest rien dautre que ce quon appelle dans les langages de pro-
grammation la signature du sous-programme qui la mettra en uvre.
Cette signature comporte les lments suivants :
le mode opratoire du sous-programme : fonction ou procdure
. une fonction rend en rsultat un objet ou une valeur, elle ne modifie pas ses paramtres
. une procdure peut modifier les paramtres quelle reoit, elle ne rend pas de rsultat
dans les langages de la famille C,
la signature dune procdure est celle dune fonction rendant un rsultat de type "void"
un nom vocateur, identifiant lopration
Idalement, le nom attribu une fonction est un substantif ou un qualificatif exprimant la relation
smantique qui permet de dfinir le rsultat au moyen des paramtres et de ltat de lobjet.
Exemples : compte. crditeur () => vrai / faux

1
Par un abus de langage, on emploie souvent le mot mthode pour dsigner lopration qui utilise la mthode.
Idalement, le nom d'une procdure est form du verbe qui en exprime l'opration principale, ven-
tuellement suivi d'un complment qui identifie le rsultat principal.
Exemples : compte. dbiter (montant)
clturer ()
client. modifier_adresse (adresse)
une liste de paramtres, qui peut tre vide
pour chaque paramtre :
. un nom, qui permet dy faire rfrence;
. son type ou sa classe;
. le mode dutilisation de ce paramtre par le sous-programme :
in le sous-programme utilise les valeurs reues mais ne les modifie pas
out le sous-programme range des valeurs dans le paramtre
inout le sous-programme utilise les valeurs reues et les modifie
si le sous-programme est une fonction ou un oprateur : le type ou la classe de son rsultat
la liste des signaux dexception mis par lopration en cas dchec
pour chaque exception :
. son type
. les ventuelles donnes dinformation contenues dans le signal
. en commentaire : les valeurs significatives
Dfinition smantique
La spcification externe dune opration devra tre complte par la liste des pr-conditions et post-
conditions, plus ventuellement la mthode (cest--dire lalgorithme), qui dfinissent la smantique de
cette opration.
1
c) Aperu sur le langage IDL
Lanalyste peut adopter les formes du futur langage de programmation, par exemple C++ ou JAVA, si celui-ci
est dtermin lavance. Mais il serait sans doute prfrable de recourir un langage comme IDL, lInterface
Definition Language faisant partie de la norme CORBA ("Common Object Request Broker Architecture")
tablie par lObject Management Group (OMG).
2
Ce langage a prcisment t dfini dans le but de permet-
tre des spcifications indpendantes dun environnement particulier.
Le langage de spcification IDL est bas sur le langage de programmation C++, ce qui le rend demble com-
prhensible une grande partie des informaticiens ...

1
Cf. infra, 3.6.
2
OMG : CORBA / IIOP Specification, vers. 3.0; www.omg.org, 2002. Voir aussi : JM. GEIB, Ch. GRAN-
SART, Ph. MERLE : CORBA, des concepts la pratique; 2
e
d., Dunod, 1999 (cet ouvrage est tlchargea-
ble sur le site corbaweb.lifl.fr/CORBA_des_concepts_a_la_pratique/).
Un module IDL regroupe des dfinitions que lanalyste considre comme solidaires.
1
Tout nom peut
tre prfix par le nom du module o il est dfini suivi, comme en C++, de loprateur ::.
Pour lessentiel, un module contient la dfinition de linterface des diffrents types dobjets, cest--
dire la spcification de leurs attributs et oprations. Le(s) super-type(s) dont hrite un sous-type
dobjets est/sont list(s) la suite du nom du sous-type, comme en C++ (pour lillustrer dans
lexemple ci-dessous, nous dfinirons le type dassociation possession de comptes comme un sous-
type du strotype Association_1_N).
Dautres dfinitions sont possibles : types de donnes analogues aux types de donnes construits du
langage C, types (structurs) des signaux dexception, constantes, etc. Dans lexemple ci-dessous,
ces dfinitions auxiliaires font partie de la dfinition de linterface qui les utilise; on aurait pu les
placer en-dehors de la dfinition des interfaces.
Exemples
COMPTE
tat
solde
date dernier mouvt
ouvrir( )
dbiter( )
crditer( )
consulter( )
clturer( )
CLIENT
nom
adresse
1 1..* 1 1..*
titulaire
POSSESSION
module mta // mta-dfinitions (strotypes du modle Ent-Ass)
{
interface ASSOC_1_1 { };
interface ASSOC_1_N { };
interface ASSOC_M_N { };
};
module commun // dfinitions communes toutes les applications
{
typedef string Nom;
struct Date { short AA, MM, JJ; };
struct Adr_Postale { string rue_et_num, code_postal, localit; };
};
module Clients
{
interface Client
{
attribute commun::Nom nom;
attribute commun::Adr_Postale adresse;
// pas doprations dfinies actuellement
};

1
En IDL, lunit compilable est le module.
interface Compte
{
enum Etat_Compte { dbiteur, sold, crditeur };
attribute Etat_Compte tat;
attribute float solde;
attribute commun::Date date_dernier_mouvt;
exception Client_Inexistant
{
string nom_client;
};
void ouvrir (in Client titulaire) raises (Client_Inexistant);
void dbiter (in montant);
void crditer (in montant);
structure Relev
{
string nom_client;
float solde;
commun::Date date_dernier_mouvt;
};
Relev consulter ();
void clturer ();
};
interface Possession : mta::ASSOC_1_N
{
attribute Client titulaire;
attribute sequence<Compte> possd;
};
};
2.2. Modlisation des relations dabstraction
D'aprs la dfinition originelle du modle EntitAssociation, une association unit des objets ou concepts,
appels entits, dont l'existence est autonome (ex.: les entits HOMME et FEMME dans l'association CON-
JOINT).
Certains auteurs
1
ont mis l'accent sur d'autres relations, dites d'abstraction, qui apparaissent comme des rela-
tions de globalisation sur des ensembles d'occurrences. Ces relations sont l'agrgation, la classification et la
gnralisation.
2
Les mthodologies et systmes orients objets accordent une importance primordiale ces relations et les re-
prsentent par des symboles particuliers.
a) Agrgation / Contenance
L'agrgation (ou son inverse : la contenance) est la relation par laquelle une collection d'objets composants
constitue par elle-mme un objet agrgat caractris par des attributs et/ou des associations distincts de ceux
des composants; l'existence d'une occurrence de l'agrgat implique l'existence d'au moins une occurrence de
composant. Comme l'association, l'agrgation est une relation entre des occurrences.

1
Voir notamment J. SMITH, D. SMITH : op. cit. Les modles bass sur cette approche sont connus sous le
nom de modles des rseaux smantiques.
2
Nous avons montr au chapitre 2, 2.1 comment les deux dernires fondent les techniques de modlisation.
Le mcanisme dagrgation/dsagrgation est tout aussi fondamental dans une dmarche danalyse.
Dans la notation UML, un petit losange signale le type agrgat.
Dans un schma EntitAssociation, l'agrgat est prsent comme une entit, tandis que les composants peu-
vent tre des entits ou des associations.
L'ide d'quipe sur un chantier, qui permet de mettre en vidence le rle de chef d'quipe, est plus
porteuse d'information qu'une simple association d'OCCUPATION (OUVRIER, CHANTIER). En
outre, l'entrepreneur peut affecter une quipe un vhicule de socit adapt ses besoins ... (Noter
que, dans les schmas ci-dessous, un ouvrier peut tre membre et mme chef de plusieurs quipes.)
UML

CHANTIER
VEHICULE
OUVRIER
EQUIPE
0..* 0..*
1..*
0..*
1..1
0..*
chef
membre
OCCUPATION
COMPOSITION
1..*
AFFECTATION
DIRECTION
0..*
Ent/Ass

CHANTIER
VEHICULE
OUVRIER
EQUIPE OCCUPATION
COMPOSITION
AFFECTATION
DIRECTION
0,N 0,N
1,N
0,N
1,N
0,N
1,1
0,N
chef membre
En UML, on distingue deux niveaux dagrgation :
l'agrgation "partage" ou "faible", dans laquelle une mme occurrence de composant peut faire simulta-
nment partie de plusieurs agrgats (c'est le cas de l'exemple ci-dessus : un ouvrier peut faire partie de diff-
rentes quipes)
l'agrgation partage est symbolise par un losange vide
la composition ou agrgation "forte", dans laquelle une occurrence de composant n'existe qu'au sein d'un
unique compos (si le compos cesse d'exister, le composant cesse galement d'exister)
la composition est symbolise par un losange plein
PROJET
PHASE
n ordre
dat e dbut
dure
descript ion
objet
responsable
budget
1..1
1..*
PLANNING
b) Classification / Instanciation
La classification (ou son inverse : l'"instanciation"
1
) est l'abstraction par laquelle une dfinition commune
(la classe, la catgorie ou le type) s'applique un ensemble de phnomnes (ou occurrences). Il n'est pas
exceptionnel de devoir inclure dans la base de donnes, non seulement la description des occurrences, mais
galement la dfinition de la classe; c'est le cas chaque fois que des objets individuels peuvent appartenir
diverses catgories qui sont elles-mmes dcrites dans un catalogue.
Les attributs et/ou associations dcrivant la classe dcrivent galement chaque occurrence; en d'autres termes,
chaque occurrence d'une classe "hrite" des attributs et associations propres cette classe.
La relation de classification/instanciation est une relation entre type et occurrences.
Elle peut tre reprsente par une association dfinie de la manire suivante :
APPARTENANCE (TYPE de 0:N, OCCURRENCE de 1:1);
l'association APPARTENANCE n'a pas d'attributs autres qu'une ventuelle priode de validit;
elle a le mme identifiant que l'entit OCCURRENCE.
Exemples : types de chambres dans un htel, types de cotisations pour les membres d'un club ...
Ent/Ass
CHAMBRE
n
t age
occupat ion
rservat ions
CATEG.CHAMBRE
code cat gorie
prix nuit e
QUALIFICATION
type
occurrence
1,N
1,1
TYPE COTIS.
int it ul
mont ant
priodicit
COTISATION
dat e
MEMBRE
n
nom
adresse
type
0,N
1,1
occurrence
UML

CHAMBRE
n
t age
occupat ion
rservat ions
CATEG.CHAMBRE
code cat gorie
prix nuit e
TYPE COTIS.
int it ul
mont ant
priodicit
MEMBRE
n
nom
adresse
type
0..*
1..1
occurrence
COTISATION
dat e

1
"Instanciation" : mot anglais construit partir du radical "instance", qui signifie occurrence.
c) Gnralisation / Spcialisation
La gnralisation (ou son inverse : la spcialisation) est une relation par laquelle une mme occurrence
d'objet appartient deux types diffrents, dont l'un le sous-type est inclus dans l'autre le sur-type. Le
sous-type "hrite" des attributs, associations et oprations gnriques du sur-type; il possde en outre des at-
tributs, associations et/ou oprations spcifiques, qui le diffrencient; il peut encore redfinir autrement cer-
taines des caractristiques dont il hrite.
1
La gnralisation/spcialisation est une relation entre des types.
Ainsi qu'on le verra, cette relation peut tre utilise pour oprer certaines transformations des schmas de don-
nes : une spcialisation peut en amliorer la prcision, une gnralisation peut en diminuer la complexit.
Cet intrt mthodologique particulier justifie qu'elle ait t intgre au modle EntitAssociation, o elle
peut tre reprsente par un symbole ad hoc.
Elle pourrait galement tre reprsente sous la forme d'une association "EST-UN", dfinie de la manire sui-
vante :
EST-UN (SUR-TYPE de 0:1, SOUS-TYPE de 1:1);
l'association EST-UN n'a pas d'attributs autres qu'une ventuelle priode de validit;
le SOUS-TYPE et l'association EST-UN ont le mme identifiant que le SUR-TYPE.
UML Ent/Ass

PERSONNE
n nat ional
nom
prnom
dat e de naissance
FEMME MARIEE
nom de jeune fille
FEMME HOMME
EST-UNE
EST-UNE
EST-UNE
0,1
0,1
0,1
1,1 1,1
1,1
PERSONNE
n nat ional
nom
prnom
dat e de naissance
FEMME MARIEE
nom de jeune fille
FEMME HOMME
N.B. On peut, sans problme, concevoir des sous-types d'associations, mais la limitation du formalisme En-
titAssociation voque plus haut ne permet pas de reprsenter le lien de ces sous-types avec un sur-type
d'association. (Ici aussi, les types d'associations devraient tre transforms en types de pseudo-entits.)

1
Les langages de programmation par objets disposent dun mcanisme slectionnant automatiquement, parmi
les diverses dfinitions dune opration "polymorphe", celle qui convient chaque objet.
Exemple : le chef d'une quipe sur chantier fait partie des membres de cette quipe;
le sous-type d'associations DIRECTION est inclus dans le sur-type COMPOSITION :
OUVRIER
EQUIPE
COMPOSITION DIRECTION
1,N
1,1
1,1
0,1
chef
membre
2.3. Schma dynamique : diagrammes dtats et transitions
a) Etats
A tout moment, un objet se trouve dans un certain tat, caractris par la valeur de ses attributs et sa participa-
tion certaines associations.
On dfinit une classe d'tats par une expression logique portant sur la valeur des attributs de l'objet et/ou sa
participation l'une ou l'autre associations.
Exemple : type d'objet classes d'tats dfinitions
Produit { puis stock = 0
{ approvisionn stock > 0
Il est parfois possible d'oprer des regroupements de classes d'tats.
Exemple : type d'objet
Dette
classes d'tats (UML)
en cours
teinte
apure remise
dfinitions
solde > 0
apure OU remise
NOTE. Les exemples ci-dessus sont des exemples d'objetsentits dont les tats sont des tats inertes. D'au-
tres objets, par exemple un programme excut sous le contrle d'un superviseur (un "processus", dans la
terminologie des systmes d'exploitation), dans certains de leurs tats, sont actifs. C'est pourquoi, dans la
description d'une classe d'tats, la notation UML donne la facult de mentionner diffrentes actions :
une action ponctuelle excute lors de l'entre dans l'tat,
une "activit" continue pendant toute la dure de l'tat,
une action ponctuelle excute lors de la sortie de l'tat,
des actions ponctuelles ragissant la survenance de certains vnements.
Exemple : type d'objet
Processus
classes d'tats (UML)
en cours
entre : charger les paramtres
sortie : prparer le code de retour
faire : excuter les instructions
b) Transitions
Dans la vie d'un objet, on peut dfinir une ou plusieurs squences de transitions d'tats autorises.
Une transition d'tat, c'est--dire le passage d'un tat un autre,
est la consquence d'un vnement dont l'objet reoit la notification sous la forme d'un message.
Cependant, si l'tat de dpart est un tat actif, la transition est parfois automatique, sans message
(ex.: la fin d'excution d'un programme).
La transition peut tre "garde", c'est--dire subordonne une condition.
Elle peut s'accompagner d'une action,
c'est--dire de l'mission d'un message driv, ventuellement destin un autre objet.
Diagramme des transitions d'tats d'un objet (UML)
Produit
puis approvisionn
crer()
entrer(qt)
sortir(qt) [qt=stock] /
^commande_fournisseur.crer
(prod,qt,fourniss)
sortir(qt) [qt<stock]
entrer(qt)
SYNTAXE recommande :
transition := vnement [garde] / action
vnement := message
message := opration (paramtres)
action := ^objet_cible.message
Processus
en cours
exec()
entre : charger les paramtres
sortie : prparer le code de retour
faire : excuter les instructions
Noter la reprsentation conventionnelle
des tats initial (unique)
et finals (en nombre quelconque).
REMARQUE. Sous peine d'ambigut, une transition ne peut pas aboutir une classe d'tats dfinie par re-
groupement.
c) Mthode
Sur l'exemple de l'tat civil d'une personne, illustrons la dmarche d'laboration d'un tel diagramme.
1)
Rpertorier les classes d'tats de base :
Clibataire, Mari, Divorc, Veuf.
2)
Recenser les vnements pertinents,
causes de transitions :
naissance, mariage, divorce, dcs du
conjoint, dcs propre.
3)
Regrouper les classes d'tats se trouvant
l'origine des mmes transitions :
libre (C ou D ou V), en vie.
C
M
D V
mariage
divorce
dcs conjoint
naissance
dcs
en vie
libre
C M D V ()
x
C x x
M x x x
D x x
V x x
()
3. Contraintes d'intgrit
3.1. Porte des contraintes dintgrit
Le schma conceptuel des donnes ne serait pas complet s'il n'nonait les rgles de cohrence, les contraintes
d'intgrit applicables aux objets qu'il dcrit.
Certaines de ces contraintes doivent tre satisfaites tout moment; on les appelle des invariants. D'autres ne
doivent tre vrifies qu' certains moments; ce sont les pr-conditions ou post-conditions des oprations et
procdures du systme de traitement de l'information. Les pr-conditions dune opration doivent tre satis-
faites pour que lopration puisse tre entreprise; les post-conditions dune opration sont des prdicats que
lexcution de lopration doit rendre vrais, elles constituent lexpression formelle des rsultats de lopration.
Certaines contraintes "concernent" un seul type dobjet, entit ou association. Ces contraintes font partie in-
tgrante de la spcification de ce type dobjet. Certains langages
1
permettent dailleurs de les incorporer la
dfinition "programme" du type dobjet : les invariants sont attachs aux attributs, les pr- et post-conditions
sont attaches aux oprations.
3.2. Connectivit et identifiant
En prcisant les connectivits minimum et maximum d'un rle et en dfinissant l'identifiant minimal d'un
type d'objet, on exprime des contraintes d'intgrit, inhrentes au modle EntitAssociation.
3.3. Dure de rtention
Avec ou sans dimension historique explicite, une entit ou association est conserve un certain temps dans la
collection dcrite par le schma. C'est ce qu'on appelle sa priode de mmorisation ou de rtention.
Il est essentiel de formuler la rgle qui en dtermine la dure, car elle n'est pas sans influence sur l'exactitude
du schma. Ainsi, par exemple, dfinissant le type CLIENT comme "tout client ayant pass au moins une
commande qui a permis de l'identifier", on pourrait penser que la connectivit du rle de CLIENT dans le type
d'association PASSATION de COMMANDE est 1:N; or ceci impliquerait que toute commande (ou au moins
une commande) soit conserve pendant l'ternit ! Si, comme il se doit, on pose la contrainte que la dure de
rtention d'une commande n'est pas illimite, cette connectivit devient 0:N.
Nous ne proposerons pas de formalisme pour l'expression de cette contrainte. Indiquons toutefois que :
par dfaut, c'est--dire sans rgle explicite, la dure de rtention d'une entit est illimite;
par dfaut, la priode de rtention d'une association est gale l'intersection des priodes de r-
tention des entits participantes;
la dure de rtention est exprime par une condition impliquant une date ou un fait temporel, fr-
quemment associ l'excution d'une procdure (ex.: "pendant cinq annes compter du 1/1 de
l'anne suivante", "jusqu' la procdure de clture annuelle").

1
Exemples : EIFFEL, SQL3.
3.4. Contraintes ensemblistes
Certaines contraintes dfinissent des relations galit, inclusion, exclusion, partition ... qui doivent
exister entre certains ensembles d'occurrences dans la collection dcrite par le schma.
Exemples : contrainte entre sous-types d'un mme type (ex.: partition) :
invariant : {HOMME} {FEMME} = {PERSONNE} ;
invariant : {HOMME} {FEMME} = {} ;
contrainte entre les rles jous par une entit dans diverses associations :
LIVRAISON (COMMANDE excute-en 0:1, BORDEREAU accompagnant 1:1)
FACTURATION (COMMANDE facture-en 0:1, FACTURE mise-pour 1:1)
invariant : {COMMANDE excute dans LIVRAISON}
= {COMMANDE facture dans FACTURATION} ;
contrainte entre plusieurs associations des mmes entits :
COMPOSITION (EQUIPE compose-de 1:N, OUVRIER membre-de 1:1)
DIRECTION (EQUIPE dirige-par 1:1, OUVRIER chef-de 0:1)
invariant : {DIRECTION} {COMPOSITION} ;
3.5. Rgles relatives la valeur des attributs
a) Dfinition des domaines de valeurs
Tout domaine de valeurs doit tre dfini.
Domaine lmentaire
Un domaine lmentaire (ex.: PRIX, QUANTITE, NOM, NUMERO ...) est dfini comme faisant partie d'un
type de valeurs du genre de ceux que proposent les langages de programmation.
Exemples : domaine type de valeur
QUANTITE nombre entier
PRIX nombre dcimal en COBOL : PICTURE 9(6)V99
NOM CHAR(20) en COBOL : PICTURE X(20)
Cette dfinition doit souvent tre restreinte, soit sous la forme d'un intervalle, soit sous celle d'une liste de
valeurs discrtes qui est gnralement une liste de code (il est important, dans ce dernier cas, que la docu-
mentation livre la signification du code).
Exemples : CODE-SEXE = {0 = inconnu, 1 = masculin, 2 = fminin} ;
NOM-DE-MOIS = {"janvier"," fvrier"," mars"...} ;
MOIS = {1..12} ;
JOUR = {1..31} ;
Rappel. Ne pas oublier de dfinir la codification des valeurs spciales inexistant et inconnu.
Domaine structur
Un domaine structur est dfini comme une relation entre sous-domaines.
Exemple : DATE = (JOUR, MOIS, ANNEE) ;
concernant DATE : invariant :
MOIS {02} JOUR {1..29} ;
MOIS {04,06,09,11} JOUR {1..30} ;
ADRESSE = (RUE, NUMERO-DE-RUE, NUMERO-POSTAL, LOCALITE) ;
Un domaine exprimant une grandeur mesure doit en principe indiquer galement l'unit de mesure.
Exemple : PRIX = (MONTANT, DEVISE) ;
b) Restriction du domaine (condition d'appartenance)
Dans le contexte d'un type d'objet (entit ou association) prcis, la dfinition du domaine de valeurs d'un at-
tribut est parfois encore restreinte. Une telle rgle est souvent perue comme une condition particulire d'ap-
partenance au type d'objet.
Exemple : invariant : Quantit-Disponible de STOCK 0
c) Relations entre attributs
Contraintes statiques
La valeur de certains attributs peut tre lie certains autres attributs ou certaines associations.
Exemple 1 :
PERSONNE
nom
dat e naissance
HOMME
FEMME
nom de jeune fille
CONJOINT
dat e mariage
mari pouse
0,1
0,1
concernant CONJOINT : invariant : Date-Mariage > Date-Naissance de HOMME mari ;
concernant CONJOINT : invariant : Date-Mariage > Date-Naissance de FEMME pouse ;
concernant FEMME : invariant :
(Nom-de-Jeune-Fille inexistant) CONJOINT pour FEMME pouse ;
Exemple 2 :
CLIENT
n client
nom client
adresse client
FACTURE
n fact ure
t ot al fact ur
PRODUIT
n produit
(1) nom produit
quant it en st ock
prix de vent e
COMMANDE
n commande
PASSATION
dat e commande
LIGNE-FACTURE
quant it livre
mont ant fact ur
LIGNE-COMMANDE
quant it commande
FACTURATION
dat e fact ure
passant
passe
comprenant
command
factur
comprenant
facture
mise
0,N
1,1
0,1
1,1
1,N
1,N
0,N
0,N
concernant COMMANDE : aprs ENREGISTREMENT-COMMANDE :
n-commande = n-commande prcdent + 1 ;
concernant COMMANDE : aprs REINITIALISATION-ANNUELLE :
n-commande = 0 ;
concernant FACTURATION : invariant :
date-facture date-commande de PASSATION pour COMMANDE passe et facture ;
concernant LIGNE-FACTURE : aprs EDITION-FACTURE :
quantit-livre = MIN ( quantit-en-stock prcdente de PRODUIT factur,
quantit-commande de LIGNE-COMMANDE
pour [COMMANDE comprenant et facture
dans FACTURATION pour FACTURE comprenant,
PRODUIT command et factur] ) ;
concernant LIGNE-FACTURE : aprs EDITION-FACTURE :
quantit-en-stock de PRODUIT factur
= quantit-en-stock prcdente de PRODUIT factur quantit-livre ;
concernant LIGNE-FACTURE : invariant :
montant-factur = prix-de-vente de PRODUIT factur * quantit-livre ;
concernant FACTURE : invariant :
total-factur = montant-factur de LIGNE-FACTURE pour FACTURE comprenant ;
Contraintes d'volution
L'volution de la valeur de certains attributs peut tre soumise des contraintes spcifiques. Par exemple, il
est impossible de redevenir clibataire aprs avoir t mari. Pour exprimer ces rgles, on distinguera les va-
leurs successives au moyen du qualificatif prcdent.
Exemple : aprs mise jour :
Etat-Civil prcdent inexistant Etat-Civil "clibataire" ;
aprs CLOTURE-MENSUELLE :
Budget-Rsiduel = Budget-Rsiduel prcdent Dpenses-Imputes ;
Alors que la seconde de ces rgles est probablement utilise par un programme de calcul, l'applica-
tion de la premire relve de l'utilisateur du programme de mise jour des donnes, et celui-ci doit en
contrler l'application. Les programmes adopteront une attitude de comprhension "souple" devant
de telles contraintes : il faut, en effet, autoriser la correction des erreurs d'encodage !
REMARQUE. Les contraintes dvolution peuvent tre dcrites au moyen de diagrammes de transitions
dtats.
1
3.6. Dfinition smantique des oprations
La dfinition smantique dune opration de traitement de donnes, particulirement dune opration caract-
ristique dun type dobjet, complte la spcification externe de cette opration.
Le complment de dfinition comporte
explicitement :
les pr-conditions rendant possible lexcution correcte de lopration,
les post-conditions que lexcution de lopration doit rendre vraies;
implicitement :
les invariants attachs aux donnes ou objets rsultats de lopration.
Certaines de ces rgles expriment une galit; parmi elles se trouvent les rgles de drivation qui dfinissent
les crations ou transformations de donnes que lopration doit accomplir.
Ainsi, pour dfinir la smantique de lopration ddition dune facture, il suffit de regrouper les contraintes
dj formules ci-dessus et, pour tre complet, dautres semblables :
aprs EDITION-FACTURE :
concernant LIGNE-FACTURE :
quantit-livre = MIN ( quantit-en-stock prcdente de PRODUIT factur,
quantit-commande de LIGNE-COMMANDE
pour [COMMANDE comprenant et facture
dans FACTURATION pour FACTURE comprenant,
PRODUIT command et factur] ) ;
quantit-en-stock de PRODUIT factur
= quantit-en-stock prcdente de PRODUIT factur quantit-livre ;
invariant :
concernant FACTURATION :
date-facture date-commande de PASSATION pour COMMANDE passe et facture ;
montant-factur = prix-de-vente de PRODUIT factur * quantit-livre ;
concernant FACTURE :
total-factur = montant-factur de LIGNE-FACTURE pour FACTURE comprenant ;

1
Cf. supra, 2.3.
3.7. Formalisme pour l'expression des rgles
Pour donner une ide du degr de prcision souhaitable, sans toutefois nous encombrer des nombreuses
conventions d'un langage formel oprationnel, nous avons ci-dessus formul les rgles dans une bauche de
langage formalis, dont voici une brve dfinition.
a) La notion de rgle
Une rgle se prsente sous la forme
[contexte :] porte : expression ;
L'expression cite des variables, c'est--dire des composants quelconques du schma auquel la rgle est atta-
che : occurrences d'entits ou d'associations, attributs, collections d'occurrences.
Nous ne donnerons pas ici une liste exhaustive des oprations possibles. Il peut sagir doprations
arithmtiques (+ / ...), ensemblistes ( ...), logiques ( ...) ou de com-
paraison (= < > ...) ... Il peut aussi s'agir d'un nom de fonction accompagn de ses para-
mtres (ex.: min(a,b) ...).
L'expression doit tre vraie dans les circonstances prcises par la porte de la rgle :
invariant l'expression doit tre vraie tout moment
avant procdure l'expression est une pr-condition de la procdure mentionne
(l'excution de la procdure est impossible sinon)
aprs procdure l'expression est une post-condition de la procdure mentionne
(les post-conditions d'une opration en dfinissent le rsultat)
L'indication facultative d'un contexte permet d'allger la rdaction de l'expression :
concernant type nom d'un type d'entit ou d'association
Exemple : concernant STOCK : invariant : Quantit-Disponible 0 ;
est synonyme de invariant : Quantit-Disponible de STOCK 0 ;
b) La notion de variable
A l'intrieur d'une expression, un nom de type d'entit, d'association, d'attribut est employ pour dsi-
gner un lment (occurrence) quelconque du type en question.
Dans les expressions, la dsignation d'une variable peut tre indice et qualifie :
variable [indice] [qualificatif ...]
L'indice prcdent permet de distinguer les occurrences successives d'un mme type d'lment.
Exemple : n-commande prcdent de COMMANDE
Les qualificatifs permettent de "naviguer" dans le schma, c'est--dire de relier les lments du schma. Les
qualificatifs possibles sont les suivants :
attribut de entit
Ent
attr
attribut de association
Ass
attr
association pour entit rle
Ass Ent
rle
entit rle dans association
Ent Ass
rle
assoc
1
pour entit rle
1
et rle
2
dans assoc
2
Ass1 Ent
rle1
Ass2
rle2
assoc pour [entit
1
rle
1
... , entit
2
rle
2
..., ...]
Ent1 Ass
rle1
Ent2
rle2
Les prpositions de dans pour sont interchangeables.
Les noms de rles peuvent tre omis si cette omission ne rend pas la dsignation ambigu.
La dsignation d'une variable doit comporter autant de qualificatifs qu'elle en exige pour tre univoque.
Toutefois, le type indiqu comme contexte en tte de la rgle peut complter implicitement toute dsigna-
tion de variable.
Exemple : concernant CONJOINT : invariant :
Date-Mariage > Date-Naissance de HOMME mari ;
est synonyme de invariant : Date-Mariage de CONJOINT
> Date-Naissance de HOMME mari dans CONJOINT ;
En vue de faciliter la rdaction des expressions, on pourra dfinir des variables intermdiaires, que les ex-
pressions pourront galement rfrencer. Une variable intermdiaire est dclare de la manire suivante :
soit variable = variable [si expression] ;
Exemple : soit COMMANDE-EN-ATTENTE
= COMMANDE si (FACTURATION pour COMMANDE) ;
c) Les ensembles
Une variable ensemble est dnote en plaant la dsignation de la variable lment dans une paire d'accola-
des :
{variable}
Exemples : {FACTURE}
{n-produit de PRODUIT}
{COMMANDE-EN-ATTENTE}
Les expressions peuvent en outre rfrencer des ensembles littraux :
liste d'lments : {1,2,5,7} {"janvier","fvrier",...}
liste d'intervalles : {1..12,15..20}
ensemble vide : {}
ensemble nomm : nom de domaine, nom de variable intermdiaire
Remarque
Les schmas graphiques que nous utilisons dfinissent des types d'entits et d'associations; ils ne dfinissent
pas les types de collections. Pour dfinir un type de collection et lui attribuer un nom, on emploiera une rgle
du genre de celles-ci :
Exemples : FICHIER-DES-CLIENTS = {CLIENT} ;
TABLE-DES-MOIS = {"janvier", "fvrier", ...} ;
CODE-SEXE = {0, 1, 2} ;
4. Validation du schma
Le premier jet d'un schma de donnes doit tre valid par un examen approfondi, ayant pour objet de lever
les ambiguts et contradictions, d'affiner et prciser la reprsentation de la ralit perue, de contrler les re-
dondances.
4.1. Suppression des incohrences
a) Correction des anomalies lexicographiques
Pour chaque dfinition, on "officialisera" un seul vocable, mais il sera bon de signaler dans la documentation
quels en sont les synonymes usuels.
L'incorporation d'un qualificatif peut rendre un vocable univoque (par exemple, COMMANDE sera prcis
en COMMANDE-DE-CLIENT et COMMANDE-A-FOURNISSEUR). On pourra cependant tolrer qu'un
nom d'attribut soit polysme (par exemple, "date-de-commande"), puisqu'il est naturellement qualifiable par
le nom du type d'objet qu'il dcrit (ex.: date-de-commande de COMMANDE-A-FOURNISSEUR)..
b) Vrification des contraintes, Elimination des contradictions
Lors de l'laboration d'un schma de donnes, les questions les plus porteuses de renseignements sont celles
qui concernent les contraintes d'intgrit inhrentes au modle : la connectivit des rles et la composition
des identifiants minimaux. Il est donc utile de faire, sur ces questions, un second tour de piste.
On vrifiera en particulier qu'il n'existe pas de contradiction entre les connectivits indiques et les contrain-
tes ensemblistes ou de dure de rtention. (On a dj donn l'exemple suivant : si la dure de rtention des
COMMANDEs est limite, la connectivit minimale du rle de CLIENT dans le type d'association
PASSATION de COMMANDE ne peut pas tre 1.)
4.2. Affinage du schma
a) Normalisation des composants
Certains attributs peuvent cacher un type d'association.
1
On cherchera alors dsagrger les types d'objets
possdant ces attributs, en explicitant le type d'association cach, pour autant que les compositions mises en
place enrichissent la smantique ou diminuent la redondance. Pour ce faire, on recourra aux rgles de nor-
malisation, dont les trois premires ont t tablies par CODD, dans son modle relationnel;
2
ces rgles font
usage du concept de dpendance fonctionnelle, dfini au chapitre 2.

1
Rappelons la parent des concepts d'attribut et type d'association.
2
E. CODD : Further Normalization of the Database Relational Model in RUSTIN (ed) : Data Base Sys-
tems, Prentice-Hall, 1972. Par la suite, d'autres auteurs ont dfini une quatrime et une cinquime formes
normales.
1NF (1
st
normal form) Un type d'entit ou d'association est en premire forme normale si tous ses attributs
sont atomiques, c'est--dire simples (non rptitifs) et lmentaires (non structurs).
Si un attribut est la fois rptitif et structur, il s'agit presque certainement d'un type d'association dguis.
Exemple : l'attribut "liste des rsultats" d'examens d'un tudiant,
chaque indication de rsultat comportant l'identification de la matire et la cote obtenue
MATIERE
int it ul
ETUDIANT
nom
liste:
{rsultat=
intitul,cote}
ETUDIANT
nom
RESULTAT
cot e
0,N
0,N
Mais il n'y aurait certainement aucun apport remplacer un attribut "liste des prnoms" par un type d'associa-
tion entre le type d'entit PERSONNE et un type d'entit PRENOM !
2NF (2
nd
normal form) Un type d'entit ou d'association est en deuxime forme normale s'il est en 1NF et
qu'en outre aucun attribut ne dpende fonctionnellement d'une partie seulement de ses identifiants.
Cette rgle fait rfrence un identifiant compos, ce qui est le plus souvent le cas d'une association, mais
quelquefois aussi d'une entit.
Exemple : l'attribut "prix unitaire" dans le type d'association LIGNE-COMMANDE
est en ralit un attribut d'un type d'entit (PRODUIT) associ
PRODUIT
n produit
nom produit
COMMANDE
n commande
LIGNE-COMMANDE
quant it commande
prix unitaire
0,N 1,N
comprenant
command
Mais si, dans le laps de temps sparant la rception et l'excution de la commande, le prix de vente unitaire est
susceptible de changer, le "prix la commande" (copi dans la LIGNE-COMMANDE) et le "prix de catalo-
gue" sont peut-tre sous le mme nom deux informations distinctes. Copier ainsi dans chaque LIGNE-
COMMANDE le prix unitaire en vigueur la date de rception de la commande pourrait rendre superflue la
conservation d'un historique du tarif.
3NF (3
rd
normal form) Un type d'entit ou d'association est en troisime forme normale s'il est en 2NF et s'il
n'existe pas de dpendance fonctionnelle transitive par rapport un de ses identifiants, c'est--dire s'il n'existe
pas d'attribut dpendant d'un autre, lui-mme dpendant d'un identifiant.
Exemple : dans le type d'entit FACTURE,
les attributs "date de commande" et "numro de client"
dpendent du "numro de commande",
qui est lui-mme dtermin par l'identifiant "numro de facture"
CLIENT
n client
nom client
FACTURE
n fact ure
n commande
date commande
n client
nom client
COMMANDE
n commande
PASSATION
FACTURATION
0,N
1,1
0,1
1,1
BCNF (Boyce-Codd normal form) Le dterminant de toute dpendance fonctionnelle l'intrieur d'un type
d'objet, entit ou association, doit tre un identifiant, primaire ou candidat, de cet objet.
Cette formule, due Boyce, rsume (et tend) les trois formes normales de Codd.
b) Spcialisation par sous-typage
La dfinition de sous-types produit une modlisation plus explicite et souvent plus rigoureuse.
Gnralisations implicites
Le fait que certains attributs d'un type d'entit ou d'association prennent la valeur "inexistant" en fonction de la
valeur d'autres attributs est un signe que le type d'entit ou d'association a t dfini par gnralisation. Dans
ce cas, n'est-il pas indiqu de procder une modlisation plus explicite, en distinguant des sous-types ?
Exemple. Le catalogue d'une firme de vente signale pour certains produits seulement un dlai de li-
vraison; il s'agit de produits que la firme ne garde pas en stock mais qu'elle achte un fournisseur.
PRODUIT
n produit
prix de vent e
[dlai de livraison]
HORS-STOCK
dlai de livraison
PRODUIT
n produit
prix de vent e
Associations conditionnelles
Un type d'association conditionnel, ne faisant intervenir un type d'entit que si un attribut de ce dernier pos-
sde une ou des valeur(s) particulire(s) n'est dfini, en toute rigueur, que sur un sous-type de cette entit.
Exemple. Si le type d'association CONJOINT est simplement dfini sur le type PERSONNE, une r-
gle supplmentaire doit signifier la condition de diffrence de sexe; la modlisation suivante est plus
explicite.
PERSONNE
nom
dat e naissance
HOMME
FEMME
nom de jeune fille CONJOINT
dat e mariage
mari pouse
0,1
0,1
4.3. Simplification du schma
a) Simplification des structures
Associations de degr lev
Un type d'association de degr lev reflte souvent un dfaut d'analyse. On cherchera donc le dcompo-
ser, c'est--dire le transformer en une composition de types d'associations de degr moindre. Un indice fr-
quent d'une telle situation est celui-ci : il existe des dpendances fonctionnelles entre les diffrents rles d'un
type d'association ou, en d'autres termes, l'identifiant minimal de ce type d'association n'inclut pas les identi-
fiants de tous les types d'entits associs.
Exemple : ENSEIGNEMENT (MATIERE dispense-dans 1:N, CLASSE suivant 1:N,
par son identifiant, la dfinition ci-dessus pose que
une matire enseigne une classe donne l'est par un seul professeur;
elle n'interdit pas qu'une matire soit toujours enseigne par le mme professeur,
pour quelque classe que ce soit;
dans ce cas, la dfinition devrait devenir la suivante :
CLASSE
PROFESSEUR
MATIERE
PROGRAMME
ENSEIGNEMENT
suivant
suivie
enseigne
titulaire
1,N
1,N
1,1
1,N
Compositions de connectivits 1:1
La proprit d'quivalence smantique nonce plus haut sera exploite pour simplifier les compositions ne
comportant que des connectivits 1:1, particulirement si ces compositions comprennent des types d'associa-
tions vides d'attributs.
PRODUIT
COMMANDE
LIGNE
COMMANDE
COMPOSITION CONCERNE 1,1 1,1 0,N 1,N
b) Contrle des structures redondantes
L'laboration d'un schma de donnes peut avoir dfini des structures redondantes, qu'il convient d'liminer
ou, tout le moins, de justifier. On adoptera pour principe de conserver la structure la plus porteuse d'infor-
mation (on pourra prendre pour mesure de la richesse smantique d'une structure le nombre d'attributs qu'elle
comporte); en cas d'galit, on conservera la structure la moins complexe (on prendra pour mesure de la
complexit le nombre de types d'objets).
Les situations suivantes sont assez frquentes.
Il se peut qu'on ait indiqu comme attribut d'un type d'entit l'identifiant d'un type d'entit associ; cet attri-
but est donc redondant avec l'association. On conservera l'association, smantiquement plus riche.
DEPARTEMENT
n dpart ement
EMPLOYE
n mat ricule
n dpartement
OCCUPATION
1,1 1,N
occup occupant
Deux types d'associations dfinis sur les mmes types d'entits avec les mmes connectivits doivent tre sus-
pects de redondance. Cette situation peut, en particulier, rsulter de la simplification, voque plus haut, des
compositions utilisant des connectivits 1:1.
Un type d'association, probablement vide d'attributs, peut s'avrer n'tre que le "rsum" d'une composition
de plusieurs associations. On conservera la composition, smantiquement plus riche.
FACTURE
COMMANDE
BORDEREAU
ACCOMPAGNEMENT
FACTURATION
LIVRAISON
1,1
0,N
0,1
1,1
1,N 1,1
c) Cas particulier : les attributs drivables
Un attribut drivable est un attribut dont la valeur peut tre tout moment dtermine, le plus souvent par
calcul, partir de la valeur d'autres attributs. Ainsi, l'attribut "prix factur" est drivable des attributs "prix de
vente unitaire" et "quantit livre" si ces deux derniers sont disponibles tout instant de la priode de rten-
tion du premier et l'attribut "montant total" de la facture est drivable partir des "prix facturs" dtaills.
Dans une collection d'informations enregistres, la prsence d'un attribut drivable est une redondance com-
pliquant les oprations de mise jour : soit un attribut R dont la valeur peut tre obtenue partir d'une srie
d'attributs D
i
; lors de tout changement de valeur d'un des attributs D
i
, la valeur de R doit tre galement modi-
fie. En revanche, la description d'une collection d'informations communiques par un document doit men-
tionner les attributs drivables, dont l'utilit spcifique est toujours d'amliorer la lisibilit du document.
Remarque. Dans les diagrammes UML, le nom d'un attribut drivable est prfix d'une barre oblique /.
4.4. Note sur les sous-schmas
Un sous-schma constitue une slection parmi les types d'objets rpertoris dans le schma global de la base
de donnes : certains types d'entits, certains types d'associations et mme certains attributs dans les types
d'objets retenus sont masqus.
En outre, les types d'objets conservs sont quelquefois transforms, de manire pallier l'absence des objets
masqus. On notera en particulier :
la transformation d'un type d'association en type d'entit, si un des types d'entits participants est masqu;
l'incorporation un type d'entit, en guise d'attributs, des identifiants des types d'associations masqus;
l'incorporation des lments permettant de dterminer la valeur des attributs drivables, si ces lments ap-
partiennent aux objets masqus.
CLIENT
n client
nom client
adresse client
FACTURE
n fact ure
t ot al fact ur
PRODUIT
n produit
(1) nom produit
quant it en st ock
prix de vent e
COMMANDE
n commande
PASSATION
dat e commande
LIGNE-FACTURE
quant it livre
mont ant fact ur
LIGNE-COMMANDE
quant it commande
FACTURATION
dat e fact ure
passant
passe
comprenant
command
factur
comprenant
objet de
pour
0,N
1,1
0,1
1,1
1,N
1,N
0,N
0,N
FACTURE
n fact ure
t ot al fact ur
date facture
n client
nom client
adresse client
CORPS
FACTURE
LIGNE
FACTURE
quant it livre
mont ant fact ur
quantit commande
n produit
nom produit
prix de vente
1,N
1,1
5. Validation du systme de rgles
5.1. Compltude du systme de rgles
Il est ncessaire de procder une vrification systmatique de la compltude du systme de rgles associ au
schma de donnes. Tout particulirement du sous-systme des rgles de drivation, dont le caractre faisa-
ble doit ainsi tre certifi.
Appelons donne primaire toute variable (lmentaire ou ensemble) dont la valeur n'est pas " calculer",
mais "reue"; appelons rsultat toute variable (lmentaire ou ensemble) dont la valeur est " calculer" par
l'application d'une rgle de drivation.
Pour chaque rgle nonce, on vrifiera les points suivants :
pour chaque rgle exprimant une galit, on statuera sur le point de savoir si elle constitue une condition de
validit (1V) ou une rgle de drivation (1D) (elle peut avoir les deux usages, mais dans des contextes
diffrents);
toutes les variables rfrences par la rgle sont-elles inventories (2) dans le schma des donnes ?
toute variable rfrence est-elle une donne primaire (3P) ? sinon, existe-t-il une rgle de drivation
dont elle soit le sujet (3D) ?
toutes les variables mentionnes dans la rgle sont-elles qualifies de manire univoque (4) ?
Il va de soi que ces vrifications impliquent l'emploi d'annotations : on "marquera" chaque rgle et chaque
variable ayant subi avec succs chacun des examens ci-dessus, par exemple, au moyen des numros indiqus
entre parenthses dans le texte de l'alina prcdent.
5.2. Cohrence du systme de rgles
Deux rgles sont redondantes si elles expriment, dans des formes diffrentes, la mme relation. On notera le
cas particulier de la permutation des parties gauche et droite d'une galit.
Le systme de rgles doit tre exempt de contradictions. Ceci est aisment vrifiable pour les rgles expri-
mant une galit : si plusieurs rgles d'galit non redondantes concernent le mme sujet, elles doivent avoir
des portes mutuellement exclusives.
6. En guise de conclusion
6.1. Recommandations diverses
Les auteurs de la mthode OMT formulent les recommandations suivantes. [La premire fois qu'un terme
propre la mthode OMT est employ, nous indiquons entre crochets son quivalent dans la terminologie du
modle EntitAssociation.]
Ne commencez pas construire un modle objet [schma EntitAssociation] en jetant ple-mle
classes [types d'entits], associations et hritage [sous-typage]. Vous devez avant tout compren-
dre le problme rsoudre. Le contenu d'un modle objet est conditionn par la pertinence de la
solution.
Efforcez-vous de garder votre modle simple. Evitez les complications inutiles.
Choisissez les noms avec soin. Ils sont importants et portent des connotations puissantes. Ils doi-
vent tre descriptifs, prcis, sans ambigut et ne doivent pas subir l'influence exclusive d'un seul as-
pect de l'objet. Le choix de bons noms est l'une des facettes les plus dlicates de la modlisation des
objets.
N'enfouissez pas des pointeurs ou des rfrences d'objets [identifiants trangers] dans les objets
en tant qu'attributs. Modlisez-les plutt comme des associations. C'est plus clair et cela saisit la
vritable intention plutt qu'une approche particulire d'implmentation.
Evitez si possible les associations ternaires et n-aires. La plupart de celles-ci peuvent tre dcom-
poses en associations binaires, ventuellement avec [...] des attributs de lien [attributs d'associa-
tion].
N'essayez pas d'exprimer parfaitement les multiplicits [connectivits] trop tt dans le dvelop-
pement.
Ne dissolvez pas les attributs de lien [attributs d'association] dans une classe [type d'entits].
[...]
Essayez d'viter les gnralisations profondment imbriques.
Reconsidrez les associations un--un. Souvent l'objet chaque extrmit est optionnel et une
multiplicit zro-ou-un peut tre plus approprie. A d'autres moments, une multiplicit "plusieurs"
sera ncessaire.
Ne soyez pas surpris que votre modle objet ait besoin d'une rvision. Il faut souvent de multiples
itrations pour clarifier les noms, rparer les erreurs, ajouter des dtails et prendre correctement en
compte les contraintes structurelles. Plusieurs de nos modles les plus complexes, qui sont seule-
ment longs de quelques pages, ont ncessit une demi-douzaine d'itrations.
Soumettez votre modle des avis extrieurs. Le modle objet peut susciter l'intrt d'autres per-
sonnes et mener une implication plus large de leur part.
Documentez systmatiquement vos modles objet. Le diagramme spcifie la structure d'un mo-
dle mais ne peut prciser les raisons qui ont prsid aux divers choix. L'explication crite guide
le lecteur travers le modle et explique les raisons subtiles pour lesquelles il a t structur de
cette faon. Les explications crites clarifient la signification des noms dans le modle et peuvent
porter la raison d'tre de chaque classe et de chaque relation.
1
6.2. Documentation du schma
C'est dessein que nous avons, ci-dessus, soulign le dernier paragraphe. Chaque nom (d'entit, d'associa-
tion, d'attribut ...) apparaissant dans un schma est le rsum d'une ou plusieurs discussions avec diffrents
interlocuteurs. La documentation accompagnant un schma doit reproduire le contexte duquel est issu chaque
nom, avec sa richesse et son "paisseur smantique".
Empruntons aux mmes auteurs l'exemple suivant, limit la dfinition des types d'entits. Le problme ana-
lys est celui du rseau de Guichets Automatiques Bancaires (GAB) d'un consortium de banques.
Compte Compte unique dans une banque, sur lequel les transactions sont appliques. Les
comptes peuvent tre de diverses sortes, comme des comptes chques ou des comptes pargne. Un
client peut dtenir plus d'un compte.
GAB Station partir de laquelle les clients peuvent raliser eux-mmes leurs transactions en
utilisant des cartes bancaires pour s'identifier. Le GAB interagit avec le client pour rcuprer les
informations de la transaction, les met vers l'ordinateur central pour validation et traitement, puis
dlivre les billets. Nous supposons que le GAB ne peut pas fonctionner sans le rseau.
Banque Institut financier qui gre les comptes des clients et dlivre les cartes bancaires autori-
sant l'accs aux comptes par le rseau des GAB.
Ordinateur de banque Ordinateur appartenant une banque, ralisant l'interface avec le r-
seau des GAB et les stations propres la banque. Une banque peut dtenir son propre rseau d'or-
dinateurs pour grer ses comptes, mais nous ne nous intressons qu' celui faisant l'interface avec le
rseau des GAB.
Carte bancaire Carte dlivre par une banque ses clients, leur permettant l'accs leur pro-
pre compte l'aide des GAB. Chaque carte comporte un code bancaire et un numro de carte, ces
derniers tant cods pour respecter les standards nationaux sur les cartes bancaires et de crdit. Le
code bancaire identifie la banque l'intrieur du consortium. Une carte ne permet pas ncessaire-
ment l'accs tous les types de comptes du client. Chaque carte de crdit est dtenue par un client
unique, mais plusieurs copies d'une mme carte peuvent exister; les accs simultans par une mme
carte doivent donc tre pris en considration.
Caissier Employ d'une banque qui est autoris effectuer des transactions partir des agences
bancaires. Il accepte et dlivre argent et chques au client. Les transactions, l'argent et les chques
manipuls par un caissier doivent tre enregistrs.
Agence bancaire Agence o un caissier peut raliser des transactions pour un client. Le cais-
sier accepte des chques et de l'argent du client et lui en dlivre galement; des reus sont impri-
ms. L'agence est en communication avec l'ordinateur de la banque pour valider et traiter les tran-
sactions.

1
Ordinateur central Ordinateur appartenant au consortium, et grant les transactions entre les
GAB et les ordinateurs des banques. L'ordinateur central valide les codes bancaires mais ne traite
pas les transactions lui-mme.
Consortium Organisation de banques qui gre le rseau des GAB. Ce rseau ne traite que les
transactions des banques du consortium.
Client Dtenteur d'un ou de plusieurs comptes dans une banque. Un client peut consister en une
ou plusieurs personnes ou une entreprise; la diffrence est sans importance pour ce problme. La
mme personne possdant des comptes dans diffrentes banques est considre comme plusieurs
clients.
Transaction Requte complte unique pour raliser des oprations sur un compte. La spcifi-
cation du GAB n'indique que la possibilit de dlivrer de l'argent, mais nous pourrions considrer la
possibilit d'imprimer des chques, d'accepter de l'argent ou des chques. Nous pourrions prvoir
aussi la possibilit d'oprer sur les comptes de clients diffrents, bien que ce ne soit pas demand ici.
Les diffrentes oprations doivent avoir des soldes quilibrs.
1
Le processus d'analyse est long et itratif ... La dernire dfinition ci-dessus montre que, tout au long
de son laboration, un dossier d'analyse contient des dfinitions provisoires ("nous pourrions prvoir
aussi ..."), sur lesquelles l'analyste devra revenir ...
Aux suggestions implicites des exemples ci-dessus, ajoutons celles-ci.
Lorsque c'est possible, la notice dcrivant un type d'objet, entit ou association, reprendra la dfi-
nition juridique ou rglementaire de la notion dcrite.
Cette notice dfinira, sans ambigut, les conditions d'existence (entre et sortie) d'une occur-
rence du type dcrit dans l'ensemble modlis (ex.: "un CLIENT est toute personne physique ou mo-
rale ayant pass au moins une commande, qui a permis de l'identifier, et cela depuis moins de deux
ans la date du 1
er
janvier coul").
La dfinition d'un type d'association mentionnera ncessairement chaque type d'entit associ et
comportera gnralement un commentaire des connectivits. Exemple : "pour une commande, une
LIGNE DE COMMANDE reprsente la quantit commande d'un produit; toute commande com-
prend au moins une ligne de commande".
La dfinition dtaille d'un attribut n'est utile que si elle apporte un complment aux renseigne-
ments fournis par le nom de cet attribut qui, normalement, en identifie le domaine de valeurs et le
rle dans la description de l'objet.
Enfin, tout lment d'information (entit, association, attribut, domaine de valeurs) doit tre le plus compl-
tement possible localis dans l'espace et le temps :
quelle est l'origine ou quels sont les responsables de la dfinition du concept (type) et de la mise
jour des valeurs (occurrences) ?
qui cette information est-elle destine ou distribue ?
quels sont les aspects historiques de l'information : dures de vie et de rtention, transitions
d'tats ?

1
A. CLARINVAL Analyse Schma logique 4-1
Chapitre 4. Schma logique du stockage des donnes
Un schma de stockage des donnes doit rendre compte des types d'objets stocks. La dfinition du contenu
smantique d'un schma de stockage constitue un schma logique des donnes. Les types d'objets d'une
structure de stockage seront dfinis par transformation du schma conceptuel.
Le schma logique des donnes doit tre complt par celui des fonctions d'accs ncessaires aux applica-
tions utilisatrices.
La dernire section de ce chapitre montre en quoi le schma logique du stockage des donnes constitue un
support de la programmation, avec application particulire au langage COBOL.
1. Schma des structures de stockage : le modle en Rseau
1.1. Elments d'une structure de stockage
Un enregistrement (ou article) est un espace du support de stockage, accessible en tant qu'occurrence dis-
tincte. La dfinition smantique d'un type d'enregistrement dcoule de la transposition d'un type d'entit ou
d'association.
La rinterprtation des rles dfinis dans le schma EntitAssociation rsulte en la dclaration de liaisons
entre enregistrements. Le concept de liaison sera prcis plus loin.
Un enregistrement est dcoup en champs. Un champ contient l'inscription d'une valeur. La dfinition s-
mantique d'un champ quivaut celle d'un attribut.
1.2. Transformation du schma EntitAssociation
Nous illustrons ici une mthode simple pour transformer en rseau un schma EntitAssociation.
Soit le sous-schma conceptuel suivant.
CLIENT
n client
nom client
adresse client
PRODUIT
n produit
(1) nom produit
quant it en st ock
prix de vent e
PASSATION
dat e commande
LIGNE-FACTURE
quant it livre
mont ant fact ur
LIGNE-COMMANDE
quant it commande
FACTURATION
dat e fact ure
passant
comprenant
command
factur
comprenant
objet de
0,N
0,1
1,N
1,N
0,N
0,N
PROSPECTUS
t ype prospect us
REPRESENTANT
nom reprsent ant
rgion
chiffre d'affaires
ABONNEMENT
CONTACT
contactant
envoy
abonn
1,N
0,N
0,N
FACTURE
n fact ure
t ot al fact ur
COMMANDE
n commande
CLIENT
PROFESSIONNEL
n TVA
CLIENT
PRIVE
1,1
1,1
passe
contact par
pour
1,1
La firme entretient un contact rgulier avec ses clients. Un client professionnel est contact par un reprsen-
tant. Un client priv est contact par prospectus; il peut tre "abonn" diffrents types de prospectus et
une rgle veut qu'il soit, tout moment, "abonn" un prospectus au moins.
La transformation de ce schma comporte les oprations suivantes.
1) Orienter les arcs reprsentant les rles, par une flche dans le sens Association Entit ou sous-type
sur-type. Chaque flche reprsente un type de liaison. Le type d'objet (Entit) situ la pointe de la fl-
che est propritaire de la liaison; le type d'objet (Association) situ l'origine de la flche est membre de
la liaison.
CLIENT
n client
nom client
adresse client
PRODUIT
n produit
(1) nom produit
quant it en st ock
prix de vent e
PASSATION
dat e commande
LIGNE-FACTURE
quant it livre
mont ant fact ur
LIGNE-COMMANDE
quant it commande
FACTURATION
dat e fact ure
passant
comprenant
command
factur
comprenant
objet de
0,N
0,1
1,N
1,N
0,N
0,N
PROSPECTUS
t ype prospect us
REPRESENTANT
nom reprsent ant
rgion
chiffre d'affaires
ABONNEMENT
CONTACT
contactant
envoy
abonn
1,N
0,N
0,N
FACTURE
n fact ure
t ot al fact ur
COMMANDE
n commande
CLIENT
PROFESSIONNEL
n TVA
CLIENT
PRIVE
1,1
1,1
passe
contact par
pour
1,1
2) Indiquer la connectivit 0:1 sur les liaisons de sous-typage, c'est--dire sur les flches dpourvues de
cette indication.
CLIENT
n client
nom client
adresse client
0,1
0,1
CLIENT
PROFESSIONNEL
n TVA
CLIENT
PRIVE
3) Fusionner en un seul type d'enregistrement les types d'objets lis par une liaison de connectivit 1:1,
1
en
conservant pour nom du type d'enregistrement, un nom de type d'entit.
CLIENT
n client
nom client
adresse client
PRODUIT
n produit
(1) nom produit
quant it en st ock
prix de vent e
PASSATION
dat e commande
LIGNE-FACTURE
quant it livre
mont ant fact ur
LIGNE-COMMANDE
quant it commande
FACTURATION
dat e fact ure
passant
comprenant
command
factur
comprenant
objet de
0,N
0,1
1,N
1,N
0,N
0,N
PROSPECTUS
t ype prospect us
REPRESENTANT
nom reprsent ant
rgion
chiffre d'affaires
ABONNEMENT
CONTACT
contactant
envoy
abonn
1,N
0,N
0,N
0,1
0,1
FACTURE
n fact ure
t ot al fact ur
COMMANDE
n commande
CLIENT
PROFESSIONNEL
n TVA
CLIENT
PRIVE
4) Supprimer la distinction entre type d'entit et type d'association.
5) Incorporer au type d'enregistrement membre de chaque liaison l'identifiant (tranger) du type d'enre-
gistrement propritaire.
2
Indiquer si cet identifiant tranger fait partie de l'identifiant primaire de l'enregistre-
ment membre. Le nom d'un identifiant tranger sera construit d'aprs le schma suivant : nom de l'attribut
nom du type propritaire qualificatif de la liaison.

1
Thoriquement, cette fusion pourrait se limiter faire disparatre les types d'associations sans attributs.
2
En toute rigueur, cette transformation, qui cre de la redondance, est ici prmature. D'ailleurs, certains
systmes de stockage (les bases de donnes CODASYL) n'y ont pas recours. Elle devrait s'oprer plus tard,
lors de l'laboration du schma physique des systmes de stockage qui l'exigent, comme les fichiers COBOL
ou les bases de donnes relationnelles. C'est parce que nous n'aborderons plus de manire systmatique les
problmes de transformation des schmas de donnes que nous citons ce point ds ici.
CLIENT
n client
nom client
adresse client
PRODUIT
n produit
(1) nom produit
quant it en st ock
prix de vent e
PASSATION
dat e commande
LIGNE-FACTURE
quant it livre
mont ant fact ur
LIGNE-COMMANDE
quant it commande
FACTURATION
dat e fact ure
passant
comprenant
command
factur
comprenant
objet de
0,N
0,1
1,N
1,N
0,N
0,N
PROSPECTUS
t ype prospect us
REPRESENTANT
nom reprsent ant
rgion
chiffre d'affaires
CLIENT
PRIVE
n client
ABONNEMENT
CONTACT
contactant
envoy
abonn
1,N
0,N
0,N
0,1
0,1
FACTURE
n fact ure
t ot al fact ur
COMMANDE
n commande
CLIENT
PROFESSIONNEL
n TVA
type prospectus
n client
n client
nom reprsentant
n commande
n produit
n client
n commande
n facture
n produit
6) Eventuellement, supprimer tout type d'enregistrement ne contenant d'autre attribut que son identifiant, s'il
n'est membre d'aucune liaison (le type d'enregistrement PROSPECTUS peut tre supprim). Un tel type
d'enregistrement sera nanmoins conserv si l'on souhaite constituer une liste des identifiants valides (identi-
fiants autoriss pour les enregistrements ABONNEMENT).
1.3. Commentaires sur le concept de liaison
Le concept de liaison est le concept central du modle prsent ici. Ce modle en rseau est d l'Amricain
BACHMAN, qui le cra ds 1963 pour supporter un systme de "stockage intgr des donnes" ("IDS, Inte-
grated Data Store"), anctre des systmes de gestion de bases de donnes. En 1970, CODASYL, organisme
crateur du langage COBOL, l'a adopt comme base de sa proposition de standard pour les bases de donnes.
Depuis lors, dans la variante mise au point par J. MARTIN dans sa mthode IEM ("Information Engineering
Methodology"), il joue galement, dans les rgions anglophones, le rle de modle de conception, que les
francophones assignent plutt au modle EntitAssociation.
1

1
a) Terminologie
Dans les bases de donnes CODASYL, une liaison est ralise sous la forme dun ensemble ("set") denre-
gistrements interconnects, entre lesquels il est possible de "naviguer" c'est--dire passer de l'un l'autre.
Soit un type de liaison E A. Une occurrence e du type d'enregistrement E est propritaire d'un ensemble
{a
i
} dont les membres ou lments sont les occurrences de A lies e. L'ensemble {a
i
} peut contenir un nom-
bre quelconque d'lments ou membres, c'est--dire d'occurrences de A, y compris 1 ou 0 (ensemble singleton
ou vide).
E
A
e1
e2
a3 a2 a1
Selon une autre terminologie, dans une liaison E A, E est pre ou parent, A est fils ou enfant.
Dans un schma en rseau, un enregistrement peut tre membre de diffrents types de liaisons, un enfant peut
avoir plusieurs parents.
1
Dans notre exemple, chaque LIGNE-DE-COMMANDE L
ij
possde deux parents :
une COMMANDE C
i
et un PRODUIT P
j
.
C1 C2
P1
P2
L11
L12
L21
L22
b) Contraintes dfinies sur les liaisons
Liaison obligatoire ou facultative
Les liaisons Epropritaire Amembre dfinies ce stade de la transformation sont obligatoires, en ce sens
qu'elles mettent en jeu toujours une (1:1) occurrence de E propritaire (il est obligatoire pour toute occur-
rence de A d'tre lie une occurrence de E). On verra plus loin que l'on peut dfinir des liaisons facultati-
ves, mettant en jeu au plus une (0:1) occurrence de E propritaire (il est facultatif pour une occurrence de A
d'tre lie une occurrence de E).
Connectivit d'un type de liaison
Dans un schma EntitAssociation, l'orientation d'un rle E(ntit) A(ssociation) est vidente, du fait de la
nature diffrente des deux extrmits E et A : type d'entit et type d'association. Dans le schma en rseau, ce
n'est plus le cas et l'orientation de la liaison est indique au moyen des connectivits.

1
Nous verrons plus loin l'utilit de dfinir des sous-schmas arborescents, dans lesquels tout enfant possde
un seul parent.
La connectivit [min..max] mentionne chaque extrmit de l'arc reprsentant un type de liaison indique
combien d'occurrences d'enregistrements de cette extrmit est reli chaque enregistrement du type situ
l'extrmit oppose.
Voici les conventions graphiques, d'usage fort rpandu, de la mthode Information Engineering :
le nombre 0 est reprsent par un cercle O
(omis par plusieurs reprsentations parce que pris pour valeur minimale par dfaut)
le nombre 1 est reprsent par un trait |
le nombre N est reprsent par une fourche /|\
CLIENT
n client
nom client
adresse client
ABONNEMENT
n client
t ype prospectus
REPRESENTANT
nom reprsent ant
rgion
chiffre d'affaires
COMMANDE
n commande
dat e commande
n client
FACTURE
n fact ure
n commande
dat e fact ure
t ot al fact ur
LIGNE COMMANDE
n commande
n produit
quant it commande
LIGNE FACTURE
n fact ure
n produit
quant it livre
mont ant fact ur
PRODUIT
n produit
<1> nom produit
quant it en st ock
prix de vent e
CL.PRIVE
n client
CL.PROFESSIONNEL
n client
n TVA
nom reprsent ant
passant
objet
comprenant
command
comprenant
fact ur
cont act ant
est
est
abonn
Sur une liaison, le losange est plac du ct du type membre.
Le prfixe signale un identifiant tranger.
La connectivit 1:1 attache au propritaire d'une liaison obligatoire est parfois laisse ltat implicite.
c) Interprtation d'une liaison comme tant une association
Bien qu'il ne soit pas issu d'un type d'association du schma EntitAssociation, mais d'un rle, un type de
liaison peut tre regard comme un type d'association qui possde les proprits suivantes :
1
une liaison est une association sans attributs;
un type de liaison est binaire, c'est--dire de degr 2 (un type de liaison peut tre cyclique);
une liaison est asymtrique : sa reprsentation est celle d'un rle orient E(ntit) A(ssociation);

1
Historiquement, c'est pour gnraliser le concept d'association, en supprimant les restrictions qui lui sont
imposes ici, qu'ont t dvelopps les modles EntitAssociation tudis au chapitre prcdent.
une liaison est fonctionnelle, en ce sens que chaque occurrence d'une liaison E A met en correspondance
une occurrence de E et un nombre quelconque d'occurrences de A, nombre dcrit par la connectivit hrite
du schma conceptuel.
1
REMARQUE. Dessinant les associations binaires sous la forme d'un simple trait, le formalisme des diagram-
mes de classes en UML peut servir la reprsentation d'un schma en rseau.
2
1.4. Optimisation du schma
En vue de simplifier les squences d'oprations d'accs qui seront ncessaires l'excution des traitements
informatiques, on examinera, cas par cas, l'opportunit d'effectuer d'autres transformations qui auront pour
effet de construire des types d'enregistrements plus agrgs. Ces transformations sont l'inverse de certaines
transformations sous-typage et normalisation effectues lors de la validation du schma conceptuel.
Cependant, le dtour n'est sans doute pas inutile : les dsagrgations pralablement opres sur le schma
conceptuel, qui avaient pour ambition d'aider l'analyste affiner et prciser sa perception de la ralit, garan-
tissent que les agrgats rintroduits ici ne sont pas des erreurs dues un dfaut d'analyse.
Chaque optimisation effectue entrane l'obligation de formuler et, plus tard, de programmer de nouvel-
les rgles ou contraintes d'intgrit.
a) Gnralisation
On peut fusionner les types d'enregistrements unis par une liaison de connectivit 0:1. Dans la plupart des
cas, cette transformation concerne des liaisons de sous-typage et constitue une gnralisation, inverse de
l'opration de spcialisation (ex.: fusion des deux sous-types de clients dans le sur-type CLIENT).
Les attributs l'origine attachs au membre d'un telle liaison sont incorpors au propritaire, o ils peuvent
prendre la valeur "inexistant"; cette nouvelle contrainte doit tre note dans une rgle. De plus, les connecti-
vits de toutes les liaisons qui impliquaient le type d'enregistrement (membre) disparu sont modifies : la
connectivit minimale dcrivant la participation de tout type d'enregistrement li au membre disparu est rame-
ne 0 la condition de rattachement doit galement tre note dans une rgle. En d'autres termes :
toute liaison dont le type d'enregistrement disparu (ex.: CLIENT-PROFESSIONNEL) tait membre de-
vient facultative, ce qui quivaut dire que la participation du propritaire (ex.: REPRESENTANT) une
telle liaison devient facultative (connectivit 0:1 plutt que 1:1);
dans toute liaison dont le type d'enregistrement disparu (ex.: CLIENT-PRIVE) tait propritaire, la parti-
cipation du membre (ex.: ABONNEMENT) devient facultative, avec une connectivit 0:N au lieu de 1:N.

1
Dans le modle de BACHMAN-CODASYL, la connectivit du membre est toujours 0:N. Une autre
connectivit (1:N, 0:1) doit tre garantie par programme.
2
Cf. chapitre 3.
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
nom reprsentant
ABONNEMENT
n client
type prospectus
REPRESENTANT
nom reprsentant
rgion
chiffre d'affaires
abonn
contactant
Remarque. Dans le type d'enregistrement rsultant d'une telle fusion, on incorpore souvent un attribut redon-
dant, un indicateur de catgorie, signalant "rapidement" quel(s) sous-type(s) appartient chaque occurrence.
Un tel attribut est qualifi de discriminant.
En rduisant les nombres d'enregistrements et de liaisons, le procd de gnralisation rduit la complexit de
la base de donnes.
b) Dnormalisation
On peut rintroduire dans le schma une certaine redondance, en procdant des dnormalisations, dont les
diffrentes formes sont dcrites ci-aprs.
Ces optimisations ont pour but de simplifier et acclrer les oprations de consultation dans la base de don-
nes. Mais elles compliquent les oprations de mise jour.
Propagation parent ==> enfants
La dnormalisation la plus frquente consiste copier dans l'enregistrement membre (ou enfant) d'une liaison
un attribut non identifiant de l'enregistrement propritaire (ou parent).
Les exemples suivants pourraient se justifier.
Une firme doit facturer ses livraisons, gnralement effectues au bout d'un dlai, au tarif en application la
date de commande. Le fait de recopier dans l'enregistrement LIGNE-COMMANDE le prix-de-vente du tarif
en vigueur la date de passation de la commande peut entraner l'conomie d'une gestion historique des ta-
rifs.
En recopiant dans l'enregistrement FACTURE l'identifiant tranger "numro de client" pris dans l'enregis-
trement COMMANDE, on cre une liaison directe CLIENT FACTURE, conomisant le dtour par la
commande : le grand-parent peut tre consult sans dtour par le parent.
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
nom reprsentant
ABONNEMENT
n client
type prospectus
REPRESENTANT
nom reprsentant
rgion
chiffre d'affaires
COMMANDE
n commande
date commande
n client
FACTURE
n facture
date facture
total factur
n commande
n client
LIGNE COMMANDE
n commande
n produit
quantit commande
prix de vente
LIGNE FACTURE
n facture
n produit
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
passant
objet
comprenant
command
comprenant
factur
abonn
contactant
Soit la donne copie du parent dans l'enfant. Toute modification de dans un enregistrement parent doit
tre propage, c'est--dire rpte, dans les enregistrements enfants (gnralement multiples !). Dans les en-
registrements enfants, l'attribut doit tre non modifiable, sauf par l'opration prcdente.
Drivation parent(s) ==> enfants
Le mcanisme de propagation est en ralit une forme simplifie de drivation, mthode par laquelle la valeur
d'un attribut dans un enregistrement enfant est obtenue (calcule) partir de celle d'autres attributs dans un
ou plusieurs enregistrements parents.
LIGNE FACTURE
n facture
n produit
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
factur
Les remarques faites ci-dessus au sujet du cas particulier de la propagation sont applicables au cas gnral de
la drivation.
Rcapitulation enfants ==> parent
A un enregistrement parent, on peut incorporer un attribut drivable partir de valeurs contenues dans l'en-
semble des enregistrements enfants.
FACTURE
n facture
date facture
total factur
n commande
n client
LIGNE FACTURE
n facture
n produit
quantit livre
montant factur
comprenant
Soit la donne calculable dans l'enregistrement parent et la donne considre dans l'enregistrement en-
fant. Toute modification de dans un enregistrement enfant doit entraner un nouveau calcul de dans l'en-
registrement parent. Dans l'enregistrement parent, est un attribut non modifiable, sauf par l'opration prc-
dente.
Deux types d'algorithmes sont envisager pour recalculer .
Si tous les enfants d'un mme enregistrement parent sont crs ou modifis en une seule transaction, les
valeurs peuvent tre cumules en mmoire centrale, et un seul accs l'enregistrement parent est effectu au
moment de conclure la transaction.
Dans le cas o les diffrents enfants sont crs ou mis jour des poques disperses, toute mise jour
d'un enregistrement enfant s'accompagne d'un accs l'enregistrement parent pour ajuster la valeur de .
Fusion des enregistrements parent et enfants
On pourrait aussi envisager d'incorporer les enregistrements membres d'une liaison l'enregistrement propri-
taire de cette liaison, faisant ainsi disparatre la liaison. Par exemple : fusionner en un seul les enregistre-
ments COMMANDE et LIGNE-COMMANDE. Les membres de la liaison deviennent des attributs rptitifs.
Ce procd ne respecte pas la 1
re
forme normale dfinie par CODD, et prsente deux inconvnients : l'impos-
sibilit habituelle de dfinir un nombre fixe d'occurrences dans le vecteur d'attributs rptitifs et l'impossibilit
de crer une base de donnes relationnelle et manipulable par les langages de requtes.
1.5. Structures particulires
a) Enregistrement d'intersection
Un enregistrement d'intersection est la traduction d'une association sans attributs, dont tous les rles ont la
connectivit maximale N. Les seuls champs prsents dans un tel enregistrement sont les identifiants (tran-
gers) des enregistrements auxquels il est li.
Exemple : une cole est abonne diffrentes revues; une liste de diffusion mentionne les professeurs qui
les revues doivent tre communiques en lecture.
Ent/Ass

REVUE
DIFFUSION
PROFESSEUR
transmise lecteur
t it re nom
0,N 0,N
UML

REVUE
DIFFUSION
PROFESSEUR
transmise lecteur
t it re nom
0..* 0..*
IEM

REVUE
titre
DIFFUSION
nom lecteur
titre revue
PROFESSEUR
nom
transmise lecteur
b) Liaison cyclique
Une liaison peut tre cyclique, c'est--dire dfinie sur un seul type d'enregistrement.
Soit le schma EntitAssociation suivant :
SOCIETE
raison sociale
sige social
DEPENDANCE
mre
filiale
0,N
0,1
Aprs incorporation des identifiants trangers, l'association cyclique de DEPENDANCE prend la forme d'un
enregistrement d'intersection :
SOCIETE
raison sociale
sige social
DEPENDANCE
raison sociale filiale
raison sociale mre
mre
filiale
Aprs fusion du membre DEPENDANCE, de connectivit 0:1, dans le type propritaire FILIALE, le schma
montre une liaison facultative :
1
SOCIETE
raison sociale
sige social
[raison sociale mre]
mre

1
Dans le modle CODASYL, cette transformation n'est pas possible, car ce modle n'admet pas les types de
liaisons cycliques.
1.6. Contraintes d'intgrit
a) Reformulation des rgles
Non seulement les dnormalisations impliquent la dfinition de nouvelles contraintes dintgrit, mais les r-
gles (contraintes d'intgrit) dj formules dans le contexte du schma EntitAssociation doivent recevoir
une nouvelle formulation qui tienne compte des autres modifications apportes au schma.
On notera d'abord que les contraintes exprimes par rapport aux rles dans le schma EntitAssociation s'ap-
pliquent automatiquement aux types de liaisons qui en drivent.
Soit la rgle : date-facture de FACTURATION date-commande de PASSATION pour COMMANDE passe
et facture dans FACTURATION. Lors de la transformation du schma, les associations PASSATION et
FACTURATION ont t incorpores aux enregistrements COMMANDE et FACTURE; ce faisant, les rles
COMMANDE passe et FACTURE mise ont disparu. Les adaptations suivantes doivent tre apportes dans
le systme de rgles associ au schma :
redfinir comme une variable intermdiaire tout type d'objet disparu par absorption (l'expression de dfi-
nition sera une projection, c'est--dire une sous-liste d'attributs, dans le type absorbant) :
soit PASSATION = ( date-de-commande ) de COMMANDE ;
soit FACTURATION = ( date-de-facture ) de FACTURE ;
dans l'nonc des rgles, supprimer toute mention des rles disparus par suite d'absorption :
date-de-facture de FACTURATION date-de-commande de PASSATION
b) Relaxation des contraintes de connectivit 1:N
Prenons l'exemple de la liaison unissant les enregistrements COMMANDE et LIGNE-COMMANDE.
COMMANDE
n commande
date commande
n client
LIGNE COMMANDE
n commande
n produit
quantit commande
comprenant
Aux deux extrmits de la liaison, les connectivits minimales sont 1 (1:1 et 1:N). Cette contrainte signifie
qu'aucune LIGNE-COMMANDE ne peut tre enregistre si elle ne peut tre relie une COMMANDE pr-
existante et qu'aucune COMMANDE ne peut tre accepte si elle ne peut tre relie au moins une LIGNE-
COMMANDE prexistante. On tolrera cependant que, pour la dure des oprations d'enregistrement seule-
ment ce qu'on appelle une transaction , cette contrainte soit viole, sans quoi il serait impossible d'enre-
gistrer un bon de commande.
Dans de trs nombreux cas, on devra cependant accepter que l'enregistrement du propritaire d'une liaison soit
effectu antrieurement l'enregistrement des membres de cette liaison. Il est alors ncessaire de relaxer la
contrainte, en transformant la connectivit 1:N en 0:N.
c) Intgrit des rfrences
Dfinition
Soit le type de liaison Epropritaire Amembre. On dit que, dans les occurrences Amembres, un identi-
fiant tranger fait rfrence l'occurrence Epropritaire.
La contrainte d'intgrit rfrentielle impose que la valeur de tout identifiant tranger dans le type Amembre
existe parmi les identifiants du type Epropritaire.
1
Cette contrainte doit tre respecte pour tout type de
liaison obligatoire.
Elle ne s'applique pas un type de liaison facultative; dans ce cas, l'identifiant tranger peut possder la va-
leur "inexistant".
Cration du propritaire d'une liaison
Le propritaire d'une liaison obligatoire doit tre enregistr avant les membres de cette liaison (ou au cours
de la mme transaction cf. paragraphe prcdent).
Dans le cas d'une liaison facultative, l'enregistrement du propritaire peut tre postrieur celui du membre;
mais, alors, le membre doit tre "rattach" son nouveau propritaire.
Suppression du propritaire d'une liaison
Que faire des occurrences Amembres lies une occurrence Epropritaire que l'on dsire supprimer ?
Dans le cas d'une liaison facultative, la suppression de l'occurrence Epropritaire est autorise; les identi-
fiants trangers dans les occurrences Amembres sont considrs comme possdant une valeur "inexistant".
Dans le cas d'une liaison obligatoire et si l'ensemble des membres n'est pas vide (il existe au moins une oc-
currence de A), une rgle particulire doit tre fournie :
ou bien la suppression de l'occurrence Epropritaire doit tre refuse son autorisation est "limite"
("restricted") au cas o l'ensemble des Amembres est vide,
ou bien les occurrences Amembres lies doivent galement tre supprimes cette rgle est rcursive :
elle se propage "en cascade" sur les ensembles dont chaque occurrence A est propritaire, etc.
Exemple : toute LIGNE-COMMANDE est membre de deux liaisons obligatoires :
COMMANDE 1:1 1:N LIGNE-COMMANDE
PRODUIT 1:1 0:N LIGNE-COMMANDE
si on supprime le propritaire COMMANDE, on doit, au cours de la mme transaction,
supprimer en cascade les membres LIGNE-COMMANDE;
l'autorisation de supprimer un PRODUIT est limite au cas des PRODUITs
qui ne sont rfrencs par aucune LIGNE-COMMANDE.

1
L'ensemble des occurrences d'identifiants du type propritaire constitue en quelque sorte un domaine dyna-
mique dans lequel l'attribut identifiant tranger prend ses valeurs.
2. Prparation du schma physique
2.1. Schma des fonctions d'accs
a) Introduction
Qu'il prenne la forme d'une base de donnes intgre ou celle d'un ensemble de fichiers spcialiss, un systme
physique de stockage des donnes doit permettre d'accder facilement et conomiquement aux diffrentes
donnes (concrtement : au diffrents enregistrements). Il le fait en incluant divers dispositifs techniques
acclrateurs, par exemple :
la contigut des enregistrements rendant immdiat l'accs l'enregistrement "suivant" (cette tech-
nique est la seule disponible sur une bande magntique);
le placement de chaque enregistrement une adresse calcule partir de la valeur d'un identifiant,
assurant un accs slectif immdiat l'enregistrement en question;
la constitution de rpertoires ou d'index acclrant la recherche;
etc.
1
Un schma logique n'est pas un schma physique ... La dfinition logique des types d'objets stocks ne prcise
donc pas les formes matrielles de ces objets (par exemple, elle ne signale pas l'ordre des champs dans l'es-
pace de l'enregistrement); elle ne dfinit pas non plus les techniques d'accs mettre en uvre. Mais elle doit
identifier les oprations d'accs qu'il est ncessaire de rendre possibles.
La mise en vidence des fonctions d'accs dcoule de l'analyse gnrale des oprations et algorithmes du
systme informatique mettre en place; en d'autres termes, elle s'inscrit dans l'analyse de l'application
qui sera insre dans le domaine dcrit par la modlisation pralable des donnes. Elle s'effectue donc
lors d'une seconde phase de l'analyse.
b) Prliminaire : le concept d'ensemble selon CODASYL
Dans les bases de donnes CODASYL, un ensemble est la ralisation d'une (occurrence de) liaison. Soit un
type de liaison Epropritaire Amembre. Une occurrence e du type d'enregistrement E est propritaire
d'un ensemble {a
i
} dont les membres ou lments sont les occurrences de A lies e. L'ensemble {a
i
} peut
contenir un nombre quelconque d'lments ou membres, c'est--dire d'occurrences de A, y compris 1 ou 0
(ensemble singleton ou vide).
Pour tre accessible, tout enregistrement d'un type quelconque doit, tout moment, tre membre d'au moins un
ensemble. Tout type d'enregistrement doit donc tre membre d'au moins un type de liaison obligatoire. Pour
que la chose soit possible, un type d'enregistrement fictif SYSTEM, contenant une seule occurrence, est im-
plicitement dfini dans tout schma. L'enregistrement SYSTEM n'est membre d'aucune liaison (il est donc
inaccessible). Il peut tre dclar propritaire de liaisons dfinies vers chacun des types d'enregistrements
existants; la chose est en tout cas ncessaire pour les types qui ne sont membres d'aucune liaison obligatoire.

1
Cf. A. CLARINVAL : Exploitation et Organisation des Fichiers, 2
e
partie.
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
nom reprsentant
ABONNEMENT
n client
type prospectus
REPRESENTANT
nom reprsentant
rgion
chiffre d'affaires
COMMANDE
n commande
date commande
n client
FACTURE
n facture
date facture
total factur
n commande
n client
LIGNE
n commande
n produit
quantit commande
prix de vente
LIGNE
n facture
n produit
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
SYSTEM
passant
objet
comprenant
command
comprenant
factur
abonn
contactant
c) Dfinition des mthodes d'accs
1
Cl d'accs
Une cl d'accs est une mthode permettant de slectionner des sous-ensembles d'occurrences d'un type d'en-
registrement donn. Un identifiant est un cas particulier de cl d'accs, qui permet de slectionner un sous-
ensemble singleton.
Mettant en uvre la relation de dpendance fonctionnelle, une cl d'accs est forme d'un groupe de champs
dterminant le sous-ensemble slectionn. En outre, les systmes de stockage qui matrialisent les cls d'accs
sous la forme d'index
2
considrent habituellement que tout prfixe (partie de gauche) l'intrieur d'une cl
d'accs constitue lui-mme une cl d'accs; de ce fait, l'ordre existant entre les composants d'une cl d'accs
n'est pas indiffrent.
Exemple : on dfinit sur le type d'enregistrement LIGNE-FACTURE
la cl d'accs qu'est son identifiant "n facture, n produit",
dont "n facture" est un prfixe considr comme cl;
ci-dessous sont illustrs deux accs par cls :

1
Ce paragraphe s'inspire de J.L. HAINAUT : Conception assiste des applications informatiques : concep-
tion de la base de donnes, Masson, 1986.
2
L'indexation, technique associant chaque valeur de cl la liste des adresses des enregistrements corres-
pondants, n'est pas la seule manire de matrialiser le concept de cl d'accs. Autre technique : l'adressage
calcul transforme directement en adresses les valeurs de la cl, en leur appliquant une formule de calcul.
cl n facture n produit quantit livre montant factur
3550 1076 1 399
3550,1210 3550 1210 10 5990
3550 1453 1 1219
3551 3551 1076 1 399
3551 2017 2 1998
3551 2044 20 9980
Sur tout type d'enregistrement peuvent tre dfinies une ou plusieurs cls d'accs. La dfinition de tout type
d'enregistrement comportera l'identification des cls dfinies sur ce type.
Remarque. La plupart des cls d'accs dfinies dans un schma sont des identifiants : identifiants propres
(primaire et candidats) de chaque type d'enregistrement A, identifiants trangers dsignant les enregistrements
E propritaires des liaisons dont le type A est membre.
Squence d'accs
Une squence d'accs est une mthode permettant, au dpart d'une occurrence a
i
d'un type d'enregistrement,
d'accder aux autres occurrences du mme type.
Entre les occurrences membres d'un ensemble est dfini un ordre de succession, appel squence d'accs. Au
dpart de toute occurrence, la squence d'accs dtermine quelle est l'occurrence suivante.
Une squence d'accs peut tre
indiffrente;
l'ordre chronologique d'insertion des membres dans l'ensemble (ou l'ordre chronologique inverse,
plus intressant, comme on l'a vu, dans les ensembles historiques) ;
dtermine par une cl de tri.
Une cl de tri est une cl d'accs, dont chaque composant est muni d'un sens, "ascendant" ou "descendant",
dterminant l'ordre entre les valeurs de ce composant. Fonctionnellement, l'accs est une succession d'accs
par cl utilisant les valeurs de la cl dans l'ordre dfini, chacun obtenant le sous-ensemble d'occurrences
correspondant.
Exemples : dans la liaison SYSTEM 0:N FACTURE,
une cl de tri explicite serait "date facture descendant, n facture ascendant"
n facture date facture n commande n client total factur
3551 03/08/95 4208 125 12397
3552 03/08/95 4212 532 899
3550 02/08/95 4211 257 7608
dans la liaison FACTURE comprenant 1:N LIGNE-FACTURE,
une cl de tri explicite serait "n produit ascendant".
n facture n produit quantit livre montant factur
3550 1076 1 399
3550 1210 10 5990
3550 1453 1 1219
La dfinition de chaque type de liaison possdant une connectivit maximale suprieure 1 comportera la
dfinition de la squence d'accs applicable l'ensemble des membres de cette liaison, si elle n'est pas indiff-
rente.
Chemin d'accs
Un chemin d'accs est une mthode permettant, au dpart d'une occurrence e
1
d'un type d'enregistrement E
1
,
d'accder aux occurrences d'un autre type E
2
lies cette occurrence e
1
.
1
Pour tout type de liaison Epropritaire Amembre dclare, deux chemins d'accs sont possibles :
un chemin allant du type Epropritaire au type Amembre : dans chaque ensemble, ce chemin part de
l'occurrence propritaire E et conduit la premire occurrence de l'ensemble des membres A; l'ensemble des
membres est alors parcouru selon la squence d'accs dfinie sur cet ensemble; ce chemin donne un accs
exhaustif tous les membres de l'ensemble; enfin, on retourne l'occurrence E propritaire (on verra plus
loin l'utilit de ce retour l'occurrence propritaire).
E
A
e1
e2
a3 a2 a1
Exemple : parcours d'un ensemble FACTURE comprenant 1:N LIGNE-FACTURE :
FACTURE n facture date facture n commande n client total factur
3550 02/08/95 4211 257 7608
LIGNE-FACT n facture n produit quantit livre montant factur
3550 1076 1 399
3550 1210 10 5990
3550 1453 1 1219
FACTURE n facture date facture n commande n client total factur
3550 02/08/95 4211 257 7608
un chemin allant du type Amembre au type Epropritaire : dans chaque ensemble, une ralisation de
ce chemin unit chaque occurrence du membre A l'occurrence propritaire E; ce chemin donne un accs s-
lectif aux lments du type E.
E
A
e1
a3 a2 a1

1
Dans la terminologie UML, on parle de sens de navigation, en disant que l'association est (une voie) "navi-
gable" dans telle direction.
Sur le diagramme, les chemins d'accs seront figurs par des flches qui en indiqueront la direction.
1
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
nom reprsentant
ABONNEMENT
n client
type prospectus
REPRESENTANT
nom reprsentant
rgion
chiffre d'affaires
COMMANDE
n commande
date commande
n client
FACTURE
n facture
date facture
total factur
n commande
n client
LIGNE COMMANDE
n commande
n produit
quantit commande
prix de vente
LIGNE FACTURE
n facture
n produit
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
SYSTEM
passant
objet
comprenant
command
comprenant
factur
abonn
contactant
2.2. Quantification du schma
Pour oprer des choix techniques raisonns et optimaux, la modlisation physique doit disposer de quantifica-
tions.
Quantification du stockage : longueur des champs (c'est--dire des chanes de caractres reprsentant les
valeurs des attributs), nombre d'occurrences (ce qu'on appelle population) d'enregistrements de chaque
type.
Quantification des accs : nombre de consultations via chaque structure d'accs, nombre d'ajouts, de modi-
fications et de suppressions.
Ces quantifications seront rapportes des poques ("au dpart, aprs un an...") ou des priodes ("par jour,
par semaine, par mois..."). Les quantits indiques seront toutes les grandeurs d'intrt statistique : maxi-
mum, mode, moyenne.

1
La mme convention existe dans les diagrammes de classes d'UML.
3. Le schma logique des donnes, support de la programmation
3.1. Parcours d'un ensemble
On l'a signal : en suivant le chemin d'accs du type Epropritaire au type Amembre, on effectue un par-
cours exhaustif de l'ensemble, qui part de l'occurrence E propritaire et y retourne.
Dans le contexte de l'ensemble dont elle est propritaire, les attributs de l'occurrence E propritaire peu-
vent se rpartir en deux classes :
les attributs sources, dont la valeur est indpendante du contenu de l'ensemble des membres A (tels sont
notamment les identifiants de E);
les attributs rsultats (trs souvent, des totaux), dont la valeur est calcule partir de celles des membres
A de l'ensemble.
Dans l'ordre chronologique, le programme accde donc :
aux attributs sources de l'occurrence E propritaire (ex.: date de facture),
aux occurrences des A membres (ex.: lignes de la facture),
aux attributs rsultats de l'occurrence E propritaire (ex.: total factur).
E
A
e1
S R
a3 a2 a1
On reconnat la structure classique d'une boucle de programme, initialise et clture.
traiter l'occurrence de E :
traiter les attributs sources de E
pour chaque occurrence de A
traiter l'occurrence de A
fin pour chaque occurrence de A
traiter les attributs rsultats de E
3.2. Sous-schma arborescent
Un sous-schma arborescent est une partie d'un schma, caractrise de la manire suivante :
il comprend l'enregistrement fictif SYSTEM, qui en constitue la racine;
tout autre type d'enregistrement est membre d'un seul type de liaison.
Dans le schma suivant, diffrents sous-schmas arborescents peuvent tre dfinis, comme ceux qui sont iden-
tifis par les minuscules places le long des liaisons qui les composent.
a
a
b
b
c
c
c
c
d
d
e
e
e
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
nom reprsentant
ABONNEMENT
n client
type prospectus
REPRESENTANT
nom reprsentant
rgion
chiffre d'affaires
COMMANDE
n commande
date commande
n client
FACTURE
n facture
date facture
total factur
n commande
n client
LIGNE COMMANDE
n commande
n produit
quantit commande
prix de vente
LIGNE FACTURE
n facture
n produit
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
SYSTEM
passant
objet
comprenant
command
comprenant
factur
abonn
contactant
La composition d'un sous-schma arborescent peut tre dfinie au moyen d'une expression parenthse de la
forme : nom-de-propritaire (ensemble-1, ensemble-2, ...)
o chaque ensemble est dcrit de la manire suivante : nom-de-liaison cardinalit nom-de-membre
et o le nom de la racine SYSTEM est remplac par le nom attribu au sous-schma.
Exemples : les sous-schmas illustrs la figure prcdente peuvent tre dfinis comme ceci :
a (0:N REPRESENTANT (contactant 0:N CLIENT))
b (0:N CLIENT (abonn- 0:N ABONNEMENT))
c (0:N COMMANDE (comprenant 1:N LIGNE-COMMANDE,
objet-de 0:1 FACTURE (comprenant 1:N LIGNE-FACTURE)))
d (0:N FACTURE (comprenant 1:N LIGNE-FACTURE))
e (0:N PRODUIT (command-par 0:N LIGNE-COMMANDE,
factur-par 0:N LIGNE-FACTURE))
Le concept de sous-schma arborescent est important.
D'une part, la collection reprsente par un sous-schma arborescent peut tre parcourue par un programme
hirarchis sur autant de niveaux de boucles embotes que le sous-schma comprend de niveaux de liaisons.
Exemple : le sous-schma arborescent deux niveaux de liaisons
E
0
(SYSTEM) E
1
(FACTURE) E
2
(LIGNE-FACTURE)
sera trait de la manire suivante :
pour chaque occurrence de E
1
(FACTURE)
traiter les attributs sources de E
1
(FACTURE)
2
(LIGNE-FACTURE)
traiter l'occurrence de E
2
(LIGNE-FACTURE)
fin pour chaque occurrence de E
2
traiter les attributs rsultats de E
1
(FACTURE)
1
3.3. Transformation squentielle des sous-schmas arborescents
a) Constitution des fichiers squentiels
D'autre part, la condition de scinder tout enregistrement propritaire d'un ensemble en deux parties compre-
nant, l'une les attributs sources, l'autre les attributs rsultats, la collection reprsente par un sous-schma ar-
borescent peut tre stocke de manire linaire, sur un imprim ou dans un fichier squentiel.
Il suffit pour cela de remplacer dans le programme du paragraphe prcdent le verbe "traiter" par le verbe
"crire".
Exemple : pour chaque occurrence de E
1
(FACTURE)
crire les attributs sources de E
1
(FACTURE) enregistrement d'en-tte
2
(LIGNE-FACTURE)
crire l'occurrence de E
2
(LIGNE-FACTURE)
2
crire les attributs rsultats de E
1
(FACTURE) enregistrement rcapitulatif
1
b) Cas particulier : ensembles htrognes
Considrons le sous-schma arborescent :
SYSTEM ETUDIANT
RESULTAT COURS
RESULTAT EXERCICE
Il prsente la particularit que le type ETUDIANT est propritaire de plusieurs (deux) types d'ensembles.
Pour la transformation squentielle, on considrera qu'il s'agit d'un seul ensemble dont les membres sont de
plusieurs types.
SYSTEM ETUDIANT RESULT. COURS ou EXERC.
c) Syntaxe de dfinition
La syntaxe propose plus haut pour la dfinition des sous-schmas arborescents peut aisment tre tendue en
vue de permettre la description des particularits introduites par leur transformation squentielle :
deux descriptions d'ensembles spares par "+" plutt que par "," dfinissent un ensemble htrogne;
les attributs sources et rsultats du type propritaire sont regroups dans deux types d'enregistrements de 1:1
occurrence, placs respectivement en tte et en queue de la liste.
Exemple : CLASSE (0:N ETUDIANT (1:1 fiche-ETUDIANT,
0:N RESULTAT-COURS + 0:N RESULTAT-EXERCICE,
1:1 total-ETUDIANT))
d) Contraintes particulires aux fichiers COBOL
L'organisation de fichiers la plus frquemment utilise en COBOL est l'organisation squentielle indexe; il
s'agit de fichiers squentiels auxquels des cls d'accs, identifiantes ou non, sont ajoutes sous la forme d'in-
dex.
Exemple COBOL : FILE-CONTROL.
SELECT Fichier-Produits ASSIGN TO .....
ORGANIZATION IS INDEXED
RECORD KEY IS No-Produit OF Produit
ALTERNATE RECORD KEY IS
Nom-Produit OF Produit
..... .
SELECT Fichier-Commandes ASSIGN TO .....
RECORD KEY IS No-Ligne OF Ligne-Commande
No-Produit OF Ligne-Commande
WITH DUPLICATES
..... .
FILE SECTION.
FD Fichier-Produits.
01 Produit.
02 Nom-Type PIC X(6).
02 No-Produit PIC X(6).
02 Nom-Produit PIC X(24).
02 Qte-en-Stock PIC 9(5).
02 Prix-de-Vente PIC 9(5).
FD Fichier-Commandes.
01 Commande.
02 No-Commande PIC 9(5).
02 No-Client PIC X(5).
02 Date-Commande PIC 9(6).
66 No-Ligne RENAMES No-Commande OF Commande
THRU No-Produit OF Commande.
01 Ligne-Commande.
02 Qte-Commandee PIC 9(5).
66 No-Ligne RENAMES No-Commande OF Ligne-Commande
THRU No-Produit OF Ligne-Commande.
En COBOL, on doit tenir compte des contraintes suivantes :
1
il est obligatoire de dclarer une cl primaire identifiante (RECORD KEY); on peut dclarer un nombre
quelconque d'identifiants candidats (ALTERNATE RECORD KEY) ou de cls non identifiantes (ALTER-
NATE RECORD KEY WITH DUPLICATES);
toute cl d'accs est forme d'une zone contigu (la clause RENAMES THRU peut tre employe pour
dclarer le regroupement des champs composant la cl);
toute cl d'accs doit tre dclare de type alphanumrique (PICTURE X(n) ou dclaration assimile);
si le fichier contient des enregistrements de diffrents types, toute cl d'accs dclare dans un type d'enre-
gistrement existe automatiquement dans tous les autres types et y occupe la mme position par rapport au d-
but de l'enregistrement (il est donc inutile, dans la clause SELECT, de dclarer les cls NO-LIGNE et NO-
PRODUIT pour le type d'enregistrement COMMANDE; de plus, plac comme il l'est, le NO-CLIENT ne
peut tre index car quel est le contenu des positions correspondantes dans le type d'enregistrement
LIGNE-COMMANDE ?);
deux cls diffrentes (NO-LIGNE et NO-PRODUIT) ne peuvent pas commencer la mme position dans
l'enregistrement;
tout prfixe d'une cl d'accs (NO-COMMANDE dans NO-LIGNE) est une cl d'accs utilisable par l'ins-
truction START de positionnement dans le fichier;
toute cl d'accs (tout index) est galement une cl de tri en ordre croissant.
e) Ralisation des fonctions d'accs
Fonctions d'accs internes un fichier squentiel
Chemin d'accs (Types d'enregistrements)
Lors du traitement d'un fichier squentiel, il est ncessaire de pouvoir reconnatre le type de chaque (occur-
rence d') enregistrement. Un moyen simple est de prfixer chaque enregistrement par un champ convention-
nel contenant le nom (codifi) de son type.
Squence et cl d'accs
En pratique, il est souvent indispensable de dterminer l'ordre des enregistrements dans un fichier squentiel;
il faut pour cela dfinir une cl de tri globale, qui, si le fichier est index, peut galement servir de cl d'accs
identifiante.

1
Ces contraintes sont celles de la norme COBOL publie en 1985; la prochaine norme actuellement en prpa-
ration devrait tre moins restrictive.
Soit un fichier squentiel dcrit par le sous-schma arborescent SYSTEM(E
0
) E
1
... E
n
, et K
i
l'identifiant
du type d'enregistrement E
i
(i > 0).
Considrons, dans le sous-schma, le segment E
i
E
j
(i > 0, j = i + 1). Tout ensemble dcrit par ce type de
liaison comprend des enregistrements de diffrents types : ES
i
, E
j
, ER
i
, qui doivent se succder dans cet ordre.
On associera donc l'identifiant K
i
un code T
i
distinctif du type d'enregistrement, code pour lequel un jeu de
valeurs ordonnes pourrait tre {"1" pour le type ES
i
, "5" pour le type E
j
, "9" pour le type ER
i
}.
1
L'identi-
fiant global, commun tous les types d'enregistrements du fichier, sera form de la concatnation K =
K
1
,T
1
,K
2
,T
2
,...K
n
. Le champ K
j
, partie de l'identifiant global K, doit possder une valeur "inexistant" dans les
types ES
i
et ER
i
.
Exemple : sous-schma : SYSTEM FACTURE LIGNE-FACTURE
fichier : FACTURIER (0:N FACTURE comprenant (1:1 en-tte-FACTURE,
1:N LIGNE-FACTURE,
1:1 totaux-FACTURE))
Type n facture T n produit
FACT-S 350 1 0000
FACT-L 350 5 0236
FACT-L 350 5 0512
FACT-L 350 5 1014
FACT-R 350 9 0000
FACT-S 351 1 0000
FACT-L 351 5 0827
FACT-L 351 5 1212
FACT-R 351 9 0000
Fonctions d'accs inter-fichiers
Il est frquent que le propritaire et les membres d'un ensemble soient rpartis dans des fichiers diffrents.
Dans les exemples ci-dessous, c'est le cas de PRODUIT LIGNE-COMMANDE.
Chemin d'accs Epropritaire Amembre
Comment, partir d'une occurrence du type propritaire (PRODUIT), retrouver les occurrences (LIGNE-
COMMANDE) de l'ensemble correspondant ?
L'identifiant tranger (n produit) dans le type membre (LIGNE-COMMANDE) doit tre dfini comme cl
d'accs, et l'on effectuera une boucle de lecture par cette cl d'accs.
SELECT Fichier-Produits ASSIGN TO ..... .
SELECT Fichier-Commandes ASSIGN TO .....
RECORD KEY IS No-Ligne OF Ligne-Commande
No-Produit OF Ligne-Commande
WITH DUPLICATES
ACCESS MODE IS DYNAMIC
..... .

1
Un jeu de valeurs plus tendu doit tre prvu dans le cas d'un ensemble possdant des membres de plusieurs
types.
PROCEDURE DIVISION.
.....
MOVE No-Produit OF Produit
TO No-Produit OF Ligne-Commande
START Fichier-Commandes
KEY = No-Produit OF Ligne-Commande
NOT INVALID KEY
READ Fichier-Commandes NEXT RECORD
PERFORM UNTIL No-Produit OF Ligne-Commande
NOT = No-Produit OF Produit
... traiter la ligne retrouve ...
AT END MOVE HIGH-VALUE TO Ligne-Commande
END-READ
END-PERFORM
END-START
Chemin d'accs Amembre Epropritaire
Comment, partir d'une occurrence du type membre (LIGNE-COMMANDE), retrouver l'occurrence pro-
pritaire (PRODUIT) correspondante ?
L'identifiant propre (n produit) du type propritaire (PRODUIT) doit tre dfini comme cl d'accs, et l'on
effectuera une lecture slective par cette cl d'accs.
SELECT Fichier-Produits ASSIGN TO .....
Nom-Produit OF Produit
ACCESS MODE IS DYNAMIC
..... .
SELECT Fichier-Commandes ..... .
PROCEDURE DIVISION.
.....
MOVE No-Produit OF Ligne-Commande
TO No-Produit OF Produit
READ Fichier-Produits RECORD
KEY IS No-Produit OF Produits
INVALID KEY
... propritaire non trouv ...
END-READ
3.4. Mthode de construction des programmes
Diffrentes mthodes de construction des programmes se fondent sur l'ide que la structure des donnes dicte
la structure des programmes. Citons les Lois de Construction de Programmes de J.D. WARNIER, l'arbre
programmatique de M.Th. BERTINI et Y. TALLINEAU et les Principles of Program Design de M. JACK-
SON.
1

1
J.D. WARNIER : Les procdures de traitement et leurs donnes, d. d'Organisation, 1973; M.Th.
BERTINI, Y. TALLINEAU : Le COBOL structur, un modle de programmation, d. d'Informatique, 1974;
La mthode esquisse ici n'est rien d'autre qu'une adaptation de celle de JACKSON au modle logique en r-
seau. Nous allons l'exposer sur l'exemple d'un programme (trs simplifi) de facturation-livraison.
a) Graphe des accs aux donnes
E
E
E
E
S
S
S
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
nom reprsentant
COMMANDE
n commande
date commande
n client
FACTURE
n facture
date facture
total factur
n commande
n client
LIGNE COMMANDE
n commande
n produit
quantit commande
prix de vente
LIGNE FACTURE
n facture
n produit
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
SYSTEM
passant
objet
comprenant
command
comprenant
factur

M. JACKSON : Principles of Program Design, Academic Press, 1975. Les deux premires mthodes sont
fort proches et, en dpit des apparences graphiques, identiques pour ce qui concerne la structure des pro-
grammes.
1) Etablir le sous-schma des donnes utilis par le programme.
2) Indiquer l'usage des types d'enregistrements dans le programme :
E = entres (donnes lues ou reues),
S = sorties (donnes cres ou modifies).
3) Dfinir les chemins d'accs ( ) utiliss par le programme. On remarquera et on exploitera les pro-
prits suivantes :
certains types d'enregistrements font l'objet d'un accs exhaustif, c'est--dire que chaque occur-
rence de ces types est traite une et une seule fois; l'accs ces enregistrements se fait en emprun-
tant le chemin Epropritaire Amembre;
Exemple : SYSTEM COMMANDE LIGNE-COMMANDE
SYSTEM FACTURE LIGNE-FACTURE
d'autres types font l'objet d'un accs slectif, c'est--dire que certaines occurrences ne sont pas
traites ou sont traites plusieurs fois; l'accs ces enregistrements (ex. : CLIENT, PRODUIT) se
fait en empruntant le chemin Amembre Epropritaire.
4) Souligner les sous-schmas arborescents supportant un accs exhaustif Epropritaire Amembre.
Seuls, ces sous-schmas dterminent la structure du programme.
5) Reprer sur ces sous-schmas en accs exhaustif les correspondances entre toutes les collections d'en-
registrements en accs exhaustif. Sont correspondantes les collections entre lesquelles existe ou pourrait
exister une liaison dont les connectivits sont 1:1 ou 0:1 et pour lesquelles les squences d'accs sont compa-
tibles.
1
Exemple : COMMANDE FACTURE
LIGNE-COMMANDE LIGNE-FACTURE
b) Rgles du traitement
Avant de construire le programme, on rassemblera les rgles concernant tous les objets du sous-schma.

1
On trouvera dans l'ouvrage de M. JACKSON la solution aux ventuels conflits de structures, c'est--dire les
cas o une telle correspondance n'existe pas pour tous les types d'enregistrements en accs exhaustif.
c) Structure du programme
La figure ci-dessous illustre la structure du programme.
6<67(0
COMMANDE FACTURE CLIENT
LIGNE
COMMANDE
LIGNE
FACTURE
PRODUIT PRODUIT
CLOSL
RLD Produlr
HRITL Llgne-Tucrure
RLHRITL Produlr
HRITL Tln-Tucrure
RLD CIlenr
HRITL Tre-Tucrure
roruI-Jucrure 0
NLAT Llgne-Communde
OPLN
NLAT Communde
NLAT Llgne-Communde
COMPLTL
quunrlre-Ilvree
quunrlre-en-srocL - quunrlre-Ilvree
monrunr-Jucrure
roruI-Jucrure monrunr-Jucrure
LNTIL TIN LNSLMBLL Sysrem
LNTIL TIN LNSLMBLL Communde
Le rectangle central recouvre les sous-schmas arborescents en accs exhaustif; les types d'enregistrements
correspondants sont rapprochs en un seul point.
La partie gauche est relative aux donnes d'entre et la partie droite, aux donnes de sortie.
Les flches en pointill reprsentent les boucles embotes qui constituent la structure du programme. Sur ces
boucles sont rparties les oprations que le programme doit excuter sur les donnes; ces oprations sont
dduites des rgles rassembles l'tape prcdente.
Sur une flche de la partie gauche, les oprations utilisant les donnes sources des enregistrements propritai-
res, situs l'origine de cette flche; sur une flche de la partie droite, les oprations utilisant les donnes r-
sultats des enregistrements propritaires.
Noter le placement particulier des instructions READ NEXT de parcours (lecture) de la collection d'entre
dfinie par le sous-schma en accs exhaustif : une premire lecture avant toute autre opration, les suivantes
en fin de toute squence traitant une occurrence d'enregistrement. Justification : si la collection contient n
occurrences, on devra effectuer n+1 lectures (n enregistrements + 1 signal de fin de fichier).
Exemple COBOL :
IDENTIFICATION DIVISION.
PROGRAM-ID. Constitution-Factures.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT Fichier-Clients ASSIGN TO ..... INDEXED
RECORD KEY IS No-Client OF Client
ACCESS MODE IS DYNAMIC.
SELECT Fichier-Produits ASSIGN TO ..... INDEXED
ALTERNATE RECORD KEY IS Nom-Produit OF Produit
ACCESS MODE IS DYNAMIC.
SELECT Fichier-Commandes ASSIGN TO ..... SEQUENTIAL.
SELECT Fichier-Factures ASSIGN TO ..... SEQUENTIAL.
FILE SECTION.
FD Fichier-Clients.
01 Client.
02 Nom-Client PIC X(32).
02 Adresse-Client.
03 Rue-No PIC X(32).
03 No-Postal PIC X(4).
03 Localite PIC X(24).
FD Fichier-Produits.
01 Produit.
02 Qte-en-Stock PIC 9(5).
FD Fichier-Commandes.
01 Commande.
66 No-Ligne RENAMES No-Commande OF Commande
THRU No-Produit OF Commande.
01 Ligne-Commande.
02 Qte-Commandee PIC 9(5).
66 No-Ligne RENAMES No-Commande OF Ligne-Commande
THRU No-Produit OF Ligne-Commande.
FD Fichier-Factures.
01 Tete-Facture.
02 No-Facture PIC 9(5).
02 Nom-Client PIC X(32).
02 Adresse-Client.
03 Rue-No PIC X(32).
03 No-Postal PIC X(4).
03 Localite PIC X(24).
02 Date-Facture PIC 9(6).
01 Ligne-Facture.
02 Qte-Livree PIC 9(5).
02 Montant PIC 9(5).
66 No-Ligne RENAMES No-Facture OF Ligne-Facture
THRU No-Produit OF Ligne-Facture.
01 Fin-Facture.
02 Total PIC 9(5).
WORKING-STORAGE SECTION.
01 Dernier-No-Facture PIC 9(5).
77 Total-Facture PIC 9(5).
PROCEDURE DIVISION.
Traiter-Fichier.
OPEN INPUT Fichier-Commandes Fichier-Clients
I-O Fichier-Produits
OUTPUT Fichier-Factures
DISPLAY "Quel fut le dernier numro attribu ? "
ACCEPT Dernier-No-Facture
PERFORM Lire-Commande
PERFORM Traiter-Commande
UNTIL Nom-Type OF Tete-Commande = SPACES
DISPLAY "Voici le dernier numro attribu : "
Dernier-No-Facture
CLOSE Fichier-Factures Fichier-Commandes
Fichier-Produits Fichier-Clients
STOP RUN
.
Traiter-Commande.
MOVE CORRESPONDING Tete-Commande TO Tete-Facture
ADD 1 TO Dernier-No-Facture
MOVE Dernier-No-Facture TO No-Facture OF Tete-Facture
ACCEPT Date-Facture FROM DATE
MOVE No-Client OF Tete-Commande TO No-Client OF Client
READ Fichier-Clients RECORD
INVALID KEY ... client non trouv ... END-READ
MOVE CORRESPONDING Client TO Tete-Facture
MOVE "FACT-T" TO Nom-Type OF Tete-Facture
WRITE Tete-Facture IN Fichier-Factures
MOVE 0 TO Total-Facture
PERFORM Traiter-Ligne
UNTIL Nom-Type OF Ligne-Commande NOT = "COMM-L"
MOVE Total-Facture TO Total OF Fin-Facture
MOVE "FACT-F" TO Nom-Type OF Fin-Facture
WRITE Fin-Facture IN Fichier-Factures
.
Traiter-Ligne.
MOVE No-Produit OF Ligne-Commande
TO No-Produit OF Produit
READ Fichier-Produits RECORD KEY No-Produit OF Produit
INVALID KEY ... produit non trouv ... END-READ
MOVE CORRESPONDING Produit TO Ligne-Facture
IF Qte-Commandee <= Qte-en-Stock
THEN COMPUTE Qte-Livree = Qte-Commandee
ELSE COMPUTE Qte-Livree = Qte-en-Stock
END-IF
SUBTRACT Qte-Livree FROM Qte-en-Stock
COMPUTE Montant OF Ligne-Facture =
Prix-de-Vente OF Produit * Qte-Livree
ADD Montant OF Ligne-Facture TO Total-Facture
MOVE "FACT-L" TO Nom-Type OF Ligne-Facture
WRITE Ligne-Facture IN Fichier-Factures
REWRITE Produit
.
Lire-Commande.
AT END MOVE SPACES TO Nom-Type OF Tete-Commande END-READ
.
A. CLARINVAL Analyse Schma physique 5-1
Chapitre 5. Schma physique de la base de donnes
Aboutissement concret de la modlisation des donnes : la cration dune base de donnes ou dun ensemble
de fichiers.
Le schma logique des donnes stockes et des fonctions daccs doit tre coul dans les formes requises par
le SGBD particulier utilis. A cette description "programme" des fichiers ou de la base de donnes, on
donne le nom de schma physique.
Nous avons voqu la fin du chapitre prcdent la transformation du schma logique en schma physique
dun ensemble de fichiers COBOL.
1
Le prsent chapitre traite du schma physique des bases de donnes.
Nous y dcrivons sommairement les deux standards que respectent la plupart des bases de donnes actuelle-
ment en activit : le standard CODASYL pour les bases de donnes en rseau et le standard SQL pour les
bases de donnes relationnelles. Pour lquilibre de lexpos, aprs la description du schma proprement dit
de la base de donnes, nous illustrons les oprations disponibles pour laccs aux donnes.
Les paragraphes qui suivent ne constituent quune introduction aux systmes de bases de donnes,
bien insuffisante pour pouvoir utiliser ces systmes.

1
Cf. chapitre 4, section 3.
1. Les bases de donnes CODASYL
Les SGBD de la premire gnration furent conus, autour de 1970, pour donner des programmes d'applica-
tion l'accs des collections de donnes intgres. (A lpoque, on nimaginait pas un utilisateur devant un
cran en train dimproviser une recherche dans une base de donnes.)
Dans ces systmes, les oprations d'accs la base de donnes portent toujours sur un seul enregistrement
on retrouve l le principe de fonctionnement traditionnel des instructions daccs aux fichiers. Les diffrents
accs doivent tre combins par les moyens propres au langage hte (IF, PERFORM ... dans le cas de
COBOL). Le programmeur contrle ainsi la "navigation" d'un enregistrement l'autre dans la base de don-
nes. De l vient le qualificatif "navigationnel" par lequel on caractrise souvent ces SGBD.
La vogue des SGBD relationnels a eu pour effet que les SGBD navigationnels sont passs de mode.
Les SGBD navigationnels sont nanmoins encore employs sur les gros ordinateurs dentreprises
qui furent parmi les premires squiper informatiquement : banques, groupes industriels, grosses
administrations publiques ....
Nous prsentons ici le modle de SGBD standard labor, entre 1971 et 1978, par CODASYL ("COnference
on DAta SYstems Languages"), lorganisme crateur du langage COBOL. Ce modle s'appuie sur le modle
des donnes en rseau dfini par BACHMAN ds 1963
1
, modle que nous avons tudi au chapitre prc-
dent.
Un SGBD conforme au standard CODASYL est notamment caractris par l'existence de deux langages : un
DDL (Data Description Language) et un DML (Data Manipulation Language).
Le DML fournit les oprations d'accs aux donnes. Il a t conu comme une extension du langage COBOL.
Le DDL est utilis par l'administrateur de la base de donnes (DBA) pour enregistrer dans un dictionnaire
interne la base de donnes le schma de celle-ci. Ce langage dcrit la fois la structure maille (en rseau)
de la base de donnes et les dispositifs techniques (index, pointeurs, etc.) supportant les fonctions d'accs
souhaites.
Le DDL est galement employ pour dfinir les sous-schmas (vues externes) utiliss par les diffrents
groupes de programmes clients.
Les exemples donns dans le texte ci-aprs sont relatifs la base de donnes dont le schma logique
a t labor au chapitre 4. Remarquer que les identifiants trangers en ont t supprims et que les
noms de liaisons ont t rendus univoques.

1
CLIENT
n client
nom client
adresse client
catgorie
CL.PRIVE
CL.PROFESSIONNEL
n TVA
PROSPECTUS
type prospectus
REPRESENTANT
nom dlgu
rgion
chiffre d'affaires
COMMANDE
n commande
date commande
FACTURE
n facture
date facture
total factur
LIGNE COMMANDE
quantit commande
prix de vente
LIGNE FACTURE
quantit livre
montant factur
PRODUIT
n produit
<1> nom produit
quantit en stock
prix de vente
SYSTEM
Client-Commande
Facturation-Commande
Dtail-Commande
Produit-Commande
Dtail-Facture
Produit-Facture
Abonnements
Contacts
Client-Facture
Clientle
Reprsentation
Carnet-Commandes
Stock-Tarif
Facturier
1.1. Le langage de description de donnes (DDL)
a) Schma de la base de donnes
Fichiers (AREA)
Le contenu d'une base de donnes CODASYL est rparti dans une ou plusieurs zones (AREA), c'est--dire
dans un ou plusieurs fichiers.
Exemple : SCHEMA NAME Ventes.
AREA NAME Donnees-Permanentes.
AREA NAME Donnees-EnCours.
AREA NAME Donnees-Archivees.
Enregistrements (RECORD)
Chaque type d'enregistrement est nomm et dcrit dans le schma.
Pour chaque type d'enregistrement, la clause WITHIN areas dsigne le(s) fichier(s) dans le(s)quel(s) les
occurrences doivent tre stockes.
Si les occurrences d'un mme type d'enregistrement peuvent tre stockes dans diffrentes zones, on
devra, avant de traiter une nouvelle occurrence, indiquer par une variable du programme le nom
(AREA-ID) de la zone vise.
A tout enregistrement cr dans la base de donnes est automatiquement attribu un identifiant interne
(DATABASE KEY ou DB-KEY), qui est son adresse.
La clause LOCATION MODE, facultative, permet d'imposer au SGBD un mode de localisation :
la clause LOCATION MODE is CALC USING data-items indique un adressage calcul sur la
base de la cl (data-items) mentionne ce mode de localisation optimise l'accs par cl;
applique aux enregistrements membres d'un type d'ensemble, la clause LOCATION MODE is
VIA set SET indique que les membres de chaque ensemble de ce type doivent tre groups proxi-
mit de l'enregistrement propritaire ce mode de localisation optimise l'accs par les chemins dfi-
nis entre le propritaire et les membres d'un ensemble.
La description d'un type d'enregistrement comporte la dfinition des champs (data-items) qui le compo-
sent. Comme en COBOL, la dcomposition de l'enregistrement est reflte par des numros de niveau et les
donnes peuvent tre structures ou rptitives.
Exemples : RECORD NAME Ligne-Commande
LOCATION MODE VIA Detail-Commande SET
WITHIN Donnees-EnCours Donnees-Archivees
AREA-ID Nom-Zone.
02 Qte-Commandee TYPE DECIMAL 5.
02 Prix-de-Vente TYPE DECIMAL 5.
RECORD NAME Client
LOCATION MODE CALC USING No-Client
DUPLICATES NOT ALLOWED
WITHIN Donnees-Permanentes.
02 No-Client PICTURE "X(4)".
02 Nom-Client PICTURE "X(32)".
02 Adresse-Client.
03 Rue-No PICTURE "X(32)".
03 No-Postal PICTURE "X(4)".
03 Localite PICTURE "X(24)".
02 Categorie PICTURE "X".
02 No-TVA PICTURE "9(9)".
Ensembles (SET)
Un ensemble (SET) regroupe un enregistrement propritaire (OWNER) et les enregistrements membres
(MEMBER) associs cet enregistrement propritaire par un mme type de laison. Noter les particularits :
chaque type d'ensemble est dsign dans le schma par un nom univoque;
tout enregistrement doit tre membre d'au moins un ensemble; le propritaire de cet ensemble peut
tre l'enregistrement fictif SYSTEM;
un enregistrement ne peut tre membre de plus d'un ensemble du mme type;
tout ensemble est dtenu par exactement un propritaire et contient un nombre (0:N) quelconque
de membres;
le propritaire et les membres d'un ensemble ne peuvent pas tre du mme type; en d'autres ter-
mes, les liaisons ne sont pas cycliques;
les enregistrements membres d'un ensemble peuvent tre de diffrents types (ex.: RESULTAT-
EXAMEN et RESULTAT-EXERCICES).
La dfinition d'un ensemble signale si la liaison des membres au propritaire est obligatoire (MANDA-
TORY) ou facultative (OPTIONAL) et si le rattachement des membres l'ensemble est assur automati-
quement par le SGBD (AUTOMATIC) ou "manuellement" par le programme (MANUAL). Une liaison
obligatoire implique l'automaticit du rattachement (MANDATORY AUTOMATIC); la combinaison
MANDATORY MANUAL signifie que, s'il a t insr dans un ensemble, un enregistrement membre ne peut
plus en tre t.
La squence d'accs aux membres d'un ensemble doit tre pr-dtermine par la clause ORDER. Celle-ci
dfinit la position d'insertion d'un nouveau membre dans l'ensemble :
ordre chronologique (ORDER is LAST),
ordre chronologique invers (ORDER is FIRST),
ordre dfini par une cl de tri (ORDER is SORTED),
insertion devant (ORDER is PRIOR) ou derrire (ORDER is NEXT) le membre "courant" s-
lectionn par le programme.
Dans le cas d'un rangement tri, on peut demander au SGBD de construire pour chaque occurrence
d'ensemble un index qui acclrera les oprations de recherche et d'insertion (ORDER is SORTED
INDEXED). Cette technique est rserver aux ensembles contenant un grand nombre de membres,
particulirement les ensembles de premier niveau, dont l'enregistrement SYSTEM est propritaire.
Exemples : SET NAME Detail-Commande
ORDER LAST
OWNER Commande
MEMBER Ligne-Commande MANDATORY AUTOMATIC.
SET NAME Stock-Tarif
ORDER SORTED INDEXED
OWNER SYSTEM
MEMBER Produit MANDATORY AUTOMATIC
ASCENDING KEY No-Produit
DUPLICATES NOT ALLOWED.
SET NAME Contacts
ORDER FIRST
OWNER Representant
MEMBER Client OPTIONAL MANUAL.
Les chemins d'accs dans un ensemble sont matrialiss au moyen de pointeurs un pointeur "vers" un
enregistrement est une donne interne, une DB-KEY, contenant l'adresse de cet enregistrement. Deux techni-
ques sont disponibles pour l'agencement des pointeurs : les chanages (CHAIN, option par dfaut) et les ta-
bleaux de pointeurs (POINTER ARRAY).
Chanage. L'enregistrement propritaire d'un ensemble contient un pointeur vers le premier mem-
bre de cet ensemble; chaque enregistrement membre de l'ensemble, sauf le dernier, contient un
pointeur vers le membre suivant; le dernier membre contient un pointeur retournant l'enregistre-
ment propritaire (dans le cas d'un ensemble vide, l'enregistrement propritaire contient un pointeur
vers lui-mme). On peut demander d'ajouter un chanage inverse : chaque enregistrement pointe vers
le prcdent (LINKED TO PRIOR). Pour optimiser les accs par le chemin membre propritaire,
on peut galement demander d'attacher chaque membre un pointeur direct vers le propritaire
(LINKED TO OWNER).
e
a1 a2 a3
LINK TO OWNER
LINK TO PRIOR
CHAIN
a4
Exemple : SET NAME Produit-Commande
MODE CHAIN
ORDER LAST
OWNER Produit
MEMBER Ligne-Commande MANDATORY AUTOMATIC
LINKED TO OWNER.
Tableau de pointeurs. La liste des pointeurs vers les membres d'un ensemble est directement atta-
che l'enregistrement propritaire. De plus, comme dans l'option LINKED TO OWNER, chaque
membre contient un pointeur direct vers le propritaire.
Cls d'accs et identifiants
La cl servant calculer l'emplacement d'un enregistrement (clause LOCATION MODE is CALC USING
cl) et la cl de tri dfinie pour les membres d'un ensemble peuvent servir de cls d'accs. En outre, pour
chaque type d'ensemble, on peut dfinir un nombre quelconque de cls pour la recherche des membres
(SEARCH KEY).
L'option DUPLICATES NOT ALLOWED est employe pour rendre identifiante n'importe quelle cl d'accs.
Exemple : SET NAME Stock-Tarif
OWNER SYSTEM
ASCENDING KEY No-Produit
DUPLICATES NOT ALLOWED
SEARCH KEY Nom-Produit
DUPLICATES NOT ALLOWED.
Exemple rcapitulatif
SCHEMA NAME Ventes.
AREA NAME Donnees-Permanentes.
AREA NAME Donnees-EnCours.
AREA NAME Donnees-Archivees.
RECORD NAME Representant
LOCATION MODE CALC USING Nom-Delegue DUPLICATES NOT ALLOWED
02 Nom-Delegue PICTURE "X(32)".
02 Region PICTURE "X(8)".
02 Ch-Affaires TYPE DECIMAL 9.
RECORD NAME Client
LOCATION MODE CALC USING No-Client DUPLICATES NOT ALLOWED
02 No-Client PICTURE "X(4)".
02 Nom-Client PICTURE "X(32)".
02 Adresse-Client.
03 Rue-No PICTURE "X(32)".
03 No-Postal PICTURE "X(4)".
03 Localite PICTURE "X(24)".
02 Categorie PICTURE "X".
02 No-TVA PICTURE "9(9)".
RECORD NAME Produit
02 No-Produit PICTURE "X(6)".
02 Nom-Produit PICTURE "X(24)".
02 Qte-en-Stock TYPE DECIMAL 5.
02 Prix-de-Vente TYPE DECIMAL 5.
RECORD NAME Commande
LOCATION MODE CALC USING No-Commande DUPLICATES NOT ALLOWED
WITHIN Donnees-EnCours Donnees-Archivees AREA-ID Nom-Zone.
02 No-Commande PICTURE "9(5)".
02 Date-Commande PICTURE "9(6)".
RECORD NAME Ligne-Commande
LOCATION MODE VIA Detail-Commande SET
WITHIN Donnees-EnCours Donnees-Archivees AREA-ID Nom-Zone.
02 Qte-Commandee TYPE DECIMAL 5.
02 Prix-de-Vente SOURCE Prix-de-Vente
OF OWNER OF Produit-Commande.
SET NAME Representation
ORDER LAST
OWNER SYSTEM
MEMBER Representant MANDATORY AUTOMATIC
SEARCH KEY Nom-Delegue.
SET NAME Clientele
OWNER SYSTEM
MEMBER Client MANDATORY AUTOMATIC
ASCENDING KEY No-Client DUPLICATES NOT ALLOWED
SEARCH KEY Nom-Client.
SET NAME Stock-Tarif
OWNER SYSTEM
ASCENDING KEY No-Produit DUPLICATES NOT ALLOWED
SEARCH KEY Nom-Produit DUPLICATES NOT ALLOWED.
SET NAME Carnet-Commandes
ORDER FIRST
OWNER SYSTEM
MEMBER Commande MANDATORY AUTOMATIC.
SET NAME Contacts
ORDER FIRST
OWNER Representant
MEMBER Client OPTIONAL MANUAL.
SET NAME Client-Commande
ORDER LAST
OWNER Client
MEMBER Commande MANDATORY AUTOMATIC.
SET NAME Detail-Commande
ORDER LAST
OWNER Commande
MEMBER Ligne-Commande MANDATORY AUTOMATIC.
SET NAME Produit-Commande
ORDER FIRST
OWNER Produit
MEMBER Ligne-Commande MANDATORY AUTOMATIC
LINKED TO OWNER.
........
b) Sous-schmas
Un sous-schma dcrit la partie de la base de donnes accessible un programme. Il en numre les zones
(fichiers), les types d'enregistrements, les types d'ensembles et les attributs. A l'instar du schma dont il d-
rive, tout sous-schma est catalogu dans le dictionnaire de la base de donnes.
Pour chaque type d'enregistrement dfini dans le sous-schma, une zone de mmoire tampon est rserve
l'intrieur du programme (analogie avec la FILE SECTION d'un programme COBOL).
Exemple : les lignes ci-dessous incorporent au programme COBOL la dfinition d'un sous-schma
DATA DIVISION.
SCHEMA SECTION.
INVOKE SUB-SCHEMA Livraison-Facturation OF SCHEMA Ventes.
1.2. Le langage de manipulation des donnes (DML)
a) Contrle de l'accs aux fichiers : OPEN, CLOSE
Un fichier (AREA) doit tre "ouvert" pour qu'on puisse y localiser des enregistrements.
L'instruction OPEN possde diffrentes formes et elle permet au programme de signaler au serveur de la base
de donnes s'il veut procder des mises jour (UPDATE) ou seulement des consultations (RETRIE-
VAL); elle peut aussi demander au serveur de protger le fichier ouvert contre tout accs concurrent manant
d'un autre programme (EXCLUSIVE) ou seulement contre les mises jour concurrentes (PROTECTED).
Aprs son utilisation, tout fichier doit tre libr par une instruction CLOSE.
Exemples : OPEN AREA Donnees-Permanentes
USAGE-MODE PROTECTED RETRIEVAL.
OPEN AREA Donnees-Archivees
USAGE-MODE EXCLUSIVE UPDATE.
CLOSE ALL.
b) Les mcanismes de navigation
Enregistrements courants
Avant de pouvoir tre manipul, tout enregistrement doit tre localis, par une instruction FIND. Cette ins-
truction mmorise dans diffrents registres l'identifiantadresse (DB-KEY) de l'enregistrement trouv.
A tout moment, en effet, le SGBD conserve l'adresse (DB-KEY) du dernier enregistrement trait (trouv ou
insr) enregistrement qualifi de courant dans chacune des catgories suivantes :
dans chaque fichier (AREA) du sous-schma,
pour chaque type d'enregistrement (RECORD) du sous-schma,
pour chaque type d'ensemble (SET) du sous-schma,
pour le programme (run-unit) = enregistrement courant le plus rcent de tous.
A tout moment, ces registres dcrivent le contexte dans lequel se droulera l'opration suivante.
Localisation d'un enregistrement : FIND
L'instruction FIND possde de nombreuses formes. Nous en illustrons ici quelques-unes :
localisation par la cl d'un enregistrement adresse calcule :
exemple : * garnir la cl :
ACCEPT No-Client
* localiser l'enregistrement :
FIND Client
localisation du premier membre d'un ensemble :
exemple : * le Client propritaire tant courant,
* localiser la premire Commande :
FIND FIRST Commande OF Client-Commande SET
localisation du membre suivant d'un ensemble :
exemple : * la Commande propritaire tant courante
* ou une Ligne-Commande tant dj courante,
* localiser la Ligne-Commande suivante :
FIND NEXT Ligne-Commande OF Detail-Commande SET
localisation du propritaire d'un ensemble :
exemple : * une Ligne-Commande tant courante,
* localiser le Produit propritaire :
FIND OWNER OF Produit-Commande SET
Test de l'appartenance d'un enregistrement un ensemble
Il est possible de tester l'appartenance de l'enregistrement courant le plus rcent un ensemble. Cette question
est utile dans le cas des membres facultatifs.
Exemple : le Client courant est-il contact par un reprsentant ?
IF RECORD [NOT] MEMBER OF Contacts
THEN SET ........
Lecture d'un enregistrement : GET
L'instruction GET transfre dans la zone de mmoire tampon accessible au programme les donnes de l'enre-
gistrement courant le plus rcent. On peut transfrer toutes les donnes de l'enregistrement ou seulement cer-
taines.
Exemple : * aprs avoir localis un enregistrement Client ...
* transfert du contenu intgral de l'enregistrement :
GET Client
* transfert de donnes slectionnes :
GET Client; Nom-Client Adresse-Client
c) Mise jour des donnes
Cration/Modification d'un enregistrement : STORE, MODIFY
Avant de stocker (STORE) un nouvel enregistrement dans la base de donnes, on doit :
ventuellement, slectionner le fichier (AREA) destinataire;
rendre courants les ensembles dans lesquels l'enregistrement doit tre insr automatiquement;
garnir les champs qui le composent avec les valeurs adquates.
Par ailleurs, l'instruction MODIFY permet de changer la valeur des champs de l'enregistrement courant le
plus rcent.
Exemple : cration d'une commande :
* slectionner le fichier destinataire :
MOVE "Donnees-EnCours" TO Nom-Zone
* localiser le Client propritaire :
DISPLAY "n Client : " NO ADVANCING ACCEPT No-Client
FIND Client
* rendre courant l'ensemble Carnet-Commandes
* en localisant la Commande la plus rcente
* (la squence de tri est l'ordre chronologique invers) :
FIND FIRST Commande OF Carnet-Commandes SET
* prendre le dernier numro de commande attribu :
GET Commande; No-Commande
* crer l'enregistrement Commande :
ADD 1 TO No-Commande
ACCEPT Date-Commande FROM DATE
* stocker l'enregistrement Commande :
STORE Commande
* localiser le Produit propritaire :
DISPLAY "n Produit : " NO ADVANCING ACCEPT No-Produit
FIND Produit USING No-Produit
* crer un enregistrement Ligne-Commande :
DISPLAY "quantit : " NO ADVANCING ACCEPT Qte-Commandee
* ajuster le stock du Produit courant :
SUBTRACT Qte-Commandee FROM Qte-en-Stock
MODIFY Produit; Qte-en-Stock
* stocker l'enregistrement Ligne-Commande :
STORE Ligne-Commande
........
Inclusion/Retrait d'un membre dans un ensemble : INSERT, REMOVE
L'instruction INSERT insre l'enregistrement courant le plus rcent dans un ensemble dont il est membre fa-
cultatif (OPTIONAL) ou MANUAL. Le membre est insr la position dtermine par la clause ORDER.
L'instruction REMOVE enlve l'enregistrement courant le plus rcent d'un ensemble dont il est membre fa-
cultatif (OPTIONAL).
Exemples : STORE Client
FIND Representant .....
INSERT Client INTO Contacts
........
FIND Client .....
REMOVE Client FROM Contacts
Suppression d'un enregistrement : DELETE
L'instruction DELETE supprime l'enregistrement courant le plus rcent. Elle possde diffrentes formes :
suppression limite aux enregistrements qui ne sont propritaires d'aucun ensemble,
suppression en cascade,
suppression slective,
.....
2. Les bases de donnes relationnelles
Dans les annes 80, une deuxime gnration de SGBD s'est impose, au dtriment des prcdents. Fonds
sur le modle relationnel de CODD
1
, ces systmes, aujourdhui les plus rpandus, ont l'avantage principal de
donner l'utilisateur un langage d'interrogation dclaratif plutt que navigationnel : l'utilisateur rdige une
expression dclarant le rsultat qu'il attend, et le SGBD lui-mme en dduit l'algorithme (la squence d'opra-
tions) excuter. Au contraire des instructions des langages prcdents, qui manipulent toujours une occur-
rence d'enregistrement, une requte relationnelle manipule des ensembles ou collections d'occurrences; ds
lors, elle n'a pas pour elle-mme besoin d'tre "habille" d'un programme plus toff. Un tel langage est prin-
cipalement destin aux utilisateurs finals d'un interprteur de requtes.
Le langage SQL ("Structured Query Language") est devenu le langage standard pour la gestion des bases de
donnes de ce type.
Aprs une prsentation succincte de la thorie du modle relationnel, nous montrerons comment, en langage
SQL, la base de donnes est dfinie dans un dictionnaire de donnes, puis comment on la manipule.
AVERTISSEMENT
Nous avons prfr ne pas encore tenir compte des apports du paradigme Objet la norme SQL3 (types de
donnes abstraits et sous-types, principalement). SQL3 est trop rcent pour que lusage de ses nouvelles pos-
sibilits soit dj gnralis. Et il est encore ncessaire dexpliquer comment transposer en SQL "ancien" les
spcifications de lanalyse.
2.1. Le modle relationnel des donnes
En 1970, l'Amricain E. CODD dfinissait un modle relationnel pour la reprsentation (le stockage) et la
manipulation des donnes dans une base de donnes. Ce modle constitue une vritable thorie mathmati-
que, comportant principalement les aspects suivants :
la prsentation des donnes sous la forme de relations au sens mathmatique;
une algbre relationnelle pour leur manipulation;
une thorie de la normalisation pour leur modlisation.
2
Cette thorie, non seulement fonde les SGBD qui s'en rclament expressment, mais elle inspire dornavant
tous ceux qui s'occupent de modlisation des donnes.
a) Les relations
Appelons domaine un ensemble de valeurs. Une relation (en anglais : "relation"
3
) est un sous-ensemble du
produit cartsien dfini sur une liste de domaines.

1
2
E. CODD : Further Normalization of the Database Relational Model in RUSTIN (ed) : Data Base Sys-
tems, Prentice-Hall, 1972.
3
Et non pas "relationship", que nous avons traduit par association.
Exemple : domaines : NOM = {Citron, Ford, Renault}
NUMERO = {ABC123, ABC456, DEF123, DEF456}
produit : ABC123 Citron
ABC123 Ford
ABC123 Renault
ABC456 Citron
ABC456 Ford
ABC456 Renault
DEF123 Citron
DEF123 Ford
DEF123 Renault
DEF456 Citron
DEF456 Ford
DEF456 Renault
relation A : ABC123 Citron
ABC456 Renault
DEF123 Renault
relation B : ABC123 Citron
ABC456 Renault
DEF456 Ford
Ainsi qu'on le voit cet exemple, une relation se reprsente aisment sous la forme d'un tableau double en-
tre, auquel on a donn le nom de table.
Chaque ligne reprsente un n-uplet (lment) de la relation. Conformment la thorie ensembliste, tout n-
uplet de valeurs est unique dans une relation; en d'autres termes, il n'existe pas deux lignes identiques dans
une table. On appelle cardinalit d'une relation le nombre de ses n-uplets.
Chaque colonne reprsente un attribut de la relation. Plusieurs attributs d'une relation peuvent prendre leurs
valeurs dans un mme domaine. On appelle degr d'une relation le nombre de ses attributs.
Exemple : domaines : NOM = {Citron, Clio, Escort, Fiesta, Ford,
Mondeo, Renault, Twingo, Visa, Xantia}
NUMERO = {ABC123, ABC456, DEF123, DEF456}
relation A : ABC123 Citron Visa
ABC456 Renault Clio
DEF123 Renault Twingo
relation B : ABC123 Citron Xantia
ABC456 Renault Clio
DEF123 Ford Escort
DEF456 Ford Mondeo
La dfinition d'un type de relation comporte les mentions suivantes :
le nom de la relation ou nom de table,
le nom de chaque attribut ou colonne,
le nom du domaine de valeurs de chaque attribut.
Exemple : VOITURE (PLAQUE : numro, MARQUE : nom, MODELE : nom)
Dans une base de donnes relationnelle, toutes les donnes sont stockes dans des tables ou relations.
Exemple : le schma logique labor au chapitre 4 devient :
(entre crochets, un attribut pouvant prendre la valeur "inexistant")
REPRESENTANT (nom-dlgu, rgion, chiffre-d-affaires)
CLIENT (n-client, nom-client, adresse-client,
catgorie-client, [no-TVA], [nom-dlgu])
ABONNEMENT (n-client, type-prospectus)
PRODUIT (n-produit, nom-produit, quantit-en-stock, prix-de-vente, taux-TVA)
COMMANDE (n-commande, n-client, date-commande)
LIGNE-COMMANDE (n-commande, n-produit, quantit-commande)
FACTURE (n-facture, n-commande, date-facture, total-factur)
LIGNE-FACTURE (n-facture, n-produit, quantit-livre, montant-factur)
dans cet exemple, on n'a pas indiqu les domaines de valeurs des attributs
Remarques
En principe, chaque type d'enregistrement dfini dans le schma logique des donnes deviendra, comme dans
l'exemple ci-dessus, un type de relation.
Une table est assimilable un fichier squentiel (COBOL, par exemple) contenant des enregistrements d'un
seul type.
b) Identification et Normalisation
En guise d'outils d'analyse, permettant de dcouvrir les types de relations dfinir dans une base de donnes,
CODD a dfini (1) des rgles de normalisation ou formes normales, (2) le concept de dpendance fonction-
nelle sur lequel elles s'appuient, (3) un traitement mathmatique de ces concepts.
Une prsentation plus intuitive de ces concepts a t donne aux chapitres 3 et 4. Nous la compltons ici de
quelques remarques.
Puisque tous les n-uplets d'une relation sont diffrents, toute relation possde, par dfinition, un identifiant :
elle-mme. Dans la ralit, les identifiants minimaux sont habituellement rduits quelques attributs ou co-
lonnes de la table. Les liens logiques entre tables s'oprent par le biais des identifiants trangers imports.
Exemple : dans le schma ci-dessus,
les identifiants primaires (minimaux) sont souligns,
les identifiants trangers sont en italiques.
Une relation est dite normalise ds lors qu'elle se trouve en premire forme normale (1NF), c'est--dire si
tous ses attributs sont la fois lmentaires (non structurs) et simples (non rptitifs). Cette rgle doit tre
obligatoirement respecte, car elle fonde le mcanisme de dsignation des attributs dans les requtes du lan-
gage relationnel : un attribut (lmentaire et simple) est compltement dsign par le seul moyen de son nom
qualifi par le nom de la relation : attribut de relation (ou, en langage SQL : table.colonne).
c) L'algbre relationnelle (pour mmoire)
Les oprations de l'algbre relationnelle sont mises en oeuvre dans les requtes formules dans le langage de
manipulation des donnes.
2.2. Le dictionnaire des donnes (SQL)
Le schma de la base de donnes est enregistr dans un dictionnaire, que la norme SQL appelle Information
Schema. Ce dictionnaire fait partie de la base de donnes elle-mme;
1
il est consult par l'interprteur des
commandes de manipulation des donnes.
Le schma d'une base de donnes contient principalement la dfinition de domaines de valeurs, la dfinition
des tables, la dfinition des contraintes d'intgrit, appeles assertions en SQL. Il peut aussi contenir la dfi-
nition de vues particulires et diversifies sur l'une ou l'autre tables, ainsi que des procdures de mise jour
automatique des donnes redondantes ou drivables.
Remarque
Toutes les contraintes d'intgrit dfinies dans le schma sont vrifies automatiquement par le
SGBD lors des oprations de mise jour. Toute contrainte peut avoir un nom, que les messages d'er-
reurs du SGBD utiliseront pour identifier chaque contrainte viole.
a) Dfinition des domaines
Les domaines de valeurs servent dcrire les colonnes dans les tables.
La dfinition d'un domaine mentionne son nom, le type de donnes dont il constitue un sous-ensemble, l'ven-
tuelle valeur par dfaut, une contrainte d'intgrit attache au domaine.
La valeur par dfaut, utilise par le SGBD lorsque l'utilisateur cre un n-uplet sans fournir de valeur pour
une colonne, doit tre une constante appartenant au type indiqu ou la valeur spciale NULL (inconnu).
Une contrainte de domaine est un prdicat quelconque restreignant l'ensemble des valeurs admises dans ce
domaine : elle dfinit le domaine comme un sous-ensemble du type de donnes. A moins que soit spcifie
une contrainte NOT NULL, tout domaine admet la valeur "inconnu".
Format : CREATE DOMAIN nom [AS] type
[ DEFAULT constante ]
[ [ CONSTRAINT nom_de_contrainte ] CHECK (prdicat) ] ;
dans une contrainte de domaine,
le mot cl VALUE reprsente toute valeur non NULL du domaine
Exemples : CREATE DOMAIN Code_Sexe AS CHARACTER(1) DEFAULT NULL
CHECK (VALUE IN ('M', 'F'));
CREATE DOMAIN Adresse_Postale AS CHARACTER(80);
CREATE DOMAIN Quantite AS INTEGER DEFAULT 0;
CREATE DOMAIN Prix AS NUMERIC(10)
CONSTRAINT "prix non nul" CHECK (VALUE > 0);

1
La norme SQL dfinit elle-mme les tables composant l'Information Schema d'une base de donnes. Exem-
ples : DOMAINS, TABLES, COLUMNS, COLUMN_DOMAIN_USAGE ...
b) Dfinition des tables
La dfinition d'une table comporte le nom de la table, la dfinition des colonnes, la dfinition des contraintes
propres cette table.
Puisque le nom d'une colonne est qualifiable par le nom de la table dont elle fait partie (table.colonne), des
colonnes appartenant diffrentes tables peuvent avoir le mme nom. Chaque colonne est dcrite par son
domaine de valeurs. Si celui-ci a t rpertori par une commande CREATE DOMAIN, il suffit d'en mention-
ner le nom; sinon, la dfinition du domaine est faite localement.
Les contraintes qui peuvent tre dfinies sur une table sont les suivantes :
[ CONSTRAINT nom_de_contrainte ]
PRIMARY KEY [(colonne, ...)] = identifiant primaire (automatiquement NOT NULL)
UNIQUE [(colonne, ...)] = identifiant candidat (valeurs en double interdites)
FOREIGN KEY [(colonne, ...)] ... = identifiant tranger (intgrit rfrentielle)
CHECK (prdicat) = restriction portant sur des colonnes de la table
Les contraintes sont dfinies la suite des colonnes. Cependant, par simplification, les contraintes portant sur
une seule colonne peuvent tre incorpores la dfinition de cette colonne.
Par dfinition, toute table possde un identifiant primaire; si la contrainte PRIMARY KEY n'est pas exprime,
une contrainte PRIMARY KEY (toutes_les_colonnes) est implicitement dfinie.
Format : CREATE TABLE nom_de_table ( dfinition_de_colonne, ...
dfinition_de_contrainte, ... ) ;
Exemple : le schma donn plus haut en exemple sera cr par les commandes suivantes :
CREATE TABLE representant
( nom_delegue CHARACTER(30),
region CHARACTER(12),
chiffre_d_affaires Prix,
CONSTRAINT "id. reprsentant"
PRIMARY KEY (nom_delegue),
CONSTRAINT "rgion obligatoire"
CHECK (region is NOT NULL) );
CREATE TABLE client
( no_client CHARACTER(5),
nom_client CHARACTER(30),
adresse_client Adresse_Postale,
categorie_client NUMERIC(1) DEFAULT NULL,
no_TVA DECIMAL(9),
nom_delegue CHARACTER(30) DEFAULT NULL,
CONSTRAINT "id. client" PRIMARY KEY (no_client),
CONSTRAINT "nom de client obligatoire"
CHECK (nom_client IS NOT NULL),
CONSTRAINT "client -> reprsentant"
FOREIGN KEY (nom_delegue)
REFERENCES representant -- Cf. note, infra
ON UPDATE CASCADE
ON DELETE SET NULL );
CREATE TABLE abonnement
( no_client CHARACTER(5),
type_prospectus CHARACTER(3),
PRIMARY KEY (no_client, type_prospectus),
FOREIGN KEY (no_client) REFERENCES client
ON DELETE CASCADE );
CREATE TABLE produit
( no_produit CHARACTER(6)
CONSTRAINT "id. produit" PRIMARY KEY,
nom_produit CHARACTER(24)
CONSTRAINT "id. (nom) produit" UNIQUE NOT NULL,
quantite_en_stock Quantite
CONSTRAINT "quantit en stock >= 0"
CHECK (quantite_en_stock >= 0),
prix_de_vente Prix,
taux_TVA NUMERIC(3,3) );
CREATE TABLE commande
( no_commande NUMERIC(5) PRIMARY KEY,
no_client CHARACTER(5) NOT NULL REFERENCES client,
date_commande DATE DEFAULT CURRENT_DATE NOT NULL );
CREATE TABLE ligne_commande
( no_commande NUMERIC(5)
REFERENCES commande ON DELETE CASCADE,
no_produit CHARACTER(6)
CONSTRAINT "produit command" -- Cf. note, infra
REFERENCES produit ON UPDATE CASCADE
ON DELETE NO ACTION,
quantite_commandee Quantite NOT NULL
CONSTRAINT "quantit commande > 0"
CHECK (quantite_commandee > 0),
PRIMARY KEY (no_commande, no_produit) );
CREATE TABLE facture
( no_facture NUMERIC(5) PRIMARY KEY,
no_commande NUMERIC(5) UNIQUE
REFERENCES commande ON DELETE SET NULL,
date_facture DATE DEFAULT CURRENT_DATE NOT NULL,
total_facture Prix );
CREATE TABLE ligne_facture
( no_facture NUMERIC(5)
REFERENCES facture ON DELETE CASCADE,
CONSTRAINT "produit livr"
REFERENCES produit ON UPDATE CASCADE,
quantite_livree Quantite NOT NULL
CONSTRAINT "quantit livre > 0"
CHECK (quantite_livree > 0),
montant_facture Prix,
PRIMARY KEY (no_facture, no_produit) );
Note sur les contraintes d'intgrit rfrentielle
Le format complet d'une contrainte d'intgrit rfrentielle est le suivant :
[ CONSTRAINT nom_de_contrainte ]
[ FOREIGN KEY (colonne_rfrenante, ...) ]
REFERENCES table [(colonne_rfrence, ...) ]
[ ON UPDATE action ]
[ ON DELETE action ]
action : CASCADE | SET NULL | SET DEFAULT | NO ACTION
La clause REFERENCES mentionne les colonnes de la table rfrence qui, dans l'ordre, doivent correspondre
aux colonnes dont est compos l'identifiant tranger (FOREIGN KEY); dans la table rfrence, les colonnes
en cause doivent, dans le mme ordre, former un identifiant primaire (PRIMARY KEY) ou candidat
(UNIQUE). Dans le cas de l'identifiant primaire, qui est le plus frquent, on peut omettre la liste des colonnes
rfrences.
La dfinition d'une contrainte d'intgrit rfrentielle indique quelle action le SGBD doit automatiquement
entreprendre sur la table rfrenante lorsque, dans la table rfrence, l'identifiant concern est modifi
(UPDATE) ou supprim (DELETE) :
ON UPDATE CASCADE = remplacer toutes les rfrences par la nouvelle valeur de l'identifiant;
ON DELETE CASCADE = supprimer en cascade toutes les occurrences rfrenantes;
ON UPDATE|DELETE SET NULL = mettre les rfrences la valeur NULL ("inconnu");
ON UPDATE|DELETE SET DEFAULT = donner aux colonnes rfrenantes leur valeur par dfaut;
ON UPDATE|DELETE NO ACTION = refuser la mise jour de la table rfrence;
on obtient le mme effet si l'option ON n'est pas explicite.
c) Dfinition des assertions
Une assertion est une contrainte qui n'est pas attache une table particulire; normalement, elle implique
plusieurs tables.
Format : CREATE ASSERTION nom_de_contrainte
CHECK (prdicat) ;
Exemple : CREATE ASSERTION "commande non vide"
CHECK (NOT EXISTS -- pas de no_commande sans lignes
(SELECT no_commande FROM commande
EXCEPT
SELECT DISTINCT no_commande FROM ligne_commande))
INITIALLY DEFERRED; -- Cf. note, infra
la diffrence (EXCEPT) entre les deux ensembles
{commande.no_commande} - {ligne_commande.no_commande}
doit tre un ensemble vide (NOT EXISTS)
Note sur les transactions et la vrification des contraintes
Une base de donnes se trouve dans un tat cohrent lorsqu'elle est conforme aux contraintes d'intgrit dfi-
nies.
On appelle transaction une suite d'oprations de consultation et/ou mise jour de la base de donnes qui,
partant d'un tat cohrent de celle-ci, la restitue dans un tat cohrent. Entre les deux instants de dbut et fin
d'une transaction, l'tat de la base de donnes peut tre non conforme. (Cette incohrence temporaire est in-
dispensable pour pouvoir enregistrer l'en-tte d'une commande avant qu'existe la moindre ligne la concer-
nant.)
1
Exemple : INSERT INTO commande (no_commande, no_client)
VALUES (315,4); -- date : DEFAULT = CURRENT_DATE
INSERT INTO ligne_commande
VALUES (315,7,1),
(315,8,1),
(315,3,2);
COMMIT; -- confirmation clturant la transaction
-- d'enregistrement de la commande 315
La vrification d'une contrainte peut tre immdiate, c'est--dire effectue immdiatement avant l'excution de
toute opration de mise jour susceptible de la violer; elle peut aussi tre diffre jusqu' l'excution de l'ins-
truction COMMIT qui clture la transaction de mise jour. En SQL, la dfinition de toute contrainte peut se
terminer par une option indiquant le dispositif enclench au dmarrage de toute transaction : INITIALLY
IMMEDIATE (par dfaut) ou INITIALLY DEFERRED.
2
(La seconde option s'impose pour la contrainte
"commande non vide" dfinie ci-dessus.)
d) Mise jour automatique des donnes drivables
Il nest pas rare quune base de donnes contienne des donnes redondantes, autres que les cls trangres.
Cest le rsultat des dnormalisations effectues en vue doptimiser laccs aux donnes.
3
Exemples : propagation parent ==> enfants
adresse du client recopie dans len-tte de facture
une modification dadresse doit tre rpercute dans toutes les factures du client
drivation parent(s) ==> enfants
montant factur inscrit dans chaque ligne de facture
une modification de prix au tarif doit entraner un nouveau calcul des montants facturs

1
La gestion des transactions possde une seconde utilit. Telles que nous les avons dfinies ici, les transac-
tions garantissent la cohrence objective de la base de donnes; elles ne garantissent pas la cohrence de la
perception qu'en ont les utilisateurs. Retenons l'hypothse d'un accs simultan de plusieurs utilisateurs ou
programmes la base de donnes. Pendant que l'utilisateur A enregistre un bon de commande, tout autre utili-
sateur B qui consulterait ou mettrait jour les stocks, aurait en ralit accs des informations incertaines. La
solution consiste limiter temporairement jusqu' la fin de la transaction , et automatiquement, les pos-
sibilits d'action et donc d'interfrence des autres utilisateurs : inconfort momentan, mais garantie d'exacti-
tude des donnes.
2
Pour le SGBD, il est videmment plus simple de tester une contrainte a priori et de ne pas entreprendre la
mise jour qui la violerait, que de devoir dfaire une ou plusieurs oprations de mise jour qui auraient viol
une contrainte teste a posteriori. C'est pourquoi, en SQL, la vrification des contraintes est, par dfaut, im-
mdiate.
3
Cf. chapitre 4.
rcapitulation enfant(s) ==> parent
total factur inscrit dans chaque facture
la modification ou la suppression dune ligne de facture implique un ajustement du total
La possibilit existe dattacher une opration de mise jour une opration de mise jour complmentaire
des donnes drives, dclenche ("triggered") automatiquement. Pour cela, on enregistre dans le diction-
naire de la base de donnes une gchette ("trigger").
1
Format : CREATE TRIGGER nom_de_gchette ON table
vnement_dclencheur
actions_dclenches ;
vnement_dclencheur : avant_aprs opration_dclenchante
avant_aprs : BEFORE | AFTER
opration_dclenchante : INSERT ON table |
DELETE ON table |
UPDATE [ OF colonne, ... ] ON table
[ REFERENCING OLD AS alias NEW AS alias ]
Linsertion, la suppression ou la modification (des colonnes indiques) dune ligne dans la table est
considre comme un vnement dclencheur; la prposition BEFORE ou AFTER indique si les actions d-
clenches doivent tre excutes avant ou aprs la mise jour dclenchante.
Les actions dclenches ont accs aux donnes prsentes dans la base de donnes. On crira donc habi-
tuellement AFTER INSERT et BEFORE DELETE.
Dans le cas dune modification par UPDATE, on doit souvent rfrencer la fois les anciennes et les nou-
velles valeurs des colonnes de la table. Les alias attribus par la clause REFERENCING permettent de les
distinguer : pour chaque alias est cre une copie temporaire des valeurs soit anciennes, soit nouvelles.
Habituellement, on dclarera un seul alias : OLD avec lvnement AFTER UPDATE, NEW avec lvne-
ment BEFORE UPDATE.
actions_dclenches : [ FOR EACH ROW ]
[ WHEN (prdicat) ]
BEGIN mise__jour ; ... END
Chaque opration de mise jour est une instruction INSERT, UPDATE ou DELETE.
La condition restrictive de la clause WHEN peut prciser les cas o les mises jour complmentaires doi-
vent tre dclenches.
Par dfaut, laction dclenche est excute une seule fois. Loption FOR EACH ROW ordonne de la r-
pter pour chaque ligne mise jour par lvnement dclencheur.
Dans les exemples ci-dessous, toute mise jour complmentaire consiste modifier une valeur dans
un n-uplet existant dans une table de la base de donnes :
UPDATE table
SET colonne = valeur
WHERE prdicat -- condition identifiant la ligne modifie

1
La mtaphore de la gchette voque l'enchanement automatique des actions : pression sur la dtente, per-
cussion du projectile.
Exemple : gestion automatique du total factur
(a) dfinition des tables :
CREATE TABLE facture
( no_facture NUMERIC(5) DEFAULT 0 -- drivable
PRIMARY KEY,
no_commande NUMERIC(5) UNIQUE
REFERENCES commande ON DELETE SET NULL,
date_facture DATE DEFAULT CURRENT_DATE NOT NULL,
total_facture Prix DEFAULT 0 ); -- drivable
puisqu'ils seront drivs automatiquement,
le numro et le total sont aussi initialiss automatiquement
pour crer l'en-tte d'une facture, il suffira de fournir le numro de la commande
CREATE TABLE ligne_facture
( no_facture NUMERIC(5)
REFERENCES facture ON DELETE CASCADE,
CONSTRAINT "produit livr"
REFERENCES produit ON UPDATE CASCADE,
quantite_livree Quantite NOT NULL
CONSTRAINT "quantit livre > 0"
CHECK (quantite_livree > 0),
montant_facture Prix,
PRIMARY KEY (no_facture, no_produit) );
la contrainte sur le numro de facture garantit que l'en-tte de la facture prexiste
(b) dfinition des mises jour automatiques :
cration de l'enregistrement Facture ==> cration du numro de facture :
CREATE TRIGGER "calcul du n de facture"
AFTER INSERT ON facture
FOR EACH ROW
BEGIN
UPDATE facture
SET no_facture = ( SELECT MAX(no_facture)
FROM facture ) + 1
-- = dernier n attribu + 1
WHERE no_facture = 0;
END;
insertion de lignes dans la facture ==> calcul du total factur :
CREATE TRIGGER "cration de lignes de factures"
AFTER INSERT ON ligne_facture
FOR EACH ROW
BEGIN
UPDATE facture
SET total_facture = total_facture +
ligne_facture.montant_facture
WHERE facture.no_facture =
ligne_facture.no_facture;
END;
modification de lignes dans la facture ==> ajustement du total factur :
CREATE TRIGGER "modification de lignes de factures"
AFTER UPDATE OF montant_facture ON ligne_facture
REFERENCING OLD AS ancien
FOR EACH ROW
BEGIN
UPDATE facture
SET total_facture = total_facture +
(ligne_facture.montant_facture
- ancien.montant_facture)
END;
suppression de lignes dans la facture ==> diminution du total factur :
CREATE TRIGGER "suppression de lignes de factures"
BEFORE DELETE ON ligne_facture
FOR EACH ROW
BEGIN
UPDATE facture
SET total_facture = total_facture
- montant_facture
END;
Des "triggers" tels que ceux-ci sont souvent prsents comme compltant les contraintes d'intgrit rfren-
tielle.
e) Les vues
Une vue constitue une prsentation alternative d'une partie du contenu de la base de donnes. Pour lutilisa-
teur (ou le programme), une vue prend la forme d'une table manipulable comme n'importe quelle autre; le
SGBD rpercute sur les tables relles les oprations entreprises sur une vue.
L'intrt d'une vue est d'offrir un utilisateur de la base de donnes une prsentation des donnes adapte ses
besoins particuliers. Il peut aussi tre de protger la confidentialit des donnes, en restreignant l'accs au
sous-ensemble des donnes prsentes par une vue sur laquelle l'utilisateur possde un droit d'accs.
Format : CREATE VIEW nom_de_vue [(noms_de_colonnes)]
AS slection
Exemples : donnes masques (slection d'une partie des colonnes) :
CREATE VIEW tarif AS
SELECT no_produit, nom_produit,
prix_de_vente, taux_TVA
FROM produit;
CREATE VIEW stock AS
SELECT no_produit, quantite_en_stock
FROM produit;
dfinition de sous-types (slection d'une partie des lignes) :
CREATE VIEW client_prive AS
SELECT * FROM client
WHERE no_TVA IS NULL;
CREATE VIEW client_professionnel AS
SELECT * FROM client
WHERE no_TVA IS NOT NULL;
Les possibilits offertes par le langage SQL en matire de dfinition de vues sont beaucoup plus tendues que
celles qui se trouvent illustres dans ces exemples. Par exemple, il est possible de dfinir une vue embrassant
un groupe de tables associes par le biais d'identifiants trangers.
f) Cration dindex
Un schma de base de donnes tel que celui montr en exemple ci-dessus est oprationnel. Pourtant, il ne
contient aucune indication relative aux aspects matriels du stockage des donnes dans l'espace d'un support;
il reste une dfinition purement conceptuelle. C'est une particularit des SGBD relationnels qu'ils puissent
fonctionner sur une telle dfinition.
Nanmoins, si l'on veut amliorer les performances du SGBD en acclrant les oprations d'accs aux don-
nes, il sera ncessaire d'tablir certaines options relatives au stockage physique des donnes. Ces options
sont spcifiques chaque SGBD; cependant, il existe une structure physique commune tous les systmes, et
pourtant ignore de la norme SQL : les index.
La fonction d'un index dans une base de donnes est analogue celle d'un index dans un ouvrage imprim.
L'index d'un livre associe chaque mot cl le numro des pages o figure ce mot; un tel index acclre la re-
cherche dans l'ouvrage, en pargnant au lecteur de devoir parcourir intgralement toutes les pages du volume.
Qui plus est, le fait que l'index soit ordonn (les mots cls y sont rangs par ordre alphabtique) acclre la
consultation de l'index lui-mme : cette consultation peut procder par sauts. Une base de donnes est gale-
ment physiquement dcoupe en pages, par exemple de 512 ou 1024 octets. A la demande de l'administrateur
de la base de donnes, le SGBD peut construire un index distinct sur n'importe quelle colonne ou groupe de
colonnes : chaque valeur de cette colonne ou de cette combinaison sont associs les numros des pages o
cette valeur est enregistre.
L'opration principale d'un langage relationnel est la requte SELECT, slection dfinie par des critres de
slection. Toute colonne de toute table peut servir de critre de slection dans une requte. Sans index, l'in-
terrogation, pour tablir la slection, doit gnralement examiner toutes les occurrences du critre prsentes
dans la base de donnes; cet examen peut impliquer le parcours d'un espace matriel important. Un index est
un acclrateur des oprations de recherche et de tri.
Quelles tables et colonnes convient-il d'indexer ?
La collection reprsente par la table doit tre suffisamment importante (> 200-300 lignes ?), sans
quoi l'examen squentiel de la table est gnralement plus performant.
Les colonnes indexes doivent tre frquemment cites en guise de critres de slection ou de tri et,
la fois, s'avrer hautement discriminantes (on n'indexe pas une colonne qui ne peut prendre que 4
valeurs diffrentes !). Tel est gnralement le cas des identifiants, primaires, candidats et trangers.
Format : CREATE [UNIQUE] INDEX nom d'index
ON table (colonne, ...) ;
le qualificatif UNIQUE dfinit un index univoque
1

1
Avant que le langage SQL permt d'exprimer les contraintes d'intgrit, cette particularit tait utilise pour
garantir l'univocit d'un identifiant.
Exemples : indexation des identifiants et rfrences du schma prcdent :
CREATE UNIQUE INDEX representant_0 -- cl primaire
ON representant (nom_delegue);
CREATE INDEX representant_region -- cl trangre
ON representant (region);
CREATE UNIQUE INDEX client_0 -- cl primaire
ON client (no_client);
CREATE INDEX client_representant -- cl trangre
ON client (nom_delegue);
CREATE UNIQUE INDEX abonnement_0 -- cl primaire
ON abonnement (no_client, type_prospectus);
CREATE UNIQUE INDEX produit_0 -- cl primaire
ON produit (no_produit);
CREATE UNIQUE INDEX produit_1 -- cl trangre
ON produit (nom_produit);
CREATE UNIQUE INDEX commande_0 -- cl primaire
ON commande (no_commande);
CREATE INDEX commande_client -- cl trangre
ON commande (no_client);
.....
Dans une base de donnes relationnelle, les index sont toujours facultatifs; ils peuvent tre crs (par une
commande CREATE INDEX) et supprims (par une commande DROP INDEX) tout moment.
2.3. La manipulation des donnes
a) Oprations disponibles
Consultation : SELECT
La consultation d'une base de donnes relationnelle procde par requtes slectionnant une partie des donnes
de la base. Le rsultat dune slection est une collection de donnes formant elle-mme une relation ou table
virtuelle.
Le format de base d'une requte SELECT en langage SQL est le suivant :
Format : SELECT liste de donnes (ou *, signifiant tous les attributs)
FROM liste de tables [ WHERE prdicat ]
les donnes affiches ou testes sont,
non seulement des variables de la base de donnes (des colonnes),
mais aussi des constantes ou des donnes calcules
la clause WHERE identifie par son prdicat les lignes retenir dans la slection
Il existe des formes de requtes plus dveloppes et, de plus, les rsultats de plusieurs requtes peuvent tre
combins, notamment par des oprateurs ensemblistes (union, intersection, diffrence).
Cration de lignes : INSERT
L'opration INSERT ajoute une ou plusieurs lignes dans une table. Si, pour une ligne, l'instruction ne fournit
pas les valeurs de toutes les colonnes, les valeurs manquantes sont remplaces par leur valeur par dfaut si on
en a dfini une, sinon par NULL (les contraintes dfinies sur la table doivent videmment autoriser ces va-
leurs NULL).
Une premire forme insre une ou plusieurs lignes composes partir de valeurs littrales, une seconde forme
insre dans la table le rsultat d'une slection.
Formats : INSERT INTO table [(colonne, ...)]
VALUES (valeur, ...), ...
INSERT INTO table [(colonne, ...)]
requte_SELECT
si l'on omet la liste de colonnes,
les colonnes sont prises dans l'ordre de leur dfinition par CREATE TABLE
chaque ligne fournie doit comporter autant de valeurs
qu'il existe de colonnes dans cette liste explicite ou implicite
Modification de lignes : UPDATE
L'opration UPDATE modifie certaines valeurs dans des lignes existantes. Les lignes modifier sont identi-
fies par la condition formule dans la clause WHERE; dfaut de cette clause, toutes les lignes de la table
sont modifies.
Format : UPDATE table
SET colonne = valeur, ... (valeur ou DEFAULT ou NULL)
[ WHERE prdicat ]
Suppression de lignes : DELETE
L'opration DELETE supprime certaines lignes dans une table. Les lignes supprimer sont identifies par la
condition formule dans la clause WHERE; dfaut de clause WHERE, toutes les lignes de la table sont sup-
primes.
Format : DELETE FROM table [ WHERE prdicat ]
Exemple : suppression d'une commande :
DELETE FROM commande WHERE no_commande = 308;
-- en vertu d'une contrainte REFERENCES,
-- les lignes de commandes sont supprimes en cascade
b) Modes d'utilisation du langage SQL
A l'origine, le langage SQL a t conu comme un langage interactif destin l'utilisateur final (utilisateur
final mais pas profane : le langage SQL est un langage d'informaticiens).
Le langage a t adapt pour s'intgrer aux langages de programmation habituels, sous deux formes : SQL
insr ("embedded SQL") pour la rdaction de requtes figes et prdfinies, SQL dynamique pour la r-
daction de requtes variables d'une excution l'autre du programme.
Dans les annes 1990 se sont dvelopps diffrents outils d'accs aux bases de donnes relationnelles, qui tra-
duisent leurs requtes en SQL. Pour ces outils, SQL sert de rfrence. Citons les outils d'interface graphi-
que qui intgrent la manipulation des bases de donnes des programmes fonctionnant dans un environne-
ment graphique comme, par exemple, MS-Windows. Citons galement les bibliothques de fonctions
comme ODBC ("Open Data Base Connectivity") de Microsoft, appelables par les programmes.
1
c) SQL insr
Comment un programme rdig en COBOL ou en C, par exemple, accde-t-il une base de donnes relation-
nelle ? Nous nous contenterons ici de dcrire la premire des possibilits avoir t offerte aux program-
meurs : lemploi dinstructions SQL insres ou "serties" ("embedded SQL"), moyennant certains amnage-
ments, dans le texte du programme. Le texte du programme est successivement analys par deux compila-
teurs : le pr-compilateur SQL puis le compilateur du langage hte.
Reprage des instructions SQL insres
Comment le pr-compilateur repre-t-il dans le texte les phrases SQL ? Toute instruction SQL est prfixe
par les mots EXEC SQL et se termine par un point-virgule, sauf dans un programme COBOL, o elle se ter-
mine par le mot END-EXEC.
2
Communication des donnes
Comment changer des donnes entre les instructions SQL et celles du langage hte ?
Partout o, dans une instruction SQL, peut tre indique une valeur littrale, on peut, en lieu et place, indiquer
le nom d'une variable du programme hte; des variables du programme hte sont galement employes pour
recevoir les rsultats d'une requte de slection. Pour le distinguer des autres noms manipuls par SQL, le
nom d'une variable du programme hte est prfix par deux points (:nom_de_variable).
3
Ces donnes doivent, dans les deux langages SQL et hte, tre d'un type quivalent.
4
De plus, dans le texte du
programme, la dclaration des variables accessibles SQL doit tre comprise entre les deux repres EXEC
SQL BEGIN DECLARE SECTION et EXEC SQL END DECLARE SECTION; grce cette dernire conven-
tion, le pr-compilateur SQL pourra prendre note du format dfini pour ces donnes.
Signalisation des incidents
Divers moyens sont offerts au programme pour connatre les incidents ventuels ou conditions d'exception qui
se sont produits pendant l'excution de chaque opration SQL. Voici le plus simple : au terme de toute ex-
cution d'une instruction SQL, le programme hte peut tester le code de retour rang dans l'indicateur de nom
SQLSTATE (cet indicateur est une variable du programme hte).

1
Ces bibliothques d'"Application Programming Interface" (API) fournissent des fonctions qui se substi-
tuent aux clauses du langage SQL insr. Ce nouveau procd ne ncessite pas l'intervention d'un pr-
compilateur des requtes SQL places dans le programme; le programme peut donc tre cr et s'excuter
sur un ordinateur client n'ayant pas accs aux outils de dveloppement particuliers du SGBD.
2
Car, en COBOL, le point-virgule est un sparateur facultatif et sans signification.
3
SQL ne pouvant ni indicer ni qualifier les noms des variables htes, celles-ci ne peuvent pas tre membres
d'une structure ou d'un tableau.
4
La norme SQL dfinit les quivalences pour un certain nombre de langages.
Les curseurs
En toute gnralit, le rsultat d'une requte de slection est un ensemble de lignes que, normalement, le pro-
gramme voudra traiter une une. A cette fin, on associe un "curseur" la slection qui, grce une instruc-
tion FETCH, avancera ligne par ligne dans la slection. Un curseur doit tre "ouvert" (initialis) et "ferm";
une autre manire de voir est donc de considrer le rsultat d'une requte comme un fichier parcouru squen-
tiellement.
1
Format : DECLARE nom_de_curseur [INSENSITIVE] [SCROLL] CURSOR
FOR requte [ ORDER BY { colonne [sens] } , ... ]
[ FOR UPDATE [ OF (liste de colonnes) ] ]
sens : le sens du tri est indiqu par ASC(ending), par dfaut, ou DESC(ending)
Le qualificatif INSENSITIVE dclare le curseur "insensible" aux mises jour concurrentes qui
pourraient survenir entre les oprations OPEN et CLOSE d'ouverture et fermeture du curseur. En r-
alit, le SGBD cre une copie de la slection opre, et c'est cette copie que le programme accde
par l'opration FETCH.
L'option SCROLL dfinit un curseur "droulant"; les lignes de la slection sont numrotes (analo-
gie avec un fichier relatif) et le programme peut se dplacer librement l'intrieur de la slection.
En l'absence de cette clause, toute opration FETCH obtient la ligne suivante par rapport la position
courante (analogie avec un fichier squentiel).
L'option ORDER BY permet de dterminer l'ordre de succession des lignes dans la slection.
L'option FOR UPDATE signale que le programme est susceptible de modifier (UPDATE) ou sup-
primer (DELETE) l'une ou l'autre lignes figurant dans la slection; si l'on indique une liste de co-
lonnes, la possibilit de mise jour est limite ces colonnes. Par dfaut, un curseur est dfini FOR
READ ONLY; il ne permet pas la mise jour.
Exemple COBOL
Voici une version COBOL-SQL de rfrence pour le programme de facturation donn en exemple la fin du
chapitre 4.
2
On remarquera que la structure du programme est inchange; les seules diffrences tiennent au
remplacement des instructions COBOL daccs aux fichiers par des instructions SQL daccs la base de
donnes.
Une seule transaction est dfinie, dans laquelle on commence par dresser la liste des commandes facturer;
toutes ces commandes sont protges contre l'accs concurrent pendant toute la dure du programme (une
mise jour des lignes de ces commandes sera galement impossible, car les accs la table Commande n-
cessits par la vrification des contraintes seront refuss).
Le programme utilise deux curseurs : un curseur sur la liste des numros des commandes facturer et r-
ptitivement un curseur parcourant lensemble des lignes de chaque commande.

1
Une requte produisant un singleton, c'est--dire un ensemble d'une seule ligne, peut, plus simplement, s'ef-
fectuer au moyen d'une instruction SELECT adapte de manire fournir une liste de variables rceptrices :
SELECT liste de donnes INTO liste de variables FROM ..... WHERE .....
2
Cf. chapitre 4, 3.4.
IDENTIFICATION DIVISION.
PROGRAM-ID. Constitution-Factures.
WORKING-STORAGE SECTION.
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
* code de retour des oprations SQL :
77 SQLSTATE PIC X(5).
* variables du programme accessibles aux oprations SQL :
77 Qte-en-Stock PIC S9(5) BINARY.
77 Prix-de-Vente PIC S9(10)V99 SIGN LEADING SEPARATE.
77 No-Commande PIC S9(5) SIGN LEADING SEPARATE.
77 Qte-Commandee PIC S9(4) BINARY.
77 No-Facture PIC S9(5) SIGN LEADING SEPARATE.
77 Qte-Livree PIC S9(5) BINARY.
77 Montant-Facture PIC S9(10)V99 SIGN LEADING SEPARATE.
77 Total-Facture PIC S9(10)V99 SIGN LEADING SEPARATE.
EXEC SQL END DECLARE SECTION END-EXEC.
PROCEDURE DIVISION.
Etablir-Connexion.
* opration non illustre
Traiter-Fichier.
* dfinir les modalits de l'unique transaction du programme
* (mise jour = READ + WRITE,
* protection contre l'accs concurrent = ISOLATION LEVEL) :
EXEC SQL
SET TRANSACTION READ WRITE
ISOLATION LEVEL REPEATABLE READ
END-EXEC
* obtenir le dernier n de facture attribu :
EXEC SQL
SELECT MAX (No_Facture) INTO :No-Facture FROM Facture
END-EXEC
IF SQLSTATE = "02000" THEN MOVE 0 TO No-Facture END-IF
* arrter la liste des commandes facturer
* (retenir les No_Commande qui ne se trouvent pas encore
* - EXCEPT ALL - dans la table Facture) :
EXEC SQL
DECLARE Commandes_a_Facturer INSENSITIVE CURSOR FOR
SELECT No_Commande FROM Commande
EXCEPT ALL
SELECT No_Commande FROM Facture
END-EXEC
EXEC SQL OPEN Commandes_a_Facturer END-EXEC
* tablir les factures :
PERFORM Traiter-Commande THRU Lire-Commande
UNTIL No-Commande = 0
* fermer le curseur et clturer la transaction :
EXEC SQL CLOSE Commandes_a_Facturer END-EXEC
EXEC SQL COMMIT WORK END-EXEC
STOP RUN
.
Traiter-Commande.
* initialiser la facture :
ADD 1 TO No-Facture MOVE 0 TO Total-Facture
* obtenir les lignes de la commande :
1
EXEC SQL
DECLARE Corps_Commande CURSOR FOR
SELECT No_Produit, Quantite_Commandee
FROM Ligne_Commande WHERE No_Commande = :No-Commande
END-EXEC
EXEC SQL OPEN Corps_Commande END-EXEC
* traiter les lignes :
PERFORM Lire-Ligne
PERFORM Traiter-Ligne THRU Lire-Ligne
UNTIL No-Produit = SPACES
* clturer la facture (date par dfaut = CURRENT_DATE) :
EXEC SQL
INSERT INTO Facture
(No_Facture, No_Commande, Total_Facture)
VALUES (:No-Facture, :No-Commande, :Total-Facture)
END-EXEC
EXEC SQL CLOSE Corps_Commande END-EXEC
.
Lire-Commande.
* obtenir le numro de la commande suivante :
EXEC SQL
FETCH Commandes_a_Facturer INTO :No-Commande
END-EXEC
IF SQLSTATE = "02000" THEN MOVE 0 TO No-Commande END-IF
.
Traiter-Ligne.
* obtenir la fiche Produit :
EXEC SQL
SELECT Quantite_en_Stock, Prix_de_Vente
INTO :Qte-en-Stock, :Prix-de-Vente
FROM Produit WHERE No_Produit = :No-Produit
END-EXEC

1
Si lopration OPEN effectuant la slection doit tre rpte pour chaque commande traiter, linstruction
DECLARE CURSOR dfinissant les modalits de la slection pourrait ntre excute quune seule fois (elle
figurerait alors immdiatement aprs le commentaire "tablir les factures").
* calculer la quantite livre :
IF Qte-Commandee <= Qte-en-Stock
THEN COMPUTE Qte-Livree = Qte-Commandee
ELSE COMPUTE Qte-Livree = Qte-en-Stock
END-IF
* modifier le stock :
EXEC SQL
UPDATE Produit
SET Quantite_en_Stock = :Qte-en-Stock - :Qte-Livree
WHERE No_Produit = :No-Produit
END-EXEC
* calculer les montants de la facture (on nglige la TVA) :
COMPUTE Montant-Facture = Prix-de-Vente * Qte-Livree
ADD Montant-Facture TO Total-Facture
* enregistrer la Ligne de Facture :
EXEC SQL
INSERT INTO Ligne_Facture
VALUES (:No-Facture, :No-Produit,
:Qte-Livree, :Montant-Facture)
END-EXEC
.
Lire-Ligne.
EXEC SQL
FETCH Corps_Commande INTO :No-Produit, :Qte-Commandee
END-EXEC
IF SQLSTATE = "02000"
THEN MOVE SPACES TO No-Produit
END-IF
.
A. CLARINVAL Analyse Modlisation des systmes 6-1
Chapitre 6. Introduction la modlisation des systmes
Un systme est un objet dynamique complexe, dont on veut dcrire le fonctionnement. Le concept de systme
et la mthodologie d'analyse des systmes sont communs un grand nombre de disciplines; citons : la biolo-
gie, les sciences de l'ingnieur, l'tude des organisations, l'informatique ... Un systme est d'ailleurs sans doute
plus un mode de reprsentation, un modle, qu'une ralit concrte.
1
Ce chapitre dresse une nomenclature des niveaux de hirarchisation des systmes de traitement de linforma-
tion.
Le chapitre 7 prsente diffrentes variantes de schmas connus sous le nom gnrique de diagrammes de flux
(de donnes, de signaux, dvnements ...). Ces modles sont ns dans le contexte ancien des programmes de
"traitement par lots", incapables de "converser" avec un utilisateur humain, caractristiques des premires
ralisations de linformatique de gestion.
Le chapitre 8 est ddi aux mthodes danalyse nes dans le sillage de la programmation par objets. Il traite
dabord brivement de la spcification des oprations effectues par les objets. Il sattache ensuite exposer
le modle des cas dutilisation mis au point par le Sudois I. JACOBSON
2
(de cration plus rcente, ce mo-
dle veut apporter une rponse aux problmes de linformatique interactive ou conversationnelle et de la pro-
grammation par objets). Le chapitre se termine par quelques considrations sur la conception dune architec-
ture logicielle, illustres par le principe darchitecture clientserveur et les patterns ou motifs architecturaux.
Les schmas dcrits ici recueillent un franc succs auprs des analystes ... et de leurs clients ou
commanditaires. En effet, nutilisant pas de concepts sophistiqus que seuls des spcialistes jargon-
nants seraient mme de manipuler, ils se rvlent trs "parlants" pour les profanes et constituent un
support de choix pour le dialogue de linformaticien avec ses commanditaires.
AVERTISSEMENT. L'tude du fonctionnement des systmes d'informations utilise des termes comme
"fonction, procdure, tche, processus" ... dont la signification est loin d'tre fixe et unanimement comprise.
Au contraire, chaque mthode, chaque auteur dfinit sa propre terminologie.

1
Cf. J.L. LE MOIGNE : La thorie du systme gnral; Presses Universitaires de France, 1977.
2
I. JACOBSON, al. : Object-Oriented Software Engineering : a Use Case Driven Approach; Addison-
Wesley, 1992. I. JACOBSON, al.: Le processus unifi de dveloppement logiciel, trad. franaise; Eyrolles,
1999.
1. Hirarchisation du systme d'information
Le fonctionnement d'un systme de traitement de l'information est dcrit en termes d'activits, ou ensembles
d'oprations, auxquels on donne le nom de processus. Afin d'en matriser la complexit, l'analyse des syst-
mes procde par dcomposition, en distinguant diffrents niveaux d'agrgation des oprations.
Nous distinguerons trois niveaux de processus : systme, tche, module.
1.1. Systme
Un systme, en particulier un systme d'information, possde les proprits dynamiques suivantes : c'est
un ensemble permanent
d'activits rcurrentes.
Beaucoup des activits rcurrentes d'un systme sont priodiques, c'est--dire qu'elles se reproduisent des
intervalles de temps dtermins.
Exemple : SYSTEME : administration des salaires :
ACTIVITES : enregistrement des modifications de la situation du personnel (occasionnel)
enregistrement des prestations (quotidien)
calcul et paiement des rmunrations (mensuel)
tablissement des attestations et documents lgaux (annuel)
Appelons systme le rfrentiel analys; il peut tre dcompos en sous-systmes, qui possdent eux-mmes
toutes les proprits dynamiques d'un systme; un sous-systme peut tre dcompos en sous-sous-systmes,
et ainsi de suite.
Dans la pratique, les critres d'individualisation d'un sous-systme d'information sont principalement organi-
sationnels. L'activit d'une entreprise le systme "oprant" est organise en grandes fonctions ou finali-
ts internes : gestion de la production, gestion financire, gestion du personnel ... Chaque grande fonction se
reflte dans un sous-systme d'information.
Exemples : entreprise :
gestion du personnel :
recrutement, formation, promotions
administration des salaires
gestion financire :
trsorerie
comptabilit :
comptabilit gnrale
budget
comptabilit analytique
..........
Au sein d'un organisme possdant diffrents siges ou filiales, on distinguera un sous-systme propre cha-
cune des entits ... Les sous-systmes particuliers aux diffrents siges d'un organisme sont ventuellement du
mme type, c'est--dire qu'ils font l'objet d'une dfinition identique.
1
1.2. Tche
Une tche est un ensemble d'oprations passant pour lmentaire aux yeux de l'utilisateur "client" du systme,
que cet utilisateur alimente en donnes et dont il attend des rsultats,
au fonctionnement duquel il affecte des ressources : moment, dure, localisation, machines, personnel ...
Exemples : TACHE : enregistrement des modifications de situation du personnel
DONNEES : donnes "familiales" communiques par l'employ
donnes "professionnelles" reues du service employeur
RESULTATS : fichier signaltique mis jour
RESSOURCES : employ du service du personnel
ordinateur personnel connect l'ordinateur central
TACHE : calcul des rmunrations
DONNEES : fichier signaltique du personnel
prestations mensuelles enregistres
RESULTATS : fiches de paie
virements bancaires
RESSOURCES : ordinateur central
entre le 5
e
et le 3
e
jours ouvrables avant fin de mois
dure estime = 2 heures
On associe souvent la tche un vnement dclencheur ou une combinaison d'vnements dclencheurs.
Exemples : TACHE : enregistrement des modifications de situation du personnel
EVENEMENTS : toute information pertinente reue
des membres du personnel
ou des services employeurs
EVENEMENTS : derniers jours ouvrables du mois
demande du service responsable
Une des ressources affectes une tche est le processeur qui l'excute. De ce point de vue, les tches de
traitement de l'information se rpartissent en :
tches automatiques, excutes par un programme d'ordinateur, sans intervention humaine;
tches "manuelles" (sic), effectues par l'tre humain sans recours l'ordinateur;
tches interactives, faisant dialoguer un programme d'ordinateur et un oprateur humain.
Exemples : TACHE interactive : enregistrement des modifications de situation du personnel
TACHE automatique : calcul des rmunrations = tablissement de la paie
TACHE "manuelle" : distribution des fiches de paie

1
Rappelons que le concept de type, classe des objets vrifiant une mme dfinition, est tout fait gnral.
Les objets dynamiques du traitement de l'information, dont il est question dans le prsent chapitre, sont eux
aussi classs par types.
Programme
Il n'est pas rare qu'une tche automatique, par exemple l'tablissement de la paie du personnel, ncessite d'en-
chaner l'excution de plusieurs programmes ... Une tche interactive implique souvent la coopration de
deux programmes dans une architecture "client/serveur", un programme grant le travail du "client" l'cran,
un autre se chargeant des accs la base de donnes au "service" des diffrents clients; ces deux programmes
s'excutent souvent sur des ordinateurs distincts : un ordinateur personnel pour le client et un ordinateur cen-
tral pour le serveur ... De plus en plus souvent, un programme se prsente comme une sorte de bote outils
dont les composants sont utiliss par des tches diverses; tel est le cas dun tableur, mais aussi dun pro-
gramme permettant de crer, mettre jour, consulter et imprimer, par exemple, des fiches Clients ...
Ces exemples montrent suffisance qu'un programme n'est qu'une des ressources affectes l'excution d'une
tche. (Et il existe des tches nutilisant pas de programmes : les tches "manuelles".)
Objet
Au concept de programme concourant l'excution d'une tche, a tendance aujourd'hui se substituer celui
d'objet programm, capable d'effectuer certaines oprations et ainsi de rendre des "services". Un objet pro-
gramm est capable de plus d'oprations qu'une tche particulire n'en utilise (c'est pourquoi, au lieu de parler
de tches, les mthodologies "orientes objets" parlent de cas d'utilisation
1
).
Tche = Transaction
Appelons transaction une squence d'oprations (d'un ou plusieurs acteurs, processeurs, programmes ou
objets) dont la terminaison est le minimum ncessaire pour que le traitement soit cohrent, c'est--dire
conforme aux rgles tablies.
2
Exemples : les oprations d'enregistrement d'un bon de commande, les opra-
tions produisant l'mission d'une facture, le traitement de prise en charge d'une criture comptable ... Les di-
verses descriptions fournies par l'analyste, dont il sera question dans la suite l'utilit fonctionnelle, les r-
gles de procdure, les liens de causalit , concernent essentiellement les transactions. Cette observation
justifie d'assimiler la tche une transaction (plutt qu' l'excution complte d'un ou plusieurs programmes).
S'il existe des rgles portant sur un ensemble de transactions lmentaires (exemple : la facturationlivraison
est quotidienne; elle traite en priorit les commandes les plus anciennes), on a affaire une tche comportant
une hirarchie de rgles et, par consquent, diffrents niveaux de transactions, lmentaires et composites.
Commentaires
Selon F. BODART et Y. PIGNEUR,
3
qui disent "phase" plutt que "tche", "Le concept de 'phase' constitue
le repre central de la nomenclature par la signification qu'il prsente sur trois plans d'analyse. Au plan
informationnel, la phase est un lieu d'identification [...] de rgles de traitement. [...] Au plan conomi-
que, elle est un lieu d'allocation des ressources humaines, matrielles et logicielles, ncessaires son excu-
tion. Au plan organisationnel, elle est un lieu de redfinition des structures d'organisation : tches, fonc-
tions, rles, responsabilits, postes de travail. [...] La phase constitue [...] le lieu lmentaire d'analyse des
changements apporter un systme d'information : changement des rgles de mmorisation et de traite-
ment, modification du comportement des personnes, changement dans les structures d'organisation, change-
ment technologique."

1
I. JACOBSON, al. : op. cit.
2
La notion classique de transaction sur une base de donnes constitue un cas particulier de la dfinition plus
gnrale propose ici. Cf. chapitre 5.
3
F. BODART, Y. PIGNEUR : Conception assiste des systmes d'information : mthodes, modles, outils;
Masson, 1989.
De plus, pour l'informaticien, ce niveau constitue le point d'articulation de deux mthodologies nettement dif-
frentes par leurs objectifs pratiques : l'analyse interne d'une tche doit produire une description programma-
ble, tandis que l'analyse des niveaux suprieurs systme et sous-systmes ne doit ordinairement produire
que de la documentation.
1.3. Module
Un module est un ensemble dorganes (objets) et/ou d'oprations lmentaire aux yeux du technicien cra-
teur dun systme de traitement de l'information. L'excution d'une tche met en uvre un ou plusieurs mo-
dules et ce sont ces derniers qui, finalement, assument la responsabilit des traitements.
Un module est gnralement confondu avec un composant programmable; il possde donc une forme concrte
lie aux moyens de conception et de ralisation dont disposent les programmeurs. Si, nagure, ces moyens
apparaissaient uniformes un module prenait l'aspect d'un sous-programme , ils sont aujourd'hui trs
divers. Cependant, ces nouvelles espces de composants, pr-programms ou non, se prsentent habituelle-
ment sous la forme dobjets plus ou moins explicitement conformes la dfinition propose par le paradigme
de la programmation par objets :
un objet est une entit
qui se trouve dans un tat, dcrit par des attributs,
et qui, capable de certaines oprations, possde un comportement
lui permettant de ragir des vnements signals par des messages.
2. Niveaux intermdiaires
Si, parce qu'ils se rencontrent dans la ralit des systmes de traitement de l'information, les niveaux de
(d)composition dfinis ci-dessus doivent se retrouver dans toute analyse, il est loisible au concepteur de dis-
tinguer des niveaux intermdiaires. Ne correspondant aucun objet prcis dans la ralit, ces niveaux pure-
ment artificiels sont distingus pour la commodit de la reprsentation mentale ou de la planification du travail
d'informatisation ...
Dans le contexte des tudes et travaux d'informatisation, on s'attaque un projet informatique, dcoup en
applications informatiques. Un projet concerne un sous-systme d'information. Une application peut recou-
vrir un sous-sous-systme ou apparatre plus ou moins comme un sous-ensemble artificiel, isol pour les be-
soins du travail d'informatisation.
Dans la dcomposition d'un systme, l'analyste peut faire apparatre des groupes de tches entre lesquelles
existent des liens particuliers de complmentarit (ex.: ensemble des tches composant le "traitement des
commandesclients") ou de similitude (ex.: groupe des tches d'"dition de statistiques"). Un groupe de
tches suffisamment vaste pourra tre gr comme une application ...
Il est possible de dfinir des niveaux intermdiaires entre la tche et le module de base; appelons composi-
tions de modules ces agrgats. A part le fait qu'elle n'est pas lmentaire, semblable composition possde
toutes les proprits d'un module.
SYSTEME
SOUS-SYSTEME projet
application
groupe de tches
TACHE
programme
composition de modules
MODULE
NOTE. Introduisant la modlisation conceptuelle des donnes, nous disions que lanalyste dcrivait par ce
moyen un domaine dapplication.
1
Il sagit maintenant de dcrire les applications qui seront dployes dans
ce domaine.

1
Cf. chapitre 3.
A. CLARINVAL Analyse Diagrammes de flux 7-1
Chapitre 7. Les diagrammes de flux
Outils privilgis, les diagrammes de flux entre activits sont utiliss par toutes les mthodologies d'analyse
des systmes d'informations. Ces diagrammes possdent de nombreuses variantes; grce telle ou telle parti-
cularits, ils permettent lanalyste dtudier le systme dinformation sous diffrents angles.
Nous prsentons dans ce chapitre trois formes de diagrammes de flux :
les diagrammes de flux de donnes, schmas fonctionnels dcrivant lutilit des traitements;
les diagrammes denchanement dynamique, qui en dcrivent les contraintes (denchanement);
les diagrammes de dploiement, qui mettent en vidence les ressources ncessaires leur excution.
1. Schma fonctionnel
Un objet dynamique, en particulier un systme, poursuit une finalit que nous appellerons sa fonction. L'ana-
lyse d'un systme d'information doit expliquer comment celui-ci remplit sa triple fonction de mmoriser,
transformer et diffuser de l'information. Ce comportement est dfini par des rgles de procdure.
Le schma fonctionnel d'un systme d'information doit en mme temps matriser la complexit inhrente ce
systme; il fournit donc des moyens pour en dcrire la structure en termes de composants plus simples. On
se sert pour cela de diagrammes de flux de donnes. Ces diagrammes possdent de nombreuses variantes, et
plusieurs manires de les utiliser sont prconises. Citons, entre autres, l'cole amricaine de la "Structured
Analysis", particulirement reprsente par l'quipe de YOURDON.
1
1.1. Contenu d'un diagramme de flux
a) Environnement
Il est dans l'essence de l'information d'tre communique. Un systme d'information appartient donc la cat-
gorie des systmes "ouverts", possdant un environnement avec lequel ils changent des donnes. Concr-
tement, le systme d'information d'une entreprise se trouve en communication avec le systme oprant et le
systme de dcision de cette entreprise; il ralise galement des changes avec (les systmes d'information
de) l'environnement socio-conomique de l'entreprise : clients et fournisseurs, bien sr, mais aussi le minis-
tre des finances (service de la TVA), etc ...
Quant l'environnement d'un sous-systme, il est constitu des autres sous-systmes avec lesquels il change
de l'information; par exemple, bon nombre des sous-systmes d'une entreprise commerciale changent des
donnes avec le sous-systme comptable de cette entreprise.
Par dfinition, l'environnement du systme de rfrence n'est pas analys; il est simplement peru comme un
ensemble de processeurs ou acteurs (fournisseurs, clients, etc.) susceptibles d'activits non prcises.
Acteur
externe
Banque
Clients Fourniss.

1
C. GANE, T. SARSON : Structured Systems Analysis : tools and techniques; Prentice-Hall, 1979. T. DE
MARCO : Structured Analysis and System Specification; Prentice-Hall, 1979. E. YOURDON : Mo-
dern Structured Analysis; Prentice-Hall, 1989.
b) Processus
La fonction d'un processus de traitement de l'information systme, sous-systme, tche ou module (sous-
programme) se dcrit aisment comme tant une transformation de donnes d'entre en donnes de sor-
tie.
1
La notion de transformation doit tre entendue dans un sens large : il ne s'agit pas seulement des opra-
tions changeant la forme des donnes, mais galement de celles qui en modifient la localisation dans l'espace
ou le temps; ainsi considrera-t-on que l'enregistrement d'un changement d'adresse, c'est--dire la simple re-
copie sur un support de la nouvelle adresse, constitue une transformation.
Exemples : SOUS-SYST. : administration des salaires
FONCTION : assurer et grer la rmunration des prestations du personnel
ENTREES : donnes signaltiques du personnel
prestations
SORTIES : rmunrations, cotisations, impts
documents lgaux
TACHE : enregistrement des modifications de situation du personnel
FONCTION : enregistrer toute modification de situation
influant sur le calcul des rmunrations
(= codifier et copier)
ENTREES : donnes "familiales" communiques par l'employ
donnes "professionnelles" reues du service employeur
SORTIES : fichier signaltique mis jour
FONCTION : calculer les montants des rmunrations et retenues diverses
(= valoriser les prestations)
diter les documents accompagnant les paiements
ENTREES : fichier signaltique du personnel
prestations mensuelles enregistres
SORTIES : fiches de paie
virements bancaires
MODULE : calcul de l'impt
FONCTION : calculer le montant de l'impt retenir sur le salaire mensuel
ENTREES : montant du salaire imposable
barmes d'imposition
SORTIES : montant de l'impt, montant net du salaire
On a voqu au paragraphe prcdent les changes d'un systme ou sous-systme, processus permanent, avec
son environnement. Un processus ponctuel, tche ou module, qui ne produirait pas de donnes de sortie ne
prsenterait aucun intrt. En revanche, l'ensemble des donnes d'entre d'un tel processus pourrait, la limi-
te, tre vide (ex.: le modulefonction rand() du langage C fournissant des nombres pseudo-alatoires).
Adoptant un vocabulaire dynamique, on dira que tout processus possde au moins un flux de donnes entran-
tes et au moins un flux de donnes sortantes. Ceci peut tre schmatis par une figure laquelle on donne le
nom de bote noire (parce qu'elle cache le "comment" de la transformation).

1
Ce schma fonctionnel est valide pour tous les systmes, pas seulement les systmes d'information.
Niveau
Processus
Acteur
Entres
Sorties
Tche
Calcul des
Rmunrations
Automatique
Prestations
mensuelles
Fiches
de paie
Virements
bancaires
Signaltique
Travailleurs
Nous nous intressons dans cette partie du cours l'ordonnancement et la spcification des tches d'un
systme de traitement de l'information et nous n'y envisagerons le module que comme un moyen de dcrire
une tche.
c) Flux de donnes
La description interne d'un processus non lmentaire en dvoile la structure sous la forme de sous-processus
relis par des flux de donnes. Le schma de cette structure est un diagramme de flux. Par convention, tous
les sous-processus recenss sur un tel diagramme sont du mme niveau d'agrgation; on distingue donc des
diagrammes de flux
entre sous-systmes d'un mme systme ou d'un mme sous-systme hirarchiquement suprieur,
entre tches (singletons) ou groupes de tches d'un mme sous-systme,
entre modules (singletons) ou compositions de modules dans une tche.
Par convention, tout flux de donnes possde une et une seule origine, une et une seule destination, mais
plusieurs flux pourraient avoir un contenu identique, c'est--dire vhiculer des copies des mmes donnes.
1
Tout flux est orient : de son origine vers sa destination. Il se reprsente graphiquement par une flche.
REMARQUE. On le verra la lecture des exemples : les flux de donnes l'intrieur du systme d'informa-
tion refltent souvent, en une sorte d'"image", les flux concrets (de matires, de services ...) qui s'coulent
l'intrieur du systme oprant de l'entreprise.
Flux direct, Messages
Si la collection de donnes vhicules par un flux est "consomme" par le processus rcepteur; c'est--dire que
l'utilisation des donnes par ce processus les prive de toute nouvelle utilit, il s'agit d'un flux direct entre deux
processus et la priode de conservation des donnes vhicules est gale la priode qui spare l'excution
des deux processus metteur et consommateur.

1
Certaines mthodes admettent les regroupements et clatements de flux, c'est--dire qu'elles autorisent des
flux aux origines ou destinations multiples. Le procd prsente l'inconvnient de masquer l'existence du pro-
cessus qui opre le regroupement ou l'clatement.
GANE & SARSON DE MARCO
1
Enregistr.
Commandes
2
Prparation
Livraisons
Rservations
Enregistr.
Commandes
Prparation
Livraisons
Rservations
Un flux direct peut tre cyclique, c'est--dire qu'il relie deux excutions successives d'un mme processus :
sortant de l'excution t, entrant pour l'excution t+1.
1
Enregistr.
Commandes
2
Prparation
Livraisons
Rservations
Commandes
diffres
Enregistr.
Commandes
Prparation
Livraisons
Rservations
Commandes
diffres
Le processus d'origine ou de destination d'un flux ne se situe pas ncessairement l'intrieur du systme analy-
s, mais parfois dans son environnement. On distingue donc des flux internes et des flux externes. Un flux
externe est toujours reprsent comme un flux direct entre un acteur externe et un processus interne,
d'"enregistrement" pour les donnes entrantes, d'"dition" pour les donnes sortantes.
1
Enregistr.
Commandes
2
Prparation
Livraisons
E-1
Clients
Bons de
Commande
Factures
Rservations
Commandes
diffres
Enregistr.
Commandes
Prparation
Livraisons
Clients
Bons de
Commande
Factures
Rservations
Commandes
diffres
Les donnes vhicules par un flux direct composent des messages. S'il est destin un acteur humain ou s'il
mane d'un tel acteur, un message prend la forme d'un document, sur papier ou sur cran ... Le contenu dun
message peut tre dcrit par un sous-schma de donnes.
1
Du fait de son orientation, un flux direct dtermine un ordre entre les processus metteur (antcdent) et r-
cepteur (consquent) qu'il relie; il dtermine une succession de transformations et une progression entre les
tats successifs des collections de donnes vhicules. Par suite, le concept de flux direct constitue un outil
privilgi de l'analyse structure des traitements.
Un flux reliant deux tches est un flux rel, la matrialisation duquel sont affectes des ressources : un sup-
port de communication (papier, disquette, bande magntique, rseau de tlcommunication ...), un point
d'origine et un point de destination identifiables dans l'espace et le temps. Entre deux tches dtermines, il
n'existe normalement pas plus d'un flux de cette nature.
Les flux directs reprsents entre systmes ou sous-systmes sont des abstractions rcapitulatives d'une somme
de flux rels. Il n'existe pas de normes relatives au nombre de flux directs reprsents ce niveau (il n'est en
effet pas obligatoire de rcapituler en un seul agrgat abstrait).
Flux indirect, Dpt de donnes
Si l'utilit des donnes vhicules par un flux n'est pas puise du fait de leur utilisation par le processus r-
cepteur, les donnes en question sont mmorises dans un dpt de donnes.
Un flux indirect relie un processus et un dpt de donnes. Il peut tre orient de trois faons :
du dpt vers le processus : flux entrant, consultation du dpt de donnes;
du processus vers le dpt : flux sortant, mise jour du dpt de donnes;
dans les deux directions : entre et sortie, consultation et mise jour.
Remarque. Si le seul but d'une consultation est d'obtenir les valeurs prcdentes en vue de les modi-
fier, on dessinera un flux unidirectionnel de mise jour.
GANE & SARSON
1
Enregistr.
Commandes
2
Prparation
Livraisons
E-1
Clients
D-1 Catalogue
D-2 Clients
D-3 Stocks
Bons de
Commande
Factures
Rservations
Commandes
diffres

1
Cf. chapitre 3.
DE MARCO
Enregistr.
Commandes
Prparation
Livraisons
Clients
Catalogue
Clients
Stocks
Bons de
Commande
Factures
Rservations
Commandes
diffres
REGLE. A l'intrieur du systme de rfrence, tout dpt de donnes doit participer au moins un flux de
mise jour (garnissant le dpt) et au moins un flux de consultation (sinon, le dpt est dpourvu d'utilit).
Le contenu d'un dpt de donnes sera nomm et dcrit par un schma de donnes. Le contenu d'un flux indi-
rect ne vhiculant qu'une partie des donnes du dpt sera lui aussi nomm et dcrit par un sous-schma de
donnes.
1
A un flux indirect sont ncessairement associes des oprations d'accs aux donnes du dpt. On exprime
habituellement ces oprations par rapport aux occurrences d'enregistrements :
insrer (ajouter), remplacer ou supprimer une ou plusieurs occurrences de tel(s) type(s),
obtenir (lire, consulter) une ou plusieurs occurrences de tel(s) type(s).
Puisqu'un nombre quelconque de processus peuvent accder aux mmes dpts, ces derniers n'introduisent
dans le schma aucune contrainte. Ds lors, dans la recherche des processus interconnecter, les concepts de
dpt de donnes et de flux indirect apparaissent accessoires. Plusieurs formes de diagrammes de flux n'en
font d'ailleurs pas mention. Plus important : les mthodes courantes d'analyse par les flux ne fournissent au-
cun critre d'identification des dpts de donnes.
Un schma dcrivant les flux physiques de donnes dans un systme rel peut mentionner comme dpts les
fichiers rels, magntiques et autres, utiliss par les traitements. Pour une description conceptuelle des flux,
antrieure la dfinition des fichiers rels, nous prconisons les dispositions suivantes :
1) entre un dpt de donnes particulier et un processus particulier, il n'existe pas plus d'un flux in-
direct;
2) il existe entre les donnes conserves dans un mme dpt une parent smantique reconnaissable
l'existence d'identifiants communs (un mme dpt peut contenir la fiche signaltique individuelle
des employs et une description des fonctions qu'ils occupent, mais un dpt ne contient pas la fois
des donnes relatives aux clients et aux produits ...); cette rgle tend distinguer une collection de
donnes dont le schma logique sera arborescent, dont la structure pourra supporter directement la
programmation
2
cette solution est recommande dans un diagramme de flux entre tches;

1
Cf. chapitre 3.
2
Cf. chapitre 4.
3) la priode de mmorisation des informations conserves dans un mme dpt est dfinie par les
mmes rgles; concrtement, cela signifie que toutes les occurrences de donnes sont insres par
des excutions d'un/des mme(s) processus et supprimes par des excutions d'un/des mme(s) pro-
cessus (dans un diagramme de flux entre sous-systmes, on peut donc mentionner un dpt de "don-
nes personnelles", mis jour par le sous-systme de gestion du personnel; mais, dans un diagramme
de flux entre tches, on distinguera diffrents dpts, mis jour par des tches diverses : fiches si-
gnaltiques des employs, relev des prestations quotidiennes du personnel, etc).
Permabilit des classes de flux directs et indirects
Dans la tche de Prparation des Livraisons (voir la figure prcdente), observons le flux cyclique des
Commandes diffres. Il a en commun avec le dpt Stocks de se trouver la fois en entre et en sortie de la
transformation et de se retrouver d'une excution l'autre de cette tche; ds lors, ne s'agit-il pas d'un dpt
de donnes ? Il a en commun avec le flux direct des Commandes reues que son contenu finira par tre
"consomm" par l'activit de Prparation des Livraisons; ds lors, ne s'agit-il pas d'un flux direct de messa-
ges ? Mais, si les rgles de procdure autorisent les livraisons partielles ( concurrence des quantits dispo-
nibles), les valeurs de quantits en commande volueront de la mme manire qu'voluent les quantits en
stock ...
Cet exemple montre qu'il n'existe pas de solution de continuit entre les catgories utilises par l'analyste.
1.2. Structures typiques
a) Applications sans flux directs
Certaines applications informatiques se caractrisent par l'absence de flux directs entre les tches. Il s'agit
d'applications dont l'objet principal est de tenir jour et disponible un "stock" d'informations, une "banque de
donnes". Exemple : le fichier des membres d'une association.
Premire variante : l'application comporte des tches de mise jour, consultation et listage des donnes,
entre lesquelles n'existe aucun ordonnancement (on peut imaginer de consulter un fichier vide, n'ayant encore
fait l'objet d'aucune mise jour ...).
Respons. Fichier
Mise jour
Consult.
Edition
Liste
Gestion des Membres
Seconde variante : une squence d'tats successifs est dfinie sur les donnes d'un dpt. L'application de
gestion de ce dpt comporte diffrentes tches de mise jour, dont chacune a pour objet de faire subir un
sous-ensemble du dpt une transition d'tat autorise. Ces tches doivent videmment se succder selon un
ordre dfini. L'numration des transitions d'tat constitue souvent un outil puissant pour la recherche des
tches dans certaines applications.
Exemple : tablissement du devis d'une entreprise de construction :
1) enregistrement du mtr (quantification des plans) de l'ouvrage tabli par l'architecte;
2) correction du mtr par l'indication des quantits recalcules par l'entrepreneur;
3) affectation de moyens de production (matriaux, etc.) aux diffrents postes du mtr;
4) calcul du prix de revient, sur la base du cot des diffrents moyens;
5) tablissement du prix de vente, par compltage (marges ...) du prix de revient.
Enregistr.
mtr
Correction
mtr
Affectation
des moyens
Calcul du
prix revient
Etablisst.
prix vente
Mtr/Devis
Mtreur
Deviseur
Catalogue
Prix
Tarif
Plans + Mtr
Architecte
Mtr
(Postes &Quantits)
Devis
Descript.
moyens
Moyens &Qts Slection
des moyens
Ajustements
de prix
1.
2.
3.
4.
5.
automatique
interactif
interactif
interactif
interactif
Quantits
calcules
Modifications
Quantits
Quantits <--
--> Prix
Etablissement Devis
b) Dcomposition suivant un axe spatio-temporel dominant
On peut voir un flux direct comme un dplacement d'informations dans l'espace et/ou le temps. De nombreux
systmes se caractrisent par des activits (des tches) clairement distantes les unes des autres. Tches qui se
rpartissent soit dans le temps, soit dans l'espace.
Certaines applications possdent une structure temporelle marque par un chelonnement priodique des
tches. Tel est, par exemple, un systme d'administration des salaires et appointements, dans lequel on peut
distinguer les groupes de tches suivants :
tches priodicit variable : enregistrement des donnes signaltiques des travailleurs;
tches quotidiennes : enregistrement des prestations (prsences et absences);
tches mensuelles : tablissement de la paie des travailleurs;
tches trimestrielles : versements aux organismes de prlvement (fisc, scurit sociale ...);
tches annuelles : tablissement d'attestations (fiches fiscales, cotisations de scurit sociale ...).
Certains systmes sont caractriss par une structure spatiale refltant la multiplicit des sites d'oprations.
Exemple classique : le binme centralisation/dcentralisation, maison-mre/filiale ... Les processus, mais
aussi les dpts de donnes, sont rpartis entre le site central et les sites priphriques. Les flux de messages
entre sites s'y avrent essentiels l'existence du systme global.
c) Systmes rguls
Pour survivre et fonctionner harmonieusement, un systme a besoin de mcanismes de rgulation. Nous al-
lons illustrer la chose par le cas du sous-systme AchatsVentesStocks d'une entreprise commerciale.
Prparation
Livraisons
Enrcgistr.
Commandcs
Commandcs
rcucs
Clicnts Stocks
Cdcs.DiII.
Etablisst.
Commandcs
Rccption
Fourniturcs
Fourn.
Commandcs dc
Rapprovist.
Fourniturcs
Invcntairc
Magasin
Stocks
ajusts
RcIus
Rcjcts
Facturcs
Id. Produits a
commandcr
Acbats
Vcntcs
Bons dc
Commandc
Acbats-Vcntcs-Stocks (diagrammc simpliIi)
Le systme possde un flux entrant (les approvisionnements auprs des fournisseurs) et un flux sortant (les
livraisons aux clients); il contient un dpt (les stocks), jouant le rle de rservoir ou de tampon (il existe
d'autres dpts, consults mais non mis jour, qui ne sont pas reprsents sur la figure). On peut en donner
cette image : un bassin quip de robinets de remplissage et de vidange. Le rservoir (les stocks) constitue
l'interface entre les deux sous-systmes (robinets) d'entre (les achats) et de sortie (les ventes).
Toute sortie est suivie d'une analyse de l'tat du rservoir; il peut en rsulter un message (identification de
produit commander) agissant sur le dbit du flux entrant (commande de rapprovisionnement). Un tel effet
des sorties sur les entres a reu le nom de boucle de rtroaction (en anglais : "feedback"). Ce concept a t
mis en avant et formalis par les cybernticiens.
1
L'existence d'un rservoir (les stocks) donne du "mou" au systme et lui permet de fonctionner sans -coups
(sans ruptures de stocks). Un tel tampon a pour rle de garantir la continuit de fonctionnement du systme.
En vue de rduire le nombre de pannes (refus de commandes), le systme peut tre perfectionn par l'exis-
tence d'un second tampon (les commandes diffres).
Les mcanismes rgulateurs voqus jusqu'ici sont internes au systme et font partie de son fonctionnement
habituel. Un autre mcanisme rgulateur est reprsent par la tche priodique (annuelle) d'inventaire, dans
son aspect d'ajustement des stocks thoriques aux stocks physiques; il s'agit dans ce cas d'une intervention
extrieure sur le systme, visant pallier les "fuites" non dtectes par le "programme" normal du systme.
On devrait imaginer une intervention analogue sur les commandes trop longtemps diffres ...
NOTE. Remarquer que la fermeture de la boucle des rapprovisionnements (commandes fournitures) im-
plique l'acteur externe Fournisseurs. La fermeture ou compltude d'un schma de flux implique habituelle-
ment l'intervention de l'environnement du systme ou la mention de tches "manuelles" en plus des tches au-
tomatiques.
1.3. Validation des diagrammes de flux
a) Syntaxe des diagrammes de flux
Relations entre composants
Il y a lieu de vrifier les relations indiques entre les divers objets reprsents sur un diagramme de flux :
tous les processus reprsents sur un diagramme de flux doivent tre du mme niveau d'agrgation : sous-
systmes, tches ou groupes de tches, modules ou compositions de modules;
tout flux possde exactement une origine et une destination; il doit avoir une des trois formes suivantes :
flux externe reliant un processus et un acteur externe,
flux direct de messages reliant deux processus ou deux excutions successives d'un mme processus,
flux indirect reliant un processus et un dpt de donnes;
tout processus reprsent sur un diagramme de flux doit avoir au moins un flux entrant et un flux sortant
(exceptionnellement, une tche ou un module pourrait ne pas avoir de flux entrant);
dans le cadre global du systme de rfrence, tout dpt de donnes doit faire l'objet d'au moins un flux de
mise jour et un flux de consultation;
entre deux composants quelconques, il n'existe, en principe, pas plus d'un flux, sauf si l'un des deux compo-
sants est un objet permanent (acteur externe ou sous-systme).

1
N. WIENER : Cyberntique et socit, trad. franaise; d. des Deux Rives, 1952.
Dnomination des composants
Tout composant acteur externe, processus, dpt de donnes doit tre nomm.
Le nom d'un processus est normalement form d'un nom indiquant le type de transformation opre et
d'un complment dsignant le flux de sortie principal.
Exemples : tches : enregistrement des commandes-clients
prparation des livraisons
expdition des factures
modules : vrification de date
calcul de l'impt
mise en page des factures
Tout flux de messages doit tre nomm. Le nom d'un tel flux est normalement form du nom de type des
messages et d'un qualificatif d'tat.
Exemples : bons de commande valides, commandes enregistres, commandes diffres.
Il est cependant quelquefois difficile d'attribuer un nom aux flux agrgs reprsents au niveau des
systmes ou sous-systmes. Dans ce cas, plutt que de recourir des noms sans signification, on
pourra tolrer de laisser ces flux sans dsignation.
Un flux indirect n'est habituellement pas nomm si son contenu est gal celui du dpt qu'il concerne.
N.B. On vitera les vocables passe-partout du genre "donnes, informations" ou "traitement" ...
Remarque. Mise en page d'un diagramme de flux
Dans un diagramme de flux, il importe d'viter les flches se croisant et tournant dans tous les sens; un tel
diagramme serait rbarbatif et sa lecture dcourage. On suivra au maximum les recommandations suivantes.
L'armature d'un diagramme de flux est forme de l'ensemble des sous-processus reprsents. De manire
respecter les habitudes de perception du lecteur, les symboles figurant ces processus seront dessins, en sui-
vant l'ordre chronologique (matrialis par les flux directs, s'il en existe dans le diagramme), de haut en bas,
au centre de la page. Si le diagramme comporte des boucles de rtroaction, les flux en cause seront reprsen-
ts par des flches remontantes.
Les autres lments du diagramme acteurs externes, dpts de donnes seront disposs sur le pour-
tour et, ventuellement, ddoubls. La rgle sera ici d'viter un maximum de croisements de flches repr-
sentant des flux.
Voir particulirement, plus haut, les exemples de diagrammes d'Applications sans flux directs.
b) Hirarchisation des diagrammes
Un diagramme de flux prsente les relations entre sous-processus d'un processus dcomposable; ce dernier est
lui-mme figur par une bote noire dans un diagramme hirarchiquement suprieur ... Il est possible d'tablir
une hirarchie de diagrammes de flux : toute bote noire d'un diagramme "parent" peut tre "clate" sous la
forme d'un diagramme "enfant". En quelque sorte, un diagramme de flux est un zoom grossissant.
Les rgles suivantes doivent tre respectes.
Racine de la hirarchie : un diagramme de contexte, comprenant une seule bote noire, reprsente le systme
de rfrence. Cette bote noire doit avoir au moins un flux de messages entrants et un flux de messages sor-
tants, connects des acteurs ou processeurs externes appartenant l'environnement du systme. Ce dia-
gramme ne fait mention d'aucun dpt de donnes.
Magasin
Fourn.
Fourniturcs
Clicnts
Facturcs
Commandcs
Rapprovist.
Ajustcmcnts
dc Stocks
Acbats
Vcntcs
Stocks
Compta
-bilit
Ecriturcs
Comptablcs
Bons dc
Commandc
1) L'environnement d'un diagramme enfant acteurs externes, processus, dpts de donnes doit tre
identique celui de la bote noire parente.
2) Les entres et sorties d'un diagramme enfant doivent tre quivalentes aux entres et sorties de la bote
noire parente. En d'autres termes, chaque flux franchissant la frontire d'un diagramme enfant est identique
un flux de la bote parente ou constitue un sous-ensemble d'un tel flux; dans le second cas, il doit y avoir, au
sens mathmatique, partition du flux parent.
Clients
Stocks
Fourn.
Fournitures
Inventaire
Magasin
Stocks
ajusts
Factures
Ventes
Compta
-bilit
Ecritures
Comptables
Ecritures
Comptables
Commandes
Rapprovist.
Bons de
Commande
Achats
S/Syst.
S : Achat s-Vent es-S t o cks
S/Syst.
S/Syst.
Prparation
Livraisons
Enrcgistr.
Commandcs
Commandcs
rcucs
Clicnts
Cdcs.DiII.
Rcjcts
Stocks
Compta
-bilit
Ecriturcs
Comptablcs
Acbats
Id. Produits a
commandcr
Bons dc
Commandc
Cataloguc
Clicnts
S/Syst. Vcntcs
Tcbc
Tcbc
Facturcs
Tcbc
Edition
Facturcs
JustiIicatiIs
dc Livraison
L'analyste prendra soin de rpercuter sur le diagramme parent les flux ajouts sur un diagramme enfant (voir,
dans la dernire figure ci-dessus, l'Identification des Produits commander). Ceci pourrait toutefois tre n-
glig pour les flux de messages refltant les cas d'erreurs que l'analyse plus globale n'avait pas mis en vidence
(exemple : les Rejets lors de l'Enregistrement des commandes).
1.4. Spcification d'un processus
La description complte dun processus opratoire, en particulier dune tche de traitement de linformation,
comporte trois volets :
lidentification de la fonction remplie par le processus, qui en dvoile lutilit;
la spcification des rgles qui contraignent les oprations et en garantissent la validit ;
la description de la procdure qui dtaille la mthode mettre en uvre.
Les deux premiers volets prcisent les besoins satisfaire; ils dfinissent "conceptuellement" une classe de
problmes rsoudre. La description de la procdure vient plus tard; elle fait partie de la description "orga-
nique" dune solution.
1
REMARQUE. Idalement, la description d'un processus devrait faire abstraction du contexte dans
lequel il a t dcouvert; de la sorte, cette description sera rutilisable dans un autre contexte. Si la
chose s'avre relativement malaise aux niveaux les plus agrgs (systme, sous-systmes), elle de-
vient davantage ralisable mesure que l'on descend vers la description des composants lmentaires.
Ce devrait au moins tre le cas de la description d'un module programmable : la description d'un mo-
dule de vrification syntaxique d'une date devrait convenir la validation de toute espce de date ...

1
Cf. chapitre 1.
a) Description externe de la fonction
Un processus de traitement de l'information poursuit une finalit, que nous appelons sa fonction, et qui
consiste en une transformation de donnes d'entre en donnes de sortie.
Dans un premier temps, la description externe (du "quoi") d'un processus a pour but d'en montrer l'effet, en
mettant en vidence les diffrences entre l'ensemble des donnes d'entre et l'ensemble des donnes de sortie.
Quant aux oprations transformatrices, elles ne sont pas dcrites comme telles. Il s'agit en quelque sorte de
commenter le dessin d'une bote noire.
1) A ce point, la spcification d'un flux d'entre ou de sortie se rduit dfinir le sous-schma des donnes
vhicules.
1
(L'indication d'origine ou de destination du flux, de mme que la quantification des occurrences
vhicules appartiennent la dfinition du contexte voir la remarque ci-dessus.)
2) Dans le cas d'un processus ponctuel, tche ou module, on indiquera les types d'oprations d'accs relatives
chaque flux :
flux direct (messages) : entre = Recevoir;
sortie = Emettre;
flux indirect (dpt) : consultation = Obtenir (Lire);
mise jour = Insrer (Crer), Remplacer (Modifier), Supprimer.
3) Dans cette premire description globale, la fonction proprement dite du traitement sera rsume en quel-
ques propositions expliquant synthtiquement la transformation subie par les donnes.
Exemples : MODULE : calcul de l'impt
FONCTION : calculer le montant de l'impt sur le salaire imposable
en appliquant les barmes d'imposition adquats;
calculer salaire net = imposable - impt
RECOIT : montant du salaire imposable
OBTIENT : barmes d'imposition
EMET : montant de l'impt, salaire net
MODULE : vrification syntaxique de date
FONCTION : tester la validit syntaxique dune date
RECOIT : date
EMET : signal-OK ou signal-KO
TACHE : prparation des commandes de rapprovisionnement
FONCTION : pour chaque produit commander,
dterminer par consultation
la quantit commander et le fournisseur;
diter le bon de commande
RECOIT : identification des produits commander
OBTIENT : stocks, catalogue, fournisseurs
EMET : bons de commande aux fournisseurs

1
Cf. chapitre 3.
b) Description de l'interface d'une tche
La tche est l'unit de traitement avec laquelle les utilisateurs changent des donnes. A ce niveau, il est donc
ncessaire de dcrire l'interface du processus : prciser en dtail la forme concrte, physique, des collections
de donnes entrantes et sortantes, du moins celles pour lesquelles l'environnement utilisateur impose des
contraintes. Une telle description prend gnralement la forme d'un dessin convenablement annot.
Exemples : formulaires de consultation et saisie de donnes l'cran; rapports imprims;
enregistrements de bandes magntiques ou messages changs entre divers organismes
(banques, fisc, scurit sociale ...).
c) Spcification dtaille des rgles
Niveaux de dfinition des rgles
Les rgles de traitement constituent une expression formelle et oprationnelle des objectifs et contraintes fixs
par l'utilisateur du systme d'information.
Au niveau d'un systme ou sous-systme, on ne peut gure indiquer que des objectifs de performance tech-
nique ou conomique, par exemple : "traiter et facturer 95 % des commandesclients le jour mme de leur
rception".
Les rgles pratiques sont dcouvertes dans le contexte d'une tche, traitement lmentaire aux yeux de l'uti-
lisateur; elles sont ultrieurement rparties sur les modules dcoups par le technicien.
Il est techniquement indispensable dassocier chaque module lnonc des rgles quil est charg
dappliquer. En outre, il est rationnel dinclure dans la description dune tche les rgles dont elle est
le sige; cependant, cet nonc sera souvent facilit si lon introduit dans cette dfinition un mini-
mum de structure grce une dcomposition en modules, ft-elle fictive (cest--dire diffrente de
celle quadopteront finalement les techniciens).
Si des rgles sont nonces diffrents niveaux de dcomposition, il convient de vrifier la cohrence des
spcifications :
les rgles attaches un module ne peuvent contredire celles de la tche : elles prcisent une par-
tie des rgles de la tche;
les ensembles de rgles fournis aux diffrents niveaux doivent tre quivalents.
Expression des rgles
Les rgles appliques dans le cadre dune tche de traitement de linformation sont principalement des prdi-
cats dterminant la qualit des donnes traites. Ces prdicats constituent les contraintes dintgrit invento-
ries dans la dfinition des donnes.
1
Il est donc assez naturel de rattacher directement les rgles aux flux de
donnes.
Exemples : MODULE : vrification syntaxique de date
RECOIT : date
- REGLES : date numrique et mois {1..12} et jour {1..31}

1
Cf. chapitre 3.
MODULE : mise jour des stocks
FONCTION : mettre jour les stocks suite lacceptation des commandesclients
et identifier les produits rapprovisionner
RECOIT : commandes-du-jour (0:N commande (1:1 en-tte, 1:N ligne))
MET-A-JOUR : stocks (0:N stock)
- REGLES : pour n-produit de stock = n-produit de ligne de commande
total-sorties = prcdent + qt-commande de ligne de commande
qt-en-stock = total-entres total-sorties
EMET : produits--rapprovisionner (0:N id-produit)
- REGLES : pour n-produit de id-produit = n-produit de stock
si qt-en-stock prcdente stock-plancher
et qt-en-stock nouvelle < stock-plancher
date = aujourdhui
1) En vue de faciliter la lecture des rgles, les flux dentre sont numrs avant les flux de sortie,
dans lordre : RECOIT, OBTIENT, MET-A-JOUR, EMET.
2) Chaque flux est dcrit sous la forme dun schma de donnes arborescent.
1
3) Dans les rgles, les expressions pour cl et si dterminent les correspondances entre flux
(on pourrait laisser ltat implicite la partie en italique des expressions pour).
4) Les rgles attaches aux flux de sortie servent de post-conditions au processus dcrit :
les relations quelles expriment doivent tre rendues vraies par lexcution du processus.
Vrification des rgles
Le caractre faisable des oprations doit tre vrifi par un contrle de compltude et de non contradiction de
l'ensemble des rgles de drivation :
pour toute variable appartenant un flux de sortie, doit exister au moins une rgle capable de la
produire;
moins d'tre dfinie comme variable intermdiaire, toute variable rfrence dans une rgle doit
appartenir un flux;
toute variable rfrence dans une rgle, soit appartient un flux d'entre, soit est le rsultat de
l'application d'une rgle.
d) Dfinition interne de la procdure
Dans un second temps, une description interne (du "comment") du processus explicite les mcanismes ca-
chs l'intrieur de la bote noire.
On peut imaginer diffrentes manires de prsenter une procdure. Nous proposons ici la forme algorithmi-
que d'un pseudo-code faisant expressment rfrence aux flux de donnes qui se croisent dans tout processus.
Comme au paragraphe prcdent, nous supposons que le contenu de chaque flux est une collection de donnes
reprsente par un schma logique arborescent; ces collections de donnes pourront donc supporter directe-
ment une programmation.
2
Si tel n'est pas le cas d'un flux, on le dcomposera en flux partiels de structure
arborescente.

1
Cf. chapitre 4.
2
Cf. chapitre 4.
Trois sries de rgles doivent tre formules :
les accs aux donnes (ces rgles sont recopier de la description externe),
les correspondances entre les composants des diffrents flux de donnes,
les rgles de drivation des sorties partir des entres : dtermination des valeurs mais aussi des
occurrences (par exemple, un contrle de validit slectionne des occurrences, celles qui satisfont
aux rgles de validit).
Un pseudo-code est un texte dcrivant un algorithme au moyen d'un pseudo-langage de programmation.
Pseudo-langage, car il ne fait pas l'objet de traduction automatique. Par suite, la syntaxe du langage n'est
pas vritablement contraignante et n'a rien d'obligatoire, le langage peut tre incomplet (par exemple, ne
pas offrir les "instructions" d'ouverture et fermeture de fichier), les objets manipuls ne sont pas les objets
techniques concrets manipuls par les programmes, mais des prfigurations conceptuelles ...
Le pseudo-langage doit permettre d'exprimer les trois sries de rgles qui dfinissent toute procdure.
1
1) La spcification des oprations d'accs aux donnes comporte thoriquement les lments suivants :
l'identification du flux vis et le nom du composant transmis par le flux;
le type d'opration :
recevoir (flux direct, messages entrants),
mettre (flux direct, messages sortants),
obtenir (flux indirect, consultation d'un dpt),
insrer, remplacer, supprimer (flux indirect, mise jour d'un dpt);
dans le cas d'une opration obtenir de consultation,
l'identification du critre de slection,
le traitement de raction aux cas d'erreurs (inexistence du composant demand).
Schmatiquement :
opration composant de flux
[ slection = critre ]
[ si erreur alors traitement [ sinon ] ]
2) La mise en correspondance des quantits d'information se fait en rpartissant les oprations de la proc-
dure, y compris les oprations d'accs aux donnes, dans des blocs de traitement appliqus aux composants
des flux d'entre. Toute opration recevoir ou obtenir est donc thoriquement suivie d'une construction de la
forme suivante :
pour chaque composant
traitements
fin
Si le flux d'entre possde une structure hirarchise (arborescente), plusieurs blocs s'embotent les uns dans
les autres, conformment au schma suivant. Soit 0, le niveau de la racine de l'arborescence et 1,2... les ni-
veaux de dcomposition successifs :

1
Ce pseudo-langage s'inspire du langage de programmation MCL Modular Control Language dfini
par A. CLARINVAL : MESANGE : Mthode et Systme d'Analyse et de Programmation de Gestion. Cette
prsentation est fort proche de celle d'un Procedure Action Diagram dans la mthode IEM de J. MARTIN.
pour chaque composant de niveau 0
.....
.....
.....
fin
.....
fin
.....
fin
Exemple : soit le flux CDES-DU-JOUR (0:N COMMANDE (contenant 1:N LIGNE-COMMANDE))
pour chaque CDES-DU-JOUR
.....
pour chaque COMMANDE
.....
pour chaque LIGNE-COMMANDE
.....
fin
.....
fin
.....
fin
3) Aucune formulation particulire n'est suggre ici pour exprimer les rgles de transformation appliques
par la procdure. Il est souvent possible, comme au paragraphe prcdent, d'adopter la syntaxe des rgles as-
socies aux schmas de donnes.
1
Les rgles dfinissant les conditions d'existence des occurrences de don-
nes dans les flux seront habituellement prsentes sous la forme d'oprations d'accs aux flux.
4) L'analyste est juge de ce qu'il peut laisser l'tat implicite. Dans les exemples qui suivent, on peut raison-
nablement penser qu'il peut en tre ainsi au moins pour les parties en italique.
Exemples : MODULE : vrification syntaxique de date
RECOIT : date
PROCEDURE : recevoir date
pour chaque date
si (date numrique et mois {1..12} et jour {1..31})
mettre signal-OK
sinon
mettre signal-KO
fin
fin

1
Cf. chapitre 3.
MODULE : cration de factures
FONCTION : calculer et crer les factures
RECOIT : commandes-du-jour (0:N commande (1:1 en-tte, 1:N ligne))
OBTIENT : clients (0:N fiche)
OBTIENT : tarif (0:N produit)
EMET : factures-du-jour (0:N facture (1:1 en-tte, 1:N ligne, 1:1 fin))
PROCEDURE : recevoir commande de commandes-du-jour
pour chaque commande
pour chaque en-tte de commande
obtenir fiche de clients slection = n-client
pour chaque fiche
mettre en-tte de facture de factures-du-jour
fin
fin
pour chaque ligne de commande
obtenir produit de tarif slection = n-produit
pour chaque produit
montant-factur = prix-de-vente * qt-livre
fin
mettre ligne de facture de factures-du-jour
fin
total-facture = montant-factur
mettre fin de facture de factures-du-jour
fin
2. Schma dynamique
Tout flux de messages entre un processus metteur et un processus rcepteur contribue rendre possible l'ex-
cution du second. Constater l'existence d'un tel flux ne suffit cependant pas rendre compte des conditions
d'excution et d'enchanement des traitements, ce qui requiert l'tablissement d'un schma logicodynami-
que des traitements.
S'inspirant de la thorie des rseaux de Petri,
1
plusieurs modles pour l'tude dynamique des systmes de trai-
tement de l'information sont apparus aux alentours de 1980-85. Citons le modle dfini par F. BODART et Y.
PIGNEUR dans le cadre de la mthode IDA,
2
ainsi que celui propos par la mthode MERISE.
3
Pour l'es-
sentiel, nous nous inspirons ici des propositions de la mthode IDA.
2.1. Contenu du schma dynamique
Un schma dynamique met en uvre les objets suivants : des processus, des vnements et des moniteurs.
On peut considrer les deux derniers concepts comme compltant ceux du schma fonctionnel.
4
Comme dans toute modlisation, on s'intressera ici aux types d'vnements, types de processus, etc. En parti-
culier, plusieurs (occurrences de) processus d'un mme type (par exemple, l'enregistrement d'une com-
mande) peuvent se drouler simultanment ...
a) Processus
Lors de l'laboration d'un schma dynamique, on considre les processus qui, dans le temps, possdent un
dbut appel dclenchement et une fin appele terminaison. Les deux moments de dclenchement
et terminaison sont deux moments remarquables, au sens propre de discernables, correspondant chacun un
changement d'tat du processus : le dclenchement fait passer celui-ci de l'tat inexistant l'tat actif, la ter-
minaison le fait passer de l'tat actif l'tat termin.
5
Caractris par un dbut et une fin, un tel processus ne peut pas tre un ensemble d'oprations rcurrentes,
comme un sous-systme. Il ne peut s'agir que d'une tche ou d'un module.
b) Evnement
Un vnement reprsente
un changement d'tat,
survenant l'intrieur du systme dcrit ou dans son environnement,
toujours observable de l'intrieur du systme dcrit,
et auquel ce dernier doit ragir par l'excution, immdiate ou diffre, de certains processus.

1
Cf., par exemple, J.L. PETERSON : Petri Nets; in ACM Computing Surveys, vol. 9, n 3, sept. 1977;
BRAHMS : Thorie et pratique des rseaux de Petri; Masson, 1983.
2
F. BODART, Y. PIGNEUR : Conception assiste des systmes d'information : mthodes, modles, outils;
Masson, 1989.
3
4
Les dpts de donnes n'interviennent pas dans la description de la dynamique.
5
Un modle prenant en compte les ressources ncessaires l'excution des processus distinguera d'autres
tats, comme, par exemple, l'tat interrompu ou suspendu par suite d'indisponibilit temporaire des ressour-
ces. La mthode IDA propose un tel modle.
Le changement d'tat observ concerne des donnes conserves dans les dpts du systme (par exemple, la
rception d'un bon de commande, l'puisement d'un stock ...) ou un processus qui, par exemple, se termine.
Sauf le cas particulier, voqu ci-aprs, des vnements de calendrier, la survenance d'un vnement est tou-
jours provoque par un processus antcdent, qui en informe un ou plusieurs processus consquents.
1
Un
vnement non observ n'est pas susceptible d'entraner une raction et n'est donc pas prendre en considra-
tion. Ce qui est fondamental, c'est l'information relative aux vnements. Cette information est vhicule par
des messages ou transmise par des signaux.
Nous avons dfini plus haut le concept de message. Un message est une information variable. Le plus com-
munment, il renseigne sur un changement d'tat survenu parmi les donnes dtenues dans les dpts du sys-
tme.
Exemples : identification d'un produit commander par suite d'puisement de stock, avec la quantit
facture refltant une vente
criture comptable refltant la mme vente
Un signal est une information invariable. Il renseigne sur un changement d'tat d'un processus, le plus sou-
vent sa terminaison. Un signal constitue un cas limite de message : le message "vide". On peut le voir
comme une entit, dont toute occurrence est discernable, mais qui ne possde pas d'attribut descriptif, pas de
texte (penser, de manire image, un "bip" sonore). Nonobstant, un signal possde un nom de type, tel
qu'il en identifie clairement la provenance : nom du processus metteur + qualificatif d'tat de ce proces-
sus. Exemple : "Prparation des Livraisons termine".
Sur un diagramme de flux, un signal peut tre reprsent sous la forme d'un flux direct entre processus.
Afin d'en indiquer la nature particulire, on pourrait le reprsenter par un trait discontinu ou bien placer son
nom entre parenthses ...
Exemple : le signal "Prparation des LivraisonsClients termine" doit tre attendu avant de dclencher le
processus de Prparation des Commandes de Rapprovisionnement; dans une autre organisation, cette attente
peut ne pas tre souhaite : la Prparation d'une Commande de Rapprovisionnement pourrait tre dclenche
immdiatement et automatiquement par l'mission du seul message "Identification d'un Produit Comman-
der".
Prparation
Livraisons
Etablisst.
Commandcs
Id. Produits a
commandcr
(Livraisons
tcrmincs)
Cas particulier : les vnements de calendrier. L'activit d'un systme, l'excution de processus, est souvent
conditionne par l'coulement du temps. Par exemple, tel processus doit tre activ "tous les vendredis 16
heures". On considrera donc que l'environnement de tout systme comporte un processus permanent "hor-
loge" ou "calendrier", dlivrant des messages de mesure du temps (exemple de message : "nous sommes
vendredi, il est 16 heures"). Le fait de situer ce processus dans l'environnement du systme dispense de le
dcrire.
Calcul dcs
Rmunrations
Calcn-
dricr
5 jours
Iin mois

1
Rappelons que les processus extrieurs un systme ne sont pas identifis dans la description de ce systme.
Tous les types d'vnements n'ont pas le mme degr de ncessit. Normalement, les vnements de calen-
drier et les signaux de transition d'tat des processus ne servent qu' ordonnancer l'usage des ressources affec-
tes l'excution des oprations; en revanche, les messages refltant l'volution des donnes sont indispensa-
bles la validit fonctionnelle des traitements, c'est--dire l'intgrit de leurs rsultats. Un schma (un dia-
gramme de flux) ne mentionnant que des messages de la seconde catgorie est fonctionnel il dcrit une
classe de problmes; un schma mentionnant les autres types d'vnements est chronologique et dcrit des
phnomnes contingents une organisation il dcrit une solution. L'analyste la recherche d'une nou-
velle solution, qui ne veut pas simplement rafrachir une solution existante, doit clairement faire cette
distinction !
c) Moniteur
D'une manire gnrale, la survenance d'un vnement ou, plus prcisment, sa notification ne suffit pas
dclencher l'excution d'un processus consquent. Il est frquent que l'on doive attendre la survenance d'une
combinaison d'vnements, c'est--dire la rception de diffrents messages ou signaux, avant de dclencher en
raction l'excution d'un ou plusieurs processus. N'est pas rare, en effet, une situation du genre de celle-ci, o
s'accumulent diffrents messages ou signaux :
existence de messages refltant une situation (ex.: bons de commande reus des clients),
condition horaire ou de calendrier (ex.: entre 15 et 16 heures),
demande expresse d'un responsable (ex.: "commencez la Prparation des Livraisons").
La gestion des vnements est assure par des moniteurs. Un moniteur est un processus, du mme niveau
(tche ou module) que les pocessus dont il doit contrler lenchanement, thoriquement permanent (en r-
alit, activation chronique) et qui
surveille l'arrive des signaux et messages;
assure, si besoin est, la mmorisation temporaire de ces informations;
analyse les vnements ainsi signals pour vrifier la condition de terminaison de l'attente;
dclenche l'excution des processus consquents, en leur transmettant les signaux et messages adquats.
Prparation
Livraisons
Etablisst.
Commandes
(Livraisons
termines)
MONIT. 01
Calen-
drier
Magasin
16 heures
go!
Id. Produits
commander
Id. Produits
commander
Un moniteur est un processus du mme niveau d'agrgation que les processus qu'il est charg d'enchaner. Il
prsente ceci de particulier qu'il n'opre aucun changement de forme sur les donnes (les messages) qu'il
"traite" et qu'il n'accde aucun dpt de donnes.
Un processus moniteur peut reproduire en sortie, sans en modifier le contenu, certains des messages reus en
entre. Par ailleurs, les messages et signaux entrants concourant la production de chaque signal ou message
de sortie sont consomms par cette production, c'est--dire enlevs de la mmoire du moniteur. Un moniteur
peut avoir grer une file d'attente, c'est--dire un mcanisme capable d'accumuler plus d'occurrences de
messages entrants que chaque dclenchement d'un processus consquent n'en consomme.
Exemple : expdition des factures par les employs du service Courrier.
file d'attente en entre : capacit illimite
(toutes les factures dites par la tche d'Edition des Factures)
consommation par chaque employ = lot de 20 factures
Calen-
drier
16 heures
MONIT. 02
Factures
Factures
Ordinateur
Employ
consommation = 20
capacit = infinie
Expdition
Courrier
Edition
Factures
A l'instar de tout processus, un moniteur est excut par un processeur : programme d'ordinateur et/ou acteur
humain; surveillance des vnements et dclenchement des ractions peuvent donc tre automatiques, "ma-
nuels" ou mixtes.
2.2. Types d'enchanements
L'attente effectue par un moniteur peut viser :
l'accumulation de plusieurs occurrences d'un mme type d'vnement, c'est--dire la rception de plusieurs
messages ou signaux du mme type;
la synchronisation d'vnements de types diffrents, c'est--dire des messages ou signaux de types diff-
rents.
Au sens propre, une synchronisation ralise une conjonction d'vnements, lis par ET. Par gnralisation, on
tend le concept de synchronisation toutes les combinaisons logiques d'vnements, en particulier, au cas des
disjonctions par OU.
Exemples : accumulation des factures par lots de 20 pour leur Expdition
synchronisation pour dclencher la Prparation des Commandes de Rapprovisionnement
messages "Identification de Produit commander"
signaux "Livraisons termines", "16 heures", "allez-y!"
disjonction : dition d'un rapport priode fixe OU la demande
Une attente ralise un enchanement convergent de processus : recevant l'information de plusieurs vne-
ments, elle produit en terminaison un seul signal, dclenchant donc l'excution d'un seul processus consquent.
Un moniteur est galement capable d'assurer un enchanement divergent :
la duplication de processus (inverse de l'accumulation) dclenche l'excution de plusieurs occurrences de
processus d'un mme type, grce l'mission de plusieurs occurrences d'un mme message ou signal;
le paralllisme (inverse de la synchronisation) dclenche l'excution simultane de processus de diffrents
types;
la slection (inverse de la pseudo-synchronisation OU), mettant un message ou signal parmi plusieurs
possibles, dclenche l'excution d'un processus parmi plusieurs candidats.
Exemples : duplication : expdition simultane de factures par plusieurs employs
paralllisme possible, la survenance du signal "Livraisons termines",
entre les tches d'Edition des Factures
et de Prparation des Commandes de Rapprovisionnement
2.3. Spcification d'un moniteur
La spcification d'un moniteur se fera comme celle d'une procdure transformant des messages ou signaux
entrants en messages ou signaux sortants.
1) Pour chaque type de message ou signal entrant, on indiquera :
le nom (de type) de ce message ou signal,
le type de processus (ou l'acteur externe) metteur,
le nombre maximum d'occurrences accumulables,
la dure limite de mmorisation (par dfaut, cette dure est illimite; une dure nulle indique une
cause de dclenchement immdiat; une dure limite signifie qu'au del, l'vnement d'origine est
"oubli" et sans effet),
les liens unissant les diffrentes occurrences (identifiants communs aux diffrentes occurrences de
messages, par exemple : "relatifs au mme fournisseur").
2) Pour chaque type de message ou signal sortant, on indiquera :
le nom (de type) de ce message ou signal (tout message sortant doit tre identique un message
entrant),
le type de processus (ou l'acteur externe) destinataire,
le nombre d'occurrences mises, en parallle destination de processus multiples d'un mme type
ou en srie destination d'un seul processus,
les liens unissant les diffrentes occurrences (identifiants communs aux diffrentes occurrences de
messages).
3) Les rgles de dclenchement, c'est--dire de production des messages ou signaux sortants, sont des prdi-
cats liant par les oprateurs logiques AND, OR, NOT les vnements (messages et signaux) entrants. Les
conditions ainsi exprimes doivent tre exhaustives (aucun vnement, aucune combinaison d'vnements ne
peuvent tre systmatiquement "laisss sur le carreau") et non contradictoires. On cherchera en outre four-
nir des rgles indiquant ce que deviennent les vnements dure de mmorisation limite s'ils n'ont pas t
consomms avant l'chance de cette dure (on doit considrer comme exceptionnel que des vnements m-
moriss soient "oublis" sans plus).
4) S'il y a lieu, on compltera par les rgles de priorit pour le traitement des files d'attente.
Exemple :
Prparation
Livraisons
Etablisst.
Commandes
(Livraisons
termines)
MONIT. 01
Calen-
drier
Magasin
16 heures
go!
Id. Produits
commander
Id. Produits
commander
MONIT.01 : dclenchement de la Prparation des Commandes de rapprovisionnement
ENTREES : (a) messages : "Identification de Produit commander"
origine : Prparation des LivraisonsClients
occurrences accumules : illimit
dure de mmorisation : illimite
(b) signal : "Livraisons termines"
origine : Prparation des LivraisonsClients
dure de mmorisation : 1 jour
(c) message : "16 heures" origine : Calendrier
dure de mmorisation : 2 heures
(d) message : "go!" origine : Magasin
dure de mmorisation : 0 (dclenchement immdiat)
SORTIES : (e) messages : "Identification de Produit commander"
destination : Prparation des Commandes de rapprovisionnement
occurrences mises : en srie, toutes occurrences de (a)
REGLES : condition de dclenchement : (a) ET (b) ET (c) ET (d)
production des sorties : (e) = (a)
conditions anormales : si le message (d) n'arrive pas dans les 2 heures
(dure de mmorisation de (c)),
traiter les messages (a) avec ceux du lendemain
2.4. Validation du schma dynamique
a) Compltude du schma
Un schma dynamique reprsente le comportement d'un processus complexe systme, sous-systme ou t-
che sous la forme d'un enchanement de processus composants.
Thoriquement, il est impossible que l'excution d'un processus soit dclenche autrement qu' l'intervention
d'un moniteur. Ceci justifie le mode de reprsentation de la mthode MERISE : un moniteur, appel syn-
chronisation, est attach chaque processus composant, appel opration (la reprsentation fait galement
apparatre les conditions d'mission des vnements signaux ou messages sortants). Inconvnient de
cette reprsentation : elle ne permet pas de visualiser les enchanements divergents, mais seulement les en-
chanements convergents.
Prparation
Livraisons
Etablisst.
Commandes
(Livraisons
termines)
16 heures
go!
a
b
c
a b
c d
a.b.c.d
OK
Id. Produits
commander
Evt.
Synchro.
Opration
Cond. Cond.
Evt.
Aux paragraphes prcdents, on a montr des diagrammes reprsentant les moniteurs comme des processus
autonomes. Dans ce type de reprsentation, on admet gnralement de ne pas faire figurer les moniteurs dont
la spcification ne comporterait pas de condition et montrerait des sorties identiques aux entres. Dans cette
reprsentation, on doit, pour chaque processus composant autre qu'un moniteur, indiquer exactement un type
d'vnement dclencheur, c'est--dire un flux de messages ou de signaux en entre (cette contrainte n'existe
pas dans un diagramme de flux du schma fonctionnel).
b) Cohrence du schma
La validation d'un schma dynamique devrait comporter la dmonstration qu'il "fonctionne" sans "blocage"
systmatique. Ncessairement globale, semblable dmonstration est difficile tablir, autrement que par une
simulation automatique.
La thorie des rseaux de Petri dfinit un certain nombre de proprits que doit vrifier un schma dynamique
"bien form". On en trouvera un expos, adapt au modle de la mthode MERISE, dans l'ouvrage de H.
TARDIEU, A. ROCHFELD et R. COLLETTI.
1
Nous en voquons ci-aprs quelques-unes.
Evnements initiaux
Dans le schma dynamique dcrivant le fonctionnement d'un processus dcompos, on doit indiquer un ou
plusieurs vnements initiaux, dont la survenance est acquise ds avant la mise en route du processus dcrit.
Ces vnements doivent natre (tre produits) l'extrieur de ce processus et tre indpendants les uns des
autres, c'est--dire ne pas dcouler les uns des autres.

1
Op. cit.
Processus atteignables
Tout processus composant doit pouvoir tre atteint au dpart d'un vnement initial. Ceci implique
l'existence d'au moins un chemin partant d'un vnement initial et aboutissant au processus en cause;
sur ce chemin, une suite de conditions de production et d'attente des vnements (signaux et messages)
non contradictoires.
Terminaison propre
Une mme cause ne peut entraner l'activation d'une infinit d'oprations. Donc, au dpart de tout vnement
initial, le comportement du processus analys doit ou bien avoir une fin ou bien ramener l'tat initial.
Pour cela, notamment, tout cycle doit possder un dbut et une fin. Il y a cycle lorsqu'un processus ou un mo-
niteur reoit en entre un vnement dont il est lui-mme, dans une excution prcdente, la cause directe ou
indirecte. Pour tout cycle, on doit trouver une condition d'amorage et une condition d'arrt.
Prparation
Livraisons
Enregistr.
Commandes
Commande
reues
Commandes
diffres
Factures
amorce
fin
cycle
Dans cet exemple, la fin du cycle par l'mission d'une facture est-elle
garantie ? En d'autres termes, n'y a-t-il aucun risque qu'une com-
mande soit ternellement diffre (par exemple, par suite du retrait de
fabrication du produit command) ? Il faudrait alors prvoir une in-
tervention palliative extrieure.
3. Schma de dploiement
On l'a dj signal : des ressources doivent tre affectes individuellement l'excution de chaque tche, ain-
si qu' chaque flux rel entre tches. Ceci peut se visualiser par un diagramme des flux dans l'organisation.
Il s'agit d'un diagramme de flux entre tches, dont les lments sont disposs dans les cases d'un tableau
double entre, o
les colonnes reprsentent les "lieux" de l'organisation : postes de travail ou services responsables;
les lignes reprsentent des moments ou des priodicits (journalier, hebdomadaire, mensuel ...).
Les botes noires symbolisant les tches portent diffrentes annotations :
dure estime,
type de processus (automatique, "manuel", interactif).
Le support des messages et dpts de donnes papier, cran, bande magntique, ligne tlphonique ...
est visualis par un symbole iconographique.
'RFXP
SDSLHU
/LJQHGH
7pOpFRP
%DQGH
PDJQpW
'LVTXHV
GXUV
'LVTXHWWH
(FUDQ
&ODYLHU
Normalement, les flux externes sont quantifis : nombre moyen d'occurrences chaque excution de tche.
La quantification des flux internes est, au moins thoriquement, dductible des rgles de traitement.
La plupart des mthodes se contentent d'une illustration de ce genre.
1

1
La mthode IDA propose un vritable modle d'analyse des ressources, assorti de programmes de simulation
permettant de tester le caractre faisable des spcifications.
Calendrier Ordinat. central Serv. Personnel Pointeuse Travailleurs Services Banque Comptabilit
INTER
Situation
Familiale Situation
Profess.
Modif.
Situation
Signalt.
AUTO
Poin-
tages
Enregistr.
Prsences
INTER
Enregistr.
Prest.spc.
Prestat.
spciales
Prestat.
AUTO
Calcul
Rmunr.
Rmunr.
Fiches
de Paie
Vire-
ments Ecri-
tures
Quotid.
Variable
Fin du
mois
Fin du
mois
10/mois
4/mois
100x2
60
100
100
20
ADMIN.SALAIRES
A. CLARINVAL Analyse Mthodes orientes Objets 8-1
Chapitre 8. Mthodes orientes Objets
On assiste actuellement (19952000) l'mergence de nouvelles mthodologies, ncessites et entranes par
le succs de la programmation par objets. Cest ainsi que lObject Management Group (OMG) a, en 1997,
adopt comme standard lUnified Modeling Language (UML).
1
Ce "langage de modlisation unifi", produit
de la socit amricaine Rational Software, est le fruit de la rencontre au sein de cette socit de trois pion-
niers des mthodes danalyse et conception "orientes objets" : les Amricains G. BOOCH et J. RUM-
BAUGH et le Sudois I. JACOBSON.
Le schma central produit par une analyse axe sur les objets, souvent le seul peut-tre, est le diagramme des
classes d'objets; il s'agit ni plus ni moins que d'un schma de donnes, muni d'oprations. Le formalisme pro-
pos par la mthode OMT
2
et repris dans UML est celui d'un schma EntitAssociation.
3
La dfinition com-
plte des classes dobjets comporte la spcification des oprations effectues par ces objets.
4
La premire section du prsent chapitre explique les diagrammes proposs par UML pour illustrer les diff-
rents aspects de la collaboration des objets.
La deuxime section dcrit le modle des cas dutilisation mis au point par I. JACOBSON. Partant de la sp-
cification des besoins des utilisateurs, la mthode conduit baucher la structure du systme en identifiant les
objets mettre en place et leurs collaborations.
La troisime section introduit le concept darchitecture logicielle et lillustre par deux principes de ralisation
trs en vogue aujourdhui : larchitecture client / serveur et la dfinition de motifs ou "patterns" standardi-
ss.

1
OMG : Unified Modeling Language Specification, vers. 1.4; www.omg.org, 2002. Voir galement P.A.
MULLER : Modlisation objet avec UML; Eyrolles, 1997.
2
OMT Object Modeling Technique est la mthode danalyse mise au point par lAmricain J. RUM-
BAUGH et son quipe. Cf. J. RUMBAUGH, al. : Modlisation et conception orientes objet, trad. franaise;
Masson, 1995.
3
Cf. chapitre 3.
4
1. Schmas doprations
1.1. Prambule : unification des mthodes autour du concept dObjet
Le concept central de la thorie Objet
1
est naturellement celui d'objet :
un objet est une entit
qui se trouve dans un tat, dcrit par des attributs,
et qui, capable de certaines oprations, possde un comportement
lui permettant de ragir des vnements signals par des messages.
La fusion des donnes et des oprations en un agrgat unique l'objet permet aux informaticiens d'utiliser
un seul modle, une seule thorie, tous les stades de leur travail : depuis l'tablissement du schma concep-
tuel de la base de donnes (schma d'un domaine d'application) jusqu' la ralisation effective des program-
mes.
Les mthodes prcdentes tudiaient sparment les donnes et les oprations et s'en donnaient des vues
des schmas qui n'avaient rien en commun. Ainsi, la mthode MERISE
2
dcrit les donnes par un schma
EntitAssociation
3
et les traitements par un schma dynamique
4
centr sur le concept d'vnement. Entre
d'un ct les concepts d'entit, association et attribut, et de l'autre les concepts de processus, vne-
ment et moniteur, qu'y a-t-il de commun ? Comment assurer la compatibilit de deux visions aussi trangres
l'une l'autre ? Dans une conception base sur les objets, un programme prend laspect dun rseau d'objets
interconnects, et les traitements sont dcrits comme des changes de messages entre ces objets, messages
empruntant les voies que constituent les relations identifies dans le diagramme des classes; voil qui assure
la cohrence de la reprsentation des donnes et de la description des oprations.
L'unification des mthodes n'est relle que l o les outils de ralisation sont eux-mmes "orients
objets" car, invitablement, la conception d'une solution technique prfigure cette solution. C'est
aujourd'hui le cas de suffisamment de langages de programmation populaires; ce ne l'est pas encore
pour les systmes de stockage des donnes : les bases de donnes "Objet" ne sont pas encore vrai-
ment sorties du domaine exprimental. Nous traversons donc une poque de transition, o des pro-
grammes respectant de plus en plus souvent le paradigme Objet doivent coexister avec des bases de
donnes qui ne le font pas encore.
1.2. Les diagrammes dinteraction
a) Concepts introductifs
Le fonctionnement dun systme construit base dobjets est schmatiquement celui-ci : une requte manant
dun objet client demande un objet serveur dexcuter une des oprations dont il est capable;
5
la mthode
utilise par lobjet serveur peut comporter lenvoi dune nouvelle requte un troisime objet, et ainsi de
suite. On dit que les objets communiquent entre eux par des messages de requte.

1
Cf. A. CLARINVAL : Concepts et mthodes de la programmation par objets.
2
3
Cf. chapitre 3.
4
Cf. chapitre 7.
5
Pour cette raison, les oprations "offertes" par un objet sont parfois aussi appeles des services.
(Dans un systme dobjets distribus, tel que CORBA
1
, les objets clients et serveurs sont rpartis travers un
rseau de plusieurs machines de types divers.)
Exemples. Puisque tout objet est responsable de son propre tat, cest le COMPTE CLIENT lui-
mme qui va se crditer du montant dun paiement; cette opration sera excute (ou refuse) en
rponse un message de demande manant dun objet PAIEMENT. En vue dafficher son propre
tat, lobjet COMPTE demande lobjet CLIENT titulaire de lui fournir ses coordonnes. Etc.
(Lobjet PAIEMENT pourrait tre localis sur une machine et les objets COMPTE et CLIENT, sur
une autre.)
paiement compte client
1: crditer (montant) 2: coordonnes ()
Les diagrammes dinteraction dobjets schmatisent la fois la structure et le fonctionnement des systmes
composs dobjets. UML suggre deux formes pour ces schmas : les diagrammes de collaboration, initia-
lement proposs par G. BOOCH, et les diagrammes de squence, initialement proposs par J. RUMBAUGH.
b) Notations communes
Objet
objet : Classe
Un objet est symbolis par un rectangle.
Des occurrences multiples dune mme classe sont symbolises par des rectangles superposs.
Un objet est identifi par une expression de la forme nom_objet :nom_type
2
une des mentions peut manquer : objet de type indtermin : nom_objet
objet anonyme : :nom_type
Pour le distinguer dun identificateur de classe, lidentificateur dun objet est soulign.
Message
Un envoi de message est reprsent par une flche oriente de lobjet client vers lobjet serveur.
Un message complet est libell sous la forme suivante :
nom_opration ( nom_paramtre :type_paramtre ... ) :type_rsultat
Lmission dun message peut tre soumise condition : [ condition ] message
ou rptitive : *[ boucle ] message
Pour reflter la squence dexcution, les messages peuvent tre numrots.

1
CORBA "Common Object Request Broker Architecture", systme normalis dfini par lOMG ("Object
Management Group").
2
Cette notation est reprise du langage PASCAL.
c) Diagramme de collaboration
Un diagramme de collaboration montre les objets, les liens qui les unissent et les messages quils changent.
Exemple : programme affichant lheure sur un cadran analogique et un cadran numrique.
: Programme
: Horloge
: Horodateur
: Cadran Analogique
: Cadran Numrique : Ecran
1: *[boucle] donner_heure ( )
2: attendre (1 sec)
3: donner_heure ( )
4: changer (heure)
6: changer (heure)
5: dessiner (figure)
7: crire (texte)
Parce quil rpartit les objets dans un espace deux dimensions, un diagramme de collaboration convient bien
la mise en vidence des relations entre objets.
Illustration : diagramme de classes correspondant lexemple ci-dessus
Ecran
dessiner( )
crire( )
Programme
excuter( )
terminer( )
Horodateur
attendre( )
donner_heure( )
Horloge
donner_heure( )
Cadran Analogique
changer( )
Cadran Numrique
changer( )
d) Diagramme de squence
Reprsentation alternative, un diagramme de squence visualise le temps sur un axe vertical (la "ligne de
vie" de chaque objet). Il est possible de prciser par des annotations la chronologie des oprations : dure
et dcomposition d'une opration (visualises sous la forme dun bandeau vertical), dlai sparant deux
oprations, condition d'mission d'un message, boucle rptitive, etc.
1

1
En particulier, diverses conventions graphiques permettent dexprimer les conditions de synchronisation des
messages, requtes et rponses ...
Exemple : programme affichant lheure sur un cadran analogique et un cadran numrique.
: Ecran : Programme : Horloge : Horodateur : Cadran
Analogique
: Cadran
Numrique
1: *[boucle] donner_heure ( )
2: attendre (1 sec)
3: donner_heure ( )
4: changer (heure)
5: dessiner (figure)
6: changer (heure)
7: crire (texte)
Les diagrammes de squence permettent d'tre plus explicite dans la description du fonctionnement d'un pro-
gramme.
2. Le schma des Cas dUtilisation
2.1. Prambule : le contexte historique
a) Libralisation de l'usage des ordinateurs
La vision des choses implicite dans les diagrammes de flux ordonnancer les tches constitutives dun sys-
tme ,
1
qui fut et reste encore celle des responsables de l'informatique dans la plupart des entreprises,
convient bien un planificateur. Elle relve d'une idologie centralisatrice et autoritaire (les analystes infor-
maticiens ntaient-ils point nagure souvent affubls du titre danalystesorganisateurs ?).
En moins d'une dcennie, le dferlement des ordinateurs personnels, aujourd'hui parfaitement intgrs au r-
seau "officiel" de l'entreprise, en a rvl les limites. L'informaticien ne formalise plus et n'automatise plus
toutes les tches, mais seulement certaines d'entre elles; en fait, on ne lui demande plus que des outils.
Le concept mme de "l'application informatique" est en train de changer. Nous ne fournissons plus
l'utilisateur une application monolithique, souvent dpasse avant mme d'tre livre. Nous lui
donnons plutt une "bote outils", qui contient tout ce dont il a besoin : application spcifique
bien sr, mais aussi traitements de texte, tableurs, outils d'interrogation, gnrateurs d'dition ...
[...]
L'utilisateur est le seul savoir rellement quel est l'outil qui lui convient et puise dans cette "bote"
le meilleur instrument pour effectuer son travail. Il sait surtout, et c'est le plus important, l'ordon-
nancement des actions effectuer. Il peut ragir et prendre une dcision face un vnement parti-
culier. Autrefois, il fallait imaginer et coder tous les scnarios possibles. Ceci impliquait ncessai-
rement un long dlai de fabrication du logiciel, aussi bien lors de la phase de conception que lors de
la phase de ralisation.
Prenons un exemple simple. Pour informatiser le processus "accrocher le tableau dans le hall d'en-
tre", il faut, pour une action qui est somme toute simple, plus de 30 actions lmentaires. Et le
nombre de scnarios et de variantes est bien suprieur pour peu qu'un vnement particulier se pro-
duise la mche se casse pendant le perage , avec toutes les autres actions lmentaires que
cela comporte : retirer la mche casse du trou, choisir une autre mche ...
Prendre un crayon papier
Prendre un mtre
Mesurer la largeur du mur
Reprer le point d'ancrage sur le mur
Choisir la vis adapte
Choisir la cheville adapte la vis
Choisir la mche adapte la nature du mur (bton, brique ...) et la cheville
Prendre la perceuse
Dvisser l'ancienne mche
Visser la mche choisie
Rgler la perceuse (percussion, profondeur de la tige de guidage ...)
Percer le trou
Enlever la poussire du trou

1
Cf. chapitre 7.
Mettre la cheville dans le trou
Prendre le marteau
Enfoncer la cheville dlicatement
Enfoncer compltement la cheville avec le marteau
Prendre la vis
Prendre le tournevis correspondant la vis
Visser la vis
Poser le tableau
Rgler l'horizontalit du tableau
Tel est le contenu des applications informatiques [anciennes]. Quatre-vingts pour cent de la pro-
grammation est utilise (gaspille ?) traiter des scnarios qui ne vont que rarement tre utiliss,
ou bien rsoudre des cas d'erreurs. De plus, le scnario imagin par le concepteur n'est pas sou-
vent celui dsir par l'utilisateur : il a peut-tre envie de commencer par rgler la perceuse alors
que l'application l'oblige d'abord saisir le crayon pour reprer le point d'ancrage sur le mur.
1
b) Modernisation des mthodes danalyse
Les diagrammes de flux sont des outils danalyse datant de lpoque du traitement par lots (en anglais :
"batch processing"). En ces temps hroques des dbuts de linformatique de gestion (19601975), un pro-
gramme en excution tait incapable dinteragir avec un utilisateur humain. Les donnes traiter taient donc
accumules dans des lots enregistrs on disait : encods dans des fichiers "de mouvements" (dabord
sur cartes perfores, plus tard sur bandes magntiques); le traitement de ces lots tait soigneusement planifi
et confi aux oprateurs de la "salle des machines"; les rsultats revenaient sous la forme dpais rapports
imprims ...
Puis apparut linformatique interactive ou conversationnelle o lutilisateur humain, par le truchement dun
terminal clavier + cran, intervenait directement dans le droulement des programmes. Les volutions pa-
rallles de la technologie et des systmes dexploitation allaient accorder lutilisateur humain "conversant"
avec un programme de plus en plus dinitiative et de libert.
Comme date charnire, on pourrait retenir celle de lapparition du systme de programmation SMALLTALK
(1980), pionnier de la programmation par objets et promoteur du style d'interface graphique qui se trouve
l'origine du systme Macintosh et de ses imitateurs.
Le modle des cas dutilisation, mis au point par le Sudois I. JACOBSON, date de cette seconde poque.
2
Plus tard, JACOBSON a rejoint lquipe des Amricains G. BOOCH et J. RUMBAUGH au sein de la socit
Rational Software, apportant lquipe la dmarche danalyse qui lui manquait et qui devint le Processus
Unifi ("Unified Process") pour le dveloppement des logiciels.
3
Loptique de lanalyste est profondment renouvele : plus de tentative de structurer lenchanement complet
de toutes les tches dun systme; au lieu de cela, chaque cas dutilisation du systme (autrement dit, chaque
tche) est analys sparment et sa spcification prend la forme dun ou plusieurs scnarios dcrivant la
"conversation" de lutilisateur avec le systme. (Les mthodes antrieures, conues pour la description des
traitements par lots, nvoquaient pas les interventions des utilisateurs dans le traitement de linformation.)

1
J.M.GILLET : L'interface graphique; InterEditions, 1995.
2
I. JACOBSON, al. : Object-Oriented Software Engineering : a Use Case Driven Approach; Addison-
Wesley, 1992. Comme les prcdentes, cette mthode danalyse a t mise au point une dizaine ou une quin-
zaine dannes aprs les modes dexploitation et de programmation quelle sapplique dcrire ...
3
I. JACOBSON, G. BOOCH, J. RUMBAUGH : Le processus unifi de dveloppement logiciel, trad. fran-
aise; Eyrolles, 1999.
2.2. Contenu du modle des Cas dUtilisation
"Un systme sadresse en principe diffrents types dutilisateurs, chacun tant identifi en tant
quacteur. Les acteurs utilisent le systme selon les interactions dcrites par les cas dutilisation.
Un cas dutilisation est une squence dactions queffectue le systme afin de produire des rsultats
satisfaisants pour lacteur. Lensemble des acteurs et des cas dutilisation constitue le modle [ou
schma] des cas dutilisation."
1
a) Systme
Comme dans les mthodologies prcdentes, le systme constitue le rfrentiel analys.
2
b) Acteur
Un acteur est un utilisateur en situation dinteraction avec le systme. On distingue lutilisateur, tre concret
individuel, et lacteur, qui est un des rles que peut jouer un utilisateur. Lutilisateur est une ralit, une oc-
currence; lacteur est une abstraction, un type. Un utilisateur peut jouer diffrents rles (ex.: une vendeuse
de grand magasin est galement cliente de ce magasin); un mme rle (ex.: client) peut tre jou par diff-
rents utilisateurs.
Acteur Vendeur Client
Les utilisateurs dun systme peuvent tre des personnes, des machines, un autre systme ...
Le mcanisme de gnralisation permet de dfinir des hirarchies de rles.
Tiers
Client
Fournisseur
Acteur externe
Un utilisateur conversant avec le systme de traitement de linformation peut jouer le rle de substitut dun
acteur externe; par exemple, lemploy(e) encodant un bon de commande reu par courrier ou par tlphone
endosse en quelque sorte le rle du client. Bien que ce client lui-mme ninteragisse avec aucun composant
particulier du systme dinformation, on peut, dans les descriptions abstraites dun modle, lui reconnatre un
rle dacteur.

1
I. JACOBSON, al. : Le processus unifi ...
2
Cf. chapitre 6.
Dans dautres situations celle dun client commandant directement via Internet ou celle dun client au gui-
chet automatique dune banque ... , lacteur externe joue lui-mme son propre rle.
c) Cas dutilisation
La dfinition dun cas dutilisation ("squence dactions produisant des rsultats satisfaisants pour lac-
teur") rappelle les deux premiers lments de notre dfinition dune tche :
(1) un ensemble d'oprations du systme,
(2) que lutilisateur alimente en donnes et dont il attend des rsultats,
(3) au fonctionnement duquel il affecte des ressources : moment, dure, localisation, machines ...
1
Le concept nest donc pas vraiment neuf. De plus, il est maladroitement dfini : les auteurs crivent aussi
quun cas dutilisation regroupe ordinairement "plusieurs squences dactions possibles", squences auxquel-
les ils donnent le nom de scnarios. Pour lever cette contradiction, il suffit dadmettre que lintention de
lutilisateur ne se dvoile pas seulement travers la squence dactions droule mais galement par les res-
sources quil affecte la satisfaction de ses besoins; on en arrive ainsi donner au cas dutilisation la dfini-
tion classique dune tche.
Un acteur est habituellement impliqu dans diffrents cas dutilisation dun systme; ainsi, un client interagit
avec le systme de vente dune firme commerciale en lui envoyant des commandes et des paiements.
Cas d'utilisation
Commander
Client
Payer
[ressource : la Poste]
[ressource : une banque]
Il arrive quun cas dutilisation implique plusieurs acteurs; normalement, un seul dentre eux joue le rle
dinitiateur, tandis que les autres sont des utilisateurs passifs. Tous ces acteurs ont des besoins que le cas
dutilisation doit satisfaire mais, seul, lacteur initiateur converse (interagit) concrtement avec le systme.
Vendeur Client
Facturer
initiateur
Le schma des cas dutilisation dun systme rpertorie les acteurs et les cas dutilisation de ce systme. Mais
diffrence essentielle avec les diagrammes de flux il ne cherche pas systmatiquement ordonnancer les
cas dutilisation. Si, par commodit, lon y opre des regroupements, il ne sagit que des cas dutilisation
concernant un mme acteur. (Bien sr, un diagramme doit tre comment et rien nempche que le commen-
taire indique lordre de succession des tches.)

1
Cf. chapitre 6.
Exemple : cas dutilisation impliquant le client.
Client
Commander
Vendeur
Payer
Facturer
Comptabilit
d) Scnario
Un scnario est une squence dactions possible dans le cadre dun cas dutilisation. (En vue de dsigner un
scnario, lanalyste emploiera donc une expression qualifie, de la forme scnario de cas ou cas::scnario .)
Par les ressources quil concentre (lieu, moment, ordinateur, formulaire daffichage lcran ... et acteur), un
cas dutilisation forme un contexte qui rend possibles diffrents scnarios et permet de les enchaner librement,
cest--dire sans changer de contexte.
Exemple : gestion du curriculum vitae des travailleurs dans une socit de travail intrimaire.
Acteur externe Acteur Cas dutilisation Scnarios
Travailleur Recruteur mise jour des C.V. remplir un C.V.
corriger / actualiser un C.V.
consulter un C.V.
imprimer un C.V.
Employeur Placeur consultation des C.V. slectionner des C.V.
impression des C.V. imprimer un C.V.
imprimer une slection de C.V.
Consultation C.V.
Placeur
(Employeur)
Impression C.V.
Recruteur
(Travailleur)
Mise jour C.V.
2.3. Spcification des scnarios
Si le concept de cas dutilisation nest pas vraiment neuf, ce qui lest, en revanche, cest la manire de les d-
crire. Eclose lre de linformatique interactive, la mthode danalyse explicite les actions de lutilisateur
autant que celles du systme ... alors que la dfinition traditionnelle dun processus nonce que celui-
ci "reoit et met des messages, obtient et met jour des donnes",
1
en ignorant compltement lutilisateur.
a) Flot dvnements
Satisfaire les besoins dun utilisateur : telle est la fonction, lutilit dun cas dutilisation. Les auteurs de la
mthode prconisent de spcifier ces besoins fonctionnels en dcrivant linteraction la conversation du
systme avec lacteur initiateur du cas dutilisation. "Les cas dutilisation permettent aux utilisateurs de
structurer et darticuler leurs dsirs; ils les obligent dfinir la manire dont ils voudraient interagir avec le
systme, prciser quelles informations ils entendent changer et dcrire ce qui doit tre fait pour obtenir
le rsultat escompt. [...] [Les cas dutilisation] se dcrivent en termes dinformations changes et dtapes
dans la manire dutiliser le systme."
2
(Il nest sans doute pas inutile ici de rappeler quun acteur peut tre
une machine, par exemple un autre ordinateur ...)
Cette interaction est vue comme une succession de messages changs de lun lautre un message est une
entit dinformation dcrivant un vnement.
3
Mais, parce que le mot message possde en programmation
par objets une signification technique particulire (requte dun objet client un objet serveur, visant acti-
ver une opration caractristique de ce dernier), les auteurs parlent ici plus vaguement de flot dvnements.
Prcisment, un flot dvnements dcrit un scnario dutilisation; un cas dutilisation peut prsenter diff-
rents scnarios dont chacun sera dcrit sparment.
Un flot dvnements est visualis sous la forme dun diagramme de squence simplifi, qui ne mentionne
que deux "objets" : lacteur initiateur et "le systme". Ce diagramme est appuy par une description "litt-
raire" plus explicite.
Exemple : scnario : enregistrement dune commandeclient reue au tlphone.
La premire tape consiste mettre jour les informations relatives au client.
Le/La tlphoniste demande au client de dcliner son identit, puis recherche sa fiche signaltique.
Si la fiche signaltique nexiste pas, le/la tlphoniste la remplit en demandant les diffrentes infor-
mations au client.
Le/La tlphoniste lit au client les rubriques apparaissant sur sa fiche signaltique (ancienne ou
nouvelle) et lui demande de confirmer la validit des donnes. Il/Elle encode les corrections ven-
tuelles et demande au systme denregistrer la fiche.
Le systme affiche alors un formulaire de commande vierge, pr-numrot et pr-dat. Il y copie
automatiquement les donnes signaltiques du client utiles lidentification de la commande.
Pour faciliter la prise de commande, le systme affiche galement une fentre de slection des pro-
duits (tarif et stock).
La commande est alors constitue ligne par ligne.
Le client indique le produit quil dsire et le/la tlphoniste le recherche dans la fentre de slection
des produits. Il/Elle informe le client sur le prix de vente et la disponibilit du produit.
Le client indique la quantit dsire, que le/la tlphoniste enregistre.
A la fin de lenregistrement, le systme calcule et affiche le prix facturable pour cette commande.
etc.

1
2
3
b) Diagramme de squence
: Client : Tlphoniste
: Systme
mise jour
de la fiche
Client
s'identifier
demander la fiche
montrer la fiche (ou une fiche vierge)
lire la fiche
signaler les mises jour
encoder les mises jour
enregistrer la fiche
prparer la
prise de
commande
prparer une commande vierge
montrer le formulaire de commande
ouvrir la fentre de slection des produits
ligne ligne
...
dsigner le produit dsir
rechercher le produit dans la liste
donner prix et disponibilit
indiquer la quantit dsire
encoder la quantit
enregistrer la ligne
fin de
commande
calculer le total facturable
afficher le total facturable
etc...
2.4. Relations entre cas dutilisation
La description des diffrents scnarios fera ressortir des squences doprations communes plusieurs cas
dutilisation. Afin de limiter les redondances, ces squences communes seront extraites et dcrites sous la
forme de cas dutilisation spars susceptibles dtre rutiliss par les cas dutilisation originaux; apparatront
alors des relations entre cas dutilisation.
a) Relations concrtes
Utilisation
Un cas dutilisation peut en utiliser (sic) un autre : un scnario du premier peut inclure un scnario du se-
cond (de la mme manire quen programmation par objets, un objet peut en "utiliser" un autre auquel il est
associ : une opration du premier peut invoquer une opration du second).
Exemple. Pour enregistrer un bon de commande, lemploy commence par demander au systme la
fiche signaltique du client; si elle nexiste pas, il en cre une qui reprend les donnes apparaissant
sur le bon de commande; si elle existe mais que ladresse du client ait chang, il modifie ladresse
mentionne sur la fiche signaltique ... Toutes ces oprations relatives la fiche signaltique dun
client peuvent tre effectues indpendamment de lenregistrement dun bon de commande; elles
font partie des scnarios du cas dutilisation "Grer les fiches Client".
symbole de la
relation
"utilise"
Encodeur
Enregistrer Commande
Grer fiche Client
Extension
On peut crer une variante dun cas dutilisation en lui ajoutant sous condition quelques oprations prsentes
sous la forme dun cas dutilisation qui tend les fonctionnalits du cas de base.
1
(Le diagramme de squence
dtaillant le scnario du cas de base doit mentionner la condition dinsertion des oprations complmentaires.)
Exemple. Une transaction commerciale effectue via Internet doit tre scurise !
Scurisation de la Transaction
Client
Paiement
<<tend>>
en cas de
paiement
lectronique

1
Le couple cas gnral + extension dfinit un cas spcialis. Le verbe "tend" possde ici le mme sens que
dans le langage de programmation JAVA : drivation dun sous-type par compltage de la dfinition dun
type de base.
b) Relations abstraites
Inclusion
Il est possible disoler dans un cas dutilisation spar, comme dans une espce de sous-programme, certaines
oprations communes plusieurs cas dutilisation rels. Un tel cas dutilisation, non directement utilisable par
un acteur et quon peut donc qualifier dabstrait, est mis en vidence dans le but de faciliter le travail
danalyse. Au lieu de parler ici dune relation "utilise", certains auteurs parlent dinclusion.
Exemple. Beaucoup de scnarios comportent une squence initiale didentification de lutilisateur :
demande et vrification du nom et du mot de passe. Ces oprations peuvent tre isoles dans un cas
dutilisation abstrait.
Lambda
Identifier Utilisateur
<<inclut>>
<<inclut>>
Acteur Cas dutilisation Scnarios
Utilisateur Identification Utilisateur vrifier lidentification
modifier le mot de passe
Gnralisation
Il est parfois possible de regrouper sous la forme dun cas dutilisation gnrique abstrait les lments com-
muns diffrents cas dutilisation concrets. Cette relation de gnralisation est analogue celle qui existe
entre certains types dentits ou classes dobjets.
Exemple. Les interventions dun garagiste sur un vhicule sont de deux sortes : entretien et rpara-
tion. Les deux cas ont beaucoup de choses en commun : prestations de mcaniciens, fournitures de
pices et de consommables, etc.; ces lments communs sont regroups dans un cas dutilisation
abstrait Intervention.
Intervention
Entretien
Garagiste
Rparation
symbole de la
relation de
gnralisation
2.5. Analyse des cas dutilisation : du scnario aux objets
Lanalyse des cas dutilisation consiste extraire de ltude des scnarios la spcification des composants de
la solution technique mettre en uvre. Ces composants sont prsents dans des classes danalyse prfigu-
rant les classes dobjets que pourrait dfinir la programmation (mais elle pourra aussi recourir dautres
techniques de ralisation ...).
a) Classification des composants
Larchitecture ModleVueContrleur (SMALLTALK)
Pionnier dans le domaine de la programmation par objets, le systme SMALLTALK (1980) a notamment
lgu aux informaticiens un principe d'architecture des programmes que, dsormais, toutes les mthodolo-
gies proposent tel quel ou plus ou moins adapt. Ce principe d'architecture rpartit en trois catgories les ob-
jets intervenant dans un programme : modles, vues, contrleurs.
[1] Des objets tels que ClientProduitCommandeFacture sont des "modles" abstraits de l'information
gre par une application; dans d'autres domaines, on trouvera les modles EmploySalaire, AvionPilote
VolRservation, TempraturePression, etc. [2] Une liste l'cran, un imprim et mme le contenu d'un fi-
chier sont des vues ou reprsentations. Un modle peut avoir plusieurs reprsentations (ex.: un tableau de
chiffres et un graphique, une fiche l'cran et une liste imprime). Chacun de ces objets dtient et lui seul
dtient toutes les oprations qui constituent son comportement : les modles abstraits sont responsables
des oprations de calcul, les vues sont responsables des oprations de mise en forme.
[3] Les contrleurs, par exemple un gestionnaire de menus ou un diteur de textes, grent les enchanements
dynamiques; ils agissent pour que les diffrents objets du programme se trouvent toujours dans un tat coh-
rent, en particulier pour que l'tat d'un modle et l'ensemble de ses reprsentations se refltent correctement.
[4] La mthode OMT
1
regroupe dans une catgorie distincte les dispositifs d'entresortie, tels que les ges-
tionnaires de la souris, du clavier, des fichiers, du rseau ..., qui sont habituellement des objets standards pr-
dfinis.
Exemple : diagramme des classes dobjets intervenant dans un programme daffichage de lheure.
Programme
excuter( )
terminer( )
<<control>>
Horodateur
attendre( )
donner_heure( )
<<model>>
Cadran Analogique
changer( )
<<view>>
Horloge
donner_heure( )
<<control>>
Ecran
dessiner( )
crire( )
<<output>>
Cadran Numrique
changer( )
<<view>>

1
REMARQUE. A proprement parler, une fentre dinterface graphique est un dispositif d'entre
sortie, gr par des oprations standards (montrer, cacher, dplacer ...), et c'est le texte format
(dans telle couleur, dans telle police, en gras, en italique ...) apparaissant dans cette fentre qui
constitue la vue. Une fentre contient souvent aussi lun ou lautre contrleurs ou, plus exacte-
ment, des vues de lun ou lautre contrleurs , tels que des boutons poussoirs.
Les classes danalyse (JACOBSON)
Dans sa mthode, I. JACOBSON prconise de rpartir les composants du systme dans des classes danalyse.
Ces classes ne sont pas ncessairement dj les classes dobjets de la programmation; elles ne font que les
prfigurer. (On "tirera" souvent plusieurs classes dobjets dune seule classe danalyse. Qui plus est, la
ralisation pourra recourir dautres techniques que la pure programmation par objets.
1
)
Exemple. Une classe danalyse pourrait tre la classe Formulaire de mise jour des fiches Client.
Le programmeur ralisant cette interface graphique y "dcoupera" plusieurs objets : une barre de
menus, une liste de slection, un panneau de prsentation et mise jour de la fiche, des boutons de
commande, etc.
menus
liste fiche
Les classes danalyse se rpartissent elles-mmes en trois catgories correspondant aux trois catgories
dobjets de SMALLTALK :
SMALLTALK I. JACOBSON symbole
Model
Entity
View Boundary
Controller Control
Une classe dentits nest rien dautre quun type dentits dgag par lanalyse pralable du domaine
dapplication.
2
La plupart des entits sont des objets persistants, conservs dans des fichiers ou une base de
donnes.
NOTE. Les acteurs externes (clients, fournisseurs ...) sont souvent dcrits par des entits internes
au systme ("fiches" clients, "fiches" fournisseurs ...).
REMARQUE. Lanalyse anticipe de quelques cas dutilisation particulirement "reprsentatifs"
peut aider lanalyse du domaine dapplication dcouvrir des classes ou types dentits.

1
Cf. infra, 3.
2
Cf. chapitre 3.
Un objet dinterface ou de frontire ("boundary") est un dispositif dchange entre le systme et ses
utilisateurs, y compris les acteurs passifs. Cette catgorie regroupe les vues mais aussi certains dispositifs
dentresortie (crans, imprimantes, lecteurs de codes barres, etc.) mentionns au paragraphe prcdent.
Un objet contrleur coordonne lintervention de diffrents autres objets dans le droulement dun ou
plusieurs scnarios. On identifiera au minimum un contrleur par scnario.
Commentaires
Tout composant du systme raliser est dfini par une classe. Il constitue une ressource le plus souvent
partage par plusieurs scnarios et mme par plusieurs cas dutilisation.
Exemple : usage de quelques classes dans la gestion des C.V.
Entit Frontire Frontire Frontire
Cas dutilisation Scnarios C.V. liste slect. formulaire fiche
mise jour des C.V. remplir un C.V. x x
corriger / actualiser un C.V. x x x
consulter un C.V. x x x
imprimer un C.V. x x x
consultation des C.V. slectionner des C.V. x x
impression des C.V. imprimer un C.V. x x x
imprimer une slection de C.V. x x x
Il arrive quun analyste hsite entre scnario et cas dutilisation : tel sous-ensemble doprations
compose-t-il un scnario ou un cas dutilisation ? Cette confusion na pas beaucoup dimportance;
en tout cas, elle na pas dimpact sur la ralisation du systme, puisque celui-ci sera form de compo-
sants qui transcendent aussi bien les cas dutilisation que les scnarios.
b) Diagramme de collaboration
Lanalyse dun cas dutilisation consiste transformer la spcification des scnarios qui le composent en dia-
grammes de collaboration entre objets et dcrire ces objets. Les objets dont il est ici question sont des
objets "danalyse" dfinis par des classes danalyse, pas encore ncessairement des objets raliser tels quels.
METHODE
1) Le diagramme de squence dcrivant un scnario identifie les messages changs entre "le systme" et un
acteur. Il sagit maintenant didentifier, lintrieur du systme, lobjet metteur ou rcepteur de chacun des
messages.
2) Paralllement, lexamen dtaill du contenu des messages fera ressortir les attributs des diffrents objets.
Pour dmarrer, il est pratique de disposer dun canevas danalyse, tel que celui propos par P.A. MULLER
pour lanalyse des programmes comportant une interface hommemachine.
1
Une classe dentits fournit des mthodes pour obtenir() et mettre__jour() les valeurs.
A chaque type dentit Ent sont associes deux fentres dotes doprations standards :
une fiche F_Ent et une liste L_Ent.
2
menus
liste fiche
La fiche F_Ent, avec ses mthodes montrer() et cacher(), prsente lcran le contenu d-
taill dune occurrence Ent. La liste L_Ent, dont lutilit est de permettre de slectionner()
une fiche, montre seulement quelques donnes de chacune des entits dune collection.
3
Objet
Contrle Frontire
Entit
obtenir( )
mettre jour( )
Fentre
montrer( )
cacher( )
Liste
slectionner( )
F_Ent
L_Ent
Ent
**
standard
-----------------------------------------------------------------------------------------------------------
application

1
2
On doit au systme SMALLTALK cette structure de rfrence pour les interfaces graphiques.
3
Dans les ralisations concrtes, il nest pas rare dajouter au duo liste de slection + fiche de mise jour une
fentre de dfinition des critres de prslection en fonction desquels sera construite une liste partielle;
lenchanement de rfrence est alors celui-ci : dfinition des critres de prslection constitution de la
liste de slection extraction et manipulation de la fiche. Il peut aussi tre ncessaire de dcouper en plu-
sieurs volets une fiche trop charge. Mais tout ceci est sans intrt au stade danalyse dont nous traitons ici.
Exemple : scnario : enregistrement dune commandeclient reue au tlphone (cf. 2.3.)
Contrle Contrle Frontire Entit Frontire
: Enreg. Commande
: Mise jour fiche Client
: Cration Commande
: L_Client
: F_Client : Client
: F_Commande
: L_Produit
: Commande
: Produit
: Base de Donnes
1: excuter ( )
9: excuter ( )
2: montrer ( )
3: slectionner ( )
4: montrer ( )
6: remplir ( )
5: obtenir ( )
7: mettre jour ( )
8: enregistrer ( )
10: montrer ( )
16: remplir ligne ( )
11: crer ( )
12: obtenir ( )
17: mettre jour ( )
13: montrer ( )
14: slectionner ( )
15: obtenir ( )
18: enregistrer ( )
c) Diagramme des classes "conceptuelles"
Lexamen dtaill des messages, essentiellement ceux qui circulent entre une entit Ent et la fiche F_Ent
correspondante, permet de recenser les attributs mentionner dans la spcification des diffrentes classes
dentits (dans lexemple, les classes Client, Commande et Produit). Ainsi slabore progressivement le dia-
gramme des classes dentits "conceptuelles" du domaine de lapplication.
3. Conception dune architecture logicielle
3.1. Nature de la dmarche de conception
Risquons un parallle avec la modlisation des donnes. Lanalyse des donnes livre dabord un schma
conceptuel, smantique, articul autour des concepts dentit, association, attribut et identifiant; ce schma
doit tre transform en schma logique, cest--dire rinterprt en termes de technologie, dobjets ralisa-
bles : enregistrements et cls daccs, par exemple. Le mme genre de dmarche doit sappliquer ici : les
schmas doprations dont nous disposons ce stade sont du niveau conceptuel; ils doivent tre couls dans
les lments dune architecture matrielle et logicielle. Dans les mthodes amricaines, cette seconde tape de
la dmarche est connue sous le nom de design, ce que lon traduit en franais par le terme conception.
Cependant, la situation est ici trs diffrente. Alors que, de nos jours, les systmes de gestion de bases de
donnes (SGBD) les plus usits sont assez uniformes (ils se conforment presque toujours au modle rela-
tionnel sous-jacent au langage SQL), les moyens de raliser les oprateurs techniques de traitement de linfor-
mation sont de plus en plus varis.
Il est donc ncessaire, fondamental mme, de dabord tracer sa voie : avant dtre mise en uvre,
une solution technique doit tre conue ! Il sagit, en premier lieu, de fixer des objectifs de qualit
technique tels que "la clart, la capacit de raction aux futurs changements et la rutilisation",
1
et doprer des choix techniques de porte gnrale.
La conception [...]
Comme l'analyse et la conception, la conception et la ralisation se chevauchent en partie. Il est
rare de savoir comment tout faire; pour cette raison, il faut essayer des techniques alternatives,
comparer les rsultats puis choisir en faisant des compromis. La conception et la ralisation se
compltent. La conception a besoin d'exprimenter, la ralisation a besoin de principes directeurs.
Afin de maintenir le plus longtemps possible les bnfices de l'abstraction, la conception est gn-
ralement subdivise en deux tapes : une tape logique indpendante de l'environnement de rali-
sation et une tape physique qui se proccupe de l'ordonnancement des ressources et des particula-
rits des langages de programmation ou de l'environnement d'excution.
La conception est souvent considre, tort, comme un simple enrichissement des rsultats obtenus
durant l'analyse. Il s'agit l d'une vision fortement rductrice qui ignore tout simplement que la
conception est le temps de la mise en uvre du savoir-faire. Ce savoir-faire peut tre interne au
projet ou acquis l'extrieur sous la forme d'outils, de composants rutilisables ou plus largement
de cadres de dveloppement.
2
[...]
La conception dbute par la dtermination de l'architecture du logiciel, c'est--dire par l'labora-
tion des structures statiques et dynamiques qui serviront de charpente pour l'ensemble du dvelop-
pement. L'architecture dfinit la forme gnrale de l'application; de sa qualit dpendent le dve-
loppement et l'volution du logiciel. L'architecture est la consquence de dcisions stratgiques ar-
rtes lors de la conception et de dcisions tactiques prises en cours de ralisation.

1
I. JACOBSON, G. BOOCH, J. RUMBAUGH : op. cit.
2
"Frameworks".
Se donner une stratgie informatique, c'est considrer le logiciel comme un lment dterminant du
dveloppement de l'entreprise; c'est aussi chercher s'assurer une avance technologique par des
choix d'architecture qui dpassent le cadre des besoins immdiats, lis une application particu-
lire.
Se donner une stratgie informatique, c'est par exemple choisir :
l'internationalisation, autrement dit, concevoir le logiciel de telle manire que le dialogue avec
l'utilisateur puisse tre men dans toutes les langues;
la rutilisation qui n'est pas le fruit du hasard, mais le rsultat d'une adhsion forte de toute une
organisation, depuis la dfinition de la ligne de produits jusqu'au dveloppement de ces produits;
l'unicit de langage pour l'ensemble des dveloppements (Ada dans le cas du ministre de la d-
fense amricain);
l'indpendance par rapport aux dispositifs d'affichage, autrement dit, le dcouplage entre l'in-
formation afficher et la manire de l'afficher;
la portabilit des sources, voire des excutables, qui rduit notablement les cots de dveloppe-
ment et surtout de maintenance dans le cas d'un logiciel multicibles.
la gnralisation des mcanismes de communication entre objets qui permet de rendre transpa-
rente la localisation des objets et ainsi de faciliter la distribution des applications et de leurs compo-
sants.
La conception est le domaine du compromis. Il nexiste pas de solution toute blanche ou toute
noire : la vrit est toujours quelque part dans le gris. Les dcisions tactiques couvrent toutes les
activits qui guideront la recherche de cette vrit dans leffort de dveloppement au jour le jour.
Elles contiennent par exemple les lments suivants :
la gnralisation dabstractions et de mcanismes pour les tches ancillaires, autrement dit, tous
les composants largement rutilisables dans les programmes, comme les dates, les chanes de ca-
ractres, les structures de donnes de base, les algorithmes de tri, etc.;
le traitement des erreurs qui peut tre effectu par des exceptions ou par des statuts exprims sous
la forme de valeurs entires. Lexception ne peut tre ignore, mais son traitement obscurcit le code
normal. Le statut derreur est simple mettre en uvre mais il peut tre ignor : le traitement de
lerreur nest alors pas garanti;
la gestion de la mmoire dynamique qui peut tre effectue par le programmeur ou automatise
par lenvironnement dexcution;
la communication entre processus qui peut reposer sur des liaisons point--point, multi-points ou
par diffusion. Elle peut tre assure par des mcanismes ad hoc ou inscrite dans un schma gnral
dintgration dapplication comme CORBA ou ActiveX;
le choix des modes de communication qui inclut la forme et la nature des messages et les diff-
rents modes de synchronisation : synchrone, semi-synchrone, drobante, minute, asynchrone, etc;
la prsentation des messages utilisateur afin de rendre toutes les interactions avec lutilisateur le
plus homognes possible;
les langages de programmation qui sont compils ou interprts et prsentent des points forts et
des limites. Les langages compils permettent dcrire des programmes plus fiables, les langages
interprts apportent plus de souplesse lors du dveloppement. Dans certains cas, il peut tre int-
ressant de mlanger diffrents langages au sein de la mme application;
le choix des structures de donnes et des algorithmes qui sont encapsuls dans les objets afin de
dcoupler la spcification de la ralisation des classes;
loptimisation du rseau de relations qui reflte les besoins de communication de lutilisateur. Le
concepteur peut tre amen modifier ce rseau pour diverses raisons : optimiser la vitesse des ac-
cs, prendre en compte des contraintes particulires de ralisation, comme labsence de lien bi-
directionnel dans les langages de programmation de troisime gnration;
la mutation de certaines relations de gnralisation parce que lhritage multiple nest pas dis-
ponible dans le langage de programmation utilis ou encore parce que la forme de gnralisation
recherche doit tre dynamique alors que lhritage est statique;
la mise en uvre de composants rutilisables dans le cadre de deux ralits : la programmation
avec la rutilisation et la programmation pour la rutilisation. La premire forme de rutilisation
consiste incorporer un composant existant et ainsi acclrer un dveloppement en cours. La
deuxime sapparente plus un investissement : le cot est immdiat et les bnfices ne sont perus
que plus tard.
L'effort dvelopp en conception est plus ou moins important selon la nature de l'application et la ri-
chesse de l'environnement de ralisation. Il est de plus en plus possible d'effectuer un transfert de
complexit des applications vers les environnements [de dveloppement], grce une factorisation
des lments et des mcanismes communs. C'est le cas dans les familles d'applications bien cibles
dans un domaine donn, comme les logiciels clients qui interagissent avec des serveurs de bases de
donnes. Inversement, plus une application est technique, plus elle interagit avec des matriels par-
ticuliers et plus l'effort de conception est important.
Les outils RAD dveloppement rapide d'applications
1
proposent une voie bien trace.
2
[...]
Il faut suivre les rgles du jeu fixes l'avance : au bnfice de la simplicit mais au dtriment de
l'originalit. Toutes les applications finissent par se ressembler, ce qui est bien et mal la fois. Le
travers des outils RAD est d'encourager faire vite et salement quick and dirty plutt que vite
et bien.
Curieusement, le RAD est un mlange de gnie logiciel dans sa conception et d'horreur informatique
dans son utilisation. Ceci est la consquence d'une vision court terme des utilisateurs pour qui
seul l'aspect rapidit compte bien souvent. Comme le RAD n'encourage pas particulirement la mo-
dularit et les abstractions en couches, trs rapidement c'est le cas de le dire le code d'inter-
face utilisateur et le code de l'application se retrouvent intimement mlangs. Le logiciel construit
de cette manire est difficile maintenir et quasiment impossible rutiliser pour une autre appli-
cation.
Le propre de la conception est de rechercher l'quilibre entre vitesse de ralisation et possibilit de
rutilisation, ouverture et solution cl en main, vision court terme (la tactique) et vision long
terme (la stratgie).
3
3.2. Le concept darchitecture logicielle
Le texte ci-dessus voque le concept darchitecture logicielle. Voyons plus concrtement en quoi cela
consiste.

1
RAD "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il prconisa, en
1991 (d. MacMillan Publishing), une nouvelle stratgie pour le dveloppement des projets informatiques :
au lieu du comportement traditionnel consistant dfinir d'abord les limites de l'application raliser et voir
ensuite les quipes de dveloppeurs accumuler les retards et dpasser toutes les prvisions budgtaires ... fixer
le budget au dpart et demander aux quipes de dveloppement de raliser "ce qu'elles peuvent" dans ce cadre,
en crant des prototypes au moyen d'outils de programmation sophistiqus et rapides. Bref, au lieu de faire
exploser les budgets, restreindre s'il le faut les ambitions du projet ... Le temps ayant pass, on a oubli cette
proposition "rvolutionnaire" pour ne retenir que la suggestion de choisir des outils performants.
2
Les outils de dveloppement rapide (ex.: WinDev, PowerBuilder, Delphi, C++ Builder et d'innombrables
autres "studios" de "visual programming") jouissent actuellement d'une grande vogue, qu'explique le seul
qualificatif "rapide". On en indique ici les limites et les piges.
3
Le concept darchitecture logicielle reprsente les aspects statiques et dynamiques les plus signifi-
catifs du systme. Larchitecture merge des besoins de lentreprise, tels quils sont exprims par les
utilisateurs et autres intervenants et tels quils sont reflts par les cas dutilisation. Elle subit,
nanmoins, linfluence dautres facteurs, tels que la plate-forme sur laquelle devra sexcuter le
systme (par exemple, larchitecture matrielle, le systme dexploitation, le systme de gestion des
bases de donnes, les protocoles de communication rseau), les briques de base rutilisables dispo-
nibles pour le dveloppement (par exemple, une infrastructure prfabrique (framework) [...]
pour les interfaces utilisateur graphiques), les considrations de dploiement, les systmes existants
et les besoins non fonctionnels (par exemple, les performances, la fiabilit).
[...]
Les architectes vont donc "couler" le systme dans une forme. Cette forme (larchitecture) doit tre
conue de faon permettre lvolution du systme, non seulement dans le cadre de son dveloppe-
ment initial, mais dans les annes et les gnrations venir. Pour dterminer une telle forme, les
architectes doivent travailler partir dune comprhension gnrale des principales fonctions, cest-
-dire des principaux cas dutilisation du systme. Ces cas dutilisation peuvent ne reprsenter que
5 10 % de tous les cas dutilisation du systme, mais ils sont les plus significatifs, ceux qui consti-
tuent le cur mme des fonctions du systme. En clair :
Larchitecte cre une bauche grossire de larchitecture, en partant de laspect qui nest pas
propre aux cas dutilisation (par exemple, la plate-forme). Bien que cette partie de larchitecture
soit indpendante des cas dutilisation, larchitecte doit avoir une comprhension globale de ceux-ci
avant desquisser larchitecture.
Il travaille, ensuite, sur un sous-ensemble des cas dutilisation identifis, ceux qui reprsentent les
fonctions essentielles du systme en cours de dveloppement. [...]
Larchitecture se dvoile peu peu, au rythme de la spcification et de la maturation des cas
dutilisation, qui favorisent, leur tour, le dveloppement dun nombre croissant de cas dutili-
sation.
Ce processus se poursuit jusqu ce que larchitecture soit juge stable.
1
3.3. Le principe d'architecture Client / Serveur
a) Etat de lart des dveloppements informatiques
Linformatique clate
Nagure, la confection d'un programme tait un processus uniforme : ayant sa disposition une "page blan-
che", un seul langage de programmation a fortiori, un seul mode de pense ou paradigme et un ordina-
teur unique, le programmeur concevait intgralement et dans ses moindres dtails un algorithme de rsolution,
le codait dans son unique langage et faisait excuter le tout dans un environnement l'ordinateur immua-
ble et familier. L'quipe de programmation tait la seule autorise fournir des programmes et il n'tait pas
courant d'acheter un logiciel d'application "standard", par exemple de comptabilit, qui ne ft pas complte-
ment "pens et confectionn maison".

1
I. JACOBSON, G. BOOCH, J. RUMBAUGH : op. cit.
Cette situation n'a plus cours. Pour reprendre le titre d'un livre : nous sommes entrs dans l're de "l'informa-
tique clate".
1
Le problme est maintenant de rpartir les lments d'une solution informatique sur les composants multifor-
mes d'une infrastructure matrielle et logicielle disparate.
Outils avancs
Le besoin de toujours plus grande qualit, en particulier dans la convivialit de l'interface hommemachine et
dans l'intgrit des donnes, contraint les informaticiens recourir des systmes logiciels spcialiss pour la
gestion des interfaces et des bases de donnes.
Ces systmes sont si sophistiqus et leur programmation si complexe qu'ils s'accompagnent d'outils de pro-
grammation, qualifis "de quatrime gnration", dont le paradigme dclaratif
2
apporte une grande facilit de
programmation et de mise au point.
Il s'ensuit que les moyens mis en uvre pour le dveloppement mais aussi l'exploitation des applications in-
formatiques sont aujourd'hui htrognes. Il devient donc ncessaire de rpartir la programmation entre les
diffrents outils. Quelle rgle adopter pour cette rpartition ? Outils htrognes et multiples, dont la dure
de vie n'est pas la mme ... Lorsque, pour une raison quelconque, on est amen remplacer un outil par un
autre, il faudrait idalement qu'un minimum de programmation doive tre refait.
Tout cela entrane la ncessit de dfinir des principes d'architecture du logiciel, visant essentiellement don-
ner des rgles de rpartition de la programmation. En complment, il est ncessaire de dire comment analyser
les lments ainsi mis en place.
b) Dfinition de larchitecture Client / Serveur
Un systme informatique construit selon une architecture client/serveur est un systme dans lequel un pro-
gramme client adresse des requtes un programme serveur, lequel effectue pour le client les services de-
mands. Ces deux programmes s'excutent simultanment et communiquent directement entre eux, d'une
manire asymtrique : l'initiative des requtes appartient exclusivement au programme client.
Habituellement, un programme serveur est capable de servir plusieurs clients en mme temps. De plus en plus
souvent, les programmes serveur et clients s'excutent sur des ordinateurs diffrents interconnects : le ser-
veur s'excute sur l'ordinateur central d'un rseau, les clients se trouvent sur les stations personnelles de ce
rseau (ce peut tre le rseau INTERNET). Par extension, les qualificatifs "client" et "serveur" s'appliquent
galement aux ordinateurs. Lorsqu'un serveur est incapable de satisfaire une requte, il peut parfois transfrer
celle-ci un autre serveur, auquel il est lui-mme reli dans un rseau de serveurs.
3
c) Rgle de rpartition
La rpartition des fonctions logicielles devrait thoriquement se faire en trois lots, conformment au schma
suivant :

1
J.M. DESAINTQUENTIN : Linformatique clate; Masson, 1991.
2
Le programmeur "dclare" (ou dessine) le rsultat quil souhaite et loutil cre automatiquement lalgo-
rithme ncessaire la production de ce rsultat.
3
INTERNET offre un rseau de serveurs l'chelle mondiale, et de plus en plus d'organisations envisagent de
raliser leur propre rseau sous les modalits d'INTERNET on parle alors d'INTRANET. Soulignons que
choisir les modalits d'INTERNET, c'est opter pour une certaine standardisation ...
logiciel client
(requtes)
logiciel serveur
(services)
gestionnaires d'interfaces bibliothques de fonctions SGBD
scnarios procdures d'application serveur de donnes
gestion d'cran
travail par lots ("batch")
dition de rapports
dition de graphiques
tableur
navigateur Web
"calculs"
algorithmes
structures
relations invariantes
ordinateurs clients ordinateurs serveurs
Tout objet class dans une colonne quelconque peut adresser des requtes
aux seuls objets classs dans la colonne situe immdiatement sa droite.
La cl de vote d'une architecture telle que celle schmatise par cette figure est celle-ci : la mme proc-
dure d'application (par exemple, d'tablissement d'une facture) doit pouvoir "servir" diffrentes interfaces
clientes, la mme poque ou des poques successives (est-ce rver que d'imaginer que les procdures
d'une application de comptabilit ou de gestion des ventes ou des stocks puissent survivre une modification
d'interface ?).
1
Il n'y a pas souvent ncessit qu'une procdure servante ne puisse s'excuter qu' travers un
seul scnario. Les diffrentes sortes de "guichets" dune banque en sont une dmonstration vidente : les
mmes oprations, par exemple un virement de compte compte, peuvent tre demandes au guichetier dune
agence bancaire ou directement effectues par le client un guichet automatique, via Internet ou au moyen
dun combin tlphonique ...
Idalement, le logiciel d'interface ne devrait comporter, outre les oprations strictes de prsentation (cons-
titution des lots, mise en page du formulaire, du rapport, du graphique, de l'hypertexte ...), que les dclen-
cheurs des procdures d'application.
2
Un "programme" l'cran, d'impression ou de traitement par lots de-
vrait tre peru et construit comme un squenceur de procdures d'application.
Le logiciel (SGBD
3
) serveur de donnes assure la cohrence des donnes, en conservant les lments
d'information et en garantissant leurs relations invariantes (contraintes et "triggers").
4
Certains SGBD per-
mettent galement de stocker les procdures d'accs aux donnes (ces procdures sont purement utilitaires et
leur identification n'est pas cruciale).
La rpartition sur trois niveaux que nous venons de dcrire caractrise la seconde gnration (
1995) des architectures clientserveur. Dans la premire ( 1980), on ne distinguait que deux
composants : le SGBD serveur de donnes et ... le reste. Lorsque ce "reste" a t port sur des ordi-
nateurs personnels ( 1990), il a pu profiter d'outils de "programmation visuelle" pour la ralisation
des interfaces d'utilisation. Le bnfice de ces outils fut double : la qualit de la prsentation aux
utilisateurs et le dveloppement rapide des programmes (RAD "rapid application development");
mais ce dispositif n'a pas rendu les solutions volutives, car les procdures d'application restaient
emptres dans la gestion des interfaces.

1
La pression du march des technologies informatiques fait que les entreprises ne sont pas entirement ma-
tresses de l'volution des interfaces travers lesquelles elles doivent "servir" leurs donnes et procdures.
2
Ainsi dfini, le logiciel dinterface rassemble donc des vues et des contrleurs, selon la terminologie de
SMALLTALK. Cf. supra, 2.5.
3
SGBD : Systme de Gestion de Bases de Donnes.
4
Cf. chapitre 5.
A prsent que s'est impos le principe d'une rpartition "three tiers" sur trois tages (et parfois da-
vantage ...), les programmeurs doivent lutter contre la tentation de facilit qui consiste, sous prtexte
de "dveloppement rapide", se servir des seuls outils visuels et produire encore des solutions "
l'ancienne" dans lesquelles les procdures d'application ne forment pas un ensemble distinct. La cou-
che intermdiaire met en uvre le principe de masquage des donnes;
1
elle garantit lintgrit et la
confidentialit des donnes.
2
La scurit des donnes pourra encore tre accrue si les donnes, dune
part, et les procdures, dautre part, sont hberges sur des ordinateurs distincts.
d) Varit des paradigmes de programmation
La multiplicit des outils intervenant aujourd'hui dans une solution informatique de qualit entrane le recours
des paradigmes de programmation varis (la pense du programmeur n'est plus uniforme !).
Les SGBD relationnels, les plus employs actuellement, utilisent le langage standardis SQL, de style d-
claratif :
les requtes (SELECT) dfinissent sous la forme prdicative l'ensemble rsultat produit par un al-
gorithme implicite;
les contraintes et assertions, elles aussi exprimes sous une forme prdicative, font l'objet d'une v-
rification automatique;
les dclencheurs ("triggers") dfinissent des procdures dont l'activation est automatique.
Les gestionnaires d'interfaces ont leur propre logique et leurs propres outils. La plupart utilisent aujour-
d'hui des "studios" de programmation visuelle : pour l'essentiel, le programmeur dessine le rsultat qu'il sou-
haite. Souvent, ces outils visuels sont greffs sur un squelette de programme ("framework" = charpente)
sous-jacent et, plus d'une fois, le programmeur doit affiner le code "grossier" qu'ils gnrent.
A application framework is a set of classes that cooperate closely with each other and together em-
body a reusable design for a general category of problems. The most common use of application
frameworks is in the creation of graphical user interfaces, or GUI applications [...]. However the
concept has applicability beyond the development of user interfaces. [...] An example might be the
ModelViewController framework in Smalltalk [...].
The framework dictates the overall structure of the application. It describes how responsibilities are
partitioned between various components, and how these components must interact with each other.
The benefit of a framework then is that the designer of a new application need only concentrate on
the specifics of the problem at hand. Previous design decisions embodied in the structure of the fra-
mework need not be reexamined, nor does the code provided by the framework need to be rewritten.
[...]
However, the fact that the overall design has already been laid out by the creator of the framework
is also a weakness, because in providing the structure of an application the framework severely
constrains the way in which new applications are allowed differ from each other. [...]

1
2
Les outils de dveloppement rapide gnrent automatiquement des requtes daccs direct aux bases de don-
nes. Cest donc un effort considrable que les programmeurs doivent fournir pour les neutraliser et les rem-
placer par des requtes scurises adresses aux procdures masquantes.
The use of a application framework usually leads to an inversion of control between the new appli-
cation-specific code and the library-supplied code. In a traditional application, application specific
code defines the overall flow of execution through the program, occasionally invoking library routi-
nes in order to execute some specific function (such as a mathematical routine or an input/output
operation).
In a application framework, on the other hand, the flow of control is dictated by the framework and
is the same from application to application. The creator of a new application merely changes the
routines invoked by the framework, but does not change the overall structure. Thus, the framework
has the dominant position and the application-specific code is reduced to a secondary position.
1
Les procdures d'application qu'il vaut mieux n'intgrer ni au dictionnaire de la base de donnes ni aux
objets d'interface ne peuvent, dans une architecture clate, qu'tre modulaires; au contraire des program-
mes anciens, elles ne renferment aucun scnario d'excution. Elles sont donc ralises sous la forme de sous-
programmes ou, mieux, de classes d'objets. Cette programmation possde donc encore la forme traditionnelle
des langages de 3
e
gnration, quand bien mme il s'agirait de langages orients objets.
3.4. Motifs architecturaux ("Patterns")
Dans la conception des solutions aux diffrents problmes qu'il doit traiter, tout programmeur, tout groupe de
programmeurs a ses habitudes, manifestations de son savoir-faire. C'est ainsi que l'on retrouve dans l'uvre de
tout programmeur des parties de solutions de structure identique en programmation par objets, il s'agit de
combinaisons de classes ou d'objets , qui se rptent frquemment comme autant de motifs architecturaux
(en anglais : "patterns"
2
). Certains de ces motifs sont si gnralement utiliss par la corporation des pro-
grammeurs, qu'ils refltent un tat de l'art collectif.
3
Il est intressant d"institutionnaliser" ces manires de faire : le choix et la dfinition des motifs architectu-
raux cela va de soi relvent de larchitecte ! Rendre communs (en dautres termes, standardiser) les
"patterns" dune quipe, cest faire profiter tout le monde du savoir-faire des pionniers, cest gagner du temps
de recherche et de mise au point, cest rendre comprhensible et changeable le travail de tous ...
Exemples
Larchitecture clientserveur est un exemple fort de motif architectural.
Au sein d'une architecture ModleVueContrleur, le couple modlevue est un motif que l'on peut r-
aliser de diffrentes manires. Une faon assez rudimentaire est de dfinir la vue (unique) en tant que
sous-classe "orne" du modle abstrait. De manire plus sophistique, le systme SMALLTALK a pr-
programm dans des classes abstraites (composant ce que nous appellerons plus loin un squelette) les
mcanismes de reflet entre vues et modles : un nombre quelconque de vues peuvent tre attaches un
modle et, chaque fois que l'tat du modle est modifi, celui-ci active la mthode afficher de chacune des
vues dont il possde la liste.

1
T. BUDD : An Introduction to Object-Oriented Programming, 2
nd
ed.; Addison-Wesley, 1997.
2
"Pattern" = forme. Ce terme anglais a la mme origine tymologique que le terme patron dans le jargon des
couturires : forme en papier utilise pour couper le tissu.
3
L'ogive fut un motif architectural caractristique du Moyen Age dans toute l'Europe occidentale. La faade
en briques rouges avec encadrements de pierre bleue est un motif de l'architecture mosane traditionnelle.
Le langage JAVA a gnralis ce motif du reflet synchronis entre un objet "observable" et des objets
"observateurs", entre un objet "vnement" et des objets " l'coute" ("listeners") ...
Un motif que l'on rencontre trs couramment est celui de la faade. Les requtes de l'objet client ne sont
pas directement reues par l'objet fournisseur des services demands, mais par un objet intermdiaire qui
modifie les messages avant de les relayer vers le destinataire final. A l'objet client, cet objet intermdiaire
apparat donc comme la "faade" de l'objet serveur. Les rles de ces faades sont trs varis :
"proxy" transmettant, via un rseau, les requtes un serveur loign;
aiguilleur ("dispatcher") slectionnant parmi plusieurs serveurs le destinataire d'une requte;
mmoire cache ou tampon acclrant l'accs aux donnes externes;
filtre adaptateur, changeant la forme des donnes;
fichier virtuel form de la runion de plusieurs fichiers physiques;
terminal virtuel standardis rendant les programmes indpendants de leur environnement rel;
fentres "abstraites" (cf. JAVA) standardisant les diffrents systmes d'interface graphique;
etc.
Autre domaine propice la mise au point de motifs architecturaux : la matrialisation des associations
entre objets. Un motif souvent mis en vidence est celui de la structure "matre dtails" permettant de
traiter une association de type 1n (ex.: 1 facture n lignes de facture, 1 commande n articles
commands).
Autre domaine encore : la gestion du multilinguisme des programmes.
Selon les cas, un "pattern" sera dcrit par un diagramme de collaboration d'objets ou un diagramme de clas-
ses, dont les lments (objets ou classes) sont de types variables. Il pourra assez souvent tre partiellement
pr-programm, sous la forme de modles gnrateurs paramtrer ("templates") ou de squelettes de pro-
grammes complter ("frameworks").
1
3.5. Industrialisation du processus de dveloppement
L'closion des mthodes base d'"objets" permet d'envisager une certaine industrialisation du processus d'in-
formatisation, en rendant possible la fabrication de composants logiciels rutilisables : types dobjets spcifi-
ques dun domaine dapplication ou "mtier",
2
"templates", etc. Cette nouvelle approche se substitue (ou
s'ajoute) l'approche classique des informaticiens dveloppant des projets.
Object-orientedness is not just a programming style but the implementation of a certain view of what
software development should be. [...] This view implies profound rethinking of the software proc-
ess. [...]
The traditional culture [...] is project-based. In other words, the subject of discourse is the project,
which starts with a certain specification and ends with the delivery of a program with the supporting
documents. [...]
The outcome is results, produced by a program in response to user's requirements. The economics is
one of profit, as produced by the results.

1
Cf. A. CLARINVAL : Concepts et mthodes de la programmation par objets, chapitre 7.
2
En franais : "objets mtier". En anglais : "business objects".
The organizational unit impacted is usually the department directly affected by the project. The time
frame is as short as it will take to produce the required solution. The goal is a program, or a few
programs. The bricks of which this program is made are program elements : modules built for the
occasion.
[...]
The culture implicit in object-oriented design is quite different. It may be called the product cul-
ture : the subject of discourse is reusable products rather than individual projects. [...]
The outcome is reusable software elements, meant to be useful to a large number of applications.
The economics is one of investment which of course is intended as deferred profit.
The unit is, beyond an individual project, a company (or division), sometimes an entire industry.
The time frame is long-term. More than a program, the goal is to build systems. The bricks are
software components, which distinguish themselves from mere program elements by having a value
of their own, independently of the context for which they were initially designed. [...]
[...]
Without question, the dominant culture is project-based and will remain so for a long time. Custom-
ers, users, management, shareholders all want results, and preferably fast. Posterity will come later.
The immediate issue then is not so much how to replace the project culture by a product culture
[...], but how to instill significant doses of product-oriented concerns into a context which is largely
driven by project preoccupations.
One of the favorite strategies of all-time subversives penetrating institutions rather than des-
troying them outright indeed seems to work here.
[...] You have users and customers, and must be ready to respond to their specific requests. [...]
You will fulfil your customers' specific requests, but you will do more than these requests, seeing the
ventural software components beyond the immediate program elements.
The effort involved in transforming program elements into software components may be called gene-
ralization [...]. It involves abstracting from the original program elements, so as to make them in-
dependent from their original context, more robust, better documented. Giving generalization a
systematic role in the software development process is the key step in the progressive transition from
project to product culture.
By starting from specific requests but going further, you can quietly start accumulating a repertoire
of ready-made components which, little by little, will play an increasing role in your subsequent de-
velopments. With such a strategy you can, after a while, start having a different attitude towards
your users more active and less reactive. You can respond to a new request, with its specific and
perhaps baroque set of technical requirements, with a counter-proposal, offering to do somewhat
different and perhaps simplified job much faster thanks to the use of pre-existing components. Then
you can give your customers a choice : either tail-made developments using traditional techniques
in n person-months, or "mix-and-match" development using object-oriented techniques in, say, 0.3 n.
Some offers are hard to refuse.
1

1
B. MEYER : The New Culture of Software Development : Reflexions on the practice of Object-Oriented
Design, in Journ'ALMIN, n 14, mars 1990.
A. CLARINVAL Analyse Bibliographie B-1
Bibliographie
BACHMAN Ch. Data Structure Diagrams
in Data Base, 1969.
BERTINI M.Th.
TALLINEAU Y.
Le COBOL structur, un modle de programmation
d. d'Informatique, 1974.
BODART F.
PIGNEUR Y.
Conception assiste des systmes d'information
Masson, 1989.
BRAHMS Thorie et pratique des rseaux de Petri
Masson, 1983.
BUDD T. An Introduction to Object-Oriented Programming
Addison-Wesley, 1997.
CHEN P. The Entity-Relationship Model Toward a Unified View of Data
in ACM TODS, 1976.
CLARINVAL A. Comprendre et connatre le COBOL 85
Presses Universitaires de Namur, 1991.
CLARINVAL A. MESANGE :
Mthode et Systme d'Analyse et de Programmation de Gestion.
Groupe S
CLARINVAL A. Exploitation et Organisation des Fichiers
HEMES, 1998.
CLARINVAL A. Concepts et mthodes de la programmation par objets
HEMES, 2001.
CODASYL Data Base Task Group Report
ACM, 1971.
CODD E. A Relational Model of Data for Large Shared Data Banks
in Communications ACM, 1970.
CODD E. Further Normalization of the Database Relational Model
in RUSTIN (ed) : Data Base Systems, Prentice-Hall, 1972.
DE MARCO T. Structured Analysis and System Specification
Prentice-Hall, 1979.
DE ROSNAY J. Le macroscope
d. du Seuil, 1975.
DESAINTQUENTIN J.M. Linformatique clate
Masson, 1991.
GANE C.
SARSON T.
Structured Systems Analysis : tools and techniques
GEIB J.M..
GRANSART Ch.
MERLE Ph.
CORBA, des concepts la pratique
Dunod, 1999
(cet ouvrage est tlchargeable sur le site
corbaweb.lifl.fr/CORBA_des_concepts_a_la_pratique/).
GILLET J.M. L'interface graphique
InterEditions, 1995.
HAINAUT J.L. Conception assiste des applications informatiques :
conception de la base de donnes
Masson, 1986.
JACKSON M. Principles of Program Design
Academic Press, 1975.
JACOBSON I.
BOOCH G.
RUMBAUGH J.
Le processus unifi de dveloppement logiciel, trad. franaise
Eyrolles, 2000.
JACOBSON I., al. Object-Oriented Software Engineering : a Use Case Driven Approach
Addison-Wesley, 1992.
LE MOIGNE J.L. La thorie du systme gnral
Presses Universitaires de France, 1977.
LISKOV B.
GUTTAG J.
Abstraction and Specification in Program Development
M.I.T. Press, 1988.
MARTIN J. Rapid Application Development
MacMillan Publishing, 1991.
MARTIN J. Diagramming Techniques for Analysts and Programmers
Prentice Hall.
MEYER B. The New Culture of Software Development :
Reflexions on the practice of Object-Oriented Design
in Journ'ALMIN, n 14, mars 1990.
MULLER P.A. Modlisation objet avec UML
Eyrolles, 1997.
OMG Unified Modeling Language Specification, vers. 1.4
www.omg.org, 2002.
OMG CORBA / IIOP Specification, vers. 3.0
www.omg.org, 2002.
PETERSON J.L. Petri Nets
in ACM Computing Surveys, vol. 9, n 3, sept. 1977.
ROLLAND C. Introduction la conception des systmes d'information
et panorama des mthodes disponibles
in Gnie Logiciel, n 4.
RUMBAUGH A., al. OMT Modlisation et conception orientes objet, trad. franaise
Masson, 1995.
SMITH J.
SMITH D.
Data Base Abstractions : Aggregation and Generalization
in ACM TODS, 1977.
TARDIEU H.
ROCHFELD A.
COLLETTI R.
La mthode MERISE
d. d'Organisation, 1983.
TSICHRITZIS D.
KLUG A.
The ANSI/X3/SPARC DBMS Framework
in Information Systems, 1978.
WARNIER J.D. Les procdures de traitement et leurs donnes
d. d'Organisation, 1973.
WEIZENBAUM J. Puissance de l'ordinateur et raison de l'homme, trad. franaise
d. d'Informatique, 1981.
WIENER N. Cyberntique et socit, trad. franaise
d. des Deux Rives, 1952.
YOURDON E. Modern Structured Analysis
i
Table des matires
CHAPITRE 1. INTRODUCTION AUX MTHODES D'ANALYSE..................................................... 1-1
1. Systmes d'information........................................................................................................................... 1-1
1.1. Le concept d'information................................................................................................................................... 1-1
1.2. Applications de l'informatique la gestion des organisations humaines ........................................................... 1-1
1.3. Applications techniques et scientifiques de l'informatique................................................................................ 1-2
2. Analyse des systmes d'information........................................................................................................ 1-3
2.1. Etapes de l'analyse............................................................................................................................................. 1-3
2.2. Niveaux de modlisation ................................................................................................................................... 1-4
2.3. Articulation gnrale de la dmarche ................................................................................................................ 1-6
3. Mthodologie de l'analyse...................................................................................................................... 1-8
3.1. Contenu d'une mthodologie............................................................................................................................. 1-8
3.2. Utilit d'une mthode......................................................................................................................................... 1-9
3.3. Schmas et Maquettes ..................................................................................................................................... 1-10
3.4. Modlisation et Programmation ...................................................................................................................... 1-12
3.5. L'quipe de dveloppement ............................................................................................................................. 1-12
4. Contenu du cours : Modlisation des applications informatiques ...................................................... 1-14
CHAPITRE 2. INTRODUCTION LA MODLISATION DES DONNES....................................... 2-1
1. BASES DE DONNES ET MODLISATION....................................................................................................... 2-2
1.1. Le concept de Systme de Gestion de Bases de Donnes (SGBD)...................................................... 2-2
1.2. Niveaux de modlisation...................................................................................................................... 2-2
a) Vues externes ....................................................................................................................................................... 2-2
b) Vue conceptuelle.................................................................................................................................................. 2-3
c) Vue interne........................................................................................................................................................... 2-3
1.3. Langage de description de donnes Schmas................................................................................. 2-4
2. FONDEMENTS DES TECHNIQUES DE MODLISATION DES DONNES............................................................... 2-5
2.1. Les mcanismes d'abstraction ............................................................................................................. 2-5
a) Classification : Type, Classe, Occurrence, Collection......................................................................................... 2-5
b) Spcialisation, Gnralisation .............................................................................................................................. 2-6
2.2. Mcanisme de dsignation des occurrences........................................................................................ 2-7
a) La relation de dpendance fonctionnelle .............................................................................................................. 2-7
b) Le concept d'identifiant ........................................................................................................................................ 2-7
2.3. Dimensions temporelles de l'information ............................................................................................ 2-7
a) Dure de vie ......................................................................................................................................................... 2-7
b) Priode de validit................................................................................................................................................ 2-8
c) Priode de mmorisation, Dure de rtention....................................................................................................... 2-8
2.4. Contraintes d'intgrit......................................................................................................................... 2-8
2.5. Aspects dynamiques des donnes......................................................................................................... 2-9
3. PANORAMA HISTORIQUE............................................................................................................................ 2-10
3.1. Les SGBD oprationnels ................................................................................................................... 2-10
3.2. Les mthodes d'analyse ..................................................................................................................... 2-10
a) Modles d'analyse des donnes .......................................................................................................................... 2-10
b) Outils d'aide la conception .............................................................................................................................. 2-11
c) Plan du cours...................................................................................................................................................... 2-11
ii
CHAPITRE 3. LE SCHMA CONCEPTUEL DES DONNES............................................................. 3-1
1. LE MODLE ENTITASSOCIATION.............................................................................................................. 3-2
1.1. Contenu du modle EntitAssociation............................................................................................... 3-2
a) Entit .................................................................................................................................................................... 3-2
b) Association........................................................................................................................................................... 3-4
Le concept d'Association....................................................................................................................................... 3-4
Notation UML....................................................................................................................................................... 3-6
Connectivit des associations................................................................................................................................ 3-6
Les connectivits dans la notation UML............................................................................................................... 3-8
c) Attribut ................................................................................................................................................................. 3-9
Attribut et Domaine............................................................................................................................................... 3-9
Noms d'attributs .................................................................................................................................................. 3-11
Proprits des attributs........................................................................................................................................ 3-11
Dfinition des domaines de valeurs..................................................................................................................... 3-12
d) Identifiants ......................................................................................................................................................... 3-12
Identifiant d'un type d'entit................................................................................................................................ 3-12
Identifiant d'un type d'association ....................................................................................................................... 3-13
Identifiants multiples........................................................................................................................................... 3-14
Proprits des identifiants ................................................................................................................................... 3-15
e) Dimension historique ......................................................................................................................................... 3-16
f) Discussion........................................................................................................................................................... 3-17
1.2. Structures particulires ..................................................................................................................... 3-18
a) Compositions smantiquement quivalentes ...................................................................................................... 3-18
b) Associations non reprsentables......................................................................................................................... 3-18
Critique du modle EntitAssociation............................................................................................................... 3-19
2. APPORTS DU PARADIGME OBJET................................................................................................................ 3-20
2.1. Classes d'objets.................................................................................................................................. 3-20
a) Les concepts ....................................................................................................................................................... 3-20
b) Spcification des oprations............................................................................................................................... 3-21
Spcification externe........................................................................................................................................... 3-21
Dfinition smantique ......................................................................................................................................... 3-22
c) Aperu sur le langage IDL.................................................................................................................................. 3-22
2.2. Modlisation des relations dabstraction .......................................................................................... 3-24
a) Agrgation / Contenance .................................................................................................................................... 3-24
b) Classification / Instanciation .............................................................................................................................. 3-26
c) Gnralisation / Spcialisation ........................................................................................................................... 3-27
2.3. Schma dynamique : diagrammes dtats et transitions................................................................... 3-28
a) Etats.................................................................................................................................................................... 3-28
b) Transitions.......................................................................................................................................................... 3-29
c) Mthode.............................................................................................................................................................. 3-30
3. CONTRAINTES D'INTGRIT........................................................................................................................ 3-31
3.1. Porte des contraintes dintgrit ..................................................................................................... 3-31
3.2. Connectivit et identifiant.................................................................................................................. 3-31
3.3. Dure de rtention............................................................................................................................. 3-31
3.4. Contraintes ensemblistes ................................................................................................................... 3-32
3.5. Rgles relatives la valeur des attributs........................................................................................... 3-32
a) Dfinition des domaines de valeurs.................................................................................................................... 3-32
Domaine lmentaire........................................................................................................................................... 3-32
Domaine structur............................................................................................................................................... 3-33
b) Restriction du domaine (condition d'appartenance) .......................................................................................... 3-33
c) Relations entre attributs...................................................................................................................................... 3-33
Contraintes statiques ........................................................................................................................................... 3-33
Contraintes d'volution ....................................................................................................................................... 3-34
3.6. Dfinition smantique des oprations ............................................................................................... 3-35
3.7. Formalisme pour l'expression des rgles .......................................................................................... 3-36
a) La notion de rgle............................................................................................................................................... 3-36
b) La notion de variable.......................................................................................................................................... 3-36
c) Les ensembles..................................................................................................................................................... 3-38
iii
4. VALIDATION DU SCHMA........................................................................................................................... 3-39
4.1. Suppression des incohrences ........................................................................................................... 3-39
a) Correction des anomalies lexicographiques ....................................................................................................... 3-39
b) Vrification des contraintes, Elimination des contradictions ............................................................................. 3-39
4.2. Affinage du schma............................................................................................................................ 3-39
a) Normalisation des composants ........................................................................................................................... 3-39
b) Spcialisation par sous-typage ........................................................................................................................... 3-41
Gnralisations implicites ................................................................................................................................... 3-41
Associations conditionnelles............................................................................................................................... 3-41
4.3. Simplification du schma................................................................................................................... 3-42
a) Simplification des structures .............................................................................................................................. 3-42
Associations de degr lev ................................................................................................................................ 3-42
Compositions de connectivits 1:1...................................................................................................................... 3-42
b) Contrle des structures redondantes................................................................................................................... 3-43
c) Cas particulier : les attributs drivables............................................................................................................. 3-43
4.4. Note sur les sous-schmas ................................................................................................................. 3-44
5. VALIDATION DU SYSTME DE RGLES........................................................................................................ 3-45
5.1. Compltude du systme de rgles ...................................................................................................... 3-45
5.2. Cohrence du systme de rgles ........................................................................................................ 3-45
6. EN GUISE DE CONCLUSION......................................................................................................................... 3-46
6.1. Recommandations diverses................................................................................................................ 3-46
6.2. Documentation du schma................................................................................................................. 3-47
CHAPITRE 4. SCHMA LOGIQUE DU STOCKAGE DES DONNES.............................................. 4-1
1. SCHMA DES STRUCTURES DE STOCKAGE : LE MODLE EN RSEAU ........................................................... 4-2
1.1. Elments d'une structure de stockage.................................................................................................. 4-2
1.2. Transformation du schma EntitAssociation ................................................................................... 4-2
1.3. Commentaires sur le concept de liaison.............................................................................................. 4-6
a) Terminologie ........................................................................................................................................................ 4-7
b) Contraintes dfinies sur les liaisons ..................................................................................................................... 4-7
Liaison obligatoire ou facultative.......................................................................................................................... 4-7
Connectivit d'un type de liaison .......................................................................................................................... 4-7
c) Interprtation d'une liaison comme tant une association..................................................................................... 4-8
1.4. Optimisation du schma ...................................................................................................................... 4-9
a) Gnralisation....................................................................................................................................................... 4-9
b) Dnormalisation................................................................................................................................................. 4-10
Propagation parent ==> enfants .......................................................................................................................... 4-10
Drivation parent(s) ==> enfants ........................................................................................................................ 4-11
Rcapitulation enfants ==> parent ...................................................................................................................... 4-12
Fusion des enregistrements parent et enfants ...................................................................................................... 4-12
1.5. Structures particulires ..................................................................................................................... 4-12
a) Enregistrement d'intersection ............................................................................................................................. 4-12
b) Liaison cyclique ................................................................................................................................................. 4-13
1.6. Contraintes d'intgrit....................................................................................................................... 4-14
a) Reformulation des rgles .................................................................................................................................... 4-14
b) Relaxation des contraintes de connectivit 1:N.................................................................................................. 4-14
c) Intgrit des rfrences....................................................................................................................................... 4-15
Cration du propritaire d'une liaison ................................................................................................................. 4-15
Suppression du propritaire d'une liaison ........................................................................................................... 4-15
2. PRPARATION DU SCHMA PHYSIQUE........................................................................................................ 4-16
2.1. Schma des fonctions d'accs ............................................................................................................ 4-16
a) Introduction........................................................................................................................................................ 4-16
b) Prliminaire : le concept d'ensemble selon CODASYL.................................................................................... 4-16
c) Dfinition des mthodes d'accs ........................................................................................................................ 4-17
Cl d'accs........................................................................................................................................................... 4-17
Squence d'accs ................................................................................................................................................. 4-18
Chemin d'accs.................................................................................................................................................... 4-19
2.2. Quantification du schma.................................................................................................................. 4-20
iv
3. LE SCHMA LOGIQUE DES DONNES, SUPPORT DE LA PROGRAMMATION.................................................... 4-21
3.1. Parcours d'un ensemble..................................................................................................................... 4-21
3.2. Sous-schma arborescent .................................................................................................................. 4-21
3.3. Transformation squentielle des sous-schmas arborescents............................................................ 4-23
a) Constitution des fichiers squentiels .................................................................................................................. 4-23
b) Cas particulier : ensembles htrognes............................................................................................................ 4-23
c) Syntaxe de dfinition.......................................................................................................................................... 4-24
d) Contraintes particulires aux fichiers COBOL................................................................................................... 4-24
e) Ralisation des fonctions d'accs........................................................................................................................ 4-25
Fonctions d'accs internes un fichier squentiel ............................................................................................... 4-25
Fonctions d'accs inter-fichiers ........................................................................................................................... 4-26
3.4. Mthode de construction des programmes ........................................................................................ 4-27
a) Graphe des accs aux donnes............................................................................................................................ 4-28
b) Rgles du traitement........................................................................................................................................... 4-29
c) Structure du programme..................................................................................................................................... 4-30
CHAPITRE 5. SCHMA PHYSIQUE DE LA BASE DE DONNES.................................................... 5-1
1. LES BASES DE DONNES CODASYL........................................................................................................... 5-2
1.1. Le langage de description de donnes (DDL) .................................................................................... 5-3
a) Schma de la base de donnes.............................................................................................................................. 5-3
Fichiers (AREA) .................................................................................................................................................. 5-3
Enregistrements (RECORD) ................................................................................................................................ 5-3
Ensembles (SET).................................................................................................................................................. 5-4
Cls d'accs et identifiants..................................................................................................................................... 5-6
Exemple rcapitulatif ............................................................................................................................................ 5-6
b) Sous-schmas ....................................................................................................................................................... 5-8
1.2. Le langage de manipulation des donnes (DML)............................................................................... 5-8
a) Contrle de l'accs aux fichiers : OPEN, CLOSE ............................................................................................... 5-8
b) Les mcanismes de navigation ............................................................................................................................. 5-8
Enregistrements courants ...................................................................................................................................... 5-8
Localisation d'un enregistrement : FIND ............................................................................................................. 5-9
Test de l'appartenance d'un enregistrement un ensemble.................................................................................... 5-9
Lecture d'un enregistrement : GET..................................................................................................................... 5-10
c) Mise jour des donnes ..................................................................................................................................... 5-10
Cration/Modification d'un enregistrement : STORE, MODIFY....................................................................... 5-10
Inclusion/Retrait d'un membre dans un ensemble : INSERT, REMOVE .......................................................... 5-11
Suppression d'un enregistrement : DELETE...................................................................................................... 5-11
2. LES BASES DE DONNES RELATIONNELLES ................................................................................................ 5-12
2.1. Le modle relationnel des donnes.................................................................................................... 5-12
a) Les relations ....................................................................................................................................................... 5-12
b) Identification et Normalisation........................................................................................................................... 5-14
c) L'algbre relationnelle (pour mmoire) ............................................................................................................. 5-14
2.2. Le dictionnaire des donnes (SQL)................................................................................................... 5-15
a) Dfinition des domaines ..................................................................................................................................... 5-15
b) Dfinition des tables........................................................................................................................................... 5-16
Note sur les contraintes d'intgrit rfrentielle .................................................................................................. 5-18
c) Dfinition des assertions..................................................................................................................................... 5-18
Note sur les transactions et la vrification des contraintes .................................................................................. 5-19
d) Mise jour automatique des donnes drivables ............................................................................................... 5-19
e) Les vues.............................................................................................................................................................. 5-22
f) Cration dindex ................................................................................................................................................. 5-23
2.3. La manipulation des donnes ............................................................................................................ 5-24
a) Oprations disponibles ....................................................................................................................................... 5-24
Consultation : SELECT ..................................................................................................................................... 5-24
Cration de lignes : INSERT.............................................................................................................................. 5-25
Modification de lignes : UPDATE..................................................................................................................... 5-25
Suppression de lignes : DELETE....................................................................................................................... 5-25
b) Modes d'utilisation du langage SQL .................................................................................................................. 5-25
v
c) SQL insr.......................................................................................................................................................... 5-26
Reprage des instructions SQL insres.............................................................................................................. 5-26
Communication des donnes............................................................................................................................... 5-26
Signalisation des incidents .................................................................................................................................. 5-26
Les curseurs......................................................................................................................................................... 5-27
Exemple COBOL................................................................................................................................................ 5-27
CHAPITRE 6. INTRODUCTION LA MODLISATION DES SYSTMES..................................... 6-1
1. HIRARCHISATION DU SYSTME D'INFORMATION ........................................................................................ 6-2
1.1. Systme ................................................................................................................................................ 6-2
1.2. Tche ................................................................................................................................................... 6-3
Programme ................................................................................................................................................................ 6-4
Objet .......................................................................................................................................................................... 6-4
Tche = Transaction .................................................................................................................................................. 6-4
1.3. Module................................................................................................................................................. 6-5
2. NIVEAUX INTERMDIAIRES.......................................................................................................................... 6-6
CHAPITRE 7. LES DIAGRAMMES DE FLUX....................................................................................... 7-1
1. SCHMA FONCTIONNEL ............................................................................................................................... 7-2
1.1. Contenu d'un diagramme de flux......................................................................................................... 7-2
a) Environnement ..................................................................................................................................................... 7-2
b) Processus.............................................................................................................................................................. 7-3
c) Flux de donnes.................................................................................................................................................... 7-4
Flux direct, Messages............................................................................................................................................ 7-4
Flux indirect, Dpt de donnes............................................................................................................................ 7-6
Permabilit des classes de flux directs et indirects .............................................................................................. 7-8
1.2. Structures typiques .............................................................................................................................. 7-8
a) Applications sans flux directs............................................................................................................................... 7-8
b) Dcomposition suivant un axe spatio-temporel dominant.................................................................................... 7-9
c) Systmes rguls................................................................................................................................................. 7-10
1.3. Validation des diagrammes de flux.................................................................................................... 7-11
a) Syntaxe des diagrammes de flux......................................................................................................................... 7-11
Relations entre composants................................................................................................................................. 7-11
Dnomination des composants............................................................................................................................ 7-12
Remarque. Mise en page d'un diagramme de flux.............................................................................................. 7-12
b) Hirarchisation des diagrammes......................................................................................................................... 7-12
1.4. Spcification d'un processus.............................................................................................................. 7-14
a) Description externe de la fonction...................................................................................................................... 7-15
b) Description de l'interface d'une tche................................................................................................................. 7-16
c) Spcification dtaille des rgles........................................................................................................................ 7-16
Niveaux de dfinition des rgles ......................................................................................................................... 7-16
Expression des rgles .......................................................................................................................................... 7-16
Vrification des rgles......................................................................................................................................... 7-17
d) Dfinition interne de la procdure...................................................................................................................... 7-17
2. SCHMA DYNAMIQUE................................................................................................................................ 7-21
2.1. Contenu du schma dynamique ......................................................................................................... 7-21
a) Processus ............................................................................................................................................................ 7-21
b) Evnement.......................................................................................................................................................... 7-21
c) Moniteur............................................................................................................................................................. 7-23
2.2. Types d'enchanements ...................................................................................................................... 7-24
2.3. Spcification d'un moniteur............................................................................................................... 7-25
2.4. Validation du schma dynamique...................................................................................................... 7-26
a) Compltude du schma....................................................................................................................................... 7-26
b) Cohrence du schma......................................................................................................................................... 7-27
Evnements initiaux............................................................................................................................................ 7-27
Processus atteignables......................................................................................................................................... 7-28
Terminaison propre............................................................................................................................................. 7-28
3. SCHMA DE DPLOIEMENT ........................................................................................................................ 7-29
vi
CHAPITRE 8. MTHODES ORIENTES OBJETS............................................................................... 8-1
1. SCHMAS DOPRATIONS ............................................................................................................................ 8-2
1.1. Prambule : unification des mthodes autour du concept dObjet..................................................... 8-2
1.2. Les diagrammes dinteraction ............................................................................................................. 8-2
a) Concepts introductifs............................................................................................................................................ 8-2
b) Notations communes............................................................................................................................................ 8-3
c) Diagramme de collaboration................................................................................................................................. 8-4
d) Diagramme de squence....................................................................................................................................... 8-4
2. LE SCHMA DES CAS DUTILISATION........................................................................................................... 8-6
2.1. Prambule : le contexte historique..................................................................................................... 8-6
a) Libralisation de l'usage des ordinateurs .............................................................................................................. 8-6
b) Modernisation des mthodes danalyse................................................................................................................ 8-7
2.2. Contenu du modle des Cas dUtilisation ........................................................................................... 8-8
a) Systme ................................................................................................................................................................ 8-8
b) Acteur................................................................................................................................................................... 8-8
Acteur externe....................................................................................................................................................... 8-8
c) Cas dutilisation.................................................................................................................................................... 8-9
d) Scnario.............................................................................................................................................................. 8-10
2.3. Spcification des scnarios................................................................................................................ 8-11
a) Flot dvnements .............................................................................................................................................. 8-11
b) Diagramme de squence..................................................................................................................................... 8-12
2.4. Relations entre cas dutilisation ........................................................................................................ 8-12
a) Relations concrtes............................................................................................................................................. 8-13
Utilisation............................................................................................................................................................ 8-13
Extension ............................................................................................................................................................ 8-13
b) Relations abstraites............................................................................................................................................. 8-14
Inclusion.............................................................................................................................................................. 8-14
Gnralisation ..................................................................................................................................................... 8-14
2.5. Analyse des cas dutilisation : du scnario aux objets ..................................................................... 8-15
a) Classification des composants ............................................................................................................................ 8-15
Larchitecture ModleVueContrleur (SMALLTALK)................................................................................. 8-15
Les classes danalyse (JACOBSON).................................................................................................................. 8-16
Commentaires ..................................................................................................................................................... 8-17
b) Diagramme de collaboration .............................................................................................................................. 8-17
c) Diagramme des classes "conceptuelles" ............................................................................................................. 8-19
3. CONCEPTION DUNE ARCHITECTURE LOGICIELLE....................................................................................... 8-20
3.1. Nature de la dmarche de conception ............................................................................................... 8-20
3.2. Le concept darchitecture logicielle .................................................................................................. 8-22
3.3. Le principe d'architecture Client / Serveur ................................................................................. 8-23
a) Etat de lart des dveloppements informatiques ................................................................................................. 8-23
Linformatique clate ................................................................................................................................... 8-23
Outils avancs ..................................................................................................................................................... 8-24
b) Dfinition de larchitecture Client / Serveur ...................................................................................................... 8-24
c) Rgle de rpartition ............................................................................................................................................ 8-24
d) Varit des paradigmes de programmation ........................................................................................................ 8-26
3.4. Motifs architecturaux ("Patterns") ................................................................................................... 8-27
3.5. Industrialisation du processus de dveloppement ............................................................................. 8-28
BIBLIOGRAPHIE ........................................................................................................................................B-1

Methodes D Analyse

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Methodes D Analyse

Diunggah oleh

Hak Cipta:

Format Tersedia

H.E.M.E.S.

Anda mungkin juga menyukai