[PDF] Formation pour apprendre la méthode de conception de donnees merise | Cours informatique

Texte intégral

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

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

(3) SYSTEME DE DECISION/PILOTAGE. support SYSTEME D'INFORMATION commande reflet SYSTEME OPERANT. Les fonctions d'un système d'information sont de conserver (mémoriser), créer (transformer) et communiquer (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'information 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écaniques) ... 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 transposable au monde de la technique. De l'information circule entre les organes d'un appareillage (par exemple, les signaux électriques à l'intérieur d'un téléviseur) ou d'une machinerie complexe (une centrale électrique) qui, à la fois, en reflète l'état et en commande le fonctionnement (l'information affichée sur les tableaux de contrôle d'une centrale électrique sert à la piloter ...). Nous donnerons plus loin le nom de modèle d'un phénomène à une représentation abstraite de ce phénomène; — le rôle de l'informatique dans une application de robotisation consiste à maintenir, analyser et manipuler un modèle mathématique du processus. Relevons un usage particulier de l'informatique dans les domaines de la science et de la technique. Alors que l'on pourrait considérer que le système d'information d'une organisation — telle qu'une entreprise commerciale, un club ou une association, un hôpital ou une école — constitue une sorte de simulation en temps réel de son fonctionnement, les techniciens et les scientifiques réalisent très couramment des programmes de simulation "à l'avance" d'une réalité future, voire purement hypothétique. En recherche médicale, la simulation informatique commence timidement à remplacer l'expérimentation animale ... Des progrès récents dans les méthodes de calcul permettent la simulation de beaucoup de structures physiques sans avoir à les construire. La simulation n'est pas seulement moins chère, elle permet aussi de fournir de l'information qui, sur les modèles physiques, est soit trop insaisissable, soit difficile à mesurer. La construction de modèles physiques ou informatiques revient généralement moins cher que la construction du système complet et permet de corriger plus tôt les déficiences. 1. 1. J. RUMBAUGH, al. : OMT — Modélisation et conception orientées objet, trad. française; Masson, 1995.. © A. CLARINVAL Analyse — Introduction. 1-2.

(4) 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'obsolescence. Il est alors nécessaire d'en développer un nouveau ou, du moins, une nouvelle version. Cette idée de développer ou fabriquer est évidemment particulièrement pertinente pour la partie "programmée" du système, c'est-à-dire pour les applications informatiques. Dans le développement d'un projet informatique, on donne le nom général d'analyse à l'ensemble des démarches 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 besoins puis la conception ("design") de la solution technique. Aux premiers temps de l'informatique (19651975), ces deux étapes étaient, dans nos contrées, désignées sous les noms d'analyse fonctionnelle (= étude des fonctionnalités, c'est-à-dire de l'utilité, du système à mettre en place) et analyse organique (= description des organes composant la solution). • Habituellement, une étude préalable d'opportunité part d'une critique du système d'information existant, qu'elle décrit plus ou moins exhaustivement, avec plus ou moins de détail. Elle justifie une nouvelle solution, qu'elle recommande et à laquelle elle assigne des objectifs. L'étude d'opportunité dit le "pourquoi"; elle motive la décision de mettre un projet en chantier. • L'analyse fonctionnelle détaille le "quoi" de la solution, pas encore le comment : "abstraction précise du but de l'application et non de la façon dont elle sera bâtie".1 Elle décrit complètement le contenu sémantique et logique du nouveau système à mettre en place, sans prendre en considération les moyens à mettre en œuvre pour le faire fonctionner. • "Comment ?" L'étape de conception définit la réalisation de ce système sous la forme de constructions — programmes et procédures — utilisant au mieux les ressources techniques et organisationnelles : logiciels, équipements, personnel, locaux, horaires, etc.. De manière générale [...], le développement d'une application répond à quatre questions : Application = Quoi + Dans quel domaine + Comment + Avec quelles compétences. Ces questions correspondent à différents points de vue et concernent différents intervenants. Elles peuvent être étudiées selon des techniques variées, mais doivent dans tous les cas être considérées pour développer une application : • Quoi faire ? La réponse est exprimée par l'utilisateur qui décrit ce qu'il attend du système, comment il entend interagir avec lui et quels sont les différents intervenants. Il s'agit d'une description fonctionnelle qui ne rentre pas dans les détails de la réalisation : le quoi faire est purement descriptif.. 1. J. RUMBAUGH, al. : op. cit.. © A. CLARINVAL Analyse — Introduction. 1-3.

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

(6) Dans le sillage de la méthode MERISE (± 1980), la tradition française, plus spéculative, distingue des niveaux de modélisation : les niveaux conceptuel, logique et physique.. Ambiguïtés terminologiques Conception. Comme traduction du terme américain "design", le mot conception désigne le fait d'élaborer une architecture; dans la démarche française, il désigne le fait de conceptualiser, de réduire à l'état notionnel. Modèle. Lorsqu'ils emploient une expression du genre "le modèle relationnel" ou "le modèle Entité–Association", les informaticiens désignent une théorie sur laquelle ils se fondent pour structurer leurs propres descriptions, qu'ils appellent alors des schémas. (Ajoutons qu'un schéma peut être celui d'un programme de simulation, c'est-à-dire le modèle d'un modèle !) Si ces théories de la décennie 1970 avaient vu le jour dix années plus tard, sans doute les appellerait-on "paradigme relationnel" et "paradigme Entité–Association" comme, en programmation, on parle aujourd'hui du "paradigme Objet".1. • Un schéma conceptuel exprime la sémantique du système qu'il représente : il fait apparaître les concepts, avec leurs relations et contraintes. Il a vocation d'être un instrument d'échange compréhensible par l'utilisateur "client" ou "commanditaire" du système d'information. Exemples de spécifications : types d'objets ou concepts : CLIENT, COMMANDE associations entre types d'objets : 1 CLIENT → n COMMANDE prédicats restrictifs (contraintes) : ∀ Qté commandée > 0 équations (règles de calcul) : Qté livrée = MIN (Qté commandée, Qté en stock) méthodes abstraites : enregistrer une commande, établir une facture2 • Un schéma logique est la traduction d'un schéma conceptuel en termes de composants programmables ou, plus largement, réalisables. Reflétant le plus directement qu'il se peut à la fois la spécification conceptuelle et l'état (la modernité) des ressources et techniques que l'on souhaite mettre en œuvre, il sert de référence pour les techniciens du système d'information. Exemples de spécifications : clés d'accès : référence du CLIENT dans l'enregistrement COMMANDE tables de codification : code Catégorie-Client actions de vérification des contraintes : si Qté commandée = 0 → message "cde nulle" sous-programmes de calcul : Calcul-Echéance (date-départ, délai) → date-échéance • Transformation finale d'un schéma logique, un schéma physique doit prendre en compte les paramètres de performance du système selon différents points de vue — économique, technique, sécuritaire, ergonomique, etc. — : configurations matérielles nécessaires, charge et coût d'utilisation des réseaux de télécommunication, délais d'attente des résultats, protection contre les intrusions et malveillances, 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. © A. CLARINVAL Analyse — Introduction. 1-5.

(7) Exemples de spécifications : regroupements de données (fusion de types d'objets ...) cryptage des données sensibles dédoublement des contrôles de validité dans une architecture décentralisée choix des polices de caractères pour les affichages à l’écran variantes d'une tâche : réception des commandes au comptoir, par courrier, par téléphone. 2.3. Articulation générale de la démarche L'étude du texte ci-dessous montrera que les deux démarches, l'américaine et la française, ne sont pas antinomiques. Mais le mérite principal de ce texte (sur lequel il vaut la peine de revenir souvent pour le méditer) est de mettre en évidence le "souffle" qui doit inspirer l'analyste concepteur.. L'analyse [...] L'analyse [au sens américain] remonte de la conséquence vers le principe : elle essaie de comprendre, d'expliquer et de représenter la nature profonde du système qu'elle observe. L'analyse ne se préoccupe pas de solutions mais de questions; elle identifie le quoi faire et l'environnement d'un système, sans décrire le comment, qui est le propre de la conception. L'analyse commence par la détermination du quoi faire, c'est-à-dire des besoins de l'utilisateur. Bien souvent, l'utilisateur n'est pas capable d'exprimer clairement ses attentes, de sorte que le cahier des charges n'est qu'une représentation approximative de ses besoins réels. La présence d'un imposant cahier des charges n'est pas toujours de bon augure. [...] Trop souvent, les cahiers de charges sont touffus, confus, contiennent des points contradictoires et ne reflètent pas les vrais besoins des utilisateurs. [...] L'analyse se poursuit par la modélisation du domaine de l'application, c'est-à-dire par l'identification des objets [...] qui appartiennent fondamentalement à l'environnement de l'application, et par la représentation des interactions entre ces objets. [...] L'assise sur les éléments du monde réel facilite le départ de la démarche car elle concentre la pensée sur des éléments concrets. Elle doit impérativement être poursuivie par une démarche d'abstraction qui vise à faire oublier les contingences du monde réel et à déterminer les concepts fondateurs qui sont à leurs origines. Si la réflexion se focalise trop sur l'existant, les risques sont grands de reproduire une solution au lieu d'identifier le problème posé [...]. L'analyse est l'antithèse de la conformité. L'analyse est souvent surprenante car elle demande de changer de point de vue, d'oublier ce qui est connu, ce qui s'impose de prime abord, afin de retrouver l'essentiel, la nature cachée des choses. Le propre de l'analyse est de trouver une description à laquelle personne n'avait jamais pensé jusqu'alors, mais qui une fois déterminée s'impose au point d'être évidente. Pour prendre une image, analyser c'est regarder un point, un cercle, une ellipse, une droite, deux droites sécantes, une hyperbole et une parabole et reconnaître que toutes ces formes peuvent être obtenues par l'intersection d'un plan et d'un cône. Dans ce cas, le principe générateur peut être exprimé par une équation de la forme ax2 + by2 + 2cx + 2dy + e = 0. Cette représentation est économe car elle décrit l'essentiel. L'analyse va à l'essentiel et recherche un modèle générique plus abstrait.. © A. CLARINVAL Analyse — Introduction. 1-6.

(8) La conséquence immédiate d'une analyse bien menée est toujours une grande économie dans la réalisation qui s'ensuit. [...] Parallèlement à l'analyse de l'environnement, se déroule parfois une analyse de l'existant et des contraintes de réalisation. L'objet de cette analyse est de comprendre parfaitement les caractéristiques et les contraintes de l'environnement de réalisation afin de pouvoir prendre lors de la conception des décisions motivées et réfléchies. [...]. La conception [...] Comme l'analyse et la conception, la conception et la réalisation se chevauchent en partie. Il est rare de savoir comment tout faire; pour cette raison, il faut essayer des techniques alternatives, comparer les résultats puis choisir en faisant des compromis. La conception et la réalisation se complètent. La conception a besoin d'expérimenter, la réalisation a besoin de principes directeurs. Afin de maintenir le plus longtemps possible les bénéfices de l'abstraction, la conception est généralement subdivisée en deux étapes : une étape logique indépendante de l'environnement de réalisation et une étape physique qui se préoccupe de l'ordonnancement des ressources et des particularités des langages de programmation ou de l'environnement d'exécution. La conception est souvent considérée, à tort, comme un simple enrichissement des résultats obtenus durant l'analyse. Il s'agit là d'une vision fortement réductrice qui ignore tout simplement que la conception est le temps de la mise en œuvre du savoir-faire. Ce savoir-faire peut être interne au projet ou acquis à l'extérieur sous la forme d'outils, de composants réutilisables ou plus largement de cadres de développement.1 [...] La conception débute par la détermination de l'architecture du logiciel, c'est-à-dire par l'élaboration des structures statiques et dynamiques qui serviront de charpente pour l'ensemble du développement. L'architecture définit la forme générale de l'application; de sa qualité dépendent le développement et l'évolution du logiciel. L'architecture est la conséquence de décisions stratégiques arrêtées lors de la conception et de décisions tactiques prises en cours de réalisation. Se donner une stratégie informatique, c'est considérer le logiciel comme un élément déterminant du développement de l'entreprise; c'est aussi chercher à s'assurer une avance technologique par des choix d'architecture qui dépassent le cadre des besoins immédiats, liés à une application particulière. Se donner une stratégie informatique, c'est par exemple choisir : • l'internationalisation, autrement dit, concevoir le logiciel de telle manière que le dialogue avec l'utilisateur puisse être mené dans toutes les langues; • la réutilisation qui n'est pas le fruit du hasard, mais le résultat d'une adhésion forte de toute une organisation, depuis la définition de la ligne de produits jusqu'au développement de ces produits; • l'unicité de langage pour l'ensemble des développements (Ada dans le cas du ministère de la défense américain); • l'indépendance par rapport aux dispositifs d'affichage, autrement dit, le découplage entre l'information à 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éveloppement et surtout de maintenance dans le cas d'un logiciel multicibles. [...]. 1. "Frameworks".. © A. CLARINVAL Analyse — Introduction. 1-7.

(9) L'effort développé en conception est plus ou moins important selon la nature de l'application et la richesse de l'environnement de réalisation. Il est de plus en plus possible d'effectuer un transfert de complexité des applications vers les environnements [de développement], grâce à une factorisation des éléments et des mécanismes communs. C'est le cas dans les familles d'applications bien ciblées dans un domaine donné, comme les logiciels clients qui interagissent avec des serveurs de bases de données. Inversement, plus une application est technique, plus elle interagit avec des matériels particuliers et plus l'effort de conception est important. Les outils RAD — développement rapide d'applications 1 — proposent une voie bien tracée.2 [...] Il faut suivre les règles du jeu fixées à l'avance : au bénéfice de la simplicité mais au détriment de l'originalité. Toutes les applications finissent par se ressembler, ce qui est bien et mal à la fois. Le travers des outils RAD est d'encourager à faire vite et salement — quick and dirty — plutôt que vite et bien. Curieusement, le RAD est un mélange de génie logiciel dans sa conception et d'horreur informatique dans son utilisation. Ceci est la conséquence d'une vision à court terme des utilisateurs pour qui seul l'aspect rapidité compte bien souvent. Comme le RAD n'encourage pas particulièrement la modularité et les abstractions en couches, très rapidement — c'est le cas de le dire — le code d'interface utilisateur et le code de l'application se retrouvent intimement mélangés. Le logiciel construit de cette manière est difficile à maintenir et quasiment impossible à réutiliser pour une autre application. Le propre de la conception est de rechercher l'équilibre entre vitesse de réalisation et possibilité de réutilisation, ouverture et solution clé en main, vision à court terme (la tactique) et vision à long terme (la stratégie). 3. 3. Méthodologie de l'analyse 3.1. Contenu d'une méthodologie Une méthode d'élaboration de logiciels décrit comment modéliser et construire des systèmes logiciels 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 modélisation qui constituent des concepts fondamentaux pour la représentation de systèmes ou de phénomènes. Les notes reportées sur les partitions sont des éléments de modélisation pour la musique. L'approche objet propose l'équivalent des notes — ce sont les objets — pour la représentation des logiciels. 1. RAD — "Rapid Application Development", l'expression est de J. MARTIN. Sous ce titre, il préconisa, en 1991 (éd. MacMillan Publishing), une nouvelle stratégie pour le développement des projets informatiques : au lieu du comportement traditionnel consistant à définir d'abord les limites de l'application à réaliser et à voir ensuite les équipes de développeurs accumuler les retards et dépasser toutes les prévisions budgétaires ... fixer le budget au départ et demander aux équipes de développement de réaliser "ce qu'elles peuvent" dans ce cadre, en créant des prototypes au moyen d'outils de programmation sophistiqués et rapides. Bref, au lieu de faire exploser les budgets, restreindre s'il le faut les ambitions du projet ... Le temps ayant passé, on a oublié cette proposition "révolutionnaire" pour ne retenir que la suggestion de choisir des outils performants. 2 Les outils de développement rapide (ex.: WinDev, PowerBuilder, Delphi, C++ Builder, ViewAge et d'innombrables autres "studios" de "visual programming") jouissent actuellement d'une grande vogue, qu'explique le seul qualificatif "rapide". On en indique ici les limites et les pièges. 3 P.A. MULLER : op. cit. © A. CLARINVAL Analyse — Introduction. 1-8.

(10) Les méthodes définissent également une représentation, souvent graphique, qui permet d'une part de manipuler aisément les modèles, et d'autre part de communiquer et d'échanger l'information entre les différents intervenants. Une bonne représentation recherche l'équilibre entre la densité d'information et la lisibilité. En plus des éléments de modélisation et de leurs représentations graphiques, une méthode définit des règles de mise en œuvre qui décrivent l'articulation des différents points de vue, l'enchaînement des actions, l'ordonnancement des tâches et la répartition des responsabilités. Ces règles définissent un processus qui assure l'harmonie au sein d'un ensemble d'éléments coopératifs et qui explique comment il convient de se servir de la méthode. 1. Une méthodologie d'analyse propose au concepteur des modèles, des méthodes et des outils. • Un modèle, au sens d'une théorie de la modélisation, est un ensemble de concepts et de lois (de complétude, de cohérence, de transformation ...) unissant ces concepts. Concepts et lois qui permettent de décrire "intelligemment" une réalité. A titre subsidiaire, un modèle comporte des formalismes, qu'il ne faut pas croire limités aux seuls schémas graphiques ou diagrammes dont, à l'instar de tout concepteur, les informaticiens sont friands. • Une méthode propose des démarches et des règles de bon usage. Idéalement, elle se fonde sur des modèles éprouvés et vise à en exploiter les potentialités en vue de fabriquer des objets répondant à certains critères de qualité (comme, par exemple, les options stratégiques listées dans le texte cité plus haut). • Depuis la fin de la décennie 1980-90 sont apparus sur le marché des outils logiciels d'aide à l'analyse. Ces outils ont reçu le nom de "CASE tools" ("Computer Aided Software Engineering") ou, en français, d'ateliers de génie logiciel. Gradation des tâches effectuées par ces outils : – support (enregistrement et restitution) des formalismes, particulièrement des dessins; – application (vérification) des règles de syntaxe, de cohérence, de complétude ...; – exploitation des lois de transformation spécifiques des modèles, se basant sur les propriétés des objets déjà définis pour définir de nouveaux objets .... 3.2. Utilité d'une méthode [Une] méthode est nécessaire : – pour maîtriser la complexité du problème informationnel à résoudre; – pour sortir la construction des systèmes d'information de l'empirisme individuel et la fonder sur une coopération efficace entre informaticiens et gestionnaires; – pour permettre la communication entre individus de l'équipe de conception; – pour construire des systèmes pertinents, fiables, flexibles et adaptatifs; – pour permettre d'évaluer le système à tout moment de son cycle, tant sur le plan de son efficacité technique que sur celui de sa pertinence par rapport aux besoins des gestionnaires; – pour améliorer les coûts, les délais et la productivité des activités de développement. 2. 1. P.A. MULLER : op. cit. C. ROLLAND : Introduction à la conception des systèmes d'information et panorama des méthodes disponibles; in Génie Logiciel, n° 4.. 2. © A. CLARINVAL Analyse — Introduction. 1-9.

(11) 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 solutions au cas par cas, de sorte que le succès dépend fortement des personnes impliquées dans le projet; – reproductible : l'organisation est capable d'établir des plans raisonnables en termes de budget et de vérifier l'état d'avancement du projet par rapport à ces plans; – défini : le processus de développement est bien défini, connu et compris par tous les intervenants du projet; – encadré : les performances du processus de développement sont mesurables objectivement; – optimisant : les données de contrôle des performances du processus permettent l'amélioration du processus. [...] Le diagramme suivant représente les cinq niveaux de maturité des processus. 1 optimisant ➚ encadré ➚ défini ➚ reproductible ➚ initial. Les équipes de développement ont besoin d’une méthode de travail contrôlée, d’un processus intégrant les diverses facettes du développement et d’une approche commune, c’est-à-dire d’un pocessus capable : – – – –. de dicter l’organisation des activités de l’équipe; de diriger les tâches de chaque individu et de l’ensemble de l’équipe; de spécifier les artefacts à produire; de proposer des critères pour le contrôle et l’évaluation des produits et des activités du projet. 2. 3.3. Schémas et Maquettes "Un modèle est une description abstraite d'un système ou d'un processus, une représentation simplifiée qui permet de comprendre et de simuler."3 Un schéma, dressé dans les formes fixées par un paradigme théorique, constitue une sorte de "discours" sur le domaine décrit, dont l'ambition est double : – discours expliquant que le domaine étudié est intelligible, un schéma sert à faire partager à d'autres (et à l'ordinateur ?) la connaissance relative à ce domaine; – image simulant la réalité à venir, un schéma permet également de vérifier, à l'avance, la pertinence de cette réalité future. 1. P.A. MULLER : op. cit. I. JACOBSON, G. BOOCH, J. RUMBAUGH : Le processus unifié de développement logiciel, trad. française; Eyrolles, 2000. 3 P.A. MULLER : op. cit. 2. © A. CLARINVAL Analyse — Introduction. 1-10.

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

(13) En raison du peu de moyens disponibles, la différence entre un design soigné et un médiocre était quasiment inexistante. Les erreurs de présentation étaient certainement moins nombreuses et moins pénalisantes. Aujourd'hui, le développement d'une application en mode graphique passe nécessairement par la fabrication d'une interface de qualité. La création systématique d'une maquette de la future application est incontournable. La conception de l'interface de l'application devient la nouvelle pierre angulaire de la phase de conception d'un projet. Une présentation peu soignée, une conception inadéquate, et c'est l'échec. Il convient donc de se pencher avec attention sur le problè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'applications. Mais les risques d'erreurs ont grandi d'autant : les variations possibles sont si nombreuses 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, conception orientée objet, etc. — sont des modèles initialement mis au point pour la programmation, dont on a par la suite élargi le champ d'application, de façon telle que leurs concepts puissent décrire d'autres réalités que des composants de programmes. Après avoir outillé l'étape finale de réalisation des systèmes d'information, les méthodologues élargissent leur vision pour remonter vers la source : ils s'intéressent à l'étape de conception, puis à l'étape d'analyse. On peut donc affirmer qu'un programme est lui-même un schéma ou/et une maquette, puisqu'il se fonde sur des concepts de modélisation. Soulignons alors le paradoxe de la programmation traditionnelle : elle modélise l'ordinateur plus que l'application ! En effet, elle se réfère explicitement à la structure matérielle de l'ordinateur; le programmeur décrit la mémoire centrale comme un ensemble d'emplacements au contenu modifiable — les variables — et il impose au processeur un plan d'action — le programme — qui utilise les opérations de base de ce processeur : l'enchaînement séquentiel, les tests de conditions, l'appel de procédure et, surtout, l'opération fondamentale de l'ordinateur : l'affectation d'un contenu à une variable. Pour certains, ce paradoxe explique la difficulté de la programmation, son coût exorbitant ... et la lancinante recherche de nouvelles manières d'aborder — c'est-àdire de penser et de modéliser — la programmation et, par extension, l'analyse.. 3.5. L'équipe de développement Pour terminer, évoquons les rôles qui doivent être remplis au sein d'une équipe attelée à la réalisation d'un projet informatique, et qu'une démarche méthodique doit coordonner.. Il existe quelques rares informaticiens virtuoses, mais quelles que soient les qualités des individus, il arrive un moment où l'ampleur de la tâche à accomplir est telle que l'effort individuel ne suffit plus. Il convient alors de travailler de concert, de coordonner les efforts et de rechercher la performance collective à partir des capacités moyennes de chacun.. 1. J.M. GILLET : L'interface graphique; InterEditions, 1995.. © A. CLARINVAL Analyse — Introduction. 1-12.

(14) Le choix des personnes qui constituent une équipe de développement détermine fortement le déroulement du projet. Au-delà des aspects techniques, le succès d'un projet dépend en grande partie des facteurs humains. Un bon processus de développement permet précisément de retirer la quintessence d'une équipe de développement, de manière reproductible et contrôlée. Les membres d'une équipe efficace doivent d'une part être complémentaires, et d'autre part être bien conscients de leur rôle dans le processus de développement. Il appartient au chef de projet de mettre sur pied cette équipe de personnes, puis d'entretenir le moral des troupes pendant l'ensemble du développement. De manière générale, un processus de développement de logiciel peut se décomposer en trois sousprocessus : – le développement informatique proprement dit, – la logistique qui pourvoit aux besoins du développement informatique, – l'interface avec le reste du monde, qui isole le développement des perturbations externes. [...]. Le développement informatique Le développement informatique est conduit par les trois acteurs suivants : – l'architecte définit la forme générale du logiciel [...]; – les abstractionnistes (de l'anglais abstractionist) identifient les objets et les mécanismes qui permettront de satisfaire les besoins de l'utilisateur; – les développeurs maîtrisent les technologies et réalisent les abstractions identifiées par les abstractionnistes.. 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 activité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 système; – le documentaliste rédige la documentation à destination de l'utilisateur; – l'administrateur–système gère et entretient le parc matériel utilisé par le projet; – l'outilleur construit et adapte les outils logiciels qui forment l'environnement de développement; – le bibliothécaire assure l'archivage et la préservation de tous les artefacts du développement et de leurs règles de production.. L'interface L'interface interagit avec les acteurs suivants : – le chef de projet assure l'interface entre l'équipe de développement et le reste du monde; – le chef de produit supervise une ligne de produits; il coordonne les activités de marketing, de formation et de support technique; – le financier contrôle l'allocation du budget et sa bonne utilisation; – l'utilisateur/client participe à des revues de prototypes; – le support technique résout ou contourne les problèmes rencontrés par les utilisateurs.. © A. CLARINVAL Analyse — Introduction. 1-13.

(15) Les rôles décrits précédemment peuvent être joués par la même personne. Dans les petites organisations, 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 notre propos à la partie automatisée des systèmes d'informations. Notre ambition est de fournir des techniques d'analyse, ainsi que l'armature intellectuelle qu'implique leur mise en œuvre. Dans ce but, nous nous attacherons à décrire différents modèles d'analyse, en nous attardant particulièrement aux règles et critères de manipulation de ces modèles. Dans ce premier cours, nous ne traiterons pas explicitement de l'intégration de ces modèles à une démarche globale d'analyse et de conception — ce sera l'objet d'un second cours.. Une théorie n'est évidemment pas n'importe quel texte grammaticalement correct utilisant un ensemble 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 interconnexions liant les lois que dans les lois elles-mêmes. (Il arrive que des étudiants préparant leurs examens de physique en apprennent par cœur des listes d'équations. Ils peuvent parfaitement réussir leurs examens avec de tels exploits de mémoire, sans que l'on puisse pour autant dire qu'ils comprennent la physique, autrement dit qu'ils en maîtrisent les théories.) Une théorie, du moins une théorie valable, n'est donc pas simplement une sorte de banque de données dans laquelle on peut "rechercher" ce qui se passerait dans telles et telles conditions. C'est plutôt une sorte de carte d'un territoire partiellement exploré. Sa fonction est souvent heuristique, c'est-à-dire qu'elle guide l'explorateur vers d'autres découvertes. Les théories sont donc remarquables [non pas] en ce qu'elles donnent des réponses à des questions, mais [en ce qu'elles] guident et stimulent une recherche intelligente. Et il n'y a pas qu'une seule carte "correcte" d'un territoire. Une photographie aérienne d'un territoire sert une fonction heuristique différente de celle de la carte démographique de ce même territoire. Un usage de la théorie est donc de préparer les catégories conceptuelles dans lesquelles les théoriciens et les praticiens poseront leurs questions et concevront leurs expérimentations. 2. Aux étudiants qui craindraient — et tout autant à ceux qui espéreraient — que ce cours leur propose un outillage rendant inutiles les efforts de créativité, nous livrons cette dernière citation. Une méthode d'analyse doit être un facteur de créativité pour les analystes et pas le contraire, elle représente un catalyseur de leur savoir-faire mais ne remplace pas celui-ci. Le propre d'une méthode de conception n'est pas de rendre ceux qui la pratiquent moins intelligents comme en donnent l'impression les méthodes formulaires qui affectionnent le style "Petit catéchisme" ou le style "procédure militaire", ainsi que semblent le souhaiter des "responsables méthodes" dans certaines organisations. 3. 1. P.A. MULLER : op. cit 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. 2. © A. CLARINVAL Analyse — Introduction. 1-14.

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

(17) © A. CLARINVAL Analyse — Introduction. 1-16.

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

(19) 1. Bases de données et Modélisation. 1.1. Le concept de Système de Gestion de Bases de Données (SGBD) Le concept de base de données (en anglais : data base) est apparu au milieu des années 60, comme palliatif aux inconvénients des fichiers spécialisés que l'on définissait pour couvrir les besoins particuliers de chaque programme. Dans ces accumulations de fichiers dispersés, il était fréquent que les mêmes informations fussent reproduites à plusieurs endroits et de diverses manières : différents fichiers décrivant les clients ou les produits, par exemple. Défauts de ces systèmes : la redondance (répétition des mêmes informations), l'incohérence des mises à jour (les fichiers redondants n'étant mis à jour ni en même temps ni par les mêmes responsables), le partage limité des informations (les divers utilisateurs potentiels ne retrouvant pas leur "point de vue" dans la manière dont les autres représentaient les informations) ... L'idée première fut celle d'un stockage intégré, en une seule collection cohérente, des données d'une application, voire d'une entreprise. L'expression base de données est à entendre dans le sens de base minimale couvrant la totalité des besoins en information d'une application ou d'une organisation. Le principe d'intégration entraînait de nombreuses conséquences : la nécessité de supprimer la redondance ou du moins de la réduire au minimum, la nécessité de structurer avec rigueur, c'est-à-dire de modéliser, la nécessité de stocker en dehors de chaque programme utilisateur une définition commune des données, la nécessité de langages de manipulation de données adaptés, la nécessité de permettre un accès simultané à plusieurs utilisateurs ou programmes, la nécessité de mécanismes garantissant la confidentialité des informations ... Une base de données suppose donc un ensemble de logiciels aptes à assurer ces multiples fonctions, qui composent ce qu'on appelle un système de gestion de bases de données, en abrégé : SGBD (en anglais : Data Base Management System ou DBMS).. 1.2. Niveaux de modélisation a) Vues externes Chaque utilisateur d'une base de données a de celle-ci une connaissance partielle et s'en fait une "représentation" personnelle, en a une "vue" particulière. On appelle vues externes ces représentations propres aux différents utilisateurs de la base de données. Exemple. Une entreprise commerciale possède une base de données couvrant tous les besoins en information des départements impliqués dans son activité de vente. Les vendeurs se font l'idée suivante d'un produit : 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 .... © A. CLARINVAL Analyse — Modélisation des données. 2-2.

(20) b) Vue conceptuelle En vertu du principe de stockage intégré des données, il est nécessaire de concilier les différentes vues externes en une seule vue conceptuelle. Exemple. Pour l'entreprise, la définition commune du concept de produit est la suivante : identification du produit (numéro et dénomination), prix de vente unitaire, taux de TVA (en % du prix de vente), numéro de fournisseur, délai de réapprovisionnement (en jours), stock actuel ("quantité en stock" dans la terminologie des vendeurs), stock plancher, stock plafond.. c) Vue interne Jusqu'ici, on n'a considéré que des notions, des concepts. Pour pouvoir réaliser une base de données effective, on doit encore s'en donner une vue interne qui intègre à la définition conceptuelle les aspects techniques du stockage des données. Exemple. Pour faciliter la recherche des produits, on créera un index sur les numéros de produits et un autre index sur les dénominations. En vue de pouvoir lister rapidement les produits livrés par un fournisseur quelconque, on créera peut-être un index sur le numéro de fournisseur. On choisira de stocker les informations relatives aux produits sur un seul ordinateur ou de les répartir sur plusieurs ordinateurs .... vue externe. vue externe. vue externe. vue externe. vue conceptuelle vue interne. Ce modèle de démarche, à trois niveaux de représentation, est connu sous le nom de modèle ANSI/SPARC (American National Standard Institute, Standards Planning and Requirements Committee). Il a été publié en 1975-78.1. 1. D. TSICHRITZIS, A. KLUG : The ANSI/X3/SPARC DBMS Framework in Information Systems, 1978.. © A. CLARINVAL Analyse — Modélisation des données. 2-3.

(21) 1.3. Langage de description de données — Schémas Un SGBD doit fournir un langage de description de données (DDL Data Definition Language) permettant de cataloguer la définition de chacune de ces vues sous une forme exploitable par les ordinateurs. On donne le nom de schéma à la définition "programmée" d'une vue : schéma conceptuel, schéma interne ou physique, (sous-)schémas externes. Le schéma interne aussi bien que les sous-schémas externes opérationnels sont des variations dérivées du schéma conceptuel; celui-ci joue le rôle de référence commune.. © A. CLARINVAL Analyse — Modélisation des données. 2-4.

(22) 2. Fondements des techniques de modélisation des données. 2.1. Les mécanismes d'abstraction L'abstraction est l'examen sélectif de certains aspects d'un problème. L'objectif de l'abstraction est d'isoler les aspects importants et de supprimer ceux qui ne le sont pas. L'abstraction se réfère toujours à un but précis, car c'est le but qui permet de déterminer ce qui est important et ce qui ne l'est pas. Selon le but recherché, il est possible de construire de nombreuses abstractions à partir d'une même réalité. Toute abstraction est incomplète et imprécise. La réalité est une toile sans couture. Tout ce qu'on peut en dire, toute description qu'on peut en faire est un raccourci. Le langage, les mots humains sont forcément des abstractions, descriptions incomplètes du monde réel. Leur utilité n'est toutefois pas remise en question. Le but de l'abstraction est de limiter l'univers afin de pouvoir agir. Dans la construction de modèles, on ne recherche pas la vérité absolue, mais l'adéquation à un but donné. Il n'y a pas de modèle "correct" unique d'une situation, seulement des modèles adéquats ou inadéquats. 1. a) Classification : Type, Classe, Occurrence, Collection Dans un processus de modélisation, on ne s'intéresse généralement pas à chaque objet particulier de la réalité décrite, mais on envisage des classes d'éléments. Ainsi, parlant de "CLIENT", on désignera par exemple "toute personne physique ou morale ayant passé à notre firme au moins un ordre de commande qui a permis de l'identifier". On définit de cette manière le type commun de tous les éléments de la classe. Dans la littérature informatique, par un abus de langage qui complique quelquefois la compréhension des choses, les deux termes classe et type sont employés l'un pour l'autre : une classe nommée ("CLIENT") et définie ("toute personne ayant ...") est également appelée un type. Plus précisément, une classe est l'ensemble concret de tous les éléments qui vérifient la définition d'un type, ensemble abstrait d'éléments "imaginables". Le type est une création pure de l'esprit, qui n'existe que par sa définition. Tout élément appartenant à une classe ou un type est une occurrence (en anglais : "instance") de cette classe ou de ce type. Exemples :. type ETUDIANT NOMBRE ENTIER SEXE COMMANDE FICHIER DE COMMANDES. occurrences Jean, Jacques, Emile 1, 3, 37, 1236, 3217 masculin, féminin la-commande-reçue-aujourd'hui-du-client-X fichier-des-commandes-reçues-ce-jour. Le type "FICHIER DE COMMANDES" est un type dont chaque occurrence (par exemple, le "fichier-descommandes-reçues-ce-jour") constitue un sous-ensemble de la classe "COMMANDE", ce que nous appellerons une collection. Cet exemple illustre la manière de modéliser un ensemble : l'ensemble et l'élément font tous deux l'objet d'une définition de type, chaque occurrence d'ensemble (ou collection) est un sous-ensemble du type de l'élément. Quant au type d'une collection, c'est un ensemble puissance.. 1. J. RUMBAUGH, al. : OMT — Modélisation et conception orientées objet, trad. française; Masson, 1995.. © A. CLARINVAL Analyse — Modélisation des données. 2-5.

(23) occurrence collection classe type. La définition d'un type est une définition d'ensemble, le plus souvent en compréhension ("toute personne ayant ..."), d'autres fois en extension ("masculin, féminin"). Remarque. Le contexte du discours dispense souvent de préciser si l'on parle de types (par exemple, dans l'expression abstraite "toute COMMANDE émane d'un et un seul CLIENT") ou d'occurrences ("ma commande du 29/08/2000"). La présence de quantificateurs "tout, toujours, certains, parfois, un et un seul, un ou plusieurs, au moins un, un au plus..." est le signe d'un discours abstrait, portant sur les types. Il est essentiel de fournir la définition constitutive des types reconnus; c'est elle qui en exprime la signification. (Un "CLIENT" est-il "toute personne ayant passé au moins une commande, etc." ou, plus largement, "tout client ou prospect" ? Les "SEXEs" possibles sont-ils "masculin et féminin" ou plutôt "masculin, féminin et inconnu" ? ...). b) Spécialisation, Généralisation La spécialisation distingue des sous-classes à l'intérieur d'une classe, des sous-types à l'intérieur d'un type (ex.: la spécialisation de NOMBRE en ENTIER, REEL, etc.; la spécialisation du PERSONNEL en OUVRIER et EMPLOYE; la spécialisation des CLIENTS en clients PRIVES et PROFESSIONNELS). Toute occurrence d'une sous-classe "hérite" des propriétés définies dans le sur-type (un OUVRIER possède toutes les propriétés d'un membre du PERSONNEL ... plus certaines propriétés spécifiques; un CLIENTPROFESSIONNEL possède toutes les propriétés d'un CLIENT, plus un numéro de TVA). Remarquons que toute définition en compréhension ("CLIENT = [1] toute personne [2] ayant ...") relève de la spécialisation. PERSONNEL OUVRIERS. EMPLOYES. Pierre Paul. Jacques André. CLIENT nom adresse. hérite PRIVE. hérite PROFESS. n°TVA. La généralisation est une abstraction globalisant (mettant "en évidence") dans un sur-type les propriétés communes de différents types (ex.: l'abstraction MOUVEMENT DE STOCK créée sur la base des types ENTREE EN STOCK et SORTIE DE STOCK, pour laquelle il faut créer artificiellement la propriété SIGNEDU-MOUVEMENT).. © A. CLARINVAL Analyse — Modélisation des données. 2-6.

(24) Grâce à la non duplication des propriétés "mises en évidence" au niveau du sur-type et dont "héritent" automatiquement les sous-types, spécialisation et généralisation sont des procédés économiques précieux, permettant de construire des modèles plus compacts.. 2.2. Mécanisme de désignation des occurrences a) La relation de dépendance fonctionnelle On dit qu'un type d'objet B dépend fonctionnellement d'un type d'objet A si, à chaque occurrence de A, correspond au plus une occurrence de B. Ce qui se note A → B. On dit aussi que l'objet B est déterminé par le déterminant A : connaissant une occurrence de A, on peut retrouver l'occurrence de B correspondante. Exemples :. n° national → personne n° de TVA → firme n° de commande → nom du client dont elle émane. La définition s'étend facilement au cas des déterminants ou déterminés constitués de groupements d'objets. Exemples :. n° national → (nom, date de naissance, sexe) (barème, ancienneté) → salaire mensuel. La relation de dépendance fonctionnelle est asymétrique. Il n'est pas vrai qu'un client puisse transmettre une commande au plus; s'il est vrai qu'à une personne correspond un seul numéro national, cette relation n'est plus vraie si — pour rester pratique — on la reformule par rapport aux noms (et prénoms) de personnes .... b) Le concept d'identifiant La relation de dépendance fonctionnelle fonde le mécanisme qui permet de distinguer sans ambiguïté les occurrences : 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 occurrences (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 temporelles de l'information, les modèles courants ne fournissent pas de concept particulier pour décrire cet aspect des choses ... devant lequel l'analyste se sent donc plus d'une fois mal à l'aise. Les paragraphes suivants introduisent le problème, en distinguant des dimensions temporelles multiples.. a) Durée de vie Les objets par rapport auxquels on enregistre de l'information ont une durée de vie déterminée. On a défini plus haut le type CLIENT comme l'ensemble de "toutes les personnes physiques ou morales ayant passé au moins un ordre de commande"; ne faudrait-il pas ajouter "depuis moins de deux ans" ?. © A. CLARINVAL Analyse — Modélisation des données. 2-7.

(25) b) Période de validité L'information relative à un objet possède une période de validité. (N.B. Une durée est une "longueur" de temps; une période est une durée "localisée" dans le cours du temps.) Une période de validité est un intervalle compris entre deux dates de début (incluse) et de fin (exclue) : [début, fin[.1 (Selon la vitesse d'évolution du système décrit, il peut être nécessaire de mentionner l'heure.) Les positions de cette période par rapport à la date du jour définissent différents états de l'information : – aujourd'hui < date de début < date de fin : information détenue mais non encore valide, – date de début ≤ aujourd'hui < date de fin : information actuellement active, – date de début < date de fin ≤ aujourd'hui : information passée (historique). Dans les deux premières situations, la date de fin de validité est le plus souvent inconnue. L'identification complète d'une occurrence d'information, par exemple telle qu’elle figure sur un formulaire ou un document, comporte donc en principe : – le nom d'un type – une valeur d'identifiant – l'indication d'une période de validité. (ex.: "le SOLDE DU COMPTE"), (ex.: "de numéro 000-00000002-02"), (ex.: "au 01/09/2000").. Cependant, la dernière de ces indications (la date) est souvent omise, ce qui est possible lorsque, dans la collection visée, on ne distingue pas différentes périodes de validité (on tient pour actuelles toutes les informations 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 moment, et conservée en mémoire un certain temps. On parle à ce propos de période de mémorisation et de durée de rétention. Une information peut être enregistrée avant de devenir valide; elle peut être ignorée, c'est-à-dire non enregistrée, aux premiers temps de sa période de validité; dans de très nombreux cas, elle est conservée en mémoire, dans des fichiers historiques ou d'archives, bien au delà de sa période de validité .... 2.4. Contraintes d'intégrité Les contraintes d'intégrité sont des prédicats ou assertions intégrées au schéma de la base de données, que celle-ci doit vérifier pour être considérée valide — on dit cohérente. Les contraintes d'intégrité sont formulé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.. © A. CLARINVAL Analyse — Modélisation des données. 2-8.