methodes d analyse

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

Upload: issiaka-dao

Post on 12-Aug-2015

111 views

Category:

Documents


10 download

TRANSCRIPT

Page 1: Methodes d Analyse

H.E.M.E.S. – Informatique

André CLARINVAL

Méthodes d’Analyse

édition : septembre 2002

Page 2: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-1

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 premierchapitre introduit brièvement les trois termes définissant ce contexte : système d'information, analyse, métho-dologie.

1. Systèmes d'information

1.1. Le concept d'information

L'information est représentée par des données, c'est-à-dire des formes écrites (textes, nombres ...), picturales(graphiques, dessins, photos, vidéos ...) et sonores. Ces données sont matérialisées sur des supports (papier,écrans, bandes magnétiques, disquettes, CD ...). A ces représentations, un être humain, une organisation ouune machine (ordinateur, robot ...) attache une signification susceptible d'entraîner une modification, immé-diate ou différée, de son comportement.

ex.: un automobiliste voyant les lettres STOP sur un panneau rouge octogonal [données] arrête savoiture [comportement]

ex.: un client ayant reçu une facture [données] prend son téléphone [comportement] pour donnerun 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 enretire certains produits et en introduit d'autres ...

On peut définir une information comme étant l'accroissement de connaissance découlant de l'interprétationd'un ensemble de données. Cette interprétation est le fait d'un acteur humain ou mécanique.

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

L'activité d'une entreprise ou d'une organisation humaine manipule de l'information : devis, commandes, fac-tures, ordres de paiement; fiches de paie, fiches fiscales; écritures comptables; plannings; etc. Cette infor-mation reflète les flux de matières (fabrications, achats, ventes ...), les flux financiers, les échanges de servi-ces ... qui forment la matière de l'activité de l'entreprise. Reçue par les acteurs de l'organisation, elle com-mande leur comportement. Echantillonnée et synthétisée, elle éclaire et supporte les décisions aux différentsniveaux de responsabilité dans l'organisation.

Si, d'après J. de ROSNAY1, "un système est un ensemble d'éléments en interaction dynamique, organisés enfonction d'un but", on peut, à la suite notamment des auteurs de la méthode MERISE2, distinguer au sein dusystè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.

Page 3: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-2

SYSTEME DEDECISION/PILOTAGE

SYSTEMED'INFORMATION

SYSTEME OPERANT

support

reflet

commande

Les fonctions d'un système d'information sont de conserver (mémoriser), créer (transformer) et communi-quer (diffuser) de l'information, plus précisément : des données que les acteurs interprètent.

De nos jours, les acteurs du traitement de l'information sont les hommes et les machines, et un système d'in-formation est partiellement automatisé; les opérations sont "programmées" sur des ordinateurs, "manuelles"(sic) ou "interactives" (c'est-à-dire mettant en communication immédiate les acteurs humains et mécani-ques) ... Nous appellerons applications informatiques — "applications de l'informatique" serait plus correct— les parties automatisées d'un système d'information.

1.3. Applications techniques et scientifiques de l'informatique

La figure ci-dessus, schématisant le rôle du système d'information dans une organisation humaine, est transpo-sable au monde de la technique.

De l'information circule entre les organes d'un appareillage (par exemple, les signaux électriques à l'intérieurd'un téléviseur) ou d'une machinerie complexe (une centrale électrique) qui, à la fois, en reflète l'état et encommande 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 dece 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 quel'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 deson 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 structuresphysiques sans avoir à les construire. La simulation n'est pas seulement moins chère, elle permetaussi 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 moinscher 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.

Page 4: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-3

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 dedé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 (= étudedes fonctionnalités, c'est-à-dire de l'utilité, du système à mettre en place) et analyse organique (= descriptiondes organes composant la solution).

• Habituellement, une étude préalable d'opportunité part d'une critique du système d'informationexistant, qu'elle décrit plus ou moins exhaustivement, avec plus ou moins de détail. Elle justifie unenouvelle solution, qu'elle recommande et à laquelle elle assigne des objectifs. L'étude d'opportunitédit le "pourquoi"; elle motive la décision de mettre un projet en chantier.

• L'analyse fonctionnelle détaille le "quoi" de la solution, pas encore le comment : "abstractionprécise du but de l'application et non de la façon dont elle sera bâtie".1 Elle décrit complètement lecontenu sémantique et logique du nouveau système à mettre en place, sans prendre en considérationles moyens à mettre en œuvre pour le faire fonctionner.

• "Comment ?" L'étape de conception définit la réalisation de ce système sous la forme de cons-tructions — programmes et procédures — utilisant au mieux les ressources techniques et organisa-tionnelles : logiciels, équipements, personnel, locaux, horaires, etc.

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

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

Ces questions correspondent à différents points de vue et concernent différents intervenants. Ellespeuvent être étudiées selon des techniques variées, mais doivent dans tous les cas être considéréespour 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 descriptionfonctionnelle 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.

Page 5: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-4

• 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 etdu 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 descontraintes 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 descompétences d'animation pour l'encadrement des équipes et sur des compétences d'organisationpour 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 senslarge) 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èrentd'une efficacité infaillible. Pour établir leurs prévisions, plus aléatoires, les météorologues se fondentsur 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 estné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 humainequi 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 dumaté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 unenotation précise, vérifier que les modèles satisfont aux spécifications du système, et progressivementajouter 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.

Page 6: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-5

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 unearchitecture; 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 lesconcepts, 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, COMMANDEassociations entre types d'objets : 1 CLIENT → n COMMANDEprédicats restrictifs (contraintes) : ∀ Qté commandée > 0équations (règles de calcul) : Qté livrée = MIN (Qté commandée, Qté en stock)méthodes abstraites : enregistrer une commande, établir une facture2

• Un schéma logique est la traduction d'un schéma conceptuel en termes de composants program-mables ou, plus largement, réalisables. Reflétant le plus directement qu'il se peut à la fois la spécifi-cation conceptuelle et l'état (la modernité) des ressources et techniques que l'on souhaite mettre enœuvre, il sert de référence pour les techniciens du système d'information.

Exemples de spécifications :

clés d'accès : référence du CLIENT dans l'enregistrement COMMANDEtables de codification : code Catégorie-Clientactions 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 desré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.

Page 7: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-6

Exemples de spécifications :

regroupements de données (fusion de types d'objets ...)cryptage des données sensiblesdédoublement des contrôles de validité dans une architecture décentraliséechoix des polices de caractères pour les affichages à l’écranvariantes 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 demettre en évidence le "souffle" qui doit inspirer l'analyste concepteur.

L'analyse [...]

L'analyse [au sens américain] remonte de la conséquence vers le principe : elle essaie de com-prendre, d'expliquer et de représenter la nature profonde du système qu'elle observe. L'analyse nese préoccupe pas de solutions mais de questions; elle identifie le quoi faire et l'environnement d'unsystè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 cahierdes 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 chargessont touffus, confus, contiennent des points contradictoires et ne reflètent pas les vrais besoins desutilisateurs. [...]

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 parla 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éesur des éléments concrets. Elle doit impérativement être poursuivie par une démarche d'abstractionqui vise à faire oublier les contingences du monde réel et à déterminer les concepts fondateurs quisont à 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 dechanger 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 pointd'être évidente.

Pour prendre une image, analyser c'est regarder un point, un cercle, une ellipse, une droite, deuxdroites sécantes, une hyperbole et une parabole et reconnaître que toutes ces formes peuvent êtreobtenues par l'intersection d'un plan et d'un cône. Dans ce cas, le principe générateur peut être ex-primé par une équation de la forme ax2 + by2 + 2cx + 2dy + e = 0. Cette représenta-tion est économe car elle décrit l'essentiel. L'analyse va à l'essentiel et recherche un modèle généri-que plus abstrait.

Page 8: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-7

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 descontraintes 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 estrare 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 secomplè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 obtenusdurant l'analyse. Il s'agit là d'une vision fortement réductrice qui ignore tout simplement que laconception est le temps de la mise en œuvre du savoir-faire. Ce savoir-faire peut être interne auprojet ou acquis à l'extérieur sous la forme d'outils, de composants réutilisables ou plus largementde 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 dudéveloppement de l'entreprise; c'est aussi chercher à s'assurer une avance technologique par deschoix 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 avecl'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 uneorganisation, 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".

Page 9: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-8

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 decomplexité des applications vers les environnements [de développement], grâce à une factorisationdes éléments et des mécanismes communs. C'est le cas dans les familles d'applications bien cibléesdans un domaine donné, comme les logiciels clients qui interagissent avec des serveurs de bases dedonné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 del'originalité. Toutes les applications finissent par se ressembler, ce qui est bien et mal à la fois. Letravers des outils RAD est d'encourager à faire vite et salement — quick and dirty — plutôt que viteet bien.

Curieusement, le RAD est un mélange de génie logiciel dans sa conception et d'horreur informatiquedans son utilisation. Ceci est la conséquence d'une vision à court terme des utilisateurs pour quiseul 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 construitde 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é deréutilisation, ouverture et solution clé en main, vision à court terme (la tactique) et vision à longterme (la stratégie). 3

3. Méthodologie de l'analyse

3.1. Contenu d'une méthodologie

Une méthode d'élaboration de logiciels décrit comment modéliser et construire des systèmes logi-ciels de manière fiable et reproductible.

De manière générale, les méthodes permettent de construire des modèles à partir d'éléments de mo-délisation qui constituent des concepts fondamentaux pour la représentation de systèmes ou de phé-nomènes. Les notes reportées sur les partitions sont des éléments de modélisation pour la musique.L'approche objet propose l'équivalent des notes — ce sont les objets — pour la représentation deslogiciels.

1 RAD — "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il préconisa, en1991 (é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 à voirensuite les équipes de développeurs accumuler les retards et dépasser toutes les prévisions budgétaires ... fixerle 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 faireexploser les budgets, restreindre s'il le faut les ambitions du projet ... Le temps ayant passé, on a oublié cetteproposition "révolutionnaire" pour ne retenir que la suggestion de choisir des outils performants.2 Les outils de développement rapide (ex.: WinDev, PowerBuilder, Delphi, C++ Builder, ViewAge et d'in-nombrables autres "studios" de "visual programming") jouissent actuellement d'une grande vogue, qu'expli-que le seul qualificatif "rapide". On en indique ici les limites et les pièges.3 P.A. MULLER : op. cit.

Page 10: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-9

Les méthodes définissent également une représentation, souvent graphique, qui permet d'une part demanipuler aisément les modèles, et d'autre part de communiquer et d'échanger l'information entreles 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éfinitdes règles de mise en œuvre qui décrivent l'articulation des différents points de vue, l'enchaînementdes actions, l'ordonnancement des tâches et la répartition des responsabilités. Ces règles définissentun processus qui assure l'harmonie au sein d'un ensemble d'éléments coopératifs et qui expliquecomment 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 (decomplétude, de cohérence, de transformation ...) unissant ces concepts. Concepts et lois qui per-mettent de décrire "intelligemment" une réalité. A titre subsidiaire, un modèle comporte des forma-lismes, qu'il ne faut pas croire limités aux seuls schémas graphiques ou diagrammes dont, à l'instar detout concepteur, les informaticiens sont friands.

• Une méthode propose des démarches et des règles de bon usage. Idéalement, elle se fonde surdes 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, enfranç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 surune 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.

Page 11: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-10

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 etde 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 intervenantsdu 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 duprocessus.

[...]

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

– 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 quipermet 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 pertinencede 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.

Page 12: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-11

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 leurshypothèses de travail.

Avant la construction proprement dite, les concepteurs élaborent de nombreux types de modèlespour des besoins divers; par exemple, des maquettes architecturales à l'intention du client, desprototypes d'avions pour les tests en soufflerie, des esquisses au crayon avant le tableau définitif, desplans techniques, des scénarimages publicitaires, des maquettes de livres, etc. Les modèles visentdifférents objectifs :

– tester une entité physique avant de la construire. Les maçons du Moyen Age ne connaissaientpas la physique moderne, mais ils construisaient des modèles à l'échelle des cathédrales gothiquesafin de tester les forces intervenant dans la structure. Les modèles réduits d'avions, de voitures oude 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 destructures physiques sans avoir à les construire. La simulation n'est pas seulement moins chère, ellepermet 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 comportementextérieur du système.

– visualiser. Les "scénarimages" de films, téléfilms et publicités permettent aux scénaristes de voirl'articulation de leurs idées. Les transitions brutales, les dénouements qui n'en finissent pas, et lespassages inutiles peuvent être modifiés avant l'écriture du script final. Les croquis permettent auxartistes de jeter leurs idées et de les modifier avant de passer à l'huile ou à la pierre.

– réduire la complexité. La principale raison, sans doute, de la modélisation, et qui englobe toutesles autres, est la possibilité qu'elle donne d'appréhender des systèmes qui seraient trop complexes àcomprendre directement. Le cerveau humain ne peut travailler qu'avec une somme limitée d'infor-mations à la fois. Les modèles réduisent la complexité dans la mesure où ils isolent un petit nombrede 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 etla 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éeset 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 descas, 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.

Page 13: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-12

En raison du peu de moyens disponibles, la différence entre un design soigné et un médiocre étaitquasiment inexistante. Les erreurs de présentation étaient certainement moins nombreuses et moinspé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 lafuture 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, uneconception inadéquate, et c'est l'échec. Il convient donc de se pencher avec attention sur le pro-blème posé par la relation avec l'utilisateur au travers de l'interface.

[...]

L'interface graphique, avec ses fenêtres multiples, ses objets hauts en relief et en couleur — icônes,images, barres d'outils, ascenseurs ... — offre des possibilités immenses pour les développeurs d'ap-plications. Mais les risques d'erreurs ont grandi d'autant : les variations possibles sont si nombreu-ses et si subtiles que l'on frôle constamment "l'explosion combinatoire" ! 1

3.4. Modélisation et Programmation

La plupart des paradigmes d'analyse — "Structured Analysis", modèle en réseau, modèle relationnel, con-ception orientée objet, etc. — sont des modèles initialement mis au point pour la programmation, dont on apar la suite élargi le champ d'application, de façon telle que leurs concepts puissent décrire d'autres réalitésque 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 deconception, 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 surdes 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écritla 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 del'ordinateur : l'affectation d'un contenu à une variable. Pour certains, ce paradoxe explique la difficulté de laprogrammation, son coût exorbitant ... et la lancinante recherche de nouvelles manières d'aborder — c'est-à-dire de penser et de modéliser — la programmation et, par extension, l'analyse.

3.5. L'équipe de développement

Pour terminer, évoquons les rôles qui doivent être remplis au sein d'une équipe attelée à la réalisation d'unprojet 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, ilarrive 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 performancecollective à partir des capacités moyennes de chacun.

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

Page 14: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-13

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 desfacteurs 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 leurrô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 quipermettront 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 deleurs 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, deformation 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.

Page 15: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-14

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 leurmise en œuvre. Dans ce but, nous nous attacherons à décrire différents modèles d'analyse, en nous attardantparticuliè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 — cesera 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 leursexamens de physique en apprennent par cœur des listes d'équations. Ils peuvent parfaitement réussirleurs 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 unethé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'unterritoire 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'ellesdonnent 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érienned'un territoire sert une fonction heuristique différente de celle de la carte démographique de cemê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, ellerepré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 donnentl'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. cit2 J. WEIZENBAUM : Puissance de l'ordinateur et raison de l'homme, trad. française; éd. d'Informatique,1981.3 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information; Masson, 1989.

Page 16: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-15

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, outilset démarches ne suffisent plus. Les méthodes "orientées objets" elles-mêmes n'ont pas soudain fleuri au milieud'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 onretrouve des traces — plus que des traces — dans les méthodes nouvelles. Ils sont constitués de quelquesmodè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ésentercette 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 lemontrer, 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 quelanalyste !) et le second, de manquer quelquefois de précision. C’est pour ces motifs que nous n’enexposerons 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.

Page 17: Methodes d Analyse

© A. CLARINVAL Analyse — Introduction 1-16

Page 18: Methodes d Analyse

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

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èmesde gestion de bases de données (SGBD).

La deuxième section définit quelques concepts fondamentaux, communs à tous les systèmes de modélisationdes données.

La troisième section dresse un panorama historique des principaux modèles de données et de leur utilisationpar les SGBD et les méthodes d'analyse.

Page 19: Methodes d Analyse

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

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 palliatifaux inconvénients des fichiers spécialisés que l'on définissait pour couvrir les besoins particuliers de chaqueprogramme.

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, parexemple. Défauts de ces systèmes : la redondance (répétition des mêmes informations), l'incohérence desmises à jour (les fichiers redondants n'étant mis à jour ni en même temps ni par les mêmes responsables), lepartage limité des informations (les divers utilisateurs potentiels ne retrouvant pas leur "point de vue" dans lamaniè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 oudu 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é à plusieursutilisateurs 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 : DataBase 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 informationdes 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 ...

Page 20: Methodes d Analyse

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

b) Vue conceptuelle

En vertu du principe de stockage intégré des données, il est nécessaire de concilier les différentes vues exter-nes en une seule vue conceptuelle.

Exemple.

Pour l'entreprise, la définition commune du concept de produit est la suivante : identification du pro-duit (numéro et dénomination), prix de vente unitaire, taux de TVA (en % du prix de vente), nu-méro de fournisseur, délai de réapprovisionnement (en jours), stock actuel ("quantité en stock" dansla terminologie des vendeurs), stock plancher, stock plafond.

c) Vue interne

Jusqu'ici, on n'a considéré que des notions, des concepts. Pour pouvoir réaliser une base de données effective,on doit encore s'en donner une vue interne qui intègre à la définition conceptuelle les aspects techniques dustockage 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 fournisseurquelconque, 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 externevue externe

vue externe

vue interne

vue conceptuelle

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é en1975-78.1

1 D. TSICHRITZIS, A. KLUG : The ANSI/X3/SPARC DBMS Framework in Information Systems, 1978.

Page 21: Methodes d Analyse

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

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) permettantde 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 ouphysique, (sous-)schémas externes. Le schéma interne aussi bien que les sous-schémas externes opérationnelssont des variations dérivées du schéma conceptuel; celui-ci joue le rôle de référence commune.

Page 22: Methodes d Analyse

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

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 estd'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'estpas. Selon le but recherché, il est possible de construire de nombreuses abstractions à partir d'unemême réalité.

Toute abstraction est incomplète et imprécise. La réalité est une toile sans couture. Tout ce qu'onpeut en dire, toute description qu'on peut en faire est un raccourci. Le langage, les mots humainssont forcément des abstractions, descriptions incomplètes du monde réel. Leur utilité n'est toutefoispas remise en question. Le but de l'abstraction est de limiter l'univers afin de pouvoir agir. Dans laconstruction de modèles, on ne recherche pas la vérité absolue, mais l'adéquation à un but donné. Iln'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 del'identifier". On définit de cette manière le type commun de tous les éléments de la classe.

Dans la littérature informatique, par un abus de langage qui complique quelquefois la compréhension des cho-ses, les deux termes classe et type sont employés l'un pour l'autre : une classe nommée ("CLIENT") et défi-nie ("toute personne ayant ...") est également appelée un type. Plus précisément, une classe est l'ensembleconcret de tous les éléments qui vérifient la définition d'un type, ensemble abstrait d'éléments "imaginables".Le type est une création pure de l'esprit, qui n'existe que par sa définition.

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

Exemples : type occurrencesETUDIANT Jean, Jacques, EmileNOMBRE ENTIER 1, 3, 37, 1236, 3217SEXE masculin, fémininCOMMANDE la-commande-reçue-aujourd'hui-du-client-XFICHIER DE COMMANDES fichier-des-commandes-reçues-ce-jour

Le type "FICHIER DE COMMANDES" est un type dont chaque occurrence (par exemple, le "fichier-des-commandes-reçues-ce-jour") constitue un sous-ensemble de la classe "COMMANDE", ce que nous appelle-rons une collection. Cet exemple illustre la manière de modéliser un ensemble : l'ensemble et l'élément fonttous deux l'objet d'une définition de type, chaque occurrence d'ensemble (ou collection) est un sous-ensembledu 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.

Page 23: Methodes d Analyse

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

occurrence

collection

classe

type

La définition d'un type est une définition d'ensemble, le plus souvent en compréhension ("toute personneayant ..."), 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, dansl'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 ouplusieurs, 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émininet 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 enOUVRIER 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èdetoutes les propriétés d'un membre du PERSONNEL ... plus certaines propriétés spécifiques; un CLIENT-PROFESSIONNEL possède toutes les propriétés d'un CLIENT, plus un numéro de TVA). Remarquons quetoute définition en compréhension ("CLIENT = [1] toute personne [2] ayant ...") relève de la spécialisation.

PierrePaul

JacquesAndré

OUVRIERS EMPLOYES

PERSONNEL CLIENTnom

adresse

PRIVE PROFESS.n°TVA

héritehérite

La généralisation est une abstraction globalisant (mettant "en évidence") dans un sur-type les propriétéscommunes de différents types (ex.: l'abstraction MOUVEMENT DE STOCK créée sur la base des typesENTREE EN STOCK et SORTIE DE STOCK, pour laquelle il faut créer artificiellement la propriété SIGNE-DU-MOUVEMENT).

Page 24: Methodes d Analyse

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

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é parle déterminant A : connaissant une occurrence de A, on peut retrouver l'occurrence de B correspondante.

Exemples : n° national → personnen° de TVA → firmen° 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 unecommande au plus; s'il est vrai qu'à une personne correspond un seul numéro national, cette relation n'est plusvraie 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 aspectdes 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 ayantpassé au moins un ordre de commande"; ne faudrait-il pas ajouter "depuis moins de deux ans" ?

Page 25: Methodes d Analyse

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

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" detemps; 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.) Lespositions 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 ouun document, comporte donc en principe :

– le nom d'un type (ex.: "le SOLDE DU COMPTE"),– une valeur d'identifiant (ex.: "de numéro 000-00000002-02"),– l'indication d'une période de validité (ex.: "au 01/09/2000").

Cependant, la dernière de ces indications (la date) est souvent omise, ce qui est possible lorsque, dans la col-lection visée, on ne distingue pas différentes périodes de validité (on tient pour actuelles toutes les informa-tions détenues).

c) Période de mémorisation, Durée de rétention

Quelle que soit la période de validité d'une information, celle-ci est connue et "enregistrée" à un certain mo-ment, et conservée en mémoire un certain temps. On parle à ce propos de période de mémorisation et deduré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, quecelle-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.

Page 26: Methodes d Analyse

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

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 disjointset 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, uneFACTURE est successivement "émise", "rappelée", "payée" ou "annulée". La transition d'un état à un autreré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, etpar 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 sadernière mise à jour, ainsi que par les opérations de mise à jour et de consultation de cet état. Troisclasses d'états remarquables sont intéressantes à distinguer : solde positif, nul ou négatif.

Page 27: Methodes d Analyse

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

3. Panorama historique

3.1. Les SGBD opérationnels

Nous avons défini un modèle comme étant la théorie et le formalisme employés pour créer un schéma de don-nées. Les SGBD se différencient principalement par le modèle théorique sur lequel ils s'appuient.

On le notera rien qu'à leurs noms : tous les modèles s'intéressent principalement aux relations exis-tant entre les données ... mais, comme diraient les musiciens, chacun joue sur ce thème sa propre va-riation.

Les SGBD relationnels, mis au point dans les années 80, sont les plus utilisés aujourd'hui. Ils s'appuient surle 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é parCODASYL à partir de 1971.3 Ces systèmes sont encore utilisés sur certains gros ordinateurs, mais on les asouvent recouverts d'une "couche" de fonctions d'accès relationnelles.

Cas particulier : le système IMS (Information Management System) d'IBM, créé en 1968, reposesur 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 dece modèle a été adoptée en France par la méthode d'analyse MERISE.5 Parce que le gouvernement françaisobligeait 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 parJ. 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.

Page 28: Methodes d Analyse

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

Le modèle des réseaux sémantiques proposé par SMITH et SMITH en 1977 constitue un des fondementsthéoriques des modèles orientés objets.1 Ses apports ont été intégrés à une deuxième génération du modèlerelationnel et à une deuxième génération des modèles entité–association.

A la suite de la programmation, les méthodes d'analyse se veulent aujourd'hui "orientées objets". En 1997,l’Object Management Group (OMG) a adopté comme standard l’Unified Modeling Language (UML).2 Leschéma central produit par une analyse axée sur les objets est le diagramme des classes d'objets; il s'agit niplus ni moins que d'un schéma de données, muni d'opérations. Le formalisme proposé par UML est celui d'unschéma Entité–Association.3

b) Outils d'aide à la conception

Depuis la fin des années 80 se sont répandus des outils logiciels d'aide à la conception (CASE tools — Com-puter Aided Software Engineering).

Actuellement, l'efficacité de ces outils est beaucoup plus grande dans l'analyse des données que dans l'analysedes opérations. S'appuyant sur l'un ou l'autre modèles de données, ces outils gèrent la documentation écrite etgraphique 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 êtreconvertis 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é–Associationenrichi 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 dansles 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 ysont 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 pionniersdes méthodes d’analyse et conception "orientées objets" : les Américains G. BOOCH et J. RUMBAUGH et leSué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.

Page 29: Methodes d Analyse

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

Page 30: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-1

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 leschéma conceptuel de cette base de données. A cette étape, l'analyste ne s'intéresse qu'à la sémantique desdonné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 desutilisateurs commanditaires du projet d'informatisation. Ces utilisateurs apportent à l'œuvre commune leurconnaissance 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 listede 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 devalidité, 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.)

Page 31: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-2

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'associationentre 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 ayantcréé 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 parlentde classes d'objets. Le concept d'objet complète celui d'entité : un objet est caractérisé, non seulement pardes 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 etAnnie sont des objets concrets, "jupe écossaise" est une entité abstraite qui décrit les propriétéscommunes à 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 classesd'objets

On représente habituellement par un rectangle un type d'entités ou une classe d'objets.

Exemples. VENDEUR CLIENTPRODUIT

Les types d'entités ne forment pas nécessairement des classes disjointes; une même personne pourrait êtrevendeuse 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ésou sous-classes d'objets.

1 La méthode MERISE parle d'individu, de relation et de propriété.2 Voir les références bibliographiques au chapitre 2. Pour l'exposé qui suit, nous nous baserons principale-ment sur l'ouvrage de F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information : mé-thode, modèles, outils, Masson, 1989.3 Voir les références bibliographiques au chapitre 2.

Page 32: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-3

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 CLIENTPRODUIT

PRODUITFABRIQUE

PRODUITDISTRIBUE

CLIENTPRIVE

CLIENTPROFESS.

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

Exemple.

CLIENT

CLIENTNATIONAL

CLIENTETRANGER

CLIENTPRIVE

CLIENTPROFESS.

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.

MATERIELDIDACTIQUE

CD-ROMLIVRE

LIVRED'ART

MANUELSCOLAIRE

CD-ROMEDUCATIF

JEUVIDEO..... .....

Page 33: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-4

b) Association

Le concept d'Association

Une association ("relationship", en anglais) est une correspondance reconnue entre des entités, de types nonnécessairement distincts, où chacune assume un rôle particulier. Son existence est contingente à celle desentités concernées; sa période d'existence est incluse dans l'intersection des périodes d'existence des entitésparticipantes 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.

PERSONNE

HOMME FEMMECONJOINT

FILIATIONparent

enfant

mari épouse

Page 34: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-5

PRODUIT

MAGASIN PRODUITFABRIQUE

PRODUITDISTRIBUE

FOURNISSEUR

FOURNITURE

STOCK

COMPOSITION composé

composant livrant

livré

contenant

entreposé

MATIERE

PROFESSEUR CLASSE

ENSEIGNEMENT

dispensée

titulaire suivant

Remarques

Le nom (d'un type) d'association doit être un substantif qui peut être "lu" dans tous les sens, comme ci-dessus dans notre exemple des PRODUITs : [FOURNISSEUR] → (FOURNITURE) → [PRODUIT-DISTRIBUE] ou [PRODUIT-DISTRIBUE] → (FOURNITURE) → [FOURNISSEUR], [PRODUIT] →(STOCK) → [MAGASIN] ou [MAGASIN] → (STOCK) → [PRODUIT] ... Contrairement aux recomman-dations de certains auteurs, on évitera de nommer un type d'association par un verbe, car un verbe se lit tou-jours dans un seul sens : sujet → verbe → complément.

Dans le cas des associations cycliques, c'est-à-dire définies sur un seul type d'entité (l'association FILIATIONentre PERSONNEs, l'association de COMPOSITION entre PRODUITs), les noms de rôles sont nécessairespour pouvoir distinguer les occurrences participantes : dans telle occurrence de l'association COMPOSITIONde PRODUITs, "vitrage" et "châssis" sont les composants du composé "fenêtre"; dans telle occurrence del'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 loinl'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 plupartbinaires (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)

Page 35: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-6

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

PERSONNE

HOMME FEMME

parent

enfant

mari épouse

FILIATION

CONJOINT

PRODUIT

MAGASINPRODUIT

FABRIQUEPRODUIT

DISTRIBUE

FOURNISSEUR

composé

composantlivrant

livrécontenant

entreposé

FOURNITURESTOCK

COMPOSITION

MATIERE

PROFESSEUR CLASSE

dispensée

titulaire suivant

ENSEIGNEMENT

Connectivité des associations

Soit un type d'association A (Ei ri, ...).

– A chaque association du type A participe sous chacun des rôles ri une entité exactement.– A chacun des rôles ri mis en jeu est attaché un couple d'entiers (mini, maxi), qui en définissent laconnectivité (on dit aussi : la cardinalité) et qui, dans les méthodes de tradition française, signi-fient :

– mini le nombre minimum d'occurrences de A auxquelles,à tout moment, participe toute occurrence de Ei;

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

Page 36: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-7

Les valeurs habituelles sont :

– mini = 0 ou 1 signifiant une participation facultative ou obligatoire,– maxi = 1 ou N ou * signifiant une participation unique ou multiple

(N ou * représente l'infini).

Exemples : CONJOINT (HOMME mari-de 0:1, FEMME épouse-de 0:1)– il existe des célibataires !FILIATION (PERSONNE enfant-de 0:2, PERSONNE parent-de 0:N)– le nombre d'enfants d'une personne est quelconque (de 0 à N)– chaque personne est enfant de deux parents mais certains parents sont inconnus

PERSONNE

HOMME FEMMECONJOINT

FILIATIONparent

enfant

0,N

0,2

mari épouse0,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 FACTUREFACTURATIONfacturée émise

0,1 1,1

FOURNITURE (PRODUIT-DISTRIBUE livré-par 1:1, FOURNISSEUR livrant 1:N)– tout fournisseur d'un type de produit est un fournisseur exclusifSTOCK (PRODUIT entreposé-dans 0:1, MAGASIN contenant 0:N)– certains produits ne sont pas stockés– aucun produit n'est stocké dans plusieurs magasinsCOMPOSITION (PRODUIT composé-de 0:N, PRODUIT composant 0:N)– il existe nécessairement des produits non composites– certains produits n'entrent dans aucune composition

PRODUIT

MAGASINPRODUIT

FABRIQUEPRODUIT

DISTRIBUE

FOURNISSEUR

FOURNITURESTOCK

COMPOSITION composé

composant livrant

livrécontenant

entreposé

0,N

0,N

1,N

1,1

0,1

0,N

Page 37: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-8

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

PROFESSEUR CLASSE

ENSEIGNEMENT

dispensée

titulaire suivant

1,1

1,N 1,N

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. Laconnectivité (ou "multiplicité") mentionnée à chaque extrémité de l'arc représentant une association binaireindique à combien d'entités de cette extrémité est associée chaque entité du type situé à l'autre extrémité, cequi revient à dire : à combien d'associations participe chaque entité du type situé à l'extrémité opposée.1

Voici l'équivalent UML des exemples donnés au paragraphe précédent. Comparez attentivement les deuxversions.

PERSONNE

HOMME FEMME

parent

enfant

mari épouse

FILIATION

CONJOINT

0..2

0..*

0..1 0..1

COMMANDE FACTUREfacturée émise

0..11..1 FACTURATION

PRODUIT

MAGASIN PRODUITFABRIQUE

PRODUITDISTRIBUE

FOURNISSEUR

composé

composantlivrant

livrécontenant

entreposé FOURNITURESTOCK

COMPOSITION

1..1

1..*

0..*

0..1

0..*

0..*

1 Cette disposition, typique des méthodes américaines, provient du modèle en réseau, que nous décrirons auchapitre suivant.

Page 38: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-9

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 typed'association sous les traits d'un type d'entité !1

MATIERE

PROFESSEUR CLASSE

dispensée

titulaire suivant

1..1

1..* 1..*

<<association>>ENSEIGNEMENT

Ce mode de représentation est également applicable aux associations binaires.Remarquer que les connectivités se placent ici de la même manièreque dans la représentation française.La mention «association» signale une variante standardisée du concept d’analyse employé,ce que, en UML, on appelle un stéréotype.

NOTE. En UML, la connectivité 1..1 peut être laissée implicite; elle peut aussi s'écrire 1.

c) Attribut

Attribut et Domaine

Un attribut est une caractéristique descriptive d'une entité ou d'une association, qui prend une valeur dans undomaine, c'est-à-dire un ensemble de valeurs admises. L'analyste, comme toujours, généralise et définit destypes d'attributs.

Exemples : type d'entité/association attribut domaine exemples de valeurs EMPLOYE nom-employé NOM Fantasio, Lagaffe

adresse-employé ADRESSE château-de-Champignacphoto-employé image N&B

CLIENT nom-client NOM Dupont, Dupondadresse-client ADRESSE château de et à Moulinsart

PRODUIT nom-produit LIBELLE chaussettes, jupe, drapsprix-de-vente PRIX 89, 879, 2299quantité-en-stock QUANTITE 433 lots,2500 pièces,1000 paires

COMMANDE qté-commandée QUANTITE 1 lot, 1 pièce, 3 pairesdate-d'émission DATE 20 avril 1995date-de-livraison DATE 30 avril 1995

CONJOINT date-de-mariage DATE 04/10/40, 03/05/57, 19/03/62 1 Il existe encore en UML d'autres éléments, par exemple le langage OCL ("Object Constraint Language"),qui ne s’adaptent pas aux associations de degré supérieur à 2. C’est sans doute pour ces raisons que les outilsd'aide à la conception qui se fondent sur la notation UML n'acceptent, en pratique, que les associations binai-res.

Page 39: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-10

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/AssPERSONNEnomdat e naissance

HOMME FEMMEnom de jeune fille

CONJOINTdat e m ariage

mari épouse

0,10,1

UML

PERSONNEnomdat e naissance

HOMME FEMMEnom de jeune fillemari épouse

0..10..1

CONJOINTdat e m ariage

REMARQUE. Dans le cas d'une entité participant à une association avec une connectivité 1:1, on peut hésiterà attacher certains attributs soit au type d'entité, soit au type d'association.

Exemple : PASSATION (CLIENT passant 0:N, COMMANDE passée-par 1:1)– la date-de-commande peut être attribut de COMMANDE ou de PASSATION

Ent/Ass

COMMANDEn° com m ande

CLIENTnom clien tadresse clien t

PASSATIONdat e com m ande

passant

passée0,N1,1

UML

COMMANDEn° com m ande

CLIENTnom clien tadresse clien t passant passée

0,N1,1

PASSATIONdat e com m ande

En mathématique, une relation est une partie du produit cartésien de plusieurs domaines. Exemple :

domaine 1 domaine 2 produit cartésien relation"masculin" "male" ("masculin", "male") ("masculin", "male")"féminin" "female" ("masculin", "female") ("féminin", "female")

("féminin", "male")("féminin", "female")

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

Page 40: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-11

Entité

Assoc.

PERSONNE

FEMMEHOMME

CONJOINT

Domaine

nomdate

naissance

mariage

de jeune fille

mari épouse

patronyme

entier

jourmois

année

prénom

Date (Entier jour, Entier mois, Entier année)PERSONNE [Nom patronyme, Nom prénom, Date naissance]HOMME [PERSONNE] -- le sous-type "hérite" de la définition de PERSONNEFEMME [PERSONNE, Nom jeune-fille]CONJOINT <Date mariage, HOMME mari, FEMME épouse>

Noms d'attributs

Ce point de vue suggère une méthode pour nommer les attributs. Le nom d'un attribut sera formé par laconcaténation :

• soit du nom de domaine et du nom du type d'objet décrit, entité ou association (ex.: nom-client, nom-produit, numéro-de-commande); le nom de domaine peut souvent être abrégé (ex.: "no" pour "numéro", "lib"pour "libellé", "qté" pour "quantité", etc);

• soit du nom de domaine et d'un qualificatif de rôle (ex.: prix-de-vente, quantité-en-stock, date-de-mariage);la présence d'un qualificatif de rôle est indispensable dans le cas où plusieurs attributs d'un même type d'objetpartagent 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).

Page 41: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-12

Un attribut peut être simple (ex.: EMPLOYE : nom) ou répétitif (ex.: EMPLOYE : prénoms) — certainsauteurs 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é purementnational 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 partagenttoutes les propriétés de celui-ci. Par généralisation, on pourra cependant inclure une valeur "inexistant" dansle domaine d'un attribut que l'on désire rendre facultatif; grâce à cet artifice, il est possible d'attacher la notionde nom-de-jeune-fille à toute personne plutôt que de distinguer le sous-type des FEMMES-MARIEES. Dansle 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 queproposent 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 valeurQUANTITE nombre entierPRIX nombre décimal — en COBOL : PICTURE 9(4)V99NOM CHAR(20) — en COBOL : PICTURE X(20)

Un domaine structuré (ex.: DATE) est redéfini comme une relation entre sous-domaines (JOUR, MOIS,ANNEE).

d) Identifiants

Le concept général d'identifiant a été introduit au chapitre 2, en même temps que celui de dépendance fonc-tionnelle. Quelle forme prend un identifiant dans le modèle Entité–Association ?

Identifiant d'un type d'entité

L'identifiant d'une entité est le plus souvent formé d'attributs propres à cette entité. Dans les exemples ci-dessous, le nom des attributs identifiants est souligné.

Exemples : EMPLOYE [n° matricule, nom, adresse]PRODUIT [n° code, nom produit, prix de vente]CLASSE [section, année, nombre d'étudiants]

1 On parle de plus en plus aujourd'hui de bases de données généralisées, où les attributs peuvent prendre laforme 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.

Page 42: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-13

Si un type d'entité E participe nécessairement à une association, c'est-à-dire avec une connectivité minimale de1 (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 Edans 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'uniqueFACTURE et faire partie de l'identifiant des BORDEREAUx d'expédition découlant de cette com-mande.

FACTUREdat e de fact ure

COMMANDEn° com m andedat e de com m ande BORDEREAU

n° de liv raisondat e d'expédit ion

FACTURATION

LIVRAISON

0,1

0,N

1,1

1,1

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

BUREAUREGIONALn° bureaulocalit é........

EMPLOYEURn° inscrip t ion........

AFFILIATIONdat e d'en regist r.

0,N 1,1

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 ensoulignant le nom des rôles des types d'entités associés dont l'identifiant est utilisé.

PRODUITid p roduitp rix unit aire

COMPOSITIONquan t it é

composé

composant 0,N

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.

Page 43: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-14

MATIERE

PROFESSEUR CLASSE

ENSEIGNEMENT

dispensée

titulaire suivant

1,N

1,N 1,N

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 encréant pour l'association un attribut identifiant.

Exemple. Un même CLIENT assuré peut, par le truchement du même COURTIER, obtenir plusieurscontrats dans une même branche d'ASSURANCE (notamment, une assurance incendie pour chacunde ses immeubles bâtis); un "numéro de police" est nécessaire à l'identification complète du CON-TRAT.

CLIENT

COURTIER

ASSURANCE

CONTRATn° po lice

assuré branche

intermédiaire

1,N 0,N

0,N

Identifiants multiples

Plusieurs identifiants peuvent exister pour le même type d'objet. Exemples : le travailleur EMPLOYE par uneentreprise peut être identifié par son numéro au Registre National et par un numéro de matricule interne; siune 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 typed'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 êtresouligné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 stockagedes données, qui se donneront pour objectif d'accélérer l'accès sélectif par le biais de cet identifiant privilégié.

Page 44: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-15

EMPLOYEn° matriculenomprénom(1) n° nat ional

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 pourracependant, comme nous l'avons fait jusqu'ici, représenter l'identifiant primaire en soulignant le nom des rôlesfournissant 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 cetidentifiant qui soit lui-même identifiant; en d'autres termes, aucun des composants d'un identifiant ne doitdépendre fonctionnellement des autres.

Supposons que l'identifiant d'un EMPLOYE soit composé de son numéro de matricule (unique dansl'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) → professeurENSEIGNEMENT (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 del'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 peutsubir pendant sa durée de vie.

C'est en particulier pour répondre à des situations où un identifiant "naturel" n'apparaît pas stable, notammentlorsque la valeur peut en être inconnue, qu'on utilise parfois des identifiants internes de substitution, attribuéspar 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.

Page 45: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-16

e) Dimension historique

L'insertion de la dimension historique dans le modèle Entité–Association s'opère en incluant l'indication despériodes de validité dans l'identifiant des entités ou associations.1

TARIFpérioden° produitprix 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

OUVRIER

réalisé

travaillant

0,N

0,N

CHANTIER

OUVRIER

OCCUPATION

réalisé

travaillant

0,N

0,1

OCCUPATIONpériode

REMARQUES. L'identifiant minimal d'un élément (entité ou association) historique est le même que celuide cet élément s'il ne possédait pas la dimension historique, augmenté de l'indication de période. L'insertionde la dimension historique au sein d'un type d'association transforme les éventuelles connectivités ?:1 enconnectivité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'uneFACTURE), 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 unmê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 dedébut et d'une date ou heure de fin. La fin d'une période de validité est le plus souvent inconnue tantque 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 desdifférentes périodes de validité est une mention redondante, dont on pourra faire l'économie pourvuque 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 devientidentifiante de l'entité ou de l'association mémorisée.

Page 46: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-17

4) La recherche d'une occurrence mémorisée portera d'ordinaire sur l'occurrence "valide à telledate", 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.

Entité

Assoc.

PERSONNE

FEMMEHOMME

CONJOINT

Domaine

nom

date

naissance

mariage

de jeune fille

mari épouse

patronyme

entier

jourmois

année

prénom

compositon

relations

identifiants

On voit que, au total, le procédé est uniforme : la modélisation des données se réduit à la composition derelations. 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 desentités; de ce fait, comme l'association FACTURATION ci-dessous, elle peut ne pas avoir d’attributs.

Page 47: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-18

COMMANDEn° com m ande

CLIENTnom clien tadresse clien t

FACTUREn° fact uredat e fact ure

FACTURATION

PASSATIONdat e com m ande

passant

passée

facturée

émise

0,N 1,1

0,11,1

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" lesdomaines de valeurs. Les frontières entre les concepts d'entité associée et valeur caractéristique ne sontdonc 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 detous les types d'associations auxquels il participe est équivalente à un type d'association. Si tous les rôlesjoués dans un type d'association ont la connectivité 1:1, la composition de ce type d'association avec tous lestypes d'entités participants est équivalente à un type d'entité.

1,11,11,11,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 leconcept d'avenant à un contrat. D'une part, cet avenant est présenté comme une association de degré 1, pourlaquelle 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 pasassumer 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èchepartant de l'association vers le membre.

Page 48: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-19

Solution : toute association non représentable, association référencée (ex.: CONTRAT) ou associationincomplè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

MODIFICATION

LOCATAIRE PROPRIETAIRECONTRAT

1,1

1,11,10,N

0,N

0,N

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 doncune 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 naturedes 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 lestransformations évoquées ici, les pseudo-associations sans attributs ayant une connectivité 1:1.

Page 49: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-20

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 lesassociations auxquelles il participe; elle ajoute les opérations que cet objet peut effectuer, essentiellementpour modifier ou faire connaître son propre état. Tout objet est en effet responsable de son propre état.

Exemple. Un COMPTE CLIENT est un objet. Il est caractérisé par des attributs et des associations :identité du client, état débiteur ou créditeur, montant du solde, date du dernier mouvement ... Lesopérations possibles sont : ouvrir le compte, le débiter du montant d'une facture, le créditer du mon-tant d'un paiement ou d'une note de crédit, consulter l'état du compte, clôturer le compte ...

COMPTEétatsoldedate dernier mouvt

ouvrir( )débiter( )créditer( )consulter( )clôturer( )

CLIENT

nomadresse 1 1..*1 1..*

titulairePOSSESSION

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’étuded’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'unobjet sont privées ou cachées (elles ne sont accessibles qu'aux opérations de l'objet), tandis que les opérationssont publiques, c'est-à-dire utilisables par n'importe quel objet ou programme. On donne à ce procédé le nomde 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 œuvreque les méthodes d’analyse anciennes, MERISE par exemple, décrétaient que les opérations ne possèdent pasle caractère quasi immuable des choses "conceptuelles", mais sont "contingentes" et sujettes à d’assez fré-quentes révisions.2 B. LISKOV, J. GUTTAG : Abstraction and Specification in Program Development; M.I.T. Press, 1988.

Page 50: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-21

Exemple. Les utilisateurs d'un objet COMPTE CLIENT ignorent si l'identité du client est enregistréesous la forme d'un attribut ou d'une association, si le montant du solde est effectivement enregistrédans la base de données ou s'il est recalculé chaque fois que c’est nécessaire ...

Dans un type de données abstraites, le concept d’attribut est redéfini de la façon suivante : un coupled’opérations set et get transmettant une valeur. L’utilisateur ignore si l’attribut est enregistré tel quel ouvirtuel, c’est-à-dire calculé à chaque accès.

Les opérations mentionnées dans la définition d’un type abstrait se répartissent en trois catégories :

– créateurs ou constructeurs d’occurrences,– modificateurs de l’état d’une occurrence,– observateurs ou rapporteurs renseignant sur l’état des occurrences.

Les opérations set et get de mise à jour et consultation d’un attribut constituent un cas particulierdes deux dernières catégories.

Données privées, opérations publiques ... A dire vrai, seule est publique la signature des opérations, c'est-à-dire la forme du message qui les invoque (nom de l’opération, description des paramètres et du résultat). Laréalisation interne des opérations (en anglais : "implementation"), c'est-à-dire la méthode utilisée, demeurecachée, tout comme les données.1 L'ensemble des signatures publiques d'un objet compose ce qu'on appelleson interface.

b) Spécification des opérations

Au même titre qu’un attribut, une opération caractéristique d’un type d’objet doit être définie.

Spécification externe

La spécification externe d’une opération n’est rien d’autre que ce qu’on appelle dans les langages de pro-grammation la signature du sous-programme qui la mettra en œuvre.

Cette signature comporte les éléments suivants :

– le mode opératoire du sous-programme : fonction ou procédure

. une fonction rend en résultat un objet ou une valeur, elle ne modifie pas ses paramètres

. une procédure peut modifier les paramètres qu’elle reçoit, elle ne rend pas de résultat

dans les langages de la famille C,la signature d’une procédure est celle d’une fonction rendant un résultat de type "void"

– un nom évocateur, identifiant l’opération

Idéalement, le nom attribué à une fonction est un substantif ou un qualificatif exprimant la relationsémantique qui permet de définir le résultat au moyen des paramètres et de l’état de l’objet.

Exemples : compte. créditeur () => vrai / faux

1 Par un abus de langage, on emploie souvent le mot méthode pour désigner l’opération qui utilise la méthode.

Page 51: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-22

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

Exemples : compte. débiter (montant) clôturer ()client. modifier_adresse (adresse)

– une liste de paramètres, qui peut être vide

pour chaque paramètre :

. un nom, qui permet d’y faire référence;

. son type ou sa classe;

. le mode d’utilisation de ce paramètre par le sous-programme :

in le sous-programme utilise les valeurs reçues mais ne les modifie pasout le sous-programme range des valeurs dans le paramètreinout le sous-programme utilise les valeurs reçues et les modifie

– si le sous-programme est une fonction ou un opérateur : le type ou la classe de son résultat

– la liste des signaux d’exception émis par l’opération en cas d’échec

pour chaque exception :

. son type

. les éventuelles données d’information contenues dans le signal

. en commentaire : les valeurs significatives

Définition sémantique

La spécification externe d’une opération devra être complétée par la liste des pré-conditions et post-conditions, plus éventuellement la méthode (c’est-à-dire l’algorithme), qui définissent la sémantique decette opération.1

c) Aperçu sur le langage IDL

L’analyste peut adopter les formes du futur langage de programmation, par exemple C++ ou JAVA, si celui-ciest déterminé à l’avance. Mais il serait sans doute préférable de recourir à un langage comme IDL, l’InterfaceDefinition Language faisant partie de la norme CORBA ("Common Object Request Broker Architecture")établie par l’Object Management Group (OMG).2 Ce langage a précisément été défini dans le but de permet-tre des spécifications indépendantes d’un environnement particulier.

Le langage de spécification IDL est basé sur le langage de programmation C++, ce qui le rend d’emblée com-préhensible à une grande partie des informaticiens ...

1 Cf. infra, § 3.6.2 OMG : CORBA / IIOP Specification, vers. 3.0; www.omg.org, 2002. Voir aussi : JM. GEIB, Ch. GRAN-SART, Ph. MERLE : CORBA, des concepts à la pratique; 2e éd., Dunod, 1999 (cet ouvrage est téléchargea-ble sur le site corbaweb.lifl.fr/CORBA_des_concepts_a_la_pratique/).

Page 52: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-23

Un module IDL regroupe des définitions que l’analyste considère comme solidaires.1 Tout nom peutêtre préfixé par le nom du module où il est défini suivi, comme en C++, de l’opérateur ::.

Pour l’essentiel, un module contient la définition de l’interface des différents types d’objets, c’est-à-dire la spécification de leurs attributs et opérations. Le(s) super-type(s) dont hérite un sous-typed’objets est/sont listé(s) à la suite du nom du sous-type, comme en C++ (pour l’illustrer dansl’exemple ci-dessous, nous définirons le type d’association possession de comptes comme un sous-type du stéréotype Association_1_N).

D’autres définitions sont possibles : types de données analogues aux types de données construits dulangage C, types (structurés) des signaux d’exception, constantes, etc. Dans l’exemple ci-dessous,ces définitions auxiliaires font partie de la définition de l’interface qui les utilise; on aurait pu lesplacer en-dehors de la définition des interfaces.

Exemples

COMPTEétatsoldedate dernier mouvt

ouvrir( )débiter( )créditer( )consulter( )clôturer( )

CLIENTnomadresse 1 1..*1 1..*

titulairePOSSESSION

module méta // méta-définitions (stéréotypes du modèle Ent-Ass){ interface ASSOC_1_1 { }; interface ASSOC_1_N { }; interface ASSOC_M_N { };};

module commun // définitions communes à toutes les applications{ typedef string Nom; struct Date { short AA, MM, JJ; }; struct Adr_Postale { string rue_et_num, code_postal, localité; };};

module Clients{ interface Client { attribute commun::Nom nom; attribute commun::Adr_Postale adresse; // pas d’opérations définies actuellement };

1 En IDL, l’unité compilable est le module.

Page 53: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-24

interface Compte { enum Etat_Compte { débiteur, soldé, créditeur }; attribute Etat_Compte état; attribute float solde; attribute commun::Date date_dernier_mouvt; exception Client_Inexistant { string nom_client; }; void ouvrir (in Client titulaire) raises (Client_Inexistant); void débiter (in montant); void créditer (in montant); structure Relevé { string nom_client; float solde; commun::Date date_dernier_mouvt; }; Relevé consulter (); void clôturer (); };

interface Possession : méta::ASSOC_1_N { attribute Client titulaire; attribute sequence<Compte> possédé; };};

2.2. Modélisation des relations d’abstraction

D'après la définition originelle du modèle Entité–Association, une association unit des objets ou concepts,appelés entités, dont l'existence est autonome (ex.: les entités HOMME et FEMME dans l'association CON-JOINT).

Certains auteurs1 ont mis l'accent sur d'autres relations, dites d'abstraction, qui apparaissent comme des rela-tions de globalisation sur des ensembles d'occurrences. Ces relations sont l'agrégation, la classification et lagénéralisation.2

Les méthodologies et systèmes orientés objets accordent une importance primordiale à ces relations et les re-présentent par des symboles particuliers.

a) Agrégation / Contenance

L'agrégation (ou son inverse : la contenance) est la relation par laquelle une collection d'objets composantsconstitue par elle-même un objet agrégat caractérisé par des attributs et/ou des associations distincts de ceuxdes composants; l'existence d'une occurrence de l'agrégat implique l'existence d'au moins une occurrence decomposant. Comme l'association, l'agrégation est une relation entre des occurrences.

1 Voir notamment J. SMITH, D. SMITH : op. cit. Les modèles basés sur cette approche sont connus sous lenom de modèles des réseaux sémantiques.2 Nous avons montré au chapitre 2, § 2.1 comment les deux dernières fondent les techniques de modélisation.Le mécanisme d’agrégation/désagrégation est tout aussi fondamental dans une démarche d’analyse.

Page 54: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-25

Dans la notation UML, un petit losange signale le type agrégat.

Dans un schéma Entité–Association, l'agrégat est présenté comme une entité, tandis que les composants peu-vent être des entités ou des associations.

L'idée d'équipe sur un chantier, qui permet de mettre en évidence le rôle de chef d'équipe, est plusporteuse d'information qu'une simple association d'OCCUPATION (OUVRIER, CHANTIER). Enoutre, l'entrepreneur peut affecter à une équipe un véhicule de société adapté à ses besoins ... (Noterque, dans les schémas ci-dessous, un ouvrier peut être membre et même chef de plusieurs équipes.)

UML

CHANTIER

VEHICULE

OUVRIER

EQUIPE0..* 0..*

1..*

0..*

1..1

0..*

chef membre

OCCUPATION

COMPOSITION

1..*

AFFECTATION

DIRECTION

0..*

Ent/Ass

CHANTIER

VEHICULE

OUVRIER

EQUIPEOCCUPATION

COMPOSITION

AFFECTATION

DIRECTION

0,N 0,N

1,N

0,N

1,N

0,N

1,1

0,Nchef membre

En UML, on distingue deux niveaux d’agrégation :

– l'agrégation "partagée" ou "faible", dans laquelle une même occurrence de composant peut faire simulta-nément partie de plusieurs agrégats (c'est le cas de l'exemple ci-dessus : un ouvrier peut faire partie de diffé-rentes équipes)

l'agrégation partagée est symbolisée par un losange vide

– la composition ou agrégation "forte", dans laquelle une occurrence de composant n'existe qu'au sein d'ununique composé (si le composé cesse d'exister, le composant cesse également d'exister)

la composition est symbolisée par un losange plein

PROJETPHASEn° o rdredat e débutduréedescript ion

objetresponsablebudget 1..1 1..*

PLANNING

Page 55: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-26

b) Classification / Instanciation

La classification (ou son inverse : l'"instanciation"1) est l'abstraction par laquelle une définition commune(la classe, la catégorie ou le type) s'applique à un ensemble de phénomènes (ou occurrences). Il n'est pasexceptionnel de devoir inclure dans la base de données, non seulement la description des occurrences, maiségalement la définition de la classe; c'est le cas chaque fois que des objets individuels peuvent appartenir àdiverses catégories qui sont elles-mêmes décrites dans un catalogue.

Les attributs et/ou associations décrivant la classe décrivent également chaque occurrence; en d'autres termes,chaque occurrence d'une classe "hérite" des attributs et associations propres à cette classe.

La relation de classification/instanciation est une relation entre type et occurrences.

Elle peut être représentée par une association définie de la manière suivante :

– APPARTENANCE (TYPE de 0:N, OCCURRENCE de 1:1);– l'association APPARTENANCE n'a pas d'attributs autres qu'une éventuelle période de validité;– elle a le même identifiant que l'entité OCCURRENCE.

Exemples : types de chambres dans un hôtel, types de cotisations pour les membres d'un club ...

Ent/Ass

CHAMBREn°ét ageoccupat ionréservat ions

CATEG.CHAMBREcode cat égoriep rix nuit ée

QUALIFICATION

type

occurrence

1,N

1,1

TYPE COTIS.in t it ulém ont an tpériodicit é

COTISATIONdat e

MEMBREn°nomadresse

type0,N

1,1occurrence

UML

CHAMBREn°ét ageoccupat ionréservat ions

CATEG.CHAMBREcode cat égoriep rix nuit ée

TYPE COTIS.in t it ulém ont an tpériodicit é

MEMBREn°nomadresse

type

0..*

1..1

occurrence

COTISATIONdat e

1 "Instanciation" : mot anglais construit à partir du radical "instance", qui signifie occurrence.

Page 56: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-27

c) Généralisation / Spécialisation

La généralisation (ou son inverse : la spécialisation) est une relation par laquelle une même occurrenced'objet appartient à deux types différents, dont l'un — le sous-type — est inclus dans l'autre — le sur-type. Lesous-type "hérite" des attributs, associations et opérations génériques du sur-type; il possède en outre des at-tributs, associations et/ou opérations spécifiques, qui le différencient; il peut encore redéfinir autrement cer-taines des caractéristiques dont il hérite.1

La généralisation/spécialisation est une relation entre des types.

Ainsi qu'on le verra, cette relation peut être utilisée pour opérer certaines transformations des schémas de don-nées : une spécialisation peut en améliorer la précision, une généralisation peut en diminuer la complexité.Cet intérêt méthodologique particulier justifie qu'elle ait été intégrée au modèle Entité–Association, où ellepeut être représentée par un symbole ad hoc.

Elle pourrait également être représentée sous la forme d'une association "EST-UN", définie de la manière sui-vante :

– EST-UN (SUR-TYPE de 0:1, SOUS-TYPE de 1:1);– l'association EST-UN n'a pas d'attributs autres qu'une éventuelle période de validité;– le SOUS-TYPE et l'association EST-UN ont le même identifiant que le SUR-TYPE.

UML Ent/Ass

PERSONNEn° nat ionalnomprénomdat e de naissance

FEMME MARIEEnom de jeune fille

FEMMEHOMME

EST-UNE

EST-UNE

EST-UNE

0,1 0,1

0,1

1,1 1,1

1,1

PERSONNEn° nat ionalnomprénomdat e de naissance

FEMME MARIEEnom de jeune fille

FEMMEHOMME

N.B. On peut, sans problème, concevoir des sous-types d'associations, mais la limitation du formalisme En-tité–Association évoquée plus haut ne permet pas de représenter le lien de ces sous-types avec un sur-typed'association. (Ici aussi, les types d'associations devraient être transformés en types de pseudo-entités.)

1 Les langages de programmation par objets disposent d’un mécanisme sélectionnant automatiquement, parmiles diverses définitions d’une opération "polymorphe", celle qui convient à chaque objet.

Page 57: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-28

Exemple : le chef d'une équipe sur chantier fait partie des membres de cette équipe;le sous-type d'associations DIRECTION est inclus dans le sur-type COMPOSITION :

OUVRIER

EQUIPE

COMPOSITIONDIRECTION

1,N

1,1

1,1

0,1chef membre

2.3. Schéma dynamique : diagrammes d’états et transitions

a) Etats

A tout moment, un objet se trouve dans un certain état, caractérisé par la valeur de ses attributs et sa participa-tion à certaines associations.

On définit une classe d'états par une expression logique portant sur la valeur des attributs de l'objet et/ou saparticipation à l'une ou l'autre associations.

Exemple : type d'objet classes d'états définitions

Produit { épuisé stock = 0{ approvisionné stock > 0

Il est parfois possible d'opérer des regroupements de classes d'états.

Exemple : type d'objet

Dette

classes d'états (UML)

en cours

éteinte

apurée remise

définitions

solde > 0

apurée OU remise

NOTE. Les exemples ci-dessus sont des exemples d'objets–entités dont les états sont des états inertes. D'au-tres objets, par exemple un programme exécuté sous le contrôle d'un superviseur (un "processus", dans laterminologie des systèmes d'exploitation), dans certains de leurs états, sont actifs. C'est pourquoi, dans ladescription d'une classe d'états, la notation UML donne la faculté de mentionner différentes actions :

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

Page 58: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-29

Exemple : type d'objet

Processus

classes d'états (UML)

en cours

entrée : charger les paramètres

sortie : préparer le code de retour

faire : exécuter les instructions

b) Transitions

Dans la vie d'un objet, on peut définir une ou plusieurs séquences de transitions d'états autorisées.

– Une transition d'état, c'est-à-dire le passage d'un état à un autre, est la conséquence d'un événement dont l'objet reçoit la notification sous la forme d'un message. Cependant, si l'état de départ est un état actif, la transition est parfois automatique, sans message (ex.: la fin d'exécution d'un programme).– La transition peut être "gardée", c'est-à-dire subordonnée à une condition.– Elle peut s'accompagner d'une action, c'est-à-dire de l'émission d'un message dérivé, éventuellement destiné à un autre objet.

Diagramme des transitions d'états d'un objet (UML)

Produit

épuisé approvisionnécréer()

entrer(qté)

sortir(qté) [qté=stock] /^commande_fournisseur.créer (prod,qté,fourniss)

sortir(qté) [qté<stock]

entrer(qté)

SYNTAXE recommandée :

transition := événement [garde] / actionévénement := messagemessage := opération (paramètres)action := ^objet_cible.message

Processus

en coursexec()

entrée : charger les paramètres

sortie : préparer le code de retour

faire : exécuter les instructions

Noter la représentation conventionnelledes états initial (unique)et finals (en nombre quelconque).

REMARQUE. Sous peine d'ambiguïté, une transition ne peut pas aboutir à une classe d'états définie par re-groupement.

Page 59: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-30

c) Méthode

Sur l'exemple de l'état civil d'une personne, illustrons la démarche d'élaboration d'un tel diagramme.

1)Répertorier les classes d'états de base :Célibataire, Marié, Divorcé, Veuf.

2)Recenser les événements pertinents,causes de transitions :naissance, mariage, divorce, décès duconjoint, décès propre.

3)Regrouper les classes d'états se trouvantà l'origine des mêmes transitions :libre (C ou D ou V), en vie.

C

M

D V

mariagedivorce

décès conjoint

naissance décès

en vie

libre

• C M D V (•)• xC x xM x x xD x xV x x(•)

Page 60: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-31

3. Contraintes d'intégrité

3.1. Portée des contraintes d’intégrité

Le schéma conceptuel des données ne serait pas complet s'il n'énonçait les règles de cohérence, les contraintesd'intégrité applicables aux objets qu'il décrit.

Certaines de ces contraintes doivent être satisfaites à tout moment; on les appelle des invariants. D'autres nedoivent être vérifiées qu'à certains moments; ce sont les pré-conditions ou post-conditions des opérations etprocédures du système de traitement de l'information. Les pré-conditions d’une opération doivent être satis-faites pour que l’opération puisse être entreprise; les post-conditions d’une opération sont des prédicats quel’exécution de l’opération doit rendre vrais, elles constituent l’expression formelle des résultats de l’opération.

Certaines contraintes "concernent" un seul type d’objet, entité ou association. Ces contraintes font partie in-tégrante de la spécification de ce type d’objet. Certains langages1 permettent d’ailleurs de les incorporer à ladéfinition "programmée" du type d’objet : les invariants sont attachés aux attributs, les pré- et post-conditionssont attachées aux opérations.

3.2. Connectivité et identifiant

En précisant les connectivités minimum et maximum d'un rôle et en définissant l'identifiant minimal d'untype d'objet, on exprime des contraintes d'intégrité, inhérentes au modèle Entité–Association.

3.3. Durée de rétention

Avec ou sans dimension historique explicite, une entité ou association est conservée un certain temps dans lacollection décrite par le schéma. C'est ce qu'on appelle sa période de mémorisation ou de rétention.

Il est essentiel de formuler la règle qui en détermine la durée, car elle n'est pas sans influence sur l'exactitudedu schéma. Ainsi, par exemple, définissant le type CLIENT comme "tout client ayant passé au moins unecommande qui a permis de l'identifier", on pourrait penser que la connectivité du rôle de CLIENT dans le typed'association PASSATION de COMMANDE est 1:N; or ceci impliquerait que toute commande (ou au moinsune commande) soit conservée pendant l'éternité ! Si, comme il se doit, on pose la contrainte que la durée derétention d'une commande n'est pas illimitée, cette connectivité devient 0:N.

Nous ne proposerons pas de formalisme pour l'expression de cette contrainte. Indiquons toutefois que :

– par défaut, c'est-à-dire sans règle explicite, la durée de rétention d'une entité est illimitée;– par défaut, la période de rétention d'une association est égale à l'intersection des périodes de ré-tention des entités participantes;– la durée de rétention est exprimée par une condition impliquant une date ou un fait temporel, fré-quemment associé à l'exécution d'une procédure (ex.: "pendant cinq années à compter du 1/1 del'année suivante", "jusqu'à la procédure de clôture annuelle").

1 Exemples : EIFFEL, SQL3.

Page 61: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-32

3.4. Contraintes ensemblistes

Certaines contraintes définissent des relations — égalité, inclusion, exclusion, partition ... — qui doiventexister entre certains ensembles d'occurrences dans la collection décrite par le schéma.

Exemples : – contrainte entre sous-types d'un même type (ex.: partition) : invariant : {HOMME} ∪ {FEMME} = {PERSONNE} ; invariant : {HOMME} ∩ {FEMME} = {∅} ;

– contrainte entre les rôles joués par une entité dans diverses associations :LIVRAISON (COMMANDE exécutée-en 0:1, BORDEREAU accompagnant 1:1)FACTURATION (COMMANDE facturée-en 0:1, FACTURE émise-pour 1:1)

invariant : {COMMANDE exécutée dans LIVRAISON} = {COMMANDE facturée dans FACTURATION} ;

– contrainte entre plusieurs associations des mêmes entités :COMPOSITION (EQUIPE composée-de 1:N, OUVRIER membre-de 1:1)DIRECTION (EQUIPE dirigée-par 1:1, OUVRIER chef-de 0:1)

invariant : {DIRECTION} ⊆ {COMPOSITION} ;

3.5. Règles relatives à la valeur des attributs

a) Définition des domaines de valeurs

Tout domaine de valeurs doit être défini.

Domaine élémentaire

Un domaine élémentaire (ex.: PRIX, QUANTITE, NOM, NUMERO ...) est défini comme faisant partie d'untype de valeurs du genre de ceux que proposent les langages de programmation.

Exemples : domaine type de valeurQUANTITE nombre entierPRIX nombre décimal — en COBOL : PICTURE 9(6)V99NOM CHAR(20) — en COBOL : PICTURE X(20)

Cette définition doit souvent être restreinte, soit sous la forme d'un intervalle, soit sous celle d'une liste devaleurs discrètes qui est généralement une liste de code (il est important, dans ce dernier cas, que la docu-mentation livre la signification du code).

Exemples : CODE-SEXE = {0 = inconnu, 1 = masculin, 2 = féminin} ;NOM-DE-MOIS = {"janvier"," février"," mars"...} ;MOIS = {1..12} ;JOUR = {1..31} ;

Rappel. Ne pas oublier de définir la codification des valeurs spéciales inexistant et inconnu.

Page 62: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-33

Domaine structuré

Un domaine structuré est défini comme une relation entre sous-domaines.

Exemple : DATE = (JOUR, MOIS, ANNEE) ;concernant DATE : invariant :

MOIS ∈ {02} ⇒ JOUR ∈ {1..29} ;MOIS ∈ {04,06,09,11} ⇒ JOUR ∈ {1..30} ;

ADRESSE = (RUE, NUMERO-DE-RUE, NUMERO-POSTAL, LOCALITE) ;

Un domaine exprimant une grandeur mesurée doit en principe indiquer également l'unité de mesure.

Exemple : PRIX = (MONTANT, DEVISE) ;

b) Restriction du domaine (condition d'appartenance)

Dans le contexte d'un type d'objet (entité ou association) précis, la définition du domaine de valeurs d'un at-tribut est parfois encore restreinte. Une telle règle est souvent perçue comme une condition particulière d'ap-partenance au type d'objet.

Exemple : invariant : Quantité-Disponible de STOCK ≥ 0

c) Relations entre attributs

Contraintes statiques

La valeur de certains attributs peut être liée à certains autres attributs ou à certaines associations.

Exemple 1 :

PERSONNEnomdate naissance

HOMME FEMMEnom de jeune filleCONJOINT

dat e m ariage

mari épouse

0,10,1

concernant CONJOINT : invariant : Date-Mariage > Date-Naissance de HOMME mari ;concernant CONJOINT : invariant : Date-Mariage > Date-Naissance de FEMME épouse ;concernant FEMME : invariant : (Nom-de-Jeune-Fille ≠ inexistant) ⇔ ∃ CONJOINT pour FEMME épouse ;

Page 63: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-34

Exemple 2 :

CLIENTn° clien tnom clientadresse client

FACTUREn° factureto t al facturé

PRODUITn° p roduit(1 ) nom p roduitquan t it é en stockprix de vent e

COMMANDEn° com m ande

PASSATIONdate com m ande

LIGNE-FACTUREquan t it é liv réem ont an t fact uré

LIGNE-COMMANDEquan t it é com m andée

FACTURATIONdate facture

passant

passée

comprenant

commandé

facturé

comprenant

facturée

émise

0,N

1,1

0,1

1,1

1,N

1,N

0,N

0,N

concernant COMMANDE : après ENREGISTREMENT-COMMANDE : n°-commande = n°-commande précédent + 1 ;concernant COMMANDE : après REINITIALISATION-ANNUELLE : n°-commande = 0 ;concernant FACTURATION : invariant : date-facture ≥ date-commande de PASSATION pour COMMANDE passée et facturée ;concernant LIGNE-FACTURE : après EDITION-FACTURE : quantité-livrée = MIN ( quantité-en-stock précédente de PRODUIT facturé, quantité-commandée de LIGNE-COMMANDE pour [COMMANDE comprenant et facturée dans FACTURATION pour FACTURE comprenant, PRODUIT commandé et facturé] ) ;concernant LIGNE-FACTURE : après EDITION-FACTURE : quantité-en-stock de PRODUIT facturé = quantité-en-stock précédente de PRODUIT facturé – quantité-livrée ;concernant LIGNE-FACTURE : invariant : montant-facturé = prix-de-vente de PRODUIT facturé * quantité-livrée ;concernant FACTURE : invariant : total-facturé = Σ montant-facturé de LIGNE-FACTURE pour FACTURE comprenant ;

Contraintes d'évolution

L'évolution de la valeur de certains attributs peut être soumise à des contraintes spécifiques. Par exemple, ilest impossible de redevenir célibataire après avoir été marié. Pour exprimer ces règles, on distinguera les va-leurs successives au moyen du qualificatif précédent.

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

Page 64: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-35

Alors que la seconde de ces règles est probablement utilisée par un programme de calcul, l'applica-tion de la première relève de l'utilisateur du programme de mise à jour des données, et celui-ci doit encontrôler l'application. Les programmes adopteront une attitude de compréhension "souple" devantde telles contraintes : il faut, en effet, autoriser la correction des erreurs d'encodage !

REMARQUE. Les contraintes d’évolution peuvent être décrites au moyen de diagrammes de transitionsd’états.1

3.6. Définition sémantique des opérations

La définition sémantique d’une opération de traitement de données, particulièrement d’une opération caracté-ristique d’un type d’objet, complète la spécification externe de cette opération.

Le complément de définition comporte

– explicitement :

– les pré-conditions rendant possible l’exécution correcte de l’opération,– les post-conditions que l’exécution de l’opération doit rendre vraies;

– implicitement :

– les invariants attachés aux données ou objets résultats de l’opération.

Certaines de ces règles expriment une égalité; parmi elles se trouvent les règles de dérivation qui définissentles créations ou transformations de données que l’opération doit accomplir.

Ainsi, pour définir la sémantique de l’opération d’édition d’une facture, il suffit de regrouper les contraintesdéjà formulées ci-dessus et, pour être complet, d’autres semblables :

après EDITION-FACTURE :concernant LIGNE-FACTURE : quantité-livrée = MIN ( quantité-en-stock précédente de PRODUIT facturé, quantité-commandée de LIGNE-COMMANDE pour [COMMANDE comprenant et facturée dans FACTURATION pour FACTURE comprenant, PRODUIT commandé et facturé] ) ;concernant LIGNE-FACTURE : quantité-en-stock de PRODUIT facturé = quantité-en-stock précédente de PRODUIT facturé – quantité-livrée ;

invariant :concernant FACTURATION : date-facture ≥ date-commande de PASSATION pour COMMANDE passée et facturée ;concernant LIGNE-FACTURE : montant-facturé = prix-de-vente de PRODUIT facturé * quantité-livrée ;concernant FACTURE : total-facturé = Σ montant-facturé de LIGNE-FACTURE pour FACTURE comprenant ;

1 Cf. supra, § 2.3.

Page 65: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-36

3.7. Formalisme pour l'expression des règles

Pour donner une idée du degré de précision souhaitable, sans toutefois nous encombrer des nombreusesconventions d'un langage formel opérationnel, nous avons ci-dessus formulé les règles dans une ébauche delangage formalisé, dont voici une brève définition.

a) La notion de règle

Une règle se présente sous la forme

[contexte :] portée : expression ;

L'expression cite des variables, c'est-à-dire des composants quelconques du schéma auquel la règle est atta-chée : occurrences d'entités ou d'associations, attributs, collections d'occurrences.

Nous ne donnerons pas ici une liste exhaustive des opérations possibles. Il peut s’agir d’opérationsarithmétiques (+ − ∗ / Σ ...), ensemblistes (∪ ∩ ...), logiques (¬ ∧ ∨ ⊕ ⇔ ⇒ ∀ ∃ ...) ou de com-paraison (= ≠ < > ≤ ≥ ∈ ⊂ ...) ... Il peut aussi s'agir d'un nom de fonction accompagné de ses para-mètres (ex.: min(a,b) ...).

L'expression doit être vraie dans les circonstances précisées par la portée de la règle :

invariant l'expression doit être vraie à tout momentavant procédure l'expression est une pré-condition de la procédure mentionnée

(l'exécution de la procédure est impossible sinon)après procédure l'expression est une post-condition de la procédure mentionnée

(les post-conditions d'une opération en définissent le résultat)

L'indication facultative d'un contexte permet d'alléger la rédaction de l'expression :

concernant type nom d'un type d'entité ou d'association

Exemple : concernant STOCK : invariant : Quantité-Disponible ≥ 0 ;est synonyme de invariant : Quantité-Disponible de STOCK ≥ 0 ;

b) La notion de variable

A l'intérieur d'une expression, un nom de type — d'entité, d'association, d'attribut — est employé pour dési-gner un élément (occurrence) quelconque du type en question.

Dans les expressions, la désignation d'une variable peut être indicée et qualifiée :

variable [indice] [qualificatif ...]

L'indice précédent permet de distinguer les occurrences successives d'un même type d'élément.

Exemple : n°-commande précédent de COMMANDE

Page 66: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-37

Les qualificatifs permettent de "naviguer" dans le schéma, c'est-à-dire de relier les éléments du schéma. Lesqualificatifs possibles sont les suivants :

attribut de entitéEnt

attr

attribut de associationAss

attr

association pour entité rôle

Ass Entrôle

entité rôle dans association

Ent Assrôle

assoc1 pour entité rôle1 et rôle2 dans assoc2

Ass1 Entrôle1 Ass2rôle2

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

Ent1 Assrôle1 Ent2rôle2

– Les prépositions de – dans – pour sont interchangeables.– Les noms de rôles peuvent être omis si cette omission ne rend pas la désignation ambiguë.– La désignation d'une variable doit comporter autant de qualificatifs qu'elle en exige pour être univoque.– Toutefois, le type indiqué comme contexte en tête de la règle peut compléter implicitement toute désigna-tion de variable.

Exemple : concernant CONJOINT : invariant : Date-Mariage > Date-Naissance de HOMME mari ;

est synonyme de invariant : Date-Mariage de CONJOINT > Date-Naissance de HOMME mari dans CONJOINT ;

En vue de faciliter la rédaction des expressions, on pourra définir des variables intermédiaires, que les ex-pressions pourront également référencer. Une variable intermédiaire est déclarée de la manière suivante :

soit variable = variable [si expression] ;

Exemple : soit COMMANDE-EN-ATTENTE = COMMANDE si ¬ ∃ (FACTURATION pour COMMANDE) ;

Page 67: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-38

c) Les ensembles

Une variable ensemble est dénotée en plaçant la désignation de la variable élément dans une paire d'accola-des :

{variable}

Exemples : {FACTURE}{n°-produit de PRODUIT}{COMMANDE-EN-ATTENTE}

Les expressions peuvent en outre référencer des ensembles littéraux :

– liste d'éléments : {1,2,5,7} {"janvier","février",...}– liste d'intervalles : {1..12,15..20}– ensemble vide : {∅}– ensemble nommé : nom de domaine, nom de variable intermédiaire

Remarque

Les schémas graphiques que nous utilisons définissent des types d'entités et d'associations; ils ne définissentpas les types de collections. Pour définir un type de collection et lui attribuer un nom, on emploiera une règledu genre de celles-ci :

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

Page 68: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-39

4. Validation du schéma

Le premier jet d'un schéma de données doit être validé par un examen approfondi, ayant pour objet de leverles ambiguïtés et contradictions, d'affiner et préciser la représentation de la réalité perçue, de contrôler les re-dondances.

4.1. Suppression des incohérences

a) Correction des anomalies lexicographiques

Pour chaque définition, on "officialisera" un seul vocable, mais il sera bon de signaler dans la documentationquels en sont les synonymes usuels.

L'incorporation d'un qualificatif peut rendre un vocable univoque (par exemple, COMMANDE sera préciséen COMMANDE-DE-CLIENT et COMMANDE-A-FOURNISSEUR). On pourra cependant tolérer qu'unnom d'attribut soit polysème (par exemple, "date-de-commande"), puisqu'il est naturellement qualifiable parle nom du type d'objet qu'il décrit (ex.: date-de-commande de COMMANDE-A-FOURNISSEUR)..

b) Vérification des contraintes, Elimination des contradictions

Lors de l'élaboration d'un schéma de données, les questions les plus porteuses de renseignements sont cellesqui concernent les contraintes d'intégrité inhérentes au modèle : la connectivité des rôles et la compositiondes identifiants minimaux. Il est donc utile de faire, sur ces questions, un second tour de piste.

On vérifiera en particulier qu'il n'existe pas de contradiction entre les connectivités indiquées et les contrain-tes ensemblistes ou de durée de rétention. (On a déjà donné l'exemple suivant : si la durée de rétention desCOMMANDEs est limitée, la connectivité minimale du rôle de CLIENT dans le type d'associationPASSATION de COMMANDE ne peut pas être 1.)

4.2. Affinage du schéma

a) Normalisation des composants

Certains attributs peuvent cacher un type d'association.1 On cherchera alors à désagréger les types d'objetspossédant ces attributs, en explicitant le type d'association caché, pour autant que les compositions mises enplace enrichissent la sémantique ou diminuent la redondance. Pour ce faire, on recourra aux règles de nor-malisation, dont les trois premières ont été établies par CODD, dans son modèle relationnel;2 ces règles fontusage du concept de dépendance fonctionnelle, défini au chapitre 2.

1 Rappelons la parenté des concepts d'attribut et type d'association.2 E. CODD : Further Normalization of the Database Relational Model in RUSTIN (ed) : Data Base Sys-tems, Prentice-Hall, 1972. Par la suite, d'autres auteurs ont défini une quatrième et une cinquième formesnormales.

Page 69: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-40

1NF (1st normal form) Un type d'entité ou d'association est en première forme normale si tous ses attributssont atomiques, c'est-à-dire simples (non répétitifs) et élémentaires (non structurés).

Si un attribut est à la fois répétitif et structuré, il s'agit presque certainement d'un type d'association déguisé.

Exemple : l'attribut "liste des résultats" d'examens d'un étudiant,chaque indication de résultat comportant l'identification de la matière et la cote obtenue

MATIEREint it ulé

ETUDIANTnomliste:{résu lta t=in titu lé,co te}

ETUDIANTnom

RESULTATco t e

0,N 0,N

Mais il n'y aurait certainement aucun apport à remplacer un attribut "liste des prénoms" par un type d'associa-tion entre le type d'entité PERSONNE et un type d'entité PRENOM !

2NF (2nd normal form) Un type d'entité ou d'association est en deuxième forme normale s'il est en 1NF etqu'en outre aucun attribut ne dépende fonctionnellement d'une partie seulement de ses identifiants.

Cette règle fait référence à un identifiant composé, ce qui est le plus souvent le cas d'une association, maisquelquefois aussi d'une entité.

Exemple : l'attribut "prix unitaire" dans le type d'association LIGNE-COMMANDEest en réalité un attribut d'un type d'entité (PRODUIT) associé

PRODUITn° p roduitnom produit

COMMANDEn° com m ande

LIGNE-COMMANDEquan t it é com m andéeprix un ita ire

0,N 1,Ncomprenantcommandé

Mais si, dans le laps de temps séparant la réception et l'exécution de la commande, le prix de vente unitaire estsusceptible de changer, le "prix à la commande" (copié dans la LIGNE-COMMANDE) et le "prix de catalo-gue" sont — peut-être sous le même nom — deux informations distinctes. Copier ainsi dans chaque LIGNE-COMMANDE le prix unitaire en vigueur à la date de réception de la commande pourrait rendre superflue laconservation d'un historique du tarif.

3NF (3rd normal form) Un type d'entité ou d'association est en troisième forme normale s'il est en 2NF et s'iln'existe pas de dépendance fonctionnelle transitive par rapport à un de ses identifiants, c'est-à-dire s'il n'existepas d'attribut dépendant d'un autre, lui-même dépendant d'un identifiant.

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

Page 70: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-41

CLIENTn° clien tnom clien t

FACTUREn° fact uren° com m andeda te com m anden° clien tnom client

COMMANDEn° com m ande

PASSATION

FACTURATION

0,N 1,1

0,1

1,1

BCNF (Boyce-Codd normal form) Le déterminant de toute dépendance fonctionnelle à l'intérieur d'un typed'objet, entité ou association, doit être un identifiant, primaire ou candidat, de cet objet.

Cette formule, due à Boyce, résume (et étend) les trois formes normales de Codd.

b) Spécialisation par sous-typage

La définition de sous-types produit une modélisation plus explicite et souvent plus rigoureuse.

Généralisations implicites

Le fait que certains attributs d'un type d'entité ou d'association prennent la valeur "inexistant" en fonction de lavaleur d'autres attributs est un signe que le type d'entité ou d'association a été défini par généralisation. Dansce cas, n'est-il pas indiqué de procéder à une modélisation plus explicite, en distinguant des sous-types ?

Exemple. Le catalogue d'une firme de vente signale pour certains produits seulement un délai de li-vraison; il s'agit de produits que la firme ne garde pas en stock mais qu'elle achète à un fournisseur.

PRODUITn° p roduitp rix de ven t e[délai de livra ison]

HORS-STOCKdélai de liv raison

PRODUITn° p roduitp rix de ven t e

Associations conditionnelles

Un type d'association conditionnel, ne faisant intervenir un type d'entité que si un attribut de ce dernier pos-sède une ou des valeur(s) particulière(s) n'est défini, en toute rigueur, que sur un sous-type de cette entité.

Exemple. Si le type d'association CONJOINT est simplement défini sur le type PERSONNE, une rè-gle supplémentaire doit signifier la condition de différence de sexe; la modélisation suivante est plusexplicite.

Page 71: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-42

PERSONNEnomdat e naissance

HOMME FEMMEnom de jeune filleCONJOINT

dat e m ariage

mari épouse

0,10,1

4.3. Simplification du schéma

a) Simplification des structures

Associations de degré élevé

Un type d'association de degré élevé reflète souvent un défaut d'analyse. On cherchera donc à le décompo-ser, c'est-à-dire à le transformer en une composition de types d'associations de degré moindre. Un indice fré-quent d'une telle situation est celui-ci : il existe des dépendances fonctionnelles entre les différents rôles d'untype d'association ou, en d'autres termes, l'identifiant minimal de ce type d'association n'inclut pas les identi-fiants de tous les types d'entités associés.

Exemple : ENSEIGNEMENT (MATIERE dispensée-dans 1:N, CLASSE suivant 1:N, PROFESSEUR titulaire-de 1:N)– par son identifiant, la définition ci-dessus pose que une matière enseignée à une classe donnée l'est par un seul professeur; elle n'interdit pas qu'une matière soit toujours enseignée par le même professeur, pour quelque classe que ce soit; dans ce cas, la définition devrait devenir la suivante :

CLASSE

PROFESSEUR

MATIERE

PROGRAMME

ENSEIGNEMENT

suivant

suivie

enseignéetitulaire

1,N 1,N

1,11,N

Compositions de connectivités 1:1

La propriété d'équivalence sémantique énoncée plus haut sera exploitée pour simplifier les compositions necomportant que des connectivités 1:1, particulièrement si ces compositions comprennent des types d'associa-tions vides d'attributs.

PRODUITCOMMANDELIGNE

COMMANDECOMPOSITION CONCERNE1,1 1,1 0,N1,N

Page 72: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-43

b) Contrôle des structures redondantes

L'élaboration d'un schéma de données peut avoir défini des structures redondantes, qu'il convient d'éliminerou, à tout le moins, de justifier. On adoptera pour principe de conserver la structure la plus porteuse d'infor-mation (on pourra prendre pour mesure de la richesse sémantique d'une structure le nombre d'attributs qu'ellecomporte); en cas d'égalité, on conservera la structure la moins complexe (on prendra pour mesure de lacomplexité le nombre de types d'objets).

Les situations suivantes sont assez fréquentes.

Il se peut qu'on ait indiqué comme attribut d'un type d'entité l'identifiant d'un type d'entité associé; cet attri-but est donc redondant avec l'association. On conservera l'association, sémantiquement plus riche.

DEPARTEMENTn° départ em ent

EMPLOYEn° m at riculen° départem ent

OCCUPATION1,1 1,Noccupé occupant

Deux types d'associations définis sur les mêmes types d'entités avec les mêmes connectivités doivent être sus-pectés de redondance. Cette situation peut, en particulier, résulter de la simplification, évoquée plus haut, descompositions utilisant des connectivités 1:1.

Un type d'association, probablement vide d'attributs, peut s'avérer n'être que le "résumé" d'une compositionde plusieurs associations. On conservera la composition, sémantiquement plus riche.

FACTURE

COMMANDE

BORDEREAU

ACCOMPAGNEMENT

FACTURATIONLIVRAISON

1,1

0,N 0,1

1,1

1,N1,1

c) Cas particulier : les attributs dérivables

Un attribut dérivable est un attribut dont la valeur peut être à tout moment déterminée, le plus souvent parcalcul, à partir de la valeur d'autres attributs. Ainsi, l'attribut "prix facturé" est dérivable des attributs "prix devente unitaire" et "quantité livrée" si ces deux derniers sont disponibles à tout instant de la période de réten-tion du premier et l'attribut "montant total" de la facture est dérivable à partir des "prix facturés" détaillés.

Dans une collection d'informations enregistrées, la présence d'un attribut dérivable est une redondance com-pliquant les opérations de mise à jour : soit un attribut R dont la valeur peut être obtenue à partir d'une séried'attributs Di; lors de tout changement de valeur d'un des attributs Di, la valeur de R doit être également modi-fiée. En revanche, la description d'une collection d'informations communiquées par un document doit men-tionner les attributs dérivables, dont l'utilité spécifique est toujours d'améliorer la lisibilité du document.

Remarque. Dans les diagrammes UML, le nom d'un attribut dérivable est préfixé d'une barre oblique /.

Page 73: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-44

4.4. Note sur les sous-schémas

Un sous-schéma constitue une sélection parmi les types d'objets répertoriés dans le schéma global de la basede données : certains types d'entités, certains types d'associations et même certains attributs dans les typesd'objets retenus sont masqués.

En outre, les types d'objets conservés sont quelquefois transformés, de manière à pallier l'absence des objetsmasqués. On notera en particulier :

– la transformation d'un type d'association en type d'entité, si un des types d'entités participants est masqué;– l'incorporation à un type d'entité, en guise d'attributs, des identifiants des types d'associations masqués;– l'incorporation des éléments permettant de déterminer la valeur des attributs dérivables, si ces éléments ap-partiennent aux objets masqués.

CLIENTn° clientnom clientadresse client

FACTUREn° factureto t al facturé

PRODUITn° produit(1) nom produitquan t it é en st ockprix de ven te

COMMANDEn° com m ande

PASSATIONdate com m ande

LIGNE-FACTUREquan t it é liv réem ontant facturé

LIGNE-COMMANDEquan t it é com m andée

FACTURATIONdate facture

passant

passée

comprenant

commandé

facturé

comprenant

objet de

pour

0,N

1,1

0,1

1,1

1,N

1,N

0,N

0,N

FACTUREn° facturet ot al fact uréda te facturen° clien tnom clien tadresse client

CORPSFACTURE

LIGNEFACTUREquan t it é liv réem ontant facturéquantité com m andéen° produ itnom produ itprix de ven te

1,N

1,1

Page 74: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-45

5. Validation du système de règles

5.1. Complétude du système de règles

Il est nécessaire de procéder à une vérification systématique de la complétude du système de règles associé auschéma de données. Tout particulièrement du sous-système des règles de dérivation, dont le caractère faisa-ble doit ainsi être certifié.

Appelons donnée primaire toute variable (élémentaire ou ensemble) dont la valeur n'est pas "à calculer",mais "reçue"; appelons résultat toute variable (élémentaire ou ensemble) dont la valeur est "à calculer" parl'application d'une règle de dérivation.

Pour chaque règle énoncée, on vérifiera les points suivants :

– pour chaque règle exprimant une égalité, on statuera sur le point de savoir si elle constitue une condition devalidité (1V) ou une règle de dérivation (1D) (elle peut avoir les deux usages, mais dans des contextesdifférents);– toutes les variables référencées par la règle sont-elles inventoriées (2) dans le schéma des données ?– toute variable référencée est-elle une donnée primaire (3P) ? sinon, existe-t-il une règle de dérivationdont elle soit le sujet (3D) ?– toutes les variables mentionnées dans la règle sont-elles qualifiées de manière univoque (4) ?

Il va de soi que ces vérifications impliquent l'emploi d'annotations : on "marquera" chaque règle et chaquevariable ayant subi avec succès chacun des examens ci-dessus, par exemple, au moyen des numéros indiquésentre parenthèses dans le texte de l'alinéa précédent.

5.2. Cohérence du système de règles

Deux règles sont redondantes si elles expriment, dans des formes différentes, la même relation. On notera lecas particulier de la permutation des parties gauche et droite d'une égalité.

Le système de règles doit être exempt de contradictions. Ceci est aisément vérifiable pour les règles expri-mant une égalité : si plusieurs règles d'égalité non redondantes concernent le même sujet, elles doivent avoirdes portées mutuellement exclusives.

Page 75: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-46

6. En guise de conclusion

6.1. Recommandations diverses

Les auteurs de la méthode OMT formulent les recommandations suivantes. [La première fois qu'un termepropre à la méthode OMT est employé, nous indiquons entre crochets son équivalent dans la terminologie dumodèle Entité–Association.]

• Ne commencez pas à construire un modèle objet [schéma Entité–Association] en jetant pêle-mêleclasses [types d'entités], associations et héritage [sous-typage]. Vous devez avant tout compren-dre le problème à résoudre. Le contenu d'un modèle objet est conditionné par la pertinence de lasolution.

• Efforcez-vous de garder votre modèle simple. Evitez les complications inutiles.

• Choisissez les noms avec soin. Ils sont importants et portent des connotations puissantes. Ils doi-vent être descriptifs, précis, sans ambiguïté et ne doivent pas subir l'influence exclusive d'un seul as-pect de l'objet. Le choix de bons noms est l'une des facettes les plus délicates de la modélisation desobjets.

• N'enfouissez pas des pointeurs ou des références d'objets [identifiants étrangers] dans les objetsen tant qu'attributs. Modélisez-les plutôt comme des associations. C'est plus clair et cela saisit lavéritable intention plutôt qu'une approche particulière d'implémentation.

• Evitez si possible les associations ternaires et n-aires. La plupart de celles-ci peuvent être décom-posées en associations binaires, éventuellement avec [...] des attributs de lien [attributs d'associa-tion].

• N'essayez pas d'exprimer parfaitement les multiplicités [connectivités] trop tôt dans le dévelop-pement.

• Ne dissolvez pas les attributs de lien [attributs d'association] dans une classe [type d'entités].

[...]

• Essayez d'éviter les généralisations profondément imbriquées.

• Reconsidérez les associations un-à-un. Souvent l'objet à chaque extrémité est optionnel et unemultiplicité zéro-ou-un peut être plus appropriée. A d'autres moments, une multiplicité "plusieurs"sera nécessaire.

• Ne soyez pas surpris que votre modèle objet ait besoin d'une révision. Il faut souvent de multiplesitérations pour clarifier les noms, réparer les erreurs, ajouter des détails et prendre correctement encompte les contraintes structurelles. Plusieurs de nos modèles les plus complexes, qui sont seule-ment longs de quelques pages, ont nécessité une demi-douzaine d'itérations.

• Soumettez votre modèle à des avis extérieurs. Le modèle objet peut susciter l'intérêt d'autres per-sonnes et mener à une implication plus large de leur part.

Page 76: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-47

• Documentez systématiquement vos modèles objet. Le diagramme spécifie la structure d'un mo-dèle mais ne peut préciser les raisons qui ont présidé aux divers choix. L'explication écrite guidele lecteur à travers le modèle et explique les raisons subtiles pour lesquelles il a été structuré decette façon. Les explications écrites clarifient la signification des noms dans le modèle et peuventporter la raison d'être de chaque classe et de chaque relation. 1

6.2. Documentation du schéma

C'est à dessein que nous avons, ci-dessus, souligné le dernier paragraphe. Chaque nom (d'entité, d'associa-tion, d'attribut ...) apparaissant dans un schéma est le résumé d'une ou plusieurs discussions avec différentsinterlocuteurs. La documentation accompagnant un schéma doit reproduire le contexte duquel est issu chaquenom, avec sa richesse et son "épaisseur sémantique".

Empruntons aux mêmes auteurs l'exemple suivant, limité à la définition des types d'entités. Le problème ana-lysé est celui du réseau de Guichets Automatiques Bancaires (GAB) d'un consortium de banques.

Compte — Compte unique dans une banque, sur lequel les transactions sont appliquées. Lescomptes peuvent être de diverses sortes, comme des comptes chèques ou des comptes épargne. Unclient peut détenir plus d'un compte.

GAB — Station à partir de laquelle les clients peuvent réaliser eux-mêmes leurs transactions enutilisant des cartes bancaires pour s'identifier. Le GAB interagit avec le client pour récupérer lesinformations de la transaction, les émet vers l'ordinateur central pour validation et traitement, puisdélivre les billets. Nous supposons que le GAB ne peut pas fonctionner sans le réseau.

Banque — Institut financier qui gère les comptes des clients et délivre les cartes bancaires autori-sant l'accès aux comptes par le réseau des GAB.

Ordinateur de banque — Ordinateur appartenant à une banque, réalisant l'interface avec le ré-seau des GAB et les stations propres à la banque. Une banque peut détenir son propre réseau d'or-dinateurs pour gérer ses comptes, mais nous ne nous intéressons qu'à celui faisant l'interface avec leréseau des GAB.

Carte bancaire — Carte délivrée par une banque à ses clients, leur permettant l'accès à leur pro-pre compte à l'aide des GAB. Chaque carte comporte un code bancaire et un numéro de carte, cesderniers étant codés pour respecter les standards nationaux sur les cartes bancaires et de crédit. Lecode bancaire identifie la banque à l'intérieur du consortium. Une carte ne permet pas nécessaire-ment l'accès à tous les types de comptes du client. Chaque carte de crédit est détenue par un clientunique, mais plusieurs copies d'une même carte peuvent exister; les accès simultanés par une mêmecarte doivent donc être pris en considération.

Caissier — Employé d'une banque qui est autorisé à effectuer des transactions à partir des agencesbancaires. Il accepte et délivre argent et chèques au client. Les transactions, l'argent et les chèquesmanipulés par un caissier doivent être enregistrés.

Agence bancaire — Agence où un caissier peut réaliser des transactions pour un client. Le cais-sier accepte des chèques et de l'argent du client et lui en délivre également; des reçus sont impri-més. L'agence est en communication avec l'ordinateur de la banque pour valider et traiter les tran-sactions.

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

Page 77: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-48

Ordinateur central — Ordinateur appartenant au consortium, et gérant les transactions entre lesGAB et les ordinateurs des banques. L'ordinateur central valide les codes bancaires mais ne traitepas les transactions lui-même.

Consortium — Organisation de banques qui gère le réseau des GAB. Ce réseau ne traite que lestransactions des banques du consortium.

Client — Détenteur d'un ou de plusieurs comptes dans une banque. Un client peut consister en uneou plusieurs personnes ou une entreprise; la différence est sans importance pour ce problème. Lamême personne possédant des comptes dans différentes banques est considérée comme plusieursclients.

Transaction — Requête complète unique pour réaliser des opérations sur un compte. La spécifi-cation du GAB n'indique que la possibilité de délivrer de l'argent, mais nous pourrions considérer lapossibilité d'imprimer des chèques, d'accepter de l'argent ou des chèques. Nous pourrions prévoiraussi la possibilité d'opérer sur les comptes de clients différents, bien que ce ne soit pas demandé ici.Les différentes opérations doivent avoir des soldes équilibrés. 1

Le processus d'analyse est long et itératif ... La dernière définition ci-dessus montre que, tout au longde son élaboration, un dossier d'analyse contient des définitions provisoires ("nous pourrions prévoiraussi ..."), sur lesquelles l'analyste devra revenir ...

Aux suggestions implicites des exemples ci-dessus, ajoutons celles-ci.

• Lorsque c'est possible, la notice décrivant un type d'objet, entité ou association, reprendra la défi-nition juridique ou réglementaire de la notion décrite.

• Cette notice définira, sans ambiguïté, les conditions d'existence (entrée et sortie) d'une occur-rence du type décrit dans l'ensemble modélisé (ex.: "un CLIENT est toute personne physique ou mo-rale ayant passé au moins une commande, qui a permis de l'identifier, et cela depuis moins de deuxans à la date du 1er janvier écoulé").

• La définition d'un type d'association mentionnera nécessairement chaque type d'entité associé etcomportera généralement un commentaire des connectivités. Exemple : "pour une commande, uneLIGNE DE COMMANDE représente la quantité commandée d'un produit; toute commande com-prend au moins une ligne de commande".

• La définition détaillée d'un attribut n'est utile que si elle apporte un complément aux renseigne-ments fournis par le nom de cet attribut qui, normalement, en identifie le domaine de valeurs et lerôle dans la description de l'objet.

Enfin, tout élément d'information (entité, association, attribut, domaine de valeurs) doit être le plus complè-tement possible localisé dans l'espace et le temps :

– quelle est l'origine ou quels sont les responsables de la définition du concept (type) et de la miseà jour des valeurs (occurrences) ?– à qui cette information est-elle destinée ou distribuée ?– quels sont les aspects historiques de l'information : durées de vie et de rétention, transitionsd'états ?

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

Page 78: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma conceptuel 3-49

Page 79: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-1

Chapitre 4. Schéma logique du stockage des données

Un schéma de stockage des données doit rendre compte des types d'objets stockés. La définition du contenusémantique d'un schéma de stockage constitue un schéma logique des données. Les types d'objets d'unestructure de stockage seront définis par transformation du schéma conceptuel.

Le schéma logique des données doit être complété par celui des fonctions d'accès nécessaires aux applica-tions utilisatrices.

La dernière section de ce chapitre montre en quoi le schéma logique du stockage des données constitue unsupport de la programmation, avec application particulière au langage COBOL.

Page 80: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-2

1. Schéma des structures de stockage : le modèle en Réseau

1.1. Eléments d'une structure de stockage

Un enregistrement (ou article) est un espace du support de stockage, accessible en tant qu'occurrence dis-tincte. La définition sémantique d'un type d'enregistrement découle de la transposition d'un type d'entité oud'association.

La réinterprétation des rôles définis dans le schéma Entité–Association résulte en la déclaration de liaisonsentre enregistrements. Le concept de liaison sera précisé plus loin.

Un enregistrement est découpé en champs. Un champ contient l'inscription d'une valeur. La définition sé-mantique d'un champ équivaut à celle d'un attribut.

1.2. Transformation du schéma Entité–Association

Nous illustrons ici une méthode simple pour transformer en réseau un schéma Entité–Association.

Soit le sous-schéma conceptuel suivant.

Page 81: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-3

CLIENTn° clientnom clientadresse client

PRODUITn° produit(1) nom produitquant it é en stockprix de vente

PASSATIONdate commande

LIGNE-FACTUREquant ité livréemontant facturé

LIGNE-COMMANDEquant it é commandée

FACTURATIONdate facture

passant

comprenant

commandé

facturé

comprenant

objet de

0,N

0,1

1,N

1,N

0,N

0,N

PROSPECTUSt ype prospectus

REPRESENTANTnom représent antrégionchiffre d'affaires

ABONNEMENT

CONTACT

contactant

envoyé à

abonné à

1,N

0,N

0,N

FACTUREn° facturetot al facturé

COMMANDEn° commande

CLIENTPROFESSIONNELn° T VA

CLIENTPRIVE

1,1

1,1

passée

contacté par

pour

1,1

La firme entretient un contact régulier avec ses clients. Un client professionnel est contacté par un représen-tant. Un client privé est contacté par prospectus; il peut être "abonné" à différents types de prospectus etune règle veut qu'il soit, à tout moment, "abonné" à un prospectus au moins.

La transformation de ce schéma comporte les opérations suivantes.

1) Orienter les arcs représentant les rôles, par une flèche dans le sens Association → Entité ou sous-type→ sur-type. Chaque flèche représente un type de liaison. Le type d'objet (Entité) situé à la pointe de la flè-che est propriétaire de la liaison; le type d'objet (Association) situé à l'origine de la flèche est membre dela liaison.

Page 82: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-4

CLIENTn° clientnom clientadresse client

PRODUITn° produit(1) nom produitquant ité en stockprix de vente

PASSATIONdate commande

LIGNE-FACTUREquant ité livréemontant facturé

LIGNE-COMMANDEquant it é commandée

FACTURATIONdate facture

passant

comprenant

commandé

facturé

comprenant

objet de

0,N

0,1

1,N

1,N

0,N

0,N

PROSPECTUSt ype prospectus

REPRESENTANTnom représentantrégionchiffre d'affaires

ABONNEMENT

CONTACT

contactant

envoyé à

abonné à

1,N

0,N

0,N

FACTUREn° facturetotal facturé

COMMANDEn° commande

CLIENTPROFESSIONNELn° T VA

CLIENTPRIVE

1,1

1,1

passée

contacté par

pour

1,1

2) Indiquer la connectivité 0:1 sur les liaisons de sous-typage, c'est-à-dire sur les flèches dépourvues decette indication.

CLIENTn° clientnom clientadresse client

0,1

0,1CLIENTPROFESSIONNELn° T VA

CLIENTPRIVE

Page 83: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-5

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

CLIENTn° clientnom clientadresse client

PRODUITn° produit(1) nom produitquant ité en stockprix de vente

PASSATIONdate commande

LIGNE-FACTUREquant it é livréemontant facturé

LIGNE-COMMANDEquant ité commandée

FACTURATIONdate facture

passant

comprenant

commandé

facturé

comprenant

objet de

0,N

0,1

1,N

1,N

0,N

0,N

PROSPECTUSt ype prospectus

REPRESENTANTnom représentantrégionchiffre d'affaires

ABONNEMENT

CONTACT

contactant

envoyé à

abonné à

1,N

0,N

0,N

0,1

0,1

FACTUREn° facturetot al facturé

COMMANDEn° commande

CLIENTPROFESSIONNELn° T VA

CLIENTPRIVE

4) Supprimer la distinction entre type d'entité et type d'association.

5) Incorporer au type d'enregistrement membre de chaque liaison l'identifiant (étranger) du type d'enre-gistrement propriétaire.2 Indiquer si cet identifiant étranger fait partie de l'identifiant primaire de l'enregistre-ment membre. Le nom d'un identifiant étranger sera construit d'après le schéma suivant : nom de l'attribut –nom du type propriétaire – qualificatif de la liaison.

1 Théoriquement, cette fusion pourrait se limiter à faire disparaître les types d'associations sans attributs.2 En toute rigueur, cette transformation, qui crée de la redondance, est ici prématurée. D'ailleurs, certainssystèmes de stockage (les bases de données CODASYL) n'y ont pas recours. Elle devrait s'opérer plus tard,lors de l'élaboration du schéma physique des systèmes de stockage qui l'exigent, comme les fichiers COBOLou les bases de données relationnelles. C'est parce que nous n'aborderons plus de manière systématique lesproblèmes de transformation des schémas de données que nous citons ce point dès ici.

Page 84: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-6

CLIENTn° clientnom clientadresse client

PRODUITn° produit(1) nom produitquant ité en stockprix de vente

PASSATIONdate commande

LIGNE-FACTUREquant it é livréemontant facturé

LIGNE-COMMANDEquant ité commandée

FACTURATIONdate facture

passant

comprenant

commandé

facturé

comprenant

objet de

0,N

0,1

1,N

1,N

0,N

0,N

PROSPECTUSt ype prospectus

REPRESENTANTnom représentantrégionchiffre d'affaires

CLIENTPRIVEn° clientABONNEMENT

CONTACT

contactant

envoyé à

abonné à

1,N

0,N

0,N

0,1

0,1

FACTUREn° facturetot al facturé

COMMANDEn° commande

CLIENTPROFESSIONNELn° T VA

type prospectusn° client

n° clientnom représentant

n° com m anden° produit

n° client

n° com m ande

n° facturen° produit

6) Eventuellement, supprimer tout type d'enregistrement ne contenant d'autre attribut que son identifiant, s'iln'est membre d'aucune liaison (le type d'enregistrement PROSPECTUS peut être supprimé). Un tel typed'enregistrement sera néanmoins conservé si l'on souhaite constituer une liste des identifiants valides (identi-fiants autorisés pour les enregistrements ABONNEMENT).

1.3. Commentaires sur le concept de liaison

Le concept de liaison est le concept central du modèle présenté ici. Ce modèle en réseau est dû à l'AméricainBACHMAN, qui le créa dès 1963 pour supporter un système de "stockage intégré des données" ("IDS, Inte-grated Data Store"), ancêtre des systèmes de gestion de bases de données. En 1970, CODASYL, organismecréateur du langage COBOL, l'a adopté comme base de sa proposition de standard pour les bases de données.Depuis lors, dans la variante mise au point par J. MARTIN dans sa méthode IEM ("Information EngineeringMethodology"), il joue également, dans les régions anglophones, le rôle de modèle de conception, que lesfrancophones assignent plutôt au modèle Entité–Association.1

1 Voir les références bibliographiques au chapitre 2.

Page 85: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-7

a) Terminologie

Dans les bases de données CODASYL, une liaison est réalisée sous la forme d’un ensemble ("set") d’enre-gistrements interconnectés, entre lesquels il est possible de "naviguer" — c'est-à-dire passer de l'un à l'autre.Soit un type de liaison E ← A. Une occurrence e du type d'enregistrement E est propriétaire d'un ensemble{ai} dont les membres ou éléments sont les occurrences de A liées à e. L'ensemble {ai} peut contenir un nom-bre quelconque d'éléments ou membres, c'est-à-dire d'occurrences de A, y compris 1 ou 0 (ensemble singletonou vide).

E

A

e1 e2

a3a2a1

Selon une autre terminologie, dans une liaison E ← A, E est père ou parent, A est fils ou enfant.

Dans un schéma en réseau, un enregistrement peut être membre de différents types de liaisons, un enfant peutavoir plusieurs parents.1 Dans notre exemple, chaque LIGNE-DE-COMMANDE Lij possède deux parents :une COMMANDE Ci et un PRODUIT Pj.

C1 C2

P1

P2

L11

L12

L21

L22

b) Contraintes définies sur les liaisons

Liaison obligatoire ou facultative

Les liaisons E–propriétaire ← A–membre définies à ce stade de la transformation sont obligatoires, en ce sensqu'elles mettent en jeu toujours une (1:1) occurrence de E propriétaire (il est obligatoire pour toute occur-rence de A d'être liée à une occurrence de E). On verra plus loin que l'on peut définir des liaisons facultati-ves, mettant en jeu au plus une (0:1) occurrence de E propriétaire (il est facultatif pour une occurrence de Ad'être liée à une occurrence de E).

Connectivité d'un type de liaison

Dans un schéma Entité–Association, l'orientation d'un rôle E(ntité) ← A(ssociation) est évidente, du fait de lanature différente des deux extrémités E et A : type d'entité et type d'association. Dans le schéma en réseau, cen'est plus le cas et l'orientation de la liaison est indiquée au moyen des connectivités.

1 Nous verrons plus loin l'utilité de définir des sous-schémas arborescents, dans lesquels tout enfant possèdeun seul parent.

Page 86: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-8

La connectivité [min..max] mentionnée à chaque extrémité de l'arc représentant un type de liaison indique àcombien d'occurrences d'enregistrements de cette extrémité est relié chaque enregistrement du type situé àl'extrémité opposée.

Voici les conventions graphiques, d'usage fort répandu, de la méthode Information Engineering :

– le nombre 0 est représenté par un cercle O (omis par plusieurs représentations parce que pris pour valeur minimale par défaut)– le nombre 1 est représenté par un trait |– le nombre N est représenté par une fourche /|\

CLIENT

n° client

nom client

adresse client

ABONNEMENT

¥ n° client

type prospectus

REPRESENTANT

nom représentant

région

chiffre d'affairesCOMMANDE

n° commande

date commande

¥ n° client

FACTURE

n° facture

¥ n° commande

date facture

total facturé

LIGNE COMMANDE

¥ n° commande

¥ n° produit

quantité commandée

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

CL.PRIVE

¥ n° client

CL.PROFESSIONNEL

¥ n° client

n° T VA

¥ nom représentant

passant

objet

comprenant

commandé

comprenant

facturé

contactant

est

est

abonné

Sur une liaison, le losange ♦ est placé du côté du type membre.Le préfixe ¥ signale un identifiant étranger.

La connectivité 1:1 attachée au propriétaire d'une liaison obligatoire est parfois laissée à l’état implicite.

c) Interprétation d'une liaison comme étant une association

Bien qu'il ne soit pas issu d'un type d'association du schéma Entité–Association, mais d'un rôle, un type deliaison peut être regardé comme un type d'association qui possède les propriétés suivantes :1

– une liaison est une association sans attributs;– un type de liaison est binaire, c'est-à-dire de degré 2 (un type de liaison peut être cyclique);– une liaison est asymétrique : sa représentation est celle d'un rôle orienté E(ntité) ← A(ssociation);

1 Historiquement, c'est pour généraliser le concept d'association, en supprimant les restrictions qui lui sontimposées ici, qu'ont été développés les modèles Entité–Association étudiés au chapitre précédent.

Page 87: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-9

– une liaison est fonctionnelle, en ce sens que chaque occurrence d'une liaison E ← A met en correspondanceune occurrence de E et un nombre quelconque d'occurrences de A, nombre décrit par la connectivité héritéedu schéma conceptuel.1

REMARQUE. Dessinant les associations binaires sous la forme d'un simple trait, le formalisme des diagram-mes de classes en UML peut servir à la représentation d'un schéma en réseau.2

1.4. Optimisation du schéma

En vue de simplifier les séquences d'opérations d'accès qui seront nécessaires à l'exécution des traitementsinformatiques, on examinera, cas par cas, l'opportunité d'effectuer d'autres transformations qui auront poureffet de construire des types d'enregistrements plus agrégés. Ces transformations sont l'inverse de certainestransformations — sous-typage et normalisation — effectuées lors de la validation du schéma conceptuel.Cependant, le détour n'est sans doute pas inutile : les désagrégations préalablement opérées sur le schémaconceptuel, qui avaient pour ambition d'aider l'analyste à affiner et préciser sa perception de la réalité, garan-tissent que les agrégats réintroduits ici ne sont pas des erreurs dues à un défaut d'analyse.

Chaque optimisation effectuée entraîne l'obligation de formuler — et, plus tard, de programmer — de nouvel-les règles ou contraintes d'intégrité.

a) Généralisation

On peut fusionner les types d'enregistrements unis par une liaison de connectivité 0:1. Dans la plupart descas, cette transformation concerne des liaisons de sous-typage et constitue une généralisation, inverse del'opération de spécialisation (ex.: fusion des deux sous-types de clients dans le sur-type CLIENT).

Les attributs à l'origine attachés au membre d'un telle liaison sont incorporés au propriétaire, où ils peuventprendre la valeur "inexistant"; cette nouvelle contrainte doit être notée dans une règle. De plus, les connecti-vités de toutes les liaisons qui impliquaient le type d'enregistrement (membre) disparu sont modifiées : laconnectivité minimale décrivant la participation de tout type d'enregistrement lié au membre disparu est rame-née à 0 — la condition de rattachement doit également être notée dans une règle. En d'autres termes :

– toute liaison dont le type d'enregistrement disparu (ex.: CLIENT-PROFESSIONNEL) était membre de-vient facultative, ce qui équivaut à dire que la participation du propriétaire (ex.: REPRESENTANT) à unetelle liaison devient facultative (connectivité 0:1 plutôt que 1:1);– dans toute liaison dont le type d'enregistrement disparu (ex.: CLIENT-PRIVE) était propriétaire, la parti-cipation du membre (ex.: ABONNEMENT) devient facultative, avec une connectivité 0:N au lieu de 1:N.

1 Dans le modèle de BACHMAN-CODASYL, la connectivité du membre est toujours 0:N. Une autreconnectivité (1:N, 0:1) doit être garantie par programme.2 Cf. chapitre 3.

Page 88: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-10

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

¥ nom représentant

ABONNEMENT

¥ n° client

type prospectus

REPRESENTANT

nom représentant

région

chiffre d'affaires

abonné

contactant

Remarque. Dans le type d'enregistrement résultant d'une telle fusion, on incorpore souvent un attribut redon-dant, un indicateur de catégorie, signalant "rapidement" à quel(s) sous-type(s) appartient chaque occurrence.Un tel attribut est qualifié de discriminant.

En réduisant les nombres d'enregistrements et de liaisons, le procédé de généralisation réduit la complexité dela base de données.

b) Dénormalisation

On peut réintroduire dans le schéma une certaine redondance, en procédant à des dénormalisations, dont lesdifférentes formes sont décrites ci-après.

Ces optimisations ont pour but de simplifier et accélérer les opérations de consultation dans la base de don-nées. Mais elles compliquent les opérations de mise à jour.

Propagation parent ==> enfants

La dénormalisation la plus fréquente consiste à copier dans l'enregistrement membre (ou enfant) d'une liaisonun attribut non identifiant de l'enregistrement propriétaire (ou parent).

Les exemples suivants pourraient se justifier.

Une firme doit facturer ses livraisons, généralement effectuées au bout d'un délai, au tarif en application à ladate de commande. Le fait de recopier dans l'enregistrement LIGNE-COMMANDE le prix-de-vente du tarifen vigueur à la date de passation de la commande peut entraîner l'économie d'une gestion historique des ta-rifs.

En recopiant dans l'enregistrement FACTURE l'identifiant étranger "numéro de client" pris dans l'enregis-trement COMMANDE, on crée une liaison directe CLIENT ← FACTURE, économisant le détour par lacommande : le grand-parent peut être consulté sans détour par le parent.

Page 89: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-11

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

¥ nom représentant

ABONNEMENT

¥ n° clienttype prospectus

REPRESENTANT

nom représentant

région

chiffre d'affaires

COMMANDE

n° commande

date commande

¥ n° client

FACTURE

n° facture

date facture

total facturé

¥ n° commande

¥ n° client

LIGNE COMMANDE

¥ n° commande

¥ n° produit

quantité commandée

prix de vente

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

passant

objet

comprenant

commandé

comprenant

facturé

abonné

contactant

Soit δ la donnée copiée du parent dans l'enfant. Toute modification de δ dans un enregistrement parent doitêtre propagée, c'est-à-dire répétée, dans les enregistrements enfants (généralement multiples !). Dans les en-registrements enfants, l'attribut δ doit être non modifiable, sauf par l'opération précédente.

Dérivation parent(s) ==> enfants

Le mécanisme de propagation est en réalité une forme simplifiée de dérivation, méthode par laquelle la valeurd'un attribut dans un enregistrement enfant est obtenue (calculée) à partir de celle d'autres attributs dans unou plusieurs enregistrements parents.

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

facturé

Page 90: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-12

Les remarques faites ci-dessus au sujet du cas particulier de la propagation sont applicables au cas général dela dérivation.

Récapitulation enfants ==> parent

A un enregistrement parent, on peut incorporer un attribut dérivable à partir de valeurs contenues dans l'en-semble des enregistrements enfants.

FACTURE

n° facture

date facture

total facturé

¥ n° commande

¥ n° client

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

comprenant

Soit Σ la donnée calculable dans l'enregistrement parent et δ la donnée considérée dans l'enregistrement en-fant. Toute modification de δ dans un enregistrement enfant doit entraîner un nouveau calcul de Σ dans l'en-registrement parent. Dans l'enregistrement parent, Σ est un attribut non modifiable, sauf par l'opération précé-dente.

Deux types d'algorithmes sont à envisager pour recalculer Σ.

– Si tous les enfants d'un même enregistrement parent sont créés ou modifiés en une seule transaction, lesvaleurs δ peuvent être cumulées en mémoire centrale, et un seul accès à l'enregistrement parent est effectué aumoment de conclure la transaction.

– Dans le cas où les différents enfants sont créés ou mis à jour à des époques dispersées, toute mise à jourd'un enregistrement enfant s'accompagne d'un accès à l'enregistrement parent pour ajuster la valeur de Σ.

Fusion des enregistrements parent et enfants

On pourrait aussi envisager d'incorporer les enregistrements membres d'une liaison à l'enregistrement proprié-taire de cette liaison, faisant ainsi disparaître la liaison. Par exemple : fusionner en un seul les enregistre-ments COMMANDE et LIGNE-COMMANDE. Les membres de la liaison deviennent des attributs répétitifs.Ce procédé ne respecte pas la 1ère forme normale définie par CODD, et présente deux inconvénients : l'impos-sibilité habituelle de définir un nombre fixe d'occurrences dans le vecteur d'attributs répétitifs et l'impossibilitéde créer une base de données relationnelle et manipulable par les langages de requêtes.

1.5. Structures particulières

a) Enregistrement d'intersection

Un enregistrement d'intersection est la traduction d'une association sans attributs, dont tous les rôles ont laconnectivité maximale N. Les seuls champs présents dans un tel enregistrement sont les identifiants (étran-gers) des enregistrements auxquels il est lié.

Exemple : une école est abonnée à différentes revues; une liste de diffusion mentionne les professeurs à quiles revues doivent être communiquées en lecture.

Page 91: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-13

Ent/Ass

REVUEDIFFUSION

PROFESSEURtransmise lecteurt it re nom

0,N 0,N

UML

REVUE DIFFUSION PROFESSEURtransmise lecteurt it re nom0..* 0..*

IEM

REVUE

titre

DIFFUSION

¥ nom lecteur

¥ titre revue

PROFESSEUR

nom

transmise lecteur

b) Liaison cyclique

Une liaison peut être cyclique, c'est-à-dire définie sur un seul type d'enregistrement.

Soit le schéma Entité–Association suivant :

SOCIETEraison socialesiège social

DEPENDANCE

mère

filiale

0,N

0,1

Après incorporation des identifiants étrangers, l'association cyclique de DEPENDANCE prend la forme d'unenregistrement d'intersection :

SOCIETE

raison sociale

siège social

DEPENDANCE

¥ raison sociale filiale

¥ raison sociale mère

mère

filiale

Après fusion du membre DEPENDANCE, de connectivité 0:1, dans le type propriétaire FILIALE, le schémamontre une liaison facultative :1

SOCIETE

raison sociale

siège social

¥ [raison sociale mère]

mère

1 Dans le modèle CODASYL, cette transformation n'est pas possible, car ce modèle n'admet pas les types deliaisons cycliques.

Page 92: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-14

1.6. Contraintes d'intégrité

a) Reformulation des règles

Non seulement les dénormalisations impliquent la définition de nouvelles contraintes d’intégrité, mais les rè-gles (contraintes d'intégrité) déjà formulées dans le contexte du schéma Entité–Association doivent recevoirune nouvelle formulation qui tienne compte des autres modifications apportées au schéma.

On notera d'abord que les contraintes exprimées par rapport aux rôles dans le schéma Entité–Association s'ap-pliquent automatiquement aux types de liaisons qui en dérivent.

Soit la règle : date-facture de FACTURATION ≥ date-commande de PASSATION pour COMMANDE passéeet facturée dans FACTURATION. Lors de la transformation du schéma, les associations PASSATION etFACTURATION ont été incorporées aux enregistrements COMMANDE et FACTURE; ce faisant, les rôlesCOMMANDE passée et FACTURE émise ont disparu. Les adaptations suivantes doivent être apportées dansle système de règles associé au schéma :

– redéfinir comme une variable intermédiaire tout type d'objet disparu par absorption (l'expression de défi-nition sera une projection, c'est-à-dire une sous-liste d'attributs, dans le type absorbant) :

soit PASSATION = ( date-de-commande ) de COMMANDE ;soit FACTURATION = ( date-de-facture ) de FACTURE ;

– dans l'énoncé des règles, supprimer toute mention des rôles disparus par suite d'absorption :

date-de-facture de FACTURATION ≥ date-de-commande de PASSATION

b) Relaxation des contraintes de connectivité 1:N

Prenons l'exemple de la liaison unissant les enregistrements COMMANDE et LIGNE-COMMANDE.

COMMANDE

n° commande

date commande

¥ n° client

LIGNE COMMANDE

¥ n° commande

¥ n° produit

quantité commandée

comprenant

Aux deux extrémités de la liaison, les connectivités minimales sont 1 (1:1 et 1:N). Cette contrainte signifiequ'aucune LIGNE-COMMANDE ne peut être enregistrée si elle ne peut être reliée à une COMMANDE pré-existante et qu'aucune COMMANDE ne peut être acceptée si elle ne peut être reliée à au moins une LIGNE-COMMANDE préexistante. On tolérera cependant que, pour la durée des opérations d'enregistrement seule-ment — ce qu'on appelle une transaction —, cette contrainte soit violée, sans quoi il serait impossible d'enre-gistrer un bon de commande.

Dans de très nombreux cas, on devra cependant accepter que l'enregistrement du propriétaire d'une liaison soiteffectué antérieurement à l'enregistrement des membres de cette liaison. Il est alors nécessaire de relaxer lacontrainte, en transformant la connectivité 1:N en 0:N.

Page 93: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-15

c) Intégrité des références

Définition

Soit le type de liaison E–propriétaire ← A–membre. On dit que, dans les occurrences A–membres, un identi-fiant étranger fait référence à l'occurrence E–propriétaire.

La contrainte d'intégrité référentielle impose que la valeur de tout identifiant étranger dans le type A–membreexiste parmi les identifiants du type E–propriétaire.1 Cette contrainte doit être respectée pour tout type deliaison obligatoire.

Elle ne s'applique pas à un type de liaison facultative; dans ce cas, l'identifiant étranger peut posséder la va-leur "inexistant".

Création du propriétaire d'une liaison

Le propriétaire d'une liaison obligatoire doit être enregistré avant les membres de cette liaison (ou au coursde la même transaction — cf. paragraphe précédent).

Dans le cas d'une liaison facultative, l'enregistrement du propriétaire peut être postérieur à celui du membre;mais, alors, le membre doit être "rattaché" à son nouveau propriétaire.

Suppression du propriétaire d'une liaison

Que faire des occurrences A–membres liées à une occurrence E–propriétaire que l'on désire supprimer ?

Dans le cas d'une liaison facultative, la suppression de l'occurrence E–propriétaire est autorisée; les identi-fiants étrangers dans les occurrences A–membres sont considérés comme possédant une valeur "inexistant".

Dans le cas d'une liaison obligatoire et si l'ensemble des membres n'est pas vide (il existe au moins une oc-currence de A), une règle particulière doit être fournie :

– ou bien la suppression de l'occurrence E–propriétaire doit être refusée — son autorisation est "limitée"("restricted") au cas où l'ensemble des A–membres est vide,– ou bien les occurrences A–membres liées doivent également être supprimées — cette règle est récursive :elle se propage "en cascade" sur les ensembles dont chaque occurrence A est propriétaire, etc.

Exemple : toute LIGNE-COMMANDE est membre de deux liaisons obligatoires :COMMANDE 1:1 ← 1:N LIGNE-COMMANDEPRODUIT 1:1 ← 0:N LIGNE-COMMANDE

– si on supprime le propriétaire COMMANDE, on doit, au cours de la même transaction,supprimer en cascade les membres LIGNE-COMMANDE;– l'autorisation de supprimer un PRODUIT est limitée au cas des PRODUITsqui ne sont référencés par aucune LIGNE-COMMANDE.

1 L'ensemble des occurrences d'identifiants du type propriétaire constitue en quelque sorte un domaine dyna-mique dans lequel l'attribut identifiant étranger prend ses valeurs.

Page 94: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-16

2. Préparation du schéma physique

2.1. Schéma des fonctions d'accès

a) Introduction

Qu'il prenne la forme d'une base de données intégrée ou celle d'un ensemble de fichiers spécialisés, un systèmephysique de stockage des données doit permettre d'accéder facilement et économiquement aux différentesdonnées (concrètement : au différents enregistrements). Il le fait en incluant divers dispositifs techniquesaccélérateurs, par exemple :

– la contiguïté des enregistrements rendant immédiat l'accès à l'enregistrement "suivant" (cette tech-nique est la seule disponible sur une bande magnétique);– le placement de chaque enregistrement à une adresse calculée à partir de la valeur d'un identifiant,assurant un accès sélectif immédiat à l'enregistrement en question;– la constitution de répertoires ou d'index accélérant la recherche;– etc.1

Un schéma logique n'est pas un schéma physique ... La définition logique des types d'objets stockés ne précisedonc pas les formes matérielles de ces objets (par exemple, elle ne signale pas l'ordre des champs dans l'es-pace de l'enregistrement); elle ne définit pas non plus les techniques d'accès à mettre en œuvre. Mais elle doitidentifier les opérations d'accès qu'il est nécessaire de rendre possibles.

La mise en évidence des fonctions d'accès découle de l'analyse générale des opérations et algorithmes dusystème informatique à mettre en place; en d'autres termes, elle s'inscrit dans l'analyse de l'applicationqui sera insérée dans le domaine décrit par la modélisation préalable des données. Elle s'effectue donclors d'une seconde phase de l'analyse.

b) Préliminaire : le concept d'ensemble selon CODASYL

Dans les bases de données CODASYL, un ensemble est la réalisation d'une (occurrence de) liaison. Soit untype de liaison E–propriétaire ← A–membre. Une occurrence e du type d'enregistrement E est propriétaired'un ensemble {ai} dont les membres ou éléments sont les occurrences de A liées à e. L'ensemble {ai} peutcontenir un nombre quelconque d'éléments ou membres, c'est-à-dire d'occurrences de A, y compris 1 ou 0(ensemble singleton ou vide).

Pour être accessible, tout enregistrement d'un type quelconque doit, à tout moment, être membre d'au moins unensemble. Tout type d'enregistrement doit donc être membre d'au moins un type de liaison obligatoire. Pourque la chose soit possible, un type d'enregistrement fictif SYSTEM, contenant une seule occurrence, est im-plicitement défini dans tout schéma. L'enregistrement SYSTEM n'est membre d'aucune liaison (il est doncinaccessible). Il peut être déclaré propriétaire de liaisons définies vers chacun des types d'enregistrementsexistants; la chose est en tout cas nécessaire pour les types qui ne sont membres d'aucune liaison obligatoire.

1 Cf. A. CLARINVAL : Exploitation et Organisation des Fichiers, 2e partie.

Page 95: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-17

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

¥ nom représentant

ABONNEMENT

¥ n° client

type prospectus

REPRESENTANT

nom représentant

région

chiffre d'affaires

COMMANDE

n° commande

date commande

¥ n° client

FACTURE

n° facture

date facture

total facturé

¥ n° commande

¥ n° client

LIGNE

¥ n° commande

¥ n° produit

quantité commandée

prix de vente

LIGNE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

SYSTEM passant

objet

comprenantcommandé

comprenant

facturé

abonné

contactant

c) Définition des méthodes d'accès 1

Clé d'accès

Une clé d'accès est une méthode permettant de sélectionner des sous-ensembles d'occurrences d'un type d'en-registrement donné. Un identifiant est un cas particulier de clé d'accès, qui permet de sélectionner un sous-ensemble singleton.

Mettant en œuvre la relation de dépendance fonctionnelle, une clé d'accès est formée d'un groupe de champsdéterminant le sous-ensemble sélectionné. En outre, les systèmes de stockage qui matérialisent les clés d'accèssous la forme d'index2 considèrent habituellement que tout préfixe (partie de gauche) à l'intérieur d'une cléd'accès constitue lui-même une clé d'accès; de ce fait, l'ordre existant entre les composants d'une clé d'accèsn'est pas indifférent.

Exemple : on définit sur le type d'enregistrement LIGNE-FACTUREla clé d'accès qu'est son identifiant "n° facture, n° produit",dont "n° facture" est un préfixe considéré comme clé;ci-dessous sont illustrés deux accès par clés :

1 Ce paragraphe s'inspire de J.L. HAINAUT : Conception assistée des applications informatiques : concep-tion de la base de données, Masson, 1986.2 L'indexation, technique associant à chaque valeur de clé la liste des adresses des enregistrements corres-pondants, n'est pas la seule manière de matérialiser le concept de clé d'accès. Autre technique : l'adressagecalculé transforme directement en adresses les valeurs de la clé, en leur appliquant une formule de calcul.

Page 96: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-18

clé ➙➙➙➙ n° facture n° produit quantité livrée montant facturé3550 1076 1 399

3550,1210 3550 1210 10 59903550 1453 1 1219

3551 3551 1076 1 3993551 2017 2 19983551 2044 20 9980

Sur tout type d'enregistrement peuvent être définies une ou plusieurs clés d'accès. La définition de tout typed'enregistrement comportera l'identification des clés définies sur ce type.

Remarque. La plupart des clés d'accès définies dans un schéma sont des identifiants : identifiants propres(primaire et candidats) de chaque type d'enregistrement A, identifiants étrangers désignant les enregistrementsE propriétaires des liaisons dont le type A est membre.

Séquence d'accès

Une séquence d'accès est une méthode permettant, au départ d'une occurrence ai d'un type d'enregistrement,d'accéder aux autres occurrences du même type.

Entre les occurrences membres d'un ensemble est défini un ordre de succession, appelé séquence d'accès. Audépart de toute occurrence, la séquence d'accès détermine quelle est l'occurrence suivante.

Une séquence d'accès peut être

– indifférente;– l'ordre chronologique d'insertion des membres dans l'ensemble (ou l'ordre chronologique inverse,plus intéressant, comme on l'a vu, dans les ensembles historiques) ;– déterminée par une clé de tri.

Une clé de tri est une clé d'accès, dont chaque composant est muni d'un sens, "ascendant" ou "descendant",déterminant l'ordre entre les valeurs de ce composant. Fonctionnellement, l'accès est une succession d'accèspar clé utilisant les valeurs de la clé dans l'ordre défini, chacun obtenant le sous-ensemble d'occurrencescorrespondant.

Exemples : dans la liaison SYSTEM ← 0:N FACTURE,une clé de tri explicite serait "date facture descendant, n° facture ascendant"

n° facture date facture n° commande n° client total facturé3551 03/08/95 4208 125 123973552 03/08/95 4212 532 8993550 02/08/95 4211 257 7608

dans la liaison FACTURE comprenant ← 1:N LIGNE-FACTURE,une clé de tri explicite serait "n° produit ascendant".

n° facture n° produit quantité livrée montant facturé3550 1076 1 3993550 1210 10 59903550 1453 1 1219

Page 97: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-19

La définition de chaque type de liaison possédant une connectivité maximale supérieure à 1 comportera ladéfinition de la séquence d'accès applicable à l'ensemble des membres de cette liaison, si elle n'est pas indiffé-rente.

Chemin d'accès

Un chemin d'accès est une méthode permettant, au départ d'une occurrence e1 d'un type d'enregistrement E1,d'accéder aux occurrences d'un autre type E2 liées à cette occurrence e1.1

Pour tout type de liaison E–propriétaire ← A–membre déclarée, deux chemins d'accès sont possibles :

– un chemin allant du type E–propriétaire au type A–membre : dans chaque ensemble, ce chemin part del'occurrence propriétaire E et conduit à la première occurrence de l'ensemble des membres A; l'ensemble desmembres est alors parcouru selon la séquence d'accès définie sur cet ensemble; ce chemin donne un accèsexhaustif à tous les membres de l'ensemble; enfin, on retourne à l'occurrence E propriétaire (on verra plusloin l'utilité de ce retour à l'occurrence propriétaire).

E

A

e1 e2

a3a2a1

Exemple : parcours d'un ensemble FACTURE comprenant ← 1:N LIGNE-FACTURE :

FACTURE n° facture date facture n° commande n° client total facturé3550 02/08/95 4211 257 7608

LIGNE-FACT n° facture n° produit quantité livrée montant facturé3550 1076 1 3993550 1210 10 59903550 1453 1 1219

FACTURE n° facture date facture n° commande n° client total facturé3550 02/08/95 4211 257 7608

– un chemin allant du type A–membre au type E–propriétaire : dans chaque ensemble, une réalisation dece chemin unit chaque occurrence du membre A à l'occurrence propriétaire E; ce chemin donne un accès sé-lectif aux éléments du type E.

E

A

e1

a3a2a1

1 Dans la terminologie UML, on parle de sens de navigation, en disant que l'association est (une voie) "navi-gable" dans telle direction.

Page 98: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-20

Sur le diagramme, les chemins d'accès seront figurés par des flèches qui en indiqueront la direction.1

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

¥ nom représentant

ABONNEMENT

¥ n° client

type prospectus

REPRESENTANT

nom représentant

région

chiffre d'affaires

COMMANDE

n° commande

date commande

¥ n° client

FACTURE

n° facture

date facture

total facturé

¥ n° commande

¥ n° client

LIGNE COMMANDE

¥ n° commande

¥ n° produit

quantité commandée

prix de vente

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

SYSTEM passant

objet

comprenantcommandé

comprenant

facturé

abonné

contactant

2.2. Quantification du schéma

Pour opérer des choix techniques raisonnés et optimaux, la modélisation physique doit disposer de quantifica-tions.

Quantification du stockage : longueur des champs (c'est-à-dire des chaînes de caractères représentant lesvaleurs des attributs), nombre d'occurrences (ce qu'on appelle population) d'enregistrements de chaquetype.

Quantification des accès : nombre de consultations via chaque structure d'accès, nombre d'ajouts, de modi-fications et de suppressions.

Ces quantifications seront rapportées à des époques ("au départ, après un an...") ou des périodes ("par jour,par semaine, par mois..."). Les quantités indiquées seront toutes les grandeurs d'intérêt statistique : maxi-mum, mode, moyenne.

1 La même convention existe dans les diagrammes de classes d'UML.

Page 99: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-21

3. Le schéma logique des données, support de la programmation

3.1. Parcours d'un ensemble

On l'a signalé : en suivant le chemin d'accès du type E–propriétaire au type A–membre, on effectue un par-cours exhaustif de l'ensemble, qui part de l'occurrence E propriétaire et y retourne.

Dans le contexte de l'ensemble dont elle est propriétaire, les attributs de l'occurrence E propriétaire peu-vent se répartir en deux classes :

– les attributs sources, dont la valeur est indépendante du contenu de l'ensemble des membres A (tels sontnotamment les identifiants de E);– les attributs résultats (très souvent, des totaux), dont la valeur est calculée à partir de celles des membresA de l'ensemble.

Dans l'ordre chronologique, le programme accède donc :

– aux attributs sources de l'occurrence E propriétaire (ex.: date de facture),– aux occurrences des A membres (ex.: lignes de la facture),– aux attributs résultats de l'occurrence E propriétaire (ex.: total facturé).

E

A

e1S R

a3a2a1

On reconnaît la structure classique d'une boucle de programme, initialisée et clôturée.

traiter l'occurrence de E :traiter les attributs sources de Epour chaque occurrence de A

traiter l'occurrence de Afin pour chaque occurrence de Atraiter les attributs résultats de E

3.2. Sous-schéma arborescent

Un sous-schéma arborescent est une partie d'un schéma, caractérisée de la manière suivante :

– il comprend l'enregistrement fictif SYSTEM, qui en constitue la racine;– tout autre type d'enregistrement est membre d'un seul type de liaison.

Dans le schéma suivant, différents sous-schémas arborescents peuvent être définis, comme ceux qui sont iden-tifiés par les minuscules placées le long des liaisons qui les composent.

Page 100: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-22

a

a

bb

c

c

c

c

dd

e

e

e

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

¥ nom représentant

ABONNEMENT

¥ n° client

type prospectus

REPRESENTANT

nom représentant

région

chiffre d'affaires

COMMANDE

n° commande

date commande

¥ n° client

FACTURE

n° facture

date facture

total facturé

¥ n° commande

¥ n° client

LIGNE COMMANDE

¥ n° commande

¥ n° produit

quantité commandée

prix de vente

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

SYSTEM passant

objet

comprenantcommandé

comprenant

facturé

abonné

contactant

La composition d'un sous-schéma arborescent peut être définie au moyen d'une expression parenthésée de laforme : nom-de-propriétaire (ensemble-1, ensemble-2, ...)

où chaque ensemble est décrit de la manière suivante : nom-de-liaison cardinalité nom-de-membre

et où le nom de la racine SYSTEM est remplacé par le nom attribué au sous-schéma.

Exemples : les sous-schémas illustrés à la figure précédente peuvent être définis comme ceci :

a (0:N REPRESENTANT (contactant 0:N CLIENT))b (0:N CLIENT (abonné-à 0:N ABONNEMENT))c (0:N COMMANDE (comprenant 1:N LIGNE-COMMANDE, objet-de 0:1 FACTURE (comprenant 1:N LIGNE-FACTURE)))d (0:N FACTURE (comprenant 1:N LIGNE-FACTURE))e (0:N PRODUIT (commandé-par 0:N LIGNE-COMMANDE, facturé-par 0:N LIGNE-FACTURE))

Le concept de sous-schéma arborescent est important.

D'une part, la collection représentée par un sous-schéma arborescent peut être parcourue par un programmehiérarchisé sur autant de niveaux de boucles emboîtées que le sous-schéma comprend de niveaux de liaisons.

Page 101: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-23

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

pour chaque occurrence de E1(FACTURE)traiter les attributs sources de E1(FACTURE)pour chaque occurrence de E2(LIGNE-FACTURE)

traiter l'occurrence de E2(LIGNE-FACTURE)fin pour chaque occurrence de E2

traiter les attributs résultats de E1(FACTURE)fin pour chaque occurrence de E1

3.3. Transformation séquentielle des sous-schémas arborescents

a) Constitution des fichiers séquentiels

D'autre part, à la condition de scinder tout enregistrement propriétaire d'un ensemble en deux parties compre-nant, l'une les attributs sources, l'autre les attributs résultats, la collection représentée par un sous-schéma ar-borescent peut être stockée de manière linéaire, sur un imprimé ou dans un fichier séquentiel.

Il suffit pour cela de remplacer dans le programme du paragraphe précédent le verbe "traiter" par le verbe"écrire".

Exemple : pour chaque occurrence de E1(FACTURE)écrire les attributs sources de E1(FACTURE) enregistrement d'en-têtepour chaque occurrence de E2(LIGNE-FACTURE)

écrire l'occurrence de E2(LIGNE-FACTURE)fin pour chaque occurrence de E2

écrire les attributs résultats de E1(FACTURE) enregistrement récapitulatiffin pour chaque occurrence de E1

b) Cas particulier : ensembles hétérogènes

Considérons le sous-schéma arborescent :

SYSTEM ETUDIANT

RESULTAT COURS

RESULTAT EXERCICE

Il présente la particularité que le type ETUDIANT est propriétaire de plusieurs (deux) types d'ensembles.Pour la transformation séquentielle, on considérera qu'il s'agit d'un seul ensemble dont les membres sont deplusieurs types.

SYSTEM ETUDIANT RESULT. COURS ou EXERC.

Page 102: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-24

c) Syntaxe de définition

La syntaxe proposée plus haut pour la définition des sous-schémas arborescents peut aisément être étendue envue de permettre la description des particularités introduites par leur transformation séquentielle :

– deux descriptions d'ensembles séparées par "+" plutôt que par "," définissent un ensemble hétérogène;– les attributs sources et résultats du type propriétaire sont regroupés dans deux types d'enregistrements de 1:1occurrence, placés respectivement en tête et en queue de la liste.

Exemple : CLASSE (0:N ETUDIANT (1:1 fiche-ETUDIANT, 0:N RESULTAT-COURS + 0:N RESULTAT-EXERCICE, 1:1 total-ETUDIANT))

d) Contraintes particulières aux fichiers COBOL

L'organisation de fichiers la plus fréquemment utilisée en COBOL est l'organisation séquentielle indexée; ils'agit de fichiers séquentiels auxquels des clés d'accès, identifiantes ou non, sont ajoutées sous la forme d'in-dex.

Exemple COBOL : FILE-CONTROL.

SELECT Fichier-Produits ASSIGN TO ..... ORGANIZATION IS INDEXED RECORD KEY IS No-Produit OF Produit ALTERNATE RECORD KEY IS Nom-Produit OF Produit ..... .

SELECT Fichier-Commandes ASSIGN TO ..... ORGANIZATION IS INDEXED RECORD KEY IS No-Ligne OF Ligne-Commande ALTERNATE RECORD KEY IS No-Produit OF Ligne-Commande WITH DUPLICATES ..... .

FILE SECTION.

FD Fichier-Produits. 01 Produit. 02 Nom-Type PIC X(6). 02 No-Produit PIC X(6). 02 Nom-Produit PIC X(24). 02 Qte-en-Stock PIC 9(5). 02 Prix-de-Vente PIC 9(5).

FD Fichier-Commandes. 01 Commande. 02 Nom-Type PIC X(6). 02 No-Commande PIC 9(5). 02 No-Produit PIC X(6). 02 No-Client PIC X(5). 02 Date-Commande PIC 9(6). 66 No-Ligne RENAMES No-Commande OF Commande THRU No-Produit OF Commande.

Page 103: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-25

01 Ligne-Commande. 02 Nom-Type PIC X(6). 02 No-Commande PIC 9(5). 02 No-Produit PIC X(6). 02 Qte-Commandee PIC 9(5). 66 No-Ligne RENAMES No-Commande OF Ligne-Commande THRU No-Produit OF Ligne-Commande.

En COBOL, on doit tenir compte des contraintes suivantes :1

– il est obligatoire de déclarer une clé primaire identifiante (RECORD KEY); on peut déclarer un nombrequelconque d'identifiants candidats (ALTERNATE RECORD KEY) ou de clés non identifiantes (ALTER-NATE RECORD KEY WITH DUPLICATES);

– toute clé d'accès est formée d'une zone contiguë (la clause RENAMES THRU peut être employée pourdéclarer le regroupement des champs composant la clé);

– toute clé d'accès doit être déclarée de type alphanumérique (PICTURE X(n) ou déclaration assimilée);

– si le fichier contient des enregistrements de différents types, toute clé d'accès déclarée dans un type d'enre-gistrement existe automatiquement dans tous les autres types et y occupe la même position par rapport au dé-but de l'enregistrement (il est donc inutile, dans la clause SELECT, de déclarer les clés NO-LIGNE et NO-PRODUIT pour le type d'enregistrement COMMANDE; de plus, placé comme il l'est, le NO-CLIENT nepeut être indexé — car quel est le contenu des positions correspondantes dans le type d'enregistrementLIGNE-COMMANDE ?);

– deux clés différentes (NO-LIGNE et NO-PRODUIT) ne peuvent pas commencer à la même position dansl'enregistrement;

– tout préfixe d'une clé d'accès (NO-COMMANDE dans NO-LIGNE) est une clé d'accès utilisable par l'ins-truction START de positionnement dans le fichier;

– toute clé d'accès (tout index) est également une clé de tri en ordre croissant.

e) Réalisation des fonctions d'accès

Fonctions d'accès internes à un fichier séquentiel

• Chemin d'accès (Types d'enregistrements)

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

• Séquence et clé d'accès

En pratique, il est souvent indispensable de déterminer l'ordre des enregistrements dans un fichier séquentiel;il faut pour cela définir une clé de tri globale, qui, si le fichier est indexé, peut également servir de clé d'accèsidentifiante.

1 Ces contraintes sont celles de la norme COBOL publiée en 1985; la prochaine norme actuellement en prépa-ration devrait être moins restrictive.

Page 104: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-26

Soit un fichier séquentiel décrit par le sous-schéma arborescent SYSTEM(E0) ← E1 ← ... En, et Ki l'identifiantdu type d'enregistrement Ei (i > 0).

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

Exemple : sous-schéma : SYSTEM ← FACTURE ← LIGNE-FACTUREfichier : FACTURIER (0:N FACTURE comprenant (1:1 en-tête-FACTURE,

1:N LIGNE-FACTURE, 1:1 totaux-FACTURE))

Type n° facture T n° produitFACT-S 350 1 0000FACT-L 350 5 0236FACT-L 350 5 0512FACT-L 350 5 1014FACT-R 350 9 0000FACT-S 351 1 0000FACT-L 351 5 0827FACT-L 351 5 1212FACT-R 351 9 0000

Fonctions d'accès inter-fichiers

Il est fréquent que le propriétaire et les membres d'un ensemble soient répartis dans des fichiers différents.Dans les exemples ci-dessous, c'est le cas de PRODUIT ← LIGNE-COMMANDE.

• Chemin d'accès E–propriétaire →→→→ A–membre

Comment, à partir d'une occurrence du type propriétaire (PRODUIT), retrouver les occurrences (LIGNE-COMMANDE) de l'ensemble correspondant ?

L'identifiant étranger (n° produit) dans le type membre (LIGNE-COMMANDE) doit être défini comme cléd'accès, et l'on effectuera une boucle de lecture par cette clé d'accès.

Exemple COBOL : FILE-CONTROL. SELECT Fichier-Produits ASSIGN TO ..... . SELECT Fichier-Commandes ASSIGN TO ..... ORGANIZATION IS INDEXED RECORD KEY IS No-Ligne OF Ligne-Commande ALTERNATE RECORD KEY IS No-Produit OF Ligne-Commande WITH DUPLICATES ACCESS MODE IS DYNAMIC ..... .

1 Un jeu de valeurs plus étendu doit être prévu dans le cas d'un ensemble possédant des membres de plusieurstypes.

Page 105: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-27

PROCEDURE DIVISION. ..... MOVE No-Produit OF Produit TO No-Produit OF Ligne-Commande START Fichier-Commandes KEY = No-Produit OF Ligne-Commande NOT INVALID KEY READ Fichier-Commandes NEXT RECORD PERFORM UNTIL No-Produit OF Ligne-Commande NOT = No-Produit OF Produit ... traiter la ligne retrouvée ... READ Fichier-Commandes NEXT RECORD AT END MOVE HIGH-VALUE TO Ligne-Commande END-READ END-PERFORM END-START

• Chemin d'accès A–membre →→→→ E–propriétaire

Comment, à partir d'une occurrence du type membre (LIGNE-COMMANDE), retrouver l'occurrence pro-priétaire (PRODUIT) correspondante ?

L'identifiant propre (n° produit) du type propriétaire (PRODUIT) doit être défini comme clé d'accès, et l'oneffectuera une lecture sélective par cette clé d'accès.

Exemple COBOL : FILE-CONTROL. SELECT Fichier-Produits ASSIGN TO ..... ORGANIZATION IS INDEXED RECORD KEY IS No-Produit OF Produit ALTERNATE RECORD KEY IS Nom-Produit OF Produit ACCESS MODE IS DYNAMIC ..... . SELECT Fichier-Commandes ..... .

PROCEDURE DIVISION. ..... MOVE No-Produit OF Ligne-Commande TO No-Produit OF Produit READ Fichier-Produits RECORD KEY IS No-Produit OF Produits INVALID KEY ... propriétaire non trouvé ... END-READ

3.4. Méthode de construction des programmes

Différentes méthodes de construction des programmes se fondent sur l'idée que la structure des données dictela structure des programmes. Citons les Lois de Construction de Programmes de J.D. WARNIER, l'arbreprogrammatique de M.Th. BERTINI et Y. TALLINEAU et les Principles of Program Design de M. JACK-SON.1

1 J.D. WARNIER : Les procédures de traitement et leurs données, éd. d'Organisation, 1973; M.Th.BERTINI, Y. TALLINEAU : Le COBOL structuré, un modèle de programmation, éd. d'Informatique, 1974;

Page 106: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-28

La méthode esquissée ici n'est rien d'autre qu'une adaptation de celle de JACKSON au modèle logique en ré-seau. Nous allons l'exposer sur l'exemple d'un programme (très simplifié) de facturation-livraison.

a) Graphe des accès aux données

E

EE

E

SS

S

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

¥ nom représentant

COMMANDE

n° commande

date commande

¥ n° client

FACTURE

n° facture

date facture

total facturé

¥ n° commande¥ n° client

LIGNE COMMANDE

¥ n° commande

¥ n° produit

quantité commandée

prix de vente

LIGNE FACTURE

¥ n° facture

¥ n° produit

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

SYSTEMpassant

objet

comprenantcommandé

comprenant

facturé

M. JACKSON : Principles of Program Design, Academic Press, 1975. Les deux premières méthodes sontfort proches et, en dépit des apparences graphiques, identiques pour ce qui concerne la structure des pro-grammes.

Page 107: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-29

1) Etablir le sous-schéma des données utilisé par le programme.

2) Indiquer l'usage des types d'enregistrements dans le programme :

E = entrées (données lues ou reçues),S = sorties (données créées ou modifiées).

3) Définir les chemins d'accès ( →→→→ ) utilisés par le programme. On remarquera et on exploitera les pro-priétés suivantes :

– certains types d'enregistrements font l'objet d'un accès exhaustif, c'est-à-dire que chaque occur-rence de ces types est traitée une et une seule fois; l'accès à ces enregistrements se fait en emprun-tant le chemin E–propriétaire →→→→ A–membre;

Exemple : SYSTEM →→→→ COMMANDE →→→→ LIGNE-COMMANDESYSTEM →→→→ FACTURE →→→→ LIGNE-FACTURE

– d'autres types font l'objet d'un accès sélectif, c'est-à-dire que certaines occurrences ne sont pastraitées ou sont traitées plusieurs fois; l'accès à ces enregistrements (ex. : CLIENT, PRODUIT) sefait en empruntant le chemin A–membre →→→→ E–propriétaire.

4) Souligner les sous-schémas arborescents supportant un accès exhaustif E–propriétaire →→→→ A–membre.Seuls, ces sous-schémas déterminent la structure du programme.

5) Repérer sur ces sous-schémas en accès exhaustif les correspondances entre toutes les collections d'en-registrements en accès exhaustif. Sont correspondantes les collections entre lesquelles existe ou pourraitexister une liaison dont les connectivités sont 1:1 ou 0:1 et pour lesquelles les séquences d'accès sont compa-tibles.1

Exemple : COMMANDE – FACTURELIGNE-COMMANDE – LIGNE-FACTURE

b) Règles du traitement

Avant de construire le programme, on rassemblera les règles concernant tous les objets du sous-schéma.

1 On trouvera dans l'ouvrage de M. JACKSON la solution aux éventuels conflits de structures, c'est-à-dire lescas où une telle correspondance n'existe pas pour tous les types d'enregistrements en accès exhaustif.

Page 108: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-30

c) Structure du programme

La figure ci-dessous illustre la structure du programme.

������

COMMANDE FACTURECLIENT

LIGNECOMMANDE

LIGNEFACTURE

PRODUIT PRODUIT

�����

������ ���

������������������

��������� ���

����������������

����������

�����������������

��������������

!�"���������##�� �

��!

!�"���##�� �

!�"���������##�� �

��$%��

&����������'���

&�����������(���)�&����������'���

#��������������

�������������*#��������������

%!�����!�!��$+���,(��#

%!�����!�!��$+����##�� �

Le rectangle central recouvre les sous-schémas arborescents en accès exhaustif; les types d'enregistrementscorrespondants sont rapprochés en un seul point.

La partie gauche est relative aux données d'entrée et la partie droite, aux données de sortie.

Les flèches en pointillé représentent les boucles emboîtées qui constituent la structure du programme. Sur cesboucles sont réparties les opérations que le programme doit exécuter sur les données; ces opérations sontdéduites des règles rassemblées à l'étape précédente.

Sur une flèche de la partie gauche, les opérations utilisant les données sources des enregistrements propriétai-res, situés à l'origine de cette flèche; sur une flèche de la partie droite, les opérations utilisant les données ré-sultats des enregistrements propriétaires.

Noter le placement particulier des instructions READ NEXT de parcours (lecture) de la collection d'entréedéfinie par le sous-schéma en accès exhaustif : une première lecture avant toute autre opération, les suivantesen fin de toute séquence traitant une occurrence d'enregistrement. Justification : si la collection contient noccurrences, on devra effectuer n+1 lectures (n enregistrements + 1 signal de fin de fichier).

Page 109: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-31

Exemple COBOL :

IDENTIFICATION DIVISION. PROGRAM-ID. Constitution-Factures.

ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. FILE-CONTROL.

SELECT Fichier-Clients ASSIGN TO ..... INDEXED RECORD KEY IS No-Client OF Client ACCESS MODE IS DYNAMIC.

SELECT Fichier-Produits ASSIGN TO ..... INDEXED RECORD KEY IS No-Produit OF Produit ALTERNATE RECORD KEY IS Nom-Produit OF Produit ACCESS MODE IS DYNAMIC.

SELECT Fichier-Commandes ASSIGN TO ..... SEQUENTIAL.

SELECT Fichier-Factures ASSIGN TO ..... SEQUENTIAL.

FILE SECTION.

FD Fichier-Clients. 01 Client. 02 No-Client PIC X(4). 02 Nom-Client PIC X(32). 02 Adresse-Client. 03 Rue-No PIC X(32). 03 No-Postal PIC X(4). 03 Localite PIC X(24).

FD Fichier-Produits. 01 Produit. 02 No-Produit PIC X(6). 02 Nom-Produit PIC X(24). 02 Qte-en-Stock PIC 9(5). 02 Prix-de-Vente PIC 9(5).

FD Fichier-Commandes. 01 Commande. 02 Nom-Type PIC X(6). 02 No-Commande PIC 9(5). 02 No-Produit PIC X(6). 02 No-Client PIC X(5). 02 Date-Commande PIC 9(6). 66 No-Ligne RENAMES No-Commande OF Commande THRU No-Produit OF Commande. 01 Ligne-Commande. 02 Nom-Type PIC X(6). 02 No-Commande PIC 9(5). 02 No-Produit PIC X(6). 02 Qte-Commandee PIC 9(5). 66 No-Ligne RENAMES No-Commande OF Ligne-Commande THRU No-Produit OF Ligne-Commande.

Page 110: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-32

FD Fichier-Factures. 01 Tete-Facture. 02 Nom-Type PIC X(6). 02 No-Facture PIC 9(5). 02 No-Produit PIC X(6). 02 No-Commande PIC 9(5). 02 Date-Commande PIC 9(6). 02 No-Client PIC X(4). 02 Nom-Client PIC X(32). 02 Adresse-Client. 03 Rue-No PIC X(32). 03 No-Postal PIC X(4). 03 Localite PIC X(24). 02 Date-Facture PIC 9(6). 01 Ligne-Facture. 02 Nom-Type PIC X(6). 02 No-Facture PIC 9(5). 02 No-Produit PIC X(6). 02 Nom-Produit PIC X(24). 02 Prix-de-Vente PIC 9(5). 02 Qte-Livree PIC 9(5). 02 Montant PIC 9(5). 66 No-Ligne RENAMES No-Facture OF Ligne-Facture THRU No-Produit OF Ligne-Facture. 01 Fin-Facture. 02 Nom-Type PIC X(6). 02 No-Facture PIC 9(5). 02 No-Produit PIC X(6). 02 Total PIC 9(5).

WORKING-STORAGE SECTION.

01 Dernier-No-Facture PIC 9(5). 77 Total-Facture PIC 9(5).

PROCEDURE DIVISION.

Traiter-Fichier.

OPEN INPUT Fichier-Commandes Fichier-Clients I-O Fichier-Produits OUTPUT Fichier-Factures

DISPLAY "Quel fut le dernier numéro attribué ? " ACCEPT Dernier-No-Facture

PERFORM Lire-Commande PERFORM Traiter-Commande UNTIL Nom-Type OF Tete-Commande = SPACES

DISPLAY "Voici le dernier numéro attribué : " Dernier-No-Facture

CLOSE Fichier-Factures Fichier-Commandes Fichier-Produits Fichier-Clients

STOP RUN .

Page 111: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-33

Traiter-Commande.

MOVE CORRESPONDING Tete-Commande TO Tete-Facture

ADD 1 TO Dernier-No-Facture MOVE Dernier-No-Facture TO No-Facture OF Tete-Facture ACCEPT Date-Facture FROM DATE

MOVE No-Client OF Tete-Commande TO No-Client OF Client READ Fichier-Clients RECORD INVALID KEY ... client non trouvé ... END-READ MOVE CORRESPONDING Client TO Tete-Facture

MOVE "FACT-T" TO Nom-Type OF Tete-Facture WRITE Tete-Facture IN Fichier-Factures

MOVE 0 TO Total-Facture

PERFORM Lire-Commande PERFORM Traiter-Ligne UNTIL Nom-Type OF Ligne-Commande NOT = "COMM-L"

MOVE Total-Facture TO Total OF Fin-Facture

MOVE "FACT-F" TO Nom-Type OF Fin-Facture WRITE Fin-Facture IN Fichier-Factures .

Traiter-Ligne.

MOVE No-Produit OF Ligne-Commande TO No-Produit OF Produit READ Fichier-Produits RECORD KEY No-Produit OF Produit INVALID KEY ... produit non trouvé ... END-READ MOVE CORRESPONDING Produit TO Ligne-Facture

IF Qte-Commandee <= Qte-en-Stock THEN COMPUTE Qte-Livree = Qte-Commandee ELSE COMPUTE Qte-Livree = Qte-en-Stock END-IF SUBTRACT Qte-Livree FROM Qte-en-Stock

COMPUTE Montant OF Ligne-Facture = Prix-de-Vente OF Produit * Qte-Livree

ADD Montant OF Ligne-Facture TO Total-Facture

MOVE "FACT-L" TO Nom-Type OF Ligne-Facture WRITE Ligne-Facture IN Fichier-Factures

REWRITE Produit

PERFORM Lire-Commande .

Lire-Commande.

READ Fichier-Commandes NEXT RECORD AT END MOVE SPACES TO Nom-Type OF Tete-Commande END-READ .

Page 112: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma logique 4-34

Page 113: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-1

Chapitre 5. Schéma physique de la base de données

Aboutissement concret de la modélisation des données : la création d’une base de données ou d’un ensemblede fichiers.

Le schéma logique des données stockées et des fonctions d’accès doit être coulé dans les formes requises parle SGBD particulier utilisé. A cette description "programmée" des fichiers ou de la base de données, ondonne le nom de schéma physique.

Nous avons évoqué à la fin du chapitre précédent la transformation du schéma logique en schéma physiqued’un ensemble de fichiers COBOL.1 Le présent chapitre traite du schéma physique des bases de données.

Nous y décrivons sommairement les deux standards que respectent la plupart des bases de données actuelle-ment en activité : le standard CODASYL pour les bases de données en réseau et le standard SQL pour lesbases de données relationnelles. Pour l’équilibre de l’exposé, après la description du schéma proprement ditde la base de données, nous illustrons les opérations disponibles pour l’accès aux données.

Les paragraphes qui suivent ne constituent qu’une introduction aux systèmes de bases de données,bien insuffisante pour pouvoir utiliser ces systèmes.

1 Cf. chapitre 4, section 3.

Page 114: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-2

1. Les bases de données CODASYL

Les SGBD de la première génération furent conçus, autour de 1970, pour donner à des programmes d'applica-tion l'accès à des collections de données intégrées. (A l’époque, on n’imaginait pas un utilisateur devant unécran en train d’improviser une recherche dans une base de données.)

Dans ces systèmes, les opérations d'accès à la base de données portent toujours sur un seul enregistrement —on retrouve là le principe de fonctionnement traditionnel des instructions d’accès aux fichiers. Les différentsaccès doivent être combinés par les moyens propres au langage hôte (IF, PERFORM ... dans le cas deCOBOL). Le programmeur contrôle ainsi la "navigation" d'un enregistrement à l'autre dans la base de don-nées. De là vient le qualificatif "navigationnel" par lequel on caractérise souvent ces SGBD.

La vogue des SGBD relationnels a eu pour effet que les SGBD navigationnels sont passés de mode.Les SGBD navigationnels sont néanmoins encore employés sur les gros ordinateurs d’entreprisesqui furent parmi les premières à s’équiper informatiquement : banques, groupes industriels, grossesadministrations publiques ....

Nous présentons ici le modèle de SGBD standard élaboré, entre 1971 et 1978, par CODASYL ("COnferenceon DAta SYstems Languages"), l’organisme créateur du langage COBOL. Ce modèle s'appuie sur le modèledes données en réseau défini par BACHMAN dès 19631, modèle que nous avons étudié au chapitre précé-dent.

Un SGBD conforme au standard CODASYL est notamment caractérisé par l'existence de deux langages : unDDL (Data Description Language) et un DML (Data Manipulation Language).

Le DML fournit les opérations d'accès aux données. Il a été conçu comme une extension du langage COBOL.

Le DDL est utilisé par l'administrateur de la base de données (DBA) pour enregistrer dans un dictionnaireinterne à la base de données le schéma de celle-ci. Ce langage décrit à la fois la structure maillée (en réseau)de la base de données et les dispositifs techniques (index, pointeurs, etc.) supportant les fonctions d'accèssouhaitées.

Le DDL est également employé pour définir les sous-schémas (vues externes) utilisés par les différentsgroupes de programmes clients.

Les exemples donnés dans le texte ci-après sont relatifs à la base de données dont le schéma logiquea été élaboré au chapitre 4. Remarquer que les identifiants étrangers en ont été supprimés et que lesnoms de liaisons ont été rendus univoques.

1 Voir les références bibliographiques au chapitre 2.

Page 115: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-3

CLIENT

n° client

nom client

adresse client

catégorie

CL.PRIVE

CL.PROFESSIONNEL

n° TVA

PROSPECTUS

type prospectus

REPRESENTANT

nom délégué

région

chiffre d'affaires

COMMANDE

n° commande

date commande

FACTURE

n° facture

date facture

total facturé

LIGNE COMMANDE

quantité commandée

prix de vente

LIGNE FACTURE

quantité livrée

montant facturé

PRODUIT

n° produit

<1> nom produit

quantité en stock

prix de vente

SYSTEMClient-Commande

Facturation-Commande

Détail-CommandeProduit-Commande

Détail-FactureProduit-Facture

Abonnements

Contacts

Client-Facture

Clientèle

Représentation

Carnet-Commandes

Stock-Tarif

Facturier

1.1. Le langage de description de données (DDL)

a) Schéma de la base de données

Fichiers (AREA)

• Le contenu d'une base de données CODASYL est réparti dans une ou plusieurs zones (AREA), c'est-à-diredans un ou plusieurs fichiers.

Exemple : SCHEMA NAME Ventes.

AREA NAME Donnees-Permanentes. AREA NAME Donnees-EnCours. AREA NAME Donnees-Archivees.

Enregistrements (RECORD)

• Chaque type d'enregistrement est nommé et décrit dans le schéma.

• Pour chaque type d'enregistrement, la clause WITHIN areas désigne le(s) fichier(s) dans le(s)quel(s) lesoccurrences doivent être stockées.

Si les occurrences d'un même type d'enregistrement peuvent être stockées dans différentes zones, ondevra, avant de traiter une nouvelle occurrence, indiquer par une variable du programme le nom(AREA-ID) de la zone visée.

• A tout enregistrement créé dans la base de données est automatiquement attribué un identifiant interne(DATABASE KEY ou DB-KEY), qui est son adresse.

Page 116: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-4

• La clause LOCATION MODE, facultative, permet d'imposer au SGBD un mode de localisation :

– la clause LOCATION MODE is CALC USING data-items indique un adressage calculé sur labase de la clé (data-items) mentionnée — ce mode de localisation optimise l'accès par clé;– appliquée aux enregistrements membres d'un type d'ensemble, la clause LOCATION MODE isVIA set SET indique que les membres de chaque ensemble de ce type doivent être groupés à proxi-mité de l'enregistrement propriétaire — ce mode de localisation optimise l'accès par les chemins défi-nis entre le propriétaire et les membres d'un ensemble.

• La description d'un type d'enregistrement comporte la définition des champs (data-items) qui le compo-sent. Comme en COBOL, la décomposition de l'enregistrement est reflétée par des numéros de niveau et lesdonnées peuvent être structurées ou répétitives.

Exemples : RECORD NAME Ligne-Commande LOCATION MODE VIA Detail-Commande SET WITHIN Donnees-EnCours Donnees-Archivees AREA-ID Nom-Zone. 02 Qte-Commandee TYPE DECIMAL 5. 02 Prix-de-Vente TYPE DECIMAL 5.

RECORD NAME Client LOCATION MODE CALC USING No-Client DUPLICATES NOT ALLOWED WITHIN Donnees-Permanentes. 02 No-Client PICTURE "X(4)". 02 Nom-Client PICTURE "X(32)". 02 Adresse-Client. 03 Rue-No PICTURE "X(32)". 03 No-Postal PICTURE "X(4)". 03 Localite PICTURE "X(24)". 02 Categorie PICTURE "X". 02 No-TVA PICTURE "9(9)".

Ensembles (SET)

• Un ensemble (SET) regroupe un enregistrement propriétaire (OWNER) et les enregistrements membres(MEMBER) associés à cet enregistrement propriétaire par un même type de laison. Noter les particularités :

– chaque type d'ensemble est désigné dans le schéma par un nom univoque;– tout enregistrement doit être membre d'au moins un ensemble; le propriétaire de cet ensemble peutêtre l'enregistrement fictif SYSTEM;– un enregistrement ne peut être membre de plus d'un ensemble du même type;– tout ensemble est détenu par exactement un propriétaire et contient un nombre (0:N) quelconquede membres;– le propriétaire et les membres d'un ensemble ne peuvent pas être du même type; en d'autres ter-mes, les liaisons ne sont pas cycliques;– les enregistrements membres d'un ensemble peuvent être de différents types (ex.: RESULTAT-EXAMEN et RESULTAT-EXERCICES).

• La définition d'un ensemble signale si la liaison des membres au propriétaire est obligatoire (MANDA-TORY) ou facultative (OPTIONAL) et si le rattachement des membres à l'ensemble est assuré automati-quement par le SGBD (AUTOMATIC) ou "manuellement" par le programme (MANUAL). Une liaisonobligatoire implique l'automaticité du rattachement (MANDATORY AUTOMATIC); la combinaisonMANDATORY MANUAL signifie que, s'il a été inséré dans un ensemble, un enregistrement membre ne peutplus en être ôté.

Page 117: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-5

• La séquence d'accès aux membres d'un ensemble doit être pré-déterminée par la clause ORDER. Celle-cidéfinit la position d'insertion d'un nouveau membre dans l'ensemble :

– ordre chronologique (ORDER is LAST),– ordre chronologique inversé (ORDER is FIRST),– ordre défini par une clé de tri (ORDER is SORTED),– insertion devant (ORDER is PRIOR) ou derrière (ORDER is NEXT) le membre "courant" sé-lectionné par le programme.

Dans le cas d'un rangement trié, on peut demander au SGBD de construire pour chaque occurrenced'ensemble un index qui accélérera les opérations de recherche et d'insertion (ORDER is SORTEDINDEXED). Cette technique est à réserver aux ensembles contenant un grand nombre de membres,particulièrement les ensembles de premier niveau, dont l'enregistrement SYSTEM est propriétaire.

Exemples : SET NAME Detail-Commande ORDER LAST OWNER Commande MEMBER Ligne-Commande MANDATORY AUTOMATIC.

SET NAME Stock-Tarif ORDER SORTED INDEXED OWNER SYSTEM MEMBER Produit MANDATORY AUTOMATIC

ASCENDING KEY No-Produit DUPLICATES NOT ALLOWED.

SET NAME Contacts ORDER FIRST OWNER Representant MEMBER Client OPTIONAL MANUAL.

• Les chemins d'accès dans un ensemble sont matérialisés au moyen de pointeurs — un pointeur "vers" unenregistrement est une donnée interne, une DB-KEY, contenant l'adresse de cet enregistrement. Deux techni-ques sont disponibles pour l'agencement des pointeurs : les chaînages (CHAIN, option par défaut) et les ta-bleaux de pointeurs (POINTER ARRAY).

– Chaînage. L'enregistrement propriétaire d'un ensemble contient un pointeur vers le premier mem-bre de cet ensemble; chaque enregistrement membre de l'ensemble, sauf le dernier, contient unpointeur vers le membre suivant; le dernier membre contient un pointeur retournant à l'enregistre-ment propriétaire (dans le cas d'un ensemble vide, l'enregistrement propriétaire contient un pointeurvers lui-même). On peut demander d'ajouter un chaînage inverse : chaque enregistrement pointe versle précédent (LINKED TO PRIOR). Pour optimiser les accès par le chemin membre→ propriétaire,on peut également demander d'attacher à chaque membre un pointeur direct vers le propriétaire(LINKED TO OWNER).

e

a1 a2 a3LINK TO OWNER

LINK TO PRIOR

CHAIN

a4

Page 118: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-6

Exemple : SET NAME Produit-Commande MODE CHAIN ORDER LAST OWNER Produit MEMBER Ligne-Commande MANDATORY AUTOMATIC LINKED TO OWNER.

– Tableau de pointeurs. La liste des pointeurs vers les membres d'un ensemble est directement atta-chée à l'enregistrement propriétaire. De plus, comme dans l'option LINKED TO OWNER, chaquemembre contient un pointeur direct vers le propriétaire.

Clés d'accès et identifiants

La clé servant à calculer l'emplacement d'un enregistrement (clause LOCATION MODE is CALC USINGclé) et la clé de tri définie pour les membres d'un ensemble peuvent servir de clés d'accès. En outre, pourchaque type d'ensemble, on peut définir un nombre quelconque de clés pour la recherche des membres(SEARCH KEY).

L'option DUPLICATES NOT ALLOWED est employée pour rendre identifiante n'importe quelle clé d'accès.

Exemple : SET NAME Stock-Tarif ORDER SORTED INDEXED OWNER SYSTEM MEMBER Produit MANDATORY AUTOMATIC

ASCENDING KEY No-Produit DUPLICATES NOT ALLOWED SEARCH KEY Nom-Produit DUPLICATES NOT ALLOWED.

Exemple récapitulatif

SCHEMA NAME Ventes.

AREA NAME Donnees-Permanentes. AREA NAME Donnees-EnCours. AREA NAME Donnees-Archivees.

RECORD NAME Representant LOCATION MODE CALC USING Nom-Delegue DUPLICATES NOT ALLOWED WITHIN Donnees-Permanentes. 02 Nom-Delegue PICTURE "X(32)". 02 Region PICTURE "X(8)".

02 Ch-Affaires TYPE DECIMAL 9.

RECORD NAME Client LOCATION MODE CALC USING No-Client DUPLICATES NOT ALLOWED WITHIN Donnees-Permanentes. 02 No-Client PICTURE "X(4)". 02 Nom-Client PICTURE "X(32)". 02 Adresse-Client. 03 Rue-No PICTURE "X(32)". 03 No-Postal PICTURE "X(4)". 03 Localite PICTURE "X(24)". 02 Categorie PICTURE "X". 02 No-TVA PICTURE "9(9)".

Page 119: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-7

RECORD NAME Produit WITHIN Donnees-Permanentes. 02 No-Produit PICTURE "X(6)". 02 Nom-Produit PICTURE "X(24)". 02 Qte-en-Stock TYPE DECIMAL 5. 02 Prix-de-Vente TYPE DECIMAL 5.

RECORD NAME Commande LOCATION MODE CALC USING No-Commande DUPLICATES NOT ALLOWED WITHIN Donnees-EnCours Donnees-Archivees AREA-ID Nom-Zone. 02 No-Commande PICTURE "9(5)". 02 Date-Commande PICTURE "9(6)".

RECORD NAME Ligne-Commande LOCATION MODE VIA Detail-Commande SET WITHIN Donnees-EnCours Donnees-Archivees AREA-ID Nom-Zone. 02 Qte-Commandee TYPE DECIMAL 5. 02 Prix-de-Vente SOURCE Prix-de-Vente OF OWNER OF Produit-Commande.

SET NAME Representation ORDER LAST OWNER SYSTEM MEMBER Representant MANDATORY AUTOMATIC SEARCH KEY Nom-Delegue.

SET NAME Clientele ORDER SORTED INDEXED OWNER SYSTEM MEMBER Client MANDATORY AUTOMATIC ASCENDING KEY No-Client DUPLICATES NOT ALLOWED SEARCH KEY Nom-Client.

SET NAME Stock-Tarif ORDER SORTED INDEXED OWNER SYSTEM MEMBER Produit MANDATORY AUTOMATIC ASCENDING KEY No-Produit DUPLICATES NOT ALLOWED SEARCH KEY Nom-Produit DUPLICATES NOT ALLOWED.

SET NAME Carnet-Commandes ORDER FIRST OWNER SYSTEM MEMBER Commande MANDATORY AUTOMATIC.

SET NAME Contacts ORDER FIRST OWNER Representant MEMBER Client OPTIONAL MANUAL.

SET NAME Client-Commande ORDER LAST OWNER Client MEMBER Commande MANDATORY AUTOMATIC.

SET NAME Detail-Commande ORDER LAST OWNER Commande MEMBER Ligne-Commande MANDATORY AUTOMATIC.

Page 120: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-8

SET NAME Produit-Commande ORDER FIRST OWNER Produit MEMBER Ligne-Commande MANDATORY AUTOMATIC LINKED TO OWNER.

........

b) Sous-schémas

Un sous-schéma décrit la partie de la base de données accessible à un programme. Il en énumère les zones(fichiers), les types d'enregistrements, les types d'ensembles et les attributs. A l'instar du schéma dont il dé-rive, tout sous-schéma est catalogué dans le dictionnaire de la base de données.

Pour chaque type d'enregistrement défini dans le sous-schéma, une zone de mémoire tampon est réservée àl'intérieur du programme (analogie avec la FILE SECTION d'un programme COBOL).

Exemple : les lignes ci-dessous incorporent au programme COBOL la définition d'un sous-schéma

DATA DIVISION. SCHEMA SECTION. INVOKE SUB-SCHEMA Livraison-Facturation OF SCHEMA Ventes.

1.2. Le langage de manipulation des données (DML)

a) Contrôle de l'accès aux fichiers : OPEN, CLOSE

Un fichier (AREA) doit être "ouvert" pour qu'on puisse y localiser des enregistrements.

L'instruction OPEN possède différentes formes et elle permet au programme de signaler au serveur de la basede données s'il veut procéder à des mises à jour (UPDATE) ou seulement à des consultations (RETRIE-VAL); elle peut aussi demander au serveur de protéger le fichier ouvert contre tout accès concurrent émanantd'un autre programme (EXCLUSIVE) ou seulement contre les mises à jour concurrentes (PROTECTED).Après son utilisation, tout fichier doit être libéré par une instruction CLOSE.

Exemples : OPEN AREA Donnees-Permanentes USAGE-MODE PROTECTED RETRIEVAL. OPEN AREA Donnees-Archivees USAGE-MODE EXCLUSIVE UPDATE.

CLOSE ALL.

b) Les mécanismes de navigation

Enregistrements courants

Avant de pouvoir être manipulé, tout enregistrement doit être localisé, par une instruction FIND. Cette ins-truction mémorise dans différents registres l'identifiant–adresse (DB-KEY) de l'enregistrement trouvé.

Page 121: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-9

A tout moment, en effet, le SGBD conserve l'adresse (DB-KEY) du dernier enregistrement traité (trouvé ouinséré) — enregistrement qualifié de courant — dans chacune des catégories suivantes :

– dans chaque fichier (AREA) du sous-schéma,– pour chaque type d'enregistrement (RECORD) du sous-schéma,– pour chaque type d'ensemble (SET) du sous-schéma,– pour le programme (run-unit) = enregistrement courant le plus récent de tous.

A tout moment, ces registres décrivent le contexte dans lequel se déroulera l'opération suivante.

Localisation d'un enregistrement : FIND

L'instruction FIND possède de nombreuses formes. Nous en illustrons ici quelques-unes :

– localisation par la clé d'un enregistrement à adresse calculée :

exemple : * garnir la clé : ACCEPT No-Client* localiser l'enregistrement : FIND Client

– localisation du premier membre d'un ensemble :

exemple : * le Client propriétaire étant courant,* localiser la première Commande : FIND FIRST Commande OF Client-Commande SET

– localisation du membre suivant d'un ensemble :

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

– localisation du propriétaire d'un ensemble :

exemple : * une Ligne-Commande étant courante,* localiser le Produit propriétaire : FIND OWNER OF Produit-Commande SET

Test de l'appartenance d'un enregistrement à un ensemble

Il est possible de tester l'appartenance de l'enregistrement courant le plus récent à un ensemble. Cette questionest utile dans le cas des membres facultatifs.

Exemple : le Client courant est-il contacté par un représentant ?

IF RECORD [NOT] MEMBER OF Contacts THEN SET ........

Page 122: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-10

Lecture d'un enregistrement : GET

L'instruction GET transfère dans la zone de mémoire tampon accessible au programme les données de l'enre-gistrement courant le plus récent. On peut transférer toutes les données de l'enregistrement ou seulement cer-taines.

Exemple : * après avoir localisé un enregistrement Client ...* transfert du contenu intégral de l'enregistrement : GET Client* transfert de données sélectionnées : GET Client; Nom-Client Adresse-Client

c) Mise à jour des données

Création/Modification d'un enregistrement : STORE, MODIFY

Avant de stocker (STORE) un nouvel enregistrement dans la base de données, on doit :

– éventuellement, sélectionner le fichier (AREA) destinataire;– rendre courants les ensembles dans lesquels l'enregistrement doit être inséré automatiquement;– garnir les champs qui le composent avec les valeurs adéquates.

Par ailleurs, l'instruction MODIFY permet de changer la valeur des champs de l'enregistrement courant leplus récent.

Exemple : création d'une commande :

* sélectionner le fichier destinataire : MOVE "Donnees-EnCours" TO Nom-Zone* localiser le Client propriétaire : DISPLAY "n° Client : " NO ADVANCING ACCEPT No-Client FIND Client* rendre courant l'ensemble Carnet-Commandes* en localisant la Commande la plus récente* (la séquence de tri est l'ordre chronologique inversé) : FIND FIRST Commande OF Carnet-Commandes SET* prendre le dernier numéro de commande attribué : GET Commande; No-Commande* créer l'enregistrement Commande : ADD 1 TO No-Commande ACCEPT Date-Commande FROM DATE* stocker l'enregistrement Commande : STORE Commande* localiser le Produit propriétaire : DISPLAY "n° Produit : " NO ADVANCING ACCEPT No-Produit FIND Produit USING No-Produit* créer un enregistrement Ligne-Commande : DISPLAY "quantité : " NO ADVANCING ACCEPT Qte-Commandee* ajuster le stock du Produit courant : SUBTRACT Qte-Commandee FROM Qte-en-Stock MODIFY Produit; Qte-en-Stock* stocker l'enregistrement Ligne-Commande : STORE Ligne-Commande ........

Page 123: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-11

Inclusion/Retrait d'un membre dans un ensemble : INSERT, REMOVE

L'instruction INSERT insère l'enregistrement courant le plus récent dans un ensemble dont il est membre fa-cultatif (OPTIONAL) ou MANUAL. Le membre est inséré à la position déterminée par la clause ORDER.

L'instruction REMOVE enlève l'enregistrement courant le plus récent d'un ensemble dont il est membre fa-cultatif (OPTIONAL).

Exemples : STORE Client FIND Representant ..... INSERT Client INTO Contacts ........ FIND Client ..... REMOVE Client FROM Contacts

Suppression d'un enregistrement : DELETE

L'instruction DELETE supprime l'enregistrement courant le plus récent. Elle possède différentes formes :

– suppression limitée aux enregistrements qui ne sont propriétaires d'aucun ensemble,– suppression en cascade,– suppression sélective,– .....

Page 124: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-12

2. Les bases de données relationnelles

Dans les années 80, une deuxième génération de SGBD s'est imposée, au détriment des précédents. Fondéssur le modèle relationnel de CODD1, ces systèmes, aujourd’hui les plus répandus, ont l'avantage principal dedonner à l'utilisateur un langage d'interrogation déclaratif plutôt que navigationnel : l'utilisateur rédige uneexpression déclarant le résultat qu'il attend, et le SGBD lui-même en déduit l'algorithme (la séquence d'opéra-tions) à exécuter. Au contraire des instructions des langages précédents, qui manipulent toujours une occur-rence d'enregistrement, une requête relationnelle manipule des ensembles ou collections d'occurrences; dèslors, elle n'a pas pour elle-même besoin d'être "habillée" d'un programme plus étoffé. Un tel langage est prin-cipalement destiné aux utilisateurs finals d'un interpréteur de requêtes.

Le langage SQL ("Structured Query Language") est devenu le langage standard pour la gestion des bases dedonnées de ce type.

Après une présentation succincte de la théorie du modèle relationnel, nous montrerons comment, en langageSQL, la base de données est définie dans un dictionnaire de données, puis comment on la manipule.

AVERTISSEMENT

Nous avons préféré ne pas encore tenir compte des apports du paradigme Objet à la norme SQL3 (types dedonnées abstraits et sous-types, principalement). SQL3 est trop récent pour que l’usage de ses nouvelles pos-sibilités soit déjà généralisé. Et il est encore nécessaire d’expliquer comment transposer en SQL "ancien" lesspécifications de l’analyse.

2.1. Le modèle relationnel des données

En 1970, l'Américain E. CODD définissait un modèle relationnel pour la représentation (le stockage) et lamanipulation des données dans une base de données. Ce modèle constitue une véritable théorie mathémati-que, comportant principalement les aspects suivants :

– la présentation des données sous la forme de relations au sens mathématique;– une algèbre relationnelle pour leur manipulation;– une théorie de la normalisation pour leur modélisation.2

Cette théorie, non seulement fonde les SGBD qui s'en réclament expressément, mais elle inspire dorénavanttous ceux qui s'occupent de modélisation des données.

a) Les relations

Appelons domaine un ensemble de valeurs. Une relation (en anglais : "relation"3) est un sous-ensemble duproduit cartésien défini sur une liste de domaines.

1 Voir les références bibliographiques au chapitre 1.2 E. CODD : Further Normalization of the Database Relational Model in RUSTIN (ed) : Data Base Sys-tems, Prentice-Hall, 1972.3 Et non pas "relationship", que nous avons traduit par association.

Page 125: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-13

Exemple : domaines : NOM = {Citroën, Ford, Renault}NUMERO = {ABC123, ABC456, DEF123, DEF456}

produit : ABC123 CitroënABC123 FordABC123 RenaultABC456 CitroënABC456 FordABC456 RenaultDEF123 CitroënDEF123 FordDEF123 RenaultDEF456 CitroënDEF456 FordDEF456 Renault

relation A : ABC123 CitroënABC456 RenaultDEF123 Renault

relation B : ABC123 CitroënABC456 RenaultDEF456 Ford

Ainsi qu'on le voit à cet exemple, une relation se représente aisément sous la forme d'un tableau à double en-trée, auquel on a donné le nom de table.

Chaque ligne représente un n-uplet (élément) de la relation. Conformément à la théorie ensembliste, tout n-uplet de valeurs est unique dans une relation; en d'autres termes, il n'existe pas deux lignes identiques dansune table. On appelle cardinalité d'une relation le nombre de ses n-uplets.

Chaque colonne représente un attribut de la relation. Plusieurs attributs d'une relation peuvent prendre leursvaleurs dans un même domaine. On appelle degré d'une relation le nombre de ses attributs.

Exemple : domaines : NOM = {Citroën, Clio, Escort, Fiesta, Ford, Mondeo, Renault, Twingo, Visa, Xantia}NUMERO = {ABC123, ABC456, DEF123, DEF456}

relation A : ABC123 Citroën VisaABC456 Renault ClioDEF123 Renault Twingo

relation B : ABC123 Citroën XantiaABC456 Renault ClioDEF123 Ford EscortDEF456 Ford Mondeo

La définition d'un type de relation comporte les mentions suivantes :

– le nom de la relation ou nom de table,– le nom de chaque attribut ou colonne,– le nom du domaine de valeurs de chaque attribut.

Exemple : VOITURE (PLAQUE : numéro, MARQUE : nom, MODELE : nom)

Page 126: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-14

Dans une base de données relationnelle, toutes les données sont stockées dans des tables ou relations.

Exemple : le schéma logique élaboré au chapitre 4 devient :(entre crochets, un attribut pouvant prendre la valeur "inexistant")

REPRESENTANT (nom-délégué, région, chiffre-d-affaires)CLIENT (n°-client, nom-client, adresse-client, catégorie-client, [no-TVA], [nom-délégué])ABONNEMENT (n°-client, type-prospectus)PRODUIT (n°-produit, nom-produit, quantité-en-stock, prix-de-vente, taux-TVA)COMMANDE (n°-commande, n°-client, date-commande)LIGNE-COMMANDE (n°-commande, n°-produit, quantité-commandée)FACTURE (n°-facture, n°-commande, date-facture, total-facturé)LIGNE-FACTURE (n°-facture, n°-produit, quantité-livrée, montant-facturé)

dans cet exemple, on n'a pas indiqué les domaines de valeurs des attributs

Remarques

En principe, chaque type d'enregistrement défini dans le schéma logique des données deviendra, comme dansl'exemple ci-dessus, un type de relation.

Une table est assimilable à un fichier séquentiel (COBOL, par exemple) contenant des enregistrements d'unseul type.

b) Identification et Normalisation

En guise d'outils d'analyse, permettant de découvrir les types de relations à définir dans une base de données,CODD a défini (1) des règles de normalisation ou formes normales, (2) le concept de dépendance fonction-nelle sur lequel elles s'appuient, (3) un traitement mathématique de ces concepts.

Une présentation plus intuitive de ces concepts a été donnée aux chapitres 3 et 4. Nous la complétons ici dequelques remarques.

Puisque tous les n-uplets d'une relation sont différents, toute relation possède, par définition, un identifiant :elle-même. Dans la réalité, les identifiants minimaux sont habituellement réduits à quelques attributs ou co-lonnes de la table. Les liens logiques entre tables s'opèrent par le biais des identifiants étrangers importés.

Exemple : dans le schéma ci-dessus,les identifiants primaires (minimaux) sont soulignés,les identifiants étrangers sont en italiques.

Une relation est dite normalisée dès lors qu'elle se trouve en première forme normale (1NF), c'est-à-dire sitous ses attributs sont à la fois élémentaires (non structurés) et simples (non répétitifs). Cette règle doit êtreobligatoirement respectée, car elle fonde le mécanisme de désignation des attributs dans les requêtes du lan-gage relationnel : un attribut (élémentaire et simple) est complètement désigné par le seul moyen de son nomqualifié par le nom de la relation : attribut de relation (ou, en langage SQL : table.colonne).

c) L'algèbre relationnelle (pour mémoire)

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

Page 127: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-15

2.2. Le dictionnaire des données (SQL)

Le schéma de la base de données est enregistré dans un dictionnaire, que la norme SQL appelle InformationSchema. Ce dictionnaire fait partie de la base de données elle-même;1 il est consulté par l'interpréteur descommandes de manipulation des données.

Le schéma d'une base de données contient principalement la définition de domaines de valeurs, la définitiondes tables, la définition des contraintes d'intégrité, appelées assertions en SQL. Il peut aussi contenir la défi-nition de vues particulières et diversifiées sur l'une ou l'autre tables, ainsi que des procédures de mise à jourautomatique des données redondantes ou dérivables.

Remarque

Toutes les contraintes d'intégrité définies dans le schéma sont vérifiées automatiquement par leSGBD lors des opérations de mise à jour. Toute contrainte peut avoir un nom, que les messages d'er-reurs du SGBD utiliseront pour identifier chaque contrainte violée.

a) Définition des domaines

Les domaines de valeurs servent à décrire les colonnes dans les tables.

La définition d'un domaine mentionne son nom, le type de données dont il constitue un sous-ensemble, l'éven-tuelle valeur par défaut, une contrainte d'intégrité attachée au domaine.

La valeur par défaut, utilisée par le SGBD lorsque l'utilisateur crée un n-uplet sans fournir de valeur pourune colonne, doit être une constante appartenant au type indiqué ou la valeur spéciale NULL (inconnu).

Une contrainte de domaine est un prédicat quelconque restreignant l'ensemble des valeurs admises dans cedomaine : elle définit le domaine comme un sous-ensemble du type de données. A moins que soit spécifiéeune contrainte NOT NULL, tout domaine admet la valeur "inconnu".

Format : CREATE DOMAIN nom [AS] type [ DEFAULT constante ] [ [ CONSTRAINT nom_de_contrainte ] CHECK (prédicat) ] ;dans une contrainte de domaine,le mot clé VALUE représente toute valeur non NULL du domaine

Exemples : CREATE DOMAIN Code_Sexe AS CHARACTER(1) DEFAULT NULL CHECK (VALUE IN ('M', 'F'));CREATE DOMAIN Adresse_Postale AS CHARACTER(80);CREATE DOMAIN Quantite AS INTEGER DEFAULT 0;CREATE DOMAIN Prix AS NUMERIC(10) CONSTRAINT "prix non nul" CHECK (VALUE > 0);

1 La norme SQL définit elle-même les tables composant l'Information Schema d'une base de données. Exem-ples : DOMAINS, TABLES, COLUMNS, COLUMN_DOMAIN_USAGE ...

Page 128: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-16

b) Définition des tables

La définition d'une table comporte le nom de la table, la définition des colonnes, la définition des contraintespropres à cette table.

Puisque le nom d'une colonne est qualifiable par le nom de la table dont elle fait partie (table.colonne), descolonnes appartenant à différentes tables peuvent avoir le même nom. Chaque colonne est décrite par sondomaine de valeurs. Si celui-ci a été répertorié par une commande CREATE DOMAIN, il suffit d'en mention-ner le nom; sinon, la définition du domaine est faite localement.

Les contraintes qui peuvent être définies sur une table sont les suivantes :

[ CONSTRAINT nom_de_contrainte ]– PRIMARY KEY [(colonne, ...)] = identifiant primaire (automatiquement NOT NULL)– UNIQUE [(colonne, ...)] = identifiant candidat (valeurs en double interdites)– FOREIGN KEY [(colonne, ...)] ... = identifiant étranger (intégrité référentielle)– CHECK (prédicat) = restriction portant sur des colonnes de la table

Les contraintes sont définies à la suite des colonnes. Cependant, par simplification, les contraintes portant surune seule colonne peuvent être incorporées à la définition de cette colonne.

Par définition, toute table possède un identifiant primaire; si la contrainte PRIMARY KEY n'est pas exprimée,une contrainte PRIMARY KEY (toutes_les_colonnes) est implicitement définie.

Format : CREATE TABLE nom_de_table ( définition_de_colonne, ... définition_de_contrainte, ... ) ;

Exemple : le schéma donné plus haut en exemple sera créé par les commandes suivantes :

CREATE TABLE representant( nom_delegue CHARACTER(30),

region CHARACTER(12),chiffre_d_affaires Prix,CONSTRAINT "id. représentant" PRIMARY KEY (nom_delegue),CONSTRAINT "région obligatoire" CHECK (region is NOT NULL) );

CREATE TABLE client( no_client CHARACTER(5),

nom_client CHARACTER(30),adresse_client Adresse_Postale,categorie_client NUMERIC(1) DEFAULT NULL,no_TVA DECIMAL(9),nom_delegue CHARACTER(30) DEFAULT NULL,CONSTRAINT "id. client" PRIMARY KEY (no_client),CONSTRAINT "nom de client obligatoire" CHECK (nom_client IS NOT NULL),CONSTRAINT "client -> représentant" FOREIGN KEY (nom_delegue) REFERENCES representant -- Cf. note, infra ON UPDATE CASCADE ON DELETE SET NULL );

Page 129: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-17

CREATE TABLE abonnement( no_client CHARACTER(5),

type_prospectus CHARACTER(3),PRIMARY KEY (no_client, type_prospectus),FOREIGN KEY (no_client) REFERENCES client ON DELETE CASCADE );

CREATE TABLE produit( no_produit CHARACTER(6)

CONSTRAINT "id. produit" PRIMARY KEY,nom_produit CHARACTER(24) CONSTRAINT "id. (nom) produit" UNIQUE NOT NULL,quantite_en_stock Quantite CONSTRAINT "quantité en stock >= 0" CHECK (quantite_en_stock >= 0),prix_de_vente Prix,taux_TVA NUMERIC(3,3) );

CREATE TABLE commande( no_commande NUMERIC(5) PRIMARY KEY,

no_client CHARACTER(5) NOT NULL REFERENCES client,date_commande DATE DEFAULT CURRENT_DATE NOT NULL );

CREATE TABLE ligne_commande( no_commande NUMERIC(5)

REFERENCES commande ON DELETE CASCADE,no_produit CHARACTER(6) CONSTRAINT "produit commandé" -- Cf. note, infra REFERENCES produit ON UPDATE CASCADE ON DELETE NO ACTION,quantite_commandee Quantite NOT NULL CONSTRAINT "quantité commandée > 0" CHECK (quantite_commandee > 0),PRIMARY KEY (no_commande, no_produit) );

CREATE TABLE facture( no_facture NUMERIC(5) PRIMARY KEY,

no_commande NUMERIC(5) UNIQUE REFERENCES commande ON DELETE SET NULL,date_facture DATE DEFAULT CURRENT_DATE NOT NULL,total_facture Prix );

CREATE TABLE ligne_facture( no_facture NUMERIC(5)

REFERENCES facture ON DELETE CASCADE,no_produit CHARACTER(6) CONSTRAINT "produit livré" REFERENCES produit ON UPDATE CASCADE,quantite_livree Quantite NOT NULL CONSTRAINT "quantité livrée > 0"

CHECK (quantite_livree > 0),montant_facture Prix,PRIMARY KEY (no_facture, no_produit) );

Page 130: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-18

Note sur les contraintes d'intégrité référentielle

Le format complet d'une contrainte d'intégrité référentielle est le suivant :

[ CONSTRAINT nom_de_contrainte ][ FOREIGN KEY (colonne_référençante, ...) ]REFERENCES table [(colonne_référencée, ...) ] [ ON UPDATE action ] [ ON DELETE action ]

action : CASCADE | SET NULL | SET DEFAULT | NO ACTION

La clause REFERENCES mentionne les colonnes de la table référencée qui, dans l'ordre, doivent correspondreaux colonnes dont est composé l'identifiant étranger (FOREIGN KEY); dans la table référencée, les colonnesen cause doivent, dans le même ordre, former un identifiant primaire (PRIMARY KEY) ou candidat(UNIQUE). Dans le cas de l'identifiant primaire, qui est le plus fréquent, on peut omettre la liste des colonnesréférencées.

La définition d'une contrainte d'intégrité référentielle indique quelle action le SGBD doit automatiquemententreprendre sur la table référençante lorsque, dans la table référencée, l'identifiant concerné est modifié(UPDATE) ou supprimé (DELETE) :

– ON UPDATE CASCADE = remplacer toutes les références par la nouvelle valeur de l'identifiant;– ON DELETE CASCADE = supprimer en cascade toutes les occurrences référençantes;

– ON UPDATE|DELETE SET NULL = mettre les références à la valeur NULL ("inconnu");

– ON UPDATE|DELETE SET DEFAULT = donner aux colonnes référençantes leur valeur par défaut;

– ON UPDATE|DELETE NO ACTION = refuser la mise à jour de la table référencée; on obtient le même effet si l'option ON n'est pas explicitée.

c) Définition des assertions

Une assertion est une contrainte qui n'est pas attachée à une table particulière; normalement, elle impliqueplusieurs tables.

Format : CREATE ASSERTION nom_de_contrainteCHECK (prédicat) ;

Exemple : CREATE ASSERTION "commande non vide" CHECK (NOT EXISTS -- pas de no_commande sans lignes

(SELECT no_commande FROM commandeEXCEPT

SELECT DISTINCT no_commande FROM ligne_commande)) INITIALLY DEFERRED; -- Cf. note, infra

la différence (EXCEPT) entre les deux ensembles {commande.no_commande} - {ligne_commande.no_commande}doit être un ensemble vide (NOT EXISTS)

Page 131: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-19

Note sur les transactions et la vérification des contraintes

Une base de données se trouve dans un état cohérent lorsqu'elle est conforme aux contraintes d'intégrité défi-nies.

On appelle transaction une suite d'opérations de consultation et/ou mise à jour de la base de données qui,partant d'un état cohérent de celle-ci, la restitue dans un état cohérent. Entre les deux instants de début et find'une transaction, l'état de la base de données peut être non conforme. (Cette incohérence temporaire est in-dispensable pour pouvoir enregistrer l'en-tête d'une commande avant qu'existe la moindre ligne la concer-nant.)1

Exemple : INSERT INTO commande (no_commande, no_client) VALUES (315,4); -- date : DEFAULT = CURRENT_DATEINSERT INTO ligne_commande VALUES (315,7,1),

(315,8,1), (315,3,2);

COMMIT; -- confirmation clôturant la transaction -- d'enregistrement de la commande 315

La vérification d'une contrainte peut être immédiate, c'est-à-dire effectuée immédiatement avant l'exécution detoute opération de mise à jour susceptible de la violer; elle peut aussi être différée jusqu'à l'exécution de l'ins-truction COMMIT qui clôture la transaction de mise à jour. En SQL, la définition de toute contrainte peut seterminer par une option indiquant le dispositif enclenché au démarrage de toute transaction : INITIALLYIMMEDIATE (par défaut) ou INITIALLY DEFERRED.2 (La seconde option s'impose pour la contrainte"commande non vide" définie ci-dessus.)

d) Mise à jour automatique des données dérivables

Il n’est pas rare qu’une base de données contienne des données redondantes, autres que les clés étrangères.C’est le résultat des dénormalisations effectuées en vue d’optimiser l’accès aux données.3

Exemples : • propagation parent ==> enfants–– adresse du client recopiée dans l’en-tête de factureune modification d’adresse doit être répercutée dans toutes les factures du client

• dérivation parent(s) ==> enfants–– montant facturé inscrit dans chaque ligne de factureune modification de prix au tarif doit entraîner un nouveau calcul des montants facturés

1 La gestion des transactions possède une seconde utilité. Telles que nous les avons définies ici, les transac-tions garantissent la cohérence objective de la base de données; elles ne garantissent pas la cohérence de laperception qu'en ont les utilisateurs. Retenons l'hypothèse d'un accès simultané de plusieurs utilisateurs ouprogrammes à la base de données. Pendant que l'utilisateur A enregistre un bon de commande, tout autre utili-sateur B qui consulterait ou mettrait à jour les stocks, aurait en réalité accès à des informations incertaines. Lasolution consiste à limiter temporairement — jusqu'à la fin de la transaction —, et automatiquement, les pos-sibilités d'action et donc d'interférence des autres utilisateurs : inconfort momentané, mais garantie d'exacti-tude des données.2 Pour le SGBD, il est évidemment plus simple de tester une contrainte a priori et de ne pas entreprendre lamise à jour qui la violerait, que de devoir défaire une ou plusieurs opérations de mise à jour qui auraient violéune contrainte testée a posteriori. C'est pourquoi, en SQL, la vérification des contraintes est, par défaut, im-médiate.3 Cf. chapitre 4.

Page 132: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-20

• récapitulation enfant(s) ==> parent–– total facturé inscrit dans chaque facturela modification ou la suppression d’une ligne de facture implique un ajustement du total

La possibilité existe d’attacher à une opération de mise à jour une opération de mise à jour complémentairedes données dérivées, déclenchée ("triggered") automatiquement. Pour cela, on enregistre dans le diction-naire de la base de données une gâchette ("trigger").1

Format : CREATE TRIGGER nom_de_gâchette ON table événement_déclencheur actions_déclenchées ;

événement_déclencheur : avant_après opération_déclenchanteavant_après : BEFORE | AFTERopération_déclenchante : INSERT ON table |

DELETE ON table |UPDATE [ OF colonne, ... ] ON table

[ REFERENCING OLD AS alias NEW AS alias ]

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

actions_déclenchées : [ FOR EACH ROW ][ WHEN (prédicat) ] BEGIN mise_à_jour ; ... END

– Chaque opération de mise à jour est une instruction INSERT, UPDATE ou DELETE.– La condition restrictive de la clause WHEN peut préciser les cas où les mises à jour complémentaires doi-vent être déclenchées.– Par défaut, l’action déclenchée est exécutée une seule fois. L’option FOR EACH ROW ordonne de la ré-péter pour chaque ligne mise à jour par l’événement déclencheur.

Dans les exemples ci-dessous, toute mise à jour complémentaire consiste à modifier une valeur dansun n-uplet existant dans une table de la base de données :

UPDATE table SET colonne = valeur WHERE prédicat -- condition identifiant la ligne modifiée

1 La métaphore de la gâchette évoque l'enchaînement automatique des actions : pression sur la détente, per-cussion du projectile.

Page 133: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-21

Exemple : gestion automatique du total facturé

(a) définition des tables :

CREATE TABLE facture( no_facture NUMERIC(5) DEFAULT 0 -- dérivable

PRIMARY KEY,no_commande NUMERIC(5) UNIQUE REFERENCES commande ON DELETE SET NULL,date_facture DATE DEFAULT CURRENT_DATE NOT NULL,total_facture Prix DEFAULT 0 ); -- dérivable

– puisqu'ils seront dérivés automatiquement, le numéro et le total sont aussi initialisés automatiquement– pour créer l'en-tête d'une facture, il suffira de fournir le numéro de la commande

CREATE TABLE ligne_facture( no_facture NUMERIC(5)

REFERENCES facture ON DELETE CASCADE,no_produit CHARACTER(6) CONSTRAINT "produit livré" REFERENCES produit ON UPDATE CASCADE,quantite_livree Quantite NOT NULL CONSTRAINT "quantité livrée > 0"

CHECK (quantite_livree > 0),montant_facture Prix,PRIMARY KEY (no_facture, no_produit) );

– la contrainte sur le numéro de facture garantit que l'en-tête de la facture préexiste

(b) définition des mises à jour automatiques :

création de l'enregistrement Facture ==> création du numéro de facture :CREATE TRIGGER "calcul du n° de facture"

AFTER INSERT ON factureFOR EACH ROWBEGIN UPDATE facture SET no_facture = ( SELECT MAX(no_facture) FROM facture ) + 1 -- = dernier n° attribué + 1 WHERE no_facture = 0;END;

insertion de lignes dans la facture ==> calcul du total facturé :CREATE TRIGGER "création de lignes de factures"

AFTER INSERT ON ligne_factureFOR EACH ROWBEGIN UPDATE facture SET total_facture = total_facture +

ligne_facture.montant_facture WHERE facture.no_facture = ligne_facture.no_facture;END;

Page 134: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-22

modification de lignes dans la facture ==> ajustement du total facturé :CREATE TRIGGER "modification de lignes de factures"

AFTER UPDATE OF montant_facture ON ligne_facture REFERENCING OLD AS ancienFOR EACH ROWBEGIN UPDATE facture SET total_facture = total_facture + (ligne_facture.montant_facture

- ancien.montant_facture) WHERE facture.no_facture =

ligne_facture.no_facture;END;

suppression de lignes dans la facture ==> diminution du total facturé :CREATE TRIGGER "suppression de lignes de factures"

BEFORE DELETE ON ligne_factureFOR EACH ROWBEGIN UPDATE facture SET total_facture = total_facture - montant_facture WHERE facture.no_facture = ligne_facture.no_facture;END;

Des "triggers" tels que ceux-ci sont souvent présentés comme complétant les contraintes d'intégrité référen-tielle.

e) Les vues

Une vue constitue une présentation alternative d'une partie du contenu de la base de données. Pour l’utilisa-teur (ou le programme), une vue prend la forme d'une table manipulable comme n'importe quelle autre; leSGBD répercute sur les tables réelles les opérations entreprises sur une vue.

L'intérêt d'une vue est d'offrir à un utilisateur de la base de données une présentation des données adaptée à sesbesoins particuliers. Il peut aussi être de protéger la confidentialité des données, en restreignant l'accès ausous-ensemble des données présentées par une vue sur laquelle l'utilisateur possède un droit d'accès.

Format : CREATE VIEW nom_de_vue [(noms_de_colonnes)]AS sélection

Exemples : données masquées (sélection d'une partie des colonnes) :CREATE VIEW tarif AS

SELECT no_produit, nom_produit, prix_de_vente, taux_TVAFROM produit;

CREATE VIEW stock ASSELECT no_produit, quantite_en_stockFROM produit;

définition de sous-types (sélection d'une partie des lignes) :CREATE VIEW client_prive AS

SELECT * FROM clientWHERE no_TVA IS NULL;

Page 135: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-23

CREATE VIEW client_professionnel ASSELECT * FROM clientWHERE no_TVA IS NOT NULL;

Les possibilités offertes par le langage SQL en matière de définition de vues sont beaucoup plus étendues quecelles qui se trouvent illustrées dans ces exemples. Par exemple, il est possible de définir une vue embrassantun groupe de tables associées par le biais d'identifiants étrangers.

f) Création d’index

Un schéma de base de données tel que celui montré en exemple ci-dessus est opérationnel. Pourtant, il necontient aucune indication relative aux aspects matériels du stockage des données dans l'espace d'un support;il reste une définition purement conceptuelle. C'est une particularité des SGBD relationnels qu'ils puissentfonctionner sur une telle définition.

Néanmoins, si l'on veut améliorer les performances du SGBD en accélérant les opérations d'accès aux don-nées, il sera nécessaire d'établir certaines options relatives au stockage physique des données. Ces optionssont spécifiques à chaque SGBD; cependant, il existe une structure physique commune à tous les systèmes, etpourtant ignorée de la norme SQL : les index.

La fonction d'un index dans une base de données est analogue à celle d'un index dans un ouvrage imprimé.L'index d'un livre associe à chaque mot clé le numéro des pages où figure ce mot; un tel index accélère la re-cherche dans l'ouvrage, en épargnant au lecteur de devoir parcourir intégralement toutes les pages du volume.Qui plus est, le fait que l'index soit ordonné (les mots clés y sont rangés par ordre alphabétique) accélère laconsultation de l'index lui-même : cette consultation peut procéder par sauts. Une base de données est égale-ment physiquement découpée en pages, par exemple de 512 ou 1024 octets. A la demande de l'administrateurde la base de données, le SGBD peut construire un index distinct sur n'importe quelle colonne ou groupe decolonnes : à chaque valeur de cette colonne ou de cette combinaison sont associés les numéros des pages oùcette valeur est enregistrée.

L'opération principale d'un langage relationnel est la requête SELECT, sélection définie par des critères desélection. Toute colonne de toute table peut servir de critère de sélection dans une requête. Sans index, l'in-terrogation, pour établir la sélection, doit généralement examiner toutes les occurrences du critère présentesdans la base de données; cet examen peut impliquer le parcours d'un espace matériel important. Un index estun accélérateur des opérations de recherche et de tri.

Quelles tables et colonnes convient-il d'indexer ?

La collection représentée par la table doit être suffisamment importante (> 200-300 lignes ?), sansquoi l'examen séquentiel de la table est généralement plus performant.

Les colonnes indexées doivent être fréquemment citées en guise de critères de sélection ou de tri et, àla fois, s'avérer hautement discriminantes (on n'indexe pas une colonne qui ne peut prendre que 4valeurs différentes !). Tel est généralement le cas des identifiants, primaires, candidats et étrangers.

Format : CREATE [UNIQUE] INDEX nom d'indexON table (colonne, ...) ;

le qualificatif UNIQUE définit un index univoque 1

1 Avant que le langage SQL permît d'exprimer les contraintes d'intégrité, cette particularité était utilisée pourgarantir l'univocité d'un identifiant.

Page 136: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-24

Exemples : indexation des identifiants et références du schéma précédent :

CREATE UNIQUE INDEX representant_0 -- clé primaireON representant (nom_delegue);

CREATE INDEX representant_region -- clé étrangèreON representant (region);

CREATE UNIQUE INDEX client_0 -- clé primaireON client (no_client);

CREATE INDEX client_representant -- clé étrangèreON client (nom_delegue);

CREATE UNIQUE INDEX abonnement_0 -- clé primaireON abonnement (no_client, type_prospectus);

CREATE UNIQUE INDEX produit_0 -- clé primaireON produit (no_produit);

CREATE UNIQUE INDEX produit_1 -- clé étrangèreON produit (nom_produit);

CREATE UNIQUE INDEX commande_0 -- clé primaireON commande (no_commande);

CREATE INDEX commande_client -- clé étrangèreON commande (no_client);

.....

Dans une base de données relationnelle, les index sont toujours facultatifs; ils peuvent être créés (par unecommande CREATE INDEX) et supprimés (par une commande DROP INDEX) à tout moment.

2.3. La manipulation des données

a) Opérations disponibles

Consultation : SELECT

La consultation d'une base de données relationnelle procède par requêtes sélectionnant une partie des donnéesde la base. Le résultat d’une sélection est une collection de données formant elle-même une relation ou tablevirtuelle.

Le format de base d'une requête SELECT en langage SQL est le suivant :

Format : SELECT liste de données (ou *, signifiant tous les attributs)FROM liste de tables [ WHERE prédicat ]– les données affichées ou testées sont, non seulement des variables de la base de données (des colonnes), mais aussi des constantes ou des données calculées– la clause WHERE identifie par son prédicat les lignes à retenir dans la sélection

Il existe des formes de requêtes plus développées et, de plus, les résultats de plusieurs requêtes peuvent êtrecombinés, notamment par des opérateurs ensemblistes (union, intersection, différence).

Page 137: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-25

Création de lignes : INSERT

L'opération INSERT ajoute une ou plusieurs lignes dans une table. Si, pour une ligne, l'instruction ne fournitpas les valeurs de toutes les colonnes, les valeurs manquantes sont remplacées par leur valeur par défaut si onen a défini une, sinon par NULL (les contraintes définies sur la table doivent évidemment autoriser ces va-leurs NULL).

Une première forme insère une ou plusieurs lignes composées à partir de valeurs littérales, une seconde formeinsère dans la table le résultat d'une sélection.

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

INSERT INTO table [(colonne, ...)]requête_SELECT

– si l'on omet la liste de colonnes, les colonnes sont prises dans l'ordre de leur définition par CREATE TABLE– chaque ligne fournie doit comporter autant de valeurs qu'il existe de colonnes dans cette liste explicite ou implicite

Modification de lignes : UPDATE

L'opération UPDATE modifie certaines valeurs dans des lignes existantes. Les lignes à modifier sont identi-fiées par la condition formulée dans la clause WHERE; à défaut de cette clause, toutes les lignes de la tablesont modifiées.

Format : UPDATE tableSET colonne = valeur, ... (valeur ou DEFAULT ou NULL)[ WHERE prédicat ]

Suppression de lignes : DELETE

L'opération DELETE supprime certaines lignes dans une table. Les lignes à supprimer sont identifiées par lacondition formulée dans la clause WHERE; à défaut de clause WHERE, toutes les lignes de la table sont sup-primées.

Format : DELETE FROM table [ WHERE prédicat ]

Exemple : suppression d'une commande :DELETE FROM commande WHERE no_commande = 308; -- en vertu d'une contrainte REFERENCES, -- les lignes de commandes sont supprimées en cascade

b) Modes d'utilisation du langage SQL

A l'origine, le langage SQL a été conçu comme un langage interactif destiné à l'utilisateur final (utilisateurfinal mais pas profane : le langage SQL est un langage d'informaticiens).

Le langage a été adapté pour s'intégrer aux langages de programmation habituels, sous deux formes : SQLinséré ("embedded SQL") pour la rédaction de requêtes figées et prédéfinies, SQL dynamique pour la ré-daction de requêtes variables d'une exécution à l'autre du programme.

Page 138: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-26

Dans les années 1990 se sont développés différents outils d'accès aux bases de données relationnelles, qui tra-duisent leurs requêtes en SQL. Pour ces outils, SQL sert de référence. Citons les outils d'interface graphi-que qui intègrent la manipulation des bases de données à des programmes fonctionnant dans un environne-ment graphique comme, par exemple, MS-Windows. Citons également les bibliothèques de fonctionscomme ODBC ("Open Data Base Connectivity") de Microsoft, appelables par les programmes.1

c) SQL inséré

Comment un programme rédigé en COBOL ou en C, par exemple, accède-t-il à une base de données relation-nelle ? Nous nous contenterons ici de décrire la première des possibilités à avoir été offerte aux program-meurs : l’emploi d’instructions SQL insérées ou "serties" ("embedded SQL"), moyennant certains aménage-ments, dans le texte du programme. Le texte du programme est successivement analysé par deux compila-teurs : le pré-compilateur SQL puis le compilateur du langage hôte.

Repérage des instructions SQL insérées

Comment le pré-compilateur repère-t-il dans le texte les phrases SQL ? Toute instruction SQL est préfixéepar les mots EXEC SQL et se termine par un point-virgule, sauf dans un programme COBOL, où elle se ter-mine par le mot END-EXEC.2

Communication des données

Comment échanger des données entre les instructions SQL et celles du langage hôte ?

Partout où, dans une instruction SQL, peut être indiquée une valeur littérale, on peut, en lieu et place, indiquerle nom d'une variable du programme hôte; des variables du programme hôte sont également employées pourrecevoir les résultats d'une requête de sélection. Pour le distinguer des autres noms manipulés par SQL, lenom d'une variable du programme hôte est préfixé par deux points (:nom_de_variable).3

Ces données doivent, dans les deux langages SQL et hôte, être d'un type équivalent.4 De plus, dans le texte duprogramme, la déclaration des variables accessibles à SQL doit être comprise entre les deux repères EXECSQL BEGIN DECLARE SECTION et EXEC SQL END DECLARE SECTION; grâce à cette dernière conven-tion, le pré-compilateur SQL pourra prendre note du format défini pour ces données.

Signalisation des incidents

Divers moyens sont offerts au programme pour connaître les incidents éventuels ou conditions d'exception quise sont produits pendant l'exécution de chaque opération SQL. Voici le plus simple : au terme de toute exé-cution d'une instruction SQL, le programme hôte peut tester le code de retour rangé dans l'indicateur de nomSQLSTATE (cet indicateur est une variable du programme hôte).

1 Ces bibliothèques d'"Application Programming Interface" (API) fournissent des fonctions qui se substi-tuent aux clauses du langage SQL inséré. Ce nouveau procédé ne nécessite pas l'intervention d'un pré-compilateur des requêtes SQL placées dans le programme; le programme peut donc être créé — et s'exécuter— sur un ordinateur client n'ayant pas accès aux outils de développement particuliers du SGBD.2 Car, en COBOL, le point-virgule est un séparateur facultatif et sans signification.3 SQL ne pouvant ni indicer ni qualifier les noms des variables hôtes, celles-ci ne peuvent pas être membresd'une structure ou d'un tableau.4 La norme SQL définit les équivalences pour un certain nombre de langages.

Page 139: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-27

Les curseurs

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

Format : DECLARE nom_de_curseur [INSENSITIVE] [SCROLL] CURSORFOR requête [ ORDER BY { colonne [sens] } , ... ] [ FOR UPDATE [ OF (liste de colonnes) ] ]

sens : le sens du tri est indiqué par ASC(ending), par défaut, ou DESC(ending)

Le qualificatif INSENSITIVE déclare le curseur "insensible" aux mises à jour concurrentes quipourraient survenir entre les opérations OPEN et CLOSE d'ouverture et fermeture du curseur. En ré-alité, le SGBD crée une copie de la sélection opérée, et c'est à cette copie que le programme accèdepar l'opération FETCH.

L'option SCROLL définit un curseur "déroulant"; les lignes de la sélection sont numérotées (analo-gie avec un fichier relatif) et le programme peut se déplacer librement à l'intérieur de la sélection.En l'absence de cette clause, toute opération FETCH obtient la ligne suivante par rapport à la positioncourante (analogie avec un fichier séquentiel).

L'option ORDER BY permet de déterminer l'ordre de succession des lignes dans la sélection.

L'option FOR UPDATE signale que le programme est susceptible de modifier (UPDATE) ou sup-primer (DELETE) l'une ou l'autre lignes figurant dans la sélection; si l'on indique une liste de co-lonnes, la possibilité de mise à jour est limitée à ces colonnes. Par défaut, un curseur est défini FORREAD ONLY; il ne permet pas la mise à jour.

Exemple COBOL

Voici une version COBOL-SQL de référence pour le programme de facturation donné en exemple à la fin duchapitre 4.2 On remarquera que la structure du programme est inchangée; les seules différences tiennent auremplacement des instructions COBOL d’accès aux fichiers par des instructions SQL d’accès à la base dedonnées.

Une seule transaction est définie, dans laquelle on commence par dresser la liste des commandes à facturer;toutes ces commandes sont protégées contre l'accès concurrent pendant toute la durée du programme (unemise à jour des lignes de ces commandes sera également impossible, car les accès à la table Commande né-cessités par la vérification des contraintes seront refusés).

Le programme utilise deux curseurs : un curseur sur la liste des numéros des commandes à facturer et — ré-pétitivement — un curseur parcourant l’ensemble des lignes de chaque commande.

1 Une requête produisant un singleton, c'est-à-dire un ensemble d'une seule ligne, peut, plus simplement, s'ef-fectuer au moyen d'une instruction SELECT adaptée de manière à fournir une liste de variables réceptrices :SELECT liste de données INTO liste de variables FROM ..... WHERE .....2 Cf. chapitre 4, § 3.4.

Page 140: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-28

IDENTIFICATION DIVISION. PROGRAM-ID. Constitution-Factures.

WORKING-STORAGE SECTION.

EXEC SQL BEGIN DECLARE SECTION END-EXEC.

* code de retour des opérations SQL : 77 SQLSTATE PIC X(5).

* variables du programme accessibles aux opérations SQL :

77 No-Produit PIC X(6). 77 Qte-en-Stock PIC S9(5) BINARY. 77 Prix-de-Vente PIC S9(10)V99 SIGN LEADING SEPARATE.

77 No-Commande PIC S9(5) SIGN LEADING SEPARATE. 77 Qte-Commandee PIC S9(4) BINARY.

77 No-Facture PIC S9(5) SIGN LEADING SEPARATE. 77 Qte-Livree PIC S9(5) BINARY. 77 Montant-Facture PIC S9(10)V99 SIGN LEADING SEPARATE. 77 Total-Facture PIC S9(10)V99 SIGN LEADING SEPARATE.

EXEC SQL END DECLARE SECTION END-EXEC.

PROCEDURE DIVISION.

Etablir-Connexion. * opération non illustrée

Traiter-Fichier.

* définir les modalités de l'unique transaction du programme* (mise à jour = READ + WRITE,* protection contre l'accès concurrent = ISOLATION LEVEL) : EXEC SQL SET TRANSACTION READ WRITE ISOLATION LEVEL REPEATABLE READ END-EXEC

* obtenir le dernier n° de facture attribué : EXEC SQL

SELECT MAX (No_Facture) INTO :No-Facture FROM Facture END-EXEC IF SQLSTATE = "02000" THEN MOVE 0 TO No-Facture END-IF

* arrêter la liste des commandes à facturer* (retenir les No_Commande qui ne se trouvent pas encore* - EXCEPT ALL - dans la table Facture) : EXEC SQL

DECLARE Commandes_a_Facturer INSENSITIVE CURSOR FOR SELECT No_Commande FROM Commande EXCEPT ALL SELECT No_Commande FROM Facture

END-EXEC EXEC SQL OPEN Commandes_a_Facturer END-EXEC

Page 141: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-29

* établir les factures : PERFORM Lire-Commande PERFORM Traiter-Commande THRU Lire-Commande

UNTIL No-Commande = 0

* fermer le curseur et clôturer la transaction : EXEC SQL CLOSE Commandes_a_Facturer END-EXEC EXEC SQL COMMIT WORK END-EXEC

STOP RUN .

Traiter-Commande.

* initialiser la facture : ADD 1 TO No-Facture MOVE 0 TO Total-Facture

* obtenir les lignes de la commande :1

EXEC SQLDECLARE Corps_Commande CURSOR FOR SELECT No_Produit, Quantite_Commandee FROM Ligne_Commande WHERE No_Commande = :No-Commande

END-EXEC EXEC SQL OPEN Corps_Commande END-EXEC

* traiter les lignes : PERFORM Lire-Ligne PERFORM Traiter-Ligne THRU Lire-Ligne

UNTIL No-Produit = SPACES

* clôturer la facture (date par défaut = CURRENT_DATE) : EXEC SQL

INSERT INTO Facture (No_Facture, No_Commande, Total_Facture)VALUES (:No-Facture, :No-Commande, :Total-Facture)

END-EXEC

EXEC SQL CLOSE Corps_Commande END-EXEC .

Lire-Commande.

* obtenir le numéro de la commande suivante : EXEC SQL

FETCH Commandes_a_Facturer INTO :No-Commande END-EXEC IF SQLSTATE = "02000" THEN MOVE 0 TO No-Commande END-IF .

Traiter-Ligne.

* obtenir la fiche Produit : EXEC SQL

SELECT Quantite_en_Stock, Prix_de_VenteINTO :Qte-en-Stock, :Prix-de-VenteFROM Produit WHERE No_Produit = :No-Produit

END-EXEC 1 Si l’opération OPEN effectuant la sélection doit être répétée pour chaque commande à traiter, l’instructionDECLARE CURSOR définissant les modalités de la sélection pourrait n’être exécutée qu’une seule fois (ellefigurerait alors immédiatement après le commentaire "établir les factures").

Page 142: Methodes d Analyse

© A. CLARINVAL Analyse — Schéma physique 5-30

* calculer la quantite livrée : IF Qte-Commandee <= Qte-en-Stock THEN COMPUTE Qte-Livree = Qte-Commandee ELSE COMPUTE Qte-Livree = Qte-en-Stock END-IF

* modifier le stock : EXEC SQL

UPDATE ProduitSET Quantite_en_Stock = :Qte-en-Stock - :Qte-LivreeWHERE No_Produit = :No-Produit

END-EXEC

* calculer les montants de la facture (on néglige la TVA) : COMPUTE Montant-Facture = Prix-de-Vente * Qte-Livree ADD Montant-Facture TO Total-Facture

* enregistrer la Ligne de Facture : EXEC SQL

INSERT INTO Ligne_FactureVALUES (:No-Facture, :No-Produit,

:Qte-Livree, :Montant-Facture) END-EXEC .

Lire-Ligne.

EXEC SQLFETCH Corps_Commande INTO :No-Produit, :Qte-Commandee

END-EXEC IF SQLSTATE = "02000" THEN MOVE SPACES TO No-Produit END-IF .

Page 143: Methodes d Analyse

© A. CLARINVAL Analyse — Modélisation des systèmes 6-1

Chapitre 6. Introduction à la modélisation des systèmes

Un système est un objet dynamique complexe, dont on veut décrire le fonctionnement. Le concept de systèmeet la méthodologie d'analyse des systèmes sont communs à un grand nombre de disciplines; citons : la biolo-gie, les sciences de l'ingénieur, l'étude des organisations, l'informatique ... Un système est d'ailleurs sans douteplus un mode de représentation, un modèle, qu'une réalité concrète.1

Ce chapitre dresse une nomenclature des niveaux de hiérarchisation des systèmes de traitement de l’informa-tion.

Le chapitre 7 présente différentes variantes de schémas connus sous le nom générique de diagrammes de flux(de données, de signaux, d’événements ...). Ces modèles sont nés dans le contexte ancien des programmes de"traitement par lots", incapables de "converser" avec un utilisateur humain, caractéristiques des premièresréalisations de l’informatique de gestion.

Le chapitre 8 est dédié aux méthodes d’analyse nées dans le sillage de la programmation par objets. Il traited’abord brièvement de la spécification des opérations effectuées par les objets. Il s’attache ensuite à exposerle modèle des cas d’utilisation mis au point par le Suédois I. JACOBSON2 (de création plus récente, ce mo-dèle veut apporter une réponse aux problèmes de l’informatique interactive ou conversationnelle et de la pro-grammation par objets). Le chapitre se termine par quelques considérations sur la conception d’une architec-ture logicielle, illustrées par le principe d’architecture client–serveur et les patterns ou motifs architecturaux.

Les schémas décrits ici recueillent un franc succès auprès des analystes ... et de leurs clients oucommanditaires. En effet, n’utilisant pas de concepts sophistiqués que seuls des spécialistes jargon-nants seraient à même de manipuler, ils se révèlent très "parlants" pour les profanes et constituent unsupport de choix pour le dialogue de l’informaticien avec ses commanditaires.

AVERTISSEMENT. L'étude du fonctionnement des systèmes d'informations utilise des termes comme"fonction, procédure, tâche, processus" ... dont la signification est loin d'être fixée et unanimement comprise.Au contraire, chaque méthode, chaque auteur définit sa propre terminologie.

1 Cf. J.L. LE MOIGNE : La théorie du système général; Presses Universitaires de France, 1977.2 I. JACOBSON, al. : Object-Oriented Software Engineering : a Use Case Driven Approach; Addison-Wesley, 1992. I. JACOBSON, al.: Le processus unifié de développement logiciel, trad. française; Eyrolles,1999.

Page 144: Methodes d Analyse

© A. CLARINVAL Analyse — Modélisation des systèmes 6-2

1. Hiérarchisation du système d'information

Le fonctionnement d'un système de traitement de l'information est décrit en termes d'activités, ou ensemblesd'opérations, auxquels on donne le nom de processus. Afin d'en maîtriser la complexité, l'analyse des systè-mes procède par décomposition, en distinguant différents niveaux d'agrégation des opérations.

Nous distinguerons trois niveaux de processus : système, tâche, module.

1.1. Système

Un système, en particulier un système d'information, possède les propriétés dynamiques suivantes : c'est

– un ensemble permanent– d'activités récurrentes.

Beaucoup des activités récurrentes d'un système sont périodiques, c'est-à-dire qu'elles se reproduisent à desintervalles de temps déterminés.

Exemple : SYSTEME : administration des salaires : ACTIVITES : enregistrement des modifications de la situation du personnel (occasionnel)

enregistrement des prestations (quotidien) calcul et paiement des rémunérations (mensuel) établissement des attestations et documents légaux (annuel)

Appelons système le référentiel analysé; il peut être décomposé en sous-systèmes, qui possèdent eux-mêmestoutes les propriétés dynamiques d'un système; un sous-système peut être décomposé en sous-sous-systèmes,et ainsi de suite.

Dans la pratique, les critères d'individualisation d'un sous-système d'information sont principalement organi-sationnels. L'activité d'une entreprise — le système "opérant" — est organisée en grandes fonctions ou finali-tés internes : gestion de la production, gestion financière, gestion du personnel ... Chaque grande fonction sereflète dans un sous-système d'information.

Exemples : entreprise :gestion du personnel :

recrutement, formation, promotionsadministration des salaires

gestion financière :trésoreriecomptabilité :

comptabilité généralebudgetcomptabilité analytique

..........

Page 145: Methodes d Analyse

© A. CLARINVAL Analyse — Modélisation des systèmes 6-3

Au sein d'un organisme possédant différents sièges ou filiales, on distinguera un sous-système propre à cha-cune des entités ... Les sous-systèmes particuliers aux différents sièges d'un organisme sont éventuellement dumême type, c'est-à-dire qu'ils font l'objet d'une définition identique.1

1.2. Tâche

Une tâche est un ensemble d'opérations passant pour élémentaire aux yeux de l'utilisateur "client" du système,

– que cet utilisateur alimente en données et dont il attend des résultats,– au fonctionnement duquel il affecte des ressources : moment, durée, localisation, machines, personnel ...

Exemples : TACHE : enregistrement des modifications de situation du personnelDONNEES : données "familiales" communiquées par l'employé

données "professionnelles" reçues du service employeurRESULTATS : fichier signalétique mis à jourRESSOURCES : employé du service du personnel

ordinateur personnel connecté à l'ordinateur central

TACHE : calcul des rémunérationsDONNEES : fichier signalétique du personnel

prestations mensuelles enregistréesRESULTATS : fiches de paie

virements bancairesRESSOURCES : ordinateur central

entre le 5e et le 3e jours ouvrables avant fin de moisdurée estimée = 2 heures

On associe souvent la tâche à un événement déclencheur ou une combinaison d'événements déclencheurs.

Exemples : TACHE : enregistrement des modifications de situation du personnelEVENEMENTS : toute information pertinente reçue

des membres du personnelou des services employeurs

TACHE : calcul des rémunérationsEVENEMENTS : derniers jours ouvrables du mois

demande du service responsable

Une des ressources affectées à une tâche est le processeur qui l'exécute. De ce point de vue, les tâches detraitement de l'information se répartissent en :

– tâches automatiques, exécutées par un programme d'ordinateur, sans intervention humaine;– tâches "manuelles" (sic), effectuées par l'être humain sans recours à l'ordinateur;– tâches interactives, faisant dialoguer un programme d'ordinateur et un opérateur humain.

Exemples : TACHE interactive : enregistrement des modifications de situation du personnelTACHE automatique : calcul des rémunérations = établissement de la paieTACHE "manuelle" : distribution des fiches de paie

1 Rappelons que le concept de type, classe des objets vérifiant une même définition, est tout à fait général.Les objets dynamiques du traitement de l'information, dont il est question dans le présent chapitre, sont euxaussi classés par types.

Page 146: Methodes d Analyse

© A. CLARINVAL Analyse — Modélisation des systèmes 6-4

Programme

Il n'est pas rare qu'une tâche automatique, par exemple l'établissement de la paie du personnel, nécessite d'en-chaîner l'exécution de plusieurs programmes ... Une tâche interactive implique souvent la coopération dedeux programmes dans une architecture "client/serveur", un programme gérant le travail du "client" à l'écran,un autre se chargeant des accès à la base de données au "service" des différents clients; ces deux programmess'exécutent souvent sur des ordinateurs distincts : un ordinateur personnel pour le client et un ordinateur cen-tral pour le serveur ... De plus en plus souvent, un programme se présente comme une sorte de boîte à outilsdont les composants sont utilisés par des tâches diverses; tel est le cas d’un tableur, mais aussi d’un pro-gramme permettant de créer, mettre à jour, consulter et imprimer, par exemple, des fiches Clients ...

Ces exemples montrent à suffisance qu'un programme n'est qu'une des ressources affectées à l'exécution d'unetâche. (Et il existe des tâches n’utilisant pas de programmes : les tâches "manuelles".)

Objet

Au concept de programme concourant à l'exécution d'une tâche, a tendance aujourd'hui à se substituer celuid'objet programmé, capable d'effectuer certaines opérations et ainsi de rendre des "services". Un objet pro-grammé est capable de plus d'opérations qu'une tâche particulière n'en utilise (c'est pourquoi, au lieu de parlerde tâches, les méthodologies "orientées objets" parlent de cas d'utilisation1).

Tâche = Transaction

Appelons transaction une séquence d'opérations (d'un ou plusieurs acteurs, processeurs, programmes ouobjets) dont la terminaison est le minimum nécessaire pour que le traitement soit cohérent, c'est-à-direconforme aux règles établies.2 Exemples : les opérations d'enregistrement d'un bon de commande, les opéra-tions produisant l'émission d'une facture, le traitement de prise en charge d'une écriture comptable ... Les di-verses descriptions fournies par l'analyste, dont il sera question dans la suite — l'utilité fonctionnelle, les rè-gles de procédure, les liens de causalité —, concernent essentiellement les transactions. Cette observationjustifie d'assimiler la tâche à une transaction (plutôt qu'à l'exécution complète d'un ou plusieurs programmes).S'il existe des règles portant sur un ensemble de transactions élémentaires (exemple : la facturation–livraisonest quotidienne; elle traite en priorité les commandes les plus anciennes), on a affaire à une tâche comportantune hiérarchie de règles et, par conséquent, différents niveaux de transactions, élémentaires et composites.

Commentaires

Selon F. BODART et Y. PIGNEUR,3 qui disent "phase" plutôt que "tâche", "Le concept de 'phase' constituele repère central de la nomenclature par la signification qu'il présente sur trois plans d'analyse. Au planinformationnel, la phase est un lieu d'identification [...] de règles de traitement. [...] Au plan économi-que, elle est un lieu d'allocation des ressources humaines, matérielles et logicielles, nécessaires à son exécu-tion. Au plan organisationnel, elle est un lieu de redéfinition des structures d'organisation : tâches, fonc-tions, rôles, responsabilités, postes de travail. [...] La phase constitue [...] le lieu élémentaire d'analyse deschangements à apporter à un système d'information : changement des règles de mémorisation et de traite-ment, modification du comportement des personnes, changement dans les structures d'organisation, change-ment technologique."

1 I. JACOBSON, al. : op. cit.2 La notion classique de transaction sur une base de données constitue un cas particulier de la définition plusgénérale proposée ici. Cf. chapitre 5.3 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information : méthodes, modèles, outils;Masson, 1989.

Page 147: Methodes d Analyse

© A. CLARINVAL Analyse — Modélisation des systèmes 6-5

De plus, pour l'informaticien, ce niveau constitue le point d'articulation de deux méthodologies nettement dif-férentes par leurs objectifs pratiques : l'analyse interne d'une tâche doit produire une description programma-ble, tandis que l'analyse des niveaux supérieurs — système et sous-systèmes — ne doit ordinairement produireque de la documentation.

1.3. Module

Un module est un ensemble d’organes (objets) et/ou d'opérations élémentaire aux yeux du technicien créa-teur d’un système de traitement de l'information. L'exécution d'une tâche met en œuvre un ou plusieurs mo-dules et ce sont ces derniers qui, finalement, assument la responsabilité des traitements.

Un module est généralement confondu avec un composant programmable; il possède donc une forme concrèteliée aux moyens de conception et de réalisation dont disposent les programmeurs. Si, naguère, ces moyensapparaissaient uniformes — un module prenait l'aspect d'un sous-programme —, ils sont aujourd'hui trèsdivers. Cependant, ces nouvelles espèces de composants, pré-programmés ou non, se présentent habituelle-ment sous la forme d’objets plus ou moins explicitement conformes à la définition proposée par le paradigmede la programmation par objets :

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

Page 148: Methodes d Analyse

© A. CLARINVAL Analyse — Modélisation des systèmes 6-6

2. Niveaux intermédiaires

Si, parce qu'ils se rencontrent dans la réalité des systèmes de traitement de l'information, les niveaux de(dé)composition définis ci-dessus doivent se retrouver dans toute analyse, il est loisible au concepteur de dis-tinguer des niveaux intermédiaires. Ne correspondant à aucun objet précis dans la réalité, ces niveaux pure-ment artificiels sont distingués pour la commodité de la représentation mentale ou de la planification du travaild'informatisation ...

Dans le contexte des études et travaux d'informatisation, on s'attaque à un projet informatique, découpé enapplications informatiques. Un projet concerne un sous-système d'information. Une application peut recou-vrir un sous-sous-système ou apparaître plus ou moins comme un sous-ensemble artificiel, isolé pour les be-soins du travail d'informatisation.

Dans la décomposition d'un système, l'analyste peut faire apparaître des groupes de tâches entre lesquellesexistent des liens particuliers de complémentarité (ex.: ensemble des tâches composant le "traitement descommandes–clients") ou de similitude (ex.: groupe des tâches d'"édition de statistiques"). Un groupe detâches suffisamment vaste pourra être géré comme une application ...

Il est possible de définir des niveaux intermédiaires entre la tâche et le module de base; appelons composi-tions de modules ces agrégats. A part le fait qu'elle n'est pas élémentaire, semblable composition possèdetoutes les propriétés d'un module.

SYSTEMESOUS-SYSTEME projet

application

groupe de tâchesTACHE

programme composition de modules

MODULE

NOTE. Introduisant la modélisation conceptuelle des données, nous disions que l’analyste décrivait par cemoyen un domaine d’application.1 Il s’agit maintenant de décrire les applications qui seront déployées dansce domaine.

1 Cf. chapitre 3.

Page 149: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-1

Chapitre 7. Les diagrammes de flux

Outils privilégiés, les diagrammes de flux entre activités sont utilisés par toutes les méthodologies d'analysedes systèmes d'informations. Ces diagrammes possèdent de nombreuses variantes; grâce à telle ou telle parti-cularités, ils permettent à l’analyste d’étudier le système d’information sous différents angles.

Nous présentons dans ce chapitre trois formes de diagrammes de flux :

– les diagrammes de flux de données, schémas fonctionnels décrivant l’utilité des traitements;– les diagrammes d’enchaînement dynamique, qui en décrivent les contraintes (d’enchaînement);– les diagrammes de déploiement, qui mettent en évidence les ressources nécessaires à leur exécution.

Page 150: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-2

1. Schéma fonctionnel

Un objet dynamique, en particulier un système, poursuit une finalité que nous appellerons sa fonction. L'ana-lyse d'un système d'information doit expliquer comment celui-ci remplit sa triple fonction de mémoriser,transformer et diffuser de l'information. Ce comportement est défini par des règles de procédure.

Le schéma fonctionnel d'un système d'information doit en même temps maîtriser la complexité inhérente à cesystème; il fournit donc des moyens pour en décrire la structure en termes de composants plus simples. Onse sert pour cela de diagrammes de flux de données. Ces diagrammes possèdent de nombreuses variantes, etplusieurs manières de les utiliser sont préconisées. Citons, entre autres, l'école américaine de la "StructuredAnalysis", particulièrement représentée par l'équipe de YOURDON.1

1.1. Contenu d'un diagramme de flux

a) Environnement

Il est dans l'essence de l'information d'être communiquée. Un système d'information appartient donc à la caté-gorie des systèmes "ouverts", possédant un environnement avec lequel ils échangent des données. Concrè-tement, le système d'information d'une entreprise se trouve en communication avec le système opérant et lesystème de décision de cette entreprise; il réalise également des échanges avec (les systèmes d'informationde) l'environnement socio-économique de l'entreprise : clients et fournisseurs, bien sûr, mais aussi le minis-tère des finances (service de la TVA), etc ...

Quant à l'environnement d'un sous-système, il est constitué des autres sous-systèmes avec lesquels il échangede l'information; par exemple, bon nombre des sous-systèmes d'une entreprise commerciale échangent desdonnées avec le sous-système comptable de cette entreprise.

Par définition, l'environnement du système de référence n'est pas analysé; il est simplement perçu comme unensemble de processeurs ou acteurs (fournisseurs, clients, etc.) susceptibles d'activités non précisées.

Acteurexterne

Banque

Clients Fourniss.

1 C. GANE, T. SARSON : Structured Systems Analysis : tools and techniques; Prentice-Hall, 1979. T. DEMARCO : Structured Analysis and System Specification; Prentice-Hall, 1979. E. YOURDON : Mo-dern Structured Analysis; Prentice-Hall, 1989.

Page 151: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-3

b) Processus

La fonction d'un processus de traitement de l'information — système, sous-système, tâche ou module (sous-programme) — se décrit aisément comme étant une transformation de données d'entrée en données de sor-tie.1 La notion de transformation doit être entendue dans un sens large : il ne s'agit pas seulement des opéra-tions changeant la forme des données, mais également de celles qui en modifient la localisation dans l'espaceou le temps; ainsi considérera-t-on que l'enregistrement d'un changement d'adresse, c'est-à-dire la simple re-copie sur un support de la nouvelle adresse, constitue une transformation.

Exemples : SOUS-SYST. : administration des salairesFONCTION : assurer et gérer la rémunération des prestations du personnelENTREES : données signalétiques du personnel

prestationsSORTIES : rémunérations, cotisations, impôts

documents légaux

TACHE : enregistrement des modifications de situation du personnelFONCTION : enregistrer toute modification de situation

influant sur le calcul des rémunérations(= codifier et copier)

ENTREES : données "familiales" communiquées par l'employédonnées "professionnelles" reçues du service employeur

SORTIES : fichier signalétique mis à jour

TACHE : calcul des rémunérationsFONCTION : calculer les montants des rémunérations et retenues diverses

(= valoriser les prestations)éditer les documents accompagnant les paiements

ENTREES : fichier signalétique du personnelprestations mensuelles enregistrées

SORTIES : fiches de paievirements bancaires

MODULE : calcul de l'impôtFONCTION : calculer le montant de l'impôt à retenir sur le salaire mensuelENTREES : montant du salaire imposable

barèmes d'impositionSORTIES : montant de l'impôt, montant net du salaire

On a évoqué au paragraphe précédent les échanges d'un système ou sous-système, processus permanent, avecson environnement. Un processus ponctuel, tâche ou module, qui ne produirait pas de données de sortie neprésenterait aucun intérêt. En revanche, l'ensemble des données d'entrée d'un tel processus pourrait, à la limi-te, être vide (ex.: le module–fonction rand() du langage C fournissant des nombres pseudo-aléatoires).

Adoptant un vocabulaire dynamique, on dira que tout processus possède au moins un flux de données entran-tes et au moins un flux de données sortantes. Ceci peut être schématisé par une figure à laquelle on donne lenom de boîte noire (parce qu'elle cache le "comment" de la transformation).

1 Ce schéma fonctionnel est valide pour tous les systèmes, pas seulement les systèmes d'information.

Page 152: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-4

Niveau

Processus

Acteur

Entrées Sorties

Tâche

Calcul desRémunérations

Automatique

Prestationsmensuelles

Fichesde paie

Virementsbancaires

SignalétiqueTravailleurs

Nous nous intéressons dans cette partie du cours à l'ordonnancement et la spécification des tâches d'unsystème de traitement de l'information et nous n'y envisagerons le module que comme un moyen de décrireune tâche.

c) Flux de données

La description interne d'un processus non élémentaire en dévoile la structure sous la forme de sous-processusreliés par des flux de données. Le schéma de cette structure est un diagramme de flux. Par convention, tousles sous-processus recensés sur un tel diagramme sont du même niveau d'agrégation; on distingue donc desdiagrammes de flux

– entre sous-systèmes d'un même système ou d'un même sous-système hiérarchiquement supérieur,– entre tâches (singletons) ou groupes de tâches d'un même sous-système,– entre modules (singletons) ou compositions de modules dans une tâche.

Par convention, tout flux de données possède une et une seule origine, une et une seule destination, maisplusieurs flux pourraient avoir un contenu identique, c'est-à-dire véhiculer des copies des mêmes données.1

Tout flux est orienté : de son origine vers sa destination. Il se représente graphiquement par une flèche.

REMARQUE. On le verra à la lecture des exemples : les flux de données à l'intérieur du système d'informa-tion reflètent souvent, en une sorte d'"image", les flux concrets (de matières, de services ...) qui s'écoulent àl'intérieur du système opérant de l'entreprise.

Flux direct, Messages

Si la collection de données véhiculées par un flux est "consommée" par le processus récepteur; c'est-à-dire quel'utilisation des données par ce processus les prive de toute nouvelle utilité, il s'agit d'un flux direct entre deuxprocessus et la période de conservation des données véhiculées est égale à la période qui sépare l'exécutiondes deux processus émetteur et consommateur.

1 Certaines méthodes admettent les regroupements et éclatements de flux, c'est-à-dire qu'elles autorisent desflux aux origines ou destinations multiples. Le procédé présente l'inconvénient de masquer l'existence du pro-cessus qui opère le regroupement ou l'éclatement.

Page 153: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-5

GANE & SARSON DE MARCO1

Enregistr.Commandes

2

PréparationLivraisons

Réservations

Enregistr.Commandes

PréparationLivraisons

Réservations

Un flux direct peut être cyclique, c'est-à-dire qu'il relie deux exécutions successives d'un même processus :sortant de l'exécution t, entrant pour l'exécution t+1.

GANE & SARSON DE MARCO1

Enregistr.Commandes

2

PréparationLivraisons

RéservationsCommandes

différées

Enregistr.Commandes

PréparationLivraisons

RéservationsCommandes

différées

Le processus d'origine ou de destination d'un flux ne se situe pas nécessairement à l'intérieur du système analy-sé, mais parfois dans son environnement. On distingue donc des flux internes et des flux externes. Un fluxexterne est toujours représenté comme un flux direct entre un acteur externe et un processus interne,d'"enregistrement" pour les données entrantes, d'"édition" pour les données sortantes.

GANE & SARSON DE MARCO

1

Enregistr.Commandes

2

PréparationLivraisons

E-1

Clients

Bons deCommande

Factures

RéservationsCommandes

différées

Enregistr.Commandes

PréparationLivraisons

Clients

Bons deCommande

Factures

RéservationsCommandes

différées

Page 154: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-6

Les données véhiculées par un flux direct composent des messages. S'il est destiné à un acteur humain ou s'ilémane d'un tel acteur, un message prend la forme d'un document, sur papier ou sur écran ... Le contenu d’unmessage peut être décrit par un sous-schéma de données.1

Du fait de son orientation, un flux direct détermine un ordre entre les processus émetteur (antécédent) et ré-cepteur (conséquent) qu'il relie; il détermine une succession de transformations et une progression entre lesétats successifs des collections de données véhiculées. Par suite, le concept de flux direct constitue un outilprivilégié de l'analyse structurée des traitements.

Un flux reliant deux tâches est un flux réel, à la matérialisation duquel sont affectées des ressources : un sup-port de communication (papier, disquette, bande magnétique, réseau de télécommunication ...), un pointd'origine et un point de destination identifiables dans l'espace et le temps. Entre deux tâches déterminées, iln'existe normalement pas plus d'un flux de cette nature.

Les flux directs représentés entre systèmes ou sous-systèmes sont des abstractions récapitulatives d'une sommede flux réels. Il n'existe pas de normes relatives au nombre de flux directs représentés à ce niveau (il n'est eneffet pas obligatoire de récapituler en un seul agrégat abstrait).

Flux indirect, Dépôt de données

Si l'utilité des données véhiculées par un flux n'est pas épuisée du fait de leur utilisation par le processus ré-cepteur, les données en question sont mémorisées dans un dépôt de données.

Un flux indirect relie un processus et un dépôt de données. Il peut être orienté de trois façons :

– du dépôt vers le processus : flux entrant, consultation du dépôt de données;– du processus vers le dépôt : flux sortant, mise à jour du dépôt de données;– dans les deux directions : entrée et sortie, consultation et mise à jour.

Remarque. Si le seul but d'une consultation est d'obtenir les valeurs précédentes en vue de les modi-fier, on dessinera un flux unidirectionnel de mise à jour.

GANE & SARSON

1

Enregistr.Commandes

2

PréparationLivraisons

E-1

Clients

D-1 Catalogue

D-2 Clients

D-3 Stocks

Bons deCommande

Factures

RéservationsCommandes

différées

1 Cf. chapitre 3.

Page 155: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-7

DE MARCO

Enregistr.Commandes

PréparationLivraisons

Clients

Catalogue

Clients

Stocks

Bons deCommande

Factures

RéservationsCommandes

différées

REGLE. A l'intérieur du système de référence, tout dépôt de données doit participer à au moins un flux demise à jour (garnissant le dépôt) et à au moins un flux de consultation (sinon, le dépôt est dépourvu d'utilité).

Le contenu d'un dépôt de données sera nommé et décrit par un schéma de données. Le contenu d'un flux indi-rect ne véhiculant qu'une partie des données du dépôt sera lui aussi nommé et décrit par un sous-schéma dedonnées.1

A un flux indirect sont nécessairement associées des opérations d'accès aux données du dépôt. On exprimehabituellement ces opérations par rapport aux occurrences d'enregistrements :

– insérer (ajouter), remplacer ou supprimer une ou plusieurs occurrences de tel(s) type(s),– obtenir (lire, consulter) une ou plusieurs occurrences de tel(s) type(s).

Puisqu'un nombre quelconque de processus peuvent accéder aux mêmes dépôts, ces derniers n'introduisentdans le schéma aucune contrainte. Dès lors, dans la recherche des processus à interconnecter, les concepts dedépôt de données et de flux indirect apparaissent accessoires. Plusieurs formes de diagrammes de flux n'enfont d'ailleurs pas mention. Plus important : les méthodes courantes d'analyse par les flux ne fournissent au-cun critère d'identification des dépôts de données.

Un schéma décrivant les flux physiques de données dans un système réel peut mentionner comme dépôts lesfichiers réels, magnétiques et autres, utilisés par les traitements. Pour une description conceptuelle des flux,antérieure à la définition des fichiers réels, nous préconisons les dispositions suivantes :

1) entre un dépôt de données particulier et un processus particulier, il n'existe pas plus d'un flux in-direct;

2) il existe entre les données conservées dans un même dépôt une parenté sémantique reconnaissableà l'existence d'identifiants communs (un même dépôt peut contenir la fiche signalétique individuelledes employés et une description des fonctions qu'ils occupent, mais un dépôt ne contient pas à la foisdes données relatives aux clients et aux produits ...); cette règle tend à distinguer une collection dedonnées dont le schéma logique sera arborescent, dont la structure pourra supporter directement laprogrammation2 — cette solution est recommandée dans un diagramme de flux entre tâches;

1 Cf. chapitre 3.2 Cf. chapitre 4.

Page 156: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-8

3) la période de mémorisation des informations conservées dans un même dépôt est définie par lesmêmes règles; concrètement, cela signifie que toutes les occurrences de données sont insérées pardes exécutions d'un/des même(s) processus et supprimées par des exécutions d'un/des même(s) pro-cessus (dans un diagramme de flux entre sous-systèmes, on peut donc mentionner un dépôt de "don-nées personnelles", mis à jour par le sous-système de gestion du personnel; mais, dans un diagrammede flux entre tâches, on distinguera différents dépôts, mis à jour par des tâches diverses : fiches si-gnalétiques des employés, relevé des prestations quotidiennes du personnel, etc).

Perméabilité des classes de flux directs et indirects

Dans la tâche de Préparation des Livraisons (voir la figure précédente), observons le flux cyclique desCommandes différées. Il a en commun avec le dépôt Stocks de se trouver à la fois en entrée et en sortie de latransformation et de se retrouver d'une exécution à l'autre de cette tâche; dès lors, ne s'agit-il pas d'un dépôtde données ? Il a en commun avec le flux direct des Commandes reçues que son contenu finira par être"consommé" par l'activité de Préparation des Livraisons; dès lors, ne s'agit-il pas d'un flux direct de messa-ges ? Mais, si les règles de procédure autorisent les livraisons partielles (à concurrence des quantités dispo-nibles), les valeurs de quantités en commande évolueront de la même manière qu'évoluent les quantités enstock ...

Cet exemple montre qu'il n'existe pas de solution de continuité entre les catégories utilisées par l'analyste.

1.2. Structures typiques

a) Applications sans flux directs

Certaines applications informatiques se caractérisent par l'absence de flux directs entre les tâches. Il s'agitd'applications dont l'objet principal est de tenir à jour et disponible un "stock" d'informations, une "banque dedonnées". Exemple : le fichier des membres d'une association.

• Première variante : l'application comporte des tâches de mise à jour, consultation et listage des données,entre lesquelles n'existe aucun ordonnancement (on peut imaginer de consulter un fichier vide, n'ayant encorefait l'objet d'aucune mise à jour ...).

Respons. Fichier

Mise à jour

Consult.

EditionListe

Gestion des Membres

Page 157: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-9

• Seconde variante : une séquence d'états successifs est définie sur les données d'un dépôt. L'application degestion de ce dépôt comporte différentes tâches de mise à jour, dont chacune a pour objet de faire subir à unsous-ensemble du dépôt une transition d'état autorisée. Ces tâches doivent évidemment se succéder selon unordre défini. L'énumération des transitions d'état constitue souvent un outil puissant pour la recherche destâches dans certaines applications.

Exemple : établissement du devis d'une entreprise de construction :

1) enregistrement du métré (quantification des plans) de l'ouvrage établi par l'architecte;2) correction du métré par l'indication des quantités recalculées par l'entrepreneur;3) affectation de moyens de production (matériaux, etc.) aux différents postes du métré;4) calcul du prix de revient, sur la base du coût des différents moyens;5) établissement du prix de vente, par complétage (marges ...) du prix de revient.

Enregistr.métré

Correctionmétré

Affectationdes moyens

Calcul duprix revient

Etablisst.prix vente

Métré/DevisMétreurDeviseur

Catalogue

Prix

Tarif

Plans + MétréArchitecte

Métré(Postes & Quantités)

Devis

Descript.moyens

Moyens & QtésSélectiondes moyens

Ajustementsde prix

1.

2.

3.

4.

5.

automatique

interactif

interactif

interactif

interactif

Quantitéscalculées

ModificationsQuantités

Quantités <----> Prix

Etablissement Devis

b) Décomposition suivant un axe spatio-temporel dominant

On peut voir un flux direct comme un déplacement d'informations dans l'espace et/ou le temps. De nombreuxsystèmes se caractérisent par des activités (des tâches) clairement distantes les unes des autres. Tâches qui serépartissent soit dans le temps, soit dans l'espace.

Page 158: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-10

• Certaines applications possèdent une structure temporelle marquée par un échelonnement périodique destâches. Tel est, par exemple, un système d'administration des salaires et appointements, dans lequel on peutdistinguer les groupes de tâches suivants :

– tâches à périodicité variable : enregistrement des données signalétiques des travailleurs;– tâches quotidiennes : enregistrement des prestations (présences et absences);– tâches mensuelles : établissement de la paie des travailleurs;– tâches trimestrielles : versements aux organismes de prélèvement (fisc, sécurité sociale ...);– tâches annuelles : établissement d'attestations (fiches fiscales, cotisations de sécurité sociale ...).

• Certains systèmes sont caractérisés par une structure spatiale reflétant la multiplicité des sites d'opérations.Exemple classique : le binôme centralisation/décentralisation, maison-mère/filiale ... Les processus, maisaussi les dépôts de données, sont répartis entre le site central et les sites périphériques. Les flux de messagesentre sites s'y avèrent essentiels à l'existence du système global.

c) Systèmes régulés

Pour survivre et fonctionner harmonieusement, un système a besoin de mécanismes de régulation. Nous al-lons illustrer la chose par le cas du sous-système Achats–Ventes–Stocks d'une entreprise commerciale.

����������

��������

��������

��������

��������

����������� ������������

����������

���������

��������

��������

����������

�����

�����������

������������

����������

�������

!�����

������

�"�����

�������"���

�������� ������������#

��������

$�%��� &����'�����

�������

$�%���(&����(������ )�������������������*

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

Page 159: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-11

Toute sortie est suivie d'une analyse de l'état du réservoir; il peut en résulter un message (identification deproduit à commander) agissant sur le débit du flux entrant (commande de réapprovisionnement). Un tel effetdes sorties sur les entrées a reçu le nom de boucle de rétroaction (en anglais : "feedback"). Ce concept a étémis en avant et formalisé par les cybernéticiens.1

L'existence d'un réservoir (les stocks) donne du "mou" au système et lui permet de fonctionner sans à-coups(sans ruptures de stocks). Un tel tampon a pour rôle de garantir la continuité de fonctionnement du système.En vue de réduire le nombre de pannes (refus de commandes), le système peut être perfectionné par l'exis-tence d'un second tampon (les commandes différées).

Les mécanismes régulateurs évoqués jusqu'ici sont internes au système et font partie de son fonctionnementhabituel. Un autre mécanisme régulateur est représenté par la tâche périodique (annuelle) d'inventaire, dansson aspect d'ajustement des stocks théoriques aux stocks physiques; il s'agit dans ce cas d'une interventionextérieure sur le système, visant à pallier les "fuites" non détectées par le "programme" normal du système.On devrait imaginer une intervention analogue sur les commandes trop longtemps différées ...

NOTE. Remarquer que la fermeture de la boucle des réapprovisionnements (commandes – fournitures) im-plique l'acteur externe Fournisseurs. La fermeture ou complétude d'un schéma de flux implique habituelle-ment l'intervention de l'environnement du système ou la mention de tâches "manuelles" en plus des tâches au-tomatiques.

1.3. Validation des diagrammes de flux

a) Syntaxe des diagrammes de flux

Relations entre composants

Il y a lieu de vérifier les relations indiquées entre les divers objets représentés sur un diagramme de flux :

• tous les processus représentés sur un diagramme de flux doivent être du même niveau d'agrégation : sous-systèmes, tâches ou groupes de tâches, modules ou compositions de modules;

• tout flux possède exactement une origine et une destination; il doit avoir une des trois formes suivantes :

– flux externe reliant un processus et un acteur externe, – flux direct de messages reliant deux processus ou deux exécutions successives d'un même processus, – flux indirect reliant un processus et un dépôt de données;

• tout processus représenté sur un diagramme de flux doit avoir au moins un flux entrant et un flux sortant(exceptionnellement, une tâche ou un module pourrait ne pas avoir de flux entrant);

• dans le cadre global du système de référence, tout dépôt de données doit faire l'objet d'au moins un flux demise à jour et un flux de consultation;

• entre deux composants quelconques, il n'existe, en principe, pas plus d'un flux, sauf si l'un des deux compo-sants est un objet permanent (acteur externe ou sous-système).

1 N. WIENER : Cybernétique et société, trad. française; éd. des Deux Rives, 1952.

Page 160: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-12

Dénomination des composants

• Tout composant — acteur externe, processus, dépôt de données — doit être nommé.

Le nom d'un processus est normalement formé d'un nom indiquant le type de transformation opérée etd'un complément désignant le flux de sortie principal.

Exemples : tâches : enregistrement des commandes-clientspréparation des livraisonsexpédition des factures

modules : vérification de datecalcul de l'impôtmise en page des factures

Tout flux de messages doit être nommé. Le nom d'un tel flux est normalement formé du nom de type desmessages et d'un qualificatif d'état.

Exemples : bons de commande valides, commandes enregistrées, commandes différées.

Il est cependant quelquefois difficile d'attribuer un nom aux flux agrégés représentés au niveau dessystèmes ou sous-systèmes. Dans ce cas, plutôt que de recourir à des noms sans signification, onpourra tolérer de laisser ces flux sans désignation.

• Un flux indirect n'est habituellement pas nommé si son contenu est égal à celui du dépôt qu'il concerne.

N.B. On évitera les vocables passe-partout du genre "données, informations" ou "traitement" ...

Remarque. Mise en page d'un diagramme de flux

Dans un diagramme de flux, il importe d'éviter les flèches se croisant et tournant dans tous les sens; un teldiagramme serait rébarbatif et sa lecture découragée. On suivra au maximum les recommandations suivantes.

L'armature d'un diagramme de flux est formée de l'ensemble des sous-processus représentés. De manière àrespecter les habitudes de perception du lecteur, les symboles figurant ces processus seront dessinés, en sui-vant l'ordre chrono–logique (matérialisé par les flux directs, s'il en existe dans le diagramme), de haut en bas,au centre de la page. Si le diagramme comporte des boucles de rétroaction, les flux en cause seront représen-tés par des flèches remontantes.

Les autres éléments du diagramme — acteurs externes, dépôts de données — seront disposés sur le pour-tour et, éventuellement, dédoublés. La règle sera ici d'éviter un maximum de croisements de flèches repré-sentant des flux.

Voir particulièrement, plus haut, les exemples de diagrammes d'Applications sans flux directs.

b) Hiérarchisation des diagrammes

Un diagramme de flux présente les relations entre sous-processus d'un processus décomposable; ce dernier estlui-même figuré par une boîte noire dans un diagramme hiérarchiquement supérieur ... Il est possible d'établirune hiérarchie de diagrammes de flux : toute boîte noire d'un diagramme "parent" peut être "éclatée" sous laforme d'un diagramme "enfant". En quelque sorte, un diagramme de flux est un zoom grossissant.

Les règles suivantes doivent être respectées.

Page 161: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-13

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

�������

����

����� �

��� ���

���� �

������� ������������

���� � ���� �������

������� �� �

������

��������������

��� ��������� �

!����� �������

1) L'environnement d'un diagramme enfant — acteurs externes, processus, dépôts de données — doit êtreidentique à celui de la boîte noire parente.

2) Les entrées et sorties d'un diagramme enfant doivent être équivalentes aux entrées et sorties de la boîtenoire parente. En d'autres termes, chaque flux franchissant la frontière d'un diagramme enfant est identique àun flux de la boîte parente ou constitue un sous-ensemble d'un tel flux; dans le second cas, il doit y avoir, ausens mathématique, partition du flux parent.

ClientsStocksFourn.

Fournitures

Inventaire

Magasin

Stocksajustés

Factures

Ventes

Compta-bilité

EcrituresComptables

EcrituresComptables

CommandesRéapprovist.

Bons deCommande

Achats

S/Syst.

S : A ch a t s-V en t es-S to ck s

S/Syst.

S/Syst.

Page 162: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-14

"��������#��������

� ������������ �

������� ������ $ �

��� ���

�� ��%�&&�

� � ��

������

��������������

��� ��������� �

������'���"������(�������

!����� �������

�������

��� ���

�)�*����� �� �

+,��

+,��

���� �

+,��

������

���� �

-���&�����&�

� �#�������

L'analyste prendra soin de répercuter sur le diagramme parent les flux ajoutés sur un diagramme enfant (voir,dans la dernière figure ci-dessus, l'Identification des Produits à commander). Ceci pourrait toutefois être né-gligé pour les flux de messages reflétant les cas d'erreurs que l'analyse plus globale n'avait pas mis en évidence(exemple : les Rejets lors de l'Enregistrement des commandes).

1.4. Spécification d'un processus

La description complète d’un processus opératoire, en particulier d’une tâche de traitement de l’information,comporte trois volets :

– l’identification de la fonction remplie par le processus, qui en dévoile l’utilité;– la spécification des règles qui contraignent les opérations et en garantissent la validité ;– la description de la procédure qui détaille la méthode à mettre en œuvre.

Les deux premiers volets précisent les besoins à satisfaire; ils définissent "conceptuellement" une classe deproblèmes à résoudre. La description de la procédure vient plus tard; elle fait partie de la description "orga-nique" d’une solution.1

REMARQUE. Idéalement, la description d'un processus devrait faire abstraction du contexte danslequel il a été découvert; de la sorte, cette description sera réutilisable dans un autre contexte. Si lachose s'avère relativement malaisée aux niveaux les plus agrégés (système, sous-systèmes), elle de-vient davantage réalisable à mesure que l'on descend vers la description des composants élémentaires.Ce devrait au moins être le cas de la description d'un module programmable : la description d'un mo-dule de vérification syntaxique d'une date devrait convenir à la validation de toute espèce de date ...

1 Cf. chapitre 1.

Page 163: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-15

a) Description externe de la fonction

Un processus de traitement de l'information poursuit une finalité, que nous appelons sa fonction, et quiconsiste en une transformation de données d'entrée en données de sortie.

Dans un premier temps, la description externe (du "quoi") d'un processus a pour but d'en montrer l'effet, enmettant en évidence les différences entre l'ensemble des données d'entrée et l'ensemble des données de sortie.Quant aux opérations transformatrices, elles ne sont pas décrites comme telles. Il s'agit en quelque sorte decommenter le dessin d'une boîte noire.

1) A ce point, la spécification d'un flux d'entrée ou de sortie se réduit à définir le sous-schéma des donnéesvéhiculées.1 (L'indication d'origine ou de destination du flux, de même que la quantification des occurrencesvéhiculées appartiennent à la définition du contexte — voir la remarque ci-dessus.)

2) Dans le cas d'un processus ponctuel, tâche ou module, on indiquera les types d'opérations d'accès relativesà chaque flux :

– flux direct (messages) : entrée = Recevoir;sortie = Emettre;

– flux indirect (dépôt) : consultation = Obtenir (Lire);mise à jour = Insérer (Créer), Remplacer (Modifier), Supprimer.

3) Dans cette première description globale, la fonction proprement dite du traitement sera résumée en quel-ques propositions expliquant synthétiquement la transformation subie par les données.

Exemples : MODULE : calcul de l'impôtFONCTION : calculer le montant de l'impôt sur le salaire imposable

en appliquant les barèmes d'imposition adéquats;calculer salaire net = imposable - impôt

RECOIT : montant du salaire imposableOBTIENT : barèmes d'impositionEMET : montant de l'impôt, salaire net

MODULE : vérification syntaxique de dateFONCTION : tester la validité syntaxique d’une dateRECOIT : dateEMET : signal-OK ou signal-KO

TACHE : préparation des commandes de réapprovisionnementFONCTION : pour chaque produit à commander,

déterminer — par consultation —la quantité à commander et le fournisseur;éditer le bon de commande

RECOIT : identification des produits à commanderOBTIENT : stocks, catalogue, fournisseursEMET : bons de commande aux fournisseurs

1 Cf. chapitre 3.

Page 164: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-16

b) Description de l'interface d'une tâche

La tâche est l'unité de traitement avec laquelle les utilisateurs échangent des données. A ce niveau, il est doncnécessaire de décrire l'interface du processus : préciser en détail la forme concrète, physique, des collectionsde données entrantes et sortantes, du moins celles pour lesquelles l'environnement utilisateur impose descontraintes. Une telle description prend généralement la forme d'un dessin convenablement annoté.

Exemples : formulaires de consultation et saisie de données à l'écran; rapports imprimés;enregistrements de bandes magnétiques ou messages échangés entre divers organismes (banques, fisc, sécurité sociale ...).

c) Spécification détaillée des règles

Niveaux de définition des règles

Les règles de traitement constituent une expression formelle et opérationnelle des objectifs et contraintes fixéspar l'utilisateur du système d'information.

• Au niveau d'un système ou sous-système, on ne peut guère indiquer que des objectifs de performance tech-nique ou économique, par exemple : "traiter et facturer 95 % des commandes–clients le jour même de leurréception".

• Les règles pratiques sont découvertes dans le contexte d'une tâche, traitement élémentaire aux yeux de l'uti-lisateur; elles sont ultérieurement réparties sur les modules découpés par le technicien.

Il est techniquement indispensable d’associer à chaque module l’énoncé des règles qu’il est chargéd’appliquer. En outre, il est rationnel d’inclure dans la description d’une tâche les règles dont elle estle siège; cependant, cet énoncé sera souvent facilité si l’on introduit dans cette définition un mini-mum de structure grâce à une décomposition en modules, fût-elle fictive (c’est-à-dire différente decelle qu’adopteront finalement les techniciens).

Si des règles sont énoncées à différents niveaux de décomposition, il convient de vérifier la cohérence desspécifications :

– les règles attachées à un module ne peuvent contredire celles de la tâche : elles précisent une par-tie des règles de la tâche;– les ensembles de règles fournis aux différents niveaux doivent être équivalents.

Expression des règles

Les règles appliquées dans le cadre d’une tâche de traitement de l’information sont principalement des prédi-cats déterminant la qualité des données traitées. Ces prédicats constituent les contraintes d’intégrité invento-riées dans la définition des données.1 Il est donc assez naturel de rattacher directement les règles aux flux dedonnées.

Exemples : MODULE : vérification syntaxique de date FONCTION : tester la validité syntaxique d’une date RECOIT : date - REGLES : date numérique et mois ∈ {1..12} et jour ∈ {1..31} EMET : signal-OK ou signal-KO

1 Cf. chapitre 3.

Page 165: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-17

MODULE : mise à jour des stocks FONCTION : mettre à jour les stocks suite à l’acceptation des commandes–clients

et identifier les produits à réapprovisionner RECOIT : commandes-du-jour (0:N commande (1:1 en-tête, 1:N ligne)) MET-A-JOUR : stocks (0:N stock) - REGLES : pour n°-produit de stock = n°-produit de ligne de commande

total-sorties = précédent + qté-commandée de ligne de commande qté-en-stock = total-entrées – total-sorties

EMET : produits-à-réapprovisionner (0:N id-produit) - REGLES : pour n°-produit de id-produit = n°-produit de stock

si qté-en-stock précédente ≥ stock-plancher et qté-en-stock nouvelle < stock-plancher date = aujourd’hui

1) En vue de faciliter la lecture des règles, les flux d’entrée sont énumérés avant les flux de sortie, dans l’ordre : RECOIT, OBTIENT, MET-A-JOUR, EMET.2) Chaque flux est décrit sous la forme d’un schéma de données arborescent.1

3) Dans les règles, les expressions pour clé et si déterminent les correspondances entre flux (on pourrait laisser à l’état implicite la partie en italique des expressions pour).4) Les règles attachées aux flux de sortie servent de post-conditions au processus décrit : les relations qu’elles expriment doivent être rendues vraies par l’exécution du processus.

Vérification des règles

Le caractère faisable des opérations doit être vérifié par un contrôle de complétude et de non contradiction del'ensemble des règles de dérivation :

– pour toute variable appartenant à un flux de sortie, doit exister au moins une règle capable de laproduire;– à moins d'être définie comme variable intermédiaire, toute variable référencée dans une règle doitappartenir à un flux;– toute variable référencée dans une règle, soit appartient à un flux d'entrée, soit est le résultat del'application d'une règle.

d) Définition interne de la procédure

Dans un second temps, une description interne (du "comment") du processus explicite les mécanismes ca-chés à l'intérieur de la boîte noire.

On peut imaginer différentes manières de présenter une procédure. Nous proposons ici la forme algorithmi-que d'un pseudo-code faisant expressément référence aux flux de données qui se croisent dans tout processus.

Comme au paragraphe précédent, nous supposons que le contenu de chaque flux est une collection de donnéesreprésentée par un schéma logique arborescent; ces collections de données pourront donc supporter directe-ment une programmation.2 Si tel n'est pas le cas d'un flux, on le décomposera en flux partiels de structurearborescente.

1 Cf. chapitre 4.2 Cf. chapitre 4.

Page 166: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-18

Trois séries de règles doivent être formulées :

– les accès aux données (ces règles sont à recopier de la description externe),– les correspondances entre les composants des différents flux de données,– les règles de dérivation des sorties à partir des entrées : détermination des valeurs mais aussi desoccurrences (par exemple, un contrôle de validité sélectionne des occurrences, celles qui satisfontaux règles de validité).

Un pseudo-code est un texte décrivant un algorithme au moyen d'un pseudo-langage de programmation.Pseudo-langage, car il ne fait pas l'objet de traduction automatique. Par suite, la syntaxe du langage n'estpas véritablement contraignante et n'a rien d'obligatoire, le langage peut être incomplet (par exemple, nepas offrir les "instructions" d'ouverture et fermeture de fichier), les objets manipulés ne sont pas les objetstechniques concrets manipulés par les programmes, mais des préfigurations conceptuelles ...

Le pseudo-langage doit permettre d'exprimer les trois séries de règles qui définissent toute procédure.1

1) La spécification des opérations d'accès aux données comporte théoriquement les éléments suivants :

• l'identification du flux visé et le nom du composant transmis par le flux;• le type d'opération :

– recevoir (flux direct, messages entrants),– émettre (flux direct, messages sortants),– obtenir (flux indirect, consultation d'un dépôt),– insérer, remplacer, supprimer (flux indirect, mise à jour d'un dépôt);

• dans le cas d'une opération obtenir de consultation,– l'identification du critère de sélection,– le traitement de réaction aux cas d'erreurs (inexistence du composant demandé).

Schématiquement :

opération composant de flux [ sélection = critère ] [ si erreur alors traitement [ sinon ] ]

2) La mise en correspondance des quantités d'information se fait en répartissant les opérations de la procé-dure, y compris les opérations d'accès aux données, dans des blocs de traitement appliqués aux composantsdes flux d'entrée. Toute opération recevoir ou obtenir est donc théoriquement suivie d'une construction de laforme suivante :

pour chaque composant traitementsfin

Si le flux d'entrée possède une structure hiérarchisée (arborescente), plusieurs blocs s'emboîtent les uns dansles autres, conformément au schéma suivant. Soit 0, le niveau de la racine de l'arborescence et 1,2... les ni-veaux de décomposition successifs :

1 Ce pseudo-langage s'inspire du langage de programmation MCL — Modular Control Language — définipar A. CLARINVAL : MESANGE : Méthode et Système d'Analyse et de Programmation de Gestion. Cetteprésentation est fort proche de celle d'un Procedure Action Diagram dans la méthode IEM de J. MARTIN.

Page 167: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-19

pour chaque composant de niveau 0 ..... pour chaque composant de niveau 1 ..... pour chaque composant de niveau 2 ..... fin ..... fin .....fin

Exemple : soit le flux CDES-DU-JOUR (0:N COMMANDE (contenant 1:N LIGNE-COMMANDE))

pour chaque CDES-DU-JOUR.....pour chaque COMMANDE

.....pour chaque LIGNE-COMMANDE

.....fin.....

fin.....

fin

3) Aucune formulation particulière n'est suggérée ici pour exprimer les règles de transformation appliquéespar la procédure. Il est souvent possible, comme au paragraphe précédent, d'adopter la syntaxe des règles as-sociées aux schémas de données.1 Les règles définissant les conditions d'existence des occurrences de don-nées dans les flux seront habituellement présentées sous la forme d'opérations d'accès aux flux.

4) L'analyste est juge de ce qu'il peut laisser à l'état implicite. Dans les exemples qui suivent, on peut raison-nablement penser qu'il peut en être ainsi au moins pour les parties en italique.

Exemples : MODULE : vérification syntaxique de date FONCTION : tester la validité syntaxique d’une date RECOIT : date EMET : signal-OK ou signal-KO PROCEDURE : recevoir date

pour chaque datesi (date numérique et mois ∈ {1..12} et jour ∈ {1..31})

émettre signal-OKsinon

émettre signal-KOfin

fin

1 Cf. chapitre 3.

Page 168: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-20

MODULE : création de factures FONCTION : calculer et créer les factures RECOIT : commandes-du-jour (0:N commande (1:1 en-tête, 1:N ligne)) OBTIENT : clients (0:N fiche) OBTIENT : tarif (0:N produit) EMET : factures-du-jour (0:N facture (1:1 en-tête, 1:N ligne, 1:1 fin)) PROCEDURE : recevoir commande de commandes-du-jour

pour chaque commandepour chaque en-tête de commande

obtenir fiche de clients sélection = n°-clientpour chaque fiche

émettre en-tête de facture de factures-du-jourfin

finpour chaque ligne de commande

obtenir produit de tarif sélection = n°-produitpour chaque produit

montant-facturé = prix-de-vente * qté-livréefinémettre ligne de facture de factures-du-jour

fintotal-facture = Σ montant-facturéémettre fin de facture de factures-du-jour

fin

Page 169: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-21

2. Schéma dynamique

Tout flux de messages entre un processus émetteur et un processus récepteur contribue à rendre possible l'exé-cution du second. Constater l'existence d'un tel flux ne suffit cependant pas à rendre compte des conditionsd'exécution et d'enchaînement des traitements, ce qui requiert l'établissement d'un schéma logico–dynami-que des traitements.

S'inspirant de la théorie des réseaux de Petri,1 plusieurs modèles pour l'étude dynamique des systèmes de trai-tement de l'information sont apparus aux alentours de 1980-85. Citons le modèle défini par F. BODART et Y.PIGNEUR dans le cadre de la méthode IDA,2 ainsi que celui proposé par la méthode MERISE.3 Pour l'es-sentiel, nous nous inspirons ici des propositions de la méthode IDA.

2.1. Contenu du schéma dynamique

Un schéma dynamique met en œuvre les objets suivants : des processus, des événements et des moniteurs.On peut considérer les deux derniers concepts comme complétant ceux du schéma fonctionnel.4

Comme dans toute modélisation, on s'intéressera ici aux types d'événements, types de processus, etc. En parti-culier, plusieurs (occurrences de) processus d'un même type (par exemple, l'enregistrement d'une com-mande) peuvent se dérouler simultanément ...

a) Processus

Lors de l'élaboration d'un schéma dynamique, on considère les processus qui, dans le temps, possèdent undébut — appelé déclenchement — et une fin — appelée terminaison. Les deux moments de déclenchementet terminaison sont deux moments remarquables, au sens propre de discernables, correspondant chacun à unchangement d'état du processus : le déclenchement fait passer celui-ci de l'état inexistant à l'état actif, la ter-minaison le fait passer de l'état actif à l'état terminé.5

Caractérisé par un début et une fin, un tel processus ne peut pas être un ensemble d'opérations récurrentes,comme un sous-système. Il ne peut s'agir que d'une tâche ou d'un module.

b) Evénement

Un événement représente

– un changement d'état,– survenant à l'intérieur du système décrit ou dans son environnement,– toujours observable de l'intérieur du système décrit,– et auquel ce dernier doit réagir par l'exécution, immédiate ou différée, de certains processus.

1 Cf., par exemple, J.L. PETERSON : Petri Nets; in ACM Computing Surveys, vol. 9, n° 3, sept. 1977;BRAHMS : Théorie et pratique des réseaux de Petri; Masson, 1983.2 F. BODART, Y. PIGNEUR : Conception assistée des systèmes d'information : méthodes, modèles, outils;Masson, 1989.3 H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode MERISE; éd. d'Organisation, 1989.4 Les dépôts de données n'interviennent pas dans la description de la dynamique.5 Un modèle prenant en compte les ressources nécessaires à l'exécution des processus distinguera d'autresétats, comme, par exemple, l'état interrompu ou suspendu par suite d'indisponibilité temporaire des ressour-ces. La méthode IDA propose un tel modèle.

Page 170: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-22

Le changement d'état observé concerne des données conservées dans les dépôts du système (par exemple, laréception d'un bon de commande, l'épuisement d'un stock ...) ou un processus qui, par exemple, se termine.

Sauf le cas particulier, évoqué ci-après, des événements de calendrier, la survenance d'un événement est tou-jours provoquée par un processus antécédent, qui en informe un ou plusieurs processus conséquents.1 Unévénement non observé n'est pas susceptible d'entraîner une réaction et n'est donc pas à prendre en considéra-tion. Ce qui est fondamental, c'est l'information relative aux événements. Cette information est véhiculée pardes messages ou transmise par des signaux.

• Nous avons défini plus haut le concept de message. Un message est une information variable. Le plus com-munément, il renseigne sur un changement d'état survenu parmi les données détenues dans les dépôts du sys-tème.

Exemples : identification d'un produit à commander par suite d'épuisement de stock, avec la quantitéfacture reflétant une venteécriture comptable reflétant la même vente

• Un signal est une information invariable. Il renseigne sur un changement d'état d'un processus, le plus sou-vent sa terminaison. Un signal constitue un cas limite de message : le message "vide". On peut le voircomme une entité, dont toute occurrence est discernable, mais qui ne possède pas d'attribut descriptif, pas detexte (penser, de manière imagée, à un "bip" sonore). Nonobstant, un signal possède un nom de type, telqu'il en identifie clairement la provenance : nom du processus émetteur + qualificatif d'état de ce proces-sus. Exemple : "Préparation des Livraisons terminée".

Sur un diagramme de flux, un signal peut être représenté sous la forme d'un flux direct entre processus.Afin d'en indiquer la nature particulière, on pourrait le représenter par un trait discontinu ou bien placer sonnom entre parenthèses ...

Exemple : le signal "Préparation des Livraisons–Clients terminée" doit être attendu avant de déclencher leprocessus de Préparation des Commandes de Réapprovisionnement; dans une autre organisation, cette attentepeut ne pas être souhaitée : la Préparation d'une Commande de Réapprovisionnement pourrait être déclenchéeimmédiatement et automatiquement par l'émission du seul message "Identification d'un Produit à Comman-der".

����������

�������� ���������

�������� ������������#�

��������

)��������

��������*

Cas particulier : les événements de calendrier. L'activité d'un système, l'exécution de processus, est souventconditionnée par l'écoulement du temps. Par exemple, tel processus doit être activé "tous les vendredis à 16heures". On considérera donc que l'environnement de tout système comporte un processus permanent "hor-loge" ou "calendrier", délivrant des messages de mesure du temps (exemple de message : "nous sommesvendredi, il est 16 heures"). Le fait de situer ce processus dans l'environnement du système dispense de ledécrire.

��������������

���������������(

������

+�"����

�������

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

Page 171: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-23

Tous les types d'événements n'ont pas le même degré de nécessité. Normalement, les événements de calen-drier et les signaux de transition d'état des processus ne servent qu'à ordonnancer l'usage des ressources affec-tées à l'exécution des opérations; en revanche, les messages reflétant l'évolution des données sont indispensa-bles à la validité fonctionnelle des traitements, c'est-à-dire à l'intégrité de leurs résultats. Un schéma (un dia-gramme de flux) ne mentionnant que des messages de la seconde catégorie est fonctionnel — il décrit uneclasse de problèmes; un schéma mentionnant les autres types d'événements est chrono–logique et décrit desphénomènes contingents à une organisation — il décrit une solution. L'analyste à la recherche d'une nou-velle solution, qui ne veut pas simplement rafraîchir une solution existante, doit clairement faire cettedistinction !

c) Moniteur

D'une manière générale, la survenance d'un événement — ou, plus précisément, sa notification — ne suffit pasà déclencher l'exécution d'un processus conséquent. Il est fréquent que l'on doive attendre la survenance d'unecombinaison d'événements, c'est-à-dire la réception de différents messages ou signaux, avant de déclencher enréaction l'exécution d'un ou plusieurs processus. N'est pas rare, en effet, une situation du genre de celle-ci, oùs'accumulent différents messages ou signaux :

– existence de messages reflétant une situation (ex.: bons de commande reçus des clients),– condition horaire ou de calendrier (ex.: entre 15 et 16 heures),– demande expresse d'un responsable (ex.: "commencez la Préparation des Livraisons").

La gestion des événements est assurée par des moniteurs. Un moniteur est un processus, du même niveau(tâche ou module) que les pocessus dont il doit contrôler l’enchaînement, théoriquement permanent (en ré-alité, à activation chronique) et qui

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

PréparationLivraisons

Etablisst.Commandes

(Livraisonsterminées)

MONIT. 01

Calen-drier

Magasin

16 heures

go!

Id. Produits àcommander

Id. Produits àcommander

Un moniteur est un processus du même niveau d'agrégation que les processus qu'il est chargé d'enchaîner. Ilprésente ceci de particulier qu'il n'opère aucun changement de forme sur les données (les messages) qu'il"traite" et qu'il n'accède à aucun dépôt de données.

Page 172: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-24

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

Exemple : expédition des factures par les employés du service Courrier.file d'attente en entrée : capacité illimitée

(toutes les factures éditées par la tâche d'Edition des Factures)consommation par chaque employé = lot de 20 factures

Calen-drier

16 heures MONIT. 02

Factures

Factures

Ordinateur

Employé

consommation = 20

capacité = infinie

ExpéditionCourrier

EditionFactures

A l'instar de tout processus, un moniteur est exécuté par un processeur : programme d'ordinateur et/ou acteurhumain; surveillance des événements et déclenchement des réactions peuvent donc être automatiques, "ma-nuels" ou mixtes.

2.2. Types d'enchaînements

L'attente effectuée par un moniteur peut viser :

• l'accumulation de plusieurs occurrences d'un même type d'événement, c'est-à-dire la réception de plusieursmessages ou signaux du même type;• la synchronisation d'événements de types différents, c'est-à-dire des messages ou signaux de types diffé-rents.

Au sens propre, une synchronisation réalise une conjonction d'événements, liés par ET. Par généralisation, onétend le concept de synchronisation à toutes les combinaisons logiques d'événements, en particulier, au cas desdisjonctions par OU.

Exemples : accumulation des factures par lots de 20 pour leur Expéditionsynchronisation pour déclencher la Préparation des Commandes de Réapprovisionnement

messages "Identification de Produit à commander"signaux "Livraisons terminées", "16 heures", "allez-y!"

disjonction : édition d'un rapport à période fixe OU à la demande

Page 173: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-25

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

• la duplication de processus (inverse de l'accumulation) déclenche l'exécution de plusieurs occurrences deprocessus d'un même type, grâce à l'émission de plusieurs occurrences d'un même message ou signal;• le parallélisme (inverse de la synchronisation) déclenche l'exécution simultanée de processus de différentstypes;• la sélection (inverse de la pseudo-synchronisation OU), émettant un message ou signal parmi plusieurspossibles, déclenche l'exécution d'un processus parmi plusieurs candidats.

Exemples : duplication : expédition simultanée de factures par plusieurs employésparallélisme possible, à la survenance du signal "Livraisons terminées",

entre les tâches d'Edition des Factures et de Préparation des Commandes de Réapprovisionnement

2.3. Spécification d'un moniteur

La spécification d'un moniteur se fera comme celle d'une procédure transformant des messages ou signauxentrants en messages ou signaux sortants.

1) Pour chaque type de message ou signal entrant, on indiquera :

– le nom (de type) de ce message ou signal,– le type de processus (ou l'acteur externe) émetteur,– le nombre maximum d'occurrences accumulables,– la durée limite de mémorisation (par défaut, cette durée est illimitée; une durée nulle indique unecause de déclenchement immédiat; une durée limitée signifie qu'au delà, l'événement d'origine est"oublié" et sans effet),– les liens unissant les différentes occurrences (identifiants communs aux différentes occurrences demessages, par exemple : "relatifs au même fournisseur").

2) Pour chaque type de message ou signal sortant, on indiquera :

– le nom (de type) de ce message ou signal (tout message sortant doit être identique à un messageentrant),– le type de processus (ou l'acteur externe) destinataire,– le nombre d'occurrences émises, en parallèle à destination de processus multiples d'un même typeou en série à destination d'un seul processus,– les liens unissant les différentes occurrences (identifiants communs aux différentes occurrences demessages).

3) Les règles de déclenchement, c'est-à-dire de production des messages ou signaux sortants, sont des prédi-cats liant par les opérateurs logiques AND, OR, NOT les événements (messages et signaux) entrants. Lesconditions ainsi exprimées doivent être exhaustives (aucun événement, aucune combinaison d'événements nepeuvent être systématiquement "laissés sur le carreau") et non contradictoires. On cherchera en outre à four-nir des règles indiquant ce que deviennent les événements à durée de mémorisation limitée s'ils n'ont pas étéconsommés avant l'échéance de cette durée (on doit considérer comme exceptionnel que des événements mé-morisés soient "oubliés" sans plus).

4) S'il y a lieu, on complétera par les règles de priorité pour le traitement des files d'attente.

Page 174: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-26

Exemple :

PréparationLivraisons

Etablisst.Commandes

(Livraisonsterminées)

MONIT. 01

Calen-drier

Magasin

16 heures

go!

Id. Produits àcommander

Id. Produits àcommander

MONIT.01 : déclenchement de la Préparation des Commandes de réapprovisionnementENTREES : (a) messages : "Identification de Produit à commander"

origine : Préparation des Livraisons–Clients occurrences accumulées : illimité durée de mémorisation : illimitée(b) signal : "Livraisons terminées" origine : Préparation des Livraisons–Clients durée de mémorisation : 1 jour(c) message : "16 heures" — origine : Calendrier durée de mémorisation : 2 heures(d) message : "go!" — origine : Magasin durée de mémorisation : 0 (déclenchement immédiat)

SORTIES : (e) messages : "Identification de Produit à commander" destination : Préparation des Commandes de réapprovisionnement occurrences émises : en série, toutes occurrences de (a)

REGLES : condition de déclenchement : (a) ET (b) ET (c) ET (d)production des sorties : (e) = (a)conditions anormales : si le message (d) n'arrive pas dans les 2 heures

(durée de mémorisation de (c)), traiter les messages (a) avec ceux du lendemain

2.4. Validation du schéma dynamique

a) Complétude du schéma

Un schéma dynamique représente le comportement d'un processus complexe — système, sous-système ou tâ-che — sous la forme d'un enchaînement de processus composants.

• Théoriquement, il est impossible que l'exécution d'un processus soit déclenchée autrement qu'à l'interventiond'un moniteur. Ceci justifie le mode de représentation de la méthode MERISE : un moniteur, appelé syn-chronisation, est attaché à chaque processus composant, appelé opération (la représentation fait égalementapparaître les conditions d'émission des événements — signaux ou messages — sortants). Inconvénient decette représentation : elle ne permet pas de visualiser les enchaînements divergents, mais seulement les en-chaînements convergents.

Page 175: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-27

PréparationLivraisons

Etablisst.Commandes

(Livraisonsterminées)

16 heures

go!

a

b

c

abc d

a.b.c.d

OKId. Produits àcommander

Evt.

Synchro.

Opération

Cond.Cond.

Evt.

• Aux paragraphes précédents, on a montré des diagrammes représentant les moniteurs comme des processusautonomes. Dans ce type de représentation, on admet généralement de ne pas faire figurer les moniteurs dontla spécification ne comporterait pas de condition et montrerait des sorties identiques aux entrées. Dans cettereprésentation, on doit, pour chaque processus composant autre qu'un moniteur, indiquer exactement un typed'événement déclencheur, c'est-à-dire un flux de messages ou de signaux en entrée (cette contrainte n'existepas dans un diagramme de flux du schéma fonctionnel).

b) Cohérence du schéma

La validation d'un schéma dynamique devrait comporter la démonstration qu'il "fonctionne" sans "blocage"systématique. Nécessairement globale, semblable démonstration est difficile à établir, autrement que par unesimulation automatique.

La théorie des réseaux de Petri définit un certain nombre de propriétés que doit vérifier un schéma dynamique"bien formé". On en trouvera un exposé, adapté au modèle de la méthode MERISE, dans l'ouvrage de H.TARDIEU, A. ROCHFELD et R. COLLETTI.1 Nous en évoquons ci-après quelques-unes.

Evénements initiaux

Dans le schéma dynamique décrivant le fonctionnement d'un processus décomposé, on doit indiquer un ouplusieurs événements initiaux, dont la survenance est acquise dès avant la mise en route du processus décrit.Ces événements doivent naître (être produits) à l'extérieur de ce processus et être indépendants les uns desautres, c'est-à-dire ne pas découler les uns des autres.

1 Op. cit.

Page 176: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-28

Processus atteignables

Tout processus composant doit pouvoir être atteint au départ d'un événement initial. Ceci implique

– l'existence d'au moins un chemin partant d'un événement initial et aboutissant au processus en cause;– sur ce chemin, une suite de conditions de production et d'attente des événements (signaux et messages)non contradictoires.

Terminaison propre

Une même cause ne peut entraîner l'activation d'une infinité d'opérations. Donc, au départ de tout événementinitial, le comportement du processus analysé doit ou bien avoir une fin ou bien ramener à l'état initial.

Pour cela, notamment, tout cycle doit posséder un début et une fin. Il y a cycle lorsqu'un processus ou un mo-niteur reçoit en entrée un événement dont il est lui-même, dans une exécution précédente, la cause directe ouindirecte. Pour tout cycle, on doit trouver une condition d'amorçage et une condition d'arrêt.

PréparationLivraisons

Enregistr.Commandes

Commandereçues

Commandesdifférées

Factures

amorce

fin

cycleDans cet exemple, la fin du cycle par l'émission d'une facture est-ellegarantie ? En d'autres termes, n'y a-t-il aucun risque qu'une com-mande soit éternellement différée (par exemple, par suite du retrait defabrication du produit commandé) ? Il faudrait alors prévoir une in-tervention palliative extérieure.

Page 177: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-29

3. Schéma de déploiement

On l'a déjà signalé : des ressources doivent être affectées individuellement à l'exécution de chaque tâche, ain-si qu'à chaque flux réel entre tâches. Ceci peut se visualiser par un diagramme des flux dans l'organisation.

Il s'agit d'un diagramme de flux entre tâches, dont les éléments sont disposés dans les cases d'un tableau àdouble entrée, où

– les colonnes représentent les "lieux" de l'organisation : postes de travail ou services responsables;– les lignes représentent des moments ou des périodicités (journalier, hebdomadaire, mensuel ...).

Les boîtes noires symbolisant les tâches portent différentes annotations :

– durée estimée,– type de processus (automatique, "manuel", interactif).

Le support des messages et dépôts de données — papier, écran, bande magnétique, ligne téléphonique ... —est visualisé par un symbole iconographique.

������

����

� ���

��������

����

�� ���������

������������

�������

�����

Normalement, les flux externes sont quantifiés : nombre moyen d'occurrences à chaque exécution de tâche.La quantification des flux internes est, au moins théoriquement, déductible des règles de traitement.

La plupart des méthodes se contentent d'une illustration de ce genre.1

1 La méthode IDA propose un véritable modèle d'analyse des ressources, assorti de programmes de simulationpermettant de tester le caractère faisable des spécifications.

Page 178: Methodes d Analyse

© A. CLARINVAL Analyse — Diagrammes de flux 7-30

Calendrier Ordinat. central Serv. Personnel Pointeuse Travailleurs Services Banque Comptabilité

INTER

SituationFamiliale Situation

Profess.Modif.Situation

Signalét.

AUTO

Poin-tages

Enregistr.Présences

INTER

Enregistr.Prest.spéc.

Prestat.spéciales

Prestat.

AUTO

CalculRémunér.

Rémunér.

Fichesde Paie

Vire-ments Ecri-

tures

Quotid.

Variable

Fin du mois

Fin du mois

10/mois

4/mois

100x2

60

100

100

20

ADMIN.SALAIRES

Page 179: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-1

Chapitre 8. Méthodes orientées Objets

On assiste actuellement (1995–2000) à l'émergence de nouvelles méthodologies, nécessitées et entraînées parle succès de la programmation par objets. C’est ainsi que l’Object Management Group (OMG) a, en 1997,adopté comme standard l’Unified Modeling Language (UML).1 Ce "langage de modélisation unifié", produitde la société américaine Rational Software, est le fruit de la rencontre au sein de cette société de trois pion-niers des méthodes d’analyse et conception "orientées objets" : les Américains G. BOOCH et J. RUM-BAUGH et le Suédois I. JACOBSON.

Le schéma central produit par une analyse axée sur les objets, souvent le seul peut-être, est le diagramme desclasses d'objets; il s'agit ni plus ni moins que d'un schéma de données, muni d'opérations. Le formalisme pro-posé par la méthode OMT2 et repris dans UML est celui d'un schéma Entité–Association.3 La définition com-plète des classes d’objets comporte la spécification des opérations effectuées par ces objets.4

La première section du présent chapitre explique les diagrammes proposés par UML pour illustrer les diffé-rents aspects de la collaboration des objets.

La deuxième section décrit le modèle des cas d’utilisation mis au point par I. JACOBSON. Partant de la spé-cification des besoins des utilisateurs, la méthode conduit à ébaucher la structure du système en identifiant lesobjets à mettre en place et leurs collaborations.

La troisième section introduit le concept d’architecture logicielle et l’illustre par deux principes de réalisationtrès en vogue aujourd’hui : l’architecture client / serveur et la définition de motifs ou "patterns" standardi-sés.

1 OMG : Unified Modeling Language Specification, vers. 1.4; www.omg.org, 2002. Voir également P.A.MULLER : Modélisation objet avec UML; Eyrolles, 1997.2 OMT – Object Modeling Technique est la méthode d’analyse mise au point par l’Américain J. RUM-BAUGH et son équipe. Cf. J. RUMBAUGH, al. : Modélisation et conception orientées objet, trad. française;Masson, 1995.3 Cf. chapitre 3.4 Cf. chapitre 3, § 2.2.

Page 180: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-2

1. Schémas d’opérations

1.1. Préambule : unification des méthodes autour du concept d’Objet

Le concept central de la théorie Objet1 est naturellement celui d'objet :

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

La fusion des données et des opérations en un agrégat unique — l'objet — permet aux informaticiens d'utiliserun seul modèle, une seule théorie, à tous les stades de leur travail : depuis l'établissement du schéma concep-tuel de la base de données (schéma d'un domaine d'application) jusqu'à la réalisation effective des program-mes.

Les méthodes précédentes étudiaient séparément les données et les opérations et s'en donnaient des vues —des schémas — qui n'avaient rien en commun. Ainsi, la méthode MERISE2 décrit les données par un schémaEntité–Association3 et les traitements par un schéma dynamique4 centré sur le concept d'événement. Entre —d'un côté — les concepts d'entité, association et attribut, et — de l'autre — les concepts de processus, événe-ment et moniteur, qu'y a-t-il de commun ? Comment assurer la compatibilité de deux visions aussi étrangèresl'une à l'autre ? Dans une conception basée sur les objets, un programme prend l’aspect d’un réseau d'objetsinterconnectés, et les traitements sont décrits comme des échanges de messages entre ces objets, messagesempruntant les voies que constituent les relations identifiées dans le diagramme des classes; voilà qui assurela cohérence de la représentation des données et de la description des opérations.

L'unification des méthodes n'est réelle que là où les outils de réalisation sont eux-mêmes "orientésobjets" car, inévitablement, la conception d'une solution technique préfigure cette solution. C'estaujourd'hui le cas de suffisamment de langages de programmation populaires; ce ne l'est pas encorepour les systèmes de stockage des données : les bases de données "Objet" ne sont pas encore vrai-ment sorties du domaine expérimental. Nous traversons donc une époque de transition, où des pro-grammes respectant de plus en plus souvent le paradigme Objet doivent coexister avec des bases dedonnées qui ne le font pas encore.

1.2. Les diagrammes d’interaction

a) Concepts introductifs

Le fonctionnement d’un système construit à base d’objets est schématiquement celui-ci : une requête émanantd’un objet client demande à un objet serveur d’exécuter une des opérations dont il est capable;5 la méthodeutilisée par l’objet serveur peut comporter l’envoi d’une nouvelle requête à un troisième objet, et ainsi desuite. On dit que les objets communiquent entre eux par des messages de requête. 1 Cf. A. CLARINVAL : Concepts et méthodes de la programmation par objets.2 H. TARDIEU, A. ROCHFELD, R. COLLETTI : La méthode MERISE; éd. d'Organisation, 1989.3 Cf. chapitre 3.4 Cf. chapitre 7.5 Pour cette raison, les opérations "offertes" par un objet sont parfois aussi appelées des services.

Page 181: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-3

(Dans un système d’objets distribués, tel que CORBA1, les objets clients et serveurs sont répartis à travers unréseau de plusieurs machines de types divers.)

Exemples. Puisque tout objet est responsable de son propre état, c’est le COMPTE CLIENT lui-même qui va se créditer du montant d’un paiement; cette opération sera exécutée (ou refusée) enréponse à un message de demande émanant d’un objet PAIEMENT. En vue d’afficher son propreétat, l’objet COMPTE demande à l’objet CLIENT titulaire de lui fournir ses coordonnées. Etc.(L’objet PAIEMENT pourrait être localisé sur une machine et les objets COMPTE et CLIENT, surune autre.)

paiement compte client

1: créditer (montant) 2: coordonnées ()

Les diagrammes d’interaction d’objets schématisent à la fois la structure et le fonctionnement des systèmescomposés d’objets. UML suggère deux formes pour ces schémas : les diagrammes de collaboration, initia-lement proposés par G. BOOCH, et les diagrammes de séquence, initialement proposés par J. RUMBAUGH.

b) Notations communes

Objet

objet : Classe

Un objet est symbolisé par un rectangle.Des occurrences multiples d’une même classe sont symbolisées par des rectangles superposés.Un objet est identifié par une expression de la forme nom_objet :nom_type 2

– une des mentions peut manquer : objet de type indéterminé : nom_objet objet anonyme : :nom_typePour le distinguer d’un identificateur de classe, l’identificateur d’un objet est souligné.

Message

Un envoi de message est représenté par une flèche orientée de l’objet client vers l’objet serveur.Un message complet est libellé sous la forme suivante : nom_opération ( nom_paramètre :type_paramètre ... ) :type_résultatL’émission d’un message peut être soumise à condition : [ condition ] message ou répétitive : *[ boucle ] messagePour refléter la séquence d’exécution, les messages peuvent être numérotés.

1 CORBA — "Common Object Request Broker Architecture", système normalisé défini par l’OMG ("ObjectManagement Group").2 Cette notation est reprise du langage PASCAL.

Page 182: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-4

c) Diagramme de collaboration

Un diagramme de collaboration montre les objets, les liens qui les unissent et les messages qu’ils échangent.

Exemple : programme affichant l’heure sur un cadran analogique et un cadran numérique.

: Programme

: Horloge

: Horodateur

: Cadran Analogique

: Cadran Numérique : Ecran

1: *[boucle] donner_heure ( )

2: attendre (1 sec)3: donner_heure ( )

4: changer (heure)

6: changer (heure) 5: dessiner (figure)

7: écrire (texte)

Parce qu’il répartit les objets dans un espace à deux dimensions, un diagramme de collaboration convient bienà la mise en évidence des relations entre objets.

Illustration : diagramme de classes correspondant à l’exemple ci-dessus

Ecran

dessiner( )écrire( )

Programme

exécuter( )terminer( )

Horodateur

attendre( )donner_heure( )

Horloge

donner_heure( )

Cadran Analogique

changer( )

Cadran Numérique

changer( )

d) Diagramme de séquence

Représentation alternative, un diagramme de séquence visualise le temps sur un axe vertical (la "ligne devie" de chaque objet). Il est possible de préciser par des annotations la chronologie des opérations : duréeet décomposition d'une opération (visualisées sous la forme d’un bandeau vertical), délai séparant deuxopérations, condition d'émission d'un message, boucle répétitive, etc.1

1 En particulier, diverses conventions graphiques permettent d’exprimer les conditions de synchronisation desmessages, requêtes et réponses ...

Page 183: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-5

Exemple : programme affichant l’heure sur un cadran analogique et un cadran numérique.

: Ecran : Programme : Horloge : Horodateur : Cadran Analogique

: Cadran Numérique

1: *[boucle] donner_heure ( )2: attendre (1 sec)

3: donner_heure ( )

4: changer (heure)5: dessiner (figure)

6: changer (heure)7: écrire (texte)

Les diagrammes de séquence permettent d'être plus explicite dans la description du fonctionnement d'un pro-gramme.

Page 184: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-6

2. Le schéma des Cas d’Utilisation

2.1. Préambule : le contexte historique

a) Libéralisation de l'usage des ordinateurs

La vision des choses implicite dans les diagrammes de flux — ordonnancer les tâches constitutives d’un sys-tème —,1 qui fut et reste encore celle des responsables de l'informatique dans la plupart des entreprises,convient bien à un planificateur. Elle relève d'une idéologie centralisatrice et autoritaire (les analystes infor-maticiens n’étaient-ils point naguère souvent affublés du titre d’analystes–organisateurs ?).

En moins d'une décennie, le déferlement des ordinateurs personnels, aujourd'hui parfaitement intégrés au ré-seau "officiel" de l'entreprise, en a révélé les limites. L'informaticien ne formalise plus et n'automatise plustoutes les tâches, mais seulement certaines d'entre elles; en fait, on ne lui demande plus que des outils.

Le concept même de "l'application informatique" est en train de changer. Nous ne fournissons plusà l'utilisateur une application monolithique, souvent dépassée avant même d'être livrée. Nous luidonnons plutôt une "boîte à outils", qui contient tout ce dont il a besoin : application spécifiquebien sûr, mais aussi traitements de texte, tableurs, outils d'interrogation, générateurs d'édition ...

[...]

L'utilisateur est le seul à savoir réellement quel est l'outil qui lui convient et puise dans cette "boîte"le meilleur instrument pour effectuer son travail. Il sait surtout, et c'est le plus important, l'ordon-nancement des actions à effectuer. Il peut réagir et prendre une décision face à un événement parti-culier. Autrefois, il fallait imaginer et coder tous les scénarios possibles. Ceci impliquait nécessai-rement un long délai de fabrication du logiciel, aussi bien lors de la phase de conception que lors dela phase de réalisation.

Prenons un exemple simple. Pour informatiser le processus "accrocher le tableau dans le hall d'en-trée", il faut, pour une action qui est somme toute simple, plus de 30 actions élémentaires. Et lenombre de scénarios et de variantes est bien supérieur pour peu qu'un événement particulier se pro-duise — la mèche se casse pendant le perçage —, avec toutes les autres actions élémentaires quecela comporte : retirer la mèche cassée du trou, choisir une autre mèche ...

Prendre un crayon à papierPrendre un mètreMesurer la largeur du murRepérer le point d'ancrage sur le murChoisir la vis adaptéeChoisir la cheville adaptée à la visChoisir la mèche adaptée à la nature du mur (béton, brique ...) et à la chevillePrendre la perceuseDévisser l'ancienne mècheVisser la mèche choisieRégler la perceuse (percussion, profondeur de la tige de guidage ...)Percer le trouEnlever la poussière du trou

1 Cf. chapitre 7.

Page 185: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-7

Mettre la cheville dans le trouPrendre le marteauEnfoncer la cheville délicatementEnfoncer complètement la cheville avec le marteauPrendre la visPrendre le tournevis correspondant à la visVisser la visPoser le tableauRégler l'horizontalité du tableau

Tel est le contenu des applications informatiques [anciennes]. Quatre-vingts pour cent de la pro-grammation est utilisée (gaspillée ?) à traiter des scénarios qui ne vont que rarement être utilisés,ou bien à résoudre des cas d'erreurs. De plus, le scénario imaginé par le concepteur n'est pas sou-vent celui désiré par l'utilisateur : il a peut-être envie de commencer par régler la perceuse alorsque l'application l'oblige d'abord à saisir le crayon pour repérer le point d'ancrage sur le mur. 1

b) Modernisation des méthodes d’analyse

Les diagrammes de flux sont des outils d’analyse datant de l’époque du traitement par lots (en anglais :"batch processing"). En ces temps héroïques des débuts de l’informatique de gestion (1960–1975), un pro-gramme en exécution était incapable d’interagir avec un utilisateur humain. Les données à traiter étaient doncaccumulées dans des lots enregistrés — on disait : encodés — dans des fichiers "de mouvements" (d’abordsur cartes perforées, plus tard sur bandes magnétiques); le traitement de ces lots était soigneusement planifiéet confié aux opérateurs de la "salle des machines"; les résultats revenaient sous la forme d’épais rapportsimprimés ...

Puis apparut l’informatique interactive ou conversationnelle où l’utilisateur humain, par le truchement d’unterminal à clavier + écran, intervenait directement dans le déroulement des programmes. Les évolutions pa-rallèles de la technologie et des systèmes d’exploitation allaient accorder à l’utilisateur humain "conversant"avec un programme de plus en plus d’initiative et de liberté.

Comme date charnière, on pourrait retenir celle de l’apparition du système de programmation SMALLTALK(1980), pionnier de la programmation par objets et promoteur du style d'interface graphique qui se trouve àl'origine du système Macintosh et de ses imitateurs.

Le modèle des cas d’utilisation, mis au point par le Suédois I. JACOBSON, date de cette seconde époque.2

Plus tard, JACOBSON a rejoint l’équipe des Américains G. BOOCH et J. RUMBAUGH au sein de la sociétéRational Software, apportant à l’équipe la démarche d’analyse qui lui manquait et qui devint le ProcessusUnifié ("Unified Process") pour le développement des logiciels.3

L’optique de l’analyste est profondément renouvelée : plus de tentative de structurer l’enchaînement completde toutes les tâches d’un système; au lieu de cela, chaque cas d’utilisation du système (autrement dit, chaquetâche) est analysé séparément et sa spécification prend la forme d’un ou plusieurs scénarios décrivant la"conversation" de l’utilisateur avec le système. (Les méthodes antérieures, conçues pour la description destraitements par lots, n’évoquaient pas les interventions des utilisateurs dans le traitement de l’information.)

1 J.M.GILLET : L'interface graphique; InterEditions, 1995.2 I. JACOBSON, al. : Object-Oriented Software Engineering : a Use Case Driven Approach; Addison-Wesley, 1992. Comme les précédentes, cette méthode d’analyse a été mise au point une dizaine ou une quin-zaine d’années après les modes d’exploitation et de programmation qu’elle s’applique à décrire ...3 I. JACOBSON, G. BOOCH, J. RUMBAUGH : Le processus unifié de développement logiciel, trad. fran-çaise; Eyrolles, 1999.

Page 186: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-8

2.2. Contenu du modèle des Cas d’Utilisation

"Un système s’adresse en principe à différents types d’utilisateurs, chacun étant identifié en tantqu’acteur. Les acteurs utilisent le système selon les interactions décrites par les cas d’utilisation.Un cas d’utilisation est une séquence d’actions qu’effectue le système afin de produire des résultatssatisfaisants pour l’acteur. L’ensemble des acteurs et des cas d’utilisation constitue le modèle [ouschéma] des cas d’utilisation." 1

a) Système

Comme dans les méthodologies précédentes, le système constitue le référentiel analysé.2

b) Acteur

Un acteur est un utilisateur en situation d’interaction avec le système. On distingue l’utilisateur, être concretindividuel, et l’acteur, qui est un des rôles que peut jouer un utilisateur. L’utilisateur est une réalité, une oc-currence; l’acteur est une abstraction, un type. Un utilisateur peut jouer différents rôles (ex.: une vendeusede grand magasin est également cliente de ce magasin); un même rôle (ex.: client) peut être joué par diffé-rents utilisateurs.

Acteur Vendeur Client

Les utilisateurs d’un système peuvent être des personnes, des machines, un autre système ...

Le mécanisme de généralisation permet de définir des hiérarchies de rôles.

Tiers

Client

Fournisseur

Acteur externe

Un utilisateur conversant avec le système de traitement de l’information peut jouer le rôle de substitut d’unacteur externe; par exemple, l’employé(e) encodant un bon de commande reçu par courrier ou par téléphoneendosse en quelque sorte le rôle du client. Bien que ce client lui-même n’interagisse avec aucun composantparticulier du système d’information, on peut, dans les descriptions abstraites d’un modèle, lui reconnaître unrôle d’acteur.

1 I. JACOBSON, al. : Le processus unifié ...2 Cf. chapitre 6.

Page 187: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-9

Dans d’autres situations — celle d’un client commandant directement via Internet ou celle d’un client au gui-chet automatique d’une banque ... —, l’acteur externe joue lui-même son propre rôle.

c) Cas d’utilisation

La définition d’un cas d’utilisation ("séquence d’actions produisant des résultats satisfaisants pour l’ac-teur") rappelle les deux premiers éléments de notre définition d’une tâche :

(1) un ensemble d'opérations du système,(2) que l’utilisateur alimente en données et dont il attend des résultats,(3) au fonctionnement duquel il affecte des ressources : moment, durée, localisation, machines ...1

Le concept n’est donc pas vraiment neuf. De plus, il est maladroitement défini : les auteurs écrivent aussiqu’un cas d’utilisation regroupe ordinairement "plusieurs séquences d’actions possibles", séquences auxquel-les ils donnent le nom de scénarios. Pour lever cette contradiction, il suffit d’admettre que l’intention del’utilisateur ne se dévoile pas seulement à travers la séquence d’actions déroulée mais également par les res-sources qu’il affecte à la satisfaction de ses besoins; on en arrive ainsi à donner au cas d’utilisation la défini-tion classique d’une tâche.

Un acteur est habituellement impliqué dans différents cas d’utilisation d’un système; ainsi, un client interagitavec le système de vente d’une firme commerciale en lui envoyant des commandes et des paiements.

Cas d'utilisation Commander

Client

Payer

[ressource : la Poste]

[ressource : une banque]

Il arrive qu’un cas d’utilisation implique plusieurs acteurs; normalement, un seul d’entre eux joue le rôled’initiateur, tandis que les autres sont des utilisateurs passifs. Tous ces acteurs ont des besoins que le casd’utilisation doit satisfaire mais, seul, l’acteur initiateur converse (inter–agit) concrètement avec le système.

Vendeur ClientFacturer

initiateur

Le schéma des cas d’utilisation d’un système répertorie les acteurs et les cas d’utilisation de ce système. Mais— différence essentielle avec les diagrammes de flux — il ne cherche pas systématiquement à ordonnancer lescas d’utilisation. Si, par commodité, l’on y opère des regroupements, il ne s’agit que des cas d’utilisationconcernant un même acteur. (Bien sûr, un diagramme doit être commenté et rien n’empêche que le commen-taire indique l’ordre de succession des tâches.)

1 Cf. chapitre 6.

Page 188: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-10

Exemple : cas d’utilisation impliquant le client.

Client

Commander

Vendeur

Payer

Facturer

Comptabilité

d) Scénario

Un scénario est une séquence d’actions possible dans le cadre d’un cas d’utilisation. (En vue de désigner unscénario, l’analyste emploiera donc une expression qualifiée, de la forme scénario de cas ou cas::scénario .)

Par les ressources qu’il concentre (lieu, moment, ordinateur, formulaire d’affichage à l’écran ... et acteur), uncas d’utilisation forme un contexte qui rend possibles différents scénarios et permet de les enchaîner librement,c’est-à-dire sans changer de contexte.

Exemple : gestion du curriculum vitae des travailleurs dans une société de travail intérimaire.

Acteur externe Acteur Cas d’utilisation ScénariosTravailleur Recruteur mise à jour des C.V. remplir un C.V.

corriger / actualiser un C.V.consulter un C.V.imprimer un C.V.

Employeur Placeur consultation des C.V. sélectionner des C.V.impression des C.V. imprimer un C.V.

imprimer une sélection de C.V.

Consultation C.V.

Placeur (Employeur)

Impression C.V.

Recruteur (Travailleur)

Mise à jour C.V.

Page 189: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-11

2.3. Spécification des scénarios

Si le concept de cas d’utilisation n’est pas vraiment neuf, ce qui l’est, en revanche, c’est la manière de les dé-crire. Eclose à l’ère de l’informatique interactive, la méthode d’analyse explicite les actions de l’utilisateurautant que celles du système ... alors que la définition traditionnelle d’un processus énonce que celui-ci "reçoit et émet des messages, obtient et met à jour des données",1 en ignorant complètement l’utilisateur.

a) Flot d’événements

Satisfaire les besoins d’un utilisateur : telle est la fonction, l’utilité d’un cas d’utilisation. Les auteurs de laméthode préconisent de spécifier ces besoins fonctionnels en décrivant l’interaction — la conversation — dusystème avec l’acteur initiateur du cas d’utilisation. "Les cas d’utilisation permettent aux utilisateurs destructurer et d’articuler leurs désirs; ils les obligent à définir la manière dont ils voudraient interagir avec lesystème, à préciser quelles informations ils entendent échanger et à décrire ce qui doit être fait pour obtenirle résultat escompté. [...] [Les cas d’utilisation] se décrivent en termes d’informations échangées et d’étapesdans la manière d’utiliser le système." 2 (Il n’est sans doute pas inutile ici de rappeler qu’un acteur peut êtreune machine, par exemple un autre ordinateur ...)

Cette interaction est vue comme une succession de messages échangés de l’un à l’autre — un message est uneentité d’information décrivant un événement.3 Mais, parce que le mot message possède en programmationpar objets une signification technique particulière (requête d’un objet client à un objet serveur, visant à acti-ver une opération caractéristique de ce dernier), les auteurs parlent ici plus vaguement de flot d’événements.Précisément, un flot d’événements décrit un scénario d’utilisation; un cas d’utilisation peut présenter diffé-rents scénarios dont chacun sera décrit séparément.

Un flot d’événements est visualisé sous la forme d’un diagramme de séquence simplifié, qui ne mentionneque deux "objets" : l’acteur initiateur et "le système". Ce diagramme est appuyé par une description "litté-raire" plus explicite.

Exemple : scénario : enregistrement d’une commande–client reçue au téléphone.

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

1 Cf. chapitre 7, section 1.2 P.A. MULLER : op. cit.3 Cf. chapitre 7, section 2.

Page 190: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-12

b) Diagramme de séquence

: Client : Téléphoniste : Système

mise à jourde la ficheClient

s'identifierdemander la fiche

montrer la fiche (ou une fiche vierge)

lire la fiche

signaler les mises à jourencoder les mises à jour

enregistrer la fiche

préparer laprise decommande

préparer une commande vierge

montrer le formulaire de commande

ouvrir la fenêtre de sélection des produits

ligne à ligne...

désigner le produit désiré

rechercher le produit dans la liste

donner prix et disponibilité

indiquer la quantité désiréeencoder la quantité

enregistrer la ligne

fin decommande

calculer le total facturable

afficher le total facturable

etc...

2.4. Relations entre cas d’utilisation

La description des différents scénarios fera ressortir des séquences d’opérations communes à plusieurs casd’utilisation. Afin de limiter les redondances, ces séquences communes seront extraites et décrites sous laforme de cas d’utilisation séparés susceptibles d’être réutilisés par les cas d’utilisation originaux; apparaîtrontalors des relations entre cas d’utilisation.

Page 191: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-13

a) Relations concrètes

Utilisation

Un cas d’utilisation peut en utiliser (sic) un autre : un scénario du premier peut inclure un scénario du se-cond (de la même manière qu’en programmation par objets, un objet peut en "utiliser" un autre auquel il estassocié : une opération du premier peut invoquer une opération du second).

Exemple. Pour enregistrer un bon de commande, l’employé commence par demander au système lafiche signalétique du client; si elle n’existe pas, il en crée une qui reprend les données apparaissantsur le bon de commande; si elle existe mais que l’adresse du client ait changé, il modifie l’adressementionnée sur la fiche signalétique ... Toutes ces opérations relatives à la fiche signalétique d’unclient peuvent être effectuées indépendamment de l’enregistrement d’un bon de commande; ellesfont partie des scénarios du cas d’utilisation "Gérer les fiches Client".

symbole de la relation "utilise"

Encodeur

Enregis trer Commande

Gérer fiche Client

Extension

On peut créer une variante d’un cas d’utilisation en lui ajoutant sous condition quelques opérations présentéessous la forme d’un cas d’utilisation qui étend les fonctionnalités du cas de base.1 (Le diagramme de séquencedétaillant le scénario du cas de base doit mentionner la condition d’insertion des opérations complémentaires.)

Exemple. Une transaction commerciale effectuée via Internet doit être sécurisée !

Sécurisation de la Transaction

ClientPaiement

<<étend>>

en cas de paiement électronique

1 Le couple cas général + extension définit un cas spécialisé. Le verbe "étend" possède ici le même sens quedans le langage de programmation JAVA : dérivation d’un sous-type par complétage de la définition d’untype de base.

Page 192: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-14

b) Relations abstraites

Inclusion

Il est possible d’isoler dans un cas d’utilisation séparé, comme dans une espèce de sous-programme, certainesopérations communes à plusieurs cas d’utilisation réels. Un tel cas d’utilisation, non directement utilisable parun acteur et qu’on peut donc qualifier d’abstrait, est mis en évidence dans le but de faciliter le travaild’analyse. Au lieu de parler ici d’une relation "utilise", certains auteurs parlent d’inclusion.

Exemple. Beaucoup de scénarios comportent une séquence initiale d’identification de l’utilisateur :demande et vérification du nom et du mot de passe. Ces opérations peuvent être isolées dans un casd’utilisation abstrait.

LambdaIdentifier Utilisateur

<<inclut>>

<<inclut>>

Acteur Cas d’utilisation ScénariosUtilisateur λ Identification Utilisateur vérifier l’identification

modifier le mot de passe

Généralisation

Il est parfois possible de regrouper sous la forme d’un cas d’utilisation générique abstrait les éléments com-muns à différents cas d’utilisation concrets. Cette relation de généralisation est analogue à celle qui existeentre certains types d’entités ou classes d’objets.

Exemple. Les interventions d’un garagiste sur un véhicule sont de deux sortes : entretien et répara-tion. Les deux cas ont beaucoup de choses en commun : prestations de mécaniciens, fournitures depièces et de consommables, etc.; ces éléments communs sont regroupés dans un cas d’utilisationabstrait Intervention.

Intervention

Entretien

Garagiste

Réparation

symbole de la relation de généralisation

Page 193: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-15

2.5. Analyse des cas d’utilisation : du scénario aux objets

L’analyse des cas d’utilisation consiste à extraire de l’étude des scénarios la spécification des composants dela solution technique à mettre en œuvre. Ces composants sont présentés dans des classes d’analyse préfigu-rant les classes d’objets que pourrait définir la programmation (mais elle pourra aussi recourir à d’autrestechniques de réalisation ...).

a) Classification des composants

L’architecture Modèle–Vue–Contrôleur (SMALLTALK)

Pionnier dans le domaine de la programmation par objets, le système SMALLTALK (1980) a notammentlégué aux informaticiens un principe d'architecture des programmes que, désormais, toutes les méthodolo-gies proposent tel quel ou plus ou moins adapté. Ce principe d'architecture répartit en trois catégories les ob-jets intervenant dans un programme : modèles, vues, contrôleurs.

[1] Des objets tels que Client–Produit–Commande–Facture sont des "modèles" abstraits de l'informationgérée par une application; dans d'autres domaines, on trouvera les modèles Employé–Salaire, Avion–Pilote–Vol–Réservation, Température–Pression, etc. [2] Une liste à l'écran, un imprimé et même le contenu d'un fi-chier sont des vues ou représentations. Un modèle peut avoir plusieurs représentations (ex.: un tableau dechiffres et un graphique, une fiche à l'écran et une liste imprimée). Chacun de ces objets détient — et lui seuldétient — toutes les opérations qui constituent son comportement : les modèles abstraits sont responsablesdes opérations de calcul, les vues sont responsables des opérations de mise en forme.

[3] Les contrôleurs, par exemple un gestionnaire de menus ou un éditeur de textes, gèrent les enchaînementsdynamiques; ils agissent pour que les différents objets du programme se trouvent toujours dans un état cohé-rent, en particulier pour que l'état d'un modèle et l'ensemble de ses représentations se reflètent correctement.[4] La méthode OMT1 regroupe dans une catégorie distincte les dispositifs d'entrée–sortie, tels que les ges-tionnaires de la souris, du clavier, des fichiers, du réseau ..., qui sont habituellement des objets standards pré-définis.

Exemple : diagramme des classes d’objets intervenant dans un programme d’affichage de l’heure.

Programme

exécuter( )terminer( )

<<control>>

Horodateur

attendre( )donner_heure( )

<<model>>

Cadran Analogique

changer( )

<<view>>Horloge

donner_heure( )

<<control>>

Ecran

dessiner( )écrire( )

<<output>>

Cadran Numérique

changer( )

<<view>>

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

Page 194: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-16

REMARQUE. A proprement parler, une fenêtre d’interface graphique est un dispositif d'entrée–sortie, géré par des opérations standards (montrer, cacher, déplacer ...), et c'est le texte formaté(dans telle couleur, dans telle police, en gras, en italique ...) apparaissant dans cette fenêtre quiconstitue la vue. Une fenêtre contient souvent aussi l’un ou l’autre contrôleurs — ou, plus exacte-ment, des vues de l’un ou l’autre contrôleurs —, tels que des boutons poussoirs.

Les classes d’analyse (JACOBSON)

Dans sa méthode, I. JACOBSON préconise de répartir les composants du système dans des classes d’analyse.Ces classes ne sont pas nécessairement déjà les classes d’objets de la programmation; elles ne font que lespréfigurer. (On "tirera" souvent plusieurs classes d’objets d’une seule classe d’analyse. Qui plus est, laréalisation pourra recourir à d’autres techniques que la pure programmation par objets.1)

Exemple. Une classe d’analyse pourrait être la classe Formulaire de mise à jour des fiches Client.Le programmeur réalisant cette interface graphique y "découpera" plusieurs objets : une barre demenus, une liste de sélection, un panneau de présentation et mise à jour de la fiche, des boutons decommande, etc.

menusliste fiche

Les classes d’analyse se répartissent elles-mêmes en trois catégories correspondant aux trois catégoriesd’objets de SMALLTALK :

SMALLTALK I. JACOBSON symbole

Model Entity

View Boundary

Controller Control

• Une classe d’entités n’est rien d’autre qu’un type d’entités dégagé par l’analyse préalable du domained’application.2 La plupart des entités sont des objets persistants, conservés dans des fichiers ou une base dedonnées.

NOTE. Les acteurs externes (clients, fournisseurs ...) sont souvent décrits par des entités internesau système ("fiches" clients, "fiches" fournisseurs ...).

REMARQUE. L’analyse anticipée de quelques cas d’utilisation particulièrement "représentatifs"peut aider l’analyse du domaine d’application à découvrir des classes ou types d’entités.

1 Cf. infra, § 3.2 Cf. chapitre 3.

Page 195: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-17

• Un objet d’interface ou de frontière ("boundary") est un dispositif d’échange entre le système et sesutilisateurs, y compris les acteurs passifs. Cette catégorie regroupe les vues mais aussi certains dispositifsd’entrée–sortie (écrans, imprimantes, lecteurs de codes à barres, etc.) mentionnés au paragraphe précédent.

• Un objet contrôleur coordonne l’intervention de différents autres objets dans le déroulement d’un ouplusieurs scénarios. On identifiera au minimum un contrôleur par scénario.

Commentaires

Tout composant du système à réaliser est défini par une classe. Il constitue une ressource le plus souventpartagée par plusieurs scénarios et même par plusieurs cas d’utilisation.

Exemple : usage de quelques classes dans la gestion des C.V.

Entité Frontière Frontière FrontièreCas d’utilisation Scénarios C.V. liste sélect. formulaire fichemise à jour des C.V. remplir un C.V. x x

corriger / actualiser un C.V. x x xconsulter un C.V. x x ximprimer un C.V. x x x

consultation des C.V. sélectionner des C.V. x ximpression des C.V. imprimer un C.V. x x x

imprimer une sélection de C.V. x x x

☛ Il arrive qu’un analyste hésite entre scénario et cas d’utilisation : tel sous-ensemble d’opérationscompose-t-il un scénario ou un cas d’utilisation ? Cette confusion n’a pas beaucoup d’importance;en tout cas, elle n’a pas d’impact sur la réalisation du système, puisque celui-ci sera formé de compo-sants qui transcendent aussi bien les cas d’utilisation que les scénarios.

b) Diagramme de collaboration

L’analyse d’un cas d’utilisation consiste à transformer la spécification des scénarios qui le composent en dia-grammes de collaboration entre objets et à décrire ces objets. Les objets dont il est ici question sont desobjets "d’analyse" définis par des classes d’analyse, pas encore nécessairement des objets à réaliser tels quels.

METHODE

1) Le diagramme de séquence décrivant un scénario identifie les messages échangés entre "le système" et unacteur. Il s’agit maintenant d’identifier, à l’intérieur du système, l’objet émetteur ou récepteur de chacun desmessages.

2) Parallèlement, l’examen détaillé du contenu des messages fera ressortir les attributs des différents objets.

Page 196: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-18

Pour démarrer, il est pratique de disposer d’un canevas d’analyse, tel que celui proposé par P.A. MULLERpour l’analyse des programmes comportant une interface homme–machine.1

Une classe d’entités fournit des méthodes pour obtenir() et mettre_à_jour() les valeurs.A chaque type d’entité Ent sont associées deux fenêtres dotées d’opérations standards : – une fiche F_Ent et une liste L_Ent.2

menusliste fiche

La fiche F_Ent, avec ses méthodes montrer() et cacher(), présente à l’écran le contenu dé-taillé d’une occurrence Ent. La liste L_Ent, dont l’utilité est de permettre de sélectionner()une fiche, montre seulement quelques données de chacune des entités d’une collection.3

Objet

Contrôle Frontière

Entité

obtenir( )mettre à jour( )

Fenêtre

montrer( )cacher( )

Liste

sélectionner( )

F_Ent

L_Ent

Ent

**

standard-----------------------------------------------------------------------------------------------------------application

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

Page 197: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-19

Exemple : scénario : enregistrement d’une commande–client reçue au téléphone (cf. § 2.3.)

Contrôle Contrôle Frontière Entité Frontière

: Enreg. Commande

: Mise à jour fiche Client

: Création Commande

: L_Client

: F_Client : Client

: F_Commande

: L_Produit

: Commande

: Produit

: Base de Données

1: exécuter ( )

9: exécuter ( )

2: montrer ( )3: sélectionner ( )

4: montrer ( )6: remplir ( ) 5: obtenir ( )

7: mettre à jour ( )

8: enregistrer ( )

10: montrer ( )16: remplir ligne ( )

11: créer ( )12: obtenir ( )

17: mettre à jour ( )

13: montrer ( )14: sélectionner ( )

15: obtenir ( )

18: enregistrer ( )

c) Diagramme des classes "conceptuelles"

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

Page 198: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-20

3. Conception d’une architecture logicielle

3.1. Nature de la démarche de conception

Risquons un parallèle avec la modélisation des données. L’analyse des données livre d’abord un schémaconceptuel, sémantique, articulé autour des concepts d’entité, association, attribut et identifiant; ce schémadoit être transformé en schéma logique, c’est-à-dire réinterprété en termes de technologie, d’objets réalisa-bles : enregistrements et clés d’accès, par exemple. Le même genre de démarche doit s’appliquer ici : lesschémas d’opérations dont nous disposons à ce stade sont du niveau conceptuel; ils doivent être coulés dansles éléments d’une architecture matérielle et logicielle. Dans les méthodes américaines, cette seconde étape dela démarche est connue sous le nom de design, ce que l’on traduit en français par le terme conception.

Cependant, la situation est ici très différente. Alors que, de nos jours, les systèmes de gestion de bases dedonnées (SGBD) les plus usités sont assez uniformes (ils se conforment presque toujours au modèle rela-tionnel sous-jacent au langage SQL), les moyens de réaliser les opérateurs techniques de traitement de l’infor-mation sont de plus en plus variés.

Il est donc nécessaire, fondamental même, de d’abord tracer sa voie : avant d’être mise en œuvre,une solution technique doit être conçue ! Il s’agit, en premier lieu, de fixer des objectifs de qualitétechnique tels que "la clarté, la capacité de réaction aux futurs changements et la réutilisation",1

et d’opérer des choix techniques de portée générale.

La conception [...]

Comme l'analyse et la conception, la conception et la réalisation se chevauchent en partie. Il estrare 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 secomplè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 obtenusdurant l'analyse. Il s'agit là d'une vision fortement réductrice qui ignore tout simplement que laconception est le temps de la mise en œuvre du savoir-faire. Ce savoir-faire peut être interne auprojet ou acquis à l'extérieur sous la forme d'outils, de composants réutilisables ou plus largementde cadres de développement.2 [...]

La conception débute par la détermination de l'architecture du logiciel, c'est-à-dire par l'élabora-tion des structures statiques et dynamiques qui serviront de charpente pour l'ensemble du dévelop-pement. L'architecture définit la forme générale de l'application; de sa qualité dépendent le déve-loppement et l'évolution du logiciel. L'architecture est la conséquence de décisions stratégiques ar-rêtées lors de la conception et de décisions tactiques prises en cours de réalisation.

1 I. JACOBSON, G. BOOCH, J. RUMBAUGH : op. cit.2 "Frameworks".

Page 199: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-21

Se donner une stratégie informatique, c'est considérer le logiciel comme un élément déterminant dudéveloppement de l'entreprise; c'est aussi chercher à s'assurer une avance technologique par deschoix 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 avecl'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 uneorganisation, depuis la définition de la ligne de produits jusqu'au développement de ces produits;• l'unicité de langage pour l'ensemble des développements (Ada dans le cas du ministère de la dé-fense américain);• l'indépendance par rapport aux dispositifs d'affichage, autrement dit, le découplage entre l'in-formation à afficher et la manière de l'afficher;• la portabilité des sources, voire des exécutables, qui réduit notablement les coûts de développe-ment et surtout de maintenance dans le cas d'un logiciel multicibles.• la généralisation des mécanismes de communication entre objets qui permet de rendre transpa-rente la localisation des objets et ainsi de faciliter la distribution des applications et de leurs compo-sants.

La conception est le domaine du compromis. Il n’existe pas de solution toute blanche ou toutenoire : la vérité est toujours quelque part dans le gris. Les décisions tactiques couvrent toutes lesactivités qui guideront la recherche de cette vérité dans l’effort de développement au jour le jour.Elles contiennent par exemple les éléments suivants :

• la généralisation d’abstractions et de mécanismes pour les tâches ancillaires, autrement dit, tousles composants largement réutilisables dans les programmes, comme les dates, les chaînes de ca-ractères, les structures de données de base, les algorithmes de tri, etc.;• le traitement des erreurs qui peut être effectué par des exceptions ou par des statuts exprimés sousla forme de valeurs entières. L’exception ne peut être ignorée, mais son traitement obscurcit le codenormal. Le statut d’erreur est simple à mettre en œuvre mais il peut être ignoré : le traitement del’erreur n’est alors pas garanti;• la gestion de la mémoire dynamique qui peut être effectuée par le programmeur ou automatiséepar l’environnement d’exécution;• la communication entre processus qui peut reposer sur des liaisons point-à-point, multi-points oupar diffusion. Elle peut être assurée par des mécanismes ad hoc ou inscrite dans un schéma générald’intégration d’application comme CORBA ou ActiveX;• le choix des modes de communication qui inclut la forme et la nature des messages et les diffé-rents modes de synchronisation : synchrone, semi-synchrone, dérobante, minutée, asynchrone, etc;• la présentation des messages utilisateur afin de rendre toutes les interactions avec l’utilisateur leplus homogènes possible;• les langages de programmation qui sont compilés ou interprétés et présentent des points forts etdes limites. Les langages compilés permettent d’écrire des programmes plus fiables, les langagesinterprétés apportent plus de souplesse lors du développement. Dans certains cas, il peut être inté-ressant de mélanger différents langages au sein de la même application;• le choix des structures de données et des algorithmes qui sont encapsulés dans les objets afin dedécoupler la spécification de la réalisation des classes;• l’optimisation du réseau de relations qui reflète les besoins de communication de l’utilisateur. Leconcepteur peut être amené à modifier ce réseau pour diverses raisons : optimiser la vitesse des ac-cès, prendre en compte des contraintes particulières de réalisation, comme l’absence de lien bi-directionnel dans les langages de programmation de troisième génération;

Page 200: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-22

• la mutation de certaines relations de généralisation parce que l’héritage multiple n’est pas dis-ponible dans le langage de programmation utilisé ou encore parce que la forme de généralisationrecherchée doit être dynamique alors que l’héritage est statique;• la mise en œuvre de composants réutilisables dans le cadre de deux réalités : la programmationavec la réutilisation et la programmation pour la réutilisation. La première forme de réutilisationconsiste à incorporer un composant existant et ainsi à accélérer un développement en cours. Ladeuxième s’apparente plus à un investissement : le coût est immédiat et les bénéfices ne sont perçusque plus tard.

L'effort développé en conception est plus ou moins important selon la nature de l'application et la ri-chesse de l'environnement de réalisation. Il est de plus en plus possible d'effectuer un transfert decomplexité des applications vers les environnements [de développement], grâce à une factorisationdes éléments et des mécanismes communs. C'est le cas dans les familles d'applications bien cibléesdans un domaine donné, comme les logiciels clients qui interagissent avec des serveurs de bases dedonné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 del'originalité. Toutes les applications finissent par se ressembler, ce qui est bien et mal à la fois. Letravers des outils RAD est d'encourager à faire vite et salement — quick and dirty — plutôt que viteet bien.

Curieusement, le RAD est un mélange de génie logiciel dans sa conception et d'horreur informatiquedans son utilisation. Ceci est la conséquence d'une vision à court terme des utilisateurs pour quiseul 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 construitde 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é deréutilisation, ouverture et solution clé en main, vision à court terme (la tactique) et vision à longterme (la stratégie). 3

3.2. Le concept d’architecture logicielle

Le texte ci-dessus évoque le concept d’architecture logicielle. Voyons plus concrètement en quoi celaconsiste.

1 RAD — "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il préconisa, en1991 (é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 à voirensuite les équipes de développeurs accumuler les retards et dépasser toutes les prévisions budgétaires ... fixerle 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 faireexploser les budgets, restreindre s'il le faut les ambitions du projet ... Le temps ayant passé, on a oublié cetteproposition "révolutionnaire" pour ne retenir que la suggestion de choisir des outils performants.2 Les outils de développement rapide (ex.: WinDev, PowerBuilder, Delphi, C++ Builder et d'innombrablesautres "studios" de "visual programming") jouissent actuellement d'une grande vogue, qu'explique le seulqualificatif "rapide". On en indique ici les limites et les pièges.3 P.A. MULLER : op. cit.

Page 201: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-23

Le concept d’architecture logicielle représente les aspects statiques et dynamiques les plus signifi-catifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par lesutilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation. Elle subit,néanmoins, l’influence d’autres facteurs, tels que la plate-forme sur laquelle devra s’exécuter lesystème (par exemple, l’architecture matérielle, le système d’exploitation, le système de gestion desbases de données, les protocoles de communication réseau), les briques de base réutilisables dispo-nibles pour le développement (par exemple, une infrastructure préfabriquée (framework) [...]pour les interfaces utilisateur graphiques), les considérations de déploiement, les systèmes existantset les besoins non fonctionnels (par exemple, les performances, la fiabilité).

[...]

Les architectes vont donc "couler" le système dans une forme. Cette forme (l’architecture) doit êtreconçue de façon à permettre l’évolution du système, non seulement dans le cadre de son développe-ment initial, mais dans les années et les générations à venir. Pour déterminer une telle forme, lesarchitectes doivent travailler à partir d’une compréhension générale des principales fonctions, c’est-à-dire des principaux cas d’utilisation du système. Ces cas d’utilisation peuvent ne représenter que5 à 10 % de tous les cas d’utilisation du système, mais ils sont les plus significatifs, ceux qui consti-tuent le cœur même des fonctions du système. En clair :

• L’architecte crée une ébauche grossière de l’architecture, en partant de l’aspect qui n’est paspropre aux cas d’utilisation (par exemple, la plate-forme). Bien que cette partie de l’architecturesoit indépendante des cas d’utilisation, l’architecte doit avoir une compréhension globale de ceux-ciavant d’esquisser l’architecture.

• Il travaille, ensuite, sur un sous-ensemble des cas d’utilisation identifiés, ceux qui représentent lesfonctions essentielles du système en cours de développement. [...]

• L’architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des casd’utilisation, qui favorisent, à leur tour, le développement d’un nombre croissant de cas d’utili-sation.

Ce processus se poursuit jusqu’à ce que l’architecture soit jugée stable. 1

3.3. Le principe d'architecture « Client / Serveur »

a) Etat de l’art des développements informatiques

« L’informatique éclatée »

Naguère, la confection d'un programme était un processus uniforme : ayant à sa disposition une "page blan-che", un seul langage de programmation — a fortiori, un seul mode de pensée ou paradigme — et un ordina-teur unique, le programmeur concevait intégralement et dans ses moindres détails un algorithme de résolution,le codait dans son unique langage et faisait exécuter le tout dans un environnement — l'ordinateur — immua-ble et familier. L'équipe de programmation était la seule autorisée à fournir des programmes et il n'était pascourant d'acheter un logiciel d'application "standard", par exemple de comptabilité, qui ne fût pas complète-ment "pensé et confectionné maison".

1 I. JACOBSON, G. BOOCH, J. RUMBAUGH : op. cit.

Page 202: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-24

Cette situation n'a plus cours. Pour reprendre le titre d'un livre : nous sommes entrés dans l'ère de "l'informa-tique éclatée".1

Le problème est maintenant de répartir les éléments d'une solution informatique sur les composants multifor-mes d'une infrastructure matérielle et logicielle disparate.

Outils avancés

Le besoin de toujours plus grande qualité, en particulier dans la convivialité de l'interface homme–machine etdans l'intégrité des données, contraint les informaticiens à recourir à des systèmes logiciels spécialisés pour lagestion des interfaces et des bases de données.

Ces systèmes sont si sophistiqués et leur programmation si complexe qu'ils s'accompagnent d'outils de pro-grammation, qualifiés "de quatrième génération", dont le paradigme déclaratif2 apporte une grande facilité deprogrammation et de mise au point.

Il s'ensuit que les moyens mis en œuvre pour le développement mais aussi l'exploitation des applications in-formatiques sont aujourd'hui hétérogènes. Il devient donc nécessaire de répartir la programmation entre lesdifférents outils. Quelle règle adopter pour cette répartition ? Outils hétérogènes et multiples, dont la duréede vie n'est pas la même ... Lorsque, pour une raison quelconque, on est amené à remplacer un outil par unautre, il faudrait idéalement qu'un minimum de programmation doive être refait.

Tout cela entraîne la nécessité de définir des principes d'architecture du logiciel, visant essentiellement à don-ner des règles de répartition de la programmation. En complément, il est nécessaire de dire comment analyserles éléments ainsi mis en place.

b) Définition de l’architecture Client / Serveur

Un système informatique construit selon une architecture client/serveur est un système dans lequel un pro-gramme client adresse des requêtes à un programme serveur, lequel effectue pour le client les services de-mandés. Ces deux programmes s'exécutent simultanément et communiquent directement entre eux, d'unemanière asymétrique : l'initiative des requêtes appartient exclusivement au programme client.

Habituellement, un programme serveur est capable de servir plusieurs clients en même temps. De plus en plussouvent, les programmes serveur et clients s'exécutent sur des ordinateurs différents interconnectés : le ser-veur s'exécute sur l'ordinateur central d'un réseau, les clients se trouvent sur les stations personnelles de ceréseau (ce peut être le réseau INTERNET). Par extension, les qualificatifs "client" et "serveur" s'appliquentégalement aux ordinateurs. Lorsqu'un serveur est incapable de satisfaire une requête, il peut parfois transférercelle-ci à un autre serveur, auquel il est lui-même relié dans un réseau de serveurs.3

c) Règle de répartition

La répartition des fonctions logicielles devrait théoriquement se faire en trois lots, conformément au schémasuivant :

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

Page 203: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-25

logiciel client(requêtes)

logiciel serveur(services)

gestionnaires d'interfaces bibliothèques de fonctions SGBDscénarios procédures d'application serveur de données– gestion d'écran– travail par lots ("batch")– édition de rapports– édition de graphiques– tableur– navigateur Web

– "calculs"– algorithmes

– structures– relations invariantes

ordinateurs clients ordinateurs serveursTout objet classé dans une colonne quelconque peut adresser des requêtesaux seuls objets classés dans la colonne située immédiatement à sa droite.

• La clé de voûte d'une architecture telle que celle schématisée par cette figure est celle-ci : la même procé-dure d'application (par exemple, d'établissement d'une facture) doit pouvoir "servir" différentes interfacesclientes, à la même époque ou à des époques successives (est-ce rêver que d'imaginer que les procéduresd'une application de comptabilité ou de gestion des ventes ou des stocks puissent survivre à une modificationd'interface ?).1 Il n'y a pas souvent nécessité qu'une procédure servante ne puisse s'exécuter qu'à travers unseul scénario. Les différentes sortes de "guichets" d’une banque en sont une démonstration évidente : lesmêmes opérations, par exemple un virement de compte à compte, peuvent être demandées au guichetier d’uneagence bancaire ou directement effectuées par le client à un guichet automatique, via Internet ou au moyend’un combiné téléphonique ...

• Idéalement, le logiciel d'interface ne devrait comporter, outre les opérations strictes de présentation (cons-titution des lots, mise en page du formulaire, du rapport, du graphique, de l'hypertexte ...), que les déclen-cheurs des procédures d'application.2 Un "programme" à l'écran, d'impression ou de traitement par lots de-vrait être perçu et construit comme un séquenceur de procédures d'application.

• Le logiciel (SGBD3) serveur de données assure la cohérence des données, en conservant les élémentsd'information et en garantissant leurs relations invariantes (contraintes et "triggers").4 Certains SGBD per-mettent également de stocker les procédures d'accès aux données (ces procédures sont purement utilitaires etleur identification n'est pas cruciale).

La répartition sur trois niveaux que nous venons de décrire caractérise la seconde génération (±1995) des architectures client–serveur. Dans la première (± 1980), on ne distinguait que deuxcomposants : le SGBD serveur de données et ... le reste. Lorsque ce "reste" a été porté sur des ordi-nateurs personnels (± 1990), il a pu profiter d'outils de "programmation visuelle" pour la réalisationdes interfaces d'utilisation. Le bénéfice de ces outils fut double : la qualité de la présentation auxutilisateurs et le développement rapide des programmes (RAD — "rapid application development");mais ce dispositif n'a pas rendu les solutions évolutives, car les procédures d'application restaientempêtrées dans la gestion des interfaces.

1 La pression du marché des technologies informatiques fait que les entreprises ne sont pas entièrement maî-tresses de l'évolution des interfaces à travers lesquelles elles doivent "servir" leurs données et procédures.2 Ainsi défini, le logiciel d’interface rassemble donc des vues et des contrôleurs, selon la terminologie deSMALLTALK. Cf. supra, § 2.5.3 SGBD : Système de Gestion de Bases de Données.4 Cf. chapitre 5.

Page 204: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-26

A présent que s'est imposé le principe d'une répartition "three tiers" sur trois étages (et parfois da-vantage ...), les programmeurs doivent lutter contre la tentation de facilité qui consiste, sous prétextede "développement rapide", à se servir des seuls outils visuels et à produire encore des solutions "àl'ancienne" dans lesquelles les procédures d'application ne forment pas un ensemble distinct. La cou-che intermédiaire met en œuvre le principe de masquage des données;1 elle garantit l’intégrité et laconfidentialité des données.2 La sécurité des données pourra encore être accrue si les données, d’unepart, et les procédures, d’autre part, sont hébergées sur des ordinateurs distincts.

d) Variété des paradigmes de programmation

La multiplicité des outils intervenant aujourd'hui dans une solution informatique de qualité entraîne le recoursà des paradigmes de programmation variés (la pensée du programmeur n'est plus uniforme !).

• Les SGBD relationnels, les plus employés actuellement, utilisent le langage standardisé SQL, de style dé-claratif :

– les requêtes (SELECT) définissent sous la forme prédicative l'ensemble résultat produit par un al-gorithme implicite;– les contraintes et assertions, elles aussi exprimées sous une forme prédicative, font l'objet d'une vé-rification automatique;– les déclencheurs ("triggers") définissent des procédures dont l'activation est automatique.

• Les gestionnaires d'interfaces ont leur propre logique et leurs propres outils. La plupart utilisent aujour-d'hui des "studios" de programmation visuelle : pour l'essentiel, le programmeur dessine le résultat qu'il sou-haite. Souvent, ces outils visuels sont greffés sur un squelette de programme ("framework" = charpente)sous-jacent et, plus d'une fois, le programmeur doit affiner le code "grossier" qu'ils génèrent.

A application framework is a set of classes that cooperate closely with each other and together em-body a reusable design for a general category of problems. The most common use of applicationframeworks is in the creation of graphical user interfaces, or GUI applications [...]. However theconcept has applicability beyond the development of user interfaces. [...] An example might be theModel–View–Controller framework in Smalltalk [...].

The framework dictates the overall structure of the application. It describes how responsibilities arepartitioned between various components, and how these components must interact with each other.The benefit of a framework then is that the designer of a new application need only concentrate onthe specifics of the problem at hand. Previous design decisions embodied in the structure of the fra-mework need not be reexamined, nor does the code provided by the framework need to be rewritten.

[...]

However, the fact that the overall design has already been laid out by the creator of the frameworkis also a weakness, because in providing the structure of an application the framework severelyconstrains the way in which new applications are allowed differ from each other. [...]

1 Cf. chapitre 3, § 2.2.2 Les outils de développement rapide génèrent automatiquement des requêtes d’accès direct aux bases de don-nées. C’est donc un effort considérable que les programmeurs doivent fournir pour les neutraliser et les rem-placer par des requêtes sécurisées adressées aux procédures masquantes.

Page 205: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-27

The use of a application framework usually leads to an inversion of control between the new appli-cation-specific code and the library-supplied code. In a traditional application, application specificcode defines the overall flow of execution through the program, occasionally invoking library routi-nes in order to execute some specific function (such as a mathematical routine or an input/outputoperation).

In a application framework, on the other hand, the flow of control is dictated by the framework andis the same from application to application. The creator of a new application merely changes theroutines invoked by the framework, but does not change the overall structure. Thus, the frameworkhas the dominant position and the application-specific code is reduced to a secondary position. 1

• Les procédures d'application — qu'il vaut mieux n'intégrer ni au dictionnaire de la base de données ni auxobjets d'interface — ne peuvent, dans une architecture éclatée, qu'être modulaires; au contraire des program-mes anciens, elles ne renferment aucun scénario d'exécution. Elles sont donc réalisées sous la forme de sous-programmes ou, mieux, de classes d'objets. Cette programmation possède donc encore la forme traditionnelledes langages de 3e génération, quand bien même il s'agirait de langages orientés objets.

3.4. Motifs architecturaux ("Patterns")

Dans la conception des solutions aux différents problèmes qu'il doit traiter, tout programmeur, tout groupe deprogrammeurs a ses habitudes, manifestations de son savoir-faire. C'est ainsi que l'on retrouve dans l'œuvre detout programmeur des parties de solutions de structure identique — en programmation par objets, il s'agit decombinaisons de classes ou d'objets —, qui se répètent fréquemment comme autant de motifs architecturaux(en anglais : "patterns"2). Certains de ces motifs sont si généralement utilisés par la corporation des pro-grammeurs, qu'ils reflètent un état de l'art collectif.3

Il est intéressant d’"institutionnaliser" ces manières de faire : le choix et la définition des motifs architectu-raux — cela va de soi — relèvent de l’architecte ! Rendre communs (en d’autres termes, standardiser) les"patterns" d’une équipe, c’est faire profiter tout le monde du savoir-faire des pionniers, c’est gagner du tempsde recherche et de mise au point, c’est rendre compréhensible et échangeable le travail de tous ...

Exemples

L’architecture client–serveur est un exemple fort de motif architectural.

Au sein d'une architecture Modèle–Vue–Contrôleur, le couple modèle–vue est un motif que l'on peut ré-aliser de différentes manières. Une façon assez rudimentaire est de définir la vue (unique) en tant quesous-classe "ornée" du modèle abstrait. De manière plus sophistiquée, le système SMALLTALK a pré-programmé dans des classes abstraites (composant ce que nous appellerons plus loin un squelette) lesmécanismes de reflet entre vues et modèles : un nombre quelconque de vues peuvent être attachées à unmodèle et, chaque fois que l'état du modèle est modifié, celui-ci active la méthode afficher de chacune desvues dont il possède la liste.

1 T. BUDD : An Introduction to Object-Oriented Programming, 2nd ed.; Addison-Wesley, 1997.2 "Pattern" = forme. Ce terme anglais a la même origine étymologique que le terme patron dans le jargon descouturières : forme en papier utilisée pour couper le tissu.3 L'ogive fut un motif architectural caractéristique du Moyen Age dans toute l'Europe occidentale. La façadeen briques rouges avec encadrements de pierre bleue est un motif de l'architecture mosane traditionnelle.

Page 206: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-28

Le langage JAVA a généralisé ce motif du reflet synchronisé entre un objet "observable" et des objets"observateurs", entre un objet "événement" et des objets "à l'écoute" ("listeners") ...

Un motif que l'on rencontre très couramment est celui de la façade. Les requêtes de l'objet client ne sontpas directement reçues par l'objet fournisseur des services demandés, mais par un objet intermédiaire quimodifie les messages avant de les relayer vers le destinataire final. A l'objet client, cet objet intermédiaireapparaît donc comme la "façade" de l'objet serveur. Les rôles de ces façades sont très variés :

– "proxy" transmettant, via un réseau, les requêtes à un serveur éloigné;– aiguilleur ("dispatcher") sélectionnant parmi plusieurs serveurs le destinataire d'une requête;– mémoire cache ou tampon accélérant l'accès aux données externes;– filtre adaptateur, changeant la forme des données;– fichier virtuel formé de la réunion de plusieurs fichiers physiques;– terminal virtuel standardisé rendant les programmes indépendants de leur environnement réel;– fenêtres "abstraites" (cf. JAVA) standardisant les différents systèmes d'interface graphique;– etc.

Autre domaine propice à la mise au point de motifs architecturaux : la matérialisation des associationsentre objets. Un motif souvent mis en évidence est celui de la structure "maître ← détails" permettant detraiter une association de type 1←n (ex.: 1 facture ← n lignes de facture, 1 commande ← n articlescommandés).

Autre domaine encore : la gestion du multilinguisme des programmes.

Selon les cas, un "pattern" sera décrit par un diagramme de collaboration d'objets ou un diagramme de clas-ses, dont les éléments (objets ou classes) sont de types variables. Il pourra assez souvent être partiellementpré-programmé, sous la forme de modèles générateurs à paramétrer ("templates") ou de squelettes de pro-grammes à compléter ("frameworks").1

3.5. Industrialisation du processus de développement

L'éclosion des méthodes à base d'"objets" permet d'envisager une certaine industrialisation du processus d'in-formatisation, en rendant possible la fabrication de composants logiciels réutilisables : types d’objets spécifi-ques d’un domaine d’application ou "métier",2 "templates", etc. Cette nouvelle approche se substitue (ous'ajoute) à l'approche classique des informaticiens développant des projets.

Object-orientedness is not just a programming style but the implementation of a certain view of whatsoftware development should be. [...] This view implies profound rethinking of the software proc-ess. [...]

The traditional culture [...] is project-based. In other words, the subject of discourse is the project,which starts with a certain specification and ends with the delivery of a program with the supportingdocuments. [...]

The outcome is results, produced by a program in response to user's requirements. The economics isone of profit, as produced by the results.

1 Cf. A. CLARINVAL : Concepts et méthodes de la programmation par objets, chapitre 7.2 En français : "objets métier". En anglais : "business objects".

Page 207: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-29

The organizational unit impacted is usually the department directly affected by the project. The timeframe is as short as it will take to produce the required solution. The goal is a program, or a fewprograms. The bricks of which this program is made are program elements : modules built for theoccasion.

[...]

The culture implicit in object-oriented design is quite different. It may be called the product cul-ture : the subject of discourse is reusable products rather than individual projects. [...]

The outcome is reusable software elements, meant to be useful to a large number of applications.The economics is one of investment — which of course is intended as deferred profit.

The unit is, beyond an individual project, a company (or division), sometimes an entire industry.The time frame is long-term. More than a program, the goal is to build systems. The bricks aresoftware components, which distinguish themselves from mere program elements by having a valueof their own, independently of the context for which they were initially designed. [...]

[...]

Without question, the dominant culture is project-based and will remain so for a long time. Custom-ers, users, management, shareholders all want results, and preferably fast. Posterity will come later.The immediate issue then is not so much how to replace the project culture by a product culture[...], but how to instill significant doses of product-oriented concerns into a context which is largelydriven by project preoccupations.

One of the favorite strategies of all-time subversives — penetrating institutions rather than des-troying them outright — indeed seems to work here.

[...] You have users and customers, and must be ready to respond to their specific requests. [...]You will fulfil your customers' specific requests, but you will do more than these requests, seeing theventural software components beyond the immediate program elements.

The effort involved in transforming program elements into software components may be called gene-ralization [...]. It involves abstracting from the original program elements, so as to make them in-dependent from their original context, more robust, better documented. Giving generalization asystematic role in the software development process is the key step in the progressive transition fromproject to product culture.

By starting from specific requests but going further, you can quietly start accumulating a repertoireof ready-made components which, little by little, will play an increasing role in your subsequent de-velopments. With such a strategy you can, after a while, start having a different attitude towardsyour users — more active and less reactive. You can respond to a new request, with its specific andperhaps baroque set of technical requirements, with a counter-proposal, offering to do somewhatdifferent and perhaps simplified job much faster thanks to the use of pre-existing components. Thenyou can give your customers a choice : either tail-made developments using traditional techniquesin n person-months, or "mix-and-match" development using object-oriented techniques in, say, 0.3 n.Some offers are hard to refuse. 1

1 B. MEYER : The New Culture of Software Development : Reflexions on the practice of Object-OrientedDesign, in Journ'ALMIN, n° 14, mars 1990.

Page 208: Methodes d Analyse

© A. CLARINVAL Analyse — Méthodes orientées Objets 8-30

Page 209: Methodes d Analyse

© A. CLARINVAL Analyse — Bibliographie B-1

Bibliographie

BACHMAN Ch. Data Structure Diagramsin Data Base, 1969.

BERTINI M.Th.TALLINEAU Y.

Le COBOL structuré, un modèle de programmationéd. d'Informatique, 1974.

BODART F.PIGNEUR Y.

Conception assistée des systèmes d'informationMasson, 1989.

BRAHMS Théorie et pratique des réseaux de PetriMasson, 1983.

BUDD T. An Introduction to Object-Oriented ProgrammingAddison-Wesley, 1997.

CHEN P. The Entity-Relationship Model — Toward a Unified View of Datain ACM TODS, 1976.

CLARINVAL A. Comprendre et connaître le COBOL 85Presses Universitaires de Namur, 1991.

CLARINVAL A. MESANGE :Méthode et Système d'Analyse et de Programmation de Gestion.Groupe S

CLARINVAL A. Exploitation et Organisation des FichiersHEMES, 1998.

CLARINVAL A. Concepts et méthodes de la programmation par objetsHEMES, 2001.

CODASYL Data Base Task Group ReportACM, 1971.

CODD E. A Relational Model of Data for Large Shared Data Banksin Communications ACM, 1970.

CODD E. Further Normalization of the Database Relational Modelin RUSTIN (ed) : Data Base Systems, Prentice-Hall, 1972.

DE MARCO T. Structured Analysis and System SpecificationPrentice-Hall, 1979.

DE ROSNAY J. Le macroscopeéd. du Seuil, 1975.

DESAINTQUENTIN J.M. L’informatique éclatéeMasson, 1991.

Page 210: Methodes d Analyse

© A. CLARINVAL Analyse — Bibliographie B-2

GANE C.SARSON T.

Structured Systems Analysis : tools and techniquesPrentice-Hall, 1979.

GEIB J.M..GRANSART Ch.MERLE Ph.

CORBA, des concepts à la pratiqueDunod, 1999(cet ouvrage est téléchargeable sur le sitecorbaweb.lifl.fr/CORBA_des_concepts_a_la_pratique/).

GILLET J.M. L'interface graphiqueInterEditions, 1995.

HAINAUT J.L. Conception assistée des applications informatiques :conception de la base de donnéesMasson, 1986.

JACKSON M. Principles of Program DesignAcademic Press, 1975.

JACOBSON I.BOOCH G.RUMBAUGH J.

Le processus unifié de développement logiciel, trad. françaiseEyrolles, 2000.

JACOBSON I., al. Object-Oriented Software Engineering : a Use Case Driven ApproachAddison-Wesley, 1992.

LE MOIGNE J.L. La théorie du système généralPresses Universitaires de France, 1977.

LISKOV B.GUTTAG J.

Abstraction and Specification in Program DevelopmentM.I.T. Press, 1988.

MARTIN J. Rapid Application DevelopmentMacMillan Publishing, 1991.

MARTIN J. Diagramming Techniques for Analysts and ProgrammersPrentice Hall.

MEYER B. The New Culture of Software Development :Reflexions on the practice of Object-Oriented Designin Journ'ALMIN, n° 14, mars 1990.

MULLER P.A. Modélisation objet avec UMLEyrolles, 1997.

OMG Unified Modeling Language Specification, vers. 1.4www.omg.org, 2002.

OMG CORBA / IIOP Specification, vers. 3.0www.omg.org, 2002.

PETERSON J.L. Petri Netsin ACM Computing Surveys, vol. 9, n° 3, sept. 1977.

Page 211: Methodes d Analyse

© A. CLARINVAL Analyse — Bibliographie B-3

ROLLAND C. Introduction à la conception des systèmes d'informationet panorama des méthodes disponiblesin Génie Logiciel, n° 4.

RUMBAUGH A., al. OMT — Modélisation et conception orientées objet, trad. françaiseMasson, 1995.

SMITH J.SMITH D.

Data Base Abstractions : Aggregation and Generalizationin ACM TODS, 1977.

TARDIEU H.ROCHFELD A.COLLETTI R.

La méthode MERISEéd. d'Organisation, 1983.

TSICHRITZIS D.KLUG A.

The ANSI/X3/SPARC DBMS Frameworkin Information Systems, 1978.

WARNIER J.D. Les procédures de traitement et leurs donnéeséd. d'Organisation, 1973.

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

WIENER N. Cybernétique et société, trad. françaiseéd. des Deux Rives, 1952.

YOURDON E. Modern Structured AnalysisPrentice-Hall, 1989.

Page 212: Methodes d Analyse

© A. CLARINVAL Analyse — Bibliographie B-4

Page 213: Methodes d Analyse

i

Table des matières

CHAPITRE 1. INTRODUCTION AUX MÉTHODES D'ANALYSE ..................................................... 1-1

1. Systèmes d'information ........................................................................................................................... 1-11.1. Le concept d'information ................................................................................................................................... 1-11.2. Applications de l'informatique à la gestion des organisations humaines ........................................................... 1-11.3. Applications techniques et scientifiques de l'informatique................................................................................ 1-2

2. Analyse des systèmes d'information........................................................................................................ 1-32.1. Etapes de l'analyse............................................................................................................................................. 1-32.2. Niveaux de modélisation ................................................................................................................................... 1-42.3. Articulation générale de la démarche ................................................................................................................ 1-6

3. Méthodologie de l'analyse ...................................................................................................................... 1-83.1. Contenu d'une méthodologie ............................................................................................................................. 1-83.2. Utilité d'une méthode......................................................................................................................................... 1-93.3. Schémas et Maquettes ..................................................................................................................................... 1-103.4. Modélisation et Programmation ...................................................................................................................... 1-123.5. L'équipe de développement ............................................................................................................................. 1-12

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

CHAPITRE 2. INTRODUCTION À LA MODÉLISATION DES DONNÉES....................................... 2-1

1. BASES DE DONNÉES ET MODÉLISATION ....................................................................................................... 2-21.1. Le concept de Système de Gestion de Bases de Données (SGBD)...................................................... 2-21.2. Niveaux de modélisation...................................................................................................................... 2-2

a) Vues externes ....................................................................................................................................................... 2-2b) Vue conceptuelle.................................................................................................................................................. 2-3c) Vue interne ........................................................................................................................................................... 2-3

1.3. Langage de description de données — Schémas................................................................................. 2-42. FONDEMENTS DES TECHNIQUES DE MODÉLISATION DES DONNÉES............................................................... 2-5

2.1. Les mécanismes d'abstraction ............................................................................................................. 2-5a) Classification : Type, Classe, Occurrence, Collection......................................................................................... 2-5b) Spécialisation, Généralisation .............................................................................................................................. 2-6

2.2. Mécanisme de désignation des occurrences........................................................................................ 2-7a) La relation de dépendance fonctionnelle .............................................................................................................. 2-7b) Le concept d'identifiant ........................................................................................................................................ 2-7

2.3. Dimensions temporelles de l'information ............................................................................................ 2-7a) Durée de vie ......................................................................................................................................................... 2-7b) Période de validité................................................................................................................................................ 2-8c) Période de mémorisation, Durée de rétention....................................................................................................... 2-8

2.4. Contraintes d'intégrité ......................................................................................................................... 2-82.5. Aspects dynamiques des données......................................................................................................... 2-9

3. PANORAMA HISTORIQUE............................................................................................................................ 2-103.1. Les SGBD opérationnels ................................................................................................................... 2-103.2. Les méthodes d'analyse ..................................................................................................................... 2-10

a) Modèles d'analyse des données .......................................................................................................................... 2-10b) Outils d'aide à la conception .............................................................................................................................. 2-11c) Plan du cours ...................................................................................................................................................... 2-11

Page 214: Methodes d Analyse

ii

CHAPITRE 3. LE SCHÉMA CONCEPTUEL DES DONNÉES ............................................................. 3-1

1. LE MODÈLE ENTITÉ–ASSOCIATION.............................................................................................................. 3-21.1. Contenu du modèle Entité–Association ............................................................................................... 3-2

a) Entité .................................................................................................................................................................... 3-2b) Association........................................................................................................................................................... 3-4

Le concept d'Association....................................................................................................................................... 3-4Notation UML....................................................................................................................................................... 3-6Connectivité des associations................................................................................................................................ 3-6Les connectivités dans la notation UML............................................................................................................... 3-8

c) Attribut ................................................................................................................................................................. 3-9Attribut et Domaine............................................................................................................................................... 3-9Noms d'attributs .................................................................................................................................................. 3-11Propriétés des attributs ........................................................................................................................................ 3-11Définition des domaines de valeurs..................................................................................................................... 3-12

d) Identifiants ......................................................................................................................................................... 3-12Identifiant d'un type d'entité ................................................................................................................................ 3-12Identifiant d'un type d'association ....................................................................................................................... 3-13Identifiants multiples........................................................................................................................................... 3-14Propriétés des identifiants ................................................................................................................................... 3-15

e) Dimension historique ......................................................................................................................................... 3-16f) Discussion........................................................................................................................................................... 3-17

1.2. Structures particulières ..................................................................................................................... 3-18a) Compositions sémantiquement équivalentes ...................................................................................................... 3-18b) Associations non représentables......................................................................................................................... 3-18

Critique du modèle Entité–Association............................................................................................................... 3-192. APPORTS DU PARADIGME OBJET................................................................................................................ 3-20

2.1. Classes d'objets.................................................................................................................................. 3-20a) Les concepts ....................................................................................................................................................... 3-20b) Spécification des opérations............................................................................................................................... 3-21

Spécification externe........................................................................................................................................... 3-21Définition sémantique ......................................................................................................................................... 3-22

c) Aperçu sur le langage IDL.................................................................................................................................. 3-222.2. Modélisation des relations d’abstraction .......................................................................................... 3-24

a) Agrégation / Contenance .................................................................................................................................... 3-24b) Classification / Instanciation .............................................................................................................................. 3-26c) Généralisation / Spécialisation ........................................................................................................................... 3-27

2.3. Schéma dynamique : diagrammes d’états et transitions................................................................... 3-28a) Etats.................................................................................................................................................................... 3-28b) Transitions.......................................................................................................................................................... 3-29c) Méthode.............................................................................................................................................................. 3-30

3. CONTRAINTES D'INTÉGRITÉ........................................................................................................................ 3-313.1. Portée des contraintes d’intégrité ..................................................................................................... 3-313.2. Connectivité et identifiant.................................................................................................................. 3-313.3. Durée de rétention ............................................................................................................................. 3-313.4. Contraintes ensemblistes ................................................................................................................... 3-323.5. Règles relatives à la valeur des attributs........................................................................................... 3-32

a) Définition des domaines de valeurs.................................................................................................................... 3-32Domaine élémentaire........................................................................................................................................... 3-32Domaine structuré ............................................................................................................................................... 3-33

b) Restriction du domaine (condition d'appartenance) .......................................................................................... 3-33c) Relations entre attributs...................................................................................................................................... 3-33

Contraintes statiques ........................................................................................................................................... 3-33Contraintes d'évolution ....................................................................................................................................... 3-34

3.6. Définition sémantique des opérations ............................................................................................... 3-353.7. Formalisme pour l'expression des règles .......................................................................................... 3-36

a) La notion de règle............................................................................................................................................... 3-36b) La notion de variable.......................................................................................................................................... 3-36c) Les ensembles..................................................................................................................................................... 3-38

Page 215: Methodes d Analyse

iii

4. VALIDATION DU SCHÉMA........................................................................................................................... 3-394.1. Suppression des incohérences ........................................................................................................... 3-39

a) Correction des anomalies lexicographiques ....................................................................................................... 3-39b) Vérification des contraintes, Elimination des contradictions ............................................................................. 3-39

4.2. Affinage du schéma............................................................................................................................ 3-39a) Normalisation des composants ........................................................................................................................... 3-39b) Spécialisation par sous-typage ........................................................................................................................... 3-41

Généralisations implicites ................................................................................................................................... 3-41Associations conditionnelles............................................................................................................................... 3-41

4.3. Simplification du schéma................................................................................................................... 3-42a) Simplification des structures .............................................................................................................................. 3-42

Associations de degré élevé ................................................................................................................................ 3-42Compositions de connectivités 1:1...................................................................................................................... 3-42

b) Contrôle des structures redondantes................................................................................................................... 3-43c) Cas particulier : les attributs dérivables............................................................................................................. 3-43

4.4. Note sur les sous-schémas ................................................................................................................. 3-445. VALIDATION DU SYSTÈME DE RÈGLES........................................................................................................ 3-45

5.1. Complétude du système de règles ...................................................................................................... 3-455.2. Cohérence du système de règles ........................................................................................................ 3-45

6. EN GUISE DE CONCLUSION ......................................................................................................................... 3-466.1. Recommandations diverses................................................................................................................ 3-466.2. Documentation du schéma................................................................................................................. 3-47

CHAPITRE 4. SCHÉMA LOGIQUE DU STOCKAGE DES DONNÉES.............................................. 4-1

1. SCHÉMA DES STRUCTURES DE STOCKAGE : LE MODÈLE EN RÉSEAU ........................................................... 4-21.1. Eléments d'une structure de stockage.................................................................................................. 4-21.2. Transformation du schéma Entité–Association ................................................................................... 4-21.3. Commentaires sur le concept de liaison .............................................................................................. 4-6

a) Terminologie ........................................................................................................................................................ 4-7b) Contraintes définies sur les liaisons ..................................................................................................................... 4-7

Liaison obligatoire ou facultative.......................................................................................................................... 4-7Connectivité d'un type de liaison .......................................................................................................................... 4-7

c) Interprétation d'une liaison comme étant une association..................................................................................... 4-81.4. Optimisation du schéma ...................................................................................................................... 4-9

a) Généralisation....................................................................................................................................................... 4-9b) Dénormalisation ................................................................................................................................................. 4-10

Propagation parent ==> enfants .......................................................................................................................... 4-10Dérivation parent(s) ==> enfants ........................................................................................................................ 4-11Récapitulation enfants ==> parent ...................................................................................................................... 4-12Fusion des enregistrements parent et enfants ...................................................................................................... 4-12

1.5. Structures particulières ..................................................................................................................... 4-12a) Enregistrement d'intersection ............................................................................................................................. 4-12b) Liaison cyclique ................................................................................................................................................. 4-13

1.6. Contraintes d'intégrité ....................................................................................................................... 4-14a) Reformulation des règles .................................................................................................................................... 4-14b) Relaxation des contraintes de connectivité 1:N.................................................................................................. 4-14c) Intégrité des références....................................................................................................................................... 4-15

Création du propriétaire d'une liaison ................................................................................................................. 4-15Suppression du propriétaire d'une liaison ........................................................................................................... 4-15

2. PRÉPARATION DU SCHÉMA PHYSIQUE........................................................................................................ 4-162.1. Schéma des fonctions d'accès ............................................................................................................ 4-16

a) Introduction ........................................................................................................................................................ 4-16b) Préliminaire : le concept d'ensemble selon CODASYL .................................................................................... 4-16c) Définition des méthodes d'accès ........................................................................................................................ 4-17

Clé d'accès........................................................................................................................................................... 4-17Séquence d'accès ................................................................................................................................................. 4-18Chemin d'accès.................................................................................................................................................... 4-19

2.2. Quantification du schéma.................................................................................................................. 4-20

Page 216: Methodes d Analyse

iv

3. LE SCHÉMA LOGIQUE DES DONNÉES, SUPPORT DE LA PROGRAMMATION.................................................... 4-213.1. Parcours d'un ensemble..................................................................................................................... 4-213.2. Sous-schéma arborescent .................................................................................................................. 4-213.3. Transformation séquentielle des sous-schémas arborescents............................................................ 4-23

a) Constitution des fichiers séquentiels .................................................................................................................. 4-23b) Cas particulier : ensembles hétérogènes............................................................................................................ 4-23c) Syntaxe de définition.......................................................................................................................................... 4-24d) Contraintes particulières aux fichiers COBOL................................................................................................... 4-24e) Réalisation des fonctions d'accès........................................................................................................................ 4-25

Fonctions d'accès internes à un fichier séquentiel ............................................................................................... 4-25Fonctions d'accès inter-fichiers ........................................................................................................................... 4-26

3.4. Méthode de construction des programmes ........................................................................................ 4-27a) Graphe des accès aux données............................................................................................................................ 4-28b) Règles du traitement........................................................................................................................................... 4-29c) Structure du programme ..................................................................................................................................... 4-30

CHAPITRE 5. SCHÉMA PHYSIQUE DE LA BASE DE DONNÉES .................................................... 5-1

1. LES BASES DE DONNÉES CODASYL ........................................................................................................... 5-21.1. Le langage de description de données (DDL) .................................................................................... 5-3

a) Schéma de la base de données.............................................................................................................................. 5-3Fichiers (AREA) .................................................................................................................................................. 5-3Enregistrements (RECORD) ................................................................................................................................ 5-3Ensembles (SET).................................................................................................................................................. 5-4Clés d'accès et identifiants..................................................................................................................................... 5-6Exemple récapitulatif ............................................................................................................................................ 5-6

b) Sous-schémas ....................................................................................................................................................... 5-81.2. Le langage de manipulation des données (DML)............................................................................... 5-8

a) Contrôle de l'accès aux fichiers : OPEN, CLOSE ............................................................................................... 5-8b) Les mécanismes de navigation ............................................................................................................................. 5-8

Enregistrements courants ...................................................................................................................................... 5-8Localisation d'un enregistrement : FIND ............................................................................................................. 5-9Test de l'appartenance d'un enregistrement à un ensemble.................................................................................... 5-9Lecture d'un enregistrement : GET..................................................................................................................... 5-10

c) Mise à jour des données ..................................................................................................................................... 5-10Création/Modification d'un enregistrement : STORE, MODIFY....................................................................... 5-10Inclusion/Retrait d'un membre dans un ensemble : INSERT, REMOVE .......................................................... 5-11Suppression d'un enregistrement : DELETE...................................................................................................... 5-11

2. LES BASES DE DONNÉES RELATIONNELLES ................................................................................................ 5-122.1. Le modèle relationnel des données.................................................................................................... 5-12

a) Les relations ....................................................................................................................................................... 5-12b) Identification et Normalisation........................................................................................................................... 5-14c) L'algèbre relationnelle (pour mémoire) ............................................................................................................. 5-14

2.2. Le dictionnaire des données (SQL)................................................................................................... 5-15a) Définition des domaines ..................................................................................................................................... 5-15b) Définition des tables........................................................................................................................................... 5-16

Note sur les contraintes d'intégrité référentielle .................................................................................................. 5-18c) Définition des assertions..................................................................................................................................... 5-18

Note sur les transactions et la vérification des contraintes .................................................................................. 5-19d) Mise à jour automatique des données dérivables ............................................................................................... 5-19e) Les vues.............................................................................................................................................................. 5-22f) Création d’index ................................................................................................................................................. 5-23

2.3. La manipulation des données ............................................................................................................ 5-24a) Opérations disponibles ....................................................................................................................................... 5-24

Consultation : SELECT ..................................................................................................................................... 5-24Création de lignes : INSERT.............................................................................................................................. 5-25Modification de lignes : UPDATE..................................................................................................................... 5-25Suppression de lignes : DELETE....................................................................................................................... 5-25

b) Modes d'utilisation du langage SQL .................................................................................................................. 5-25

Page 217: Methodes d Analyse

v

c) SQL inséré.......................................................................................................................................................... 5-26Repérage des instructions SQL insérées.............................................................................................................. 5-26Communication des données............................................................................................................................... 5-26Signalisation des incidents .................................................................................................................................. 5-26Les curseurs......................................................................................................................................................... 5-27Exemple COBOL................................................................................................................................................ 5-27

CHAPITRE 6. INTRODUCTION À LA MODÉLISATION DES SYSTÈMES..................................... 6-1

1. HIÉRARCHISATION DU SYSTÈME D'INFORMATION ........................................................................................ 6-21.1. Système ................................................................................................................................................ 6-21.2. Tâche ................................................................................................................................................... 6-3

Programme ................................................................................................................................................................ 6-4Objet .......................................................................................................................................................................... 6-4Tâche = Transaction .................................................................................................................................................. 6-4

1.3. Module................................................................................................................................................. 6-52. NIVEAUX INTERMÉDIAIRES.......................................................................................................................... 6-6

CHAPITRE 7. LES DIAGRAMMES DE FLUX....................................................................................... 7-1

1. SCHÉMA FONCTIONNEL ............................................................................................................................... 7-21.1. Contenu d'un diagramme de flux......................................................................................................... 7-2

a) Environnement ..................................................................................................................................................... 7-2b) Processus.............................................................................................................................................................. 7-3c) Flux de données.................................................................................................................................................... 7-4

Flux direct, Messages............................................................................................................................................ 7-4Flux indirect, Dépôt de données............................................................................................................................ 7-6Perméabilité des classes de flux directs et indirects .............................................................................................. 7-8

1.2. Structures typiques .............................................................................................................................. 7-8a) Applications sans flux directs............................................................................................................................... 7-8b) Décomposition suivant un axe spatio-temporel dominant.................................................................................... 7-9c) Systèmes régulés................................................................................................................................................. 7-10

1.3. Validation des diagrammes de flux.................................................................................................... 7-11a) Syntaxe des diagrammes de flux......................................................................................................................... 7-11

Relations entre composants................................................................................................................................. 7-11Dénomination des composants............................................................................................................................ 7-12Remarque. Mise en page d'un diagramme de flux.............................................................................................. 7-12

b) Hiérarchisation des diagrammes......................................................................................................................... 7-121.4. Spécification d'un processus.............................................................................................................. 7-14

a) Description externe de la fonction...................................................................................................................... 7-15b) Description de l'interface d'une tâche................................................................................................................. 7-16c) Spécification détaillée des règles........................................................................................................................ 7-16

Niveaux de définition des règles ......................................................................................................................... 7-16Expression des règles .......................................................................................................................................... 7-16Vérification des règles......................................................................................................................................... 7-17

d) Définition interne de la procédure...................................................................................................................... 7-172. SCHÉMA DYNAMIQUE ................................................................................................................................ 7-21

2.1. Contenu du schéma dynamique ......................................................................................................... 7-21a) Processus ............................................................................................................................................................ 7-21b) Evénement.......................................................................................................................................................... 7-21c) Moniteur............................................................................................................................................................. 7-23

2.2. Types d'enchaînements ...................................................................................................................... 7-242.3. Spécification d'un moniteur ............................................................................................................... 7-252.4. Validation du schéma dynamique...................................................................................................... 7-26

a) Complétude du schéma....................................................................................................................................... 7-26b) Cohérence du schéma......................................................................................................................................... 7-27

Evénements initiaux ............................................................................................................................................ 7-27Processus atteignables......................................................................................................................................... 7-28Terminaison propre ............................................................................................................................................. 7-28

3. SCHÉMA DE DÉPLOIEMENT ........................................................................................................................ 7-29

Page 218: Methodes d Analyse

vi

CHAPITRE 8. MÉTHODES ORIENTÉES OBJETS............................................................................... 8-1

1. SCHÉMAS D’OPÉRATIONS ............................................................................................................................ 8-21.1. Préambule : unification des méthodes autour du concept d’Objet..................................................... 8-21.2. Les diagrammes d’interaction ............................................................................................................. 8-2

a) Concepts introductifs............................................................................................................................................ 8-2b) Notations communes ............................................................................................................................................ 8-3c) Diagramme de collaboration................................................................................................................................. 8-4d) Diagramme de séquence....................................................................................................................................... 8-4

2. LE SCHÉMA DES CAS D’UTILISATION........................................................................................................... 8-62.1. Préambule : le contexte historique ..................................................................................................... 8-6

a) Libéralisation de l'usage des ordinateurs .............................................................................................................. 8-6b) Modernisation des méthodes d’analyse................................................................................................................ 8-7

2.2. Contenu du modèle des Cas d’Utilisation ........................................................................................... 8-8a) Système ................................................................................................................................................................ 8-8b) Acteur................................................................................................................................................................... 8-8

Acteur externe ....................................................................................................................................................... 8-8c) Cas d’utilisation.................................................................................................................................................... 8-9d) Scénario.............................................................................................................................................................. 8-10

2.3. Spécification des scénarios................................................................................................................ 8-11a) Flot d’événements .............................................................................................................................................. 8-11b) Diagramme de séquence..................................................................................................................................... 8-12

2.4. Relations entre cas d’utilisation ........................................................................................................ 8-12a) Relations concrètes............................................................................................................................................. 8-13

Utilisation............................................................................................................................................................ 8-13Extension ............................................................................................................................................................ 8-13

b) Relations abstraites............................................................................................................................................. 8-14Inclusion.............................................................................................................................................................. 8-14Généralisation ..................................................................................................................................................... 8-14

2.5. Analyse des cas d’utilisation : du scénario aux objets ..................................................................... 8-15a) Classification des composants ............................................................................................................................ 8-15

L’architecture Modèle–Vue–Contrôleur (SMALLTALK)................................................................................. 8-15Les classes d’analyse (JACOBSON).................................................................................................................. 8-16Commentaires ..................................................................................................................................................... 8-17

b) Diagramme de collaboration .............................................................................................................................. 8-17c) Diagramme des classes "conceptuelles" ............................................................................................................. 8-19

3. CONCEPTION D’UNE ARCHITECTURE LOGICIELLE....................................................................................... 8-203.1. Nature de la démarche de conception ............................................................................................... 8-203.2. Le concept d’architecture logicielle .................................................................................................. 8-223.3. Le principe d'architecture « Client / Serveur » ................................................................................. 8-23

a) Etat de l’art des développements informatiques ................................................................................................. 8-23« L’informatique éclatée »................................................................................................................................... 8-23Outils avancés ..................................................................................................................................................... 8-24

b) Définition de l’architecture Client / Serveur ...................................................................................................... 8-24c) Règle de répartition ............................................................................................................................................ 8-24d) Variété des paradigmes de programmation ........................................................................................................ 8-26

3.4. Motifs architecturaux ("Patterns") ................................................................................................... 8-273.5. Industrialisation du processus de développement ............................................................................. 8-28

BIBLIOGRAPHIE ........................................................................................................................................B-1