Analyse PDF

H.E.M.E.S.
– Informatique
André CLARINVAL
Méthodes d’Analyse
édition : septembre 2002

Chapitre 1. Introduction aux méthodes d'analyse
La matière qui va nous occuper relève de la méthodologie d'analyse des systèmes d'information. Ce premier
chapitre introduit brièvement les trois termes définissant ce contexte : système d'information, analyse, métho-
dologie.
1. Systèmes d'information
1.1. Le concept d'information
L'information est représentée par des données, c'est-à-dire des formes écrites (textes, nombres ...), picturales
(graphiques, dessins, photos, vidéos ...) et sonores. Ces données sont matérialisées sur des supports (papier,
écrans, bandes magnétiques, disquettes, CD ...). A ces représentations, un être humain, une organisation ou
une machine (ordinateur, robot ...) attache une signification susceptible d'entraîner une modification, immé-
diate ou différée, de son comportement.
ex.: un automobiliste voyant les lettres STOP sur un panneau rouge octogonal [données] arrête sa
voiture [comportement]
ex.: un client ayant reçu une facture [données] prend son téléphone [comportement] pour donner
un ordre de virement à sa banque [données]; l'ordinateur de la banque recevant de la ligne télépho-
nique les chiffres composant le virement [données] effectue diverses opérations [comportement]
ex.: après avoir accumulé des données statistiques relatives à ses ventes, à la concurrence, etc., la di-
rection d'une firme commerciale décide de changer sa politique et de modifier son catalogue : elle en
retire certains produits et en introduit d'autres ...
On peut définir une information comme étant l'accroissement de connaissance découlant de l'interprétation
d'un ensemble de données. Cette interprétation est le fait d'un acteur humain ou mécanique.
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 reflète les flux de matières (fabrications, achats, ventes ...), les flux financiers, les échanges de servi-
ces ... qui forment la matière de l'activité de l'entreprise. Reçue par les acteurs de l'organisation, elle com-
mande leur comportement. Echantillonnée et synthétisée, elle éclaire et supporte les décisions aux différents
niveaux de responsabilité dans l'organisation.
Si, d'après J. de ROSNAY1, "un système est un ensemble d'éléments en interaction dynamique, organisés en
fonction d'un but", on peut, à la suite notamment des auteurs de la méthode MERISE2, distinguer au sein du
système qu'est toute entreprise ou organisation les trois sous-systèmes schématisés sur la figure suivante.
1 J. de ROSNAY : Le macroscope; éd. du Seuil, 1975.

2 H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode MERISE; éd. d'Organisation, 1983.
© A. CLARINVAL Analyse — Introduction 1-1

SYSTEME DE
DECISION/PILOTAGE
support
SYSTEME
D'INFORMATION
commande
reflet
SYSTEME OPERANT
Les fonctions d'un système d'information sont de conserver (mémoriser), créer (transformer) et communi-
quer (diffuser) de l'information, plus précisément : des données que les acteurs interprètent.
De nos jours, les acteurs du traitement de l'information sont les hommes et les machines, et un système d'in-
formation est partiellement automatisé; les opérations sont "programmées" sur des ordinateurs, "manuelles"
(sic) ou "interactives" (c'est-à-dire mettant en communication immédiate les acteurs humains et mécani-
ques) ... Nous appellerons applications informatiques — "applications de l'informatique" serait plus correct
— les parties automatisées d'un système d'information.
1.3. Applications techniques et scientifiques de l'informatique
La figure ci-dessus, schématisant le rôle du système 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'intérieur
d'un téléviseur) ou d'une machinerie complexe (une centrale électrique) qui, à la fois, en reflète l'état et en
commande le fonctionnement (l'information affichée sur les tableaux de contrôle d'une centrale électrique sert
à la piloter ...). Nous donnerons plus loin le nom de modèle d'un phénomène à une représentation abstraite de
ce phénomène; — le rôle de l'informatique dans une application de robotisation consiste à maintenir, analy-
ser et manipuler un modèle mathématique du processus.
Relevons un usage particulier de l'informatique dans les domaines de la science et de la technique. Alors que
l'on pourrait considérer que le système d'information d'une organisation — telle qu'une entreprise commer-
ciale, un club ou une association, un hôpital ou une école — constitue une sorte de simulation en temps réel de
son fonctionnement, les techniciens et les scientifiques réalisent très couramment des programmes de simula-
tion "à l'avance" d'une réalité future, voire purement hypothétique. En recherche médicale, la simulation in-
formatique commence timidement à remplacer l'expérimentation animale ...
Des progrès récents dans les méthodes de calcul permettent la simulation de beaucoup de structures
physiques sans avoir à les construire. La simulation n'est pas seulement moins chère, elle permet
aussi de fournir de l'information qui, sur les modèles physiques, est soit trop insaisissable, soit diffi-
cile à mesurer. La construction de modèles physiques ou informatiques revient généralement moins
cher que la construction du système complet et permet de corriger plus tôt les déficiences. 1
1 J. RUMBAUGH, al. : OMT — Modélisation et conception orientées objet, trad. française; Masson, 1995.

2. Analyse des systèmes d'information
Comme tout phénomène humain, un système d'information évolue et est périodiquement atteint d'obsoles-
cence. Il est alors nécessaire d'en développer un nouveau ou, du moins, une nouvelle version. Cette idée de
développer ou fabriquer est évidemment particulièrement pertinente pour la partie "programmée" du système,
c'est-à-dire pour les applications informatiques.
Dans le développement d'un projet informatique, on donne le nom général d'analyse à l'ensemble des démar-
ches accomplies avant de rédiger et mettre au point les programmes.
L'analyse se déroule en plusieurs étapes et elle procède à différents niveaux ou de différents points de vue.
2.1. Etapes de l'analyse
La tradition américaine, foncièrement 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 contrées, désignées sous les noms d'analyse fonctionnelle (= étude
des fonctionnalités, c'est-à-dire de l'utilité, du système à mettre en place) et analyse organique (= description
des organes composant la solution).
• Habituellement, une étude préalable d'opportunité part d'une critique du système d'information
existant, qu'elle décrit plus ou moins exhaustivement, avec plus ou moins de détail. Elle justifie une
nouvelle solution, qu'elle recommande et à laquelle elle assigne des objectifs. L'étude d'opportunité
dit le "pourquoi"; elle motive la décision de mettre un projet en chantier.
• L'analyse fonctionnelle détaille le "quoi" de la solution, pas encore le comment : "abstraction

précise du but de l'application et non de la façon dont elle sera bâtie".1 Elle décrit complètement le
contenu sémantique et logique du nouveau système à mettre en place, sans prendre en considération
les moyens à mettre en œuvre pour le faire fonctionner.
• "Comment ?" L'étape de conception définit la réalisation de ce système sous la forme de cons-
tructions — programmes et procédures — utilisant au mieux les ressources techniques et organisa-
tionnelles : logiciels, équipements, personnel, locaux, horaires, etc.
De manière générale [...], le développement d'une application répond à quatre questions :
Application = Quoi + Dans quel domaine + Comment + Avec quelles compétences
Ces questions correspondent à différents points de vue et concernent différents intervenants. Elles
peuvent être étudiées selon des techniques variées, mais doivent dans tous les cas être considérées
pour développer une application :
• Quoi faire ? La réponse est exprimée par l'utilisateur qui décrit ce qu'il attend du système, com-
ment il entend interagir avec lui et quels sont les différents intervenants. Il s'agit d'une description
fonctionnelle qui ne rentre pas dans les détails de la réalisation : le quoi faire est purement des-
criptif.
1 J. RUMBAUGH, al. : op. cit.

• Dans quel domaine ? La réponse doit décrire le domaine (l'environnement) dans lequel l'appli-
cation va exister et préciser quels sont les éléments pertinents dans ce domaine pour l'application.
L'étude du domaine est le fruit d'une analyse, totalement déconnectée de toute considération de ré-
alisation. Le domaine est analysé par un analyste et doit pouvoir être compris par un utilisateur.
• Comment ? Il faut le déterminer lors de la conception. Le comment est le fruit de l'expérience et

du savoir-faire du concepteur. La conception est l'art de rendre possible les désirs de l'utilisateur —
exprimés dans le quoi faire — en considérant le domaine de l'application et en tenant compte des
contraintes de réalisation.
• Avec quelles compétences ? Il faut déterminer tout ce qui est nécessaire à la fabrication de l'ap-
plication. Ce point repose sur des compétences techniques pour le développement [...], sur des
compétences d'animation pour l'encadrement des équipes et sur des compétences d'organisation
pour assurer la logistique générale. 1
2.2. Niveaux de modélisation
Le texte reproduit ci-dessus souligne la multiplicité des points de vue développés lors de l'analyse (au sens
large) d'une application informatique.
Et, en effet, l'analyse d'un système d'information consiste pour l'essentiel à en établir différents modèles, c'est-
à-dire différentes représentations abstraites et réductrices, selon divers points de vue qui se complètent pro-
gressivement.
– Les modèles mathématiques mis au point par les astronomes leur permettent de prévoir des années
à l'avance les phénomènes célestes tels que les éclipses; leurs abstractions mathématiques s'avèrent
d'une efficacité infaillible. Pour établir leurs prévisions, plus aléatoires, les météorologues se fondent
sur des modèles probabilistes.
– Nous l'avons déjà évoqué : dans les applications industrielles, l'ordinateur qui "pilote" un proces-
sus manipule en réalité un modèle mathématique de ce processus.
– Le système comptable d'une entreprise est un modèle de celle-ci, fortement réducteur puisqu'il ra-
mène tous les événements de la vie de cette entreprise à de pures quantifications monétaires; il est
néanmoins très efficace pour la gestion et la conduite de l'entreprise.
Mais on ne recourt pas à des modèles que pour prévoir ou piloter, on en utilise aussi beaucoup dans les dé-
marches de création. C'est dans ce but que les informaticiens élaborent des modèles avant de programmer.
Un modèle est une abstraction de quelque chose de réel qui permet de comprendre avant de cons-
truire. Parce qu'il ne tient pas compte des éléments qui ne sont pas essentiels, le modèle est plus fa-
cile à manipuler que l'entité originale. L'abstraction est une capacité fondamentalement humaine
qui nous permet de gérer la complexité. Depuis des milliers d'années, les ingénieurs, artistes et arti-
sans construisent des modèles pour tester leurs concepts avant de les exécuter. Le développement du
matériel informatique et du logiciel ne fait pas exception. Pour construire des systèmes complexes,
le développeur doit abstraire différentes vues du système, construire des modèles en utilisant une
notation précise, vérifier que les modèles satisfont aux spécifications du système, et progressivement
ajouter des détails pour transformer les modèles en une implémentation. 2
1 P.A. MULLER : Modélisation objet avec UML; Eyrolles, 1997.


Dans le sillage de la méthode MERISE (± 1980), la tradition française, plus spéculative, distingue des ni-
veaux de modélisation : les niveaux conceptuel, logique et physique.
Ambiguïtés terminologiques
Conception. Comme traduction du terme américain "design", le mot conception désigne le fait d'élaborer une
architecture; dans la démarche française, il désigne le fait de conceptualiser, de réduire à l'état notionnel.
Modèle. Lorsqu'ils emploient une expression du genre "le modèle relationnel" ou "le modèle Entité–Asso-
ciation", les informaticiens désignent une théorie sur laquelle ils se fondent pour structurer leurs propres des-
criptions, qu'ils appellent alors des schémas. (Ajoutons qu'un schéma peut être celui d'un programme de si-
mulation, c'est-à-dire le modèle d'un modèle !) Si ces théories de la décennie 1970 avaient vu le jour dix an-
nées plus tard, sans doute les appellerait-on "paradigme relationnel" et "paradigme Entité–Association"
comme, en programmation, on parle aujourd'hui du "paradigme Objet".1
• Un schéma conceptuel exprime la sémantique du système qu'il représente : il fait apparaître les
concepts, avec leurs relations et contraintes. Il a vocation d'être un instrument d'échange compréhen-
sible par l'utilisateur "client" ou "commanditaire" du système d'information.
Exemples de spécifications :
types d'objets ou concepts : CLIENT, COMMANDE

associations entre types d'objets : 1 CLIENT → n COMMANDE
prédicats restrictifs (contraintes) : ∀ Qté commandée > 0
équations (règles de calcul) : Qté livrée = MIN (Qté commandée, Qté en stock)
méthodes abstraites : enregistrer une commande, établir une facture2
• Un schéma logique est la traduction d'un schéma conceptuel en termes de composants program-
mables ou, plus largement, réalisables. Reflétant le plus directement qu'il se peut à la fois la spécifi-
cation conceptuelle et l'état (la modernité) des ressources et techniques que l'on souhaite mettre en
œuvre, il sert de référence pour les techniciens du système d'information.
clés d'accès : référence du CLIENT dans l'enregistrement COMMANDE

tables de codification : code Catégorie-Client
actions de vérification des contraintes : si Qté commandée = 0 → message "cde nulle"
sous-programmes de calcul : Calcul-Echéance (date-départ, délai) → date-échéance
• Transformation finale d'un schéma logique, un schéma physique doit prendre en compte les para-
mètres de performance du système selon différents points de vue — économique, technique, sécuri-
taire, ergonomique, etc. — : configurations matérielles nécessaires, charge et coût d'utilisation des
réseaux de télécommunication, délais d'attente des résultats, protection contre les intrusions et mal-
veillances, etc.
1 Paradigme [logique] : modèle théorique de pensée qui oriente la recherche et la réflexion scientifiques. —
Petit Larousse 1997.
2 Méthode abstraite = prendre note de telle donnée, retrouver telle autre information, calculer tel résultat, etc.

regroupements de données (fusion de types d'objets ...)

cryptage des données sensibles
dédoublement des contrôles de validité dans une architecture décentralisée
choix des polices de caractères pour les affichages à l’écran
variantes d'une tâche : réception des commandes au comptoir, par courrier, par téléphone
2.3. Articulation générale de la démarche
L'étude du texte ci-dessous montrera que les deux démarches, l'américaine et la française, ne sont pas antino-
miques.
Mais le mérite principal de ce texte (sur lequel il vaut la peine de revenir souvent pour le méditer) est de
mettre en évidence le "souffle" qui doit inspirer l'analyste concepteur.
L'analyse [...]
L'analyse [au sens américain] remonte de la conséquence vers le principe : elle essaie de com-
prendre, d'expliquer et de représenter la nature profonde du système qu'elle observe. L'analyse ne
se préoccupe pas de solutions mais de questions; elle identifie le quoi faire et l'environnement d'un
système, sans décrire le comment, qui est le propre de la conception.
L'analyse commence par la détermination 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 représentation approximative de ses besoins réels. La présence 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 reflètent pas les vrais besoins des
utilisateurs. [...]
L'analyse se poursuit par la modélisation 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 représentation des interactions entre ces objets. [...]
L'assise sur les éléments du monde réel facilite le départ de la démarche car elle concentre la pensée
sur des éléments concrets. Elle doit impérativement être poursuivie par une démarche d'abstraction
qui vise à faire oublier les contingences du monde réel et à déterminer les concepts fondateurs qui
sont à leurs origines. Si la réflexion se focalise trop sur l'existant, les risques sont grands de repro-
duire une solution au lieu d'identifier le problème posé [...].
L'analyse est l'antithèse 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 cachée des choses. Le propre de l'analyse est de trouver une description à
laquelle personne n'avait jamais pensé jusqu'alors, mais qui une fois déterminée 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 sécantes, une hyperbole et une parabole et reconnaître que toutes ces formes peuvent être
obtenues par l'intersection d'un plan et d'un cône. Dans ce cas, le principe générateur peut être ex-
primé par une équation de la forme ax2 + by2 + 2cx + 2dy + e = 0. Cette représenta-
tion est économe car elle décrit l'essentiel. L'analyse va à l'essentiel et recherche un modèle généri-
que plus abstrait.

La conséquence immédiate d'une analyse bien menée est toujours une grande économie dans la ré-
alisation qui s'ensuit. [...]
Parallèlement à l'analyse de l'environnement, se déroule parfois une analyse de l'existant et des

contraintes de réalisation. L'objet de cette analyse est de comprendre parfaitement les caractéristi-
ques et les contraintes de l'environnement de réalisation afin de pouvoir prendre lors de la concep-
tion des décisions motivées et réfléchies. [...]
La conception [...]
Comme l'analyse et la conception, la conception et la réalisation se chevauchent en partie. Il est
rare de savoir comment tout faire; pour cette raison, il faut essayer des techniques alternatives,
comparer les résultats puis choisir en faisant des compromis. La conception et la réalisation se
complètent. La conception a besoin d'expérimenter, la réalisation a besoin de principes directeurs.
Afin de maintenir le plus longtemps possible les bénéfices de l'abstraction, la conception est géné-
ralement subdivisée en deux étapes : une étape logique indépendante de l'environnement de réali-
sation et une étape physique qui se préoccupe de l'ordonnancement des ressources et des particula-
rités des langages de programmation ou de l'environnement d'exécution.
La conception est souvent considérée, à tort, comme un simple enrichissement des résultats obtenus
durant l'analyse. Il s'agit là d'une vision fortement réductrice 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'extérieur sous la forme d'outils, de composants réutilisables ou plus largement
de cadres de développement.1 [...]
La conception débute par la détermination 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 dévelop-
pement. L'architecture définit la forme générale de l'application; de sa qualité dépendent le déve-
loppement et l'évolution du logiciel. L'architecture est la conséquence de décisions stratégiques ar-
rêtées lors de la conception et de décisions tactiques prises en cours de réalisation.
Se donner une stratégie informatique, c'est considérer le logiciel comme un élément déterminant du
développement de l'entreprise; c'est aussi chercher à s'assurer une avance technologique par des
choix d'architecture qui dépassent le cadre des besoins immédiats, liés à une application particu-
lière.
Se donner une stratégie informatique, c'est par exemple choisir :
• l'internationalisation, autrement dit, concevoir le logiciel de telle manière que le dialogue avec
l'utilisateur puisse être mené dans toutes les langues;
• la réutilisation qui n'est pas le fruit du hasard, mais le résultat d'une adhésion forte de toute une
organisation, depuis la définition de la ligne de produits jusqu'au développement de ces produits;
• l'unicité de langage pour l'ensemble des développements (Ada dans le cas du ministère de la dé-
fense américain);
• l'indépendance par rapport aux dispositifs d'affichage, autrement dit, le découplage entre l'in-
formation à afficher et la manière de l'afficher;
• la portabilité des sources, voire des exécutables, qui réduit notablement les coûts de développe-
ment et surtout de maintenance dans le cas d'un logiciel multicibles.
[...]
1 "Frameworks".

L'effort développé en conception est plus ou moins important selon la nature de l'application et la ri-
chesse de l'environnement de réalisation. Il est de plus en plus possible d'effectuer un transfert de
complexité des applications vers les environnements [de développement], grâce à une factorisation
des éléments et des mécanismes communs. C'est le cas dans les familles d'applications bien ciblées
dans un domaine donné, comme les logiciels clients qui interagissent avec des serveurs de bases de
données. Inversement, plus une application est technique, plus elle interagit avec des matériels par-
ticuliers et plus l'effort de conception est important.
Les outils RAD — développement rapide d'applications 1 — proposent une voie bien tracée.2 [...]
Il faut suivre les règles du jeu fixées à l'avance : au bénéfice de la simplicité mais au détriment 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 — plutôt que vite
et bien.
Curieusement, le RAD est un mélange de génie logiciel dans sa conception et d'horreur informatique
dans son utilisation. Ceci est la conséquence d'une vision à court terme des utilisateurs pour qui
seul l'aspect rapidité compte bien souvent. Comme le RAD n'encourage pas particulièrement la mo-
dularité et les abstractions en couches, très rapidement — c'est le cas de le dire — le code d'inter-
face utilisateur et le code de l'application se retrouvent intimement mélangés. Le logiciel construit
de cette manière est difficile à maintenir et quasiment impossible à réutiliser pour une autre appli-
cation.
Le propre de la conception est de rechercher l'équilibre entre vitesse de réalisation et possibilité de

réutilisation, ouverture et solution clé en main, vision à court terme (la tactique) et vision à long
terme (la stratégie). 3
3. Méthodologie de l'analyse
3.1. Contenu d'une méthodologie
Une méthode d'élaboration de logiciels décrit comment modéliser et construire des systèmes logi-
ciels de manière fiable et reproductible.
De manière générale, les méthodes permettent de construire des modèles à partir d'éléments de mo-
délisation qui constituent des concepts fondamentaux pour la représentation de systèmes ou de phé-
nomènes. Les notes reportées sur les partitions sont des éléments de modélisation pour la musique.
L'approche objet propose l'équivalent des notes — ce sont les objets — pour la représentation des
logiciels.
1 RAD — "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il préconisa, en
1991 (éd. MacMillan Publishing), une nouvelle stratégie pour le développement des projets informatiques :
au lieu du comportement traditionnel consistant à définir d'abord les limites de l'application à réaliser et à voir
ensuite les équipes de développeurs accumuler les retards et dépasser toutes les prévisions budgétaires ... fixer
le budget au départ et demander aux équipes de développement de réaliser "ce qu'elles peuvent" dans ce cadre,
en créant des prototypes au moyen d'outils de programmation sophistiqués 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 "révolutionnaire" pour ne retenir que la suggestion de choisir des outils performants.
2 Les outils de développement 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 pièges.
3 P.A. MULLER : op. cit.

Les méthodes définissent également une représentation, souvent graphique, qui permet d'une part de
manipuler aisément les modèles, et d'autre part de communiquer et d'échanger l'information entre
les différents intervenants. Une bonne représentation recherche l'équilibre entre la densité d'infor-
mation et la lisibilité.
En plus des éléments de modélisation et de leurs représentations graphiques, une méthode définit
des règles de mise en œuvre qui décrivent l'articulation des différents points de vue, l'enchaînement
des actions, l'ordonnancement des tâches et la répartition des responsabilités. Ces règles définissent
un processus qui assure l'harmonie au sein d'un ensemble d'éléments coopératifs et qui explique
comment il convient de se servir de la méthode. 1
Une méthodologie d'analyse propose au concepteur des modèles, des méthodes et des outils.
• Un modèle, au sens d'une théorie de la modélisation, est un ensemble de concepts et de lois (de
complétude, de cohérence, de transformation ...) unissant ces concepts. Concepts et lois qui per-
mettent de décrire "intelligemment" une réalité. A titre subsidiaire, un modèle comporte des forma-
lismes, qu'il ne faut pas croire limités aux seuls schémas graphiques ou diagrammes dont, à l'instar de
tout concepteur, les informaticiens sont friands.
• Une méthode propose des démarches et des règles de bon usage. Idéalement, elle se fonde sur
des modèles éprouvés et vise à en exploiter les potentialités en vue de fabriquer des objets répondant
à certains critères de qualité (comme, par exemple, les options stratégiques listées dans le texte cité
plus haut).
• Depuis la fin de la décennie 1980-90 sont apparus sur le marché des outils logiciels d'aide à l'ana-
lyse. Ces outils ont reçu le nom de "CASE tools" ("Computer Aided Software Engineering") ou, en
français, d'ateliers de génie logiciel. Gradation des tâches effectuées par ces outils :
– support (enregistrement et restitution) des formalismes, particulièrement des dessins;

– application (vérification) des règles de syntaxe, de cohérence, de complétude ...;
– exploitation des lois de transformation spécifiques des modèles,
se basant sur les propriétés des objets déjà définis pour définir de nouveaux objets ...
3.2. Utilité d'une méthode
[Une] méthode est nécessaire :
– pour maîtriser la complexité du problème informationnel à résoudre;

– pour sortir la construction des systèmes d'information de l'empirisme individuel et la fonder sur
une coopération efficace entre informaticiens et gestionnaires;
– pour permettre la communication entre individus de l'équipe de conception;
– pour construire des systèmes pertinents, fiables, flexibles et adaptatifs;
– pour permettre d'évaluer le système à 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 améliorer les coûts, les délais et la productivité des activités de développement. 2

2 C. ROLLAND : Introduction à la conception des systèmes d'information et panorama des méthodes dispo-
nibles; in Génie Logiciel, n° 4.

Watts S. Humphrey a proposé cinq niveaux de maturité des processus de développement de logiciel :
– initial : le développement n'est pas formalisé, l'équipe réagit au jour le jour et choisit des solu-
tions au cas par cas, de sorte que le succès dépend fortement des personnes impliquées dans le pro-
jet;
– reproductible : l'organisation est capable d'établir des plans raisonnables en termes de budget et
de vérifier l'état d'avancement du projet par rapport à ces plans;
– défini : le processus de développement est bien défini, connu et compris par tous les intervenants
du projet;
– encadré : les performances du processus de développement sont mesurables objectivement;
– optimisant : les données de contrôle des performances du processus permettent l'amélioration du
processus.
[...]
Le diagramme suivant représente les cinq niveaux de maturité des processus. 1
optimisant
➚
encadré
➚
défini
➚
reproductible
➚
initial
Les équipes de développement ont besoin d’une méthode de travail contrôlée, d’un processus inté-
grant les diverses facettes du développement et d’une approche commune, c’est-à-dire d’un pocessus
capable :
– de dicter l’organisation des activités de l’équipe;

– de diriger les tâches de chaque individu et de l’ensemble de l’équipe;
– de spécifier les artefacts à produire;
– de proposer des critères pour le contrôle et l’évaluation des produits et des activités du projet. 2
3.3. Schémas et Maquettes
"Un modèle est une description abstraite d'un système ou d'un processus, une représentation simplifiée qui
permet de comprendre et de simuler."3 Un schéma, dressé dans les formes fixées par un paradigme théorique,
constitue une sorte de "discours" sur le domaine décrit, dont l'ambition est double :
– discours expliquant que le domaine étudié est intelligible, un schéma sert à faire partager à d'au-
tres (et à l'ordinateur ?) la connaissance relative à ce domaine;
– image simulant la réalité à venir, un schéma permet également de vérifier, à l'avance, la pertinence
de cette réalité future.

2 I. JACOBSON, G. BOOCH, J. RUMBAUGH : Le processus unifié de développement logiciel, trad. fran-
çaise; Eyrolles, 2000.

Les informaticiens recourent de plus en plus souvent à la réalisation (au moyen d'outils RAD de développe-
ment rapide) de maquettes, "modèles réduits" utilisés pour vérifier expérimentalement l'adéquation de leurs
hypothèses de travail.
Avant la construction proprement dite, les concepteurs élaborent de nombreux types de modèles
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 définitif, des
plans techniques, des scénarimages publicitaires, des maquettes de livres, etc. Les modèles visent
différents objectifs :
– tester une entité physique avant de la construire. Les maçons du Moyen Age ne connaissaient
pas la physique moderne, mais ils construisaient des modèles à l'échelle des cathédrales gothiques
afin de tester les forces intervenant dans la structure. Les modèles réduits d'avions, de voitures ou
de bateaux sont testés en soufflerie ou en bassin pour améliorer l'aérodynamique ou l'hydrodynami-
que. Des progrès récents dans les méthodes de calcul permettent la simulation de beaucoup de
structures physiques sans avoir à les construire. La simulation n'est pas seulement moins chère, elle
permet aussi de fournir de l'information qui, sur les modèles physiques, est soit trop insaisissable,
soit difficile à mesurer. La construction de modèles physiques ou informatiques revient générale-
ment moins cher que la construction du système complet et permet de corriger plus tôt les déficien-
ces.
– communiquer avec le client. Les architectes et les concepteurs de produits construisent des mo-
dèles de démonstration. Les maquettes sont des modèles imitant tout ou partie du comportement
extérieur du système.
– visualiser. Les "scénarimages" de films, téléfilms et publicités permettent aux scénaristes de voir
l'articulation de leurs idées. Les transitions brutales, les dénouements qui n'en finissent pas, et les
passages inutiles peuvent être modifiés avant l'écriture du script final. Les croquis permettent aux
artistes de jeter leurs idées et de les modifier avant de passer à l'huile ou à la pierre.
– réduire la complexité. La principale raison, sans doute, de la modélisation, et qui englobe toutes
les autres, est la possibilité qu'elle donne d'appréhender des systèmes qui seraient trop complexes à
comprendre directement. Le cerveau humain ne peut travailler qu'avec une somme limitée d'infor-
mations à la fois. Les modèles réduisent la complexité dans la mesure où ils isolent un petit nombre
de choses importantes à examiner à la fois. 1
Le domaine privilégié de la réalisation 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 développement de l'application, principalement sur les données
et les traitements. Une application jugée convenable était avant tout une application sans anoma-
lies, livrée à temps et qui comportait à peu près les fonctionnalités décrites dans le cahier des char-
ges. L'aspect interface était très limité : seuls étaient présentés, sur papier, et dans le meilleur des
cas, quelques écrans ou états [imprimés] de la future application. Les outils utilisés ne permet-
taient pas de créer rapidement une maquette complète de l'application.

En raison du peu de moyens disponibles, la différence entre un design soigné et un médiocre était
quasiment inexistante. Les erreurs de présentation étaient certainement moins nombreuses et moins
pénalisantes. Aujourd'hui, le développement d'une application en mode graphique passe nécessai-
rement par la fabrication d'une interface de qualité. La création systématique 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 présentation peu soignée, une
conception inadéquate, et c'est l'échec. Il convient donc de se pencher avec attention sur le pro-
blème posé par la relation avec l'utilisateur au travers de l'interface.
[...]
L'interface graphique, avec ses fenêtres multiples, ses objets hauts en relief et en couleur — icônes,
images, barres d'outils, ascenseurs ... — offre des possibilités immenses pour les développeurs 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 frôle constamment "l'explosion combinatoire" ! 1
3.4. Modélisation et Programmation
La plupart des paradigmes d'analyse — "Structured Analysis", modèle en réseau, modèle relationnel, con-
ception orientée objet, etc. — sont des modèles initialement mis au point pour la programmation, dont on a
par la suite élargi le champ d'application, de façon telle que leurs concepts puissent décrire d'autres réalités
que des composants de programmes. Après avoir outillé l'étape finale de réalisation des systèmes d'informa-
tion, les méthodologues élargissent leur vision pour remonter vers la source : ils s'intéressent à l'étape de
conception, puis à l'étape d'analyse.
On peut donc affirmer qu'un programme est lui-même un schéma ou/et une maquette, puisqu'il se fonde sur
des concepts de modélisation.
Soulignons alors le paradoxe de la programmation traditionnelle : elle modélise l'ordinateur plus que l'appli-
cation ! En effet, elle se réfère explicitement à la structure matérielle de l'ordinateur; le programmeur décrit
la mémoire 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 opérations de base de ce processeur :
l'enchaînement séquentiel, les tests de conditions, l'appel de procédure et, surtout, l'opération fondamentale de
l'ordinateur : l'affectation d'un contenu à une variable. Pour certains, ce paradoxe explique la difficulté de la
programmation, son coût exorbitant ... et la lancinante recherche de nouvelles manières d'aborder — c'est-à-
dire de penser et de modéliser — la programmation et, par extension, l'analyse.
3.5. L'équipe de développement
Pour terminer, évoquons les rôles qui doivent être remplis au sein d'une équipe attelée à la réalisation d'un
projet informatique, et qu'une démarche méthodique doit coordonner.
Il existe quelques rares informaticiens virtuoses, mais quelles que soient les qualités des individus, il
arrive un moment où l'ampleur de la tâche à 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 capacités moyennes de chacun.
1 J.M. GILLET : L'interface graphique; InterEditions, 1995.

Le choix des personnes qui constituent une équipe de développement détermine fortement le dérou-
lement du projet. Au-delà des aspects techniques, le succès d'un projet dépend en grande partie des
facteurs humains. Un bon processus de développement permet précisément de retirer la quintes-
sence d'une équipe de développement, de manière reproductible et contrôlée. Les membres d'une
équipe efficace doivent d'une part être complémentaires, et d'autre part être bien conscients de leur
rôle dans le processus de développement. 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 développement.
De manière générale, un processus de développement de logiciel peut se décomposer en trois sous-

processus :
– le développement informatique proprement dit,

– la logistique qui pourvoit aux besoins du développement informatique,
– l'interface avec le reste du monde, qui isole le développement des perturbations externes.
[...]
Le développement informatique
Le développement informatique est conduit par les trois acteurs suivants :
– l'architecte définit la forme générale du logiciel [...];

– les abstractionnistes (de l'anglais abstractionist) identifient les objets et les mécanismes qui
permettront de satisfaire les besoins de l'utilisateur;
– les développeurs maîtrisent les technologies et réalisent les abstractions identifiées par les abs-
tractionnistes.
La logistique
La logistique interagit avec les acteurs suivants :
– le chef de projet compose l'équipe, gère le budget et les personnes, et coordonne les diverses acti-
vités;
– l'analyste est un expert du domaine, chargé de comprendre les besoins des utilisateurs;
– l'intégrateur assemble les éléments produits par les développeurs [...];
– le qualiticien évalue tous les éléments produits par le développement et dirige les tests du sys-
tème;
– le documentaliste rédige la documentation à destination de l'utilisateur;
– l'administrateur–système gère et entretient le parc matériel utilisé par le projet;
– l'outilleur construit et adapte les outils logiciels qui forment l'environnement de développement;
– le bibliothécaire assure l'archivage et la préservation de tous les artefacts du développement et de
leurs règles de production.
L'interface
L'interface interagit avec les acteurs suivants :
– le chef de projet assure l'interface entre l'équipe de développement et le reste du monde;

– le chef de produit supervise une ligne de produits; il coordonne les activités de marketing, de
formation et de support technique;
– le financier contrôle l'allocation du budget et sa bonne utilisation;
– l'utilisateur/client participe à des revues de prototypes;
– le support technique résout ou contourne les problèmes rencontrés par les utilisateurs.

Les rôles décrits précédemment peuvent être joués par la même personne. Dans les petites organi-
sations, il est fréquent que le chef de projet remplisse également les rôles d'architecte et d'analyste.
De même, les développeurs et les abstractionnistes sont souvent confondus. 1
4. Contenu du cours : Modélisation des applications informatiques
L'objet de ce cours est la modélisation des applications informatiques. En principe, nous restreindrons no-
tre propos à la partie automatisée des systèmes 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 à décrire différents modèles d'analyse, en nous attardant
particulièrement aux règles et critères de manipulation de ces modèles. Dans ce premier cours, nous ne traite-
rons pas explicitement de l'intégration de ces modèles à une démarche globale d'analyse et de conception — ce
sera l'objet d'un second cours.
Une théorie n'est évidemment pas n'importe quel texte grammaticalement correct utilisant un ensem-
ble de termes symboliquement reliés à la réalité. C'est un agrégat systématique d'énoncés de lois.
Son contenu, sa valeur même en tant que théorie, repose au moins autant sur la structure des inter-
connexions liant les lois que dans les lois elles-mêmes. (Il arrive que des étudiants préparant leurs
examens de physique en apprennent par cœur des listes d'équations. Ils peuvent parfaitement réussir
leurs examens avec de tels exploits de mémoire, sans que l'on puisse pour autant dire qu'ils com-
prennent la physique, autrement dit qu'ils en maîtrisent les théories.) Une théorie, du moins une
théorie valable, n'est donc pas simplement une sorte de banque de données dans laquelle on peut
"rechercher" ce qui se passerait dans telles et telles conditions. C'est plutôt 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 découvertes. Les théories sont donc remarquables [non pas] en ce qu'elles
donnent des réponses à 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 aérienne
d'un territoire sert une fonction heuristique différente de celle de la carte démographique de ce
même territoire. Un usage de la théorie est donc de préparer les catégories conceptuelles dans les-
quelles les théoriciens et les praticiens poseront leurs questions et concevront leurs expérimenta-
tions. 2
Aux étudiants qui craindraient — et tout autant à ceux qui espéreraient — que ce cours leur propose un outil-
lage rendant inutiles les efforts de créativité, nous livrons cette dernière citation.
Une méthode d'analyse doit être un facteur de créativité pour les analystes et pas le contraire, elle
représente 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 méthodes formulaires qui affectionnent le style "Petit catéchisme" ou le style "pro-
cédure militaire", ainsi que semblent le souhaiter des "responsables méthodes" dans certaines orga-
nisations. 3
1 P.A. MULLER : op. cit

2 J. WEIZENBAUM : Puissance de l'ordinateur et raison de l'homme, trad. française; éd. d'Informatique,
1981.
3 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information; Masson, 1989.

Nous nous trouvons aujourd'hui (1995–2000) à une époque d'émergence de nouvelles méthodologies, néces-
sitées et entraînées par le succès de la programmation par objets. La culture des informaticiens reste néan-
moins imprégnée des méthodologies précédentes, même s'ils reconnaissent volontiers que leurs modèles, outils
et démarches ne suffisent plus. Les méthodes "orientées objets" elles-mêmes n'ont pas soudain fleuri au milieu
d'un désert culturel; en particulier, leurs modèles reprennent à leur compte nombre d'acquis des théories anté-
rieures.
Ce cours s’enracine donc dans l’étude des "classiques" que nous ont laissés les méthodes anciennes et dont on
retrouve des traces — plus que des traces — dans les méthodes nouvelles. Ils sont constitués de quelques
modèles (les démarches s'avèrent assurément plus éphémères) : modèles de données et modèles des systè-
mes de traitement de l'information. Imitant la programmation de son époque, cette analyse traditionnelle sé-
pare nettement la description des données et celle des opérations. (Une manière plus moderne de présenter
cette dichotomie consiste à distinguer l’analyse d’un domaine d’application et la spécification des applica-
tions qui seront réalisées dans ce domaine.1)
Mais on y intègre l'apport du paradigme Objet à l'analyse.2 En effet, ainsi que nous aurons l’occasion de le
montrer, le concept d’Objet ne contredit pas les notions anciennes; il les unifie.
Pour l’analyse "orientée objets", nous utiliserons un sous-ensemble d’UML (Unified Modeling Lan-
guage), "langage de modélisation unifié" mis au point par la société américaine Rational Software.
UML a été adopté comme standard par l’OMG (Object Management Group) en 1997 et, de ce fait,
s’impose de plus en plus rapidement à toutes les équipes adeptes des méthodes "Objet".
Pourtant, UML n’est pas exempt de défauts, dont le principal est sans doute de vouloir en faire trop
(ce langage a pour ambition de pouvoir formaliser tout ce que souhaiterait exprimer n’importe quel
analyste !) et le second, de manquer quelquefois de précision. C’est pour ces motifs que nous n’en
exposerons qu’un sous-ensemble. Nous nous baserons principalement sur les ouvrages suivants :
P.A. MULLER : Modélisation objet avec UML; Eyrolles, 1997.

OMG : Unified Modeling Language Specification, vers. 1.4; www.omg.org, 2002.
Le second de ces ouvrages constitue la définition officielle d’UML.
1 Voir notamment P.A. MULLER : op. cit. et I. JACOBSON, al.: op. cit.
2 On suppose l'étudiant initié à la programmation par objets.

Chapitre 2. Introduction à la modélisation des données
L'essor des modèles de données est intimement lié à celui des bases de données.
La première section de ce chapitre montre quels besoins de modélisation sont nés de l'avènement des systèmes
de gestion de bases de données (SGBD).
La deuxième section définit quelques concepts fondamentaux, communs à tous les systèmes de modélisation
des données.
La troisième section dresse un panorama historique des principaux modèles de données et de leur utilisation
par les SGBD et les méthodes d'analyse.
© A. CLARINVAL Analyse — Modélisation des données 2-1

1. Bases de données et Modélisation
1.1. Le concept de Système de Gestion de Bases de Données (SGBD)
Le concept de base de données (en anglais : data base) est apparu au milieu des années 60, comme palliatif
aux inconvénients des fichiers spécialisés que l'on définissait pour couvrir les besoins particuliers de chaque
programme.
Dans ces accumulations de fichiers dispersés, il était fréquent que les mêmes informations fussent reproduites
à plusieurs endroits et de diverses manières : différents fichiers décrivant les clients ou les produits, par
exemple. Défauts de ces systèmes : la redondance (répétition des mêmes informations), l'incohérence des
mises à jour (les fichiers redondants n'étant mis à jour ni en même temps ni par les mêmes responsables), le
partage limité des informations (les divers utilisateurs potentiels ne retrouvant pas leur "point de vue" dans la
manière dont les autres représentaient les informations) ...
L'idée première fut celle d'un stockage intégré, en une seule collection cohérente, des données d'une applica-
tion, voire d'une entreprise. L'expression base de données 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'intégration entraînait de nombreuses conséquences : la nécessité de supprimer la redondance ou

du moins de la réduire au minimum, la nécessité de structurer avec rigueur, c'est-à-dire de modéliser, la néces-
sité de stocker en dehors de chaque programme utilisateur une définition commune des données, la nécessité
de langages de manipulation de données adaptés, la nécessité de permettre un accès simultané à plusieurs
utilisateurs ou programmes, la nécessité de mécanismes garantissant la confidentialité des informations ...
Une base de données suppose donc un ensemble de logiciels aptes à assurer ces multiples fonctions, qui com-
posent ce qu'on appelle un système de gestion de bases de données, en abrégé : SGBD (en anglais : Data
Base Management System ou DBMS).
1.2. Niveaux de modélisation
a) Vues externes
Chaque utilisateur d'une base de données a de celle-ci une connaissance partielle et s'en fait une "représenta-
tion" personnelle, en a une "vue" particulière. On appelle vues externes ces représentations propres aux diffé-
rents utilisateurs de la base de données.
Exemple.
Une entreprise commerciale possède une base de données couvrant tous les besoins en information
des départements impliqués dans son activité de vente. Les vendeurs se font l'idée 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 même que celle utilisée par les vendeurs), stock actuel, stock plancher (minimum),
stock plafond (maximum), identité du fournisseur, délai de réapprovisionnement ...

b) Vue conceptuelle
En vertu du principe de stockage intégré des données, il est nécessaire de concilier les différentes vues exter-
nes en une seule vue conceptuelle.
Exemple.
Pour l'entreprise, la définition commune du concept de produit est la suivante : identification du pro-
duit (numéro et dénomination), prix de vente unitaire, taux de TVA (en % du prix de vente), nu-
méro de fournisseur, délai de réapprovisionnement (en jours), stock actuel ("quantité en stock" dans
la terminologie des vendeurs), stock plancher, stock plafond.
c) Vue interne
Jusqu'ici, on n'a considéré que des notions, des concepts. Pour pouvoir réaliser une base de données effective,
on doit encore s'en donner une vue interne qui intègre à la définition conceptuelle les aspects techniques du
stockage des données.
Exemple.
Pour faciliter la recherche des produits, on créera un index sur les numéros de produits et un autre in-
dex sur les dénominations. En vue de pouvoir lister rapidement les produits livrés par un fournisseur
quelconque, on créera peut-être un index sur le numéro de fournisseur. On choisira de stocker les in-
formations relatives aux produits sur un seul ordinateur ou de les répartir sur plusieurs ordinateurs ...
vue externe
vue externe
vue externe
vue externe
vue conceptuelle
vue interne
Ce modèle de démarche, à trois niveaux de représentation, est connu sous le nom de modèle 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 données — Schémas
Un SGBD doit fournir un langage de description de données (DDL Data Definition Language) permettant
de cataloguer la définition de chacune de ces vues sous une forme exploitable par les ordinateurs.
On donne le nom de schéma à la définition "programmée" d'une vue : schéma conceptuel, schéma interne ou
physique, (sous-)schémas externes. Le schéma interne aussi bien que les sous-schémas externes opérationnels
sont des variations dérivées du schéma conceptuel; celui-ci joue le rôle de référence commune.

2. Fondements des techniques de modélisation des données
2.1. Les mécanismes d'abstraction
L'abstraction est l'examen sélectif de certains aspects d'un problème. L'objectif de l'abstraction est
d'isoler les aspects importants et de supprimer ceux qui ne le sont pas. L'abstraction se réfère tou-
jours à un but précis, car c'est le but qui permet de déterminer 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
même réalité.
Toute abstraction est incomplète et imprécise. La réalité 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 forcément des abstractions, descriptions incomplètes du monde réel. 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 modèles, on ne recherche pas la vérité absolue, mais l'adéquation à un but donné. Il
n'y a pas de modèle "correct" unique d'une situation, seulement des modèles adéquats ou inadé-
quats. 1
a) Classification : Type, Classe, Occurrence, Collection
Dans un processus de modélisation, on ne s'intéresse généralement pas à chaque objet particulier de la réalité
décrite, mais on envisage des classes d'éléments. Ainsi, parlant de "CLIENT", on désignera par exemple
"toute personne physique ou morale ayant passé à notre firme au moins un ordre de commande qui a permis de
l'identifier". On définit de cette manière le type commun de tous les éléments de la classe.
Dans la littérature informatique, par un abus de langage qui complique quelquefois la compréhension des cho-
ses, les deux termes classe et type sont employés l'un pour l'autre : une classe nommée ("CLIENT") et défi-
nie ("toute personne ayant ...") est également appelée un type. Plus précisément, une classe est l'ensemble
concret de tous les éléments qui vérifient la définition d'un type, ensemble abstrait d'éléments "imaginables".
Le type est une création pure de l'esprit, qui n'existe que par sa définition.
Tout élément 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, féminin
COMMANDE la-commande-reçue-aujourd'hui-du-client-X
FICHIER DE COMMANDES fichier-des-commandes-reçues-ce-jour
Le type "FICHIER DE COMMANDES" est un type dont chaque occurrence (par exemple, le "fichier-des-
commandes-reçues-ce-jour") constitue un sous-ensemble de la classe "COMMANDE", ce que nous appelle-
rons une collection. Cet exemple illustre la manière de modéliser un ensemble : l'ensemble et l'élément font
tous deux l'objet d'une définition de type, chaque occurrence d'ensemble (ou collection) est un sous-ensemble
du type de l'élément. Quant au type d'une collection, c'est un ensemble puissance.

occurrence
collection
classe
type
La définition d'un type est une définition d'ensemble, le plus souvent en compréhension ("toute personne
ayant ..."), d'autres fois en extension ("masculin, féminin").
Remarque. Le contexte du discours dispense souvent de préciser 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 présence 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 définition 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 féminin" ou plutôt "masculin, féminin
et inconnu" ? ...)
b) Spécialisation, Généralisation
La spécialisation distingue des sous-classes à l'intérieur d'une classe, des sous-types à l'intérieur d'un type
(ex.: la spécialisation de NOMBRE en ENTIER, REEL, etc.; la spécialisation du PERSONNEL en
OUVRIER et EMPLOYE; la spécialisation des CLIENTS en clients PRIVES et PROFESSIONNELS).
Toute occurrence d'une sous-classe "hérite" des propriétés définies dans le sur-type (un OUVRIER possède
toutes les propriétés d'un membre du PERSONNEL ... plus certaines propriétés spécifiques; un CLIENT-
PROFESSIONNEL possède toutes les propriétés d'un CLIENT, plus un numéro de TVA). Remarquons que
toute définition en compréhension ("CLIENT = [1] toute personne [2] ayant ...") relève de la spécialisation.
PERSONNEL CLIENT
nom
OUVRIERS EMPLOYES adresse
Pierre Jacques
Paul André hérite hérite
PRIVE PROFESS.
n°TVA
La généralisation est une abstraction globalisant (mettant "en évidence") dans un sur-type les propriétés
communes de différents types (ex.: l'abstraction MOUVEMENT DE STOCK créée sur la base des types
ENTREE EN STOCK et SORTIE DE STOCK, pour laquelle il faut créer artificiellement la propriété SIGNE-
DU-MOUVEMENT).

Grâce à la non duplication des propriétés "mises en évidence" au niveau du sur-type et dont "héritent" auto-
matiquement les sous-types, spécialisation et généralisation sont des procédés économiques précieux, permet-
tant de construire des modèles plus compacts.
2.2. Mécanisme de désignation des occurrences
a) La relation de dépendance fonctionnelle
On dit qu'un type d'objet B dépend 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 déterminé par
le déterminant 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 définition s'étend facilement au cas des déterminants ou déterminés constitués de groupements d'objets.
Exemples : n° national → (nom, date de naissance, sexe)

(barème, ancienneté) → salaire mensuel
La relation de dépendance fonctionnelle est asymétrique. Il n'est pas vrai qu'un client puisse transmettre une
commande au plus; s'il est vrai qu'à une personne correspond un seul numéro national, cette relation n'est plus
vraie si — pour rester pratique — on la reformule par rapport aux noms (et prénoms) de personnes ...
b) Le concept d'identifiant
La relation de dépendance fonctionnelle fonde le mécanisme qui permet de distinguer sans ambiguïté les oc-
currences : le déterminant d'une dépendance fonctionnelle (ex.: n° national, n° de TVA, le couple barème +
ancienneté) sera choisi pour "désigner" 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 schéma de données sans prendre en compte les propriétés tempo-
relles de l'information, les modèles courants ne fournissent pas de concept particulier pour décrire cet aspect
des choses ... devant lequel l'analyste se sent donc plus d'une fois mal à l'aise.
Les paragraphes suivants introduisent le problème, en distinguant des dimensions temporelles multiples.
a) Durée de vie
Les objets par rapport auxquels on enregistre de l'information ont une durée de vie déterminée.
On a défini 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) Période de validité
L'information relative à un objet possède une période de validité. (N.B. Une durée est une "longueur" de
temps; une période est une durée "localisée" dans le cours du temps.)
Une période de validité est un intervalle compris entre deux dates de début (incluse) et de fin (exclue) : [dé-
but, fin[.1 (Selon la vitesse d'évolution du système décrit, il peut être nécessaire de mentionner l'heure.) Les
positions de cette période par rapport à la date du jour définissent différents états de l'information :
– aujourd'hui < date de début < date de fin : information détenue mais non encore valide,
– date de début ≤ aujourd'hui < date de fin : information actuellement active,
– date de début < date de fin ≤ aujourd'hui : information passée (historique).
Dans les deux premières situations, la date de fin de validité est le plus souvent inconnue.
L'identification complète d'une occurrence d'information, par exemple telle qu’elle 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 numéro 000-00000002-02"),
– l'indication d'une période de validité (ex.: "au 01/09/2000").
Cependant, la dernière de ces indications (la date) est souvent omise, ce qui est possible lorsque, dans la col-
lection visée, on ne distingue pas différentes périodes de validité (on tient pour actuelles toutes les informa-
tions détenues).
c) Période de mémorisation, Durée de rétention
Quelle que soit la période de validité d'une information, celle-ci est connue et "enregistrée" à un certain mo-
ment, et conservée en mémoire un certain temps. On parle à ce propos de période de mémorisation et de
durée de rétention.
Une information peut être enregistrée avant de devenir valide; elle peut être ignorée, c'est-à-dire non enregis-
trée, aux premiers temps de sa période de validité; dans de très nombreux cas, elle est conservée en mémoire,
dans des fichiers historiques ou d'archives, bien au delà de sa période de validité ...
2.4. Contraintes d'intégrité
Les contraintes d'intégrité sont des prédicats ou assertions intégrées au schéma de la base de données, que
celle-ci doit vérifier pour être considérée valide — on dit cohérente. Les contraintes d'intégrité sont formu-
lées par rapport à l'existence des (occurrences d') objets ou aux valeurs des données.
Exemples.
le nom de jeune fille n'existe que pour les femmes mariées (existence)
mais on accepte qu'il soit inconnu (valeurs)
la date de mariage d'une personne est postérieure à sa date de naissance (valeurs)
1 Définie de cette manière, la date de fin est en réalité la date de début de la période suivante.

toute commande concerne au moins un produit (existence)
toute ligne de commande indique une quantité commandée > 0 (valeurs)
le montant facturé est égal au prix unitaire multiplié par la quantité livrée (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 vérifie lui-même le respect des contraintes formulées dans le schéma de la base de données.
2.5. Aspects dynamiques des données
L'information possède un aspect dynamique : elle évolue en passant par différents états. Ainsi, une
FACTURE est successivement "émise", "rappelée", "payée" ou "annulée". La transition d'un état à un autre
résulte d'une certaine action.
Ignorant tout des opérations et actions du système de traitement de l'information, les modèles de données tra-
ditionnels donnent de celles-ci une vue exclusivement statique. Pour obtenir une vision dynamique, il est né-
cessaire de passer du concept de donnée à celui d'objet, avec le sens qu'accordent à ce terme les méthodolo-
gies "orientées objets" : un objet est caractérisé à la fois par des attributs, données qui décrivent son état, et
par des opérations portant sur cet état.
Exemple. Un objet solde est caractérisé par le nombre indiquant sa valeur actuelle et la date de sa
dernière mise à jour, ainsi que par les opérations de mise à jour et de consultation de cet état. Trois
classes d'états remarquables sont intéressantes à distinguer : solde positif, nul ou négatif.

3. Panorama historique
3.1. Les SGBD opérationnels
Nous avons défini un modèle comme étant la théorie et le formalisme employés pour créer un schéma de don-
nées. Les SGBD se différencient principalement par le modèle théorique sur lequel ils s'appuient.
On le notera rien qu'à leurs noms : tous les modèles s'intéressent principalement aux relations exis-
tant entre les données ... mais, comme diraient les musiciens, chacun joue sur ce thème sa propre va-
riation.
Les SGBD relationnels, mis au point dans les années 80, sont les plus utilisés aujourd'hui. Ils s'appuient sur
le modèle relationnel des données défini par E. CODD chez IBM en 1970.1
La génération précédente fut celle des bases de données en réseau, apparues à la fin des années 60. Le mo-
dèle en réseau avait été créé par Ch. BACHMAN chez General Electric en 1963;2 il a été standardisé par
CODASYL à partir de 1971.3 Ces systèmes sont encore utilisés sur certains gros ordinateurs, mais on les a
souvent recouverts d'une "couche" de fonctions d'accès relationnelles.
Cas particulier : le système IMS (Information Management System) d'IBM, créé en 1968, repose
sur un modèle hiérarchique, moins puissant qu'un modèle en réseau.
Depuis les années 90, commencent à apparaître des SGBD que l'on qualifie d'orientés objets. Il n'est pas en-
core possible de savoir sous quelle forme ils s'imposeront.
3.2. Les méthodes d'analyse
a) Modèles d'analyse des données
D'autres modèles de données, qualifiés de sémantiques, sur lesquels ne s'appuie directement aucun SGBD,
sont couramment utilisés dans les démarches préalables d'analyse d'une base de données.
Le modèle entité–association a été défini aux alentours de 1975 par l'Américain P. CHEN.4 Une variante de
ce modèle a été adoptée en France par la méthode d'analyse MERISE.5 Parce que le gouvernement français
obligeait les informaticiens de ses administrations à pratiquer la méthode MERISE, le modèle entité–associa-
tion est le plus utilisé dans les régions francophones.
Les anglo-saxons utilisent plutôt une variante du modèle en réseau de BACHMAN, mise au point par
J. MARTIN dans sa méthode 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 créateur 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 méthode MERISE, éd. d'Organisation, Paris 1983.
6 J. MARTIN : Diagramming Techniques for Analysts and Programmers, Prentice Hall.

Le modèle des réseaux sémantiques proposé par SMITH et SMITH en 1977 constitue un des fondements
théoriques des modèles orientés objets.1 Ses apports ont été intégrés à une deuxième génération du modèle
relationnel et à une deuxième génération des modèles entité–association.
A la suite de la programmation, les méthodes d'analyse se veulent aujourd'hui "orientées objets". En 1997,
l’Object Management Group (OMG) a adopté comme standard l’Unified Modeling Language (UML).2 Le
schéma central produit par une analyse axée sur les objets est le diagramme des classes d'objets; il s'agit ni
plus ni moins que d'un schéma de données, muni d'opérations. Le formalisme proposé par UML est celui d'un
schéma Entité–Association.3
b) Outils d'aide à la conception
Depuis la fin des années 80 se sont répandus 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 données que dans l'analyse
des opérations. S'appuyant sur l'un ou l'autre modèles de données, ces outils gèrent la documentation écrite et
graphique des schémas et effectuent des vérifications de complétude et de cohérence.
Ils opèrent aussi des transformations de schémas aboutissant à la définition "programmée" d'une base de don-
nées. En effet, les schémas produits à partir des modèles d'analyse doivent subir des transformations pour être
convertis dans le formalisme du modèle adopté par le SGBD.
c) Plan du cours
Les trois chapitres suivants, en se servant des modèles les plus couramment employés dans les régions franco-
phones, présentent les transformations successives d'un schéma de base de données.
Le chapitre 3 traite de l'élaboration du schéma conceptuel, dans les formes du modèle Entité–Association
enrichi des apports du paradigme objet.
Le chapitre 4 décrit la confection du schéma logique de la base de données, transposition du précédent dans
les formes du modèle en Réseau.
Le chapitre 5 décrit le schéma physique de la base de données dérivé du schéma logique. Deux standards y
sont présentés : le système CODASYL et le système 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 société américaine Rational Software, fruit de la rencontre de trois pionniers
des méthodes d’analyse et conception "orientées objets" : les Américains G. BOOCH et J. RUMBAUGH et le
Suédois I. JACOBSON. Cf. OMG : Unified Modeling Language Specification, vers 1.3.; www.omg.org,
1999. Voir aussi P.A. MULLER : Modélisation objet avec UML; Eyrolles, 1997.
3 UML a repris ce formalisme à la méthode OMT (Object Modeling Technique) de J. RUMBAUGH. Cf. J.
RUMBAUGH, al. : Modélisation et conception orientées objet, trad. française; Masson, 1995.

Chapitre 3. Le schéma conceptuel des données
Le premier résultat important produit par l'analyse préparatoire à la réalisation d'une base de données est le
schéma conceptuel de cette base de données. A cette étape, l'analyste ne s'intéresse qu'à la sémantique des
données, c'est-à-dire à leur contenu informationnel.
En élaborant ce schéma, l'analyste décrit un domaine d'application.1 La démarche suppose la coopération des
utilisateurs commanditaires du projet d'informatisation. Ces utilisateurs apportent à l'œuvre commune leur
connaissance du domaine; l'informaticien, spécialiste de la modélisation, apporte la structure. Le résultat,
c'est-à-dire le schéma, doit entre autres choses démontrer que les deux parties se sont comprises.
La démarche préconisée est la suivante :
1) élaboration de sous-schémas bruts (sur la base d'interviews, d'examen de documents, etc.),

2) consolidation en un schéma global brut,
3) validation du schéma global,
4) correction des sous-schémas en fonction du schéma global validé.
Nous commencerons par décrire le contenu du schéma conceptuel de la base de données. Ce contenu com-
porte deux volets : d'abord, une description structurée de l'ensemble des données détenues; ensuite, une liste
de contraintes de validité. Nous élaborerons la description structurée en utilisant un modèle aujourd'hui clas-
sique, le modèle Entité–Association, enrichi des apports pertinents du paradigme Objet. Quant aux règles de
validité, nous les énoncerons au moyen d'un langage expérimental.
La fin du chapitre est consacrée à la validation des descriptions fournies.
1 "Décrire le domaine (l'environnement) dans lequel l'application va exister et préciser quels sont les élé-
ments pertinents dans ce domaine pour l'application. L'étude du domaine est le fruit d'une analyse, totale-
ment déconnectée de toute considération de réalisation. Le domaine est analysé par un analyste et doit pou-
voir être compris par un utilisateur." (P.A. MULLER : Modélisation objet avec UML; Eyrolles, 1997.)
© A. CLARINVAL Analyse — Schéma conceptuel 3-1

1. Le modèle Entité–Association
Le modèle Entité–Association exprime la sémantique des données à l'aide des concepts d'entité, d'association
entre entités, d'attribut décrivant les entités et les associations.1
Défini aux alentours de l'année 1975 par les travaux de CHEN aux Etats-Unis, de l'équipe de TARDIEU ayant
créé en France la méthode MERISE, de l'équipe de BODART ayant créé aux Facultés de Namur l'atelier logi-
ciel IDA, le modèle Entité–Association est aujourd'hui le plus communément utilisé dans les régions franco-
phones.2
Avec plus ou moins de bonheur, ce modèle a été adopté et adapté par certaines méthodes "orientées objets",
notamment UML ("Unified Modeling Language").3 Au lieu de parler de types d'entités, ces méthodes parlent
de classes d'objets. Le concept d'objet complète celui d'entité : un objet est caractérisé, non seulement par
des attributs qui en décrivent l'état, mais également par des opérations ou "méthodes" utilisées principale-
ment pour modifier ou afficher la valeur de ses attributs.
1.1. Contenu du modèle Entité–Association
a) Entité
Une entité est une chose de la réalité perçue par l'analyste, concrète ou abstraite, durable ou momentanée, à
laquelle on reconnaît une existence autonome, indépendante 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 décrit les propriétés
communes à toutes les jupes écossaises. Un poste du plan comptable est aussi une entité ...
Les entités sont classées par types d'entités ou, selon la terminologie plus en vogue aujourd'hui, par classes
d'objets
On représente habituellement par un rectangle un type d'entités ou une classe d'objets.
Exemples. VENDEUR CLIENT

PRODUIT
Les types d'entités ne forment pas nécessairement des classes disjointes; une même personne pourrait être
vendeuse et cliente de la même firme.
Le modèle Entité–Association a été étendu de manière à permettre la représentation de sous-types d'entités

ou sous-classes d'objets.
1 La méthode MERISE parle d'individu, de relation et de propriété.

2 Voir les références bibliographiques au chapitre 2. Pour l'exposé qui suit, nous nous baserons principale-
ment sur l'ouvrage de F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information : mé-
thode, modèles, outils, Masson, 1989.
3 Voir les références bibliographiques au chapitre 2.

Exemples. Une firme commerciale établit une distinction entre ses clients privés et professionnels;
elle vend des produits qu'elle fabrique elle-même et des produits d'un fournisseur dont elle est "dis-
tributrice".
VENDEUR PRODUIT CLIENT
PRODUIT PRODUIT CLIENT CLIENT

FABRIQUE DISTRIBUE PRIVE PROFESS.
Il est possible d’effectuer différentes répartitions en sous-types à l’intérieur d’un même super-type, chaque
répartition se fondant sur un critère particulier.
Exemple.
CLIENT
CLIENT CLIENT CLIENT CLIENT

NATIONAL ETRANGER PRIVE PROFESS.
Un même 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.
LIVRE CD-ROM
LIVRE MANUEL CD-ROM JEU

..... D'ART SCOLAIRE EDUCATIF VIDEO .....
MATERIEL
DIDACTIQUE

b) Association
Le concept d'Association
Une association ("relationship", en anglais) est une correspondance reconnue entre des entités, de types non
nécessairement distincts, où chacune assume un rôle particulier. Son existence est contingente à celle des
entités concernées; sa période d'existence est incluse dans l'intersection des périodes d'existence des entités
participantes et sa durée de vie peut être inférieure à la durée de vie de ces entités.
Exemples : le lien conjugal unissant Monsieur X et Madame X,

dans lequel l'un joue le rôle d'époux et l'autre, celui d'épouse
le lien parental ou de filiation existant entre deux personnes,

dans lequel l'une joue le rôle 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 matière "radiesthésie"
– par le professeur Tournesol
– à la classe de Poésie
Les associations sont classées par types d'associations, définis sur des types d'entités. D'un point de vue ma-
thématique, un type d'association est une relation.
Exemples : ASSOCIATION (ENTITE rôle, ...)
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 dispensée, PROFESSEUR titulaire, CLASSE suivant)
A la suite de la méthode MERISE, nous représenterons un type d'association par un ovale. (D'autres repré-
sentations utilisent l'hexagone ou le losange.) Les rôles sont représentés par les arcs reliant le type d'associa-
tion aux types d'entités participantes.
parent
FILIATION PERSONNE
enfant
mari épouse
HOMME CONJOINT FEMME

COMPOSITION composé FOURNISSEUR
composant PRODUIT livrant
entreposé
FOURNITURE
STOCK
livré
contenant
MAGASIN PRODUIT PRODUIT
FABRIQUE DISTRIBUE
MATIERE
dispensée
ENSEIGNEMENT
titulaire suivant
PROFESSEUR CLASSE
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 → complément.
Dans le cas des associations cycliques, c'est-à-dire définies sur un seul type d'entité (l'association FILIATION
entre PERSONNEs, l'association de COMPOSITION entre PRODUITs), les noms de rôles sont nécessaires
pour pouvoir distinguer les occurrences participantes : dans telle occurrence de l'association COMPOSITION
de PRODUITs, "vitrage" et "châssis" sont les composants du composé "fenêtre"; dans telle occurrence de
l'association FILIATION, Jésus est l'enfant et Marie est le parent.
Dans les autres cas, les noms de rôles apparaîtront souvent redondants. Cependant, nous verrons plus loin
l'intérêt qu'ils offrent pour l'expression des règles de validité. De plus, afin d'augmenter la lisibilité des ex-
pressions de la forme ENTITE–rôle qui y font référence, on choisira en guise de noms de rôles, si c'est possi-
ble, des participes présents (rôles actifs) ou passés (rôles passifs).
On appelle degré d'une association le nombre d'entités 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 entités d'un même type, est de degré au moins égal à 2.)
Plusieurs types d'associations peuvent être définis sur les mêmes types d'entités.
Exemples : COMPOSITION (EQUIPE comprenant, PERSONNE membre)

DIRECTION (EQUIPE dirigée, PERSONNE dirigeant)
PROPRIETE (PERSONNE possédant, VOITURE possédée)

PILOTAGE (PERSONNE conduisant, VOITURE conduite)

Le modèle n'autorise pas la représentation de sous-types d'associations.
Notation UML
Dans les diagrammes de classes d'UML, les associations sont simplement figurées par les traits qui relient les
symboles des classes d'objets participants; dans le cas d'une association de degré supérieur à 2, un petit lo-
sange est utilisé pour connecter les traits.
parent
FILIATION PERSONNE
enfant
mari épouse
HOMME FEMME
CONJOINT
composé
COMPOSITION
FOURNISSEUR
composant PRODUIT
livrant
entreposé
STOCK FOURNITURE
contenant
livré
MAGASIN
PRODUIT PRODUIT
FABRIQUE DISTRIBUE
MATIERE
dispensée
titulaire suivant
PROFESSEUR CLASSE
ENSEIGNEMENT
Connectivité des associations
Soit un type d'association A (Ei ri, ...).
– A chaque association du type A participe sous chacun des rôles ri une entité exactement.
– A chacun des rôles ri mis en jeu est attaché un couple d'entiers (mini, maxi), qui en définissent la
connectivité (on dit aussi : la cardinalité) et qui, dans les méthodes de tradition française, signi-
fient :
– mini le nombre minimum d'occurrences de A auxquelles,

à tout moment, participe toute occurrence de Ei;
– maxi le nombre maximum d'occurrences de A auxquelles,
à tout moment, participe toute occurrence de Ei.

Les valeurs habituelles sont :
– mini = 0 ou 1 signifiant une participation facultative ou obligatoire,

– maxi = 1 ou N ou * signifiant une participation unique ou multiple
(N ou * représente l'infini).
Exemples : CONJOINT (HOMME mari-de 0:1, FEMME épouse-de 0:1)

– il existe des célibataires !
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
0,N parent
FILIATION PERSONNE
0,2 enfant
mari épouse
HOMME CONJOINT FEMME
0,1 0,1
FACTURATION (COMMANDE facturée-en 0:1, FACTURE émise-pour 1:1)

– une commande existe un certain temps sans être liée à une facture
facturée émise
COMMANDE FACTURATION FACTURE
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 stockés
– aucun produit n'est stocké dans plusieurs magasins
COMPOSITION (PRODUIT composé-de 0:N, PRODUIT composant 0:N)
– il existe nécessairement des produits non composites
– certains produits n'entrent dans aucune composition
0,N
COMPOSITION composé FOURNISSEUR
0,N
composant PRODUIT livrant
entreposé 1,N
0,1
FOURNITURE
STOCK
1,1
0,N
contenant livré
MAGASIN
PRODUIT PRODUIT
FABRIQUE DISTRIBUE

ENSEIGNEMENT (MATIERE dispensée-dans 1:1, PROFESSEUR titulaire-de 1:N,
CLASSE suivant 1:N)
– une matière fait l'objet d'un seul enseignement
– un professeur peut être titulaire de plusieurs enseignements
– une classe suit au moins un enseignement
MATIERE
dispensée
1,1
ENSEIGNEMENT
1,N 1,N
titulaire suivant
PROFESSEUR CLASSE
Les connectivités dans la notation UML
Dans la représentation UML d'un type d'association, seuls les types des entités participantes sont montrés. La
connectivité (ou "multiplicité") mentionnée à chaque extrémité de l'arc représentant une association binaire
indique à combien d'entités de cette extrémité est associée chaque entité du type situé à l'autre extrémité, ce
qui revient à dire : à combien d'associations participe chaque entité du type situé à l'extrémité opposée.1
Voici l'équivalent UML des exemples donnés au paragraphe précédent. Comparez attentivement les deux
versions.
0..2 parent
FILIATION PERSONNE
0..* enfant
0..1 0..1
HOMME FEMME
mari CONJOINT épouse
1..1 FACTURATION 0..1

COMMANDE FACTURE
facturée émise
0..* composé
COMPOSITION
FOURNISSEUR
0..* composant PRODUIT
1..1 livrant
0..*
entreposé FOURNITURE
STOCK
1..* livré
0..1 contenant
MAGASIN PRODUIT PRODUIT
FABRIQUE DISTRIBUE
1Cette disposition, typique des méthodes américaines, provient du modèle en réseau, que nous décrirons au
chapitre suivant.

Le procédé n'est pas transposable aux types d'associations d'un degré supérieur à 2 (à moins que les connecti-
vités soient les mêmes sur tous les rôles). Les auteurs d'UML préconisent dans ce cas de représenter le type
d'association sous les traits d'un type d'entité !1
MATIERE
dispensée
1..1
<<association>>
ENSEIGNEMENT
1..* 1..*
titulaire suivant
PROFESSEUR CLASSE
Ce mode de représentation est également applicable aux associations binaires.

Remarquer que les connectivités se placent ici de la même manière
que dans la représentation française.
La mention «association» signale une variante standardisée du concept d’analyse employé,
ce que, en UML, on appelle un stéréotype.
NOTE. En UML, la connectivité 1..1 peut être laissée implicite; elle peut aussi s'écrire 1.
c) Attribut
Attribut et Domaine
Un attribut est une caractéristique 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, généralise et définit des
types d'attributs.
Exemples : type d'entité/association attribut domaine exemples de valeurs

EMPLOYE nom-employé NOM Fantasio, Lagaffe
adresse-employé ADRESSE château-de-Champignac
photo-employé image N&B
CLIENT nom-client NOM Dupont, Dupond

adresse-client ADRESSE château de et à Moulinsart
PRODUIT nom-produit LIBELLE chaussettes, jupe, draps
prix-de-vente PRIX 89, 879, 2299
quantité-en-stock QUANTITE 433 lots,2500 pièces,1000 paires
COMMANDE qté-commandée QUANTITE 1 lot, 1 pièce, 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 éléments, par exemple le langage OCL ("Object Constraint Language"),
qui ne s’adaptent pas aux associations de degré supérieur à 2. C’est 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'intérieur du symbole représentant le type d'entité
ou d'association. La documentation doit en outre indiquer quel est le domaine de chaque type d’attribut.
Ent/Ass UML
PERSONNE
n om
PERSONNE
dat e n aissan ce
nom
dat e naissan ce
HOMME FEMME
n o m de jeun e fille 0..1 0..1 FEMME
mari épouse HOMME
mari épouse n o m de jeun e fille
0,1 0,1
CONJOINT
CONJOINT dat e m ariage
dat e m ariage
REMARQUE. Dans le cas d'une entité participant à une association avec une connectivité 1:1, on peut hésiter
à attacher certains attributs soit au type d'entité, soit au type d'association.
Exemple : PASSATION (CLIENT passant 0:N, COMMANDE passée-par 1:1)

– la date-de-commande peut être attribut de COMMANDE ou de PASSATION
Ent/Ass
CLIENT passant
n o m clien t PASSATION 1,1 COMMANDE
adresse clien t 0,N dat e co m m an de passée n° co m m an de
UML
CLIENT 1,1 0,N COMMANDE
n o m clien t
adresse clien t passant passée n° co m m an de
PASSATION
dat e co m m an de
En mathématique, une relation est une partie du produit cartésien de plusieurs domaines. Exemple :
domaine 1 domaine 2 produit cartésien relation

"masculin" "male" ("masculin", "male") ("masculin", "male")
"féminin" "female" ("masculin", "female") ("féminin", "female")
("féminin", "male")
("féminin", "female")
Un type d'attribut est une relation faisant correspondre à chaque élément d'un ensemble d'entités ou d'associa-
tions un élément d'un domaine de valeurs (de la même manière qu’un type d’association est une relation fai-
sant correspondre à chaque occurrence d’un ensemble d’associations une occurrence du domaine que constitue
un type d’entités), ce que suggère bien la représentation graphique préconisée par CHEN.

entier
année
Domaine mois
jour
date nom
patronyme
naissance
prénom
PERSONNE
Entité
de jeune fille
HOMME FEMME
mariage
mari épouse
Assoc.
CONJOINT
Date (Entier jour, Entier mois, Entier année)

PERSONNE [Nom patronyme, Nom prénom, Date naissance]
HOMME [PERSONNE] -- le sous-type "hérite" de la définition de PERSONNE
FEMME [PERSONNE, Nom jeune-fille]
CONJOINT <Date mariage, HOMME mari, FEMME épouse>
Noms d'attributs
Ce point de vue suggère une méthode pour nommer les attributs. Le nom d'un attribut sera formé par la
concaténation :
• soit du nom de domaine et du nom du type d'objet décrit, entité ou association (ex.: nom-client, nom-
produit, numéro-de-commande); le nom de domaine peut souvent être abrégé (ex.: "no" pour "numéro", "lib"
pour "libellé", "qté" pour "quantité", etc);
• soit du nom de domaine et d'un qualificatif de rôle (ex.: prix-de-vente, quantité-en-stock, date-de-mariage);
la présence d'un qualificatif de rôle est indispensable dans le cas où plusieurs attributs d'un même type d'objet
partagent un domaine commun (ex.: les attributs date-d'émission et date-de-livraison-souhaitée du type d'ob-
jet COMMANDE);
• soit du nom de domaine, d'un qualificatif de rôle et du nom du type d'objet décrit (ex.: date-d'émission-de-
la-commande).
Propriétés des attributs
Un attribut peut être élémentaire (ex.: nom-client, nom-produit) ou structuré (ex.: date-de-commande, dé-
composable en jour + mois + année).

Un attribut peut être simple (ex.: EMPLOYE : nom) ou répétitif (ex.: EMPLOYE : prénoms) — certains
auteurs emploient les qualificatifs mono-valué et multi-valué.
Lorsque la valeur d'un attribut est une grandeur mesurée (QUANTITE, PRIX), l'unité de mesure doit théo-
riquement être indiquée (ex.: lot, pièce, 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-
nétaire 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 théorie, tout attribut est obligatoire; en effet, par définition, toutes les occurrences d'un type partagent
toutes les propriétés de celui-ci. Par généralisation, on pourra cependant inclure une valeur "inexistant" dans
le domaine d'un attribut que l'on désire rendre facultatif; grâce à cet artifice, il est possible d'attacher la notion
de nom-de-jeune-fille à toute personne plutôt que de distinguer le sous-type des FEMMES-MARIEES. Dans
le même ordre d'idées, on peut inclure dans tout domaine de valeurs, la valeur "inconnu".
Définition des domaines de valeurs
Dans un système écrit, la valeur d'un attribut est représentée par une suite de caractères.1 A ce niveau, un do-
maine élémentaire est redéfini comme faisant lui-même partie d'un type de valeur, du genre de ceux que
proposent les langages de programmation.2 (Si le domaine contient les valeurs spéciales "inexistant" ou "in-
connu", on n'oubliera pas de prévoir la méthode de codification de ces valeurs.)
Exemples : domaine type de valeur

QUANTITE nombre entier
PRIX nombre décimal — en COBOL : PICTURE 9(4)V99
NOM CHAR(20) — en COBOL : PICTURE X(20)
Un domaine structuré (ex.: DATE) est redéfini comme une relation entre sous-domaines (JOUR, MOIS,
ANNEE).
d) Identifiants
Le concept général d'identifiant a été introduit au chapitre 2, en même temps que celui de dépendance fonc-
tionnelle. Quelle forme prend un identifiant dans le modèle Entité–Association ?
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, année, nombre d'étudiants]
1 On parle de plus en plus aujourd'hui de bases de données généralisées, où les attributs peuvent prendre la
forme d'images, de textes quelconques, de séquences sonores ...
2 La locution "type d'un attribut" est habituellement comprise dans ce sens de type de la valeur de l’attribut.

Si un type d'entité E participe nécessairement à une association, c'est-à-dire avec une connectivité minimale de
1 (connectivité 1:1 ou 1:N), l'identifiant du type E peut être entièrement ou partiellement formé de l'identi-
fiant des entités auxquelles il est nécessairement associé. On appelle identifiant étranger l'identifiant ainsi
"importé" d'une entité associée. Nous représenterons la chose en soulignant la connectivité 1:? du rôle de E
dans l'association par laquelle il reçoit 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'expédition découlant de cette com-
mande.
FACTURE
FACTURATION 1,1
0,1 dat e de fact ure
COMMANDE
n ° co m m ande
dat e de co m m an de BORDEREAU
0,N LIVRAISON 1,1 n ° de liv raiso n
dat e d'ex p édit ion
C'est toujours le cas des immatriculations hiérarchiques.
Exemple. Le numéro d'affiliation d'un employeur à une Caisse d'Allocations Familiales dépend du
bureau régional de cette caisse qui gère le dossier; le numéro d'affiliation est formé par la concaté-
nation du numéro de bureau et d'un numéro d'inscription à ce bureau.
BUREAU
REGIONAL
n ° bureau AFFILIATION EMPLOYEUR
0,N 1,1 n ° in scrip t io n
lo calit é dat e d'en regist r.
........ ........
Toute entité occurrence d'un sous-type (ex.: HOMME ou FEMME) appartient également au sur-type (ex.:
PERSONNE); elle hérite donc de l'identifiant défini pour le sur-type (ex.: numéro au Registre National).
Identifiant d'un type d'association
L'identifiant d'une association est en principe formé d'identifiants étrangers. Nous représenterons la chose en
soulignant le nom des rôles des types d'entités associés dont l'identifiant est utilisé.
PRODUIT composé 0,N

COMPOSITION
id p ro duit
quan t it é
p rix unit aire
composant 0,N
1 L'expression identifiant étranger provient de la théorie du modèle relationnel. Dans le cas du modèle Enti-
té–Association, certains parlent d'identification par les rôles.

MATIERE
dispensée
1,N
ENSEIGNEMENT
1,N 1,N
titulaire suivant
PROFESSEUR CLASSE
en supposant que toute matière est enseignée par un seul professeur
Quelquefois, les identifiants des entités associées ne suffisent pas à identifier l'association. On suppléera en
créant pour l'association un attribut identifiant.
Exemple. Un même CLIENT assuré peut, par le truchement du même COURTIER, obtenir plusieurs
contrats dans une même branche d'ASSURANCE (notamment, une assurance incendie pour chacun
de ses immeubles bâtis); un "numéro de police" est nécessaire à l'identification complète du CON-
TRAT.
CLIENT ASSURANCE
assuré branche
1,N 0,N
CONTRAT
n ° p o lice
0,N
intermédiaire
COURTIER
Identifiants multiples
Plusieurs identifiants peuvent exister pour le même type d'objet. Exemples : le travailleur EMPLOYE par une
entreprise peut être identifié par son numéro au Registre National et par un numéro de matricule interne; si
une FACTURE est toujours relative à une et une seule COMMANDE, le numéro de commande est un identi-
fiant de FACTURE, aussi bien que le numéro de facture. On choisit habituellement un identifiant primaire,
privilégié; les autres sont qualifiés de candidats (à devenir primaires).1
REMARQUE. Un sous-type d'entité hérite des identifiants de son sur-type. Mais ceux-ci n'ont pas nécessai-
rement le même statut dans le sur-type et le sous-type. Exemple : l'identifiant unique et donc primaire du type
d'entité PERSONNE est le numéro du Registre National; pour le sous-type EMPLOYE, dont l'identifiant pri-
maire est un numéro de matricule propre à l'entreprise, l'identifiant hérité n'est que candidat.
Dans les représentations graphiques d'un type d'entité, les composants de l'identifiant primaire peuvent être
soulignés et les composants d'un même identifiant candidat, préfixés par un numéro distinctif commun.
1La nécessité de choisir un identifiant primaire sera surtout le fait des techniques informatiques de stockage
des données, qui se donneront pour objectif d'accélérer l'accès sélectif par le biais de cet identifiant privilégié.

EMPLOYE
n° m atricule
nom
prénom
(1) n° national
Les représentations 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 détour d'un commentaire); on pourra
cependant, comme nous l'avons fait jusqu'ici, représenter l'identifiant primaire en soulignant le nom des rôles
fournissant l'identifiant ou en le préfixant par un astérisque.
Propriétés 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-même identifiant; en d'autres termes, aucun des composants d'un identifiant ne doit
dépendre fonctionnellement des autres.
Supposons que l'identifiant d'un EMPLOYE soit composé de son numéro de matricule (unique dans
l'ensemble de l'entreprise) et du numéro du département qui l'occupe; cet identifiant n'est pas mini-
mal, car le numéro de matricule est à lui seul identifiant et le numéro de département dépend fonc-
tionnellement de ce numéro : n° matricule → n° département.
Dans les exemples suivants d'associations, seuls les rôles soulignés composent l'identifiant; on re-
marquera que, dans le cas où la connectivité maximale d'un rôle est 1, ce rôle à 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 dispensée-dans 1:N, classe suivant 1:N,

PROFESSEUR titulaire-de 1:N);
elle peut être identifiée de différentes manières et le choix de l'identifiant complète et précise la dé-
finition sémantique de ce type d'association :
ENSEIGNEMENT (MATIERE dispensée-dans 1:N, CLASSE suivant 1:N,

PROFESSEUR titulaire-de 1:N)
– toute matière est enseignée par un seul professeur, éventuellement à plusieurs classes :
(matière, classe) → professeur
ENSEIGNEMENT (MATIERE dispensée-dans 1:N, CLASSE suivant 1:N,
– plusieurs professeurs enseignent la même matière, mais pas dans la même classe :
(matière, professeur) → classe
Les attributs entrant dans la composition de l'identifiant primaire ne peuvent prendre les valeurs "inconnu" ou
"inexistant" (le numéro de carte d'identité serait un mauvais identifiant pour les HABITANTs d'une com-
mune, car certains habitants — les enfants — ne possèdent pas de carte d'identité). De plus, la valeur de
l'identifiant primaire doit être stable, c'est-à-dire non sujette à modification; cette dernière condition est né-
cessaire à la continuité de l'identification de chaque occurrence d'objet, en dépit des modifications qu'elle peut
subir pendant sa durée de vie.
C'est en particulier pour répondre à des situations où un identifiant "naturel" n'apparaît pas stable, notamment
lorsque la valeur peut en être inconnue, qu'on utilise parfois des identifiants internes de substitution, attribués
par le système (automatique ou manuel) de mémorisation de l'information; il s'agira par exemple d'un com-
postage, attribution d'un simple numéro de suite.

e) Dimension historique
L'insertion de la dimension historique dans le modèle Entité–Association s'opère en incluant l'indication des
périodes de validité dans l'identifiant des entités ou associations.1
TARIF
période
n° produit
prix de vente
Soit le type d'association OCCUPATION (OUVRIER travaillant-à 0:1, CHANTIER réalisé-par 0:N). Si l'en-
trepreneur veut garder trace de l'occupation successive de ses ouvriers à différents chantiers, le type d'associa-
tion devient :
CHANTIER CHANTIER
réalisé réalisé
0,N 0,N
OCCUPATION OCCUPATION
pério de
0,1
0,N
travaillant
travaillant
OUVRIER
OUVRIER
REMARQUES. L'identifiant minimal d'un élément (entité ou association) historique est le même que celui
de cet élément s'il ne possédait pas la dimension historique, augmenté de l'indication de période. L'insertion
de la dimension historique au sein d'un type d'association transforme les éventuelles connectivités ?:1 en
connectivités ?:N.
Si la période de validité, au lieu d'être réduite à un point dans le temps (comme la "date d'envoi" d'une
FACTURE), forme un intervalle continu, la représentation et la manipulation de cette indication posent quel-
ques problèmes spécifiques.
1) Pour fournir une identification certaine des occurrences successives, les périodes définies pour un
même type d'élément doivent être disjointes.
2) La mention d'une période se fait théoriquement par la double indication d'une date ou heure de
début et d'une date ou heure de fin. La fin d'une période de validité est le plus souvent inconnue tant
que la période n'est pas révolue; pour cette raison, la date (ou heure) de fin se prête 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
différentes périodes 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 période de validité pourrait également être attachée à la valeur d'un attribut.
Mais, dès que l'on veut garder trace de l'histoire de cet attribut, il devient nécessaire de mémoriser les versions
(occurrences) successives du type d'objet qui possède cet attribut. De ce fait, l'indication de période devient
identifiante de l'entité ou de l'association mémorisée.

4) La recherche d'une occurrence mémorisée portera d'ordinaire sur l'occurrence "valide à telle
date", la date indiquée n'étant pas nécessairement la date de début (ni l'éventuelle date de fin) ins-
crite dans l'identifiant de l'occurrence cherchée; on devra donc parcourir l'ensemble ordonné de tou-
tes les occurrences mémorisées, les comparant deux à deux, pour savoir sur quelle occurrence "s'ar-
rêter" (comme les accès les plus fréquents visent les occurrences les plus récentes, on aura avantage
à classer la collection historique par ordre de dates décroissantes) : "lire-suivant jusqu'à ce que date-
de-début-de-validité ≤ date-cherchée".
Exemple : début de validité date cherchée

04/02/2002
28/11/2001
17/03/2001 ≤ 20/09/2001
03/06/2000
NOTE. En réalité, toute information possède une dimension historique, et l'analyste devrait systématique-
ment chercher quelles conséquences exactes entraîne le fait de la masquer.
f) Discussion
Revenons à la représentation originale de CHEN.
compositon
entier nom
année
Domaine mois
jour relations
date
patronyme
naissance prénom identifiants
PERSONNE
Entité
de jeune fille
HOMME FEMME
mariage
mari épouse
Assoc.
CONJOINT
On voit que, au total, le procédé est uniforme : la modélisation des données se réduit à la composition de
relations. Les niveaux de composition se distinguent de la façon suivante :
– une entité (ex.: PERSONNE) se différencie d’une valeur structurée (ex.: DATE) par le fait qu'elle pos-
sède un identifiant qui permet de la désigner, tandis qu'une valeur se "désigne" elle-même;
– une association (ex.: CONJOINT) se différencie d’une entité (ex.: PERSONNE) en ce qu'elle relie des
entités; de ce fait, comme l'association FACTURATION ci-dessous, elle peut ne pas avoir d’attributs.

CLIENT passant
n o m clien t PASSATION
adresse clien t 0,N dat e com m an de 1,1
passée COMMANDE
n° co m m an de
facturée
0,1
FACTURE 1,1
n ° fact ure FACTURATION
dat e fact ure émise
Plus significativement, l'analyste considère que les entités constituent la matière spécifique et "vivante"
de l'application qu'il décrit, tandis qu'il tient pour préexistants, "donnés tels quels" ou "inertes" les
domaines de valeurs. Les frontières entre les concepts d'entité associée et valeur caractéristique ne sont
donc pas fixes; elles dépendent de la perception de l'analyste.
Exemple. Pour toute firme effectuant une gestion de clients, le client est, entre autres choses, une en-
tité associée à des commandes; pour le commerçant détaillant qui "ne fait pas crédit" mais qui ac-
cepte de "prendre des commandes", l'identité du client est un attribut de la commande.
1.2. Structures particulières
a) Compositions sémantiquement équivalentes
Si tous les rôles assumés 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 rôles
joués dans un type d'association ont la connectivité 1:1, la composition de ce type d'association avec tous les
types d'entités participants est équivalente à un type d'entité.
1,1 1,1 1,1 1,1
Cette propriété d'équivalence sémantique sera exploitée par certaines transformations de schémas.
b) Associations non représentables
Un contrat est typiquement une association; un avenant fait référence à 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 modèle Entité–Association ne permettent pas de représenter sous ces termes le
concept d'avenant à un contrat. D'une part, cet avenant est présenté comme une association de degré 1, pour
laquelle existe un seul rôle (CONTRAT modifié); or toute association est de degré au moins égal à 2. D'au-
tre part, il est présenté comme une association d'associations; or une association (CONTRAT) ne peut pas
assumer un rôle au sein d'une autre association.1
1 Pour passer outre à cette limitation, il suffirait que tout arc symbolisant un rôle soit orienté par une flèche
partant de l'association vers le membre.

Solution : toute association non représentable, association référencée (ex.: CONTRAT) ou association
incomplète (ex.: AVENANT), peut être transformée en pseudo-entité et chacun de ses rôles en pseudo-
association sans attributs, à laquelle la pseudo-entité participe avec une connectivité 1:1. Cette transforma-
tion exploite la propriété d'équivalence sémantique définie au paragraphe précédent.
AVENANT
1,1
MODIFICATION
0,N
0,N 1,1 1,1 0,N

LOCATAIRE CONTRAT PROPRIETAIRE
Critique du modèle Entité–Association
Cette limitation du modèle, qui conduit à représenter une association sous les traits d'une entité, véhicule donc
une contradiction sémantique : le formalisme nie sa propre définition !
A cause de cette même limitation, un schéma Entité–Association 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'entités).
Un schéma Entité–Association n'est pas exempt de constructions parasites. Telles sont, comme dans les
transformations évoquées 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'entités, les adeptes de l'orientation objet parlent de classes d'objets.
Comme la définition d'une entité, la définition d'un objet mentionne les attributs qui décrivent son état et les
associations auxquelles il participe; elle ajoute les opérations que cet objet peut effectuer, essentiellement
pour modifier ou faire connaître son propre état. Tout objet est en effet responsable de son propre état.
Exemple. Un COMPTE CLIENT est un objet. Il est caractérisé par des attributs et des associations :
identité du client, état débiteur ou créditeur, montant du solde, date du dernier mouvement ... Les
opérations possibles sont : ouvrir le compte, le débiter du montant d'une facture, le créditer du mon-
tant d'un paiement ou d'une note de crédit, consulter l'état du compte, clôturer le compte ...
COMPTE
état
solde
CLIENT date dernier mouvt
POSSESSION
nom titulaire
ouvrir( )
adresse 1 1..* débiter( )
créditer( )
consulter( )
clôturer( )
UML : diagramme de classes
Des objets et classes d’objets peuvent être découverts à différents stades de l’analyse. Les plus "es-
sentiels" d’entre eux, à la fois les plus significatifs et les moins contingents, le sont lors de l’étude
d’un domaine d’application, lors de l’élaboration du schéma conceptuel de ce domaine. Les opéra-
tions en font-elles partie ? Assurément. En effet, autant que les attributs, les opérations possibles —
telles celles que nous avons identifiées pour un compte client — manifestent la nature intime des ob-
jets du domaine. (Ce qui sera le propre des applications futures, ce sera la répartition, la mise en œu-
vre de ces opérations dans différents scénarios d’activation.1)
Particularité remarquable : en principe, les utilisateurs d'un objet ne connaissent que les opérations qu'ils peu-
vent demander à cet objet et, à proprement parler, en ignorent les attributs et associations. Les données d'un
objet sont privées ou cachées (elles ne sont accessibles qu'aux opérations de l'objet), tandis que les opérations
sont publiques, c'est-à-dire utilisables par n'importe quel objet ou programme. On donne à ce procédé le nom
de masquage (en anglais : "encapsulation"); ce principe a été formalisé dans la théorie des types de don-
nées abstraites.2
1 C’est parce qu’elles ne faisaient pas la distinction entre les opérations proprement dites et leur mise en œuvre
que les méthodes d’analyse anciennes, MERISE par exemple, décrétaient que les opérations ne possèdent pas
le caractère quasi immuable des choses "conceptuelles", mais sont "contingentes" et sujettes à d’assez fré-
quentes révisions.
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 enregistrée
sous la forme d'un attribut ou d'une association, si le montant du solde est effectivement enregistré
dans la base de données ou s'il est recalculé chaque fois que c’est nécessaire ...
Dans un type de données abstraites, le concept d’attribut est redéfini de la façon suivante : un couple
d’opérations set et get transmettant une valeur. L’utilisateur ignore si l’attribut est enregistré tel quel ou
virtuel, c’est-à-dire calculé à chaque accès.
Les opérations mentionnées dans la définition d’un type abstrait se répartissent en trois catégories :
– créateurs ou constructeurs d’occurrences,

– modificateurs de l’état d’une occurrence,
– observateurs ou rapporteurs renseignant sur l’état des occurrences.
Les opérations set et get de mise à jour et consultation d’un attribut constituent un cas particulier
des deux dernières catégories.
Données privées, opérations publiques ... A dire vrai, seule est publique la signature des opérations, c'est-à-
dire la forme du message qui les invoque (nom de l’opération, description des paramètres et du résultat). La
réalisation interne des opérations (en anglais : "implementation"), c'est-à-dire la méthode utilisée, demeure
cachée, tout comme les données.1 L'ensemble des signatures publiques d'un objet compose ce qu'on appelle
son interface.
b) Spécification des opérations
Au même titre qu’un attribut, une opération caractéristique d’un type d’objet doit être définie.
Spécification externe
La spécification externe d’une opération n’est rien d’autre que ce qu’on appelle dans les langages de pro-
grammation la signature du sous-programme qui la mettra en œuvre.
Cette signature comporte les éléments suivants :
– le mode opératoire du sous-programme : fonction ou procédure
. une fonction rend en résultat un objet ou une valeur, elle ne modifie pas ses paramètres
. une procédure peut modifier les paramètres qu’elle reçoit, elle ne rend pas de résultat
dans les langages de la famille C,

la signature d’une procédure est celle d’une fonction rendant un résultat de type "void"
– un nom évocateur, identifiant l’opération
Idéalement, le nom attribué à une fonction est un substantif ou un qualificatif exprimant la relation
sémantique qui permet de définir le résultat au moyen des paramètres et de l’état de l’objet.
Exemples : compte. créditeur () => vrai / faux
1 Par un abus de langage, on emploie souvent le mot méthode pour désigner l’opération qui utilise la méthode.

Idéalement, le nom d'une procédure est formé du verbe qui en exprime l'opération principale, éven-
tuellement suivi d'un complément qui identifie le résultat principal.
Exemples : compte. débiter (montant)

clôturer ()
client. modifier_adresse (adresse)
– une liste de paramètres, qui peut être vide
pour chaque paramètre :
. un nom, qui permet d’y faire référence;

. son type ou sa classe;
. le mode d’utilisation de ce paramètre par le sous-programme :
in le sous-programme utilise les valeurs reçues mais ne les modifie pas

out le sous-programme range des valeurs dans le paramètre
inout le sous-programme utilise les valeurs reçues et les modifie
– si le sous-programme est une fonction ou un opérateur : le type ou la classe de son résultat
– la liste des signaux d’exception émis par l’opération en cas d’échec
pour chaque exception :
. son type
. les éventuelles données d’information contenues dans le signal
. en commentaire : les valeurs significatives
Définition sémantique
La spécification externe d’une opération devra être complétée par la liste des pré-conditions et post-
conditions, plus éventuellement la méthode (c’est-à-dire l’algorithme), qui définissent la sémantique de
cette opération.1
c) Aperçu sur le langage IDL
L’analyste peut adopter les formes du futur langage de programmation, par exemple C++ ou JAVA, si celui-ci
est déterminé à l’avance. Mais il serait sans doute préférable de recourir à un langage comme IDL, l’Interface
Definition Language faisant partie de la norme CORBA ("Common Object Request Broker Architecture")
établie par l’Object Management Group (OMG).2 Ce langage a précisément été défini dans le but de permet-
tre des spécifications indépendantes d’un environnement particulier.
Le langage de spécification IDL est basé sur le langage de programmation C++, ce qui le rend d’emblée com-
préhensible à 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; 2e éd., Dunod, 1999 (cet ouvrage est téléchargea-
ble sur le site corbaweb.lifl.fr/CORBA_des_concepts_a_la_pratique/).

Un module IDL regroupe des définitions que l’analyste considère comme solidaires.1 Tout nom peut
être préfixé par le nom du module où il est défini suivi, comme en C++, de l’opérateur ::.
Pour l’essentiel, un module contient la définition de l’interface des différents types d’objets, c’est-à-
dire la spécification de leurs attributs et opérations. Le(s) super-type(s) dont hérite un sous-type
d’objets est/sont listé(s) à la suite du nom du sous-type, comme en C++ (pour l’illustrer dans
l’exemple ci-dessous, nous définirons le type d’association possession de comptes comme un sous-
type du stéréotype Association_1_N).
D’autres définitions sont possibles : types de données analogues aux types de données construits du
langage C, types (structurés) des signaux d’exception, constantes, etc. Dans l’exemple ci-dessous,
ces définitions auxiliaires font partie de la définition de l’interface qui les utilise; on aurait pu les
placer en-dehors de la définition des interfaces.
Exemples
COMPTE
état
solde
CLIENT date dernier mouvt
POSSESSION
nom titulaire
ouvrir( )
adresse 1 1..* débiter( )
créditer( )
consulter( )
clôturer( )
module méta // méta-définitions (stéréotypes du modèle Ent-Ass)

{
interface ASSOC_1_1 { };
interface ASSOC_1_N { };
interface ASSOC_M_N { };
};
module commun // définitions 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 d’opérations définies actuellement
};
1 En IDL, l’unité compilable est le module.

interface Compte
{
enum Etat_Compte { débiteur, soldé, créditeur };
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 débiter (in montant);
void créditer (in montant);
structure Relevé
{
string nom_client;
float solde;
commun::Date date_dernier_mouvt;
};
Relevé consulter ();
void clôturer ();
};
interface Possession : méta::ASSOC_1_N

{
attribute Client titulaire;
attribute sequence<Compte> possédé;
};
};
2.2. Modélisation des relations d’abstraction
D'après la définition originelle du modèle Entité–Association, une association unit des objets ou concepts,
appelés entités, dont l'existence est autonome (ex.: les entités HOMME et FEMME dans l'association CON-
JOINT).
Certains auteurs1 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'agrégation, la classification et la
généralisation.2
Les méthodologies et systèmes orientés objets accordent une importance primordiale à ces relations et les re-
présentent par des symboles particuliers.
a) Agrégation / Contenance
L'agrégation (ou son inverse : la contenance) est la relation par laquelle une collection d'objets composants
constitue par elle-même un objet agrégat caractérisé par des attributs et/ou des associations distincts de ceux
des composants; l'existence d'une occurrence de l'agrégat implique l'existence d'au moins une occurrence de
composant. Comme l'association, l'agrégation est une relation entre des occurrences.
1 Voir notamment J. SMITH, D. SMITH : op. cit. Les modèles basés sur cette approche sont connus sous le
nom de modèles des réseaux sémantiques.
2 Nous avons montré au chapitre 2, § 2.1 comment les deux dernières fondent les techniques de modélisation.
Le mécanisme d’agrégation/désagrégation est tout aussi fondamental dans une démarche d’analyse.

Dans la notation UML, un petit losange signale le type agrégat.
Dans un schéma Entité–Association, l'agrégat est présenté comme une entité, tandis que les composants peu-
vent être des entités ou des associations.
L'idée d'équipe sur un chantier, qui permet de mettre en évidence le rôle 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 véhicule de société adapté à ses besoins ... (Noter
que, dans les schémas ci-dessous, un ouvrier peut être membre et même chef de plusieurs équipes.)
UML
0..* 0..*
CHANTIER EQUIPE 0..*
OCCUPATION
0..*
0..* AFFECTATION
COMPOSITION 1..*
DIRECTION
VEHICULE
1..*
1..1 chef membre
OUVRIER
Ent/Ass
0,N 0,N
CHANTIER OCCUPATION EQUIPE
1,N
1,1 1,N
AFFECTATION
DIRECTION COMPOSITION
0,N
0,N 0,N
chef membre VEHICULE
OUVRIER
En UML, on distingue deux niveaux d’agrégation :
– l'agrégation "partagée" ou "faible", dans laquelle une même occurrence de composant peut faire simulta-
nément partie de plusieurs agrégats (c'est le cas de l'exemple ci-dessus : un ouvrier peut faire partie de diffé-
rentes équipes)
l'agrégation partagée est symbolisée par un losange vide
– la composition ou agrégation "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 symbolisée par un losange plein
PHASE
PROJET n ° o rdre
o bjet PLANNING
dat e début
resp on sable 1..* durée
budget 1..1
descript io n

b) Classification / Instanciation
La classification (ou son inverse : l'"instanciation"1) est l'abstraction par laquelle une définition commune
(la classe, la catégorie ou le type) s'applique à un ensemble de phénomènes (ou occurrences). Il n'est pas
exceptionnel de devoir inclure dans la base de données, non seulement la description des occurrences, mais
également la définition de la classe; c'est le cas chaque fois que des objets individuels peuvent appartenir à
diverses catégories qui sont elles-mêmes décrites dans un catalogue.
Les attributs et/ou associations décrivant la classe décrivent également chaque occurrence; en d'autres termes,
chaque occurrence d'une classe "hérite" des attributs et associations propres à cette classe.
La relation de classification/instanciation est une relation entre type et occurrences.
Elle peut être représentée par une association définie de la manière suivante :
– APPARTENANCE (TYPE de 0:N, OCCURRENCE de 1:1);

– l'association APPARTENANCE n'a pas d'attributs autres qu'une éventuelle période de validité;
– elle a le même identifiant que l'entité OCCURRENCE.
Exemples : types de chambres dans un hôtel, types de cotisations pour les membres d'un club ...
Ent/Ass
CATEG.CHAMBRE TYPE COTIS.
co de cat égo rie in t it ulé
p rix nuit ée m o n t an t
p ério dicit é
type
1,N type
0,N
QUALIFICATION
COTISATION
dat e
1,1
occurrence
1,1
CHAMBRE occurrence
n°
MEMBRE
ét age
n°
o ccup at ion
no m
réserv at io n s
adresse
UML
CATEG.CHAMBRE TYPE COTIS.
co de cat égo rie in t it ulé
p rix n uit ée m o n t an t
p ério dicit é
1..1 type
COTISATION
CHAMBRE dat e
n°
ét age
o ccup at io n
0..* occurrence
réserv at io n s MEMBRE
n°
nom
adresse
1 "Instanciation" : mot anglais construit à partir du radical "instance", qui signifie occurrence.

c) Généralisation / Spécialisation
La généralisation (ou son inverse : la spécialisation) est une relation par laquelle une même occurrence
d'objet appartient à deux types différents, dont l'un — le sous-type — est inclus dans l'autre — le sur-type. Le
sous-type "hérite" des attributs, associations et opérations génériques du sur-type; il possède en outre des at-
tributs, associations et/ou opérations spécifiques, qui le différencient; il peut encore redéfinir autrement cer-
taines des caractéristiques dont il hérite.1
La généralisation/spécialisation est une relation entre des types.
Ainsi qu'on le verra, cette relation peut être utilisée pour opérer certaines transformations des schémas de don-
nées : une spécialisation peut en améliorer la précision, une généralisation peut en diminuer la complexité.
Cet intérêt méthodologique particulier justifie qu'elle ait été intégrée au modèle Entité–Association, où elle
peut être représentée par un symbole ad hoc.
Elle pourrait également être représentée sous la forme d'une association "EST-UN", définie de la manière 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 période de validité;
– le SOUS-TYPE et l'association EST-UN ont le même identifiant que le SUR-TYPE.
UML Ent/Ass
PERSONNE PERSONNE
n ° n at io nal n ° n at io n al
nom nom
p rén o m p rén o m
dat e de n aissan ce dat e de n aissan ce
0,1 0,1
EST-UNE EST-UNE
1,1 1,1
HOMME FEMME HOMME FEMME
0,1
EST-UNE
1,1
FEMME MARIEE FEMME MARIEE

n om de jeun e fille n om de jeun e fille
N.B. On peut, sans problème, concevoir des sous-types d'associations, mais la limitation du formalisme En-
tité–Association évoquée plus haut ne permet pas de représenter le lien de ces sous-types avec un sur-type
d'association. (Ici aussi, les types d'associations devraient être transformés en types de pseudo-entités.)
1 Les langages de programmation par objets disposent d’un mécanisme sélectionnant automatiquement, parmi
les diverses définitions d’une opération "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 :
EQUIPE
1,1 1,N
DIRECTION COMPOSITION
0,1 1,1
chef membre
OUVRIER
2.3. Schéma dynamique : diagrammes d’états et transitions
a) Etats
A tout moment, un objet se trouve dans un certain état, caractérisé par la valeur de ses attributs et sa participa-
tion à certaines associations.
On définit 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 définitions
Produit { épuisé stock = 0

{ approvisionné stock > 0
Il est parfois possible d'opérer des regroupements de classes d'états.
Exemple : type d'objet classes d'états (UML) définitions
Dette en cours solde > 0
apurée OU remise
éteinte
apurée remise
NOTE. Les exemples ci-dessus sont des exemples d'objets–entités dont les états sont des états inertes. D'au-
tres objets, par exemple un programme exécuté sous le contrôle d'un superviseur (un "processus", dans la
terminologie des systèmes 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 différentes actions :
– une action ponctuelle exécutée lors de l'entrée dans l'état,

– une "activité" continue pendant toute la durée de l'état,
– une action ponctuelle exécutée lors de la sortie de l'état,
– des actions ponctuelles réagissant à la survenance de certains événements.

Exemple : type d'objet classes d'états (UML)
Processus en cours
entrée : charger les paramètres
faire : exécuter les instructions
sortie : préparer le code de retour
b) Transitions
Dans la vie d'un objet, on peut définir une ou plusieurs séquences de transitions d'états autorisées.
– Une transition d'état, c'est-à-dire le passage d'un état à un autre,

est la conséquence d'un événement dont l'objet reçoit la notification sous la forme d'un message.
Cependant, si l'état de départ est un état actif, la transition est parfois automatique, sans message
(ex.: la fin d'exécution d'un programme).
– La transition peut être "gardée", c'est-à-dire subordonnée à une condition.
– Elle peut s'accompagner d'une action,
c'est-à-dire de l'émission d'un message dérivé, éventuellement destiné à un autre objet.
Diagramme des transitions d'états d'un objet (UML)
Produit SYNTAXE recommandée :
entrer(qté) entrer(qté) transition := événement [garde] / action

créer()
événement := message
épuisé approvisionné message := opération (paramètres)
action := ^objet_cible.message
sortir(qté) [qté=stock] /
sortir(qté) [qté<stock]
^commande_fournisseur.créer
(prod,qté,fourniss)
Processus
en cours
exec()
entrée : charger les paramètres Noter la représentation conventionnelle
faire : exécuter les instructions
des états initial (unique)
sortie : préparer le code de retour
et finals (en nombre quelconque).
REMARQUE. Sous peine d'ambiguïté, une transition ne peut pas aboutir à une classe d'états définie par re-
groupement.

c) Méthode
Sur l'exemple de l'état civil d'une personne, illustrons la démarche d'élaboration d'un tel diagramme.
1)
Répertorier les classes d'états de base : en vie
Célibataire, Marié, Divorcé, Veuf. libre
naissance décès
C D V
2)
Recenser les événements pertinents,
causes de transitions :
naissance, mariage, divorce, décès du divorce
conjoint, décès propre. mariage
décès conjoint
3) M
Regrouper les classes d'états se trouvant
à l'origine des mêmes transitions :
libre (C ou D ou V), en vie.
Ü • C M D V (•)
• x
C x x
M x x x
D x x
V x x
(•)

3. Contraintes d'intégrité
3.1. Portée des contraintes d’intégrité
Le schéma conceptuel des données ne serait pas complet s'il n'énonçait les règles de cohérence, les contraintes
d'intégrité applicables aux objets qu'il décrit.
Certaines de ces contraintes doivent être satisfaites à tout moment; on les appelle des invariants. D'autres ne
doivent être vérifiées qu'à certains moments; ce sont les pré-conditions ou post-conditions des opérations et
procédures du système de traitement de l'information. Les pré-conditions d’une opération doivent être satis-
faites pour que l’opération puisse être entreprise; les post-conditions d’une opération sont des prédicats que
l’exécution de l’opération doit rendre vrais, elles constituent l’expression formelle des résultats de l’opération.
Certaines contraintes "concernent" un seul type d’objet, entité ou association. Ces contraintes font partie in-
tégrante de la spécification de ce type d’objet. Certains langages1 permettent d’ailleurs de les incorporer à la
définition "programmée" du type d’objet : les invariants sont attachés aux attributs, les pré- et post-conditions
sont attachées aux opérations.
3.2. Connectivité et identifiant
En précisant les connectivités minimum et maximum d'un rôle et en définissant l'identifiant minimal d'un
type d'objet, on exprime des contraintes d'intégrité, inhérentes au modèle Entité–Association.
3.3. Durée de rétention
Avec ou sans dimension historique explicite, une entité ou association est conservée un certain temps dans la
collection décrite par le schéma. C'est ce qu'on appelle sa période de mémorisation ou de rétention.
Il est essentiel de formuler la règle qui en détermine la durée, car elle n'est pas sans influence sur l'exactitude
du schéma. Ainsi, par exemple, définissant 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 rôle 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 conservée pendant l'éternité ! Si, comme il se doit, on pose la contrainte que la durée de
rétention d'une commande n'est pas illimitée, cette connectivité devient 0:N.
Nous ne proposerons pas de formalisme pour l'expression de cette contrainte. Indiquons toutefois que :
– par défaut, c'est-à-dire sans règle explicite, la durée de rétention d'une entité est illimitée;
– par défaut, la période de rétention d'une association est égale à l'intersection des périodes de ré-
tention des entités participantes;
– la durée de rétention est exprimée par une condition impliquant une date ou un fait temporel, fré-
quemment associé à l'exécution d'une procédure (ex.: "pendant cinq années à compter du 1/1 de
l'année suivante", "jusqu'à la procédure de clôture annuelle").
1 Exemples : EIFFEL, SQL3.

3.4. Contraintes ensemblistes
Certaines contraintes définissent des relations — égalité, inclusion, exclusion, partition ... — qui doivent
exister entre certains ensembles d'occurrences dans la collection décrite par le schéma.
Exemples : – contrainte entre sous-types d'un même type (ex.: partition) :

invariant : {HOMME} ∪ {FEMME} = {PERSONNE} ;
invariant : {HOMME} ∩ {FEMME} = {∅} ;
– contrainte entre les rôles joués par une entité dans diverses associations :
LIVRAISON (COMMANDE exécutée-en 0:1, BORDEREAU accompagnant 1:1)
FACTURATION (COMMANDE facturée-en 0:1, FACTURE émise-pour 1:1)
invariant : {COMMANDE exécutée dans LIVRAISON}
= {COMMANDE facturée dans FACTURATION} ;
– contrainte entre plusieurs associations des mêmes entités :

COMPOSITION (EQUIPE composée-de 1:N, OUVRIER membre-de 1:1)
DIRECTION (EQUIPE dirigée-par 1:1, OUVRIER chef-de 0:1)
invariant : {DIRECTION} ⊆ {COMPOSITION} ;
3.5. Règles relatives à la valeur des attributs
a) Définition des domaines de valeurs
Tout domaine de valeurs doit être défini.
Domaine élémentaire
Un domaine élémentaire (ex.: PRIX, QUANTITE, NOM, NUMERO ...) est défini 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 décimal — en COBOL : PICTURE 9(6)V99
NOM CHAR(20) — en COBOL : PICTURE X(20)
Cette définition doit souvent être restreinte, soit sous la forme d'un intervalle, soit sous celle d'une liste de
valeurs discrètes qui est généralement 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 = féminin} ;

NOM-DE-MOIS = {"janvier"," février"," mars"...} ;
MOIS = {1..12} ;
JOUR = {1..31} ;
Rappel. Ne pas oublier de définir la codification des valeurs spéciales inexistant et inconnu.

Domaine structuré
Un domaine structuré est défini 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 mesurée 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) précis, la définition du domaine de valeurs d'un at-
tribut est parfois encore restreinte. Une telle règle est souvent perçue comme une condition particulière 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 liée à certains autres attributs ou à certaines associations.
Exemple 1 :
PERSONNE
no m
dat e n aissan ce
HOMME mari épouse FEMME

CONJOINT no m de jeune fille
0,1 dat e m ariage 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 ° clien t passant PASSATION
n om client
0,N dat e com m ande
adresse client
1,1
passée
comprenant COMMANDE
n ° co m m an de
LIGNE-COMMANDE 1,N
quan t it é com m andée facturée
0,N 0,1
PRODUIT
n° p ro duit
commandé
(1 ) n o m p ro duit FACTURATION
quan t it é en st o ck dat e fact ure
facturé
prix de v ent e
1,1
0,N LIGNE-FACTURE
quan t it é liv rée émise
m on t an t fact uré
1,N FACTURE
n° fact ure
comprenant
t o t al fact uré
concernant COMMANDE : après ENREGISTREMENT-COMMANDE :

n°-commande = n°-commande précédent + 1 ;
concernant COMMANDE : après REINITIALISATION-ANNUELLE :
n°-commande = 0 ;
concernant FACTURATION : invariant :
date-facture ≥ date-commande de PASSATION pour COMMANDE passée et facturée ;
concernant LIGNE-FACTURE : après EDITION-FACTURE :
quantité-livrée = MIN ( quantité-en-stock précédente de PRODUIT facturé,
quantité-commandée de LIGNE-COMMANDE
pour [COMMANDE comprenant et facturée
dans FACTURATION pour FACTURE comprenant,
PRODUIT commandé et facturé] ) ;
concernant LIGNE-FACTURE : après EDITION-FACTURE :
quantité-en-stock de PRODUIT facturé
= quantité-en-stock précédente de PRODUIT facturé – quantité-livrée ;
concernant LIGNE-FACTURE : invariant :
montant-facturé = prix-de-vente de PRODUIT facturé * quantité-livrée ;
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 spécifiques. Par exemple, il
est impossible de redevenir célibataire après avoir été marié. Pour exprimer ces règles, on distinguera les va-
leurs successives au moyen du qualificatif précédent.
Exemple : après mise à jour :

Etat-Civil précédent ≠ inexistant ⇒ Etat-Civil ≠ "célibataire" ;
après CLOTURE-MENSUELLE :
Budget-Résiduel = Budget-Résiduel précédent − Dépenses-Imputées ;

Alors que la seconde de ces règles est probablement utilisée par un programme de calcul, l'applica-
tion de la première relève de l'utilisateur du programme de mise à jour des données, et celui-ci doit en
contrôler l'application. Les programmes adopteront une attitude de compréhension "souple" devant
de telles contraintes : il faut, en effet, autoriser la correction des erreurs d'encodage !
REMARQUE. Les contraintes d’évolution peuvent être décrites au moyen de diagrammes de transitions
d’états.1
3.6. Définition sémantique des opérations
La définition sémantique d’une opération de traitement de données, particulièrement d’une opération caracté-
ristique d’un type d’objet, complète la spécification externe de cette opération.
Le complément de définition comporte
– explicitement :
– les pré-conditions rendant possible l’exécution correcte de l’opération,

– les post-conditions que l’exécution de l’opération doit rendre vraies;
– implicitement :
– les invariants attachés aux données ou objets résultats de l’opération.
Certaines de ces règles expriment une égalité; parmi elles se trouvent les règles de dérivation qui définissent
les créations ou transformations de données que l’opération doit accomplir.
Ainsi, pour définir la sémantique de l’opération d’édition d’une facture, il suffit de regrouper les contraintes
déjà formulées ci-dessus et, pour être complet, d’autres semblables :
après EDITION-FACTURE :
concernant LIGNE-FACTURE :
quantité-livrée = MIN ( quantité-en-stock précédente de PRODUIT facturé,
quantité-commandée de LIGNE-COMMANDE
pour [COMMANDE comprenant et facturée
dans FACTURATION pour FACTURE comprenant,
PRODUIT commandé et facturé] ) ;
quantité-en-stock de PRODUIT facturé
= quantité-en-stock précédente de PRODUIT facturé – quantité-livrée ;
invariant :
concernant FACTURATION :
date-facture ≥ date-commande de PASSATION pour COMMANDE passée et facturée ;
montant-facturé = prix-de-vente de PRODUIT facturé * quantité-livrée ;
concernant FACTURE :
total-facturé = Σ montant-facturé de LIGNE-FACTURE pour FACTURE comprenant ;
1 Cf. supra, § 2.3.

3.7. Formalisme pour l'expression des règles
Pour donner une idée du degré de précision souhaitable, sans toutefois nous encombrer des nombreuses
conventions d'un langage formel opérationnel, nous avons ci-dessus formulé les règles dans une ébauche de
langage formalisé, dont voici une brève définition.
a) La notion de règle
Une règle se présente sous la forme
[contexte :] portée : expression ;
L'expression cite des variables, c'est-à-dire des composants quelconques du schéma auquel la règle est atta-
chée : occurrences d'entités ou d'associations, attributs, collections d'occurrences.
Nous ne donnerons pas ici une liste exhaustive des opérations possibles. Il peut s’agir d’opérations
arithmétiques (+ − ∗ / Σ ...), ensemblistes (∪ ∩ ...), logiques (¬ ∧ ∨ ⊕ ⇔ ⇒ ∀ ∃ ...) ou de com-
paraison (= ≠ < > ≤ ≥ ∈ ⊂ ...) ... Il peut aussi s'agir d'un nom de fonction accompagné de ses para-
mètres (ex.: min(a,b) ...).
L'expression doit être vraie dans les circonstances précisées par la portée de la règle :
invariant l'expression doit être vraie à tout moment

avant procédure l'expression est une pré-condition de la procédure mentionnée
(l'exécution de la procédure est impossible sinon)
après procédure l'expression est une post-condition de la procédure mentionnée
(les post-conditions d'une opération en définissent le résultat)
L'indication facultative d'un contexte permet d'alléger la rédaction 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'intérieur d'une expression, un nom de type — d'entité, d'association, d'attribut — est employé pour dési-
gner un élément (occurrence) quelconque du type en question.
Dans les expressions, la désignation d'une variable peut être indicée et qualifiée :
variable [indice] [qualificatif ...]
L'indice précédent permet de distinguer les occurrences successives d'un même type d'élément.
Exemple : n°-commande précédent de COMMANDE

Les qualificatifs permettent de "naviguer" dans le schéma, c'est-à-dire de relier les éléments du schéma. Les
qualificatifs possibles sont les suivants :
Ent
attribut de entité attr
Ass
attribut de association attr
association pour entité rôle

rôle
Ass Ent
entité rôle dans association

rôle
Ent Ass
assoc1 pour entité rôle1 et rôle2 dans assoc2

rôle1 rôle2 Ass2
Ass1 Ent
assoc pour [entité1 rôle1 ... , entité2 rôle2 ..., ...]

rôle1 rôle2 Ent2
Ent1 Ass
– Les prépositions de – dans – pour sont interchangeables.

– Les noms de rôles peuvent être omis si cette omission ne rend pas la désignation ambiguë.
– La désignation d'une variable doit comporter autant de qualificatifs qu'elle en exige pour être univoque.
– Toutefois, le type indiqué comme contexte en tête de la règle peut compléter implicitement toute désigna-
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 rédaction des expressions, on pourra définir des variables intermédiaires, que les ex-
pressions pourront également référencer. Une variable intermédiaire est déclarée de la manière suivante :
soit variable = variable [si expression] ;
Exemple : soit COMMANDE-EN-ATTENTE

= COMMANDE si ¬ ∃ (FACTURATION pour COMMANDE) ;

c) Les ensembles
Une variable ensemble est dénotée en plaçant la désignation de la variable élément dans une paire d'accola-
des :
{variable}
Exemples : {FACTURE}
{n°-produit de PRODUIT}
{COMMANDE-EN-ATTENTE}
Les expressions peuvent en outre référencer des ensembles littéraux :
– liste d'éléments : {1,2,5,7} {"janvier","février",...}

– liste d'intervalles : {1..12,15..20}
– ensemble vide : {∅}
– ensemble nommé : nom de domaine, nom de variable intermédiaire
Remarque
Les schémas graphiques que nous utilisons définissent des types d'entités et d'associations; ils ne définissent
pas les types de collections. Pour définir un type de collection et lui attribuer un nom, on emploiera une règle
du genre de celles-ci :
Exemples : FICHIER-DES-CLIENTS = {CLIENT} ;

TABLE-DES-MOIS = {"janvier", "février", ...} ;
CODE-SEXE = {0, 1, 2} ;

4. Validation du schéma
Le premier jet d'un schéma de données doit être validé par un examen approfondi, ayant pour objet de lever
les ambiguïtés et contradictions, d'affiner et préciser la représentation de la réalité perçue, de contrôler les re-
dondances.
4.1. Suppression des incohérences
a) Correction des anomalies lexicographiques
Pour chaque définition, 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 précisé
en COMMANDE-DE-CLIENT et COMMANDE-A-FOURNISSEUR). On pourra cependant tolérer qu'un
nom d'attribut soit polysème (par exemple, "date-de-commande"), puisqu'il est naturellement qualifiable par
le nom du type d'objet qu'il décrit (ex.: date-de-commande de COMMANDE-A-FOURNISSEUR)..
b) Vérification des contraintes, Elimination des contradictions
Lors de l'élaboration d'un schéma de données, les questions les plus porteuses de renseignements sont celles
qui concernent les contraintes d'intégrité inhérentes au modèle : la connectivité des rôles et la composition
des identifiants minimaux. Il est donc utile de faire, sur ces questions, un second tour de piste.
On vérifiera en particulier qu'il n'existe pas de contradiction entre les connectivités indiquées et les contrain-
tes ensemblistes ou de durée de rétention. (On a déjà donné l'exemple suivant : si la durée de rétention des
COMMANDEs est limitée, la connectivité minimale du rôle de CLIENT dans le type d'association
PASSATION de COMMANDE ne peut pas être 1.)
4.2. Affinage du schéma
a) Normalisation des composants
Certains attributs peuvent cacher un type d'association.1 On cherchera alors à désagréger les types d'objets
possédant ces attributs, en explicitant le type d'association caché, pour autant que les compositions mises en
place enrichissent la sémantique ou diminuent la redondance. Pour ce faire, on recourra aux règles de nor-
malisation, dont les trois premières ont été établies par CODD, dans son modèle relationnel;2 ces règles font
usage du concept de dépendance fonctionnelle, défini 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 défini une quatrième et une cinquième formes
normales.

1NF (1st normal form) Un type d'entité ou d'association est en première forme normale si tous ses attributs
sont atomiques, c'est-à-dire simples (non répétitifs) et élémentaires (non structurés).
Si un attribut est à la fois répétitif et structuré, il s'agit presque certainement d'un type d'association déguisé.
Exemple : l'attribut "liste des résultats" d'examens d'un étudiant,

chaque indication de résultat comportant l'identification de la matière et la cote obtenue
ETUDIANT
n om
liste:
{résu lta t= ETUDIANT RESULTAT MATIERE
in titu lé,co te} no m 0,N 0,N int it ulé
co t e
Mais il n'y aurait certainement aucun apport à remplacer un attribut "liste des prénoms" par un type d'associa-
tion entre le type d'entité PERSONNE et un type d'entité PRENOM !
2NF (2nd normal form) Un type d'entité ou d'association est en deuxième forme normale s'il est en 1NF et
qu'en outre aucun attribut ne dépende fonctionnellement d'une partie seulement de ses identifiants.
Cette règle fait référence à 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 réalité un attribut d'un type d'entité (PRODUIT) associé
PRODUIT commandé LIGNE-COMMANDE comprenant COMMANDE

n ° p ro duit 0,N quan t it é co m m an dée 1,N n ° com m an de
n o m p ro duit p rix un ita ire
Mais si, dans le laps de temps séparant la réception et l'exécution 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 même nom — deux informations distinctes. Copier ainsi dans chaque LIGNE-
COMMANDE le prix unitaire en vigueur à la date de réception de la commande pourrait rendre superflue la
conservation d'un historique du tarif.
3NF (3rd normal form) Un type d'entité ou d'association est en troisième forme normale s'il est en 2NF et s'il
n'existe pas de dépendance fonctionnelle transitive par rapport à un de ses identifiants, c'est-à-dire s'il n'existe
pas d'attribut dépendant d'un autre, lui-même dépendant d'un identifiant.
Exemple : dans le type d'entité FACTURE,

les attributs "date de commande" et "numéro de client"
dépendent du "numéro de commande",
qui est lui-même déterminé par l'identifiant "numéro de facture"

CLIENT
n ° clien t
n o m clien t 0,N PASSATION 1,1 COMMANDE
n ° co m m ande
0,1
FACTURE
n° fact ure
n° co m m a n d e 1,1 FACTURATION
da te co m m a n d e
n° clien t
no m client
BCNF (Boyce-Codd normal form) Le déterminant de toute dépendance fonctionnelle à l'intérieur d'un type
d'objet, entité ou association, doit être un identifiant, primaire ou candidat, de cet objet.
Cette formule, due à Boyce, résume (et étend) les trois formes normales de Codd.
b) Spécialisation par sous-typage
La définition de sous-types produit une modélisation plus explicite et souvent plus rigoureuse.
Généralisations 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é défini par généralisation. Dans
ce cas, n'est-il pas indiqué de procéder à une modélisation plus explicite, en distinguant des sous-types ?
Exemple. Le catalogue d'une firme de vente signale pour certains produits seulement un délai de li-
vraison; il s'agit de produits que la firme ne garde pas en stock mais qu'elle achète à un fournisseur.
PRODUIT
n ° p ro duit
p rix de v en t e
PRODUIT
n ° p ro duit
p rix de v en t e
[d élai d e livra iso n]
HORS-STOCK
délai de liv raiso n
Associations conditionnelles
Un type d'association conditionnel, ne faisant intervenir un type d'entité que si un attribut de ce dernier pos-
sède une ou des valeur(s) particulière(s) n'est défini, en toute rigueur, que sur un sous-type de cette entité.
Exemple. Si le type d'association CONJOINT est simplement défini sur le type PERSONNE, une rè-
gle supplémentaire doit signifier la condition de différence de sexe; la modélisation suivante est plus
explicite.

PERSONNE
n om
dat e n aissan ce
HOMME mari épouse FEMME

CONJOINT n o m de jeun e fille
0,1 dat e m ariage 0,1
4.3. Simplification du schéma
a) Simplification des structures
Associations de degré élevé
Un type d'association de degré élevé reflète souvent un défaut d'analyse. On cherchera donc à le décompo-
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 dépendances fonctionnelles entre les différents rôles 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'entités associés.
Exemple : ENSEIGNEMENT (MATIERE dispensée-dans 1:N, CLASSE suivant 1:N,

– par son identifiant, la définition ci-dessus pose que
une matière enseignée à une classe donnée l'est par un seul professeur;
elle n'interdit pas qu'une matière soit toujours enseignée par le même professeur,
pour quelque classe que ce soit;
dans ce cas, la définition devrait devenir la suivante :
suivant
CLASSE 1,N PROGRAMME 1,N
suivie
MATIERE
enseignée
titulaire 1,1
PROFESSEUR 1,N ENSEIGNEMENT
Compositions de connectivités 1:1
La propriété d'équivalence sémantique énoncée plus haut sera exploitée pour simplifier les compositions ne
comportant que des connectivités 1:1, particulièrement si ces compositions comprennent des types d'associa-
tions vides d'attributs.
LIGNE
COMMANDE 1,N COMPOSITION 1,1 1,1 CONCERNE 0,N PRODUIT
COMMANDE

b) Contrôle des structures redondantes
L'élaboration d'un schéma de données peut avoir défini 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 sémantique 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 fréquentes.
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, sémantiquement plus riche.
EMPLOYE occupé
n ° m at ricule 1,1 OCCUPATION 1,Noccupant DEPARTEMENT
n ° dép art em ent
n ° d ép a rtem ent
Deux types d'associations définis sur les mêmes types d'entités avec les mêmes connectivités doivent être sus-
pectés de redondance. Cette situation peut, en particulier, résulter de la simplification, évoquée plus haut, des
compositions utilisant des connectivités 1:1.
Un type d'association, probablement vide d'attributs, peut s'avérer n'être que le "résumé" d'une composition
de plusieurs associations. On conservera la composition, sémantiquement plus riche.
0,N COMMANDE
0,1
LIVRAISON FACTURATION
1,1
1,1
BORDEREAU FACTURE
1,1 ACCOMPAGNEMENT 1,N
c) Cas particulier : les attributs dérivables
Un attribut dérivable est un attribut dont la valeur peut être à tout moment déterminée, le plus souvent par
calcul, à partir de la valeur d'autres attributs. Ainsi, l'attribut "prix facturé" est dérivable des attributs "prix de
vente unitaire" et "quantité livrée" si ces deux derniers sont disponibles à tout instant de la période de réten-
tion du premier et l'attribut "montant total" de la facture est dérivable à partir des "prix facturés" détaillés.
Dans une collection d'informations enregistrées, la présence d'un attribut dérivable est une redondance com-
pliquant les opérations de mise à jour : soit un attribut R dont la valeur peut être obtenue à partir d'une série
d'attributs Di; lors de tout changement de valeur d'un des attributs Di, la valeur de R doit être également modi-
fiée. En revanche, la description d'une collection d'informations communiquées par un document doit men-
tionner les attributs dérivables, dont l'utilité spécifique est toujours d'améliorer la lisibilité du document.
Remarque. Dans les diagrammes UML, le nom d'un attribut dérivable est préfixé d'une barre oblique /.

4.4. Note sur les sous-schémas
Un sous-schéma constitue une sélection parmi les types d'objets répertoriés dans le schéma global de la base
de données : certains types d'entités, certains types d'associations et même certains attributs dans les types
d'objets retenus sont masqués.
En outre, les types d'objets conservés sont quelquefois transformés, de manière à pallier l'absence des objets
masqués. On notera en particulier :
– la transformation d'un type d'association en type d'entité, si un des types d'entités participants est masqué;
– l'incorporation à un type d'entité, en guise d'attributs, des identifiants des types d'associations masqués;
– l'incorporation des éléments permettant de déterminer la valeur des attributs dérivables, si ces éléments ap-
partiennent aux objets masqués.
CLIENT FACTURE
n° client passant PASSATION n ° fact ure
0,N dat e com m an de
no m client t ot al fact uré
adresse client d a te fa ctu re
1,1 n ° clien t
n o m clien t
passée
a d resse client
COMMANDE
comprenant n ° co m m an de 1,N
1,N
LIGNE-COMMANDE objet de
quan t it é co m m an dée CORPS
0,N 0,1 FACTURE
PRODUIT
n ° produit
commandé
FACTURATION 1,1
(1) n om produit dat e fact ure
quan t it é en st ock LIGNE
facturé
p rix de v en t e
1,1 FACTURE
0,N LIGNE-FACTURE
quan t it é liv rée
pour m on t ant fact uré
quan t it é liv rée
qu a ntité co m m an d ée
m on t ant fact uré FACTURE
1,N n° p ro du it
n° fact ure no m p ro du it
comprenant t o t al fact uré prix d e ven te

5. Validation du système de règles
5.1. Complétude du système de règles
Il est nécessaire de procéder à une vérification systématique de la complétude du système de règles associé au
schéma de données. Tout particulièrement du sous-système des règles de dérivation, dont le caractère faisa-
ble doit ainsi être certifié.
Appelons donnée primaire toute variable (élémentaire ou ensemble) dont la valeur n'est pas "à calculer",
mais "reçue"; appelons résultat toute variable (élémentaire ou ensemble) dont la valeur est "à calculer" par
l'application d'une règle de dérivation.
Pour chaque règle énoncée, on vérifiera les points suivants :
– pour chaque règle exprimant une égalité, on statuera sur le point de savoir si elle constitue une condition de
validité (1V) ou une règle de dérivation (1D) (elle peut avoir les deux usages, mais dans des contextes
différents);
– toutes les variables référencées par la règle sont-elles inventoriées (2) dans le schéma des données ?
– toute variable référencée est-elle une donnée primaire (3P) ? sinon, existe-t-il une règle de dérivation
dont elle soit le sujet (3D) ?
– toutes les variables mentionnées dans la règle sont-elles qualifiées de manière univoque (4) ?
Il va de soi que ces vérifications impliquent l'emploi d'annotations : on "marquera" chaque règle et chaque
variable ayant subi avec succès chacun des examens ci-dessus, par exemple, au moyen des numéros indiqués
entre parenthèses dans le texte de l'alinéa précédent.
5.2. Cohérence du système de règles
Deux règles sont redondantes si elles expriment, dans des formes différentes, la même relation. On notera le
cas particulier de la permutation des parties gauche et droite d'une égalité.
Le système de règles doit être exempt de contradictions. Ceci est aisément vérifiable pour les règles expri-
mant une égalité : si plusieurs règles d'égalité non redondantes concernent le même sujet, elles doivent avoir
des portées mutuellement exclusives.

6. En guise de conclusion
6.1. Recommandations diverses
Les auteurs de la méthode OMT formulent les recommandations suivantes. [La première fois qu'un terme
propre à la méthode OMT est employé, nous indiquons entre crochets son équivalent dans la terminologie du
modèle Entité–Association.]
• Ne commencez pas à construire un modèle objet [schéma Entité–Association] en jetant pêle-mêle

classes [types d'entités], associations et héritage [sous-typage]. Vous devez avant tout compren-
dre le problème à résoudre. Le contenu d'un modèle objet est conditionné par la pertinence de la
solution.
• Efforcez-vous de garder votre modèle simple. Evitez les complications inutiles.
• Choisissez les noms avec soin. Ils sont importants et portent des connotations puissantes. Ils doi-
vent être descriptifs, précis, sans ambiguïté 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 délicates de la modélisation des
objets.
• N'enfouissez pas des pointeurs ou des références d'objets [identifiants étrangers] dans les objets
en tant qu'attributs. Modélisez-les plutôt comme des associations. C'est plus clair et cela saisit la
véritable intention plutôt qu'une approche particulière d'implémentation.
• Evitez si possible les associations ternaires et n-aires. La plupart de celles-ci peuvent être décom-
posées en associations binaires, éventuellement avec [...] des attributs de lien [attributs d'associa-
tion].
• N'essayez pas d'exprimer parfaitement les multiplicités [connectivités] trop tôt dans le dévelop-
pement.
• Ne dissolvez pas les attributs de lien [attributs d'association] dans une classe [type d'entités].
[...]
• Essayez d'éviter les généralisations profondément imbriquées.
• Reconsidérez les associations un-à-un. Souvent l'objet à chaque extrémité est optionnel et une
multiplicité zéro-ou-un peut être plus appropriée. A d'autres moments, une multiplicité "plusieurs"
sera nécessaire.
• Ne soyez pas surpris que votre modèle objet ait besoin d'une révision. Il faut souvent de multiples
itérations pour clarifier les noms, réparer les erreurs, ajouter des détails et prendre correctement en
compte les contraintes structurelles. Plusieurs de nos modèles les plus complexes, qui sont seule-
ment longs de quelques pages, ont nécessité une demi-douzaine d'itérations.
• Soumettez votre modèle à des avis extérieurs. Le modèle objet peut susciter l'intérêt d'autres per-
sonnes et mener à une implication plus large de leur part.

• Documentez systématiquement vos modèles objet. Le diagramme spécifie la structure d'un mo-
dèle mais ne peut préciser les raisons qui ont présidé aux divers choix. L'explication écrite guide
le lecteur à travers le modèle et explique les raisons subtiles pour lesquelles il a été structuré de
cette façon. Les explications écrites clarifient la signification des noms dans le modèle et peuvent
porter la raison d'être de chaque classe et de chaque relation. 1
6.2. Documentation du schéma
C'est à dessein que nous avons, ci-dessus, souligné le dernier paragraphe. Chaque nom (d'entité, d'associa-
tion, d'attribut ...) apparaissant dans un schéma est le résumé d'une ou plusieurs discussions avec différents
interlocuteurs. La documentation accompagnant un schéma doit reproduire le contexte duquel est issu chaque
nom, avec sa richesse et son "épaisseur sémantique".
Empruntons aux mêmes auteurs l'exemple suivant, limité à la définition des types d'entités. Le problème ana-
lysé est celui du réseau de Guichets Automatiques Bancaires (GAB) d'un consortium de banques.
Compte — Compte unique dans une banque, sur lequel les transactions sont appliquées. Les
comptes peuvent être de diverses sortes, comme des comptes chèques ou des comptes épargne. Un
client peut détenir plus d'un compte.
GAB — Station à partir de laquelle les clients peuvent réaliser eux-mêmes leurs transactions en
utilisant des cartes bancaires pour s'identifier. Le GAB interagit avec le client pour récupérer les
informations de la transaction, les émet vers l'ordinateur central pour validation et traitement, puis
délivre les billets. Nous supposons que le GAB ne peut pas fonctionner sans le réseau.
Banque — Institut financier qui gère les comptes des clients et délivre les cartes bancaires autori-
sant l'accès aux comptes par le réseau des GAB.
Ordinateur de banque — Ordinateur appartenant à une banque, réalisant l'interface avec le ré-
seau des GAB et les stations propres à la banque. Une banque peut détenir son propre réseau d'or-
dinateurs pour gérer ses comptes, mais nous ne nous intéressons qu'à celui faisant l'interface avec le
réseau des GAB.
Carte bancaire — Carte délivrée par une banque à ses clients, leur permettant l'accès à leur pro-
pre compte à l'aide des GAB. Chaque carte comporte un code bancaire et un numéro de carte, ces
derniers étant codés pour respecter les standards nationaux sur les cartes bancaires et de crédit. Le
code bancaire identifie la banque à l'intérieur du consortium. Une carte ne permet pas nécessaire-
ment l'accès à tous les types de comptes du client. Chaque carte de crédit est détenue par un client
unique, mais plusieurs copies d'une même carte peuvent exister; les accès simultanés par une même
carte doivent donc être pris en considération.
Caissier — Employé d'une banque qui est autorisé à effectuer des transactions à partir des agences
bancaires. Il accepte et délivre argent et chèques au client. Les transactions, l'argent et les chèques
manipulés par un caissier doivent être enregistrés.
Agence bancaire — Agence où un caissier peut réaliser des transactions pour un client. Le cais-
sier accepte des chèques et de l'argent du client et lui en délivre également; des reçus sont impri-
més. L'agence est en communication avec l'ordinateur de la banque pour valider et traiter les tran-
sactions.

Ordinateur central — Ordinateur appartenant au consortium, et gérant les transactions entre les
GAB et les ordinateurs des banques. L'ordinateur central valide les codes bancaires mais ne traite
pas les transactions lui-même.
Consortium — Organisation de banques qui gère le réseau des GAB. Ce réseau ne traite que les
transactions des banques du consortium.
Client — Détenteur d'un ou de plusieurs comptes dans une banque. Un client peut consister en une
ou plusieurs personnes ou une entreprise; la différence est sans importance pour ce problème. La
même personne possédant des comptes dans différentes banques est considérée comme plusieurs
clients.
Transaction — Requête complète unique pour réaliser des opérations sur un compte. La spécifi-
cation du GAB n'indique que la possibilité de délivrer de l'argent, mais nous pourrions considérer la
possibilité d'imprimer des chèques, d'accepter de l'argent ou des chèques. Nous pourrions prévoir
aussi la possibilité d'opérer sur les comptes de clients différents, bien que ce ne soit pas demandé ici.
Les différentes opérations doivent avoir des soldes équilibrés. 1
Le processus d'analyse est long et itératif ... La dernière définition ci-dessus montre que, tout au long
de son élaboration, un dossier d'analyse contient des définitions provisoires ("nous pourrions prévoir
aussi ..."), sur lesquelles l'analyste devra revenir ...
Aux suggestions implicites des exemples ci-dessus, ajoutons celles-ci.
• Lorsque c'est possible, la notice décrivant un type d'objet, entité ou association, reprendra la défi-
nition juridique ou réglementaire de la notion décrite.
• Cette notice définira, sans ambiguïté, les conditions d'existence (entrée et sortie) d'une occur-
rence du type décrit dans l'ensemble modélisé (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 1er janvier écoulé").
• La définition d'un type d'association mentionnera nécessairement chaque type d'entité associé et
comportera généralement un commentaire des connectivités. Exemple : "pour une commande, une
LIGNE DE COMMANDE représente la quantité commandée d'un produit; toute commande com-
prend au moins une ligne de commande".
• La définition détaillée d'un attribut n'est utile que si elle apporte un complément aux renseigne-
ments fournis par le nom de cet attribut qui, normalement, en identifie le domaine de valeurs et le
rôle dans la description de l'objet.
Enfin, tout élément 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 définition du concept (type) et de la mise
à jour des valeurs (occurrences) ?
– à qui cette information est-elle destinée ou distribuée ?
– quels sont les aspects historiques de l'information : durées de vie et de rétention, transitions
d'états ?

Chapitre 4. Schéma logique du stockage des données
Un schéma de stockage des données doit rendre compte des types d'objets stockés. La définition du contenu
sémantique d'un schéma de stockage constitue un schéma logique des données. Les types d'objets d'une
structure de stockage seront définis par transformation du schéma conceptuel.
Le schéma logique des données doit être complété par celui des fonctions d'accès nécessaires aux applica-
tions utilisatrices.
La dernière section de ce chapitre montre en quoi le schéma logique du stockage des données constitue un
support de la programmation, avec application particulière au langage COBOL.
© A. CLARINVAL Analyse — Schéma logique 4-1

1. Schéma des structures de stockage : le modèle en Réseau
1.1. Eléments d'une structure de stockage
Un enregistrement (ou article) est un espace du support de stockage, accessible en tant qu'occurrence dis-
tincte. La définition sémantique d'un type d'enregistrement découle de la transposition d'un type d'entité ou
d'association.
La réinterprétation des rôles définis dans le schéma Entité–Association résulte en la déclaration de liaisons
entre enregistrements. Le concept de liaison sera précisé plus loin.
Un enregistrement est découpé en champs. Un champ contient l'inscription d'une valeur. La définition sé-
mantique d'un champ équivaut à celle d'un attribut.
1.2. Transformation du schéma Entité–Association
Nous illustrons ici une méthode simple pour transformer en réseau un schéma Entité–Association.
Soit le sous-schéma conceptuel suivant.

abonné à CLIENT
PRIVE
ABONNEMENT 1,N
CLIENT
0,N n° client
PROSPECTUS envoyé à nom client
t ype prospectus adresse client
CLIENT passant
PROFESSIONNEL
contacté par n° T VA
0,N
1,1
PASSATION
CONTACT dat e com m ande
0,N
REPRESENTANT 1,1
nom représent ant contactant
passée
région
chiffre d'affaires COMMANDE
comprenant n° com mande
LIGNE-COMMANDE
quant it é com mandée
1,N objet de
0,N
PRODUIT 0,1
n° produit commandé
(1) nom produit FACTURATION
quant it é en stock facturé dat e facture
prix de vente
1,1
0,N
LIGNE-FACTURE
quantité livrée 1,N
montant fact uré
pour
FACTURE
comprenant n° fact ure
t ot al facturé
La firme entretient un contact régulier avec ses clients. Un client professionnel est contacté par un représen-
tant. Un client privé est contacté par prospectus; il peut être "abonné" à différents types de prospectus et
une règle veut qu'il soit, à tout moment, "abonné" à un prospectus au moins.
La transformation de ce schéma comporte les opérations suivantes.
1) Orienter les arcs représentant les rôles, par une flèche dans le sens Association → Entité ou sous-type
→ sur-type. Chaque flèche représente un type de liaison. Le type d'objet (Entité) situé à la pointe de la flè-
che est propriétaire de la liaison; le type d'objet (Association) situé à l'origine de la flèche est membre de
la liaison.

abonné à CLIENT
PRIVE
ABONNEMENT 1,N
CLIENT
0,N n° client
PROSPECTUS envoyé à nom client
t ype prospect us adresse client
CLIENT passant
PROFESSIONNEL
contacté par
n° T VA 0,N
1,1
PASSATION
CONTACT date com mande
0,N
1,1
REPRESENTANT
nom représentant contactant
passée
région
chiffre d'affaires COMMANDE
comprenant n° comm ande
LIGNE-COMMANDE
quant it é com mandée
1,N objet de
0,N
PRODUIT 0,1
(1) nom produit FACTURATION
quant ité en stock facturé date fact ure
prix de vent e
1,1
0,N
LIGNE-FACTURE
quant ité livrée 1,N
mont ant fact uré
pour
FACTURE
comprenant n° facture
total fact uré
2) Indiquer la connectivité 0:1 sur les liaisons de sous-typage, c'est-à-dire sur les flèches dépourvues de
cette indication.
CLIENT
0,1
PRIVE
CLIENT
n° client
nom client
adresse client
CLIENT
0,1
PROFESSIONNEL
n° T VA

3) Fusionner en un seul type d'enregistrement les types d'objets liés par une liaison de connectivité 1:1,1 en
conservant pour nom du type d'enregistrement, un nom de type d'entité.
abonné à CLIENT 0,1

PRIVE
ABONNEMENT 1,N
0,N CLIENT
n° client
PROSPECTUS envoyé à
nom client
t ype prospect us
adresse client
CLIENT passant
PROFESSIONNEL 0,1
n° T VA
CONTACT
0,N
0,N
PASSATION
REPRESENTANT dat e com m ande
nom représentant
contactant
région COMMANDE
chiffre d'affaires comprenant n° com mande
LIGNE-COMMANDE
quant ité com mandée
1,N
0,N
objet de
PRODUIT
(1) nom produit
quantité en stock facturé
prix de vent e 0,1
0,N
LIGNE-FACTURE FACTURATION
quant it é livrée date fact ure
mont ant facturé 1,N
FACTURE
comprenant n° fact ure
t ot al facturé
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 propriétaire.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'après le schéma suivant : nom de l'attribut –
nom du type propriétaire – qualificatif de la liaison.
1 Théoriquement, cette fusion pourrait se limiter à faire disparaître les types d'associations sans attributs.
2 En toute rigueur, cette transformation, qui crée de la redondance, est ici prématurée. D'ailleurs, certains
systèmes de stockage (les bases de données CODASYL) n'y ont pas recours. Elle devrait s'opérer plus tard,
lors de l'élaboration du schéma physique des systèmes de stockage qui l'exigent, comme les fichiers COBOL
ou les bases de données relationnelles. C'est parce que nous n'aborderons plus de manière systématique les
problèmes de transformation des schémas de données que nous citons ce point dès ici.

CLIENT
abonné à 0,1
PRIVE
ABONNEMENT 1,N n° client
0,N CLIENT
type prospectus n° client
PROSPECTUS envoyé à n° client nom client
t ype prospect us
adresse client
CLIENT passant
PROFESSIONNEL 0,1
n° T VA
CONTACT
0,N
0,N n° client
nom représentant
PASSATION
REPRESENTANT dat e com m ande
nom représentant
contactant
région COMMANDE
chiffre d'affaires comprenant n° com mande
LIGNE-COMMANDE n° client
quant ité com mandée
1,N
0,N
PRODUIT objet de
n° com m ande
n° produit commandé n° produit
(1) nom produit
quantité en stock facturé
prix de vent e 0,1
0,N
LIGNE-FACTURE FACTURATION
quant it é livrée date fact ure
mont ant facturé 1,N
FACTURE
n° facture comprenant n° fact ure
n° produit t ot al facturé
n° com m ande
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 néanmoins conservé si l'on souhaite constituer une liste des identifiants valides (identi-
fiants autorisés pour les enregistrements ABONNEMENT).
1.3. Commentaires sur le concept de liaison
Le concept de liaison est le concept central du modèle présenté ici. Ce modèle en réseau est dû à l'Américain
BACHMAN, qui le créa dès 1963 pour supporter un système de "stockage intégré des données" ("IDS, Inte-
grated Data Store"), ancêtre des systèmes de gestion de bases de données. En 1970, CODASYL, organisme
créateur du langage COBOL, l'a adopté comme base de sa proposition de standard pour les bases de données.
Depuis lors, dans la variante mise au point par J. MARTIN dans sa méthode IEM ("Information Engineering
Methodology"), il joue également, dans les régions anglophones, le rôle de modèle de conception, que les
francophones assignent plutôt au modèle Entité–Association.1

a) Terminologie
Dans les bases de données CODASYL, une liaison est réalisée sous la forme d’un ensemble ("set") d’enre-
gistrements interconnectés, 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 propriétaire d'un ensemble
{ai} dont les membres ou éléments sont les occurrences de A liées à e. L'ensemble {ai} peut contenir un nom-
bre quelconque d'éléments ou membres, c'est-à-dire d'occurrences de A, y compris 1 ou 0 (ensemble singleton
ou vide).
E e1 e2
a1 a2 a3
A
Selon une autre terminologie, dans une liaison E ← A, E est père ou parent, A est fils ou enfant.
Dans un schéma en réseau, un enregistrement peut être membre de différents types de liaisons, un enfant peut
avoir plusieurs parents.1 Dans notre exemple, chaque LIGNE-DE-COMMANDE Lij possède deux parents :
une COMMANDE Ci et un PRODUIT Pj.
C1 C2
L11
P1
L21
L12
P2
L22
b) Contraintes définies sur les liaisons
Liaison obligatoire ou facultative
Les liaisons E–propriétaire ← A–membre définies à ce stade de la transformation sont obligatoires, en ce sens
qu'elles mettent en jeu toujours une (1:1) occurrence de E propriétaire (il est obligatoire pour toute occur-
rence de A d'être liée à une occurrence de E). On verra plus loin que l'on peut définir des liaisons facultati-
ves, mettant en jeu au plus une (0:1) occurrence de E propriétaire (il est facultatif pour une occurrence de A
d'être liée à une occurrence de E).
Connectivité d'un type de liaison
Dans un schéma Entité–Association, l'orientation d'un rôle E(ntité) ← A(ssociation) est évidente, du fait de la
nature différente des deux extrémités E et A : type d'entité et type d'association. Dans le schéma en réseau, ce
n'est plus le cas et l'orientation de la liaison est indiquée au moyen des connectivités.
1Nous verrons plus loin l'utilité de définir des sous-schémas arborescents, dans lesquels tout enfant possède
un seul parent.

La connectivité [min..max] mentionnée à chaque extrémité de l'arc représentant un type de liaison indique à
combien d'occurrences d'enregistrements de cette extrémité est relié chaque enregistrement du type situé à
l'extrémité opposée.
Voici les conventions graphiques, d'usage fort répandu, de la méthode Information Engineering :
– le nombre 0 est représenté par un cercle O

(omis par plusieurs représentations parce que pris pour valeur minimale par défaut)
– le nombre 1 est représenté par un trait |
– le nombre N est représenté par une fourche /|\
ABONNEMENT CLIENT
CL.PRIVE est
¥ n° client n° client
type prospectus abonné ¥ n° client nom client
adresse client
est
CL.PROFESSIONNEL passant
¥ n° client
REPRESENTANT n° T VA
nom représentant ¥ nom représentant
contactant
région
COMMANDE
chiffre d'affaires
comprenant n° commande
LIGNE COMMANDE date commande
¥ n° commande ¥ n° client
¥ n° produit
PRODUIT commandé objet
quantité commandée
n° produit
<1> nom produit
quantité en stock LIGNE FACTURE
prix de vente facturé ¥ n° facture
FACTURE
¥ n° produit
n° facture
quantité livrée
comprenant ¥ n° commande
montant facturé
date facture
total facturé
Sur une liaison, le losange ♦ est placé du côté du type membre.

Le préfixe ¥ signale un identifiant étranger.
La connectivité 1:1 attachée au propriétaire d'une liaison obligatoire est parfois laissée à l’état implicite.
c) Interprétation d'une liaison comme étant une association
Bien qu'il ne soit pas issu d'un type d'association du schéma Entité–Association, mais d'un rôle, un type de
liaison peut être regardé comme un type d'association qui possède les propriétés 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 asymétrique : sa représentation est celle d'un rôle orienté E(ntité) ← A(ssociation);
1 Historiquement, c'est pour généraliser le concept d'association, en supprimant les restrictions qui lui sont
imposées ici, qu'ont été développés les modèles Entité–Association étudiés au chapitre précédent.

– 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 décrit par la connectivité héritée
du schéma 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 représentation d'un schéma en réseau.2
1.4. Optimisation du schéma
En vue de simplifier les séquences d'opérations d'accès qui seront nécessaires à l'exécution 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 agrégés. Ces transformations sont l'inverse de certaines
transformations — sous-typage et normalisation — effectuées lors de la validation du schéma conceptuel.
Cependant, le détour n'est sans doute pas inutile : les désagrégations préalablement opérées sur le schéma
conceptuel, qui avaient pour ambition d'aider l'analyste à affiner et préciser sa perception de la réalité, garan-
tissent que les agrégats réintroduits ici ne sont pas des erreurs dues à un défaut d'analyse.
Chaque optimisation effectuée entraîne l'obligation de formuler — et, plus tard, de programmer — de nouvel-
les règles ou contraintes d'intégrité.
a) Généralisation
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 généralisation, inverse de
l'opération de spécialisation (ex.: fusion des deux sous-types de clients dans le sur-type CLIENT).
Les attributs à l'origine attachés au membre d'un telle liaison sont incorporés au propriétaire, où ils peuvent
prendre la valeur "inexistant"; cette nouvelle contrainte doit être notée dans une règle. De plus, les connecti-
vités de toutes les liaisons qui impliquaient le type d'enregistrement (membre) disparu sont modifiées : la
connectivité minimale décrivant la participation de tout type d'enregistrement lié au membre disparu est rame-
née à 0 — la condition de rattachement doit également être notée dans une règle. 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 propriétaire (ex.: REPRESENTANT) à une
telle liaison devient facultative (connectivité 0:1 plutôt que 1:1);
– dans toute liaison dont le type d'enregistrement disparu (ex.: CLIENT-PRIVE) était propriétaire, la parti-
cipation du membre (ex.: ABONNEMENT) devient facultative, avec une connectivité 0:N au lieu de 1:N.
1 Dans le modèle 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.

ABONNEMENT CLIENT
¥ n° client n° client
type prospectus abonné nom client
adresse client
catégorie
REPRESENTANT CL.PRIVE
nom représentant CL.PROFESSIONNEL
région contactant n° TVA
chiffre d'affaires ¥ nom représentant
Remarque. Dans le type d'enregistrement résultant d'une telle fusion, on incorpore souvent un attribut redon-
dant, un indicateur de catégorie, signalant "rapidement" à quel(s) sous-type(s) appartient chaque occurrence.
Un tel attribut est qualifié de discriminant.
En réduisant les nombres d'enregistrements et de liaisons, le procédé de généralisation réduit la complexité de

la base de données.
b) Dénormalisation
On peut réintroduire dans le schéma une certaine redondance, en procédant à des dénormalisations, dont les
différentes formes sont décrites ci-après.
Ces optimisations ont pour but de simplifier et accélérer les opérations de consultation dans la base de don-
nées. Mais elles compliquent les opérations de mise à jour.
Propagation parent ==> enfants
La dénormalisation la plus fréquente consiste à copier dans l'enregistrement membre (ou enfant) d'une liaison
un attribut non identifiant de l'enregistrement propriétaire (ou parent).
Les exemples suivants pourraient se justifier.
Une firme doit facturer ses livraisons, généralement effectuées au bout d'un délai, 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 entraîner l'économie d'une gestion historique des ta-
rifs.
En recopiant dans l'enregistrement FACTURE l'identifiant étranger "numéro de client" pris dans l'enregis-
trement COMMANDE, on crée une liaison directe CLIENT ← FACTURE, économisant le détour par la
commande : le grand-parent peut être consulté sans détour par le parent.

CLIENT
ABONNEMENT n° client
¥ n° client abonné nom client
type prospectus adresse client
catégorie
CL.PRIVE
CL.PROFESSIONNEL
n° TVA
REPRESENTANT ¥ nom représentant
contactant
nom représentant
région passant
chiffre d'affaires
COMMANDE
LIGNE COMMANDE comprenant n° commande
¥ n° commande date commande
¥ n° produit ¥ n° client
PRODUIT commandé quantité commandée
n° produit objet
prix de vente
<1> nom produit
quantité en stock
prix de vente facturé LIGNE FACTURE
¥ n° facture
FACTURE
¥ n° produit n° facture
quantité livrée date facture
montant facturé comprenant total facturé
¥ n° commande
¥ n° client
Soit δ la donnée copiée du parent dans l'enfant. Toute modification de δ dans un enregistrement parent doit
être propagée, c'est-à-dire répétée, dans les enregistrements enfants (généralement multiples !). Dans les en-
registrements enfants, l'attribut δ doit être non modifiable, sauf par l'opération précédente.
Dérivation parent(s) ==> enfants
Le mécanisme de propagation est en réalité une forme simplifiée de dérivation, méthode par laquelle la valeur
d'un attribut dans un enregistrement enfant est obtenue (calculée) à partir de celle d'autres attributs dans un
ou plusieurs enregistrements parents.
PRODUIT LIGNE FACTURE

n° produit ¥ n° facture
<1> nom produit ¥ n° produit
quantité en stock facturé quantité livrée
prix de vente montant facturé

Les remarques faites ci-dessus au sujet du cas particulier de la propagation sont applicables au cas général de
la dérivation.
Récapitulation enfants ==> parent
A un enregistrement parent, on peut incorporer un attribut dérivable à partir de valeurs contenues dans l'en-
semble des enregistrements enfants.
FACTURE
LIGNE FACTURE
n° facture
¥ n° facture comprenant
date facture
¥ n° produit
total facturé
quantité livrée
¥ n° commande
montant facturé
¥ n° client
Soit Σ la donnée calculable dans l'enregistrement parent et δ la donnée considérée dans l'enregistrement en-
fant. Toute modification de δ dans un enregistrement enfant doit entraîner un nouveau calcul de Σ dans l'en-
registrement parent. Dans l'enregistrement parent, Σ est un attribut non modifiable, sauf par l'opération précé-
dente.
Deux types d'algorithmes sont à envisager pour recalculer Σ.
– Si tous les enfants d'un même enregistrement parent sont créés ou modifiés en une seule transaction, les
valeurs δ peuvent être cumulées en mémoire centrale, et un seul accès à l'enregistrement parent est effectué au
moment de conclure la transaction.
– Dans le cas où les différents enfants sont créés ou mis à jour à des époques dispersées, toute mise à jour
d'un enregistrement enfant s'accompagne d'un accès à 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 disparaître la liaison. Par exemple : fusionner en un seul les enregistre-
ments COMMANDE et LIGNE-COMMANDE. Les membres de la liaison deviennent des attributs répétitifs.
Ce procédé ne respecte pas la 1ère forme normale définie par CODD, et présente deux inconvénients : l'impos-
sibilité habituelle de définir un nombre fixe d'occurrences dans le vecteur d'attributs répétitifs et l'impossibilité
de créer une base de données relationnelle et manipulable par les langages de requêtes.
1.5. Structures particulières
a) Enregistrement d'intersection
Un enregistrement d'intersection est la traduction d'une association sans attributs, dont tous les rôles ont la
connectivité maximale N. Les seuls champs présents dans un tel enregistrement sont les identifiants (étran-
gers) des enregistrements auxquels il est lié.
Exemple : une école est abonnée à différentes revues; une liste de diffusion mentionne les professeurs à qui
les revues doivent être communiquées en lecture.

Ent/Ass
REVUE transmise lecteur PROFESSEUR
t it re DIFFUSION nom
0,N 0,N
UML
REVUE transmise DIFFUSION lecteur PROFESSEUR
t it re nom
0..* 0..*
IEM
DIFFUSION lecteur
REVUE transmise PROFESSEUR
titre ¥ nom lecteur
nom
¥ titre revue
b) Liaison cyclique
Une liaison peut être cyclique, c'est-à-dire définie sur un seul type d'enregistrement.
Soit le schéma Entité–Association suivant :
mère
SOCIETE 0,N
raison sociale DEPENDANCE
siège social 0,1
filiale
Après incorporation des identifiants étrangers, l'association cyclique de DEPENDANCE prend la forme d'un
enregistrement d'intersection :
SOCIETE mère DEPENDANCE

raison sociale ¥ raison sociale filiale
siège social filiale ¥ raison sociale mère
Après fusion du membre DEPENDANCE, de connectivité 0:1, dans le type propriétaire FILIALE, le schéma
montre une liaison facultative :1
SOCIETE
raison sociale mère
siège social
¥ [raison sociale mère]
1 Dans le modèle CODASYL, cette transformation n'est pas possible, car ce modèle n'admet pas les types de
liaisons cycliques.

1.6. Contraintes d'intégrité
a) Reformulation des règles
Non seulement les dénormalisations impliquent la définition de nouvelles contraintes d’intégrité, mais les rè-
gles (contraintes d'intégrité) déjà formulées dans le contexte du schéma Entité–Association doivent recevoir
une nouvelle formulation qui tienne compte des autres modifications apportées au schéma.
On notera d'abord que les contraintes exprimées par rapport aux rôles dans le schéma Entité–Association s'ap-
pliquent automatiquement aux types de liaisons qui en dérivent.
Soit la règle : date-facture de FACTURATION ≥ date-commande de PASSATION pour COMMANDE passée

et facturée dans FACTURATION. Lors de la transformation du schéma, les associations PASSATION et
FACTURATION ont été incorporées aux enregistrements COMMANDE et FACTURE; ce faisant, les rôles
COMMANDE passée et FACTURE émise ont disparu. Les adaptations suivantes doivent être apportées dans
le système de règles associé au schéma :
– redéfinir comme une variable intermédiaire tout type d'objet disparu par absorption (l'expression de défi-
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 règles, supprimer toute mention des rôles 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.
LIGNE COMMANDE COMMANDE

comprenant
¥ n° commande n° commande
¥ n° produit date commande
quantité commandée ¥ n° client
Aux deux extrémités de la liaison, les connectivités minimales sont 1 (1:1 et 1:N). Cette contrainte signifie
qu'aucune LIGNE-COMMANDE ne peut être enregistrée si elle ne peut être reliée à une COMMANDE pré-
existante et qu'aucune COMMANDE ne peut être acceptée si elle ne peut être reliée à au moins une LIGNE-
COMMANDE préexistante. On tolérera cependant que, pour la durée des opérations d'enregistrement seule-
ment — ce qu'on appelle une transaction —, cette contrainte soit violée, sans quoi il serait impossible d'enre-
gistrer un bon de commande.
Dans de très nombreux cas, on devra cependant accepter que l'enregistrement du propriétaire d'une liaison soit
effectué antérieurement à l'enregistrement des membres de cette liaison. Il est alors nécessaire de relaxer la
contrainte, en transformant la connectivité 1:N en 0:N.

c) Intégrité des références
Définition
Soit le type de liaison E–propriétaire ← A–membre. On dit que, dans les occurrences A–membres, un identi-
fiant étranger fait référence à l'occurrence E–propriétaire.
La contrainte d'intégrité référentielle impose que la valeur de tout identifiant étranger dans le type A–membre
existe parmi les identifiants du type E–propriétaire.1 Cette contrainte doit être respectée pour tout type de
liaison obligatoire.
Elle ne s'applique pas à un type de liaison facultative; dans ce cas, l'identifiant étranger peut posséder la va-
leur "inexistant".
Création du propriétaire d'une liaison
Le propriétaire d'une liaison obligatoire doit être enregistré avant les membres de cette liaison (ou au cours
de la même transaction — cf. paragraphe précédent).
Dans le cas d'une liaison facultative, l'enregistrement du propriétaire peut être postérieur à celui du membre;
mais, alors, le membre doit être "rattaché" à son nouveau propriétaire.
Suppression du propriétaire d'une liaison
Que faire des occurrences A–membres liées à une occurrence E–propriétaire que l'on désire supprimer ?
Dans le cas d'une liaison facultative, la suppression de l'occurrence E–propriétaire est autorisée; les identi-
fiants étrangers dans les occurrences A–membres sont considérés comme possédant 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 règle particulière doit être fournie :
– ou bien la suppression de l'occurrence E–propriétaire doit être refusée — son autorisation est "limitée"
("restricted") au cas où l'ensemble des A–membres est vide,
– ou bien les occurrences A–membres liées doivent également être supprimées — cette règle est récursive :
elle se propage "en cascade" sur les ensembles dont chaque occurrence A est propriétaire, 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 propriétaire COMMANDE, on doit, au cours de la même transaction,
supprimer en cascade les membres LIGNE-COMMANDE;
– l'autorisation de supprimer un PRODUIT est limitée au cas des PRODUITs
qui ne sont référencés par aucune LIGNE-COMMANDE.
1L'ensemble des occurrences d'identifiants du type propriétaire constitue en quelque sorte un domaine dyna-
mique dans lequel l'attribut identifiant étranger prend ses valeurs.

2. Préparation du schéma physique
2.1. Schéma des fonctions d'accès
a) Introduction
Qu'il prenne la forme d'une base de données intégrée ou celle d'un ensemble de fichiers spécialisés, un système
physique de stockage des données doit permettre d'accéder facilement et économiquement aux différentes
données (concrètement : au différents enregistrements). Il le fait en incluant divers dispositifs techniques
accélérateurs, par exemple :
– la contiguïté des enregistrements rendant immédiat l'accès à l'enregistrement "suivant" (cette tech-
nique est la seule disponible sur une bande magnétique);
– le placement de chaque enregistrement à une adresse calculée à partir de la valeur d'un identifiant,
assurant un accès sélectif immédiat à l'enregistrement en question;
– la constitution de répertoires ou d'index accélérant la recherche;
– etc.1
Un schéma logique n'est pas un schéma physique ... La définition logique des types d'objets stockés ne précise
donc pas les formes matérielles de ces objets (par exemple, elle ne signale pas l'ordre des champs dans l'es-
pace de l'enregistrement); elle ne définit pas non plus les techniques d'accès à mettre en œuvre. Mais elle doit
identifier les opérations d'accès qu'il est nécessaire de rendre possibles.
La mise en évidence des fonctions d'accès découle de l'analyse générale des opérations et algorithmes du
système informatique à mettre en place; en d'autres termes, elle s'inscrit dans l'analyse de l'application
qui sera insérée dans le domaine décrit par la modélisation préalable des données. Elle s'effectue donc
lors d'une seconde phase de l'analyse.
b) Préliminaire : le concept d'ensemble selon CODASYL
Dans les bases de données CODASYL, un ensemble est la réalisation d'une (occurrence de) liaison. Soit un
type de liaison E–propriétaire ← A–membre. Une occurrence e du type d'enregistrement E est propriétaire
d'un ensemble {ai} dont les membres ou éléments sont les occurrences de A liées à e. L'ensemble {ai} peut
contenir un nombre quelconque d'éléments 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 défini dans tout schéma. L'enregistrement SYSTEM n'est membre d'aucune liaison (il est donc
inaccessible). Il peut être déclaré propriétaire de liaisons définies vers chacun des types d'enregistrements
existants; la chose est en tout cas nécessaire pour les types qui ne sont membres d'aucune liaison obligatoire.
1 Cf. A. CLARINVAL : Exploitation et Organisation des Fichiers, 2e partie.

CLIENT
n° client
ABONNEMENT nom client
abonné
¥ n° client adresse client
type prospectus catégorie
CL.PRIVE
CL.PROFESSIONNEL
REPRESENTANT n° TVA
contactant ¥ nom représentant
nom représentant
SYSTEM région
passant
chiffre d'affaires
COMMANDE
LIGNE n° commande
¥ n° produit comprenant ¥ n° client
n° produit objet
prix de vente
<1> nom produit
quantité en stock
prix de vente facturé LIGNE
¥ n° facture FACTURE
¥ n° produit comprenant n° facture
montant facturé total facturé
¥ n° commande
¥ n° client
c) Définition des méthodes d'accès 1
Clé d'accès
Une clé d'accès est une méthode permettant de sélectionner des sous-ensembles d'occurrences d'un type d'en-
registrement donné. Un identifiant est un cas particulier de clé d'accès, qui permet de sélectionner un sous-
ensemble singleton.
Mettant en œuvre la relation de dépendance fonctionnelle, une clé d'accès est formée d'un groupe de champs
déterminant le sous-ensemble sélectionné. En outre, les systèmes de stockage qui matérialisent les clés d'accès
sous la forme d'index2 considèrent habituellement que tout préfixe (partie de gauche) à l'intérieur d'une clé
d'accès constitue lui-même une clé d'accès; de ce fait, l'ordre existant entre les composants d'une clé d'accès
n'est pas indifférent.
Exemple : on définit sur le type d'enregistrement LIGNE-FACTURE

la clé d'accès qu'est son identifiant "n° facture, n° produit",
dont "n° facture" est un préfixe considéré comme clé;
ci-dessous sont illustrés deux accès par clés :
1 Ce paragraphe s'inspire de J.L. HAINAUT : Conception assistée des applications informatiques : concep-
tion de la base de données, Masson, 1986.
2 L'indexation, technique associant à chaque valeur de clé la liste des adresses des enregistrements corres-
pondants, n'est pas la seule manière de matérialiser le concept de clé d'accès. 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é livrée 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 définies une ou plusieurs clés d'accès. La définition de tout type
d'enregistrement comportera l'identification des clés définies sur ce type.
Remarque. La plupart des clés d'accès définies dans un schéma sont des identifiants : identifiants propres
(primaire et candidats) de chaque type d'enregistrement A, identifiants étrangers désignant les enregistrements
E propriétaires des liaisons dont le type A est membre.
Séquence d'accès
Une séquence d'accès est une méthode permettant, au départ d'une occurrence ai d'un type d'enregistrement,
d'accéder aux autres occurrences du même type.
Entre les occurrences membres d'un ensemble est défini un ordre de succession, appelé séquence d'accès. Au
départ de toute occurrence, la séquence d'accès détermine quelle est l'occurrence suivante.
Une séquence d'accès peut être
– indifférente;
– l'ordre chronologique d'insertion des membres dans l'ensemble (ou l'ordre chronologique inverse,
plus intéressant, comme on l'a vu, dans les ensembles historiques) ;
– déterminée par une clé de tri.
Une clé de tri est une clé d'accès, dont chaque composant est muni d'un sens, "ascendant" ou "descendant",
déterminant l'ordre entre les valeurs de ce composant. Fonctionnellement, l'accès est une succession d'accès
par clé utilisant les valeurs de la clé dans l'ordre défini, 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é livrée montant facturé
3550 1076 1 399
3550 1210 10 5990
3550 1453 1 1219

La définition de chaque type de liaison possédant une connectivité maximale supérieure à 1 comportera la
définition de la séquence d'accès applicable à l'ensemble des membres de cette liaison, si elle n'est pas indiffé-
rente.
Chemin d'accès
Un chemin d'accès est une méthode permettant, au départ d'une occurrence e1 d'un type d'enregistrement E1,
d'accéder aux occurrences d'un autre type E2 liées à cette occurrence e1.1
Pour tout type de liaison E–propriétaire ← A–membre déclarée, deux chemins d'accès sont possibles :
– un chemin allant du type E–propriétaire au type A–membre : dans chaque ensemble, ce chemin part de
l'occurrence propriétaire E et conduit à la première occurrence de l'ensemble des membres A; l'ensemble des
membres est alors parcouru selon la séquence d'accès définie sur cet ensemble; ce chemin donne un accès
exhaustif à tous les membres de l'ensemble; enfin, on retourne à l'occurrence E propriétaire (on verra plus
loin l'utilité de ce retour à l'occurrence propriétaire).
E e1 e2
a1 a2 a3
A
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é livrée 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 A–membre au type E–propriétaire : dans chaque ensemble, une réalisation de
ce chemin unit chaque occurrence du membre A à l'occurrence propriétaire E; ce chemin donne un accès sé-
lectif aux éléments du type E.
E e1
a1 a2 a3
A
1Dans 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'accès seront figurés par des flèches qui en indiqueront la direction.1
CLIENT
n° client
abonné
¥ n° client adresse client
CL.PRIVE
CL.PROFESSIONNEL
nom représentant
SYSTEM région
passant
chiffre d'affaires
COMMANDE
LIGNE COMMANDE n° commande
n° produit objet
prix de vente
<1> nom produit
quantité en stock
¥ n° facture
FACTURE
¥ n° commande
¥ n° client
2.2. Quantification du schéma
Pour opérer des choix techniques raisonnés et optimaux, la modélisation physique doit disposer de quantifica-
tions.
Quantification du stockage : longueur des champs (c'est-à-dire des chaînes de caractères représentant les
valeurs des attributs), nombre d'occurrences (ce qu'on appelle population) d'enregistrements de chaque
type.
Quantification des accès : nombre de consultations via chaque structure d'accès, nombre d'ajouts, de modi-
fications et de suppressions.
Ces quantifications seront rapportées à des époques ("au départ, après un an...") ou des périodes ("par jour,
par semaine, par mois..."). Les quantités indiquées seront toutes les grandeurs d'intérêt statistique : maxi-
mum, mode, moyenne.
1 La même convention existe dans les diagrammes de classes d'UML.

3. Le schéma logique des données, support de la programmation
3.1. Parcours d'un ensemble
On l'a signalé : en suivant le chemin d'accès du type E–propriétaire au type A–membre, on effectue un par-
cours exhaustif de l'ensemble, qui part de l'occurrence E propriétaire et y retourne.
Dans le contexte de l'ensemble dont elle est propriétaire, les attributs de l'occurrence E propriétaire peu-
vent se répartir en deux classes :
– les attributs sources, dont la valeur est indépendante du contenu de l'ensemble des membres A (tels sont
notamment les identifiants de E);
– les attributs résultats (très souvent, des totaux), dont la valeur est calculée à partir de celles des membres
A de l'ensemble.
Dans l'ordre chronologique, le programme accède donc :
– aux attributs sources de l'occurrence E propriétaire (ex.: date de facture),

– aux occurrences des A membres (ex.: lignes de la facture),
– aux attributs résultats de l'occurrence E propriétaire (ex.: total facturé).
E e1
S R
A a1 a2 a3
On reconnaît la structure classique d'une boucle de programme, initialisée et clôturée.
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 résultats de E
3.2. Sous-schéma arborescent
Un sous-schéma arborescent est une partie d'un schéma, caractérisée de la manière 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 schéma suivant, différents sous-schémas arborescents peuvent être définis, comme ceux qui sont iden-
tifiés par les minuscules placées le long des liaisons qui les composent.

CLIENT
n° client
abonné
¥ n° client b adresse client
b
CL.PRIVE
a CL.PROFESSIONNEL
nom représentant
a
SYSTEM région
passant
chiffre d'affaires
c
e COMMANDE
c date commande
¥ n° commande
n° produit e objet
prix de vente c
<1> nom produit
quantité en stock e
¥ n° facture
FACTURE
d quantité livrée date facture
cd
¥ n° commande
¥ n° client
La composition d'un sous-schéma arborescent peut être définie au moyen d'une expression parenthésée de la
forme : nom-de-propriétaire (ensemble-1, ensemble-2, ...)
où chaque ensemble est décrit de la manière suivante : nom-de-liaison cardinalité nom-de-membre
et où le nom de la racine SYSTEM est remplacé par le nom attribué au sous-schéma.
Exemples : les sous-schémas illustrés à la figure précédente peuvent être définis 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-schéma arborescent est important.
D'une part, la collection représentée par un sous-schéma arborescent peut être parcourue par un programme
hiérarchisé sur autant de niveaux de boucles emboîtées que le sous-schéma comprend de niveaux de liaisons.

Exemple : le sous-schéma arborescent à deux niveaux de liaisons
E0(SYSTEM) ← E1(FACTURE) ← E2(LIGNE-FACTURE)
sera traité de la manière suivante :
pour chaque occurrence de E1(FACTURE)

traiter les attributs sources de E1(FACTURE)
pour chaque occurrence de E2(LIGNE-FACTURE)
traiter l'occurrence de E2(LIGNE-FACTURE)
fin pour chaque occurrence de E2
traiter les attributs résultats de E1(FACTURE)
3.3. Transformation séquentielle des sous-schémas arborescents
a) Constitution des fichiers séquentiels
D'autre part, à la condition de scinder tout enregistrement propriétaire d'un ensemble en deux parties compre-
nant, l'une les attributs sources, l'autre les attributs résultats, la collection représentée par un sous-schéma ar-
borescent peut être stockée de manière linéaire, sur un imprimé ou dans un fichier séquentiel.
Il suffit pour cela de remplacer dans le programme du paragraphe précédent le verbe "traiter" par le verbe
"écrire".
Exemple : pour chaque occurrence de E1(FACTURE)

écrire les attributs sources de E1(FACTURE) enregistrement d'en-tête
pour chaque occurrence de E2(LIGNE-FACTURE)
écrire l'occurrence de E2(LIGNE-FACTURE)
écrire les attributs résultats de E1(FACTURE) enregistrement récapitulatif
b) Cas particulier : ensembles hétérogènes
Considérons le sous-schéma arborescent :
RESULTAT COURS
SYSTEM ETUDIANT
RESULTAT EXERCICE
Il présente la particularité que le type ETUDIANT est propriétaire de plusieurs (deux) types d'ensembles.
Pour la transformation séquentielle, on considérera qu'il s'agit d'un seul ensemble dont les membres sont de
plusieurs types.
SYSTEM ETUDIANT RESULT. COURS ou EXERC.

c) Syntaxe de définition
La syntaxe proposée plus haut pour la définition des sous-schémas arborescents peut aisément être étendue en
vue de permettre la description des particularités introduites par leur transformation séquentielle :
– deux descriptions d'ensembles séparées par "+" plutôt que par "," définissent un ensemble hétérogène;
– les attributs sources et résultats du type propriétaire sont regroupés dans deux types d'enregistrements de 1:1
occurrence, placés respectivement en tête 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 particulières aux fichiers COBOL
L'organisation de fichiers la plus fréquemment utilisée en COBOL est l'organisation séquentielle indexée; il
s'agit de fichiers séquentiels auxquels des clés d'accès, identifiantes ou non, sont ajoutées 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 déclarer une clé primaire identifiante (RECORD KEY); on peut déclarer un nombre
quelconque d'identifiants candidats (ALTERNATE RECORD KEY) ou de clés non identifiantes (ALTER-
NATE RECORD KEY WITH DUPLICATES);
– toute clé d'accès est formée d'une zone contiguë (la clause RENAMES THRU peut être employée pour
déclarer le regroupement des champs composant la clé);
– toute clé d'accès doit être déclarée de type alphanumérique (PICTURE X(n) ou déclaration assimilée);
– si le fichier contient des enregistrements de différents types, toute clé d'accès déclarée dans un type d'enre-
gistrement existe automatiquement dans tous les autres types et y occupe la même position par rapport au dé-
but de l'enregistrement (il est donc inutile, dans la clause SELECT, de déclarer les clés 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 clés différentes (NO-LIGNE et NO-PRODUIT) ne peuvent pas commencer à la même position dans
l'enregistrement;
– tout préfixe d'une clé d'accès (NO-COMMANDE dans NO-LIGNE) est une clé d'accès utilisable par l'ins-
truction START de positionnement dans le fichier;
– toute clé d'accès (tout index) est également une clé de tri en ordre croissant.
e) Réalisation des fonctions d'accès
Fonctions d'accès internes à un fichier séquentiel
• Chemin d'accès (Types d'enregistrements)

Lors du traitement d'un fichier séquentiel, il est nécessaire de pouvoir reconnaître le type de chaque (occur-
rence d') enregistrement. Un moyen simple est de préfixer chaque enregistrement par un champ convention-
nel contenant le nom (codifié) de son type.
• Séquence et clé d'accès

En pratique, il est souvent indispensable de déterminer l'ordre des enregistrements dans un fichier séquentiel;
il faut pour cela définir une clé de tri globale, qui, si le fichier est indexé, peut également servir de clé d'accès
identifiante.
1 Ces contraintes sont celles de la norme COBOL publiée en 1985; la prochaine norme actuellement en prépa-
ration devrait être moins restrictive.

Soit un fichier séquentiel décrit par le sous-schéma arborescent SYSTEM(E0) ← E1 ← ... En, et Ki l'identifiant
du type d'enregistrement Ei (i > 0).
Considérons, dans le sous-schéma, le segment Ei ← Ej (i > 0, j = i + 1). Tout ensemble décrit par ce type de
liaison comprend des enregistrements de différents types : ESi, Ej, ERi, qui doivent se succéder dans cet ordre.
On associera donc à l'identifiant Ki un code Ti distinctif du type d'enregistrement, code pour lequel un jeu de
valeurs ordonnées pourrait être {"1" pour le type ESi, "5" pour le type Ej, "9" pour le type ERi}.1 L'identi-
fiant global, commun à tous les types d'enregistrements du fichier, sera formé de la concaténation K =
K1,T1,K2,T2,...Kn. Le champ Kj, partie de l'identifiant global K, doit posséder une valeur "inexistant" dans les
types ESi et ERi.
Exemple : sous-schéma : SYSTEM ← FACTURE ← LIGNE-FACTURE

fichier : FACTURIER (0:N FACTURE comprenant (1:1 en-tête-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'accès inter-fichiers
Il est fréquent que le propriétaire et les membres d'un ensemble soient répartis dans des fichiers différents.
Dans les exemples ci-dessous, c'est le cas de PRODUIT ← LIGNE-COMMANDE.
• Chemin d'accès E–propriétaire → A–membre

Comment, à partir d'une occurrence du type propriétaire (PRODUIT), retrouver les occurrences (LIGNE-
COMMANDE) de l'ensemble correspondant ?
L'identifiant étranger (n° produit) dans le type membre (LIGNE-COMMANDE) doit être défini comme clé
d'accès, et l'on effectuera une boucle de lecture par cette clé d'accès.

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 prévu dans le cas d'un ensemble possédant 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 retrouvée ...
AT END MOVE HIGH-VALUE TO Ligne-Commande
END-READ
END-PERFORM
END-START
• Chemin d'accès A–membre → E–propriétaire

Comment, à partir d'une occurrence du type membre (LIGNE-COMMANDE), retrouver l'occurrence pro-
priétaire (PRODUIT) correspondante ?
L'identifiant propre (n° produit) du type propriétaire (PRODUIT) doit être défini comme clé d'accès, et l'on
effectuera une lecture sélective par cette clé d'accès.

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
... propriétaire non trouvé ...
END-READ
3.4. Méthode de construction des programmes
Différentes méthodes de construction des programmes se fondent sur l'idée que la structure des données 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
1J.D. WARNIER : Les procédures de traitement et leurs données, éd. d'Organisation, 1973; M.Th.
BERTINI, Y. TALLINEAU : Le COBOL structuré, un modèle de programmation, éd. d'Informatique, 1974;

La méthode esquissée ici n'est rien d'autre qu'une adaptation de celle de JACKSON au modèle logique en ré-
seau. Nous allons l'exposer sur l'exemple d'un programme (très simplifié) de facturation-livraison.
a) Graphe des accès aux données
E
CLIENT
n° client
nom client
adresse client
catégorie
CL.PRIVE
CL.PROFESSIONNEL
n° TVA
passant
SYSTEM ¥ nom représentant
E
E COMMANDE
E S ¥ n° commande date commande
PRODUIT ¥ n° produit comprenant ¥ n° client
commandé
quantité commandée
n° produit objet
prix de vente
<1> nom produit
quantité en stock
S S
FACTURE
¥ n° facture
comprenant
¥ n° produit n° facture
¥ n° commande
¥ n° client
M. JACKSON : Principles of Program Design, Academic Press, 1975. Les deux premières méthodes sont
fort proches et, en dépit des apparences graphiques, identiques pour ce qui concerne la structure des pro-
grammes.

1) Etablir le sous-schéma des données utilisé par le programme.
2) Indiquer l'usage des types d'enregistrements dans le programme :
E = entrées (données lues ou reçues),

S = sorties (données créées ou modifiées).
3) Définir les chemins d'accès ( → ) utilisés par le programme. On remarquera et on exploitera les pro-
priétés suivantes :
– certains types d'enregistrements font l'objet d'un accès exhaustif, c'est-à-dire que chaque occur-
rence de ces types est traitée une et une seule fois; l'accès à ces enregistrements se fait en emprun-
tant le chemin E–propriétaire → A–membre;
Exemple : SYSTEM → COMMANDE → LIGNE-COMMANDE

SYSTEM → FACTURE → LIGNE-FACTURE
– d'autres types font l'objet d'un accès sélectif, c'est-à-dire que certaines occurrences ne sont pas
traitées ou sont traitées plusieurs fois; l'accès à ces enregistrements (ex. : CLIENT, PRODUIT) se
fait en empruntant le chemin A–membre → E–propriétaire.
4) Souligner les sous-schémas arborescents supportant un accès exhaustif E–propriétaire → A–membre.

Seuls, ces sous-schémas déterminent la structure du programme.
5) Repérer sur ces sous-schémas en accès exhaustif les correspondances entre toutes les collections d'en-
registrements en accès exhaustif. Sont correspondantes les collections entre lesquelles existe ou pourrait
exister une liaison dont les connectivités sont 1:1 ou 0:1 et pour lesquelles les séquences d'accès sont compa-
tibles.1
Exemple : COMMANDE – FACTURE

LIGNE-COMMANDE – LIGNE-FACTURE
b) Règles du traitement
Avant de construire le programme, on rassemblera les règles concernant tous les objets du sous-schéma.
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 accès exhaustif.

c) Structure du programme
La figure ci-dessous illustre la structure du programme.
6<67(0

!

!" ##
%! ! !$+ ,(#
CLIENT COMMANDE FACTURE

!" ##

%! ! !$+ ##
LIGNE LIGNE
PRODUIT PRODUIT
COMMANDE FACTURE
!" ##

$
%
&'
&() &'
#
* #

Le rectangle central recouvre les sous-schémas arborescents en accès exhaustif; les types d'enregistrements
correspondants sont rapprochés en un seul point.
La partie gauche est relative aux données d'entrée et la partie droite, aux données de sortie.
Les flèches en pointillé représentent les boucles emboîtées qui constituent la structure du programme. Sur ces
boucles sont réparties les opérations que le programme doit exécuter sur les données; ces opérations sont
déduites des règles rassemblées à l'étape précédente.
Sur une flèche de la partie gauche, les opérations utilisant les données sources des enregistrements propriétai-
res, situés à l'origine de cette flèche; sur une flèche de la partie droite, les opérations utilisant les données ré-
sultats des enregistrements propriétaires.
Noter le placement particulier des instructions READ NEXT de parcours (lecture) de la collection d'entrée
définie par le sous-schéma en accès exhaustif : une première lecture avant toute autre opération, les suivantes
en fin de toute séquence 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 numéro attribué ? "

ACCEPT Dernier-No-Facture
PERFORM Lire-Commande
PERFORM Traiter-Commande
UNTIL Nom-Type OF Tete-Commande = SPACES
DISPLAY "Voici le dernier numéro 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
.

Chapitre 5. Schéma physique de la base de données
Aboutissement concret de la modélisation des données : la création d’une base de données ou d’un ensemble
de fichiers.
Le schéma logique des données stockées et des fonctions d’accès doit être coulé dans les formes requises par
le SGBD particulier utilisé. A cette description "programmée" des fichiers ou de la base de données, on
donne le nom de schéma physique.
Nous avons évoqué à la fin du chapitre précédent la transformation du schéma logique en schéma physique
d’un ensemble de fichiers COBOL.1 Le présent chapitre traite du schéma physique des bases de données.
Nous y décrivons sommairement les deux standards que respectent la plupart des bases de données actuelle-
ment en activité : le standard CODASYL pour les bases de données en réseau et le standard SQL pour les
bases de données relationnelles. Pour l’équilibre de l’exposé, après la description du schéma proprement dit
de la base de données, nous illustrons les opérations disponibles pour l’accès aux données.
Les paragraphes qui suivent ne constituent qu’une introduction aux systèmes de bases de données,
bien insuffisante pour pouvoir utiliser ces systèmes.
1 Cf. chapitre 4, section 3.
© A. CLARINVAL Analyse — Schéma physique 5-1

1. Les bases de données CODASYL
Les SGBD de la première génération furent conçus, autour de 1970, pour donner à des programmes d'applica-
tion l'accès à des collections de données intégrées. (A l’époque, on n’imaginait pas un utilisateur devant un
écran en train d’improviser une recherche dans une base de données.)
Dans ces systèmes, les opérations d'accès à la base de données portent toujours sur un seul enregistrement —
on retrouve là le principe de fonctionnement traditionnel des instructions d’accès aux fichiers. Les différents
accès doivent être combinés par les moyens propres au langage hôte (IF, PERFORM ... dans le cas de
COBOL). Le programmeur contrôle ainsi la "navigation" d'un enregistrement à l'autre dans la base de don-
nées. De là vient le qualificatif "navigationnel" par lequel on caractérise souvent ces SGBD.
La vogue des SGBD relationnels a eu pour effet que les SGBD navigationnels sont passés de mode.
Les SGBD navigationnels sont néanmoins encore employés sur les gros ordinateurs d’entreprises
qui furent parmi les premières à s’équiper informatiquement : banques, groupes industriels, grosses
administrations publiques ....
Nous présentons ici le modèle de SGBD standard élaboré, entre 1971 et 1978, par CODASYL ("COnference
on DAta SYstems Languages"), l’organisme créateur du langage COBOL. Ce modèle s'appuie sur le modèle
des données en réseau défini par BACHMAN dès 19631, modèle que nous avons étudié au chapitre précé-
dent.
Un SGBD conforme au standard CODASYL est notamment caractérisé par l'existence de deux langages : un
DDL (Data Description Language) et un DML (Data Manipulation Language).
Le DML fournit les opérations d'accès aux données. Il a été conçu comme une extension du langage COBOL.
Le DDL est utilisé par l'administrateur de la base de données (DBA) pour enregistrer dans un dictionnaire
interne à la base de données le schéma de celle-ci. Ce langage décrit à la fois la structure maillée (en réseau)
de la base de données et les dispositifs techniques (index, pointeurs, etc.) supportant les fonctions d'accès
souhaitées.
Le DDL est également employé pour définir les sous-schémas (vues externes) utilisés par les différents
groupes de programmes clients.
Les exemples donnés dans le texte ci-après sont relatifs à la base de données dont le schéma logique
a été élaboré au chapitre 4. Remarquer que les identifiants étrangers en ont été supprimés et que les
noms de liaisons ont été rendus univoques.

CLIENT
n° client
PROSPECTUS Abonnements nom client
Clientèle
type prospectus adresse client
catégorie
CL.PRIVE
CL.PROFESSIONNEL
REPRESENTANT Contacts
n° TVA
nom délégué
Représentation
SYSTEM région
chiffre d'affaires Client-Commande
Carnet-Commandes Client-Facture
Stock-Tarif
COMMANDE
n° commande
LIGNE COMMANDE
date commande
PRODUIT Produit-Commande quantité commandée
n° produit prix de vente Détail-Commande
<1> nom produit Facturation-Commande
quantité en stock
prix de vente LIGNE FACTURE
Produit-Facture Détail-Facture
quantité livrée FACTURE
montant facturé
n° facture
Facturier
date facture
total facturé
1.1. Le langage de description de données (DDL)
a) Schéma de la base de données
Fichiers (AREA)
• Le contenu d'une base de données CODASYL est réparti 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 décrit dans le schéma.
• Pour chaque type d'enregistrement, la clause WITHIN areas désigne le(s) fichier(s) dans le(s)quel(s) les
occurrences doivent être stockées.
Si les occurrences d'un même type d'enregistrement peuvent être stockées dans différentes zones, on
devra, avant de traiter une nouvelle occurrence, indiquer par une variable du programme le nom
(AREA-ID) de la zone visée.
• A tout enregistrement créé dans la base de données 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) mentionnée — ce mode de localisation optimise l'accès par clé;
– appliquée 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 groupés à proxi-
mité de l'enregistrement propriétaire — ce mode de localisation optimise l'accès par les chemins défi-
nis entre le propriétaire et les membres d'un ensemble.
• La description d'un type d'enregistrement comporte la définition des champs (data-items) qui le compo-
sent. Comme en COBOL, la décomposition de l'enregistrement est reflétée par des numéros de niveau et les
données peuvent être structurées ou répétitives.
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 propriétaire (OWNER) et les enregistrements membres

(MEMBER) associés à cet enregistrement propriétaire par un même type de laison. Noter les particularités :
– chaque type d'ensemble est désigné dans le schéma par un nom univoque;
– tout enregistrement doit être membre d'au moins un ensemble; le propriétaire de cet ensemble peut
être l'enregistrement fictif SYSTEM;
– un enregistrement ne peut être membre de plus d'un ensemble du même type;
– tout ensemble est détenu par exactement un propriétaire et contient un nombre (0:N) quelconque
de membres;
– le propriétaire et les membres d'un ensemble ne peuvent pas être du même type; en d'autres ter-
mes, les liaisons ne sont pas cycliques;
– les enregistrements membres d'un ensemble peuvent être de différents types (ex.: RESULTAT-
EXAMEN et RESULTAT-EXERCICES).
• La définition d'un ensemble signale si la liaison des membres au propriétaire 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é inséré dans un ensemble, un enregistrement membre ne peut
plus en être ôté.

• La séquence d'accès aux membres d'un ensemble doit être pré-déterminée par la clause ORDER. Celle-ci
définit la position d'insertion d'un nouveau membre dans l'ensemble :
– ordre chronologique (ORDER is LAST),

– ordre chronologique inversé (ORDER is FIRST),
– ordre défini par une clé de tri (ORDER is SORTED),
– insertion devant (ORDER is PRIOR) ou derrière (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 accélérera les opérations de recherche et d'insertion (ORDER is SORTED
INDEXED). Cette technique est à réserver aux ensembles contenant un grand nombre de membres,
particulièrement les ensembles de premier niveau, dont l'enregistrement SYSTEM est propriétaire.
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'accès dans un ensemble sont matérialisés au moyen de pointeurs — un pointeur "vers" un
enregistrement est une donnée interne, une DB-KEY, contenant l'adresse de cet enregistrement. Deux techni-
ques sont disponibles pour l'agencement des pointeurs : les chaînages (CHAIN, option par défaut) et les ta-
bleaux de pointeurs (POINTER ARRAY).
– Chaînage. L'enregistrement propriétaire 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 propriétaire (dans le cas d'un ensemble vide, l'enregistrement propriétaire contient un pointeur
vers lui-même). On peut demander d'ajouter un chaînage inverse : chaque enregistrement pointe vers
le précédent (LINKED TO PRIOR). Pour optimiser les accès par le chemin membre→ propriétaire,
on peut également demander d'attacher à chaque membre un pointeur direct vers le propriétaire
(LINKED TO OWNER).
e
CHAIN
LINK TO PRIOR
LINK TO OWNER
a1 a2 a3 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-
chée à l'enregistrement propriétaire. De plus, comme dans l'option LINKED TO OWNER, chaque
membre contient un pointeur direct vers le propriétaire.
Clés d'accès et identifiants
La clé servant à calculer l'emplacement d'un enregistrement (clause LOCATION MODE is CALC USING
clé) et la clé de tri définie pour les membres d'un ensemble peuvent servir de clés d'accès. En outre, pour
chaque type d'ensemble, on peut définir un nombre quelconque de clés pour la recherche des membres
(SEARCH KEY).
L'option DUPLICATES NOT ALLOWED est employée pour rendre identifiante n'importe quelle clé d'accès.
Exemple : SET NAME Stock-Tarif

OWNER SYSTEM
ASCENDING KEY No-Produit
DUPLICATES NOT ALLOWED
SEARCH KEY Nom-Produit
DUPLICATES NOT ALLOWED.
Exemple récapitulatif
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-schémas
Un sous-schéma décrit la partie de la base de données accessible à un programme. Il en énumère les zones
(fichiers), les types d'enregistrements, les types d'ensembles et les attributs. A l'instar du schéma dont il dé-
rive, tout sous-schéma est catalogué dans le dictionnaire de la base de données.
Pour chaque type d'enregistrement défini dans le sous-schéma, une zone de mémoire tampon est réservée à
l'intérieur du programme (analogie avec la FILE SECTION d'un programme COBOL).
Exemple : les lignes ci-dessous incorporent au programme COBOL la définition d'un sous-schéma
DATA DIVISION.
SCHEMA SECTION.
INVOKE SUB-SCHEMA Livraison-Facturation OF SCHEMA Ventes.
1.2. Le langage de manipulation des données (DML)
a) Contrôle de l'accès aux fichiers : OPEN, CLOSE
Un fichier (AREA) doit être "ouvert" pour qu'on puisse y localiser des enregistrements.
L'instruction OPEN possède différentes formes et elle permet au programme de signaler au serveur de la base
de données s'il veut procéder à des mises à jour (UPDATE) ou seulement à des consultations (RETRIE-
VAL); elle peut aussi demander au serveur de protéger le fichier ouvert contre tout accès concurrent émanant
d'un autre programme (EXCLUSIVE) ou seulement contre les mises à jour concurrentes (PROTECTED).
Après son utilisation, tout fichier doit être libéré 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 mécanismes de navigation
Enregistrements courants
Avant de pouvoir être manipulé, tout enregistrement doit être localisé, par une instruction FIND. Cette ins-
truction mémorise dans différents registres l'identifiant–adresse (DB-KEY) de l'enregistrement trouvé.

A tout moment, en effet, le SGBD conserve l'adresse (DB-KEY) du dernier enregistrement traité (trouvé ou
inséré) — enregistrement qualifié de courant — dans chacune des catégories suivantes :
– dans chaque fichier (AREA) du sous-schéma,

– pour chaque type d'enregistrement (RECORD) du sous-schéma,
– pour chaque type d'ensemble (SET) du sous-schéma,
– pour le programme (run-unit) = enregistrement courant le plus récent de tous.
A tout moment, ces registres décrivent le contexte dans lequel se déroulera l'opération suivante.
Localisation d'un enregistrement : FIND
L'instruction FIND possède de nombreuses formes. Nous en illustrons ici quelques-unes :
– localisation par la clé d'un enregistrement à adresse calculée :
exemple : * garnir la clé :

ACCEPT No-Client
* localiser l'enregistrement :
FIND Client
– localisation du premier membre d'un ensemble :
exemple : * le Client propriétaire étant courant,

* localiser la première Commande :
FIND FIRST Commande OF Client-Commande SET
– localisation du membre suivant d'un ensemble :
exemple : * la Commande propriétaire étant courante

* ou une Ligne-Commande étant déjà courante,
* localiser la Ligne-Commande suivante :
FIND NEXT Ligne-Commande OF Detail-Commande SET
– localisation du propriétaire d'un ensemble :
exemple : * une Ligne-Commande étant courante,

* localiser le Produit propriétaire :
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 récent à un ensemble. Cette question
est utile dans le cas des membres facultatifs.
Exemple : le Client courant est-il contacté par un représentant ?
IF RECORD [NOT] MEMBER OF Contacts

THEN SET ........

Lecture d'un enregistrement : GET
L'instruction GET transfère dans la zone de mémoire tampon accessible au programme les données de l'enre-
gistrement courant le plus récent. On peut transférer toutes les données de l'enregistrement ou seulement cer-
taines.
Exemple : * après avoir localisé un enregistrement Client ...

* transfert du contenu intégral de l'enregistrement :
GET Client
* transfert de données sélectionnées :
GET Client; Nom-Client Adresse-Client
c) Mise à jour des données
Création/Modification d'un enregistrement : STORE, MODIFY
Avant de stocker (STORE) un nouvel enregistrement dans la base de données, on doit :
– éventuellement, sélectionner le fichier (AREA) destinataire;

– rendre courants les ensembles dans lesquels l'enregistrement doit être inséré automatiquement;
– garnir les champs qui le composent avec les valeurs adéquates.
Par ailleurs, l'instruction MODIFY permet de changer la valeur des champs de l'enregistrement courant le
plus récent.
Exemple : création d'une commande :
* sélectionner le fichier destinataire :

MOVE "Donnees-EnCours" TO Nom-Zone
* localiser le Client propriétaire :
DISPLAY "n° Client : " NO ADVANCING ACCEPT No-Client
FIND Client
* rendre courant l'ensemble Carnet-Commandes
* en localisant la Commande la plus récente
* (la séquence de tri est l'ordre chronologique inversé) :
FIND FIRST Commande OF Carnet-Commandes SET
* prendre le dernier numéro de commande attribué :
GET Commande; No-Commande
* créer l'enregistrement Commande :
ADD 1 TO No-Commande
ACCEPT Date-Commande FROM DATE
* stocker l'enregistrement Commande :
STORE Commande
* localiser le Produit propriétaire :
DISPLAY "n° Produit : " NO ADVANCING ACCEPT No-Produit
FIND Produit USING No-Produit
* créer 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 insère l'enregistrement courant le plus récent dans un ensemble dont il est membre fa-
cultatif (OPTIONAL) ou MANUAL. Le membre est inséré à la position déterminée par la clause ORDER.
L'instruction REMOVE enlève l'enregistrement courant le plus récent 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 récent. Elle possède différentes formes :
– suppression limitée aux enregistrements qui ne sont propriétaires d'aucun ensemble,

– suppression en cascade,
– suppression sélective,
– .....

2. Les bases de données relationnelles
Dans les années 80, une deuxième génération de SGBD s'est imposée, au détriment des précédents. Fondés
sur le modèle relationnel de CODD1, ces systèmes, aujourd’hui les plus répandus, ont l'avantage principal de
donner à l'utilisateur un langage d'interrogation déclaratif plutôt que navigationnel : l'utilisateur rédige une
expression déclarant le résultat qu'il attend, et le SGBD lui-même en déduit l'algorithme (la séquence d'opéra-
tions) à exécuter. Au contraire des instructions des langages précédents, qui manipulent toujours une occur-
rence d'enregistrement, une requête relationnelle manipule des ensembles ou collections d'occurrences; dès
lors, elle n'a pas pour elle-même besoin d'être "habillée" d'un programme plus étoffé. Un tel langage est prin-
cipalement destiné aux utilisateurs finals d'un interpréteur de requêtes.
Le langage SQL ("Structured Query Language") est devenu le langage standard pour la gestion des bases de
données de ce type.
Après une présentation succincte de la théorie du modèle relationnel, nous montrerons comment, en langage
SQL, la base de données est définie dans un dictionnaire de données, puis comment on la manipule.
AVERTISSEMENT
Nous avons préféré ne pas encore tenir compte des apports du paradigme Objet à la norme SQL3 (types de
données abstraits et sous-types, principalement). SQL3 est trop récent pour que l’usage de ses nouvelles pos-
sibilités soit déjà généralisé. Et il est encore nécessaire d’expliquer comment transposer en SQL "ancien" les
spécifications de l’analyse.
2.1. Le modèle relationnel des données
En 1970, l'Américain E. CODD définissait un modèle relationnel pour la représentation (le stockage) et la
manipulation des données dans une base de données. Ce modèle constitue une véritable théorie mathémati-
que, comportant principalement les aspects suivants :
– la présentation des données sous la forme de relations au sens mathématique;

– une algèbre relationnelle pour leur manipulation;
– une théorie de la normalisation pour leur modélisation.2
Cette théorie, non seulement fonde les SGBD qui s'en réclament expressément, mais elle inspire dorénavant
tous ceux qui s'occupent de modélisation des données.
a) Les relations
Appelons domaine un ensemble de valeurs. Une relation (en anglais : "relation"3) est un sous-ensemble du
produit cartésien défini sur une liste de domaines.

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 = {Citroën, Ford, Renault}
NUMERO = {ABC123, ABC456, DEF123, DEF456}
produit : ABC123 Citroën

ABC123 Ford
ABC123 Renault
ABC456 Citroën
ABC456 Ford
ABC456 Renault
DEF123 Citroën
DEF123 Ford
DEF123 Renault
DEF456 Citroën
DEF456 Ford
DEF456 Renault
relation A : ABC123 Citroën

ABC456 Renault
DEF123 Renault
relation B : ABC123 Citroën

ABC456 Renault
DEF456 Ford
Ainsi qu'on le voit à cet exemple, une relation se représente aisément sous la forme d'un tableau à double en-
trée, auquel on a donné le nom de table.
Chaque ligne représente un n-uplet (élément) de la relation. Conformément à la théorie 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 représente un attribut de la relation. Plusieurs attributs d'une relation peuvent prendre leurs
valeurs dans un même domaine. On appelle degré d'une relation le nombre de ses attributs.
Exemple : domaines : NOM = {Citroën, Clio, Escort, Fiesta, Ford,

Mondeo, Renault, Twingo, Visa, Xantia}
NUMERO = {ABC123, ABC456, DEF123, DEF456}
relation A : ABC123 Citroën Visa

ABC456 Renault Clio
DEF123 Renault Twingo
relation B : ABC123 Citroën Xantia

ABC456 Renault Clio
DEF123 Ford Escort
DEF456 Ford Mondeo
La définition 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 : numéro, MARQUE : nom, MODELE : nom)

Dans une base de données relationnelle, toutes les données sont stockées dans des tables ou relations.
Exemple : le schéma logique élaboré au chapitre 4 devient :

(entre crochets, un attribut pouvant prendre la valeur "inexistant")
REPRESENTANT (nom-délégué, région, chiffre-d-affaires)

CLIENT (n°-client, nom-client, adresse-client,
catégorie-client, [no-TVA], [nom-délégué])
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é-commandée)
FACTURE (n°-facture, n°-commande, date-facture, total-facturé)
LIGNE-FACTURE (n°-facture, n°-produit, quantité-livrée, montant-facturé)
dans cet exemple, on n'a pas indiqué les domaines de valeurs des attributs
Remarques
En principe, chaque type d'enregistrement défini dans le schéma logique des données deviendra, comme dans
l'exemple ci-dessus, un type de relation.
Une table est assimilable à un fichier séquentiel (COBOL, par exemple) contenant des enregistrements d'un
seul type.
b) Identification et Normalisation
En guise d'outils d'analyse, permettant de découvrir les types de relations à définir dans une base de données,
CODD a défini (1) des règles de normalisation ou formes normales, (2) le concept de dépendance fonction-
nelle sur lequel elles s'appuient, (3) un traitement mathématique de ces concepts.
Une présentation plus intuitive de ces concepts a été donnée aux chapitres 3 et 4. Nous la complétons ici de
quelques remarques.
Puisque tous les n-uplets d'une relation sont différents, toute relation possède, par définition, un identifiant :
elle-même. Dans la réalité, les identifiants minimaux sont habituellement réduits à quelques attributs ou co-
lonnes de la table. Les liens logiques entre tables s'opèrent par le biais des identifiants étrangers importés.
Exemple : dans le schéma ci-dessus,

les identifiants primaires (minimaux) sont soulignés,
les identifiants étrangers sont en italiques.
Une relation est dite normalisée dès lors qu'elle se trouve en première forme normale (1NF), c'est-à-dire si
tous ses attributs sont à la fois élémentaires (non structurés) et simples (non répétitifs). Cette règle doit être
obligatoirement respectée, car elle fonde le mécanisme de désignation des attributs dans les requêtes du lan-
gage relationnel : un attribut (élémentaire et simple) est complètement désigné 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'algèbre relationnelle (pour mémoire)

Les opérations de l'algèbre relationnelle sont mises en oeuvre dans les requêtes formulées dans le langage de
manipulation des données.

2.2. Le dictionnaire des données (SQL)
Le schéma de la base de données est enregistré dans un dictionnaire, que la norme SQL appelle Information
Schema. Ce dictionnaire fait partie de la base de données elle-même;1 il est consulté par l'interpréteur des
commandes de manipulation des données.
Le schéma d'une base de données contient principalement la définition de domaines de valeurs, la définition
des tables, la définition des contraintes d'intégrité, appelées assertions en SQL. Il peut aussi contenir la défi-
nition de vues particulières et diversifiées sur l'une ou l'autre tables, ainsi que des procédures de mise à jour
automatique des données redondantes ou dérivables.
Remarque
Toutes les contraintes d'intégrité définies dans le schéma sont vérifiées automatiquement par le
SGBD lors des opérations de mise à jour. Toute contrainte peut avoir un nom, que les messages d'er-
reurs du SGBD utiliseront pour identifier chaque contrainte violée.
a) Définition des domaines
Les domaines de valeurs servent à décrire les colonnes dans les tables.
La définition d'un domaine mentionne son nom, le type de données dont il constitue un sous-ensemble, l'éven-
tuelle valeur par défaut, une contrainte d'intégrité attachée au domaine.
La valeur par défaut, utilisée par le SGBD lorsque l'utilisateur crée un n-uplet sans fournir de valeur pour
une colonne, doit être une constante appartenant au type indiqué ou la valeur spéciale NULL (inconnu).
Une contrainte de domaine est un prédicat quelconque restreignant l'ensemble des valeurs admises dans ce
domaine : elle définit le domaine comme un sous-ensemble du type de données. A moins que soit spécifiée
une contrainte NOT NULL, tout domaine admet la valeur "inconnu".
Format : CREATE DOMAIN nom [AS] type

[ DEFAULT constante ]
[ [ CONSTRAINT nom_de_contrainte ] CHECK (prédicat) ] ;
dans une contrainte de domaine,
le mot clé VALUE représente 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 définit elle-même les tables composant l'Information Schema d'une base de données. Exem-
ples : DOMAINS, TABLES, COLUMNS, COLUMN_DOMAIN_USAGE ...

b) Définition des tables
La définition d'une table comporte le nom de la table, la définition des colonnes, la définition 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 à différentes tables peuvent avoir le même nom. Chaque colonne est décrite par son
domaine de valeurs. Si celui-ci a été répertorié par une commande CREATE DOMAIN, il suffit d'en mention-
ner le nom; sinon, la définition du domaine est faite localement.
Les contraintes qui peuvent être définies 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 (intégrité référentielle)
– CHECK (prédicat) = restriction portant sur des colonnes de la table
Les contraintes sont définies à la suite des colonnes. Cependant, par simplification, les contraintes portant sur
une seule colonne peuvent être incorporées à la définition de cette colonne.
Par définition, toute table possède un identifiant primaire; si la contrainte PRIMARY KEY n'est pas exprimée,
une contrainte PRIMARY KEY (toutes_les_colonnes) est implicitement définie.
Format : CREATE TABLE nom_de_table ( définition_de_colonne, ...

définition_de_contrainte, ... ) ;
Exemple : le schéma 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. représentant"
PRIMARY KEY (nom_delegue),
CONSTRAINT "région 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 -> représentant"
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é commandée > 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é livrée > 0"
CHECK (quantite_livree > 0),
montant_facture Prix,
PRIMARY KEY (no_facture, no_produit) );

Note sur les contraintes d'intégrité référentielle
Le format complet d'une contrainte d'intégrité référentielle est le suivant :
[ CONSTRAINT nom_de_contrainte ]
[ FOREIGN KEY (colonne_référençante, ...) ]
REFERENCES table [(colonne_référencée, ...) ]
[ ON UPDATE action ]
[ ON DELETE action ]
action : CASCADE | SET NULL | SET DEFAULT | NO ACTION
La clause REFERENCES mentionne les colonnes de la table référencée qui, dans l'ordre, doivent correspondre
aux colonnes dont est composé l'identifiant étranger (FOREIGN KEY); dans la table référencée, les colonnes
en cause doivent, dans le même ordre, former un identifiant primaire (PRIMARY KEY) ou candidat
(UNIQUE). Dans le cas de l'identifiant primaire, qui est le plus fréquent, on peut omettre la liste des colonnes
référencées.
La définition d'une contrainte d'intégrité référentielle indique quelle action le SGBD doit automatiquement
entreprendre sur la table référençante lorsque, dans la table référencée, l'identifiant concerné est modifié
(UPDATE) ou supprimé (DELETE) :
– ON UPDATE CASCADE = remplacer toutes les références par la nouvelle valeur de l'identifiant;
– ON DELETE CASCADE = supprimer en cascade toutes les occurrences référençantes;
– ON UPDATE|DELETE SET NULL = mettre les références à la valeur NULL ("inconnu");
– ON UPDATE|DELETE SET DEFAULT = donner aux colonnes référençantes leur valeur par défaut;
– ON UPDATE|DELETE NO ACTION = refuser la mise à jour de la table référencée;

on obtient le même effet si l'option ON n'est pas explicitée.
c) Définition des assertions
Une assertion est une contrainte qui n'est pas attachée à une table particulière; normalement, elle implique
plusieurs tables.
Format : CREATE ASSERTION nom_de_contrainte

CHECK (prédicat) ;
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 différence (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 vérification des contraintes
Une base de données se trouve dans un état cohérent lorsqu'elle est conforme aux contraintes d'intégrité défi-
nies.
On appelle transaction une suite d'opérations de consultation et/ou mise à jour de la base de données qui,
partant d'un état cohérent de celle-ci, la restitue dans un état cohérent. Entre les deux instants de début et fin
d'une transaction, l'état de la base de données peut être non conforme. (Cette incohérence temporaire est in-
dispensable pour pouvoir enregistrer l'en-tête 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 clôturant la transaction
-- d'enregistrement de la commande 315
La vérification d'une contrainte peut être immédiate, c'est-à-dire effectuée immédiatement avant l'exécution de
toute opération de mise à jour susceptible de la violer; elle peut aussi être différée jusqu'à l'exécution de l'ins-
truction COMMIT qui clôture la transaction de mise à jour. En SQL, la définition de toute contrainte peut se
terminer par une option indiquant le dispositif enclenché au démarrage de toute transaction : INITIALLY
IMMEDIATE (par défaut) ou INITIALLY DEFERRED.2 (La seconde option s'impose pour la contrainte
"commande non vide" définie ci-dessus.)
d) Mise à jour automatique des données dérivables
Il n’est pas rare qu’une base de données contienne des données redondantes, autres que les clés étrangères.
C’est le résultat des dénormalisations effectuées en vue d’optimiser l’accès aux données.3
Exemples : • propagation parent ==> enfants

–– adresse du client recopiée dans l’en-tête de facture
une modification d’adresse doit être répercutée dans toutes les factures du client
• dérivation parent(s) ==> enfants

–– montant facturé inscrit dans chaque ligne de facture
une modification de prix au tarif doit entraîner un nouveau calcul des montants facturés
1 La gestion des transactions possède une seconde utilité. Telles que nous les avons définies ici, les transac-
tions garantissent la cohérence objective de la base de données; elles ne garantissent pas la cohérence de la
perception qu'en ont les utilisateurs. Retenons l'hypothèse d'un accès simultané de plusieurs utilisateurs ou
programmes à la base de données. Pendant que l'utilisateur A enregistre un bon de commande, tout autre utili-
sateur B qui consulterait ou mettrait à jour les stocks, aurait en réalité accès à des informations incertaines. La
solution consiste à limiter temporairement — jusqu'à la fin de la transaction —, et automatiquement, les pos-
sibilités d'action et donc d'interférence des autres utilisateurs : inconfort momentané, mais garantie d'exacti-
tude des données.
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 défaire une ou plusieurs opérations de mise à jour qui auraient violé
une contrainte testée a posteriori. C'est pourquoi, en SQL, la vérification des contraintes est, par défaut, im-
médiate.
3 Cf. chapitre 4.

• récapitulation enfant(s) ==> parent
–– total facturé inscrit dans chaque facture
la modification ou la suppression d’une ligne de facture implique un ajustement du total
La possibilité existe d’attacher à une opération de mise à jour une opération de mise à jour complémentaire
des données dérivées, déclenchée ("triggered") automatiquement. Pour cela, on enregistre dans le diction-
naire de la base de données une gâchette ("trigger").1
Format : CREATE TRIGGER nom_de_gâchette ON table

événement_déclencheur
actions_déclenchées ;
événement_déclencheur : avant_après opération_déclenchante

avant_après : BEFORE | AFTER
opération_déclenchante : INSERT ON table |
DELETE ON table |
UPDATE [ OF colonne, ... ] ON table
[ REFERENCING OLD AS alias NEW AS alias ]
– L’insertion, la suppression ou la modification (des colonnes indiquées) d’une ligne dans la table est
considérée comme un événement déclencheur; la préposition BEFORE ou AFTER indique si les actions dé-
clenchées doivent être exécutées avant ou après la mise à jour déclenchante.
– Les actions déclenchées ont accès aux données présentes dans la base de données. On écrira donc habi-
tuellement AFTER INSERT et BEFORE DELETE.
– Dans le cas d’une modification par UPDATE, on doit souvent référencer à la fois les anciennes et les nou-
velles valeurs des colonnes de la table. Les alias attribués par la clause REFERENCING permettent de les
distinguer : pour chaque alias est créée une copie temporaire des valeurs soit anciennes, soit nouvelles.
Habituellement, on déclarera un seul alias : OLD avec l’événement AFTER UPDATE, NEW avec l’événe-
ment BEFORE UPDATE.
actions_déclenchées : [ FOR EACH ROW ]

[ WHEN (prédicat) ]
BEGIN mise_à_jour ; ... END
– Chaque opération de mise à jour est une instruction INSERT, UPDATE ou DELETE.
– La condition restrictive de la clause WHEN peut préciser les cas où les mises à jour complémentaires doi-
vent être déclenchées.
– Par défaut, l’action déclenchée est exécutée une seule fois. L’option FOR EACH ROW ordonne de la ré-
péter pour chaque ligne mise à jour par l’événement déclencheur.
Dans les exemples ci-dessous, toute mise à jour complémentaire consiste à modifier une valeur dans
un n-uplet existant dans une table de la base de données :
UPDATE table
SET colonne = valeur
WHERE prédicat -- condition identifiant la ligne modifiée
1 La métaphore de la gâchette évoque l'enchaînement automatique des actions : pression sur la détente, per-
cussion du projectile.

Exemple : gestion automatique du total facturé
(a) définition des tables :
CREATE TABLE facture

( no_facture NUMERIC(5) DEFAULT 0 -- dérivable
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 ); -- dérivable
– puisqu'ils seront dérivés automatiquement,
le numéro et le total sont aussi initialisés automatiquement
– pour créer l'en-tête d'une facture, il suffira de fournir le numéro 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é livrée > 0"
CHECK (quantite_livree > 0),
montant_facture Prix,
PRIMARY KEY (no_facture, no_produit) );
– la contrainte sur le numéro de facture garantit que l'en-tête de la facture préexiste
(b) définition des mises à jour automatiques :
création de l'enregistrement Facture ==> création du numéro 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 "création 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 présentés comme complétant les contraintes d'intégrité référen-
tielle.
e) Les vues
Une vue constitue une présentation alternative d'une partie du contenu de la base de données. Pour l’utilisa-
teur (ou le programme), une vue prend la forme d'une table manipulable comme n'importe quelle autre; le
SGBD répercute sur les tables réelles les opérations entreprises sur une vue.
L'intérêt d'une vue est d'offrir à un utilisateur de la base de données une présentation des données adaptée à ses
besoins particuliers. Il peut aussi être de protéger la confidentialité des données, en restreignant l'accès au
sous-ensemble des données présentées par une vue sur laquelle l'utilisateur possède un droit d'accès.
Format : CREATE VIEW nom_de_vue [(noms_de_colonnes)]

AS sélection
Exemples : données masquées (sélection 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;
définition de sous-types (sélection 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 possibilités offertes par le langage SQL en matière de définition de vues sont beaucoup plus étendues que
celles qui se trouvent illustrées dans ces exemples. Par exemple, il est possible de définir une vue embrassant
un groupe de tables associées par le biais d'identifiants étrangers.
f) Création d’index
Un schéma de base de données tel que celui montré en exemple ci-dessus est opérationnel. Pourtant, il ne
contient aucune indication relative aux aspects matériels du stockage des données dans l'espace d'un support;
il reste une définition purement conceptuelle. C'est une particularité des SGBD relationnels qu'ils puissent
fonctionner sur une telle définition.
Néanmoins, si l'on veut améliorer les performances du SGBD en accélérant les opérations d'accès aux don-
nées, il sera nécessaire d'établir certaines options relatives au stockage physique des données. Ces options
sont spécifiques à chaque SGBD; cependant, il existe une structure physique commune à tous les systèmes, et
pourtant ignorée de la norme SQL : les index.
La fonction d'un index dans une base de données est analogue à celle d'un index dans un ouvrage imprimé.
L'index d'un livre associe à chaque mot clé le numéro des pages où figure ce mot; un tel index accélère la re-
cherche dans l'ouvrage, en épargnant au lecteur de devoir parcourir intégralement toutes les pages du volume.
Qui plus est, le fait que l'index soit ordonné (les mots clés y sont rangés par ordre alphabétique) accélère la
consultation de l'index lui-même : cette consultation peut procéder par sauts. Une base de données est égale-
ment physiquement découpée en pages, par exemple de 512 ou 1024 octets. A la demande de l'administrateur
de la base de données, 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 associés les numéros des pages où
cette valeur est enregistrée.
L'opération principale d'un langage relationnel est la requête SELECT, sélection définie par des critères de
sélection. Toute colonne de toute table peut servir de critère de sélection dans une requête. Sans index, l'in-
terrogation, pour établir la sélection, doit généralement examiner toutes les occurrences du critère présentes
dans la base de données; cet examen peut impliquer le parcours d'un espace matériel important. Un index est
un accélérateur des opérations de recherche et de tri.
Quelles tables et colonnes convient-il d'indexer ?
La collection représentée par la table doit être suffisamment importante (> 200-300 lignes ?), sans
quoi l'examen séquentiel de la table est généralement plus performant.
Les colonnes indexées doivent être fréquemment citées en guise de critères de sélection ou de tri et, à
la fois, s'avérer hautement discriminantes (on n'indexe pas une colonne qui ne peut prendre que 4
valeurs différentes !). Tel est généralement le cas des identifiants, primaires, candidats et étrangers.
Format : CREATE [UNIQUE] INDEX nom d'index

ON table (colonne, ...) ;
le qualificatif UNIQUE définit un index univoque 1
1Avant que le langage SQL permît d'exprimer les contraintes d'intégrité, cette particularité était utilisée pour
garantir l'univocité d'un identifiant.

Exemples : indexation des identifiants et références du schéma précédent :
CREATE UNIQUE INDEX representant_0 -- clé primaire

ON representant (nom_delegue);
CREATE INDEX representant_region -- clé étrangère
ON representant (region);
CREATE UNIQUE INDEX client_0 -- clé primaire

ON client (no_client);
CREATE INDEX client_representant -- clé étrangère
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é étrangère
ON produit (nom_produit);
CREATE UNIQUE INDEX commande_0 -- clé primaire

ON commande (no_commande);
CREATE INDEX commande_client -- clé étrangère
ON commande (no_client);
.....
Dans une base de données relationnelle, les index sont toujours facultatifs; ils peuvent être créés (par une
commande CREATE INDEX) et supprimés (par une commande DROP INDEX) à tout moment.
2.3. La manipulation des données
a) Opérations disponibles
Consultation : SELECT
La consultation d'une base de données relationnelle procède par requêtes sélectionnant une partie des données
de la base. Le résultat d’une sélection est une collection de données formant elle-même une relation ou table
virtuelle.
Le format de base d'une requête SELECT en langage SQL est le suivant :
Format : SELECT liste de données (ou *, signifiant tous les attributs)

FROM liste de tables [ WHERE prédicat ]
– les données affichées ou testées sont,
non seulement des variables de la base de données (des colonnes),
mais aussi des constantes ou des données calculées
– la clause WHERE identifie par son prédicat les lignes à retenir dans la sélection
Il existe des formes de requêtes plus développées et, de plus, les résultats de plusieurs requêtes peuvent être
combinés, notamment par des opérateurs ensemblistes (union, intersection, différence).

Création de lignes : INSERT
L'opération 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 remplacées par leur valeur par défaut si on
en a défini une, sinon par NULL (les contraintes définies sur la table doivent évidemment autoriser ces va-
leurs NULL).
Une première forme insère une ou plusieurs lignes composées à partir de valeurs littérales, une seconde forme
insère dans la table le résultat d'une sélection.
Formats : INSERT INTO table [(colonne, ...)]

VALUES (valeur, ...), ...
INSERT INTO table [(colonne, ...)]

requête_SELECT
– si l'on omet la liste de colonnes,

les colonnes sont prises dans l'ordre de leur définition 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'opération UPDATE modifie certaines valeurs dans des lignes existantes. Les lignes à modifier sont identi-
fiées par la condition formulée dans la clause WHERE; à défaut de cette clause, toutes les lignes de la table
sont modifiées.
Format : UPDATE table

SET colonne = valeur, ... (valeur ou DEFAULT ou NULL)
[ WHERE prédicat ]
Suppression de lignes : DELETE
L'opération DELETE supprime certaines lignes dans une table. Les lignes à supprimer sont identifiées par la
condition formulée dans la clause WHERE; à défaut de clause WHERE, toutes les lignes de la table sont sup-
primées.
Format : DELETE FROM table [ WHERE prédicat ]
Exemple : suppression d'une commande :

DELETE FROM commande WHERE no_commande = 308;
-- en vertu d'une contrainte REFERENCES,
-- les lignes de commandes sont supprimées en cascade
b) Modes d'utilisation du langage SQL
A l'origine, le langage SQL a été conçu 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'intégrer aux langages de programmation habituels, sous deux formes : SQL
inséré ("embedded SQL") pour la rédaction de requêtes figées et prédéfinies, SQL dynamique pour la ré-
daction de requêtes variables d'une exécution à l'autre du programme.

Dans les années 1990 se sont développés différents outils d'accès aux bases de données relationnelles, qui tra-
duisent leurs requêtes en SQL. Pour ces outils, SQL sert de référence. Citons les outils d'interface graphi-
que qui intègrent la manipulation des bases de données à des programmes fonctionnant dans un environne-
ment graphique comme, par exemple, MS-Windows. Citons également les bibliothèques de fonctions
comme ODBC ("Open Data Base Connectivity") de Microsoft, appelables par les programmes.1
c) SQL inséré
Comment un programme rédigé en COBOL ou en C, par exemple, accède-t-il à une base de données relation-
nelle ? Nous nous contenterons ici de décrire la première des possibilités à avoir été offerte aux program-
meurs : l’emploi d’instructions SQL insérées ou "serties" ("embedded SQL"), moyennant certains aménage-
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 hôte.
Repérage des instructions SQL insérées
Comment le pré-compilateur repère-t-il dans le texte les phrases SQL ? Toute instruction SQL est préfixée
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 données
Comment échanger des données entre les instructions SQL et celles du langage hôte ?
Partout où, dans une instruction SQL, peut être indiquée une valeur littérale, on peut, en lieu et place, indiquer
le nom d'une variable du programme hôte; des variables du programme hôte sont également employées pour
recevoir les résultats d'une requête de sélection. Pour le distinguer des autres noms manipulés par SQL, le
nom d'une variable du programme hôte est préfixé par deux points (:nom_de_variable).3
Ces données doivent, dans les deux langages SQL et hôte, être d'un type équivalent.4 De plus, dans le texte du
programme, la déclaration des variables accessibles à SQL doit être comprise entre les deux repères EXEC
SQL BEGIN DECLARE SECTION et EXEC SQL END DECLARE SECTION; grâce à cette dernière conven-
tion, le pré-compilateur SQL pourra prendre note du format défini pour ces données.
Signalisation des incidents
Divers moyens sont offerts au programme pour connaître les incidents éventuels ou conditions d'exception qui
se sont produits pendant l'exécution de chaque opération SQL. Voici le plus simple : au terme de toute exé-
cution d'une instruction SQL, le programme hôte peut tester le code de retour rangé dans l'indicateur de nom
SQLSTATE (cet indicateur est une variable du programme hôte).
1 Ces bibliothèques d'"Application Programming Interface" (API) fournissent des fonctions qui se substi-
tuent aux clauses du langage SQL inséré. Ce nouveau procédé ne nécessite pas l'intervention d'un pré-
compilateur des requêtes SQL placées dans le programme; le programme peut donc être créé — et s'exécuter
— sur un ordinateur client n'ayant pas accès aux outils de développement particuliers du SGBD.
2 Car, en COBOL, le point-virgule est un séparateur facultatif et sans signification.
3 SQL ne pouvant ni indicer ni qualifier les noms des variables hôtes, celles-ci ne peuvent pas être membres
d'une structure ou d'un tableau.
4 La norme SQL définit les équivalences pour un certain nombre de langages.

Les curseurs
En toute généralité, le résultat d'une requête de sélection est un ensemble de lignes que, normalement, le pro-
gramme voudra traiter une à une. A cette fin, on associe un "curseur" à la sélection qui, grâce à une instruc-
tion FETCH, avancera ligne par ligne dans la sélection. Un curseur doit être "ouvert" (initialisé) et "fermé";
une autre manière de voir est donc de considérer le résultat d'une requête comme un fichier parcouru séquen-
tiellement.1
Format : DECLARE nom_de_curseur [INSENSITIVE] [SCROLL] CURSOR

FOR requête [ ORDER BY { colonne [sens] } , ... ]
[ FOR UPDATE [ OF (liste de colonnes) ] ]
sens : le sens du tri est indiqué par ASC(ending), par défaut, ou DESC(ending)
Le qualificatif INSENSITIVE déclare le curseur "insensible" aux mises à jour concurrentes qui
pourraient survenir entre les opérations OPEN et CLOSE d'ouverture et fermeture du curseur. En ré-
alité, le SGBD crée une copie de la sélection opérée, et c'est à cette copie que le programme accède
par l'opération FETCH.
L'option SCROLL définit un curseur "déroulant"; les lignes de la sélection sont numérotées (analo-
gie avec un fichier relatif) et le programme peut se déplacer librement à l'intérieur de la sélection.
En l'absence de cette clause, toute opération FETCH obtient la ligne suivante par rapport à la position
courante (analogie avec un fichier séquentiel).
L'option ORDER BY permet de déterminer l'ordre de succession des lignes dans la sélection.
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 sélection; si l'on indique une liste de co-
lonnes, la possibilité de mise à jour est limitée à ces colonnes. Par défaut, un curseur est défini FOR
READ ONLY; il ne permet pas la mise à jour.
Exemple COBOL
Voici une version COBOL-SQL de référence pour le programme de facturation donné en exemple à la fin du
chapitre 4.2 On remarquera que la structure du programme est inchangée; les seules différences tiennent au
remplacement des instructions COBOL d’accès aux fichiers par des instructions SQL d’accès à la base de
données.
Une seule transaction est définie, dans laquelle on commence par dresser la liste des commandes à facturer;
toutes ces commandes sont protégées contre l'accès concurrent pendant toute la durée du programme (une
mise à jour des lignes de ces commandes sera également impossible, car les accès à la table Commande né-
cessités par la vérification des contraintes seront refusés).
Le programme utilise deux curseurs : un curseur sur la liste des numéros des commandes à facturer et — ré-
pétitivement — un curseur parcourant l’ensemble des lignes de chaque commande.
1 Une requête produisant un singleton, c'est-à-dire un ensemble d'une seule ligne, peut, plus simplement, s'ef-
fectuer au moyen d'une instruction SELECT adaptée de manière à fournir une liste de variables réceptrices :
SELECT liste de données 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 opérations SQL :

77 SQLSTATE PIC X(5).
* variables du programme accessibles aux opérations 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.
* opération non illustrée
Traiter-Fichier.
* définir les modalités de l'unique transaction du programme

* (mise à jour = READ + WRITE,
* protection contre l'accès 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
* arrêter 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 clôturer 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
* clôturer la facture (date par défaut = 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 numéro 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 l’opération OPEN effectuant la sélection doit être répétée pour chaque commande à traiter, l’instruction
DECLARE CURSOR définissant les modalités de la sélection pourrait n’être exécutée qu’une seule fois (elle
figurerait alors immédiatement après le commentaire "établir les factures").

* calculer la quantite livrée :
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 néglige 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
.

Chapitre 6. Introduction à la modélisation des systèmes
Un système est un objet dynamique complexe, dont on veut décrire le fonctionnement. Le concept de système
et la méthodologie d'analyse des systèmes sont communs à un grand nombre de disciplines; citons : la biolo-
gie, les sciences de l'ingénieur, l'étude des organisations, l'informatique ... Un système est d'ailleurs sans doute
plus un mode de représentation, un modèle, qu'une réalité concrète.1
Ce chapitre dresse une nomenclature des niveaux de hiérarchisation des systèmes de traitement de l’informa-
tion.
Le chapitre 7 présente différentes variantes de schémas connus sous le nom générique de diagrammes de flux
(de données, de signaux, d’événements ...). Ces modèles sont nés dans le contexte ancien des programmes de
"traitement par lots", incapables de "converser" avec un utilisateur humain, caractéristiques des premières
réalisations de l’informatique de gestion.
Le chapitre 8 est dédié aux méthodes d’analyse nées dans le sillage de la programmation par objets. Il traite
d’abord brièvement de la spécification des opérations effectuées par les objets. Il s’attache ensuite à exposer
le modèle des cas d’utilisation mis au point par le Suédois I. JACOBSON2 (de création plus récente, ce mo-
dèle veut apporter une réponse aux problèmes de l’informatique interactive ou conversationnelle et de la pro-
grammation par objets). Le chapitre se termine par quelques considérations sur la conception d’une architec-
ture logicielle, illustrées par le principe d’architecture client–serveur et les patterns ou motifs architecturaux.
Les schémas décrits ici recueillent un franc succès auprès des analystes ... et de leurs clients ou
commanditaires. En effet, n’utilisant pas de concepts sophistiqués que seuls des spécialistes jargon-
nants seraient à même de manipuler, ils se révèlent très "parlants" pour les profanes et constituent un
support de choix pour le dialogue de l’informaticien avec ses commanditaires.
AVERTISSEMENT. L'étude du fonctionnement des systèmes d'informations utilise des termes comme
"fonction, procédure, tâche, processus" ... dont la signification est loin d'être fixée et unanimement comprise.
Au contraire, chaque méthode, chaque auteur définit sa propre terminologie.
1Cf. J.L. LE MOIGNE : La théorie du système général; 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 développement logiciel, trad. française; Eyrolles,
1999.
© A. CLARINVAL Analyse — Modélisation des systèmes 6-1

1. Hiérarchisation du système d'information
Le fonctionnement d'un système de traitement de l'information est décrit en termes d'activités, ou ensembles
d'opérations, auxquels on donne le nom de processus. Afin d'en maîtriser la complexité, l'analyse des systè-
mes procède par décomposition, en distinguant différents niveaux d'agrégation des opérations.
Nous distinguerons trois niveaux de processus : système, tâche, module.
1.1. Système
Un système, en particulier un système d'information, possède les propriétés dynamiques suivantes : c'est
– un ensemble permanent
– d'activités récurrentes.
Beaucoup des activités récurrentes d'un système sont périodiques, c'est-à-dire qu'elles se reproduisent à des
intervalles de temps déterminés.
Exemple : SYSTEME : administration des salaires :

ACTIVITES : enregistrement des modifications de la situation du personnel (occasionnel)
enregistrement des prestations (quotidien)
calcul et paiement des rémunérations (mensuel)
établissement des attestations et documents légaux (annuel)
Appelons système le référentiel analysé; il peut être décomposé en sous-systèmes, qui possèdent eux-mêmes
toutes les propriétés dynamiques d'un système; un sous-système peut être décomposé en sous-sous-systèmes,
et ainsi de suite.
Dans la pratique, les critères d'individualisation d'un sous-système d'information sont principalement organi-
sationnels. L'activité d'une entreprise — le système "opérant" — est organisée en grandes fonctions ou finali-
tés internes : gestion de la production, gestion financière, gestion du personnel ... Chaque grande fonction se
reflète dans un sous-système d'information.
Exemples : entreprise :
gestion du personnel :
recrutement, formation, promotions
administration des salaires
gestion financière :
trésorerie
comptabilité :
comptabilité générale
budget
comptabilité analytique
..........

Au sein d'un organisme possédant différents sièges ou filiales, on distinguera un sous-système propre à cha-
cune des entités ... Les sous-systèmes particuliers aux différents sièges d'un organisme sont éventuellement du
même type, c'est-à-dire qu'ils font l'objet d'une définition identique.1
1.2. Tâche
Une tâche est un ensemble d'opérations passant pour élémentaire aux yeux de l'utilisateur "client" du système,
– que cet utilisateur alimente en données et dont il attend des résultats,

– au fonctionnement duquel il affecte des ressources : moment, durée, localisation, machines, personnel ...
Exemples : TACHE : enregistrement des modifications de situation du personnel

DONNEES : données "familiales" communiquées par l'employé
données "professionnelles" reçues du service employeur
RESULTATS : fichier signalétique mis à jour
RESSOURCES : employé du service du personnel
ordinateur personnel connecté à l'ordinateur central
TACHE : calcul des rémunérations

DONNEES : fichier signalétique du personnel
prestations mensuelles enregistrées
RESULTATS : fiches de paie
virements bancaires
RESSOURCES : ordinateur central
entre le 5e et le 3e jours ouvrables avant fin de mois
durée estimée = 2 heures
On associe souvent la tâche à un événement déclencheur ou une combinaison d'événements déclencheurs.
Exemples : TACHE : enregistrement des modifications de situation du personnel

EVENEMENTS : toute information pertinente reçue
des membres du personnel
ou des services employeurs

EVENEMENTS : derniers jours ouvrables du mois
demande du service responsable
Une des ressources affectées à une tâche est le processeur qui l'exécute. De ce point de vue, les tâches de
traitement de l'information se répartissent en :
– tâches automatiques, exécutées par un programme d'ordinateur, sans intervention humaine;

– tâches "manuelles" (sic), effectuées par l'être humain sans recours à l'ordinateur;
– tâches interactives, faisant dialoguer un programme d'ordinateur et un opérateur humain.
Exemples : TACHE interactive : enregistrement des modifications de situation du personnel

TACHE automatique : calcul des rémunérations = établissement de la paie
TACHE "manuelle" : distribution des fiches de paie
1 Rappelons que le concept de type, classe des objets vérifiant une même définition, est tout à fait général.
Les objets dynamiques du traitement de l'information, dont il est question dans le présent chapitre, sont eux
aussi classés par types.

Programme
Il n'est pas rare qu'une tâche automatique, par exemple l'établissement de la paie du personnel, nécessite d'en-
chaîner l'exécution de plusieurs programmes ... Une tâche interactive implique souvent la coopération de
deux programmes dans une architecture "client/serveur", un programme gérant le travail du "client" à l'écran,
un autre se chargeant des accès à la base de données au "service" des différents clients; ces deux programmes
s'exécutent 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 présente comme une sorte de boîte à outils
dont les composants sont utilisés par des tâches diverses; tel est le cas d’un tableur, mais aussi d’un pro-
gramme permettant de créer, mettre à jour, consulter et imprimer, par exemple, des fiches Clients ...
Ces exemples montrent à suffisance qu'un programme n'est qu'une des ressources affectées à l'exécution d'une
tâche. (Et il existe des tâches n’utilisant pas de programmes : les tâches "manuelles".)
Objet
Au concept de programme concourant à l'exécution d'une tâche, a tendance aujourd'hui à se substituer celui
d'objet programmé, capable d'effectuer certaines opérations et ainsi de rendre des "services". Un objet pro-
grammé est capable de plus d'opérations qu'une tâche particulière n'en utilise (c'est pourquoi, au lieu de parler
de tâches, les méthodologies "orientées objets" parlent de cas d'utilisation1).
Tâche = Transaction
Appelons transaction une séquence d'opérations (d'un ou plusieurs acteurs, processeurs, programmes ou
objets) dont la terminaison est le minimum nécessaire pour que le traitement soit cohérent, c'est-à-dire
conforme aux règles établies.2 Exemples : les opérations d'enregistrement d'un bon de commande, les opéra-
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 procédure, les liens de causalité —, concernent essentiellement les transactions. Cette observation
justifie d'assimiler la tâche à une transaction (plutôt qu'à l'exécution complète d'un ou plusieurs programmes).
S'il existe des règles portant sur un ensemble de transactions élémentaires (exemple : la facturation–livraison
est quotidienne; elle traite en priorité les commandes les plus anciennes), on a affaire à une tâche comportant
une hiérarchie de règles et, par conséquent, différents niveaux de transactions, élémentaires et composites.
Commentaires
Selon F. BODART et Y. PIGNEUR,3 qui disent "phase" plutôt que "tâche", "Le concept de 'phase' constitue
le repère central de la nomenclature par la signification qu'il présente sur trois plans d'analyse. Au plan
informationnel, la phase est un lieu d'identification [...] de règles de traitement. [...] Au plan économi-
que, elle est un lieu d'allocation des ressources humaines, matérielles et logicielles, nécessaires à son exécu-
tion. Au plan organisationnel, elle est un lieu de redéfinition des structures d'organisation : tâches, fonc-
tions, rôles, responsabilités, postes de travail. [...] La phase constitue [...] le lieu élémentaire d'analyse des
changements à apporter à un système d'information : changement des règles de mémorisation 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 données constitue un cas particulier de la définition plus
générale proposée ici. Cf. chapitre 5.
3 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information : méthodes, modèles, outils;
Masson, 1989.

De plus, pour l'informaticien, ce niveau constitue le point d'articulation de deux méthodologies nettement dif-
férentes par leurs objectifs pratiques : l'analyse interne d'une tâche doit produire une description programma-
ble, tandis que l'analyse des niveaux supérieurs — système et sous-systèmes — ne doit ordinairement produire
que de la documentation.
1.3. Module
Un module est un ensemble d’organes (objets) et/ou d'opérations élémentaire aux yeux du technicien créa-
teur d’un système de traitement de l'information. L'exécution d'une tâche met en œuvre un ou plusieurs mo-
dules et ce sont ces derniers qui, finalement, assument la responsabilité des traitements.
Un module est généralement confondu avec un composant programmable; il possède donc une forme concrète
liée aux moyens de conception et de réalisation dont disposent les programmeurs. Si, naguère, ces moyens
apparaissaient uniformes — un module prenait l'aspect d'un sous-programme —, ils sont aujourd'hui très
divers. Cependant, ces nouvelles espèces de composants, pré-programmés ou non, se présentent habituelle-
ment sous la forme d’objets plus ou moins explicitement conformes à la définition proposée par le paradigme
de la programmation par objets :
un objet est une entité

– qui se trouve dans un état, décrit par des attributs,
– et qui, capable de certaines opérations, possède un comportement
lui permettant de réagir à des événements signalés par des messages.

2. Niveaux intermédiaires
Si, parce qu'ils se rencontrent dans la réalité des systèmes de traitement de l'information, les niveaux de
(dé)composition définis ci-dessus doivent se retrouver dans toute analyse, il est loisible au concepteur de dis-
tinguer des niveaux intermédiaires. Ne correspondant à aucun objet précis dans la réalité, ces niveaux pure-
ment artificiels sont distingués pour la commodité de la représentation mentale ou de la planification du travail
d'informatisation ...
Dans le contexte des études et travaux d'informatisation, on s'attaque à un projet informatique, découpé en
applications informatiques. Un projet concerne un sous-système d'information. Une application peut recou-
vrir un sous-sous-système ou apparaître plus ou moins comme un sous-ensemble artificiel, isolé pour les be-
soins du travail d'informatisation.
Dans la décomposition d'un système, l'analyste peut faire apparaître des groupes de tâches entre lesquelles
existent des liens particuliers de complémentarité (ex.: ensemble des tâches composant le "traitement des
commandes–clients") ou de similitude (ex.: groupe des tâches d'"édition de statistiques"). Un groupe de
tâches suffisamment vaste pourra être géré comme une application ...
Il est possible de définir des niveaux intermédiaires entre la tâche et le module de base; appelons composi-
tions de modules ces agrégats. A part le fait qu'elle n'est pas élémentaire, semblable composition possède
toutes les propriétés d'un module.
SYSTEME
SOUS-SYSTEME projet
application
groupe de tâches
TACHE
programme
composition de modules
MODULE
NOTE. Introduisant la modélisation conceptuelle des données, nous disions que l’analyste décrivait par ce
moyen un domaine d’application.1 Il s’agit maintenant de décrire les applications qui seront déployées dans
ce domaine.
1 Cf. chapitre 3.

Chapitre 7. Les diagrammes de flux
Outils privilégiés, les diagrammes de flux entre activités sont utilisés par toutes les méthodologies d'analyse
des systèmes d'informations. Ces diagrammes possèdent de nombreuses variantes; grâce à telle ou telle parti-
cularités, ils permettent à l’analyste d’étudier le système d’information sous différents angles.
Nous présentons dans ce chapitre trois formes de diagrammes de flux :
– les diagrammes de flux de données, schémas fonctionnels décrivant l’utilité des traitements;
– les diagrammes d’enchaînement dynamique, qui en décrivent les contraintes (d’enchaînement);
– les diagrammes de déploiement, qui mettent en évidence les ressources nécessaires à leur exécution.
© A. CLARINVAL Analyse — Diagrammes de flux 7-1

1. Schéma fonctionnel
Un objet dynamique, en particulier un système, poursuit une finalité que nous appellerons sa fonction. L'ana-
lyse d'un système d'information doit expliquer comment celui-ci remplit sa triple fonction de mémoriser,
transformer et diffuser de l'information. Ce comportement est défini par des règles de procédure.
Le schéma fonctionnel d'un système d'information doit en même temps maîtriser la complexité inhérente à ce
système; il fournit donc des moyens pour en décrire la structure en termes de composants plus simples. On
se sert pour cela de diagrammes de flux de données. Ces diagrammes possèdent de nombreuses variantes, et
plusieurs manières de les utiliser sont préconisées. Citons, entre autres, l'école américaine de la "Structured
Analysis", particulièrement représentée 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 communiquée. Un système d'information appartient donc à la caté-
gorie des systèmes "ouverts", possédant un environnement avec lequel ils échangent des données. Concrè-
tement, le système d'information d'une entreprise se trouve en communication avec le système opérant et le
système de décision de cette entreprise; il réalise également des échanges avec (les systèmes d'information
de) l'environnement socio-économique de l'entreprise : clients et fournisseurs, bien sûr, mais aussi le minis-
tère des finances (service de la TVA), etc ...
Quant à l'environnement d'un sous-système, il est constitué des autres sous-systèmes avec lesquels il échange
de l'information; par exemple, bon nombre des sous-systèmes d'une entreprise commerciale échangent des
données avec le sous-système comptable de cette entreprise.
Par définition, l'environnement du système de référence n'est pas analysé; il est simplement perçu comme un
ensemble de processeurs ou acteurs (fournisseurs, clients, etc.) susceptibles d'activités non précisées.
Acteur Banque
externe
Clients Fourniss.
1C. 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 — système, sous-système, tâche ou module (sous-
programme) — se décrit aisément comme étant une transformation de données d'entrée en données de sor-
tie.1 La notion de transformation doit être entendue dans un sens large : il ne s'agit pas seulement des opéra-
tions changeant la forme des données, mais également de celles qui en modifient la localisation dans l'espace
ou le temps; ainsi considérera-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 gérer la rémunération des prestations du personnel
ENTREES : données signalétiques du personnel
prestations
SORTIES : rémunérations, cotisations, impôts
documents légaux
TACHE : enregistrement des modifications de situation du personnel

FONCTION : enregistrer toute modification de situation
influant sur le calcul des rémunérations
(= codifier et copier)
ENTREES : données "familiales" communiquées par l'employé
données "professionnelles" reçues du service employeur
SORTIES : fichier signalétique mis à jour

FONCTION : calculer les montants des rémunérations et retenues diverses
(= valoriser les prestations)
éditer les documents accompagnant les paiements
ENTREES : fichier signalétique du personnel
prestations mensuelles enregistrées
SORTIES : fiches de paie
virements bancaires
MODULE : calcul de l'impôt

FONCTION : calculer le montant de l'impôt à retenir sur le salaire mensuel
ENTREES : montant du salaire imposable
barèmes d'imposition
SORTIES : montant de l'impôt, montant net du salaire
On a évoqué au paragraphe précédent les échanges d'un système ou sous-système, processus permanent, avec
son environnement. Un processus ponctuel, tâche ou module, qui ne produirait pas de données de sortie ne
présenterait aucun intérêt. En revanche, l'ensemble des données d'entrée d'un tel processus pourrait, à la limi-
te, être vide (ex.: le module–fonction rand() du langage C fournissant des nombres pseudo-aléatoires).
Adoptant un vocabulaire dynamique, on dira que tout processus possède au moins un flux de données entran-
tes et au moins un flux de données sortantes. Ceci peut être schématisé par une figure à laquelle on donne le
nom de boîte noire (parce qu'elle cache le "comment" de la transformation).
1 Ce schéma fonctionnel est valide pour tous les systèmes, pas seulement les systèmes d'information.

Tâche
Fiches
Calcul des
Prestations de paie
Rémunérations
Niveau mensuelles Virements
Processus bancaires
Entrées Sorties Automatique
Acteur Signalétique
Travailleurs
Nous nous intéressons dans cette partie du cours à l'ordonnancement et la spécification des tâches d'un
système de traitement de l'information et nous n'y envisagerons le module que comme un moyen de décrire
une tâche.
c) Flux de données
La description interne d'un processus non élémentaire en dévoile la structure sous la forme de sous-processus
reliés par des flux de données. Le schéma de cette structure est un diagramme de flux. Par convention, tous
les sous-processus recensés sur un tel diagramme sont du même niveau d'agrégation; on distingue donc des
diagrammes de flux
– entre sous-systèmes d'un même système ou d'un même sous-système hiérarchiquement supérieur,
– entre tâches (singletons) ou groupes de tâches d'un même sous-système,
– entre modules (singletons) ou compositions de modules dans une tâche.
Par convention, tout flux de données possède une et une seule origine, une et une seule destination, mais
plusieurs flux pourraient avoir un contenu identique, c'est-à-dire véhiculer des copies des mêmes données.1
Tout flux est orienté : de son origine vers sa destination. Il se représente graphiquement par une flèche.
REMARQUE. On le verra à la lecture des exemples : les flux de données à l'intérieur du système d'informa-
tion reflètent souvent, en une sorte d'"image", les flux concrets (de matières, de services ...) qui s'écoulent à
l'intérieur du système opérant de l'entreprise.
Flux direct, Messages
Si la collection de données véhiculées par un flux est "consommée" par le processus récepteur; c'est-à-dire que
l'utilisation des données par ce processus les prive de toute nouvelle utilité, il s'agit d'un flux direct entre deux
processus et la période de conservation des données véhiculées est égale à la période qui sépare l'exécution
des deux processus émetteur et consommateur.
1 Certaines méthodes admettent les regroupements et éclatements de flux, c'est-à-dire qu'elles autorisent des
flux aux origines ou destinations multiples. Le procédé présente l'inconvénient de masquer l'existence du pro-
cessus qui opère le regroupement ou l'éclatement.

GANE & SARSON DE MARCO
1
Enregistr.
Enregistr.
Commandes
Commandes
Réservations Réservations
2
Préparation
Préparation
Livraisons
Livraisons
Un flux direct peut être cyclique, c'est-à-dire qu'il relie deux exécutions successives d'un même processus :
sortant de l'exécution t, entrant pour l'exécution t+1.

1
Enregistr.
Enregistr.
Commandes
Commandes
Réservations Réservations
Commandes Commandes
différées différées
2
Préparation
Préparation
Livraisons
Livraisons
Le processus d'origine ou de destination d'un flux ne se situe pas nécessairement à l'intérieur du système analy-
sé, mais parfois dans son environnement. On distingue donc des flux internes et des flux externes. Un flux
externe est toujours représenté comme un flux direct entre un acteur externe et un processus interne,
d'"enregistrement" pour les données entrantes, d'"édition" pour les données sortantes.
1 Bons de Bons de
Enregistr.
Enregistr. Commande Commande
Commandes
Commandes
E-1 Clients
Réservations Clients Réservations
Commandes Commandes
différées différées
2
Préparation
Préparation
Factures Livraisons Factures
Livraisons

Les données véhiculées 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 d’un
message peut être décrit par un sous-schéma de données.1
Du fait de son orientation, un flux direct détermine un ordre entre les processus émetteur (antécédent) et ré-
cepteur (conséquent) qu'il relie; il détermine une succession de transformations et une progression entre les
états successifs des collections de données véhiculées. Par suite, le concept de flux direct constitue un outil
privilégié de l'analyse structurée des traitements.
Un flux reliant deux tâches est un flux réel, à la matérialisation duquel sont affectées des ressources : un sup-
port de communication (papier, disquette, bande magnétique, réseau de télécommunication ...), un point
d'origine et un point de destination identifiables dans l'espace et le temps. Entre deux tâches déterminées, il
n'existe normalement pas plus d'un flux de cette nature.
Les flux directs représentés entre systèmes ou sous-systèmes sont des abstractions récapitulatives d'une somme
de flux réels. Il n'existe pas de normes relatives au nombre de flux directs représentés à ce niveau (il n'est en
effet pas obligatoire de récapituler en un seul agrégat abstrait).
Flux indirect, Dépôt de données
Si l'utilité des données véhiculées par un flux n'est pas épuisée du fait de leur utilisation par le processus ré-
cepteur, les données en question sont mémorisées dans un dépôt de données.
Un flux indirect relie un processus et un dépôt de données. Il peut être orienté de trois façons :
– du dépôt vers le processus : flux entrant, consultation du dépôt de données;

– du processus vers le dépôt : flux sortant, mise à jour du dépôt de données;
– dans les deux directions : entrée et sortie, consultation et mise à jour.
Remarque. Si le seul but d'une consultation est d'obtenir les valeurs précédentes en vue de les modi-
fier, on dessinera un flux unidirectionnel de mise à jour.
GANE & SARSON
D-1 Catalogue 1 Bons de

Enregistr. Commande
Commandes
D-2 Clients
E-1
Réservations Clients
Commandes
différées
2
Préparation
Livraisons Factures
D-3 Stocks
1 Cf. chapitre 3.

DE MARCO
Catalogue Bons de
Enregistr.
Commande
Commandes
Clients
Clients
Réservations
Commandes
différées
Préparation
Livraisons
Factures
Stocks
REGLE. A l'intérieur du système de référence, tout dépôt de données doit participer à au moins un flux de
mise à jour (garnissant le dépôt) et à au moins un flux de consultation (sinon, le dépôt est dépourvu d'utilité).
Le contenu d'un dépôt de données sera nommé et décrit par un schéma de données. Le contenu d'un flux indi-
rect ne véhiculant qu'une partie des données du dépôt sera lui aussi nommé et décrit par un sous-schéma de
données.1
A un flux indirect sont nécessairement associées des opérations d'accès aux données du dépôt. On exprime
habituellement ces opérations par rapport aux occurrences d'enregistrements :
– insérer (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 accéder aux mêmes dépôts, ces derniers n'introduisent
dans le schéma aucune contrainte. Dès lors, dans la recherche des processus à interconnecter, les concepts de
dépôt de données et de flux indirect apparaissent accessoires. Plusieurs formes de diagrammes de flux n'en
font d'ailleurs pas mention. Plus important : les méthodes courantes d'analyse par les flux ne fournissent au-
cun critère d'identification des dépôts de données.
Un schéma décrivant les flux physiques de données dans un système réel peut mentionner comme dépôts les
fichiers réels, magnétiques et autres, utilisés par les traitements. Pour une description conceptuelle des flux,
antérieure à la définition des fichiers réels, nous préconisons les dispositions suivantes :
1) entre un dépôt de données particulier et un processus particulier, il n'existe pas plus d'un flux in-
direct;
2) il existe entre les données conservées dans un même dépôt une parenté sémantique reconnaissable
à l'existence d'identifiants communs (un même dépôt peut contenir la fiche signalétique individuelle
des employés et une description des fonctions qu'ils occupent, mais un dépôt ne contient pas à la fois
des données relatives aux clients et aux produits ...); cette règle tend à distinguer une collection de
données dont le schéma logique sera arborescent, dont la structure pourra supporter directement la
programmation2 — cette solution est recommandée dans un diagramme de flux entre tâches;
1 Cf. chapitre 3.
2 Cf. chapitre 4.

3) la période de mémorisation des informations conservées dans un même dépôt est définie par les
mêmes règles; concrètement, cela signifie que toutes les occurrences de données sont insérées par
des exécutions d'un/des même(s) processus et supprimées par des exécutions d'un/des même(s) pro-
cessus (dans un diagramme de flux entre sous-systèmes, on peut donc mentionner un dépôt de "don-
nées personnelles", mis à jour par le sous-système de gestion du personnel; mais, dans un diagramme
de flux entre tâches, on distinguera différents dépôts, mis à jour par des tâches diverses : fiches si-
gnalétiques des employés, relevé des prestations quotidiennes du personnel, etc).
Perméabilité des classes de flux directs et indirects
Dans la tâche de Préparation des Livraisons (voir la figure précédente), observons le flux cyclique des
Commandes différées. Il a en commun avec le dépôt Stocks de se trouver à la fois en entrée et en sortie de la
transformation et de se retrouver d'une exécution à l'autre de cette tâche; dès lors, ne s'agit-il pas d'un dépôt
de données ? Il a en commun avec le flux direct des Commandes reçues que son contenu finira par être
"consommé" par l'activité de Préparation des Livraisons; dès lors, ne s'agit-il pas d'un flux direct de messa-
ges ? Mais, si les règles de procédure autorisent les livraisons partielles (à concurrence des quantités dispo-
nibles), les valeurs de quantités en commande évolueront de la même manière qu'évoluent les quantités en
stock ...
Cet exemple montre qu'il n'existe pas de solution de continuité entre les catégories utilisées par l'analyste.
1.2. Structures typiques
a) Applications sans flux directs
Certaines applications informatiques se caractérisent par l'absence de flux directs entre les tâches. Il s'agit
d'applications dont l'objet principal est de tenir à jour et disponible un "stock" d'informations, une "banque de
données". Exemple : le fichier des membres d'une association.
• Première variante : l'application comporte des tâches de mise à jour, consultation et listage des données,
entre lesquelles n'existe aucun ordonnancement (on peut imaginer de consulter un fichier vide, n'ayant encore
fait l'objet d'aucune mise à jour ...).
Gestion des Membres
Mise à jour
Respons. Consult. Fichier
Edition
Liste

• Seconde variante : une séquence d'états successifs est définie sur les données d'un dépôt. L'application de
gestion de ce dépôt comporte différentes tâches de mise à jour, dont chacune a pour objet de faire subir à un
sous-ensemble du dépôt une transition d'état autorisée. Ces tâches doivent évidemment se succéder selon un
ordre défini. L'énumération des transitions d'état constitue souvent un outil puissant pour la recherche des
tâches dans certaines applications.
Exemple : établissement du devis d'une entreprise de construction :
1) enregistrement du métré (quantification des plans) de l'ouvrage établi par l'architecte;

2) correction du métré par l'indication des quantités recalculées par l'entrepreneur;
3) affectation de moyens de production (matériaux, etc.) aux différents postes du métré;
4) calcul du prix de revient, sur la base du coût des différents moyens;
5) établissement du prix de vente, par complétage (marges ...) du prix de revient.
Etablissement Devis
1.
Plans + Métré Enregistr. Métré
Architecte métré (Postes & Quantités)
interactif
2.
Quantités Correction Modifications
calculées métré Quantités
interactif
3.
Métreur Sélection Affectation Moyens & Qtés
Deviseur des moyens des moyens Métré/Devis
Descript.
interactif moyens
Catalogue
4. Tarif
Calcul du
prix revient Quantités <--
--> Prix
automatique
Ajustements 5.
de prix Etablisst. Prix
prix vente
Devis
interactif
b) Décomposition suivant un axe spatio-temporel dominant
On peut voir un flux direct comme un déplacement d'informations dans l'espace et/ou le temps. De nombreux
systèmes se caractérisent par des activités (des tâches) clairement distantes les unes des autres. Tâches qui se
répartissent soit dans le temps, soit dans l'espace.

• Certaines applications possèdent une structure temporelle marquée par un échelonnement périodique des
tâches. Tel est, par exemple, un système d'administration des salaires et appointements, dans lequel on peut
distinguer les groupes de tâches suivants :
– tâches à périodicité variable : enregistrement des données signalétiques des travailleurs;

– tâches quotidiennes : enregistrement des prestations (présences et absences);
– tâches mensuelles : établissement de la paie des travailleurs;
– tâches trimestrielles : versements aux organismes de prélèvement (fisc, sécurité sociale ...);
– tâches annuelles : établissement d'attestations (fiches fiscales, cotisations de sécurité sociale ...).
• Certains systèmes sont caractérisés par une structure spatiale reflétant la multiplicité des sites d'opérations.
Exemple classique : le binôme centralisation/décentralisation, maison-mère/filiale ... Les processus, mais
aussi les dépôts de données, sont répartis entre le site central et les sites périphériques. Les flux de messages
entre sites s'y avèrent essentiels à l'existence du système global.
c) Systèmes régulés
Pour survivre et fonctionner harmonieusement, un système a besoin de mécanismes de régulation. Nous al-
lons illustrer la chose par le cas du sous-système Achats–Ventes–Stocks d'une entreprise commerciale.
!

"
$%(& ( )*
$% &
'

"

#

Le système possède un flux entrant (les approvisionnements auprès des fournisseurs) et un flux sortant (les
livraisons aux clients); il contient un dépôt (les stocks), jouant le rôle de réservoir ou de tampon (il existe
d'autres dépôts, consultés mais non mis à jour, qui ne sont pas représentés sur la figure). On peut en donner
cette image : un bassin équipé de robinets de remplissage et de vidange. Le réservoir (les stocks) constitue
l'interface entre les deux sous-systèmes (robinets) d'entrée (les achats) et de sortie (les ventes).

Toute sortie est suivie d'une analyse de l'état du réservoir; il peut en résulter un message (identification de
produit à commander) agissant sur le débit du flux entrant (commande de réapprovisionnement). Un tel effet
des sorties sur les entrées a reçu le nom de boucle de rétroaction (en anglais : "feedback"). Ce concept a été
mis en avant et formalisé par les cybernéticiens.1
L'existence d'un réservoir (les stocks) donne du "mou" au système et lui permet de fonctionner sans à-coups
(sans ruptures de stocks). Un tel tampon a pour rôle de garantir la continuité de fonctionnement du système.
En vue de réduire le nombre de pannes (refus de commandes), le système peut être perfectionné par l'exis-
tence d'un second tampon (les commandes différées).
Les mécanismes régulateurs évoqués jusqu'ici sont internes au système et font partie de son fonctionnement
habituel. Un autre mécanisme régulateur est représenté par la tâche périodique (annuelle) d'inventaire, dans
son aspect d'ajustement des stocks théoriques aux stocks physiques; il s'agit dans ce cas d'une intervention
extérieure sur le système, visant à pallier les "fuites" non détectées par le "programme" normal du système.
On devrait imaginer une intervention analogue sur les commandes trop longtemps différées ...
NOTE. Remarquer que la fermeture de la boucle des réapprovisionnements (commandes – fournitures) im-
plique l'acteur externe Fournisseurs. La fermeture ou complétude d'un schéma de flux implique habituelle-
ment l'intervention de l'environnement du système ou la mention de tâches "manuelles" en plus des tâches au-
tomatiques.
1.3. Validation des diagrammes de flux
a) Syntaxe des diagrammes de flux
Relations entre composants
Il y a lieu de vérifier les relations indiquées entre les divers objets représentés sur un diagramme de flux :
• tous les processus représentés sur un diagramme de flux doivent être du même niveau d'agrégation : sous-
systèmes, tâches ou groupes de tâches, modules ou compositions de modules;
• tout flux possède 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 exécutions successives d'un même processus,
– flux indirect reliant un processus et un dépôt de données;
• tout processus représenté sur un diagramme de flux doit avoir au moins un flux entrant et un flux sortant
(exceptionnellement, une tâche ou un module pourrait ne pas avoir de flux entrant);
• dans le cadre global du système de référence, tout dépôt de données 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-système).
1 N. WIENER : Cybernétique et société, trad. française; éd. des Deux Rives, 1952.

Dénomination des composants
• Tout composant — acteur externe, processus, dépôt de données — doit être nommé.
Le nom d'un processus est normalement formé d'un nom indiquant le type de transformation opérée et
d'un complément désignant le flux de sortie principal.
Exemples : tâches : enregistrement des commandes-clients

préparation des livraisons
expédition des factures
modules : vérification de date

calcul de l'impôt
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 enregistrées, commandes différées.
Il est cependant quelquefois difficile d'attribuer un nom aux flux agrégés représentés au niveau des
systèmes ou sous-systèmes. Dans ce cas, plutôt que de recourir à des noms sans signification, on
pourra tolérer de laisser ces flux sans désignation.
• Un flux indirect n'est habituellement pas nommé si son contenu est égal à celui du dépôt qu'il concerne.
N.B. On évitera les vocables passe-partout du genre "données, informations" ou "traitement" ...
Remarque. Mise en page d'un diagramme de flux
Dans un diagramme de flux, il importe d'éviter les flèches se croisant et tournant dans tous les sens; un tel
diagramme serait rébarbatif et sa lecture découragée. On suivra au maximum les recommandations suivantes.
L'armature d'un diagramme de flux est formée de l'ensemble des sous-processus représentés. De manière à
respecter les habitudes de perception du lecteur, les symboles figurant ces processus seront dessinés, en sui-
vant l'ordre chrono–logique (matérialisé 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 rétroaction, les flux en cause seront représen-
tés par des flèches remontantes.
Les autres éléments du diagramme — acteurs externes, dépôts de données — seront disposés sur le pour-
tour et, éventuellement, dédoublés. La règle sera ici d'éviter un maximum de croisements de flèches repré-
sentant des flux.
Voir particulièrement, plus haut, les exemples de diagrammes d'Applications sans flux directs.
b) Hiérarchisation des diagrammes
Un diagramme de flux présente les relations entre sous-processus d'un processus décomposable; ce dernier est
lui-même figuré par une boîte noire dans un diagramme hiérarchiquement supérieur ... Il est possible d'établir
une hiérarchie de diagrammes de flux : toute boîte noire d'un diagramme "parent" peut être "éclatée" sous la
forme d'un diagramme "enfant". En quelque sorte, un diagramme de flux est un zoom grossissant.
Les règles suivantes doivent être respectées.

Racine de la hiérarchie : un diagramme de contexte, comprenant une seule boîte noire, représente le système
de référence. Cette boîte noire doit avoir au moins un flux de messages entrants et un flux de messages sor-
tants, connectés à des acteurs ou processeurs externes appartenant à l'environnement du système. Ce dia-
gramme ne fait mention d'aucun dépôt de données.

!

1) L'environnement d'un diagramme enfant — acteurs externes, processus, dépôts de données — doit être
identique à celui de la boîte noire parente.
2) Les entrées et sorties d'un diagramme enfant doivent être équivalentes aux entrées et sorties de la boîte
noire parente. En d'autres termes, chaque flux franchissant la frontière d'un diagramme enfant est identique à
un flux de la boîte parente ou constitue un sous-ensemble d'un tel flux; dans le second cas, il doit y avoir, au
sens mathématique, partition du flux parent.
Magasin
Stocks
ajustés
S : A c h a t s-V e n t e s-S t o ck s
S/Syst.
Inventaire
Fournitures S/Syst. S/Syst. Bons de

Commande
Stocks
Fourn. Clients
Achats Ventes
Commandes
Réapprovist. Factures
Ecritures Compta Ecritures

Comptables -bilité Comptables

)*
+, !

%&&
$

+,
"

#

'"
(

- &&
#

+,

L'analyste prendra soin de répercuter sur le diagramme parent les flux ajoutés sur un diagramme enfant (voir,
dans la dernière figure ci-dessus, l'Identification des Produits à commander). Ceci pourrait toutefois être né-
gligé pour les flux de messages reflétant 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. Spécification d'un processus
La description complète d’un processus opératoire, en particulier d’une tâche de traitement de l’information,
comporte trois volets :
– l’identification de la fonction remplie par le processus, qui en dévoile l’utilité;

– la spécification des règles qui contraignent les opérations et en garantissent la validité ;
– la description de la procédure qui détaille la méthode à mettre en œuvre.
Les deux premiers volets précisent les besoins à satisfaire; ils définissent "conceptuellement" une classe de
problèmes à résoudre. La description de la procédure vient plus tard; elle fait partie de la description "orga-
nique" d’une solution.1
REMARQUE. Idéalement, la description d'un processus devrait faire abstraction du contexte dans
lequel il a été découvert; de la sorte, cette description sera réutilisable dans un autre contexte. Si la
chose s'avère relativement malaisée aux niveaux les plus agrégés (système, sous-systèmes), elle de-
vient davantage réalisable à mesure que l'on descend vers la description des composants élémentaires.
Ce devrait au moins être le cas de la description d'un module programmable : la description d'un mo-
dule de vérification syntaxique d'une date devrait convenir à la validation de toute espèce 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 données d'entrée en données 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 différences entre l'ensemble des données d'entrée et l'ensemble des données de sortie.
Quant aux opérations transformatrices, elles ne sont pas décrites comme telles. Il s'agit en quelque sorte de
commenter le dessin d'une boîte noire.
1) A ce point, la spécification d'un flux d'entrée ou de sortie se réduit à définir le sous-schéma des données
véhiculées.1 (L'indication d'origine ou de destination du flux, de même que la quantification des occurrences
véhiculées appartiennent à la définition du contexte — voir la remarque ci-dessus.)
2) Dans le cas d'un processus ponctuel, tâche ou module, on indiquera les types d'opérations d'accès relatives
à chaque flux :
– flux direct (messages) : entrée = Recevoir;

sortie = Emettre;
– flux indirect (dépôt) : consultation = Obtenir (Lire);
mise à jour = Insérer (Créer), Remplacer (Modifier), Supprimer.
3) Dans cette première description globale, la fonction proprement dite du traitement sera résumée en quel-
ques propositions expliquant synthétiquement la transformation subie par les données.
Exemples : MODULE : calcul de l'impôt

FONCTION : calculer le montant de l'impôt sur le salaire imposable
en appliquant les barèmes d'imposition adéquats;
calculer salaire net = imposable - impôt
RECOIT : montant du salaire imposable
OBTIENT : barèmes d'imposition
EMET : montant de l'impôt, salaire net
MODULE : vérification syntaxique de date

FONCTION : tester la validité syntaxique d’une date
RECOIT : date
EMET : signal-OK ou signal-KO
TACHE : préparation des commandes de réapprovisionnement

FONCTION : pour chaque produit à commander,
déterminer — 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 tâche
La tâche est l'unité de traitement avec laquelle les utilisateurs échangent des données. A ce niveau, il est donc
nécessaire de décrire l'interface du processus : préciser en détail la forme concrète, physique, des collections
de données entrantes et sortantes, du moins celles pour lesquelles l'environnement utilisateur impose des
contraintes. Une telle description prend généralement la forme d'un dessin convenablement annoté.
Exemples : formulaires de consultation et saisie de données à l'écran; rapports imprimés;

enregistrements de bandes magnétiques ou messages échangés entre divers organismes
(banques, fisc, sécurité sociale ...).
c) Spécification détaillée des règles
Niveaux de définition des règles
Les règles de traitement constituent une expression formelle et opérationnelle des objectifs et contraintes fixés
par l'utilisateur du système d'information.
• Au niveau d'un système ou sous-système, on ne peut guère indiquer que des objectifs de performance tech-
nique ou économique, par exemple : "traiter et facturer 95 % des commandes–clients le jour même de leur
réception".
• Les règles pratiques sont découvertes dans le contexte d'une tâche, traitement élémentaire aux yeux de l'uti-
lisateur; elles sont ultérieurement réparties sur les modules découpés par le technicien.
Il est techniquement indispensable d’associer à chaque module l’énoncé des règles qu’il est chargé
d’appliquer. En outre, il est rationnel d’inclure dans la description d’une tâche les règles dont elle est
le siège; cependant, cet énoncé sera souvent facilité si l’on introduit dans cette définition un mini-
mum de structure grâce à une décomposition en modules, fût-elle fictive (c’est-à-dire différente de
celle qu’adopteront finalement les techniciens).
Si des règles sont énoncées à différents niveaux de décomposition, il convient de vérifier la cohérence des
spécifications :
– les règles attachées à un module ne peuvent contredire celles de la tâche : elles précisent une par-
tie des règles de la tâche;
– les ensembles de règles fournis aux différents niveaux doivent être équivalents.
Expression des règles
Les règles appliquées dans le cadre d’une tâche de traitement de l’information sont principalement des prédi-
cats déterminant la qualité des données traitées. Ces prédicats constituent les contraintes d’intégrité invento-
riées dans la définition des données.1 Il est donc assez naturel de rattacher directement les règles aux flux de
données.
Exemples : MODULE : vérification syntaxique de date

RECOIT : date
- REGLES : date numérique et mois ∈ {1..12} et jour ∈ {1..31}
1 Cf. chapitre 3.

MODULE : mise à jour des stocks
FONCTION : mettre à jour les stocks suite à l’acceptation des commandes–clients
et identifier les produits à réapprovisionner
RECOIT : commandes-du-jour (0:N commande (1:1 en-tête, 1:N ligne))
MET-A-JOUR : stocks (0:N stock)
- REGLES : pour n°-produit de stock = n°-produit de ligne de commande
total-sorties = précédent + qté-commandée de ligne de commande
qté-en-stock = total-entrées – total-sorties
EMET : produits-à-réapprovisionner (0:N id-produit)
- REGLES : pour n°-produit de id-produit = n°-produit de stock
si qté-en-stock précédente ≥ stock-plancher
et qté-en-stock nouvelle < stock-plancher
date = aujourd’hui
1) En vue de faciliter la lecture des règles, les flux d’entrée sont énumérés avant les flux de sortie,
dans l’ordre : RECOIT, OBTIENT, MET-A-JOUR, EMET.
2) Chaque flux est décrit sous la forme d’un schéma de données arborescent.1
3) Dans les règles, les expressions pour clé et si déterminent les correspondances entre flux
(on pourrait laisser à l’état implicite la partie en italique des expressions pour).
4) Les règles attachées aux flux de sortie servent de post-conditions au processus décrit :
les relations qu’elles expriment doivent être rendues vraies par l’exécution du processus.
Vérification des règles
Le caractère faisable des opérations doit être vérifié par un contrôle de complétude et de non contradiction de
l'ensemble des règles de dérivation :
– pour toute variable appartenant à un flux de sortie, doit exister au moins une règle capable de la
produire;
– à moins d'être définie comme variable intermédiaire, toute variable référencée dans une règle doit
appartenir à un flux;
– toute variable référencée dans une règle, soit appartient à un flux d'entrée, soit est le résultat de
l'application d'une règle.
d) Définition interne de la procédure
Dans un second temps, une description interne (du "comment") du processus explicite les mécanismes ca-
chés à l'intérieur de la boîte noire.
On peut imaginer différentes manières de présenter une procédure. Nous proposons ici la forme algorithmi-
que d'un pseudo-code faisant expressément référence aux flux de données qui se croisent dans tout processus.
Comme au paragraphe précédent, nous supposons que le contenu de chaque flux est une collection de données
représentée par un schéma logique arborescent; ces collections de données pourront donc supporter directe-
ment une programmation.2 Si tel n'est pas le cas d'un flux, on le décomposera en flux partiels de structure
arborescente.
1 Cf. chapitre 4.
2 Cf. chapitre 4.

Trois séries de règles doivent être formulées :
– les accès aux données (ces règles sont à recopier de la description externe),
– les correspondances entre les composants des différents flux de données,
– les règles de dérivation des sorties à partir des entrées : détermination des valeurs mais aussi des
occurrences (par exemple, un contrôle de validité sélectionne des occurrences, celles qui satisfont
aux règles de validité).
Un pseudo-code est un texte décrivant 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 véritablement 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 manipulés ne sont pas les objets
techniques concrets manipulés par les programmes, mais des préfigurations conceptuelles ...
Le pseudo-langage doit permettre d'exprimer les trois séries de règles qui définissent toute procédure.1
1) La spécification des opérations d'accès aux données comporte théoriquement les éléments suivants :
• l'identification du flux visé et le nom du composant transmis par le flux;

• le type d'opération :
– recevoir (flux direct, messages entrants),
– émettre (flux direct, messages sortants),
– obtenir (flux indirect, consultation d'un dépôt),
– insérer, remplacer, supprimer (flux indirect, mise à jour d'un dépôt);
• dans le cas d'une opération obtenir de consultation,
– l'identification du critère de sélection,
– le traitement de réaction aux cas d'erreurs (inexistence du composant demandé).
Schématiquement :
opération composant de flux

[ sélection = critère ]
[ si erreur alors traitement [ sinon ] ]
2) La mise en correspondance des quantités d'information se fait en répartissant les opérations de la procé-
dure, y compris les opérations d'accès aux données, dans des blocs de traitement appliqués aux composants
des flux d'entrée. Toute opération recevoir ou obtenir est donc théoriquement suivie d'une construction de la
forme suivante :
pour chaque composant

traitements
fin
Si le flux d'entrée possède une structure hiérarchisée (arborescente), plusieurs blocs s'emboîtent les uns dans
les autres, conformément au schéma suivant. Soit 0, le niveau de la racine de l'arborescence et 1,2... les ni-
veaux de décomposition successifs :
1 Ce pseudo-langage s'inspire du langage de programmation MCL — Modular Control Language — défini

par A. CLARINVAL : MESANGE : Méthode et Système d'Analyse et de Programmation de Gestion. Cette
présentation est fort proche de celle d'un Procedure Action Diagram dans la méthode 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 particulière n'est suggérée ici pour exprimer les règles de transformation appliquées
par la procédure. Il est souvent possible, comme au paragraphe précédent, d'adopter la syntaxe des règles as-
sociées aux schémas de données.1 Les règles définissant les conditions d'existence des occurrences de don-
nées dans les flux seront habituellement présentées sous la forme d'opérations d'accès 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 : vérification syntaxique de date

RECOIT : date
PROCEDURE : recevoir date
pour chaque date
si (date numérique et mois ∈ {1..12} et jour ∈ {1..31})
émettre signal-OK
sinon
émettre signal-KO
fin
fin
1 Cf. chapitre 3.

MODULE : création de factures
FONCTION : calculer et créer les factures
RECOIT : commandes-du-jour (0:N commande (1:1 en-tête, 1:N ligne))
OBTIENT : clients (0:N fiche)
OBTIENT : tarif (0:N produit)
EMET : factures-du-jour (0:N facture (1:1 en-tête, 1:N ligne, 1:1 fin))
PROCEDURE : recevoir commande de commandes-du-jour
pour chaque commande
pour chaque en-tête de commande
obtenir fiche de clients sélection = n°-client
pour chaque fiche
émettre en-tête de facture de factures-du-jour
fin
fin
pour chaque ligne de commande
obtenir produit de tarif sélection = n°-produit
pour chaque produit
montant-facturé = prix-de-vente * qté-livrée
fin
émettre ligne de facture de factures-du-jour
fin
total-facture = Σ montant-facturé
émettre fin de facture de factures-du-jour
fin

2. Schéma dynamique
Tout flux de messages entre un processus émetteur et un processus récepteur contribue à rendre possible l'exé-
cution du second. Constater l'existence d'un tel flux ne suffit cependant pas à rendre compte des conditions
d'exécution et d'enchaînement des traitements, ce qui requiert l'établissement d'un schéma logico–dynami-
que des traitements.
S'inspirant de la théorie des réseaux de Petri,1 plusieurs modèles pour l'étude dynamique des systèmes de trai-
tement de l'information sont apparus aux alentours de 1980-85. Citons le modèle défini par F. BODART et Y.
PIGNEUR dans le cadre de la méthode IDA,2 ainsi que celui proposé par la méthode MERISE.3 Pour l'es-
sentiel, nous nous inspirons ici des propositions de la méthode IDA.
2.1. Contenu du schéma dynamique
Un schéma dynamique met en œuvre les objets suivants : des processus, des événements et des moniteurs.
On peut considérer les deux derniers concepts comme complétant ceux du schéma fonctionnel.4
Comme dans toute modélisation, on s'intéressera ici aux types d'événements, types de processus, etc. En parti-
culier, plusieurs (occurrences de) processus d'un même type (par exemple, l'enregistrement d'une com-
mande) peuvent se dérouler simultanément ...
a) Processus
Lors de l'élaboration d'un schéma dynamique, on considère les processus qui, dans le temps, possèdent un
début — appelé déclenchement — et une fin — appelée terminaison. Les deux moments de déclenchement
et terminaison sont deux moments remarquables, au sens propre de discernables, correspondant chacun à un
changement d'état du processus : le déclenchement 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
Caractérisé par un début et une fin, un tel processus ne peut pas être un ensemble d'opérations récurrentes,
comme un sous-système. Il ne peut s'agir que d'une tâche ou d'un module.
b) Evénement
Un événement représente
– un changement d'état,
– survenant à l'intérieur du système décrit ou dans son environnement,
– toujours observable de l'intérieur du système décrit,
– et auquel ce dernier doit réagir par l'exécution, immédiate ou différée, de certains processus.
1 Cf., par exemple, J.L. PETERSON : Petri Nets; in ACM Computing Surveys, vol. 9, n° 3, sept. 1977;
BRAHMS : Théorie et pratique des réseaux de Petri; Masson, 1983.
2 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information : méthodes, modèles, outils;
Masson, 1989.
4 Les dépôts de données n'interviennent pas dans la description de la dynamique.
5 Un modèle prenant en compte les ressources nécessaires à l'exécution des processus distinguera d'autres
états, comme, par exemple, l'état interrompu ou suspendu par suite d'indisponibilité temporaire des ressour-
ces. La méthode IDA propose un tel modèle.

Le changement d'état observé concerne des données conservées dans les dépôts du système (par exemple, la
réception d'un bon de commande, l'épuisement d'un stock ...) ou un processus qui, par exemple, se termine.
Sauf le cas particulier, évoqué ci-après, des événements de calendrier, la survenance d'un événement est tou-
jours provoquée par un processus antécédent, qui en informe un ou plusieurs processus conséquents.1 Un
événement non observé n'est pas susceptible d'entraîner une réaction et n'est donc pas à prendre en considéra-
tion. Ce qui est fondamental, c'est l'information relative aux événements. Cette information est véhiculée par
des messages ou transmise par des signaux.
• Nous avons défini plus haut le concept de message. Un message est une information variable. Le plus com-
munément, il renseigne sur un changement d'état survenu parmi les données détenues dans les dépôts du sys-
tème.
Exemples : identification d'un produit à commander par suite d'épuisement de stock, avec la quantité
facture reflétant une vente
écriture comptable reflétant la même 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 possède pas d'attribut descriptif, pas de
texte (penser, de manière imagée, à un "bip" sonore). Nonobstant, un signal possède un nom de type, tel
qu'il en identifie clairement la provenance : nom du processus émetteur + qualificatif d'état de ce proces-
sus. Exemple : "Préparation des Livraisons terminée".
Sur un diagramme de flux, un signal peut être représenté sous la forme d'un flux direct entre processus.
Afin d'en indiquer la nature particulière, on pourrait le représenter par un trait discontinu ou bien placer son
nom entre parenthèses ...
Exemple : le signal "Préparation des Livraisons–Clients terminée" doit être attendu avant de déclencher le
processus de Préparation des Commandes de Réapprovisionnement; dans une autre organisation, cette attente
peut ne pas être souhaitée : la Préparation d'une Commande de Réapprovisionnement pourrait être déclenchée
immédiatement et automatiquement par l'émission du seul message "Identification d'un Produit à Comman-
der".
)

*

#

Cas particulier : les événements de calendrier. L'activité d'un système, l'exécution de processus, est souvent
conditionnée par l'écoulement du temps. Par exemple, tel processus doit être activé "tous les vendredis à 16
heures". On considérera donc que l'environnement de tout système comporte un processus permanent "hor-
loge" ou "calendrier", délivrant 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 système dispense de le
décrire.
( +"

1 Rappelons que les processus extérieurs à un système ne sont pas identifiés dans la description de ce système.

Tous les types d'événements n'ont pas le même degré de nécessité. Normalement, les événements de calen-
drier et les signaux de transition d'état des processus ne servent qu'à ordonnancer l'usage des ressources affec-
tées à l'exécution des opérations; en revanche, les messages reflétant l'évolution des données sont indispensa-
bles à la validité fonctionnelle des traitements, c'est-à-dire à l'intégrité de leurs résultats. Un schéma (un dia-
gramme de flux) ne mentionnant que des messages de la seconde catégorie est fonctionnel — il décrit une
classe de problèmes; un schéma mentionnant les autres types d'événements est chrono–logique et décrit des
phénomènes contingents à une organisation — il décrit une solution. L'analyste à la recherche d'une nou-
velle solution, qui ne veut pas simplement rafraîchir une solution existante, doit clairement faire cette
distinction !
c) Moniteur
D'une manière générale, la survenance d'un événement — ou, plus précisément, sa notification — ne suffit pas
à déclencher l'exécution d'un processus conséquent. Il est fréquent que l'on doive attendre la survenance d'une
combinaison d'événements, c'est-à-dire la réception de différents messages ou signaux, avant de déclencher en
réaction l'exécution d'un ou plusieurs processus. N'est pas rare, en effet, une situation du genre de celle-ci, où
s'accumulent différents messages ou signaux :
– existence de messages reflétant une situation (ex.: bons de commande reçus des clients),
– condition horaire ou de calendrier (ex.: entre 15 et 16 heures),
– demande expresse d'un responsable (ex.: "commencez la Préparation des Livraisons").
La gestion des événements est assurée par des moniteurs. Un moniteur est un processus, du même niveau
(tâche ou module) que les pocessus dont il doit contrôler l’enchaînement, théoriquement permanent (en ré-
alité, à activation chronique) et qui
– surveille l'arrivée des signaux et messages;

– assure, si besoin est, la mémorisation temporaire de ces informations;
– analyse les événements ainsi signalés pour vérifier la condition de terminaison de l'attente;
– déclenche l'exécution des processus conséquents, en leur transmettant les signaux et messages adéquats.
Préparation
Livraisons
(Livraisons Id. Produits à

terminées) commander
Calen-
drier 16 heures
MONIT. 01
Magasin go!
Id. Produits à
commander
Etablisst.
Commandes
Un moniteur est un processus du même niveau d'agrégation que les processus qu'il est chargé d'enchaîner. Il
présente ceci de particulier qu'il n'opère aucun changement de forme sur les données (les messages) qu'il
"traite" et qu'il n'accède à aucun dépôt de données.

Un processus moniteur peut reproduire en sortie, sans en modifier le contenu, certains des messages reçus en
entrée. Par ailleurs, les messages et signaux entrants concourant à la production de chaque signal ou message
de sortie sont consommés par cette production, c'est-à-dire enlevés de la mémoire du moniteur. Un moniteur
peut avoir à gérer une file d'attente, c'est-à-dire un mécanisme capable d'accumuler plus d'occurrences de
messages entrants que chaque déclenchement d'un processus conséquent n'en consomme.
Exemple : expédition des factures par les employés du service Courrier.

file d'attente en entrée : capacité illimitée
(toutes les factures éditées par la tâche d'Edition des Factures)
consommation par chaque employé = lot de 20 factures
Edition
Factures
Ordinateur
Factures
capacité = infinie
Calen- 16 heures MONIT. 02

drier
Factures
consommation = 20
Expédition
Courrier
Employé
A l'instar de tout processus, un moniteur est exécuté par un processeur : programme d'ordinateur et/ou acteur
humain; surveillance des événements et déclenchement des réactions peuvent donc être automatiques, "ma-
nuels" ou mixtes.
2.2. Types d'enchaînements
L'attente effectuée par un moniteur peut viser :
• l'accumulation de plusieurs occurrences d'un même type d'événement, c'est-à-dire la réception de plusieurs
messages ou signaux du même type;
• la synchronisation d'événements de types différents, c'est-à-dire des messages ou signaux de types diffé-
rents.
Au sens propre, une synchronisation réalise une conjonction d'événements, liés par ET. Par généralisation, on
étend le concept de synchronisation à toutes les combinaisons logiques d'événements, en particulier, au cas des
disjonctions par OU.
Exemples : accumulation des factures par lots de 20 pour leur Expédition

synchronisation pour déclencher la Préparation des Commandes de Réapprovisionnement
messages "Identification de Produit à commander"
signaux "Livraisons terminées", "16 heures", "allez-y!"
disjonction : édition d'un rapport à période fixe OU à la demande

Une attente réalise un enchaînement convergent de processus : recevant l'information de plusieurs événe-
ments, elle produit en terminaison un seul signal, déclenchant donc l'exécution d'un seul processus conséquent.
Un moniteur est également capable d'assurer un enchaînement divergent :
• la duplication de processus (inverse de l'accumulation) déclenche l'exécution de plusieurs occurrences de

processus d'un même type, grâce à l'émission de plusieurs occurrences d'un même message ou signal;
• le parallélisme (inverse de la synchronisation) déclenche l'exécution simultanée de processus de différents
types;
• la sélection (inverse de la pseudo-synchronisation OU), émettant un message ou signal parmi plusieurs
possibles, déclenche l'exécution d'un processus parmi plusieurs candidats.
Exemples : duplication : expédition simultanée de factures par plusieurs employés

parallélisme possible, à la survenance du signal "Livraisons terminées",
entre les tâches d'Edition des Factures
et de Préparation des Commandes de Réapprovisionnement
2.3. Spécification d'un moniteur
La spécification d'un moniteur se fera comme celle d'une procédure 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 durée limite de mémorisation (par défaut, cette durée est illimitée; une durée nulle indique une
cause de déclenchement immédiat; une durée limitée signifie qu'au delà, l'événement d'origine est
"oublié" et sans effet),
– les liens unissant les différentes occurrences (identifiants communs aux différentes occurrences de
messages, par exemple : "relatifs au même 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 parallèle à destination de processus multiples d'un même type
ou en série à destination d'un seul processus,
– les liens unissant les différentes occurrences (identifiants communs aux différentes occurrences de
messages).
3) Les règles de déclenchement, c'est-à-dire de production des messages ou signaux sortants, sont des prédi-
cats liant par les opérateurs logiques AND, OR, NOT les événements (messages et signaux) entrants. Les
conditions ainsi exprimées doivent être exhaustives (aucun événement, aucune combinaison d'événements ne
peuvent être systématiquement "laissés sur le carreau") et non contradictoires. On cherchera en outre à four-
nir des règles indiquant ce que deviennent les événements à durée de mémorisation limitée s'ils n'ont pas été
consommés avant l'échéance de cette durée (on doit considérer comme exceptionnel que des événements mé-
morisés soient "oubliés" sans plus).
4) S'il y a lieu, on complétera par les règles de priorité pour le traitement des files d'attente.

Exemple :
Préparation
Livraisons
(Livraisons Id. Produits à

terminées) commander
Calen-
drier 16 heures
MONIT. 01
Magasin go!
Id. Produits à
commander
Etablisst.
Commandes
MONIT.01 : déclenchement de la Préparation des Commandes de réapprovisionnement

ENTREES : (a) messages : "Identification de Produit à commander"
origine : Préparation des Livraisons–Clients
occurrences accumulées : illimité
durée de mémorisation : illimitée
(b) signal : "Livraisons terminées"
origine : Préparation des Livraisons–Clients
durée de mémorisation : 1 jour
(c) message : "16 heures" — origine : Calendrier
durée de mémorisation : 2 heures
(d) message : "go!" — origine : Magasin
durée de mémorisation : 0 (déclenchement immédiat)
SORTIES : (e) messages : "Identification de Produit à commander"
destination : Préparation des Commandes de réapprovisionnement
occurrences émises : en série, toutes occurrences de (a)
REGLES : condition de déclenchement : (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
(durée de mémorisation de (c)),
traiter les messages (a) avec ceux du lendemain
2.4. Validation du schéma dynamique
a) Complétude du schéma
Un schéma dynamique représente le comportement d'un processus complexe — système, sous-système ou tâ-
che — sous la forme d'un enchaînement de processus composants.
• Théoriquement, il est impossible que l'exécution d'un processus soit déclenchée autrement qu'à l'intervention
d'un moniteur. Ceci justifie le mode de représentation de la méthode MERISE : un moniteur, appelé syn-
chronisation, est attaché à chaque processus composant, appelé opération (la représentation fait également
apparaître les conditions d'émission des événements — signaux ou messages — sortants). Inconvénient de
cette représentation : elle ne permet pas de visualiser les enchaînements divergents, mais seulement les en-
chaînements convergents.

Evt.
a (Livraisons
terminées)
Préparation
Synchro. Livraisons
b 16 heures
OK
Opération c go! Id. Produits à
commander
Cond. Cond. c b a d
Evt.
a.b.c.d
Etablisst.
Commandes
• Aux paragraphes précédents, on a montré des diagrammes représentant les moniteurs comme des processus
autonomes. Dans ce type de représentation, on admet généralement de ne pas faire figurer les moniteurs dont
la spécification ne comporterait pas de condition et montrerait des sorties identiques aux entrées. Dans cette
représentation, on doit, pour chaque processus composant autre qu'un moniteur, indiquer exactement un type
d'événement déclencheur, c'est-à-dire un flux de messages ou de signaux en entrée (cette contrainte n'existe
pas dans un diagramme de flux du schéma fonctionnel).
b) Cohérence du schéma
La validation d'un schéma dynamique devrait comporter la démonstration qu'il "fonctionne" sans "blocage"
systématique. Nécessairement globale, semblable démonstration est difficile à établir, autrement que par une
simulation automatique.
La théorie des réseaux de Petri définit un certain nombre de propriétés que doit vérifier un schéma dynamique
"bien formé". On en trouvera un exposé, adapté au modèle de la méthode MERISE, dans l'ouvrage de H.
TARDIEU, A. ROCHFELD et R. COLLETTI.1 Nous en évoquons ci-après quelques-unes.
Evénements initiaux
Dans le schéma dynamique décrivant le fonctionnement d'un processus décomposé, on doit indiquer un ou
plusieurs événements initiaux, dont la survenance est acquise dès avant la mise en route du processus décrit.
Ces événements doivent naître (être produits) à l'extérieur de ce processus et être indépendants les uns des
autres, c'est-à-dire ne pas découler les uns des autres.
1 Op. cit.

Processus atteignables
Tout processus composant doit pouvoir être atteint au départ d'un événement initial. Ceci implique
– l'existence d'au moins un chemin partant d'un événement initial et aboutissant au processus en cause;
– sur ce chemin, une suite de conditions de production et d'attente des événements (signaux et messages)
non contradictoires.
Terminaison propre
Une même cause ne peut entraîner l'activation d'une infinité d'opérations. Donc, au départ de tout événement
initial, le comportement du processus analysé doit ou bien avoir une fin ou bien ramener à l'état initial.
Pour cela, notamment, tout cycle doit posséder un début et une fin. Il y a cycle lorsqu'un processus ou un mo-
niteur reçoit en entrée un événement dont il est lui-même, dans une exécution précédente, la cause directe ou
indirecte. Pour tout cycle, on doit trouver une condition d'amorçage et une condition d'arrêt.
Enregistr.
Commandes
Commandes amorce
différées
Commande Dans cet exemple, la fin du cycle par l'émission d'une facture est-elle
cycle reçues garantie ? En d'autres termes, n'y a-t-il aucun risque qu'une com-
mande soit éternellement différée (par exemple, par suite du retrait de
Préparation
Livraisons fabrication du produit commandé) ? Il faudrait alors prévoir une in-
tervention palliative extérieure.
fin
Factures

3. Schéma de déploiement
On l'a déjà signalé : des ressources doivent être affectées individuellement à l'exécution de chaque tâche, ain-
si qu'à chaque flux réel entre tâches. Ceci peut se visualiser par un diagramme des flux dans l'organisation.
Il s'agit d'un diagramme de flux entre tâches, dont les éléments sont disposés dans les cases d'un tableau à
double entrée, où
– les colonnes représentent les "lieux" de l'organisation : postes de travail ou services responsables;
– les lignes représentent des moments ou des périodicités (journalier, hebdomadaire, mensuel ...).
Les boîtes noires symbolisant les tâches portent différentes annotations :
– durée estimée,
– type de processus (automatique, "manuel", interactif).
Le support des messages et dépôts de données — papier, écran, bande magnétique, ligne téléphonique ... —
est visualisé par un symbole iconographique.

Normalement, les flux externes sont quantifiés : nombre moyen d'occurrences à chaque exécution de tâche.
La quantification des flux internes est, au moins théoriquement, déductible des règles de traitement.
La plupart des méthodes se contentent d'une illustration de ce genre.1
1La méthode IDA propose un véritable modèle d'analyse des ressources, assorti de programmes de simulation
permettant de tester le caractère faisable des spécifications.

ADMIN.SALAIRES
Calendrier Ordinat. central Serv. Personnel Pointeuse Travailleurs Services Banque Comptabilité
Signalét. 10/mois Situation

Modif. Familiale Situation
Variable Situation Profess.
INTER 4/mois
Enregistr. 100x2 Poin-

Quotid. Présences tages
AUTO
Enregistr. 60 Prestat.
Fin du Prest.spéc. spéciales
mois INTER
Prestat.
Fiches
100 de Paie
Fin du Calcul
Rémunér. Vire-
mois 100
ments Ecri-
AUTO
20 tures
Rémunér.

Chapitre 8. Méthodes orientées Objets
On assiste actuellement (1995–2000) à l'émergence de nouvelles méthodologies, nécessitées et entraînées par

le succès de la programmation par objets. C’est ainsi que l’Object Management Group (OMG) a, en 1997,
adopté comme standard l’Unified Modeling Language (UML).1 Ce "langage de modélisation unifié", produit
de la société américaine Rational Software, est le fruit de la rencontre au sein de cette société de trois pion-
niers des méthodes d’analyse et conception "orientées objets" : les Américains G. BOOCH et J. RUM-
BAUGH et le Suédois I. JACOBSON.
Le schéma central produit par une analyse axée 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 schéma de données, muni d'opérations. Le formalisme pro-
posé par la méthode OMT2 et repris dans UML est celui d'un schéma Entité–Association.3 La définition com-
plète des classes d’objets comporte la spécification des opérations effectuées par ces objets.4
La première section du présent chapitre explique les diagrammes proposés par UML pour illustrer les diffé-
rents aspects de la collaboration des objets.
La deuxième section décrit le modèle des cas d’utilisation mis au point par I. JACOBSON. Partant de la spé-
cification des besoins des utilisateurs, la méthode conduit à ébaucher la structure du système en identifiant les
objets à mettre en place et leurs collaborations.
La troisième section introduit le concept d’architecture logicielle et l’illustre par deux principes de réalisation
très en vogue aujourd’hui : l’architecture client / serveur et la définition de motifs ou "patterns" standardi-
sés.
1 OMG : Unified Modeling Language Specification, vers. 1.4; www.omg.org, 2002. Voir également P.A.
MULLER : Modélisation objet avec UML; Eyrolles, 1997.
2 OMT – Object Modeling Technique est la méthode d’analyse mise au point par l’Américain J. RUM-
BAUGH et son équipe. Cf. J. RUMBAUGH, al. : Modélisation et conception orientées objet, trad. française;
Masson, 1995.
3 Cf. chapitre 3.
© A. CLARINVAL Analyse — Méthodes orientées Objets 8-1

1. Schémas d’opérations
1.1. Préambule : unification des méthodes autour du concept d’Objet
Le concept central de la théorie Objet1 est naturellement celui d'objet :
– un objet est une entité

– qui se trouve dans un état, décrit par des attributs,
– et qui, capable de certaines opérations, possède un comportement
– lui permettant de réagir à des événements signalés par des messages.
La fusion des données et des opérations en un agrégat unique — l'objet — permet aux informaticiens d'utiliser
un seul modèle, une seule théorie, à tous les stades de leur travail : depuis l'établissement du schéma concep-
tuel de la base de données (schéma d'un domaine d'application) jusqu'à la réalisation effective des program-
mes.
Les méthodes précédentes étudiaient séparément les données et les opérations et s'en donnaient des vues —
des schémas — qui n'avaient rien en commun. Ainsi, la méthode MERISE2 décrit les données par un schéma
Entité–Association3 et les traitements par un schéma dynamique4 centré sur le concept d'événement. Entre —
d'un côté — les concepts d'entité, association et attribut, et — de l'autre — les concepts de processus, événe-
ment et moniteur, qu'y a-t-il de commun ? Comment assurer la compatibilité de deux visions aussi étrangères
l'une à l'autre ? Dans une conception basée sur les objets, un programme prend l’aspect d’un réseau d'objets
interconnectés, et les traitements sont décrits comme des échanges de messages entre ces objets, messages
empruntant les voies que constituent les relations identifiées dans le diagramme des classes; voilà qui assure
la cohérence de la représentation des données et de la description des opérations.
L'unification des méthodes n'est réelle que là où les outils de réalisation sont eux-mêmes "orientés
objets" car, inévitablement, la conception d'une solution technique préfigure cette solution. C'est
aujourd'hui le cas de suffisamment de langages de programmation populaires; ce ne l'est pas encore
pour les systèmes de stockage des données : les bases de données "Objet" ne sont pas encore vrai-
ment sorties du domaine expérimental. 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
données qui ne le font pas encore.
1.2. Les diagrammes d’interaction
a) Concepts introductifs
Le fonctionnement d’un système construit à base d’objets est schématiquement celui-ci : une requête émanant
d’un objet client demande à un objet serveur d’exécuter une des opérations dont il est capable;5 la méthode
utilisée par l’objet serveur peut comporter l’envoi d’une nouvelle requête à un troisième objet, et ainsi de
suite. On dit que les objets communiquent entre eux par des messages de requête.
1 Cf. A. CLARINVAL : Concepts et méthodes de la programmation par objets.

3 Cf. chapitre 3.
4 Cf. chapitre 7.
5 Pour cette raison, les opérations "offertes" par un objet sont parfois aussi appelées des services.

(Dans un système d’objets distribués, tel que CORBA1, les objets clients et serveurs sont répartis à travers un
réseau de plusieurs machines de types divers.)
Exemples. Puisque tout objet est responsable de son propre état, c’est le COMPTE CLIENT lui-
même qui va se créditer du montant d’un paiement; cette opération sera exécutée (ou refusée) en
réponse à un message de demande émanant d’un objet PAIEMENT. En vue d’afficher son propre
état, l’objet COMPTE demande à l’objet CLIENT titulaire de lui fournir ses coordonnées. Etc.
(L’objet PAIEMENT pourrait être localisé sur une machine et les objets COMPTE et CLIENT, sur
une autre.)
1: créditer (montant) 2: coordonnées ()
paiement compte client
Les diagrammes d’interaction d’objets schématisent à la fois la structure et le fonctionnement des systèmes
composés d’objets. UML suggère deux formes pour ces schémas : les diagrammes de collaboration, initia-
lement proposés par G. BOOCH, et les diagrammes de séquence, initialement proposés par J. RUMBAUGH.
b) Notations communes
Objet
objet : Classe
Un objet est symbolisé par un rectangle.

Des occurrences multiples d’une même classe sont symbolisées par des rectangles superposés.
Un objet est identifié par une expression de la forme nom_objet :nom_type 2
– une des mentions peut manquer : objet de type indéterminé : nom_objet
objet anonyme : :nom_type
Pour le distinguer d’un identificateur de classe, l’identificateur d’un objet est souligné.
Message
Un envoi de message est représenté par une flèche orientée de l’objet client vers l’objet serveur.
Un message complet est libellé sous la forme suivante :
nom_opération ( nom_paramètre :type_paramètre ... ) :type_résultat
L’émission d’un message peut être soumise à condition : [ condition ] message
ou répétitive : *[ boucle ] message
Pour refléter la séquence d’exécution, les messages peuvent être numérotés.
1 CORBA — "Common Object Request Broker Architecture", système normalisé défini par l’OMG ("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 qu’ils échangent.
Exemple : programme affichant l’heure sur un cadran analogique et un cadran numérique.
: Programme 1: *[boucle] donner_heure ( )
4: changer (heure)
: Horloge : Cadran Analogique
6: changer (heure) 5: dessiner (figure)

3: donner_heure ( )
7: écrire (texte)
: Horodateur 2: attendre (1 sec)
: Cadran Numérique : Ecran
Parce qu’il répartit 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 à l’exemple ci-dessus
Programme
exécuter( )
terminer( )
Horloge Cadran Analogique
donner_heure( ) changer( )
Horodateur Ecran
Cadran Numérique
attendre( ) dessiner( )
changer( )
donner_heure( ) écrire( )
d) Diagramme de séquence
Représentation alternative, un diagramme de séquence visualise le temps sur un axe vertical (la "ligne de
vie" de chaque objet). Il est possible de préciser par des annotations la chronologie des opérations : durée
et décomposition d'une opération (visualisées sous la forme d’un bandeau vertical), délai séparant deux
opérations, condition d'émission d'un message, boucle répétitive, etc.1
1En particulier, diverses conventions graphiques permettent d’exprimer les conditions de synchronisation des
messages, requêtes et réponses ...

Exemple : programme affichant l’heure sur un cadran analogique et un cadran numérique.
: Programme : Horloge : Horodateur : Cadran : Cadran : Ecran

Analogique Numérique
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 séquence permettent d'être plus explicite dans la description du fonctionnement d'un pro-
gramme.

2. Le schéma des Cas d’Utilisation
2.1. Préambule : le contexte historique
a) Libéralisation de l'usage des ordinateurs
La vision des choses implicite dans les diagrammes de flux — ordonnancer les tâches constitutives d’un sys-
tème —,1 qui fut et reste encore celle des responsables de l'informatique dans la plupart des entreprises,
convient bien à un planificateur. Elle relève d'une idéologie centralisatrice et autoritaire (les analystes infor-
maticiens n’étaient-ils point naguère souvent affublés du titre d’analystes–organisateurs ?).
En moins d'une décennie, le déferlement des ordinateurs personnels, aujourd'hui parfaitement intégrés au ré-
seau "officiel" de l'entreprise, en a révélé les limites. L'informaticien ne formalise plus et n'automatise plus
toutes les tâches, mais seulement certaines d'entre elles; en fait, on ne lui demande plus que des outils.
Le concept même de "l'application informatique" est en train de changer. Nous ne fournissons plus
à l'utilisateur une application monolithique, souvent dépassée avant même d'être livrée. Nous lui
donnons plutôt une "boîte à outils", qui contient tout ce dont il a besoin : application spécifique
bien sûr, mais aussi traitements de texte, tableurs, outils d'interrogation, générateurs d'édition ...
[...]
L'utilisateur est le seul à savoir réellement quel est l'outil qui lui convient et puise dans cette "boîte"
le meilleur instrument pour effectuer son travail. Il sait surtout, et c'est le plus important, l'ordon-
nancement des actions à effectuer. Il peut réagir et prendre une décision face à un événement parti-
culier. Autrefois, il fallait imaginer et coder tous les scénarios possibles. Ceci impliquait nécessai-
rement un long délai de fabrication du logiciel, aussi bien lors de la phase de conception que lors de
la phase de réalisation.
Prenons un exemple simple. Pour informatiser le processus "accrocher le tableau dans le hall d'en-
trée", il faut, pour une action qui est somme toute simple, plus de 30 actions élémentaires. Et le
nombre de scénarios et de variantes est bien supérieur pour peu qu'un événement particulier se pro-
duise — la mèche se casse pendant le perçage — , avec toutes les autres actions élémentaires que
cela comporte : retirer la mèche cassée du trou, choisir une autre mèche ...
Prendre un crayon à papier

Prendre un mètre
Mesurer la largeur du mur
Repérer le point d'ancrage sur le mur
Choisir la vis adaptée
Choisir la cheville adaptée à la vis
Choisir la mèche adaptée à la nature du mur (béton, brique ...) et à la cheville
Prendre la perceuse
Dévisser l'ancienne mèche
Visser la mèche choisie
Régler la perceuse (percussion, profondeur de la tige de guidage ...)
Percer le trou
Enlever la poussière du trou
1 Cf. chapitre 7.

Mettre la cheville dans le trou
Prendre le marteau
Enfoncer la cheville délicatement
Enfoncer complètement la cheville avec le marteau
Prendre la vis
Prendre le tournevis correspondant à la vis
Visser la vis
Poser le tableau
Régler l'horizontalité du tableau
Tel est le contenu des applications informatiques [anciennes]. Quatre-vingts pour cent de la pro-
grammation est utilisée (gaspillée ?) à traiter des scénarios qui ne vont que rarement être utilisés,
ou bien à résoudre des cas d'erreurs. De plus, le scénario imaginé par le concepteur n'est pas sou-
vent celui désiré par l'utilisateur : il a peut-être envie de commencer par régler la perceuse alors
que l'application l'oblige d'abord à saisir le crayon pour repérer le point d'ancrage sur le mur. 1
b) Modernisation des méthodes d’analyse
Les diagrammes de flux sont des outils d’analyse datant de l’époque du traitement par lots (en anglais :
"batch processing"). En ces temps héroïques des débuts de l’informatique de gestion (1960–1975), un pro-
gramme en exécution était incapable d’interagir avec un utilisateur humain. Les données à traiter étaient donc
accumulées dans des lots enregistrés — on disait : encodés — dans des fichiers "de mouvements" (d’abord
sur cartes perforées, plus tard sur bandes magnétiques); le traitement de ces lots était soigneusement planifié
et confié aux opérateurs de la "salle des machines"; les résultats revenaient sous la forme d’épais rapports
imprimés ...
Puis apparut l’informatique interactive ou conversationnelle où l’utilisateur humain, par le truchement d’un
terminal à clavier + écran, intervenait directement dans le déroulement des programmes. Les évolutions pa-
rallèles de la technologie et des systèmes d’exploitation allaient accorder à l’utilisateur humain "conversant"
avec un programme de plus en plus d’initiative et de liberté.
Comme date charnière, on pourrait retenir celle de l’apparition du système de programmation SMALLTALK
(1980), pionnier de la programmation par objets et promoteur du style d'interface graphique qui se trouve à
l'origine du système Macintosh et de ses imitateurs.
Le modèle des cas d’utilisation, mis au point par le Suédois I. JACOBSON, date de cette seconde époque.2
Plus tard, JACOBSON a rejoint l’équipe des Américains G. BOOCH et J. RUMBAUGH au sein de la société
Rational Software, apportant à l’équipe la démarche d’analyse qui lui manquait et qui devint le Processus
Unifié ("Unified Process") pour le développement des logiciels.3
L’optique de l’analyste est profondément renouvelée : plus de tentative de structurer l’enchaînement complet
de toutes les tâches d’un système; au lieu de cela, chaque cas d’utilisation du système (autrement dit, chaque
tâche) est analysé séparément et sa spécification prend la forme d’un ou plusieurs scénarios décrivant la
"conversation" de l’utilisateur avec le système. (Les méthodes antérieures, conçues pour la description des
traitements par lots, n’évoquaient pas les interventions des utilisateurs dans le traitement de l’information.)
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 précédentes, cette méthode d’analyse a été mise au point une dizaine ou une quin-
zaine d’années après les modes d’exploitation et de programmation qu’elle s’applique à décrire ...
3 I. JACOBSON, G. BOOCH, J. RUMBAUGH : Le processus unifié de développement logiciel, trad. fran-
çaise; Eyrolles, 1999.

2.2. Contenu du modèle des Cas d’Utilisation
"Un système s’adresse en principe à différents types d’utilisateurs, chacun étant identifié en tant
qu’acteur. Les acteurs utilisent le système selon les interactions décrites par les cas d’utilisation.
Un cas d’utilisation est une séquence d’actions qu’effectue le système afin de produire des résultats
satisfaisants pour l’acteur. L’ensemble des acteurs et des cas d’utilisation constitue le modèle [ou
schéma] des cas d’utilisation." 1
a) Système
Comme dans les méthodologies précédentes, le système constitue le référentiel analysé.2
b) Acteur
Un acteur est un utilisateur en situation d’interaction avec le système. On distingue l’utilisateur, être concret
individuel, et l’acteur, qui est un des rôles que peut jouer un utilisateur. L’utilisateur est une réalité, une oc-
currence; l’acteur est une abstraction, un type. Un utilisateur peut jouer différents rôles (ex.: une vendeuse
de grand magasin est également cliente de ce magasin); un même rôle (ex.: client) peut être joué par diffé-
rents utilisateurs.
Acteur Vendeur Client
Les utilisateurs d’un système peuvent être des personnes, des machines, un autre système ...
Le mécanisme de généralisation permet de définir des hiérarchies de rôles.
Client
Tiers
Fournisseur
Acteur externe
Un utilisateur conversant avec le système de traitement de l’information peut jouer le rôle de substitut d’un
acteur externe; par exemple, l’employé(e) encodant un bon de commande reçu par courrier ou par téléphone
endosse en quelque sorte le rôle du client. Bien que ce client lui-même n’interagisse avec aucun composant
particulier du système d’information, on peut, dans les descriptions abstraites d’un modèle, lui reconnaître un
rôle d’acteur.
1 I. JACOBSON, al. : Le processus unifié ...

2 Cf. chapitre 6.

Dans d’autres situations — celle d’un client commandant directement via Internet ou celle d’un client au gui-
chet automatique d’une banque ... —, l’acteur externe joue lui-même son propre rôle.
c) Cas d’utilisation
La définition d’un cas d’utilisation ("séquence d’actions produisant des résultats satisfaisants pour l’ac-
teur") rappelle les deux premiers éléments de notre définition d’une tâche :
(1) un ensemble d'opérations du système,

(2) que l’utilisateur alimente en données et dont il attend des résultats,
(3) au fonctionnement duquel il affecte des ressources : moment, durée, localisation, machines ...1
Le concept n’est donc pas vraiment neuf. De plus, il est maladroitement défini : les auteurs écrivent aussi
qu’un cas d’utilisation regroupe ordinairement "plusieurs séquences d’actions possibles", séquences auxquel-
les ils donnent le nom de scénarios. Pour lever cette contradiction, il suffit d’admettre que l’intention de
l’utilisateur ne se dévoile pas seulement à travers la séquence d’actions déroulée mais également par les res-
sources qu’il affecte à la satisfaction de ses besoins; on en arrive ainsi à donner au cas d’utilisation la défini-
tion classique d’une tâche.
Un acteur est habituellement impliqué dans différents cas d’utilisation d’un système; ainsi, un client interagit
avec le système de vente d’une firme commerciale en lui envoyant des commandes et des paiements.
[ressource : la Poste]
Cas d'utilisation Commander
Client [ressource : une banque]
Payer
Il arrive qu’un cas d’utilisation implique plusieurs acteurs; normalement, un seul d’entre eux joue le rôle
d’initiateur, tandis que les autres sont des utilisateurs passifs. Tous ces acteurs ont des besoins que le cas
d’utilisation doit satisfaire mais, seul, l’acteur initiateur converse (inter–agit) concrètement avec le système.
initiateur
Facturer
Vendeur Client
Le schéma des cas d’utilisation d’un système répertorie les acteurs et les cas d’utilisation de ce système. Mais
— différence essentielle avec les diagrammes de flux — il ne cherche pas systématiquement à ordonnancer les
cas d’utilisation. Si, par commodité, l’on y opère des regroupements, il ne s’agit que des cas d’utilisation
concernant un même acteur. (Bien sûr, un diagramme doit être commenté et rien n’empêche que le commen-
taire indique l’ordre de succession des tâches.)
1 Cf. chapitre 6.

Exemple : cas d’utilisation impliquant le client.
Commander
Vendeur
Facturer
Client
Comptabilité
Payer
d) Scénario
Un scénario est une séquence d’actions possible dans le cadre d’un cas d’utilisation. (En vue de désigner un
scénario, l’analyste emploiera donc une expression qualifiée, de la forme scénario de cas ou cas::scénario .)
Par les ressources qu’il concentre (lieu, moment, ordinateur, formulaire d’affichage à l’écran ... et acteur), un
cas d’utilisation forme un contexte qui rend possibles différents scénarios et permet de les enchaîner librement,
c’est-à-dire sans changer de contexte.
Exemple : gestion du curriculum vitae des travailleurs dans une société de travail intérimaire.
Acteur externe Acteur Cas d’utilisation Scénarios

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. sélectionner des C.V.
impression des C.V. imprimer un C.V.
imprimer une sélection de C.V.
Mis e à jour C.V.

Recruteur
(Travailleur)
Consultation C.V.
Placeur
(Em ployeur)
Im pres sion C.V.

2.3. Spécification des scénarios
Si le concept de cas d’utilisation n’est pas vraiment neuf, ce qui l’est, en revanche, c’est la manière de les dé-
crire. Eclose à l’ère de l’informatique interactive, la méthode d’analyse explicite les actions de l’utilisateur
autant que celles du système ... alors que la définition traditionnelle d’un processus énonce que celui-
ci "reçoit et émet des messages, obtient et met à jour des données",1 en ignorant complètement l’utilisateur.
a) Flot d’événements
Satisfaire les besoins d’un utilisateur : telle est la fonction, l’utilité d’un cas d’utilisation. Les auteurs de la
méthode préconisent de spécifier ces besoins fonctionnels en décrivant l’interaction — la conversation — du
système avec l’acteur initiateur du cas d’utilisation. "Les cas d’utilisation permettent aux utilisateurs de
structurer et d’articuler leurs désirs; ils les obligent à définir la manière dont ils voudraient interagir avec le
système, à préciser quelles informations ils entendent échanger et à décrire ce qui doit être fait pour obtenir
le résultat escompté. [...] [Les cas d’utilisation] se décrivent en termes d’informations échangées et d’étapes
dans la manière d’utiliser le système." 2 (Il n’est sans doute pas inutile ici de rappeler qu’un acteur peut être
une machine, par exemple un autre ordinateur ...)
Cette interaction est vue comme une succession de messages échangés de l’un à l’autre — un message est une
entité d’information décrivant un événement.3 Mais, parce que le mot message possède en programmation
par objets une signification technique particulière (requête d’un objet client à un objet serveur, visant à acti-
ver une opération caractéristique de ce dernier), les auteurs parlent ici plus vaguement de flot d’événements.
Précisément, un flot d’événements décrit un scénario d’utilisation; un cas d’utilisation peut présenter diffé-
rents scénarios dont chacun sera décrit séparément.
Un flot d’événements est visualisé sous la forme d’un diagramme de séquence simplifié, qui ne mentionne
que deux "objets" : l’acteur initiateur et "le système". Ce diagramme est appuyé par une description "litté-
raire" plus explicite.
Exemple : scénario : enregistrement d’une commande–client reçue au téléphone.
La première étape consiste à mettre à jour les informations relatives au client.

Le/La téléphoniste demande au client de décliner son identité, puis recherche sa fiche signalétique.
Si la fiche signalétique n’existe pas, le/la téléphoniste la remplit en demandant les différentes infor-
mations au client.
Le/La téléphoniste lit au client les rubriques apparaissant sur sa fiche signalétique (ancienne ou
nouvelle) et lui demande de confirmer la validité des données. Il/Elle encode les corrections éven-
tuelles et demande au système d’enregistrer la fiche.
Le système affiche alors un formulaire de commande vierge, pré-numéroté et pré-daté. Il y copie
automatiquement les données signalétiques du client utiles à l’identification de la commande.
Pour faciliter la prise de commande, le système affiche également une fenêtre de sélection des pro-
duits (tarif et stock).
La commande est alors constituée ligne par ligne.
Le client indique le produit qu’il désire et le/la téléphoniste le recherche dans la fenêtre de sélection
des produits. Il/Elle informe le client sur le prix de vente et la disponibilité du produit.
Le client indique la quantité désirée, que le/la téléphoniste enregistre.
A la fin de l’enregistrement, le système calcule et affiche le prix facturable pour cette commande.
etc.


b) Diagramme de séquence
: Système
: Client : Téléphoniste
s'identifier
mise à jour demander la fiche
de la fiche
Client montrer la fiche (ou une fiche vierge)
lire la fiche
signaler les mises à jour

encoder les mises à jour
enregistrer la fiche
préparer une commande vierge

préparer la
prise de montrer le formulaire de commande
commande
ouvrir la fenêtre de sélection des produits
ligne à ligne désigner le produit désiré

...
rechercher le produit dans la liste
donner prix et disponibilité
indiquer la quantité désirée

encoder la quantité
enregistrer la ligne
calculer le total facturable

fin de
commande afficher le total facturable
etc...
2.4. Relations entre cas d’utilisation
La description des différents scénarios fera ressortir des séquences d’opérations communes à plusieurs cas
d’utilisation. Afin de limiter les redondances, ces séquences communes seront extraites et décrites sous la
forme de cas d’utilisation séparés susceptibles d’être réutilisés par les cas d’utilisation originaux; apparaîtront
alors des relations entre cas d’utilisation.

a) Relations concrètes
Utilisation
Un cas d’utilisation peut en utiliser (sic) un autre : un scénario du premier peut inclure un scénario du se-
cond (de la même manière qu’en programmation par objets, un objet peut en "utiliser" un autre auquel il est
associé : une opération du premier peut invoquer une opération du second).
Exemple. Pour enregistrer un bon de commande, l’employé commence par demander au système la
fiche signalétique du client; si elle n’existe pas, il en crée une qui reprend les données apparaissant
sur le bon de commande; si elle existe mais que l’adresse du client ait changé, il modifie l’adresse
mentionnée sur la fiche signalétique ... Toutes ces opérations relatives à la fiche signalétique d’un
client peuvent être effectuées indépendamment de l’enregistrement d’un bon de commande; elles
font partie des scénarios du cas d’utilisation "Gérer les fiches Client".
Enregis trer Com m ande symbole de la

relation
"utilis e"
Encodeur
Gérer fiche Client
Extension
On peut créer une variante d’un cas d’utilisation en lui ajoutant sous condition quelques opérations présentées
sous la forme d’un cas d’utilisation qui étend les fonctionnalités du cas de base.1 (Le diagramme de séquence
détaillant le scénario du cas de base doit mentionner la condition d’insertion des opérations complémentaires.)
Exemple. Une transaction commerciale effectuée via Internet doit être sécurisée !
en cas de
paiem ent
électronique
Paiem ent
Client
<<étend>>
Sécurisation de la Transaction
1 Le couple cas général + extension définit un cas spécialisé. Le verbe "étend" possède ici le même sens que
dans le langage de programmation JAVA : dérivation d’un sous-type par complétage de la définition d’un
type de base.

b) Relations abstraites
Inclusion
Il est possible d’isoler dans un cas d’utilisation séparé, comme dans une espèce de sous-programme, certaines
opérations communes à plusieurs cas d’utilisation réels. Un tel cas d’utilisation, non directement utilisable par
un acteur et qu’on peut donc qualifier d’abstrait, est mis en évidence dans le but de faciliter le travail
d’analyse. Au lieu de parler ici d’une relation "utilise", certains auteurs parlent d’inclusion.
Exemple. Beaucoup de scénarios comportent une séquence initiale d’identification de l’utilisateur :

demande et vérification du nom et du mot de passe. Ces opérations peuvent être isolées dans un cas
d’utilisation abstrait.
<<inclut>>
<<inclut>>
Identifier Utilisateur
Lam bda
Acteur Cas d’utilisation Scénarios

Utilisateur λ Identification Utilisateur vérifier l’identification
modifier le mot de passe
Généralisation
Il est parfois possible de regrouper sous la forme d’un cas d’utilisation générique abstrait les éléments com-
muns à différents cas d’utilisation concrets. Cette relation de généralisation est analogue à celle qui existe
entre certains types d’entités ou classes d’objets.
Exemple. Les interventions d’un garagiste sur un véhicule sont de deux sortes : entretien et répara-
tion. Les deux cas ont beaucoup de choses en commun : prestations de mécaniciens, fournitures de
pièces et de consommables, etc.; ces éléments communs sont regroupés dans un cas d’utilisation
abstrait Intervention.
symbole de la
relation de
généralis ation
Entretien
Intervention
Garagiste
Réparation

2.5. Analyse des cas d’utilisation : du scénario aux objets
L’analyse des cas d’utilisation consiste à extraire de l’étude des scénarios la spécification des composants de
la solution technique à mettre en œuvre. Ces composants sont présentés dans des classes d’analyse préfigu-
rant les classes d’objets que pourrait définir la programmation (mais elle pourra aussi recourir à d’autres
techniques de réalisation ...).
a) Classification des composants
L’architecture Modèle–Vue–Contrôleur (SMALLTALK)
Pionnier dans le domaine de la programmation par objets, le système SMALLTALK (1980) a notamment
légué aux informaticiens un principe d'architecture des programmes que, désormais, toutes les méthodolo-
gies proposent tel quel ou plus ou moins adapté. Ce principe d'architecture répartit en trois catégories les ob-
jets intervenant dans un programme : modèles, vues, contrôleurs.
[1] Des objets tels que Client–Produit–Commande–Facture sont des "modèles" abstraits de l'information
gérée par une application; dans d'autres domaines, on trouvera les modèles Employé–Salaire, Avion–Pilote–
Vol–Réservation, Température–Pression, etc. [2] Une liste à l'écran, un imprimé et même le contenu d'un fi-
chier sont des vues ou représentations. Un modèle peut avoir plusieurs représentations (ex.: un tableau de
chiffres et un graphique, une fiche à l'écran et une liste imprimée). Chacun de ces objets détient — et lui seul
détient — toutes les opérations qui constituent son comportement : les modèles abstraits sont responsables
des opérations de calcul, les vues sont responsables des opérations de mise en forme.
[3] Les contrôleurs, par exemple un gestionnaire de menus ou un éditeur de textes, gèrent les enchaînements
dynamiques; ils agissent pour que les différents objets du programme se trouvent toujours dans un état cohé-
rent, en particulier pour que l'état d'un modèle et l'ensemble de ses représentations se reflètent correctement.
[4] La méthode OMT1 regroupe dans une catégorie distincte les dispositifs d'entrée–sortie, tels que les ges-
tionnaires de la souris, du clavier, des fichiers, du réseau ..., qui sont habituellement des objets standards pré-
définis.
Exemple : diagramme des classes d’objets intervenant dans un programme d’affichage de l’heure.
<<control>>
Programme
exécuter( )
terminer( )
<<control>> <<view>>
Horloge Cadran Analogique
donner_heure( ) changer( )
<<model>> <<output>>
<<view>>
Horodateur Ecran
Cadran Numérique
attendre( ) dessiner( )
changer( )
donner_heure( ) écrire( )

REMARQUE. A proprement parler, une fenêtre d’interface graphique est un dispositif d'entrée–
sortie, géré par des opérations standards (montrer, cacher, déplacer ...), et c'est le texte formaté
(dans telle couleur, dans telle police, en gras, en italique ...) apparaissant dans cette fenêtre qui
constitue la vue. Une fenêtre contient souvent aussi l’un ou l’autre contrôleurs — ou, plus exacte-
ment, des vues de l’un ou l’autre contrôleurs —, tels que des boutons poussoirs.
Les classes d’analyse (JACOBSON)
Dans sa méthode, I. JACOBSON préconise de répartir les composants du système dans des classes d’analyse.
Ces classes ne sont pas nécessairement déjà les classes d’objets de la programmation; elles ne font que les
préfigurer. (On "tirera" souvent plusieurs classes d’objets d’une seule classe d’analyse. Qui plus est, la
réalisation pourra recourir à d’autres techniques que la pure programmation par objets.1)
Exemple. Une classe d’analyse pourrait être la classe Formulaire de mise à jour des fiches Client.
Le programmeur réalisant cette interface graphique y "découpera" plusieurs objets : une barre de
menus, une liste de sélection, un panneau de présentation et mise à jour de la fiche, des boutons de
commande, etc.
menus
liste fiche
Les classes d’analyse se répartissent elles-mêmes en trois catégories correspondant aux trois catégories
d’objets de SMALLTALK :
SMALLTALK I. JACOBSON symbole
Model Entity
View Boundary
Controller Control
• Une classe d’entités n’est rien d’autre qu’un type d’entités dégagé par l’analyse préalable du domaine
d’application.2 La plupart des entités sont des objets persistants, conservés dans des fichiers ou une base de
données.
NOTE. Les acteurs externes (clients, fournisseurs ...) sont souvent décrits par des entités internes
au système ("fiches" clients, "fiches" fournisseurs ...).
REMARQUE. L’analyse anticipée de quelques cas d’utilisation particulièrement "représentatifs"

peut aider l’analyse du domaine d’application à découvrir des classes ou types d’entités.
1 Cf. infra, § 3.
2 Cf. chapitre 3.

• Un objet d’interface ou de frontière ("boundary") est un dispositif d’échange entre le système et ses
utilisateurs, y compris les acteurs passifs. Cette catégorie regroupe les vues mais aussi certains dispositifs
d’entrée–sortie (écrans, imprimantes, lecteurs de codes à barres, etc.) mentionnés au paragraphe précédent.
• Un objet contrôleur coordonne l’intervention de différents autres objets dans le déroulement d’un ou
plusieurs scénarios. On identifiera au minimum un contrôleur par scénario.
Commentaires
Tout composant du système à réaliser est défini par une classe. Il constitue une ressource le plus souvent
partagée par plusieurs scénarios et même par plusieurs cas d’utilisation.
Exemple : usage de quelques classes dans la gestion des C.V.
Entité Frontière Frontière Frontière

Cas d’utilisation Scénarios C.V. liste sélect. 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. sélectionner des C.V. x x
impression des C.V. imprimer un C.V. x x x
imprimer une sélection de C.V. x x x
☛ Il arrive qu’un analyste hésite entre scénario et cas d’utilisation : tel sous-ensemble d’opérations
compose-t-il un scénario ou un cas d’utilisation ? Cette confusion n’a pas beaucoup d’importance;
en tout cas, elle n’a pas d’impact sur la réalisation du système, puisque celui-ci sera formé de compo-
sants qui transcendent aussi bien les cas d’utilisation que les scénarios.
b) Diagramme de collaboration
L’analyse d’un cas d’utilisation consiste à transformer la spécification des scénarios qui le composent en dia-
grammes de collaboration entre objets et à décrire ces objets. Les objets dont il est ici question sont des
objets "d’analyse" définis par des classes d’analyse, pas encore nécessairement des objets à réaliser tels quels.
METHODE
1) Le diagramme de séquence décrivant un scénario identifie les messages échangés entre "le système" et un
acteur. Il s’agit maintenant d’identifier, à l’intérieur du système, l’objet émetteur ou récepteur de chacun des
messages.
2) Parallèlement, l’examen détaillé du contenu des messages fera ressortir les attributs des différents objets.

Pour démarrer, il est pratique de disposer d’un canevas d’analyse, tel que celui proposé par P.A. MULLER
pour l’analyse des programmes comportant une interface homme–machine.1
Une classe d’entités fournit des méthodes pour obtenir() et mettre_à_jour() les valeurs.
A chaque type d’entité Ent sont associées deux fenêtres dotées d’opérations standards :
– une fiche F_Ent et une liste L_Ent.2
menus
liste fiche
La fiche F_Ent, avec ses méthodes montrer() et cacher(), présente à l’écran le contenu dé-
taillé d’une occurrence Ent. La liste L_Ent, dont l’utilité est de permettre de sélectionner()
une fiche, montre seulement quelques données de chacune des entités d’une collection.3
Objet
Entité
Contrôle Frontière
obtenir( )
mettre à jour( )
Fenêtre
m ontrer( )
cacher( )
Liste
sélectionner( )
standard
-----------------------------------------------------------------------------------------------------------
application
F_Ent Ent
L_Ent

2 On doit au système SMALLTALK cette structure de référence pour les interfaces graphiques.
3 Dans les réalisations concrètes, il n’est pas rare d’ajouter au duo liste de sélection + fiche de mise à jour une
fenêtre de définition des critères de présélection en fonction desquels sera construite une liste partielle;
l’enchaînement de référence est alors celui-ci : définition des critères de présélection → constitution de la
liste de sélection → extraction et manipulation de la fiche. Il peut aussi être nécessaire de découper en plu-
sieurs volets une fiche trop chargée. Mais tout ceci est sans intérêt au stade d’analyse dont nous traitons ici.

Exemple : scénario : enregistrement d’une commande–client reçue au téléphone (cf. § 2.3.)
Contrôle Contrôle Frontière Entité Frontière
2: montrer ( )
3: sélectionner ( ) : L_Client
4: montrer ( )
: Mise à jour fiche Client 6: remplir ( ) 5: obtenir ( )
7: mettre à jour ( )
: F_Client : Client
1: exécuter ( ) 8: enregistrer ( )
: Enreg. Commande 11: créer ( )

12: obtenir ( )
17: mettre à jour ( ) 18: enregistrer ( )
9: exécuter ( )
10: montrer ( )
16: remplir ligne ( ) : F_Commande : Commande : Base de Données
: Création Commande 13: montrer ( )

14: sélectionner ( )
15: obtenir ( )
: L_Produit : Produit
c) Diagramme des classes "conceptuelles"
L’examen détaillé des messages, essentiellement ceux qui circulent entre une entité Ent et la fiche F_Ent
correspondante, permet de recenser les attributs à mentionner dans la spécification des différentes classes
d’entités (dans l’exemple, les classes Client, Commande et Produit). Ainsi s’élabore progressivement le dia-
gramme des classes d’entités "conceptuelles" du domaine de l’application.

3. Conception d’une architecture logicielle
3.1. Nature de la démarche de conception
Risquons un parallèle avec la modélisation des données. L’analyse des données livre d’abord un schéma
conceptuel, sémantique, articulé autour des concepts d’entité, association, attribut et identifiant; ce schéma
doit être transformé en schéma logique, c’est-à-dire réinterprété en termes de technologie, d’objets réalisa-
bles : enregistrements et clés d’accès, par exemple. Le même genre de démarche doit s’appliquer ici : les
schémas d’opérations dont nous disposons à ce stade sont du niveau conceptuel; ils doivent être coulés dans
les éléments d’une architecture matérielle et logicielle. Dans les méthodes américaines, cette seconde étape de
la démarche est connue sous le nom de design, ce que l’on traduit en français par le terme conception.
Cependant, la situation est ici très différente. Alors que, de nos jours, les systèmes de gestion de bases de
données (SGBD) les plus usités sont assez uniformes (ils se conforment presque toujours au modèle rela-
tionnel sous-jacent au langage SQL), les moyens de réaliser les opérateurs techniques de traitement de l’infor-
mation sont de plus en plus variés.
Il est donc nécessaire, fondamental même, de d’abord tracer sa voie : avant d’être mise en œuvre,
une solution technique doit être conçue ! Il s’agit, en premier lieu, de fixer des objectifs de qualité
technique tels que "la clarté, la capacité de réaction aux futurs changements et la réutilisation",1
et d’opérer des choix techniques de portée générale.
La conception [...]
Comme l'analyse et la conception, la conception et la réalisation se chevauchent en partie. Il est
rare de savoir comment tout faire; pour cette raison, il faut essayer des techniques alternatives,
comparer les résultats puis choisir en faisant des compromis. La conception et la réalisation se
complètent. La conception a besoin d'expérimenter, la réalisation a besoin de principes directeurs.
Afin de maintenir le plus longtemps possible les bénéfices de l'abstraction, la conception est géné-
ralement subdivisée en deux étapes : une étape logique indépendante de l'environnement de réali-
sation et une étape physique qui se préoccupe de l'ordonnancement des ressources et des particula-
rités des langages de programmation ou de l'environnement d'exécution.
La conception est souvent considérée, à tort, comme un simple enrichissement des résultats obtenus
durant l'analyse. Il s'agit là d'une vision fortement réductrice 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'extérieur sous la forme d'outils, de composants réutilisables ou plus largement
de cadres de développement.2 [...]
La conception débute par la détermination 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 dévelop-
pement. L'architecture définit la forme générale de l'application; de sa qualité dépendent le déve-
loppement et l'évolution du logiciel. L'architecture est la conséquence de décisions stratégiques ar-
rêtées lors de la conception et de décisions tactiques prises en cours de réalisation.
1 I. JACOBSON, G. BOOCH, J. RUMBAUGH : op. cit.

2 "Frameworks".

Se donner une stratégie informatique, c'est considérer le logiciel comme un élément déterminant du
développement de l'entreprise; c'est aussi chercher à s'assurer une avance technologique par des
choix d'architecture qui dépassent le cadre des besoins immédiats, liés à une application particu-
lière.
Se donner une stratégie informatique, c'est par exemple choisir :
• l'internationalisation, autrement dit, concevoir le logiciel de telle manière que le dialogue avec
l'utilisateur puisse être mené dans toutes les langues;
• la réutilisation qui n'est pas le fruit du hasard, mais le résultat d'une adhésion forte de toute une
organisation, depuis la définition de la ligne de produits jusqu'au développement de ces produits;
• l'unicité de langage pour l'ensemble des développements (Ada dans le cas du ministère de la dé-
fense américain);
• l'indépendance par rapport aux dispositifs d'affichage, autrement dit, le découplage entre l'in-
formation à afficher et la manière de l'afficher;
• la portabilité des sources, voire des exécutables, qui réduit notablement les coûts de développe-
ment et surtout de maintenance dans le cas d'un logiciel multicibles.
• la généralisation des mécanismes 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 n’existe pas de solution toute blanche ou toute
noire : la vérité est toujours quelque part dans le gris. Les décisions tactiques couvrent toutes les
activités qui guideront la recherche de cette vérité dans l’effort de développement au jour le jour.
Elles contiennent par exemple les éléments suivants :
• la généralisation d’abstractions et de mécanismes pour les tâches ancillaires, autrement dit, tous
les composants largement réutilisables dans les programmes, comme les dates, les chaînes de ca-
ractères, les structures de données de base, les algorithmes de tri, etc.;
• le traitement des erreurs qui peut être effectué par des exceptions ou par des statuts exprimés sous
la forme de valeurs entières. L’exception ne peut être ignorée, mais son traitement obscurcit le code
normal. Le statut d’erreur est simple à mettre en œuvre mais il peut être ignoré : le traitement de
l’erreur n’est alors pas garanti;
• la gestion de la mémoire dynamique qui peut être effectuée par le programmeur ou automatisée
par l’environnement d’exécution;
• la communication entre processus qui peut reposer sur des liaisons point-à-point, multi-points ou
par diffusion. Elle peut être assurée par des mécanismes ad hoc ou inscrite dans un schéma général
d’intégration d’application 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, dérobante, minutée, asynchrone, etc;
• la présentation des messages utilisateur afin de rendre toutes les interactions avec l’utilisateur le
plus homogènes possible;
• les langages de programmation qui sont compilés ou interprétés et présentent des points forts et
des limites. Les langages compilés permettent d’écrire des programmes plus fiables, les langages
interprétés apportent plus de souplesse lors du développement. Dans certains cas, il peut être inté-
ressant de mélanger différents langages au sein de la même application;
• le choix des structures de données et des algorithmes qui sont encapsulés dans les objets afin de
découpler la spécification de la réalisation des classes;
• l’optimisation du réseau de relations qui reflète les besoins de communication de l’utilisateur. Le
concepteur peut être amené à modifier ce réseau pour diverses raisons : optimiser la vitesse des ac-
cès, prendre en compte des contraintes particulières de réalisation, comme l’absence de lien bi-
directionnel dans les langages de programmation de troisième génération;

• la mutation de certaines relations de généralisation parce que l’héritage multiple n’est pas dis-
ponible dans le langage de programmation utilisé ou encore parce que la forme de généralisation
recherchée doit être dynamique alors que l’héritage est statique;
• la mise en œuvre de composants réutilisables dans le cadre de deux réalités : la programmation
avec la réutilisation et la programmation pour la réutilisation. La première forme de réutilisation
consiste à incorporer un composant existant et ainsi à accélérer un développement en cours. La
deuxième s’apparente plus à un investissement : le coût est immédiat et les bénéfices ne sont perçus
que plus tard.
L'effort développé en conception est plus ou moins important selon la nature de l'application et la ri-
chesse de l'environnement de réalisation. Il est de plus en plus possible d'effectuer un transfert de
complexité des applications vers les environnements [de développement], grâce à une factorisation
des éléments et des mécanismes communs. C'est le cas dans les familles d'applications bien ciblées
dans un domaine donné, comme les logiciels clients qui interagissent avec des serveurs de bases de
données. Inversement, plus une application est technique, plus elle interagit avec des matériels par-
ticuliers et plus l'effort de conception est important.
Les outils RAD — développement rapide d'applications 1 — proposent une voie bien tracée.2 [...]
Il faut suivre les règles du jeu fixées à l'avance : au bénéfice de la simplicité mais au détriment 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 — plutôt que vite
et bien.
Curieusement, le RAD est un mélange de génie logiciel dans sa conception et d'horreur informatique
dans son utilisation. Ceci est la conséquence d'une vision à court terme des utilisateurs pour qui
seul l'aspect rapidité compte bien souvent. Comme le RAD n'encourage pas particulièrement la mo-
dularité et les abstractions en couches, très rapidement — c'est le cas de le dire — le code d'inter-
face utilisateur et le code de l'application se retrouvent intimement mélangés. Le logiciel construit
de cette manière est difficile à maintenir et quasiment impossible à réutiliser pour une autre appli-
cation.
Le propre de la conception est de rechercher l'équilibre entre vitesse de réalisation et possibilité de

réutilisation, ouverture et solution clé en main, vision à court terme (la tactique) et vision à long
terme (la stratégie). 3
3.2. Le concept d’architecture logicielle
Le texte ci-dessus évoque le concept d’architecture logicielle. Voyons plus concrètement en quoi cela
consiste.
1 RAD — "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il préconisa, en
1991 (éd. MacMillan Publishing), une nouvelle stratégie pour le développement des projets informatiques :
au lieu du comportement traditionnel consistant à définir d'abord les limites de l'application à réaliser et à voir
ensuite les équipes de développeurs accumuler les retards et dépasser toutes les prévisions budgétaires ... fixer
le budget au départ et demander aux équipes de développement de réaliser "ce qu'elles peuvent" dans ce cadre,
en créant des prototypes au moyen d'outils de programmation sophistiqués 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 "révolutionnaire" pour ne retenir que la suggestion de choisir des outils performants.
2 Les outils de développement 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 pièges.

Le concept d’architecture logicielle représente les aspects statiques et dynamiques les plus signifi-
catifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les
utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation. Elle subit,
néanmoins, l’influence d’autres facteurs, tels que la plate-forme sur laquelle devra s’exécuter le
système (par exemple, l’architecture matérielle, le système d’exploitation, le système de gestion des
bases de données, les protocoles de communication réseau), les briques de base réutilisables dispo-
nibles pour le développement (par exemple, une infrastructure préfabriquée (framework) [...]
pour les interfaces utilisateur graphiques), les considérations de déploiement, les systèmes existants
et les besoins non fonctionnels (par exemple, les performances, la fiabilité).
[...]
Les architectes vont donc "couler" le système dans une forme. Cette forme (l’architecture) doit être
conçue de façon à permettre l’évolution du système, non seulement dans le cadre de son développe-
ment initial, mais dans les années et les générations à venir. Pour déterminer une telle forme, les
architectes doivent travailler à partir d’une compréhension générale des principales fonctions, c’est-
à-dire des principaux cas d’utilisation du système. Ces cas d’utilisation peuvent ne représenter que
5 à 10 % de tous les cas d’utilisation du système, mais ils sont les plus significatifs, ceux qui consti-
tuent le cœur même des fonctions du système. En clair :
• L’architecte crée une ébauche grossière de l’architecture, en partant de l’aspect qui n’est pas
propre aux cas d’utilisation (par exemple, la plate-forme). Bien que cette partie de l’architecture
soit indépendante des cas d’utilisation, l’architecte doit avoir une compréhension globale de ceux-ci
avant d’esquisser l’architecture.
• Il travaille, ensuite, sur un sous-ensemble des cas d’utilisation identifiés, ceux qui représentent les
fonctions essentielles du système en cours de développement. [...]
• L’architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas

d’utilisation, qui favorisent, à leur tour, le développement d’un nombre croissant de cas d’utili-
sation.
Ce processus se poursuit jusqu’à ce que l’architecture soit jugée stable. 1
3.3. Le principe d'architecture « Client / Serveur »
a) Etat de l’art des développements informatiques
« L’informatique éclatée »
Naguère, 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 pensée ou paradigme — et un ordina-
teur unique, le programmeur concevait intégralement et dans ses moindres détails un algorithme de résolution,
le codait dans son unique langage et faisait exécuter le tout dans un environnement — l'ordinateur — immua-
ble et familier. L'équipe de programmation était la seule autorisée à fournir des programmes et il n'était pas
courant d'acheter un logiciel d'application "standard", par exemple de comptabilité, qui ne fût pas complète-
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 entrés dans l'ère de "l'informa-
tique éclatée".1
Le problème est maintenant de répartir les éléments d'une solution informatique sur les composants multifor-
mes d'une infrastructure matérielle et logicielle disparate.
Outils avancés
Le besoin de toujours plus grande qualité, en particulier dans la convivialité de l'interface homme–machine et
dans l'intégrité des données, contraint les informaticiens à recourir à des systèmes logiciels spécialisés pour la
gestion des interfaces et des bases de données.
Ces systèmes sont si sophistiqués et leur programmation si complexe qu'ils s'accompagnent d'outils de pro-
grammation, qualifiés "de quatrième génération", dont le paradigme déclaratif2 apporte une grande facilité de
programmation et de mise au point.
Il s'ensuit que les moyens mis en œuvre pour le développement mais aussi l'exploitation des applications in-
formatiques sont aujourd'hui hétérogènes. Il devient donc nécessaire de répartir la programmation entre les
différents outils. Quelle règle adopter pour cette répartition ? Outils hétérogènes et multiples, dont la durée
de vie n'est pas la même ... Lorsque, pour une raison quelconque, on est amené à remplacer un outil par un
autre, il faudrait idéalement qu'un minimum de programmation doive être refait.
Tout cela entraîne la nécessité de définir des principes d'architecture du logiciel, visant essentiellement à don-
ner des règles de répartition de la programmation. En complément, il est nécessaire de dire comment analyser
les éléments ainsi mis en place.
b) Définition de l’architecture Client / Serveur
Un système informatique construit selon une architecture client/serveur est un système dans lequel un pro-
gramme client adresse des requêtes à un programme serveur, lequel effectue pour le client les services de-
mandés. Ces deux programmes s'exécutent simultanément et communiquent directement entre eux, d'une
manière asymétrique : l'initiative des requêtes appartient exclusivement au programme client.
Habituellement, un programme serveur est capable de servir plusieurs clients en même temps. De plus en plus
souvent, les programmes serveur et clients s'exécutent sur des ordinateurs différents interconnectés : le ser-
veur s'exécute sur l'ordinateur central d'un réseau, les clients se trouvent sur les stations personnelles de ce
réseau (ce peut être le réseau INTERNET). Par extension, les qualificatifs "client" et "serveur" s'appliquent
également aux ordinateurs. Lorsqu'un serveur est incapable de satisfaire une requête, il peut parfois transférer
celle-ci à un autre serveur, auquel il est lui-même relié dans un réseau de serveurs.3
c) Règle de répartition
La répartition des fonctions logicielles devrait théoriquement se faire en trois lots, conformément au schéma
suivant :
1 J.M. DESAINTQUENTIN : L’informatique éclatée; Masson, 1991.

2 Le programmeur "déclare" (ou dessine) le résultat qu’il souhaite et l’outil crée automatiquement l’algo-
rithme nécessaire à la production de ce résultat.
3 INTERNET offre un réseau de serveurs à l'échelle mondiale, et de plus en plus d'organisations envisagent de
réaliser leur propre réseau sous les modalités d'INTERNET— on parle alors d'INTRANET. Soulignons que
choisir les modalités d'INTERNET, c'est opter pour une certaine standardisation ...

logiciel client logiciel serveur
(requêtes) (services)
gestionnaires d'interfaces bibliothèques de fonctions SGBD
scénarios procédures d'application serveur de données
– gestion d'écran – "calculs" – structures
– travail par lots ("batch") – algorithmes – relations invariantes
– édition de rapports
– édition de graphiques
– tableur
– navigateur Web
ordinateurs clients ordinateurs serveurs
Tout objet classé dans une colonne quelconque peut adresser des requêtes
aux seuls objets classés dans la colonne située immédiatement à sa droite.
• La clé de voûte d'une architecture telle que celle schématisée par cette figure est celle-ci : la même procé-
dure d'application (par exemple, d'établissement d'une facture) doit pouvoir "servir" différentes interfaces
clientes, à la même époque ou à des époques successives (est-ce rêver que d'imaginer que les procédures
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 nécessité qu'une procédure servante ne puisse s'exécuter qu'à travers un
seul scénario. Les différentes sortes de "guichets" d’une banque en sont une démonstration évidente : les
mêmes opérations, par exemple un virement de compte à compte, peuvent être demandées au guichetier d’une
agence bancaire ou directement effectuées par le client à un guichet automatique, via Internet ou au moyen
d’un combiné téléphonique ...
• Idéalement, le logiciel d'interface ne devrait comporter, outre les opérations strictes de présentation (cons-
titution des lots, mise en page du formulaire, du rapport, du graphique, de l'hypertexte ...), que les déclen-
cheurs des procédures d'application.2 Un "programme" à l'écran, d'impression ou de traitement par lots de-
vrait être perçu et construit comme un séquenceur de procédures d'application.
• Le logiciel (SGBD3) serveur de données assure la cohérence des données, en conservant les éléments
d'information et en garantissant leurs relations invariantes (contraintes et "triggers").4 Certains SGBD per-
mettent également de stocker les procédures d'accès aux données (ces procédures sont purement utilitaires et
leur identification n'est pas cruciale).
La répartition sur trois niveaux que nous venons de décrire caractérise la seconde génération (±
1995) des architectures client–serveur. Dans la première (± 1980), on ne distinguait que deux
composants : le SGBD serveur de données 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 réalisation
des interfaces d'utilisation. Le bénéfice de ces outils fut double : la qualité de la présentation aux
utilisateurs et le développement rapide des programmes (RAD — "rapid application development");
mais ce dispositif n'a pas rendu les solutions évolutives, car les procédures d'application restaient
empêtrées dans la gestion des interfaces.
1 La pression du marché des technologies informatiques fait que les entreprises ne sont pas entièrement maî-
tresses de l'évolution des interfaces à travers lesquelles elles doivent "servir" leurs données et procédures.
2 Ainsi défini, le logiciel d’interface rassemble donc des vues et des contrôleurs, selon la terminologie de
SMALLTALK. Cf. supra, § 2.5.
3 SGBD : Système de Gestion de Bases de Données.
4 Cf. chapitre 5.

A présent que s'est imposé le principe d'une répartition "three tiers" sur trois étages (et parfois da-
vantage ...), les programmeurs doivent lutter contre la tentation de facilité qui consiste, sous prétexte
de "développement rapide", à se servir des seuls outils visuels et à produire encore des solutions "à
l'ancienne" dans lesquelles les procédures d'application ne forment pas un ensemble distinct. La cou-
che intermédiaire met en œuvre le principe de masquage des données;1 elle garantit l’intégrité et la
confidentialité des données.2 La sécurité des données pourra encore être accrue si les données, d’une
part, et les procédures, d’autre part, sont hébergées sur des ordinateurs distincts.
d) Variété des paradigmes de programmation
La multiplicité des outils intervenant aujourd'hui dans une solution informatique de qualité entraîne le recours
à des paradigmes de programmation variés (la pensée du programmeur n'est plus uniforme !).
• Les SGBD relationnels, les plus employés actuellement, utilisent le langage standardisé SQL, de style dé-
claratif :
– les requêtes (SELECT) définissent sous la forme prédicative l'ensemble résultat produit par un al-
gorithme implicite;
– les contraintes et assertions, elles aussi exprimées sous une forme prédicative, font l'objet d'une vé-
rification automatique;
– les déclencheurs ("triggers") définissent des procédures 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 résultat qu'il sou-
haite. Souvent, ces outils visuels sont greffés sur un squelette de programme ("framework" = charpente)
sous-jacent et, plus d'une fois, le programmeur doit affiner le code "grossier" qu'ils génèrent.
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
Model–View–Controller 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. [...]

2 Les outils de développement rapide génèrent automatiquement des requêtes d’accès direct aux bases de don-
nées. C’est donc un effort considérable que les programmeurs doivent fournir pour les neutraliser et les rem-
placer par des requêtes sécurisées adressées aux procédures 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 procédures d'application — qu'il vaut mieux n'intégrer ni au dictionnaire de la base de données ni aux
objets d'interface — ne peuvent, dans une architecture éclatée, qu'être modulaires; au contraire des program-
mes anciens, elles ne renferment aucun scénario d'exécution. Elles sont donc réalisées sous la forme de sous-
programmes ou, mieux, de classes d'objets. Cette programmation possède donc encore la forme traditionnelle
des langages de 3e génération, quand bien même il s'agirait de langages orientés objets.
3.4. Motifs architecturaux ("Patterns")
Dans la conception des solutions aux différents problèmes 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 répètent fréquemment comme autant de motifs architecturaux
(en anglais : "patterns"2). Certains de ces motifs sont si généralement utilisés par la corporation des pro-
grammeurs, qu'ils reflètent un état de l'art collectif.3
Il est intéressant d’"institutionnaliser" ces manières de faire : le choix et la définition des motifs architectu-
raux — cela va de soi — relèvent de l’architecte ! Rendre communs (en d’autres termes, standardiser) les
"patterns" d’une équipe, c’est faire profiter tout le monde du savoir-faire des pionniers, c’est gagner du temps
de recherche et de mise au point, c’est rendre compréhensible et échangeable le travail de tous ...
Exemples
L’architecture client–serveur est un exemple fort de motif architectural.
Au sein d'une architecture Modèle–Vue–Contrôleur, le couple modèle–vue est un motif que l'on peut ré-
aliser de différentes manières. Une façon assez rudimentaire est de définir la vue (unique) en tant que
sous-classe "ornée" du modèle abstrait. De manière plus sophistiquée, le système SMALLTALK a pré-
programmé dans des classes abstraites (composant ce que nous appellerons plus loin un squelette) les
mécanismes de reflet entre vues et modèles : un nombre quelconque de vues peuvent être attachées à un
modèle et, chaque fois que l'état du modèle est modifié, celui-ci active la méthode afficher de chacune des
vues dont il possède la liste.
1 T. BUDD : An Introduction to Object-Oriented Programming, 2nd ed.; Addison-Wesley, 1997.

2 "Pattern" = forme. Ce terme anglais a la même origine étymologique que le terme patron dans le jargon des
couturières : forme en papier utilisée pour couper le tissu.
3 L'ogive fut un motif architectural caractéristique du Moyen Age dans toute l'Europe occidentale. La façade
en briques rouges avec encadrements de pierre bleue est un motif de l'architecture mosane traditionnelle.

Le langage JAVA a généralisé ce motif du reflet synchronisé entre un objet "observable" et des objets
"observateurs", entre un objet "événement" et des objets "à l'écoute" ("listeners") ...
Un motif que l'on rencontre très couramment est celui de la façade. Les requêtes de l'objet client ne sont
pas directement reçues par l'objet fournisseur des services demandés, mais par un objet intermédiaire qui
modifie les messages avant de les relayer vers le destinataire final. A l'objet client, cet objet intermédiaire
apparaît donc comme la "façade" de l'objet serveur. Les rôles de ces façades sont très variés :
– "proxy" transmettant, via un réseau, les requêtes à un serveur éloigné;

– aiguilleur ("dispatcher") sélectionnant parmi plusieurs serveurs le destinataire d'une requête;
– mémoire cache ou tampon accélérant l'accès aux données externes;
– filtre adaptateur, changeant la forme des données;
– fichier virtuel formé de la réunion de plusieurs fichiers physiques;
– terminal virtuel standardisé rendant les programmes indépendants de leur environnement réel;
– fenêtres "abstraites" (cf. JAVA) standardisant les différents systèmes d'interface graphique;
– etc.
Autre domaine propice à la mise au point de motifs architecturaux : la matérialisation des associations
entre objets. Un motif souvent mis en évidence est celui de la structure "maître ← détails" permettant de
traiter une association de type 1←n (ex.: 1 facture ← n lignes de facture, 1 commande ← n articles
commandés).
Autre domaine encore : la gestion du multilinguisme des programmes.
Selon les cas, un "pattern" sera décrit par un diagramme de collaboration d'objets ou un diagramme de clas-
ses, dont les éléments (objets ou classes) sont de types variables. Il pourra assez souvent être partiellement
pré-programmé, sous la forme de modèles générateurs à paramétrer ("templates") ou de squelettes de pro-
grammes à compléter ("frameworks").1
3.5. Industrialisation du processus de développement
L'éclosion des méthodes à base d'"objets" permet d'envisager une certaine industrialisation du processus d'in-
formatisation, en rendant possible la fabrication de composants logiciels réutilisables : types d’objets spécifi-
ques d’un domaine d’application ou "métier",2 "templates", etc. Cette nouvelle approche se substitue (ou
s'ajoute) à l'approche classique des informaticiens développant 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 méthodes de la programmation par objets, chapitre 7.

2 En français : "objets métier". 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
1B. MEYER : The New Culture of Software Development : Reflexions on the practice of Object-Oriented
Design, in Journ'ALMIN, n° 14, mars 1990.

Bibliographie
BACHMAN Ch. Data Structure Diagrams

in Data Base, 1969.
BERTINI M.Th. Le COBOL structuré, un modèle de programmation

TALLINEAU Y. éd. d'Informatique, 1974.
BODART F. Conception assistée des systèmes d'information

PIGNEUR Y. Masson, 1989.
BRAHMS Théorie et pratique des réseaux 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 connaître le COBOL 85

Presses Universitaires de Namur, 1991.
CLARINVAL A. MESANGE :
Méthode et Système d'Analyse et de Programmation de Gestion.
Groupe S
CLARINVAL A. Exploitation et Organisation des Fichiers

HEMES, 1998.
CLARINVAL A. Concepts et méthodes 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. L’informatique éclatée

Masson, 1991.
© A. CLARINVAL Analyse — Bibliographie B-1

GANE C. Structured Systems Analysis : tools and techniques
SARSON T. Prentice-Hall, 1979.
GEIB J.M.. CORBA, des concepts à la pratique

GRANSART Ch. Dunod, 1999
MERLE Ph. (cet ouvrage est téléchargeable sur le site
corbaweb.lifl.fr/CORBA_des_concepts_a_la_pratique/).
GILLET J.M. L'interface graphique

InterEditions, 1995.
HAINAUT J.L. Conception assistée des applications informatiques :

conception de la base de données
Masson, 1986.
JACKSON M. Principles of Program Design

Academic Press, 1975.
JACOBSON I. Le processus unifié de développement logiciel, trad. française

BOOCH G. Eyrolles, 2000.
RUMBAUGH J.
JACOBSON I., al. Object-Oriented Software Engineering : a Use Case Driven Approach
Addison-Wesley, 1992.
LE MOIGNE J.L. La théorie du système général

Presses Universitaires de France, 1977.
LISKOV B. Abstraction and Specification in Program Development

GUTTAG J. 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. Modélisation 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 systèmes d'information
et panorama des méthodes disponibles
in Génie Logiciel, n° 4.
RUMBAUGH A., al. OMT — Modélisation et conception orientées objet, trad. française
Masson, 1995.
SMITH J. Data Base Abstractions : Aggregation and Generalization

SMITH D. in ACM TODS, 1977.
TARDIEU H. La méthode MERISE

ROCHFELD A. éd. d'Organisation, 1983.
COLLETTI R.
TSICHRITZIS D. The ANSI/X3/SPARC DBMS Framework

KLUG A. in Information Systems, 1978.
WARNIER J.D. Les procédures de traitement et leurs données

éd. d'Organisation, 1973.
WEIZENBAUM J. Puissance de l'ordinateur et raison de l'homme, trad. française

éd. d'Informatique, 1981.
WIENER N. Cybernétique et société, trad. française

éd. des Deux Rives, 1952.
YOURDON E. Modern Structured Analysis

Prentice-Hall, 1989.

Table des matières
CHAPITRE 1. INTRODUCTION AUX MÉTHODES D'ANALYSE ..................................................... 1-1

1. Systèmes 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 systèmes d'information........................................................................................................ 1-3
2.1. Etapes de l'analyse............................................................................................................................................. 1-3
2.2. Niveaux de modélisation ................................................................................................................................... 1-4
2.3. Articulation générale de la démarche ................................................................................................................ 1-6
3. Méthodologie de l'analyse ...................................................................................................................... 1-8
3.1. Contenu d'une méthodologie ............................................................................................................................. 1-8
3.2. Utilité d'une méthode......................................................................................................................................... 1-9
3.3. Schémas et Maquettes ..................................................................................................................................... 1-10
3.4. Modélisation et Programmation ...................................................................................................................... 1-12
3.5. L'équipe de développement ............................................................................................................................. 1-12
4. Contenu du cours : Modélisation des applications informatiques ...................................................... 1-14
CHAPITRE 2. INTRODUCTION À LA MODÉLISATION DES DONNÉES....................................... 2-1
1. BASES DE DONNÉES ET MODÉLISATION ....................................................................................................... 2-2
1.1. Le concept de Système de Gestion de Bases de Données (SGBD)...................................................... 2-2
1.2. Niveaux de modélisation...................................................................................................................... 2-2
a) Vues externes ....................................................................................................................................................... 2-2
b) Vue conceptuelle.................................................................................................................................................. 2-3
c) Vue interne ........................................................................................................................................................... 2-3
1.3. Langage de description de données — Schémas................................................................................. 2-4
2. FONDEMENTS DES TECHNIQUES DE MODÉLISATION DES DONNÉES ............................................................... 2-5
2.1. Les mécanismes d'abstraction ............................................................................................................. 2-5
a) Classification : Type, Classe, Occurrence, Collection......................................................................................... 2-5
b) Spécialisation, Généralisation .............................................................................................................................. 2-6
2.2. Mécanisme de désignation des occurrences........................................................................................ 2-7
a) La relation de dépendance fonctionnelle .............................................................................................................. 2-7
b) Le concept d'identifiant ........................................................................................................................................ 2-7
2.3. Dimensions temporelles de l'information ............................................................................................ 2-7
a) Durée de vie ......................................................................................................................................................... 2-7
b) Période de validité................................................................................................................................................ 2-8
c) Période de mémorisation, Durée de rétention....................................................................................................... 2-8
2.4. Contraintes d'intégrité ......................................................................................................................... 2-8
2.5. Aspects dynamiques des données......................................................................................................... 2-9
3. PANORAMA HISTORIQUE ............................................................................................................................ 2-10
3.1. Les SGBD opérationnels ................................................................................................................... 2-10
3.2. Les méthodes d'analyse ..................................................................................................................... 2-10
a) Modèles d'analyse des données .......................................................................................................................... 2-10
b) Outils d'aide à la conception .............................................................................................................................. 2-11
c) Plan du cours ...................................................................................................................................................... 2-11
i
CHAPITRE 3. LE SCHÉMA CONCEPTUEL DES DONNÉES ............................................................. 3-1
1. LE MODÈLE ENTITÉ–ASSOCIATION .............................................................................................................. 3-2
1.1. Contenu du modèle Entité–Association ............................................................................................... 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 connectivités dans la notation UML............................................................................................................... 3-8
c) Attribut ................................................................................................................................................................. 3-9
Attribut et Domaine............................................................................................................................................... 3-9
Noms d'attributs .................................................................................................................................................. 3-11
Propriétés des attributs ........................................................................................................................................ 3-11
Définition 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
Propriétés des identifiants ................................................................................................................................... 3-15
e) Dimension historique ......................................................................................................................................... 3-16
f) Discussion........................................................................................................................................................... 3-17
1.2. Structures particulières ..................................................................................................................... 3-18
a) Compositions sémantiquement équivalentes ...................................................................................................... 3-18
b) Associations non représentables......................................................................................................................... 3-18
Critique du modèle Entité–Association............................................................................................................... 3-19
2. APPORTS DU PARADIGME OBJET ................................................................................................................ 3-20
2.1. Classes d'objets.................................................................................................................................. 3-20
a) Les concepts ....................................................................................................................................................... 3-20
b) Spécification des opérations............................................................................................................................... 3-21
Spécification externe........................................................................................................................................... 3-21
Définition sémantique ......................................................................................................................................... 3-22
c) Aperçu sur le langage IDL.................................................................................................................................. 3-22
2.2. Modélisation des relations d’abstraction .......................................................................................... 3-24
a) Agrégation / Contenance .................................................................................................................................... 3-24
b) Classification / Instanciation .............................................................................................................................. 3-26
c) Généralisation / Spécialisation ........................................................................................................................... 3-27
2.3. Schéma dynamique : diagrammes d’états et transitions................................................................... 3-28
a) Etats.................................................................................................................................................................... 3-28
b) Transitions.......................................................................................................................................................... 3-29
c) Méthode.............................................................................................................................................................. 3-30
3. CONTRAINTES D'INTÉGRITÉ........................................................................................................................ 3-31
3.1. Portée des contraintes d’intégrité ..................................................................................................... 3-31
3.2. Connectivité et identifiant.................................................................................................................. 3-31
3.3. Durée de rétention ............................................................................................................................. 3-31
3.4. Contraintes ensemblistes ................................................................................................................... 3-32
3.5. Règles relatives à la valeur des attributs........................................................................................... 3-32
a) Définition des domaines de valeurs.................................................................................................................... 3-32
Domaine élémentaire........................................................................................................................................... 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. Définition sémantique des opérations ............................................................................................... 3-35
3.7. Formalisme pour l'expression des règles .......................................................................................... 3-36
a) La notion de règle............................................................................................................................................... 3-36
b) La notion de variable.......................................................................................................................................... 3-36
c) Les ensembles..................................................................................................................................................... 3-38
ii
4. VALIDATION DU SCHÉMA........................................................................................................................... 3-39
4.1. Suppression des incohérences ........................................................................................................... 3-39
a) Correction des anomalies lexicographiques ....................................................................................................... 3-39
b) Vérification des contraintes, Elimination des contradictions ............................................................................. 3-39
4.2. Affinage du schéma............................................................................................................................ 3-39
a) Normalisation des composants ........................................................................................................................... 3-39
b) Spécialisation par sous-typage ........................................................................................................................... 3-41
Généralisations implicites ................................................................................................................................... 3-41
Associations conditionnelles............................................................................................................................... 3-41
4.3. Simplification du schéma................................................................................................................... 3-42
a) Simplification des structures .............................................................................................................................. 3-42
Associations de degré élevé ................................................................................................................................ 3-42
Compositions de connectivités 1:1...................................................................................................................... 3-42
b) Contrôle des structures redondantes................................................................................................................... 3-43
c) Cas particulier : les attributs dérivables............................................................................................................. 3-43
4.4. Note sur les sous-schémas ................................................................................................................. 3-44
5. VALIDATION DU SYSTÈME DE RÈGLES........................................................................................................ 3-45
5.1. Complétude du système de règles ...................................................................................................... 3-45
5.2. Cohérence du système de règles ........................................................................................................ 3-45
6. EN GUISE DE CONCLUSION ......................................................................................................................... 3-46
6.1. Recommandations diverses................................................................................................................ 3-46
6.2. Documentation du schéma................................................................................................................. 3-47
CHAPITRE 4. SCHÉMA LOGIQUE DU STOCKAGE DES DONNÉES .............................................. 4-1
1. SCHÉMA DES STRUCTURES DE STOCKAGE : LE MODÈLE EN RÉSEAU ........................................................... 4-2
1.1. Eléments d'une structure de stockage.................................................................................................. 4-2
1.2. Transformation du schéma Entité–Association ................................................................................... 4-2
1.3. Commentaires sur le concept de liaison .............................................................................................. 4-6
a) Terminologie ........................................................................................................................................................ 4-7
b) Contraintes définies sur les liaisons ..................................................................................................................... 4-7
Liaison obligatoire ou facultative.......................................................................................................................... 4-7
Connectivité d'un type de liaison .......................................................................................................................... 4-7
c) Interprétation d'une liaison comme étant une association..................................................................................... 4-8
1.4. Optimisation du schéma ...................................................................................................................... 4-9
a) Généralisation....................................................................................................................................................... 4-9
b) Dénormalisation ................................................................................................................................................. 4-10
Propagation parent ==> enfants .......................................................................................................................... 4-10
Dérivation parent(s) ==> enfants ........................................................................................................................ 4-11
Récapitulation enfants ==> parent ...................................................................................................................... 4-12
Fusion des enregistrements parent et enfants ...................................................................................................... 4-12
1.5. Structures particulières ..................................................................................................................... 4-12
a) Enregistrement d'intersection ............................................................................................................................. 4-12
b) Liaison cyclique ................................................................................................................................................. 4-13
1.6. Contraintes d'intégrité ....................................................................................................................... 4-14
a) Reformulation des règles .................................................................................................................................... 4-14
b) Relaxation des contraintes de connectivité 1:N.................................................................................................. 4-14
c) Intégrité des références....................................................................................................................................... 4-15
Création du propriétaire d'une liaison ................................................................................................................. 4-15
Suppression du propriétaire d'une liaison ........................................................................................................... 4-15
2. PRÉPARATION DU SCHÉMA PHYSIQUE ........................................................................................................ 4-16
2.1. Schéma des fonctions d'accès ............................................................................................................ 4-16
a) Introduction ........................................................................................................................................................ 4-16
b) Préliminaire : le concept d'ensemble selon CODASYL .................................................................................... 4-16
c) Définition des méthodes d'accès ........................................................................................................................ 4-17
Clé d'accès........................................................................................................................................................... 4-17
Séquence d'accès ................................................................................................................................................. 4-18
Chemin d'accès.................................................................................................................................................... 4-19
2.2. Quantification du schéma.................................................................................................................. 4-20
iii
3. LE SCHÉMA LOGIQUE DES DONNÉES, SUPPORT DE LA PROGRAMMATION.................................................... 4-21
3.1. Parcours d'un ensemble..................................................................................................................... 4-21
3.2. Sous-schéma arborescent .................................................................................................................. 4-21
3.3. Transformation séquentielle des sous-schémas arborescents............................................................ 4-23
a) Constitution des fichiers séquentiels .................................................................................................................. 4-23
b) Cas particulier : ensembles hétérogènes............................................................................................................ 4-23
c) Syntaxe de définition.......................................................................................................................................... 4-24
d) Contraintes particulières aux fichiers COBOL................................................................................................... 4-24
e) Réalisation des fonctions d'accès........................................................................................................................ 4-25
Fonctions d'accès internes à un fichier séquentiel............................................................................................... 4-25
Fonctions d'accès inter-fichiers ........................................................................................................................... 4-26
3.4. Méthode de construction des programmes ........................................................................................ 4-27
a) Graphe des accès aux données............................................................................................................................ 4-28
b) Règles du traitement........................................................................................................................................... 4-29
c) Structure du programme ..................................................................................................................................... 4-30
CHAPITRE 5. SCHÉMA PHYSIQUE DE LA BASE DE DONNÉES .................................................... 5-1
1. LES BASES DE DONNÉES CODASYL ........................................................................................................... 5-2
1.1. Le langage de description de données (DDL) .................................................................................... 5-3
a) Schéma de la base de données.............................................................................................................................. 5-3
Fichiers (AREA) .................................................................................................................................................. 5-3
Enregistrements (RECORD) ................................................................................................................................ 5-3
Ensembles (SET).................................................................................................................................................. 5-4
Clés d'accès et identifiants..................................................................................................................................... 5-6
Exemple récapitulatif ............................................................................................................................................ 5-6
b) Sous-schémas ....................................................................................................................................................... 5-8
1.2. Le langage de manipulation des données (DML)............................................................................... 5-8
a) Contrôle de l'accès aux fichiers : OPEN, CLOSE ............................................................................................... 5-8
b) Les mécanismes 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 données ..................................................................................................................................... 5-10
Création/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 DONNÉES RELATIONNELLES ................................................................................................ 5-12
2.1. Le modèle relationnel des données.................................................................................................... 5-12
a) Les relations ....................................................................................................................................................... 5-12
b) Identification et Normalisation........................................................................................................................... 5-14
c) L'algèbre relationnelle (pour mémoire) ............................................................................................................. 5-14
2.2. Le dictionnaire des données (SQL)................................................................................................... 5-15
a) Définition des domaines ..................................................................................................................................... 5-15
b) Définition des tables........................................................................................................................................... 5-16
Note sur les contraintes d'intégrité référentielle .................................................................................................. 5-18
c) Définition des assertions..................................................................................................................................... 5-18
Note sur les transactions et la vérification des contraintes .................................................................................. 5-19
d) Mise à jour automatique des données dérivables ............................................................................................... 5-19
e) Les vues.............................................................................................................................................................. 5-22
f) Création d’index ................................................................................................................................................. 5-23
2.3. La manipulation des données ............................................................................................................ 5-24
a) Opérations disponibles ....................................................................................................................................... 5-24
Consultation : SELECT ..................................................................................................................................... 5-24
Création 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
iv
c) SQL inséré.......................................................................................................................................................... 5-26
Repérage des instructions SQL insérées.............................................................................................................. 5-26
Communication des données............................................................................................................................... 5-26
Signalisation des incidents .................................................................................................................................. 5-26
Les curseurs......................................................................................................................................................... 5-27
Exemple COBOL ................................................................................................................................................ 5-27
CHAPITRE 6. INTRODUCTION À LA MODÉLISATION DES SYSTÈMES..................................... 6-1
1. HIÉRARCHISATION DU SYSTÈME D'INFORMATION ........................................................................................ 6-2
1.1. Système ................................................................................................................................................ 6-2
1.2. Tâche ................................................................................................................................................... 6-3
Programme ................................................................................................................................................................ 6-4
Objet.......................................................................................................................................................................... 6-4
Tâche = Transaction .................................................................................................................................................. 6-4
1.3. Module................................................................................................................................................. 6-5
2. NIVEAUX INTERMÉDIAIRES .......................................................................................................................... 6-6
CHAPITRE 7. LES DIAGRAMMES DE FLUX ....................................................................................... 7-1
1. SCHÉMA FONCTIONNEL ............................................................................................................................... 7-2
1.1. Contenu d'un diagramme de flux......................................................................................................... 7-2
a) Environnement ..................................................................................................................................................... 7-2
b) Processus.............................................................................................................................................................. 7-3
c) Flux de données.................................................................................................................................................... 7-4
Flux direct, Messages............................................................................................................................................ 7-4
Flux indirect, Dépôt de données............................................................................................................................ 7-6
Perméabilité des classes de flux directs et indirects .............................................................................................. 7-8
1.2. Structures typiques .............................................................................................................................. 7-8
a) Applications sans flux directs............................................................................................................................... 7-8
b) Décomposition suivant un axe spatio-temporel dominant.................................................................................... 7-9
c) Systèmes régulés................................................................................................................................................. 7-10
1.3. Validation des diagrammes de flux.................................................................................................... 7-11
a) Syntaxe des diagrammes de flux......................................................................................................................... 7-11
Relations entre composants................................................................................................................................. 7-11
Dénomination des composants............................................................................................................................ 7-12
Remarque. Mise en page d'un diagramme de flux.............................................................................................. 7-12
b) Hiérarchisation des diagrammes......................................................................................................................... 7-12
1.4. Spécification d'un processus.............................................................................................................. 7-14
a) Description externe de la fonction...................................................................................................................... 7-15
b) Description de l'interface d'une tâche................................................................................................................. 7-16
c) Spécification détaillée des règles........................................................................................................................ 7-16
Niveaux de définition des règles ......................................................................................................................... 7-16
Expression des règles .......................................................................................................................................... 7-16
Vérification des règles......................................................................................................................................... 7-17
d) Définition interne de la procédure...................................................................................................................... 7-17
2. SCHÉMA DYNAMIQUE ................................................................................................................................ 7-21
2.1. Contenu du schéma dynamique ......................................................................................................... 7-21
a) Processus ............................................................................................................................................................ 7-21
b) Evénement.......................................................................................................................................................... 7-21
c) Moniteur............................................................................................................................................................. 7-23
2.2. Types d'enchaînements ...................................................................................................................... 7-24
2.3. Spécification d'un moniteur ............................................................................................................... 7-25
2.4. Validation du schéma dynamique...................................................................................................... 7-26
a) Complétude du schéma....................................................................................................................................... 7-26
b) Cohérence du schéma......................................................................................................................................... 7-27
Evénements initiaux ............................................................................................................................................ 7-27
Processus atteignables......................................................................................................................................... 7-28
Terminaison propre ............................................................................................................................................. 7-28
3. SCHÉMA DE DÉPLOIEMENT ........................................................................................................................ 7-29
v
CHAPITRE 8. MÉTHODES ORIENTÉES OBJETS ............................................................................... 8-1
1. SCHÉMAS D’OPÉRATIONS ............................................................................................................................ 8-2
1.1. Préambule : unification des méthodes autour du concept d’Objet..................................................... 8-2
1.2. Les diagrammes d’interaction ............................................................................................................. 8-2
a) Concepts introductifs............................................................................................................................................ 8-2
b) Notations communes ............................................................................................................................................ 8-3
c) Diagramme de collaboration................................................................................................................................. 8-4
d) Diagramme de séquence....................................................................................................................................... 8-4
2. LE SCHÉMA DES CAS D’UTILISATION ........................................................................................................... 8-6
2.1. Préambule : le contexte historique ..................................................................................................... 8-6
a) Libéralisation de l'usage des ordinateurs .............................................................................................................. 8-6
b) Modernisation des méthodes d’analyse................................................................................................................ 8-7
2.2. Contenu du modèle des Cas d’Utilisation ........................................................................................... 8-8
a) Système ................................................................................................................................................................ 8-8
b) Acteur................................................................................................................................................................... 8-8
Acteur externe ....................................................................................................................................................... 8-8
c) Cas d’utilisation.................................................................................................................................................... 8-9
d) Scénario.............................................................................................................................................................. 8-10
2.3. Spécification des scénarios................................................................................................................ 8-11
a) Flot d’événements .............................................................................................................................................. 8-11
b) Diagramme de séquence..................................................................................................................................... 8-12
2.4. Relations entre cas d’utilisation ........................................................................................................ 8-12
a) Relations concrètes............................................................................................................................................. 8-13
Utilisation............................................................................................................................................................ 8-13
Extension ............................................................................................................................................................ 8-13
b) Relations abstraites............................................................................................................................................. 8-14
Inclusion.............................................................................................................................................................. 8-14
Généralisation ..................................................................................................................................................... 8-14
2.5. Analyse des cas d’utilisation : du scénario aux objets ..................................................................... 8-15
a) Classification des composants ............................................................................................................................ 8-15
L’architecture Modèle–Vue–Contrôleur (SMALLTALK)................................................................................. 8-15
Les classes d’analyse (JACOBSON).................................................................................................................. 8-16
Commentaires ..................................................................................................................................................... 8-17
b) Diagramme de collaboration .............................................................................................................................. 8-17
c) Diagramme des classes "conceptuelles" ............................................................................................................. 8-19
3. CONCEPTION D’UNE ARCHITECTURE LOGICIELLE ....................................................................................... 8-20
3.1. Nature de la démarche de conception ............................................................................................... 8-20
3.2. Le concept d’architecture logicielle .................................................................................................. 8-22
3.3. Le principe d'architecture « Client / Serveur » ................................................................................. 8-23
a) Etat de l’art des développements informatiques ................................................................................................. 8-23
« L’informatique éclatée »................................................................................................................................... 8-23
Outils avancés ..................................................................................................................................................... 8-24
b) Définition de l’architecture Client / Serveur ...................................................................................................... 8-24
c) Règle de répartition ............................................................................................................................................ 8-24
d) Variété des paradigmes de programmation ........................................................................................................ 8-26
3.4. Motifs architecturaux ("Patterns") ................................................................................................... 8-27
3.5. Industrialisation du processus de développement ............................................................................. 8-28
BIBLIOGRAPHIE ........................................................................................................................................B-1
vi

Analyse PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Analyse PDF

Uploaded by

Copyright:

Available Formats

H.E.M.E.S.

édition : septembre 2002

1.1. Le concept d'information

1.2. Applications de l'informatique à la gestion des organisations humaines

1 J. de ROSNAY : Le macroscope; éd. du Seuil, 1975.

© A. CLARINVAL Analyse — Introduction 1-1

1.3. Applications techniques et scientifiques de l'informatique

© A. CLARINVAL Analyse — Introduction 1-2

2.1. Etapes de l'analyse

• L'analyse fonctionnelle détaille le "quoi" de la solution, pas encore le comment : "abstraction

De manière générale [...], le développement d'une application répond à quatre questions :

Application = Quoi + Dans quel domaine + Comment + Avec quelles compétences

1 J. RUMBAUGH, al. : op. cit.

© A. CLARINVAL Analyse — Introduction 1-3

• Comment ? Il faut le déterminer lors de la conception. Le comment est le fruit de l'expérience et

2.2. Niveaux de modélisation

1 P.A. MULLER : Modélisation objet avec UML; Eyrolles, 1997.

© A. CLARINVAL Analyse — Introduction 1-4

types d'objets ou concepts : CLIENT, COMMANDE

clés d'accès : référence du CLIENT dans l'enregistrement COMMANDE

© A. CLARINVAL Analyse — Introduction 1-5

regroupements de données (fusion de types d'objets ...)

2.3. Articulation générale de la démarche

L'analyse se poursuit par la modélisation du domaine de l'application, c'est-à-dire par l'identifica-

© A. CLARINVAL Analyse — Introduction 1-6

Parallèlement à l'analyse de l'environnement, se déroule parfois une analyse de l'existant et des

La conception débute par la détermination de l'architecture du logiciel, c'est-à-dire par l'élabora-

Se donner une stratégie informatique, c'est par exemple choisir :

© A. CLARINVAL Analyse — Introduction 1-7

Le propre de la conception est de rechercher l'équilibre entre vitesse de réalisation et possibilité de

3.1. Contenu d'une méthodologie

© A. CLARINVAL Analyse — Introduction 1-8

– support (enregistrement et restitution) des formalismes, particulièrement des dessins;

3.2. Utilité d'une méthode

[Une] méthode est nécessaire :

– pour maîtriser la complexité du problème informationnel à résoudre;

1 P.A. MULLER : op. cit.

© A. CLARINVAL Analyse — Introduction 1-9

Le diagramme suivant représente les cinq niveaux de maturité des processus. 1

– de dicter l’organisation des activités de l’équipe;

3.3. Schémas et Maquettes

1 P.A. MULLER : op. cit.

© A. CLARINVAL Analyse — Introduction 1-10

1 J. RUMBAUGH, al. : op. cit.

© A. CLARINVAL Analyse — Introduction 1-11

3.4. Modélisation et Programmation

3.5. L'équipe de développement

1 J.M. GILLET : L'interface graphique; InterEditions, 1995.

© A. CLARINVAL Analyse — Introduction 1-12

De manière générale, un processus de développement de logiciel peut se décomposer en trois sous-

– le développement informatique proprement dit,

– l'architecte définit la forme générale du logiciel [...];

– le chef de projet assure l'interface entre l'équipe de développement et le reste du monde;

© A. CLARINVAL Analyse — Introduction 1-13

4. Contenu du cours : Modélisation des applications informatiques

1 P.A. MULLER : op. cit

© A. CLARINVAL Analyse — Introduction 1-14

P.A. MULLER : Modélisation objet avec UML; Eyrolles, 1997.

Le second de ces ouvrages constitue la définition officielle d’UML.

© A. CLARINVAL Analyse — Introduction 1-15

© A. CLARINVAL Analyse — Modélisation des données 2-1

1.1. Le concept de Système de Gestion de Bases de Données (SGBD)

Le principe d'intégration entraînait de nombreuses conséquences : la nécessité de supprimer la redondance ou