Vous êtes sur la page 1sur 218

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

(graphiques, dessins, photos, vidéos

).

une machine (ordinateur, robot

diate ou différée, de son comportement.

picturales

) 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

) attache une signification susceptible d'entraîner une modification, immé-

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

ces

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.

les flux financiers, les échanges de servi-

qui forment la matière de l'activité de l'entreprise. Reçue par les acteurs de l'organisation, elle com-

),

Si, d'après J. de ROSNAY 1 , "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 MERISE 2 , 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.

SYSTEME DE DECISION/PILOTAGE support SYSTEME D'INFORMATION commande reflet SYSTEME OPERANT
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-

Nous appellerons applications informatiques "applications de l'informatique" serait plus correct

ques)

— 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.

"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.

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

"Comment ?"

tructions — programmes et procédures — utilisant au mieux les ressources techniques et organisa- tionnelles : logiciels, équipements, personnel, locaux, horaires, etc.

L'étape de conception définit la réalisation de ce système sous la forme de cons-

De manière générale [ ], le développement d'une application répond à quatre questions : Application
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-
• 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.

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

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 facture 2

• 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.

Exemples de spécifications :

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.

Exemples de spécifications :

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 :
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 ax 2 + by 2 + 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 terme (la stratégie). 3

et vision à long

(la tactique)

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

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

WinDev, PowerBuilder, Delphi, C++ Builder, ViewAge et d'in-

ensuite les équipes de développeurs accumuler les retards et dépasser toutes les prévisions budgétaires

(ex.:

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

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.

) unissant ces concepts. Concepts et lois qui per-

• 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

1 P.A. MULLER : op. cit.

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.

1 P.A. MULLER : op. cit.

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

3 P.A. MULLER : op. cit.

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

Les croquis permettent aux

artistes de jeter leurs idées et de les modifier avant de passer à l'huile ou à la pierre.

passages inutiles peuvent être modifiés avant l'écriture du script final.

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.

mations à la fois. Les modèles réduisent la complexité dans la mesure où ils isolent un petit nombre

Le cerveau humain ne peut travailler qu'avec une somme limitée d'infor-

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.

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

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

plications. Mais les risques d'erreurs ont grandi d'autant : les variations possibles sont si nombreu-

— offre des possibilités immenses pour les développeurs d'ap-

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

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.

programmation, son coût exorbitant

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
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 :

1981.

3 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information; Masson, 1989.

Puissance de l'ordinateur et raison de l'homme, trad. française;

éd. d'Informatique,

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.

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-

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.

duit (numéro et dénomination), prix de vente unitaire, taux de TVA (en % du prix de vente),

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
répartir sur plusieurs ordinateurs vue externe vue externe vue externe vue externe vue interne vue conceptuelle
répartir sur plusieurs ordinateurs vue externe vue externe vue externe vue externe vue interne vue conceptuelle
répartir sur plusieurs ordinateurs vue externe vue externe vue externe vue externe vue interne vue conceptuelle
vue externe
vue externe

vue externe

vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle

vue interne

vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle

vue conceptuelle

vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue interne vue conceptuelle
vue externe vue externe vue interne vue conceptuelle Ce modèle de démarche, à trois niveaux de

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-

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.

nie ("toute personne ayant

")

Tout élément appartenant à une classe ou un type est une occurrence (en anglais : "instance") de cette classe ou de ce type.

Exemples :

type ETUDIANT NOMBRE ENTIER SEXE COMMANDE FICHIER DE COMMANDES

occurrences Jean, Jacques, Emile 1, 3, 37, 1236, 3217 masculin, féminin la-commande-reçue-aujourd'hui-du-client-X 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.

1 J. RUMBAUGH, al. : OMT — Modélisation et conception orientées objet, trad. française; Masson, 1995.

occurrence collection classe type La définition d'un type est une définition d'ensemble, le plus souvent

occurrence

collectionoccurrence classe type La définition d'un type est une définition d'ensemble, le plus souvent en compréhension

classeoccurrence collection type La définition d'un type est une définition d'ensemble, le plus souvent en

typeoccurrence collection classe La définition d'un type est une définition d'ensemble, le plus souvent en

occurrence collection classe type La définition d'un type est une définition d'ensemble, le plus souvent en

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

plus certaines propriétés spécifiques; un CLIENT-

toutes les propriétés d'un membre du PERSONNEL

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 OUVRIERS EMPLOYES Pierre Jacques Paul André
PERSONNEL
OUVRIERS
EMPLOYES
Pierre
Jacques
Paul
André
CLIENT nom adresse hérite hérite PRIVE PROFESS. n°TVA
CLIENT
nom
adresse
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é tions détenues).

(on tient pour actuelles toutes les informa-

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 riation.

mais, comme diraient les musiciens, chacun joue sur ce thème sa propre va-

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,

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

l’Object Management Group (OMG) a adopté comme standard l’Unified Modeling Language (UML). 2

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.)

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
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.

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.

Pour l'exposé qui suit, nous nous baserons principale-

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.
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.
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
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
parent
FILIATION
PERSONNE
enfant
mari
épouse
HOMME
CONJOINT
FEMME
COMPOSITION composé FOURNISSEUR composant PRODUIT livrant entreposé FOURNITURE STOCK livré contenant PRODUIT
COMPOSITION
composé
FOURNISSEUR
composant
PRODUIT
livrant
entreposé
FOURNITURE
STOCK
livré
contenant
PRODUIT
PRODUIT
MAGASIN
FABRIQUE
DISTRIBUE
MATIERE
dispensée ENSEIGNEMENT titulaire suivant
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],

(STOCK) [MAGASIN] ou [MAGASIN] (STOCK) [PRODUIT]

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.

[PRODUIT]

Contrairement aux recomman-

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 PERSONNE FILIATION enfant mari épouse HOMME FEMME CONJOINT
parent
PERSONNE
FILIATION
enfant
mari
épouse
HOMME
FEMME
CONJOINT
composé COMPOSITION FOURNISSEUR composant PRODUIT livrant entreposé FOURNITURE STOCK contenant livré MAGASIN
composé
COMPOSITION
FOURNISSEUR
composant
PRODUIT
livrant
entreposé
FOURNITURE
STOCK
contenant
livré
MAGASIN
PRODUIT
PRODUIT
FABRIQUE
DISTRIBUE

MATIERE

dispensée titulaire suivant
dispensée
titulaire
suivant

ENSEIGNEMENT

PROFESSEUR

CLASSE

Connectivité des associations

Soit un type d'association A (E i r i ,

).

– A chaque association du type A participe sous chacun des rôles r i une entité exactement.

– A chacun des rôles r i mis en jeu est attaché un couple d'entiers (min i , max i ), qui en définissent la connectivité (on dit aussi : la cardinalité) et qui, dans les méthodes de tradition française, signi- fient :

– le nombre minimum d'occurrences de A auxquelles,

min i

à

tout moment, participe toute occurrence de E i ;

– le nombre maximum d'occurrences de A auxquelles,

max i

à tout moment, participe toute occurrence de E i .

Les valeurs habituelles sont :

min i = 0 ou 1

signifiant une participation facultative ou obligatoire,

max i = 1 ou N ou *

signifiant une participation unique ou multiple (N ou * 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 enfant 0,2 mari épouse HOMME CONJOINT FEMME 0,1 0,1
0,N
parent
FILIATION
PERSONNE
enfant
0,2
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

COMMANDE

facturée

 

émise

 

0,1

FACTURATION

1,1

FACTURE

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
COMPOSITION
composé
FOURNISSEUR
0,N
composant
PRODUIT
livrant
entreposé
1,N
0,1
FOURNITURE
STOCK
1,1
contenant 0,N
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
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. versions.

Comparez attentivement les deux

0 2 parent PERSONNE FILIATION 0 * enfant 0 1 0 1 HOMME FEMME mari
0 2
parent
PERSONNE
FILIATION
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
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
PRODUIT
PRODUIT
MAGASIN
DISTRIBUE
FABRIQUE

1 Cette 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
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

c) Attribut

Attribut et Domaine

1

peut être laissée implicite; elle peut aussi s'écrire 1.

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

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

CLIENT nom-client NOM

adresse-client

ADRESSE

Dupont, Dupond château de et à Moulinsart

PRODUIT nom-produit LIBELLE chaussettes, jupe, draps

prix-de-vente

PRIX

quantité-en-stock QUANTITE COMMANDE qté-commandée QUANTITE

date-d'émission DATE date-de-livraison DATE CONJOINT date-de-mariage DATE

89, 879, 2299 433 lots,2500 pièces,1000 paires 1 lot, 1 pièce, 3 paires 20 avril 1995 30 avril 1995 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

PERSONNE nom date naissance FEMME HOMME nom de jeune fille mari épouse 0,1 0,1 CONJOINT
PERSONNE
nom
date naissance
FEMME
HOMME
nom de jeune fille
mari
épouse
0,1
0,1
CONJOINT
dat e mariage

UML

PERSONNE nom date naissance 0 1 0 1 FEMME HOMME nom de jeune fille mari
PERSONNE
nom
date naissance
0
1
0
1
FEMME
HOMME
nom de jeune fille
mari
épouse
CONJOINT
date mariage

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
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
PASSATION
1,1
COMMANDE
nom client
0,N
dat e commande
n° commande
adresse client
passée

UML

CLIENT

1,1

0,N

COMMANDE

nom client

 

n° commande

adresse client

passant

passée

 

PASSATION

 

date commande

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", "male") ("féminin", "female")

("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.

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

Date (Entier jour, Entier mois, Entier année)

PERSONNE [Nom patronyme, Nom prénom, Date naissance]

HOMME [PERSONNE]

FEMME [PERSONNE, Nom jeune-fille] CONJOINT <Date mariage, HOMME mari, FEMME épouse>

-- le sous-type "hérite" de la définition de PERSONNE

Noms d'attributs

Ce point de vue suggère une méthode pour nommer les attributs. concaténation :

Le nom d'un attribut sera formé par la

• 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é ANNEE).

(ex.:

d) Identifiants

DATE)

est redéfini comme une relation entre sous-domaines

(JOUR, MOIS,

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.

d'expédition découlant de cette com- mande. FACTURE dat e de facture BORDEREAU n° de livraison date
FACTURE dat e de facture BORDEREAU n° de livraison date d'expédition
FACTURE
dat e de facture
BORDEREAU
n° de livraison
date d'expédition
FACTURATION 1,1 0,1 0,N LIVRAISON 1,1
FACTURATION
1,1
0,1
0,N
LIVRAISON
1,1
d'expédition FACTURATION 1,1 0,1 0,N LIVRAISON 1,1 COMMANDE n° commande dat e de commande C'est toujours
COMMANDE n° commande dat e de commande
COMMANDE
n° commande
dat e de commande

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 localité
BUREAU
REGIONAL
n° bureau
localité

AFFILIATION

date d'enregistr.

0,N 1,1
0,N
1,1
EMPLOYEUR n° inscription
EMPLOYEUR
n° inscription

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é.

composé 0,N PRODUIT COMPOSITION id produit quantit é prix unitaire composant 0,N
composé
0,N
PRODUIT
COMPOSITION
id produit
quantit é
prix unitaire
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
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 0,N 1,N CONTRAT n° police 0,N intermédiaire COURTIER
CLIENT
ASSURANCE
assuré
branche
0,N
1,N
CONTRAT
n° police
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.

1 La 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° matricule nom prénom (1) n° national
EMPLOYE
n° matricule
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, PROFESSEUR titulaire-de 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
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

réalisé

0,N

OCCUPATION

0,1

travaillant

OUVRIER

: CHANTIER réalisé 0,N OCCUPATION 0,1 travaillant OUVRIER CHANTIER réalisé 0,N 0,N OCCUPATION période travaillant

CHANTIER

réalisé

0,N

0,N

OCCUPATION

période

travaillant

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.

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

compositon

HOMME FEMME mariage mari épouse CONJOINT compositon relations identifiants On voit que, au total, le procédé

relations

FEMME mariage mari épouse CONJOINT compositon relations identifiants On voit que, au total, le procédé est
FEMME mariage mari épouse CONJOINT compositon relations identifiants On voit que, au total, le procédé est

identifiants

mari épouse CONJOINT compositon relations identifiants On voit que, au total, le procédé est uniforme :
mari épouse CONJOINT compositon relations identifiants On voit que, au total, le procédé est uniforme :

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 nom client PASSATION adresse client 0,N date commande 1,1 passée COMMANDE n° commande
CLIENT
passant
nom client
PASSATION
adresse client
0,N
date commande
1,1
passée
COMMANDE
n° commande
facturée
0,1
FACTURE
1,1
FACTURATION
n° facture
émise
date facture

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
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 1,1 1,1 0,N 0,N CONTRAT
AVENANT
1,1
MODIFICATION
0,N
1,1
1,1
0,N
0,N
CONTRAT

LOCATAIRE

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 :

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

identité du client, état débiteur ou créditeur, montant du solde, date du dernier mouvement

COMPTE

état solde date dernier mouvt

ouvrir( )

débiter( )

créditer( )

consulter( )

clôturer( )

CLIENT

nom

adresse

POSSESSION

titulaire

11

1 * *1

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 i