Thesis
Reference
Intégration des spécifications dans la conception des systèmes d'information
ESTIER, Thibault
Abstract
Les spécifications formelles jouent un rôle croissant dans la conception et la conduite des systèmes d'information (SI) aujourd'hui. A partir d'un modèle orienté objet, l'approche proposée par l'auteur permet d'intégrer les spécifications issues des différents aspects d'un SI: structures des classes, cycles de vie des objets, contextes sémantiques, événements et processus. L'étude des propriétés du système s'appuye sur une interprétation formelle basée sur les réseaux de Petri. L'auteur décrit les outils qu'il a mis en œuvre pour supporter cette approche. Ceux-ci contiennent notamment un dictionnaire de spécifications intégré au SI généré, où toutes les spécifications participent sous forment d'objets du système au fonctionnement et au contrôle de l'évolution de celui-ci.
ESTIER, Thibault. Intégration des spécifications dans la conception des systèmes d'information . Thèse de doctorat : Univ. Genève, 1995, no. SES 421
DOI : 10.13097/archive-ouverte/unige:155399
Available at:
http://archive-ouverte.unige.ch/unige:155399
Disclaimer: layout of this document may differ from the published version.
1 / 1
des systèmes d'information
Thibault ESTIER
éditions systèmes et information
Chez le même éditeur Thèses
Interrogation de bases de données à l'aide d'un modèlè sémantique, par Gilles Falquet, 1989 (Prix LaJsis 1990).
Atelier de génie logiciel et spécification de logiciel, par Didier Buchs, 1989.
Sémantique des bases de données: un modèle et une réalisation, par Marc Junet, 1990.
Optimisation globale des contrôles d'intégrité dans une base de données, par Le Pham Ngung Huong, 1990.
Une approche multivaluée du. cnncept de croyance: représentation et rai- sonnement, par Jacques Mouttet, 1992.
Parallélisation des couches supérieures du modèle OS/: stratégie et mise en oeuvre, par Stéphane Spahni, 1993.
Groupage perceptuel asynchrone pour la compréhension qualitative d'im- ages: des contours aux primitives génériques, par Alain Jacot-Descombes, 1993.
Extraction et représentation de la connaissance tirée de textes médicaux, par Anne-Marie Rassinoux, 1994.
Un système d'information botanique: contribution au désenclavement de l'information, par Catherine Zellweger, 1995.
Un environnement de développement de spécifications pour systèmes con- currents, par Jacques Flumet, 1995.
Autres ouvrages en informatique
Évolution des méthodes de conception et de développement de systèmes d'in- formation, ouvrage collectif, 1990.
Conception et génération d'applications bases de données, actes des journées de travail de Beaune, 1991.
Modèle relationnel et SQL -théorie et pratique, par Jacques Guyot, 1994.
dans la conception des systèmes d'information
THÈSE
présentée à la faculté des sciences économiques et sociales de l'Université de Genève
par
Thibault ESTIER
pour l'obtention du grade de Docteur ès sciences économiques et sociales,
mention systèmes d'information
Membres du jury de thèse:
MM. Eugen HORBER, professeur, président du jury Michel ADIBA, professeur, Université de Grenoble François BODART, professeur, Université de Namur Jean-Paul de BLASIS, professeur
Dennis TSICHRITZIS, professeur
Michel LEONARD, professeur, directeur de thèse
Thèseno421
éditions systèmes et information (ESI) Genève, 1995
La Faculté des sciences économiques et sociales, sur préavis du jury, a autorisé l'impression de la présente thèse, sans entendre, par là, émettre aucune opinion sur les propositions qui s'y trou- vent énoncées et qui n'engagent que la responsabilité de leur auteur.
Genève, le 3 novembre 1995
Le doyen Beat BÜRGENMEIER
Impression d'après le manuscrit de l'auteur
©éditions systèmes et information, Genève - 1996 ISBN 2-940105-06-5
compagne et complice de toujours, source inépuisable d'encouragements et de compréhension,
àSolenn, qui a attendu patiemment, que cette fameuse "thèse"
lui rende enfin son papa.
Table des Matières
1 Introduction
Contexte de cette étude ... 1
2 L'importance de l'intégration des spécifications ... 2
3 L'intégration des spécifications dans les autres approches ... 3
3.1 OSSAD [Dumas 90] ... .4
3.2 IDA [Bodart 89] ... .5
3.3 OOSE (Objectory) [Jacobson 92) ... 6
3.4 ExSpect [van Hee 94] ... 8
4 Présentation du plan du mémoire ... 9
II Spécifications statiques et dynamiques 5 Le Modèle statique (F2) ... 11
5.1 Présentation des concepts ... 12
5.2 Structure des objets ... 16
5.2.1 Schéma d'une base d'objets ... 16
5.2.2 Instance du schéma d 'une base ... 17
5.2.3 Collections d'objets ... 17
5.2.4 Spécification du schéma d'une base ... 18
5.3 Comportement générique des objets: primitives ... 19
5.3.1 Create ... 19
5.3.2 Enter ... 20
5.3.3 Delete ... 20
5.3.4 Assign ... 21
5.3.5 Eval ... 22
5.4 Vues sur la base d'objets: contextes ... 22
5.4.1 Instance d'un contexte: fonction de connexion ... 23
5.4.2 Propriétés de la fonction de connexion ... 24
5.4.3 Spécification de contextes ... 25
5.5 Opérations sur les contextes: Assert(t) et Retract(t) ... 26
5.5.1 Assert(t) ... 26
5.5.2 Retract(t) ... 28
6 Le Modèle dynamique (MTG) ... 29
6.1 Présentation des concepts ... 29
6.2 Réseaux de Petri et structures dynamiques ... 34
vi Intégration des Spécifications
6.2.1 Définitions et propriétés élémentaires ... 34
6.2.2 Les opérateurs du langage MTG ... 35
6.2.3 Réseaux de Petri et Structure dynamique ... .39
6.3 Cycle de vie des objets ... .40
6.3.1 Définitions ... .40
6.3.2 Spécification d'un cycle de vie d'objets ... .41
6.3.3 Interprétation d'un cycle de vie d'objets ... .42
6.4 Structure d'événements ... .43
6.4.1 Définition ... 43
6.4.2 Spécification d'une structure d'événements ... .45
6.4.3 Interprétation d'une structure d'événements ... .45
6.5 Processus et cycle de vie global ... .46
6.5.1 Dé.finitions ... .46
6.5.2 Spécification de processus ... .47
6.5.3 Interprétation d'un processus ... .48
6.5.4 Structure de processus. et cycle de vie global ... .48
7 Vue d'ensemble du modèle proposé ... .51
7.1 Définitions, spécifications et interprétations ... 51
7.2 Vue d'ensemble des interprétations: modules ... .51
III
Intégration descriptive 8 Le dictionnaire de spécifications ... 558.1 Intégration des spécifications dans le dictionnaire ... 56
8.2 Auto-validations des spécifications ... 58
8.2.1 Contraintes intrinsèques aux instances cohérentes ... .58
8.2.2 Spécifications contenant des cycles ... 59
8.2.3 Spécifications contenant des graphes ... 61
8.3 Avantage de l'unifonnité de représentation ... 64
9 Le langage MTG ... 66
9.1 Un langage de raffinements de RdP ... 66
9.1.1 Classes de réseaux de Petri ... 66
9.1.2 Primitives MTG et Classes de Réseaux ... 67
9.1.3 Primitives MTG et Vivacité ... 68
9.2 Adéquation des raffinements, consolidation du CVG ... 71
9.2.1 Compatibilité de la granularité des états ... 72
9.2.2 Compatibilité sémantique des événements ... 72
9.3 Propriétés dynamiques du CVG ... 74
9.3.l Construction du CVG ... 74
IV
V
VI
VII
VIII9.3.2 Compatibilité entre CVG et structure d'événements ... 75
Intégration effective 10 Interprétation exécutable ... 80
10.1 Instanciation de l'état du système ... 80
10.2 Instanciation du comportement ... 80
10.2.1 Comportement local ... 81
10.2.2 Comportement global ... 83
10.3 Moniteur d'événements ... 84
10.3.1 Mode d'exécution réactif ... 85
10.3.2 Mode d'exécution interactif. ... 85
11 Evolution des spécifications ... 87
11.1 L'approche classique & l'approche évolutive ... 87
11.2 Transformation d'une interprétation ... 89
12 Outils pour l'intégration de spécifications ... 90
12.1 Le système de gestion de base de données Farandole 2 ... 90
12.2 Le compilateur MTG ... 91
12.3 Autres composants de l'environnement F2+MTG ... 91
Conclusion Références bibliographiques Index des définitions Annexes Le théorème du rang ... 105
Preuves du paragraphe 9.1 ... 106
Granunaire BNF du langage MTG ... 108
Schéma du dictionnaire de spécifications ... 109 Description des caractéristiques évolutives du SGBD Farandole 2 (F2) 110
I Introduction
1 Contexte de cette étude
La complexité croissante des systèmes d'information (SI) utilisés aujourd'hui a favorisé l'émergence d'un grand nombre de méthodes de conception qui proposent le plus souvent une dé- marche appuyée sur des outils formels (langages de spécification) ou techniques (environnements informatisés de conception). Ces méthodes fournissent une assistance aux personnes chargées de l'élaboration du SI dans leurs travaux d'analyse, de développement et de mise en œuvre. On peut citer entre autres les méthodes Merise [Tardieu 83], IDA [Bodart 89], Remora [Rolland 82] pour leur popularité en Europe francophone, SADT [Ross 77], Structured Analysis [De Marco 79] ou Information Engineering [Martin 89], plus répandues dans le monde anglophone. D'autres mé- thodes sont centrées sur certains aspects particuliers du SI, l'interface utilisateur du système Software through Pictures [Wasser. 86], ou l'analyse de l'organisation et des activités autour d'un SI: OSSAD [Dumas 90]. A la fin des années 80, l'entrée en force des concepts orientés-objets dans les SI a favorisé l'émergence d'une nouvelle vague de méthodes. Certaines sont nées d'une adaptation de méthodes antérieures (p.ex. OOA/OOD [Coad 91], OMT[Rumb. 91]), d'autres pui- sent leurs concepts plus directement dans les fondements des langages de programmation orien- tés-objets (OOSE [Jacobson 92], OODA [Booch 91]). Il est devenu presque impossible d'être exhaustif dans ce domaine: une étude publiée en septembre 1992 [Monarchi 92] recensait 83 mé- thodes orientées-objet différentes. Ce nombre dépasse certainement la centaine aujourd'hui. Tou- tefois, bon nombre de ces méthodes récentes se résument souvent à des propositions de notations graphiques ou textuelles et sont surtout centrées sur la phase de développement des systèmes d'in- formation.
La plupart de ces méthodes proposent plusieurs modèles pour exprimer les spécifications du SI: modèles de données (conceptuels ou informatiques), modèles de traitements (en termes d' évé- nements ou de fonctions), modèles de communication (techniques ou humains). Les démarches qui adoptent l'approche orientée objet tendent généralement vers un modèle unique pour définir les entités considérées et les opérations qui s'y appliquent directement (encapsulation objets/mé- thodes [Atkinson 89], [Adiba 89]). Cependant ce modèle comporte toujours des aspects structu- rels, liés à l'état des objets, et dynamiques, liés à la synchronisation et à la communication entre objets. Nous nous intéressons ici aux formalismes proposés pour exprimer et valider ces différents modèles.
2 Intégration des Spécifications
2 L'importance de ! 'intégration des spécifications
Dans les approches mentionnées ci-dessus, les formalismes retenus pour exprimer les différents modèles sont assortis de règles de validation. Elles permettent au concepteur de vérifier que cha- cune de ses spécifications satisfait un certain nombre de critères de cohérence. Malgré la grande richesse de ces règles à l'intérieur de chaque modèle, peu d'indications sont fournies au concep- teur pour déterminer si la réunion de ses spécifications forme un ensemble cohérent. La plupart des méthodes sous-entendent que si toutes les spécifications sont valides, l'ensemble constitue une spécification globale correcte du S.I. Les vérifications de cohérence entre modèles sont géné- ralement effectuées sur des tableaux croisés permettant de confronter la liste des concepts d'un modèle avec celle d'un autre (par exemple, liste des types d' informations en ligne et liste des pro- cessus qui s'y appliquent en colonne). Ce procédé très répandu et facile à mettre en œuvre est re- pris presque systématiquement dans les outils d'aide à la conception commercialisés avec les méthodes. Ces v6rifications syntaxiques d'existence (il existe bien telle information pour alimen- ter tel processus, il existe bien tel processus pour produire telle information) ne suffisent pas tou- jours pour dégager la sémantique globale du système en projet.
La validation sémantique d'un système doit pouvoir s'appuyer sur une interprétation univo- que de ses spécifications. Le moyen le plus sûr de garantir l'unicité d'interprétation est de définir formellement comment celle-ci est construite. Cette approche reconnue depuis longtemps dans le génie logiciel des systèmes temps-réel embarqués (avionique ou télécommunications, par exem- ple) commence à pénétrer le domaine des systèmes d'information (voir par exemple [Dubois 94 ]).
Une interprétation sûre des spécifications d'un SI permet, si nécessaire, d'accorder les différentes vues qu'en possèdent tous les acteurs impliqués dans sa conception ou sa conduite: utilisateurs, responsables organisationnels, concepteurs, développeurs, méthodologues, etc. Elle tient lieu d'arbitre dans les malentendus possibles entre ces personnes. Elle facilite également l'intégration dt:s ùiffét'ents résultats d' ruuùysc: lorsque certaines spécifications sont :ijontées ou modifiées il est possible de raisonner sur l'interprétation formelle pour savoir comment les propriétés du système s'en trouvent changées.
Dans la littérature récente, le terme d'intégration est souvent utilisé pour désigner une activité de fusion de spécifications d'origines différentes, formulées dans un même modèle. Il s'agit par exemple d'intégration de schémas de différentes bases de données pour obtenir un schéma global en vue de fédérer plusieurs bases ou en vue d'en construire une nouvelle à partir du contenu d' an- ciennes. Dans d'autre cas, l'intégration est liée à la réutilisation de composants logiciels ou à la réutilisation de spécifications génériques. La possibilité de construire une interprétation formelle rend certainement des services dans les deux cas cités précédemment (on connaît un peu mieux les propriétés des systèmes qu'on tente de fusionner ou de réutiliser). Toutefois, la réutilisation suppose que soient réunies beaucoup d'autres conditions qui débordent du sujet de ce travail.
Nous présentons ici des contributions à deux aspects de l'intégration des spécifications:
• l'intégration descriptive, c'est-à-dire l'ensemble des validations possibles qu'on peut ef- fectuer sur les spécifications issues de différents modèles et munies de leur interprétation, afin d'anticiper au mieux les propriétés du système décrit,
• l'intégration effective, ou les conditions à réunir pour embarquer les spécifications dans le système opérationnel, non pas seulement à titre documentaire ou descriptif, mais en tant que composants actifs du système. Ces spécifications embarquées peuvent jouer un rôle détenninant pour conduire l'évolution du système.
3 L'intégration des spécifications dans les autres approches
Dans le tableau ci-dessous, nous avons représenté une classification de méthodes de conception selon que les spécifications et leurs interprétations sont appuyées sur un formalisme ou non. Une méthode semi-formelle propose des langages de spécifications fonnels (graphiques ou textuels) et une interprétation iaformelle de ceux-ci. Une méthode formelle fournit en plus un moyen de construire .formellement une interprétation de ses spécifications. Dans la suite de ce paragraphe, les qualificatifs «formels» ou «semi-formels» ne connotent aucun jugement de valeur sur ces mé- thodes, mais font simplement référence aux caractéristiques présentées dans ce tableau.
méthodes méthodes méthodes
informelles semi-formelles formelles
spécifications inf annelles formelles formelles
(syntaxe)
interprétations infonnelles informelles formelles
(sémantique)
vérification des difficile (travail col- possible, possible, spécifications lectif délicat) automatisable automatisable (validation syntaxique)
vérification des impossible ou arbi- basée sur l'expérience possible, éventuel- interprétations traire de «l'expert» lement assistée,
(validation sémantique) preuves
La répartition en trois colonnes ci-dessus est en fait trop rigide pour discerner correctement le degré de formalisation proposé par les méthodes. On peut considérer qu'une méthode est plus ou moins formelle qu'une autre en fonction du nombre d'aspects spécifiés pris en compte dans l'interprétation. On peut également prendre en compte l'étendue des possibilités offertes par le formalisme choisi pour raisonner sur l'interprétation du système. Pour illustrer les différences qu'on peut rencontrer aujourd'hui dans ce domaine, nous avons choisi quatre méthodes qui se dis- tinguent assez bien les unes de autres du point de vue de l'utilisation de formalismes pour tra- vailler les spécifications d'un S.I. Nous ne présentons pas l'intégralité de ces méthodes mais simplement les modèles qu'elles proposent pour exprimer des spécifications.
4 Intégration des Spécifications
3.1 OSSAD [Dumas 90]
La méthode OS SAD a été définie au cours d'un projet ESPRIT de la commission des communau- tés européennes. Elle vise l'analyse, la conception et la mise en œuvre des systèmes bureautiques (Office Support Systems). La notion de bureau sous-jacente est à prendre au sens large: tout lieu où l'intelligence humaine traite de l'information assistée par des moyens technologiques ([Dumas 90] page 9). Bien que les auteurs reconnaissent que la frontière entre systèmes bureautiques et systèmes informatiques s'estompe progressivement, ils indiquent que l'accent est mis ici sur l'usage collectif qui est fait des systèmes techniques par les acteurs humains, dans le cadre de leur activité professionnelle. L'ambition de la méthode OSSAD est donc de mettre l'accent sur la modélisation de l'organisation sous l'angle de la communication et du traitement de l'informa- tion. Elle propose un vocabulaire précis (le glossaire «ossadique») et un ensemble de modèles pour formuler des spécifications OSSAD, ainsi qu'une démarche de mise-en-œuvre de la métho- de.
Les spécifications sont exprimées à l'aide de trois types de modèles:
• modèle abstrait: permet un découpage global du réel organisationnel observé en termes de fonctions décomposables en sous-fonctions, s'échangeant des paquets d'information. Les sous-fonctions atomiques sont appelées activités. Par les concepts et par les formes graphi- ques proposées, il est très proche du modèle conceptuel de communication (MCC) de Me- rise [Diviné 94],
• modèle descriptif: décrit les activités en termes de tâches assurées par des rôles (regroupés en unités organisationnelles et assumés par des acteurs), tâches découpées en opérations s'effectuant à l'aide de ressources (informationnelles) et d'outils,
• modèle prescriptif définit des spécifications techniques et organisationnelles des solutions retenues par un modèle descriptif, s'appuyant si nécessaire et au gré des praticiens de la méthode sur l'un ou l'autre formalisme ou atelier de gënie logiciel existant d'une part et sur des pratiques traditionnelles de modélisation organisationnelles (organigrammes, dia- grammes de communication, etc.). Ce modèle dont la forme n'est pas définie par OSSAD, constitue l'interface de la méthode avec les personnes et les moyens nécessaires à la mise en œuvre du système étudié.
Les modèles abstraits et descriptifs sont exprimés par des fiches de documentation et des dia- grammes de trois types:
• des graphes de relations pour exprimer la circulation de paquets entre fonctions ou la cir- culation de ressources entre rôles ou entre opérations (très proches de diagrammes de flux);
• des diagrammes d'enchaînements basés sur les réseaux de Petri (cf. paragraphe 6.2 page 34) pour exprimer le déroulement d'une tâche ou la coopération entre rôles pour accomplir une procédure, une certaine liberté dans l'usage du formalisme est recommandée pour fa- voriser la lecture: suppression de places ou introduction de transitions supplémentaires non-nécessairement liées à des concepts du modèle;
• des matrices activités/rôles, les cases pleines de ces matrices caractérisant les tâches.
L'accent étant mis sur le «comment on procède» plutôt que sur le «que traite-t-on», il n'y a pas à proprement parler de modèle de données. L' infonnation est caractérisée par les échanges et les flux auquels elle participe. Toutefois, les deux notions de paquet (dans le modèle abstrait) et de ressource (dans le modèle descriptif) permettent de documenter les fomes que doivent ou peu- vent prendre cette information. Les règles syntaxiques constituent surtout un ensemble de recom- mandations pour la clarté, la concision ou l'accessibilité des spécifications, plutôt qu'un ensemble normatif pour définir des spécifications conformes. Les représenrations graphiques sont assorties d'un certain nombre de règles de représentation.
L'interprétation des spécifications se base en grande partie sur les noms des concepts des dif- férents modèles. Ces termes sont soigneusement choisis (dans les 4 langues <<officielles» de lamé- thode - voir tableau page 34 de [Dumas 90]) car ils appuyent l' interprétation sur la langue naturelle (OS SAD suppose que tour le mc;mde est d'accord sur la signification d'une activité, d'un rôle, d' une tâche, parce que ce sont des termes simples et courants dans la pratique organisation- nelle). En pratique, !'interprétation des spécifications OS SAD repose très largement sur la présen- ce d'un «expert ossadique» ou sur un nombre suffisant d'itérations dans la démarche de modélisation pour obtenir un consensus sur les solutions proposées. Cette méthode correspond assez bien à la catégorie des méthodes semi-formelles décrite par le tableau ci-dessus. La forma- hsation intervient de façon discrète dans l'expression des spécifications, mais pas dans l' interpré- tation de celles-ci.
3.2 IDA [Bodart 89]
IDA (Interactive Design Approach) est une méthode de conception de SI proposant un ensemble de modèles, des outils logiciels1 et'une démarche. Les modèles proposés comprennent:
• modèle Entité/Association (EA) pour définir les informations mémorisées et traitées, il comprend outre les concepts de type d'entité et d'association du modèle EA d'origine, le concept de sous-type et une batterie de contraintes structurelles (identifiants, connectivité, inclusion, exclusion, etc.);
• modèle de structuration des traitements, pour définir une hiérarchie arborescente de traite- ments, identifiés par les concepts de projet, d'application, de phase et de fonction, selon le niveau de décomposition du traitement considéré, ces quatre concepts sont assortis de cri- tères d'identification facilitant la modélisation;
• modèle de la statique des traitements, pour déterminer les propriétés de chaque traitement (essentiellement pour les phases et les fonctions): objectif, performances, informations consommées, informations produites, informations consultées en mémoire, actions sur la mémoire (ajouts, retraits, etc ... ), règles spécifiant la relation existant entre ces différentes informations (de façon algorithmique, algébrique, logique, etc.);
• modèle de la dynamique des traitements, pour déterminer les règles d'enchaînements, de synchronisation entre les traitements, le modèle introduit le concept d'événement (associé
1. IDA est une marque déposée par la société METSI-France et le nom del' environnement de con- ception qu'elle diffuse.
6 Intégration des Spécifications
à une information produite par un traitement ou associé à la terminaison d'un traitement) et le concept de processus qui est simplement l'activation d'un traitement;
• modèle des ressources, permettant de déterminer et quantifier les ressources nécessaires à l'exécution des processus, en considérant celles qui peuvent éventuellement manquer de telle sorte à empêcher le déroulement d'un processus (temps, espace, disponibilité de per- sonnes, capacité de lignes de communication, etc.);
• diagrammes de flux, ils constituent essentiellement un résumé des modèles statiques et dy- namiques de traitements pour faciliter la prise de décision dans des phases préalables d'un projet.
Les spécifications sont rédigées dans le langage DSL qui comprend une forme textuelle et une forme graphique pour chacun des modèles (certains points de détails spécifiés n'apparaissent que dans la forme textuelle). Chaque modèle est assorti d'un grand nombre de règles de deux ty- pes: règles de complétude et de cohérence. Les régles de complétude fixent les exigences mini- males que doivent satisfaire les spécifications de chaque modèle pour être considérées comme bien-formées. Les règles de cohérence permettent de détecter des contradictions entre différents niveaux de détail dans un même modèle ou entre différents modèles. Certaines règles de cohérence sont plus indicatives que normatives. Dans l'outil d'aide à la conception, les spécifica- tions sont conservées dans un dictionnaire entouré d'utilitaires de saisie, de validation et de res- titution des spécifications, ainsi que d'un gestionnaire de dialogues avec les concepteurs.
L'interprétation des spécifications est assurée par deux activités complémentaires à l'acqui- sition des spécifications: la génération de prototypes et la simulation, toutes deux assistées par l'outil d'aide à la conception (composants DSL/Proto et DSL/Sim). La simulation et la génération de prototypes permet de mettre en évidence les performances du système en regard des ressources disponibles, de vérifier le comportement spécifié par les règles de traitement et de vérifier si les dialogues hommes-machines issus des spécifications dynamiques sont conformes aux postes de travail qui vont les exploiter. Elles indiquent la faisabilité d'une solution retenue et permettent d'itérer sur les spécifications à partir de critères mesurables avant l'existence du système projeté.
L'environnement de conception assurant automatiquement la génération des prototypes et les tests de simulation à partir des spécifications en DSL, l'ensemble fournit une interprétation uni- voque des spécifications, mais la construction de cette interprétation (c'est-à-dire les règles de gé- nération) sont plus ou moins enfouies dans l'outil de conception. Cette approche est un peu a mi- chemin entre les méthodes semi-formelles et les méthodes formelles.
3.3 OOSE (Objectory) [Jacobson 92]
OOSE (Object Oriented Software Engineering) est une définition de modèles sur lesquels est construite la méthode Objectory et l'environnement de conception OrySE. OOSE vise à appliquer les paradigmes de l'approche orientée-objet à toutes les phases d'analyse, de développement et de mise-au-point d'un système. L' intention est d'éviter de changer brutalement de cadre concep- tuel en passant d'une analyse par décomposition fonctionnelle vers une architecture et un déve- loppement orienté-objet. Développée à l'origine (1985-1986) pour les applications de télécommunications (la version initiale d'Objectory a donné lieu à une norme de spécifications
du CCITT), la méthode a été étendue par la suite pour couvrir le domaine des systèmes d'infor- mation. Elle propose une suite de modèles qui permettent d'opérer un glissement plus ou moins continu à partir de l'analyse des besoins jusqu'à l'implantation et au test du système:
• modèle de l'analyse de besoins (requirements model), défini sur la notion d'acteur (inter- venant extérieur au système) et de use case. Ce dernier terme est délicat à traduire en fran- çais et correspond à peu près à situation type d'usage du système et nous garderons ici le terme d'usage. Un usage traduit un ensemble d'événements adressés par un acteur (en principe humain) à un système. L'idée sous-jacente est que toute l'architecture du système sera conditionnée par l'interaction avec ses utilisateurs. Les usages peuvent être abstraits (factorisant certains événements pour d'autres usages) ou concrets auquel cas on peut les retrouver tels quels dans le système existant. Ce modèle inclut encore la définition des in- terfaces hommes-machines (de façon abstraite plutôt que technique) et des objets «natu- rels» du champ d'application (problem domain abjects) ainsi que les associations statiques et dynamiques qui existent entre eux;
• modèle d'analyse (conceptuelle du système), défini à l'aide de trois types d'objets: les en- tités, les interfaces et les contrôles. Cette répartition en trois catégories se rapproche dupa- radigme MVC (modèle, vue, contrôleur) de Smalltalk [Goldberg 83) ou plus précisement du modèle PAC (présentation, abstraction, contrôle) de Joëlle Coutaz [Coutaz 88). Ce mo- dèle sert à structurer le précédent en répartissant les fonctionnalités demandées par chaque usage entre des objets de ces trois catégories. Il définit également les relations qui existent entre ces objets: associations statiques (acquaintance) et dynamiques (communication) as- sorties de contraintes de cardinalité, agrégations, attributs des entités, factorisation des propriétés par héritage. Lorsqu'un modèle d'analyse contient un grand nombre d'objets, il peut être découpé en sous-systèmes, en fonction du couplage fort qui existe entre des ob- jets des trois types pour structurer un usage. Les usages les plus simples peuvent être struc- turés avec simplement des objets-interfaces et des objets-entités. Dans les cas plus complexes, les objets-contrôles servent à factoriser une partie du comportement modélisé qui touche plusieurs interfaces et entités. Ils permettent de localiser certaines fonctionna- lités d'un usage sans les éclater sur plusieurs autres objets;
• modèle d'architecture du système (design model), est un prolongement des deux modèles précédents où l'on intègre progressivement les contraintes de l'environnement technique qui supporte le système (répartition de sites, découpages imposés par le langage ou les outils de développement). Il indique quelles solutions sont choisies pour mettre en œuvre le système décrit dans le modèle d'analyse. Il est basé sur la notion de bloc (pour anticiper comment le code source devra être structuré dans l'implantation), de stimulus et il est structuré par des diagrammes d'interaction, qui indiquent les échanges de stimuli entre blocs. Chaque usage du modèle initial possède un tel diagramme dans le modèle d'archi- tecture;
• modèle d'implantation et de test, dérivé du précédent, il s'agit du code source du système annoté d'indications reliant ce code aux blocs du modèle précédent. Il définit les interfaces de chaque bloc et les mécanismes d'échanges de stimuli (appels, messages, rendez-vous, etc.). Le modèle de test définit la spécification de chaque test et précise comment les résul-
8 Intégration des Spécifiq1.tions
tats des tests doivent être analysés. Les tests sont répartis en tests d'unités (les fonctionna- lités d'un bloc sont analysées séparément de son environnement), tests d'intégration (un bloc est ajouté à un ensemble de blocs), tests système (l'ensemble des blocs est confronté au système de support (système d'exploitation, système de gestion de bases de données, etc.).
L'interprétation des spécifications OOSE s'appuye sur deux principes: la correspondance (traceability) et les tests. Le principe de correspondance impose aux différents modèles que l'on puisse identifier facilement (voire automatiquement) les objets-usages de l'analyse des besoins avec les objets des modèles suivants qui servent à les définir et à les implanter dans le système, jusqu'aux composants du code source. Cette correspondance doit être bi-directionnelle et doit permettre de remonter les résultats des tests jusqu'au modèle initial, afin d'identifier l'origine d'une erreur ou d'une inadéquation à tous les niveaux d'abstraction en parallèle (plutôt qu'uni- quement dans le code du système implanté). Dans cette approche de transformation (plus ou moins) continue d'un modèle dans l'autre, chaque étape donne une interprétation des spécifica- tions de la précédente, jusqu'à l'environnement de tests qui donne l'interprétation finale du sys- tème. Ce procédé général à l'avantage d'être complètement explicite pour les concepteurs: il n'y a en principe pas de code généré automatiquement à partir de spécifications, mais une assistance de l'environnement à produire le système aux différents niveaux. L'interprétation de spécifica- tions est ainsi dans les mains du développeur et ne peut pas toujours être univoque. Le très grand degré de liberté qui existe pour implanter un diagramme d'interaction dans un bloc est une source possible de malentendu, que les tests doivent permettre de lever, si le principe de correspondance a été bien respecté. Cette approche semi-formelle est un exemple où l'interprétation des spécifi- cations joue un rôle tout au long de la méthode et où le formalisme sous-jacent est donné par le ou les langages qui permettent l'implantation du système.
3.4 ExSpect [van Hee 94]
ExSpect est une méthode formelle de conception de systèmes d'information développée à l'Uni- versité d'Eindhoven. C'est également le nom d'un outil supportant cette approche développé dès 1989, puis utilisé dans le cadre du projet ESPRIT PROOFS par des fabricants de logiciels euro- péens. ExSpect propose un modèle de spécifications en deux parties:
• un modèle d'objets (ou statique) pour définir l'espace des états d'un système, en utilisant les notions de simplexe (objets de types atomiques), de complexes (objets structurés cons- truits par aggrégation), des relations entre simplexes munies de contraintes (fonctionnelle, de totalité, surjective, injective);
• un modèle d'acteurs (ou dynamique) pour définir les lois de transitions entre ces états, en utilisant la notion de processeur, de réseau de processeurs ( = un acteur) et de jetons: un jeton a une valeur complexe, une empreinte temporelle et son passage d'un processeur à l'autre dans le réseau est défini par des relations de transitions. Les processeurs sont soit atomiques soit contiennent un réseau de processeurs.
L'intégration des spécifications des deux modèles se fait par les fonctions déclenchées lors des transitions du modèle d'acteurs qui opérent sur des valeurs décrites dans le modèle d'objet. Ces
fonctions sont spécifiées dans un sous-ensemble du langage de spécification formelle Z [Spivey 87]. Les deux modèles sont exprimés à l'aide d'un langage graphique.
L'interprétation des spécifications est construite sur deux formalismes: le modèle entité-as- sociation binaire (très proche du modèle Data Semantics [Abrial 74]) et sur une version propre à ExSpect des réseaux de Petri colorés et temporalisés [Jensen 82]. Les spécifications peuvent être analysées en étudiant leur interprétation de plusieurs manières:
• analyse des invariants des réseaux de Petri (invariants de place et de transition) qui permet de connaître quelles propriétés vérifient les objets-jetons qui sont dans tel ou tel état;
• analyse des graphes d'occurrences qui est une adaptation à ExSpect des techniques bien connues sur les réseaux de Petri d'étude des graphes de couvertures, elle renseigne sur l'at- teignabilité de certains états du système à partir d'un ou plusieurs états initiaux (voir para- graphe 9.1page66);
• analyse temporelle en complétant les graphes d'occurences qui renseigne sur les temps de réponse et les débits prévisibles du système.
Une étude des propriétés du système par analyse statistique des traces d'exécution (dans un environnement de simulation) est également proposée.
4 Présentation du plan du mémoire
Pour illustrer nos propositions concernant les spécifications d'un S.I., nous avons choisi un en- semble de modèles (F2+MTG) développés et expérimentés depuis plusieurs années dans l'équipe de recherche en systèmes d'information de l'Université de Genève [Léonard 88], [Léonard 91].
Le chapitre II est consacré aux définitions de ces modèles et à l'interprétation qu'on peut en donner.
Partant de ces définitions, nous montrons dans le chapitre ID comment effectuer l'intégration descriptive de ces spécifications, c'est-à-dire quelle exploitation on peut faire du support unifor- me de représentation des spécifications (dictionnaire de spécification) et de leur interprétation.
Le chapitre IV présente l'approche retenue dans notre environnement d'outils pour effectuer l'intégration effective des spécifications dans un prototype opérationnel du système spécifié. Cet- te approche tente de mettre en œuvre une architecture évolutive du système généré.
La conclusion (V) esquisse quelques prolongements possibles à ces travaux.
0
-
II Spécifications statiques et dynamiques
Nous présentons ici un modèle de spécifications de système d'information. Ces spécifications peuvent être classées selon un grand nombre de critères différents. L'approche la plus répandue dans les méthodes de conception de SI [Olle 90], regroupe ces spécifications par niveaux d'abs- tractions (conceptuels, logiques, physiques) et sépare fréquemment, à l'intérieur de chacun des ni- veaux, les spécifications statiques des spécifications dynamiques. Les spécifications statiques décrivent la structure de l'état du système à un instant donné (photographie), les spécifications dy- namiques définissent les mécanismes et les conditions de passage d'une photographie à l'autre.
L'approche orientée-objet dans les bases de données [Atkinson 89], [Beech 87], [Lécluse 88]
tend à rassembler ces deux classes de spécifications en un seul modèle. Toutefois, les aspects sta- tiques et dynamiques d'un objet sont exprimés par des concepts bien distincts: l'état d'un objet est donné par les valeurs que prennent à un instant donné ses variables d'instance (ses attributs), les conditions de passage d'un état à l'autre sont exprimées par les méthodes, soit explicitées sous forme de pré- et post-conditions soit implicitement dans le code de leurs algorithmes. Dans cette étude, la définition complète d'un objet est obtenue en intégrant la spécification du schéma de sa classe et celle de son cycle de vie.
Dans ce chapitre, les différents concepts des modèles décrits seront illustrés à l'aide d'un exemple de système d'information dont l'énoncé a été proposé par [Olle 88b]. Il s'agit du problè- me de l'organisation d'une conférence, des articles soumis à un comité de programme, de la sé- lection de ces papiers, de la planification de la conférence en sessions, de la gestion des participants, etc.
5 Le Modèle statique (F2)
Le modèle F2 est un modèle sémantique de données que l'on peut voir aussi bien comme une ex- tension du modèle Entité-Association, dans la ligne du modèle ECRINS [Junet 90], que comme une extension d'un modèle fonctionnel ou encore comme un sous-ensemble du modèle IFO [Abi- teboul 87]. Enfin, le modèle F2 appartient à la famille des modèles de bases de données orientées objet [Beech 87].
12 Intégration des Spécifications
Après une brève présentation informelle, les quatre notions principales du modèle (classe, at- tribut, sous-classe et contexte) sont définies ainsi que les contraintes qu'elles font porter sur les collections d'objets gérées par le système.
5.1 Présentation des concepts
Objets
La mémorisation dans le système d'un fait ou d'une information sera obtenue par la présence d'un objet plus ou moins structuré. La première propriété d'un objet est d'être identifiable (c'est-à-dire distinguable des autres). On souhaite pouvoir distinguer deux objets si on sait distinguer les infor- mations (les faits) qu'ils représentent.
Ailleurs information
figure 1 identification d'un objet
Pour interpréter l'information que représente un objet, on lui associe une valeur. Celle-ci est un ensemble de symboles intelligibles (caractères, pixels graphiques, signaux audio ou vidéo, etc ... ) qui permettent au besoin de "lire" l'information enfermée dans l'objet.
Classes et Attributs
Ailleurs information
fi~ure 2 interprétation d'un objet
La classe d'un objet définit à la fois son type et un ensemble d'objets de ce type.
Certaines classes sont atomiques, c'est-à-dire qu'elles sont définies sans s'appuyer sur la dé- finition d'une autre classe. La classe des nombres entiers positifs ou la classe des chaînes de ca- ractères d'au plus 20 caractères en sont des exemples. Les objets de ces classes ont une caractéristique particulière: leur identifiant est leur valeur elle-même. Par exemple le nombre 3.141592 de la classe des nombres flottants n'est identifiable que par la valeur "3.141592".
Les classes composites sont caractérisées par un ensemble d'attributs. Un attribut est une fonction qui fait correspondre à chaque objet de la classe un ensemble d'objets d'une autre classe (éventuellement de la même). La valeur d'un objet composite est un tuple d'identificateurs des objets obtenus par application de tous ses attributs. Contrairement aux classes atomiques, les ob- jets des classes composites sont identifiables indépendamment de leur valeur. Cette propriété (ap- pelée l' OID de l'objet) permet d'y faire référence, de les nommer sans utiliser leur valeur qu'elle soit structurée ou non. Celle-ci peut donc changer sans que les références ne soient invalidées.
classe DateLégale : Date(1.jan.1989 .. 31.déc.2020); nom
classe ChaîneCourte : Caractères • 20; Personne prènom ChaîneCourte )
classe Personne(nom : ChaîneCourte, ... ~ .. ..
prénom : ChaîneCourte);
classe Conférence(acronyme : ChaîneCourte, délaiPapiers:DateLégale);
classe Papier(titre: ChaîneCourte, auteurs : Personne*(1 .. 5), soumisA : Conférence, reluPar : Personne*(3 .. 6) );
sousclasse PapierAccepté de Papier (présentéDans : Session);
classe Session (titre : ChaineCourte,
auCoursDe : Conférence); prés,entéDans Session figure 3 un schéma de quelques classes et sa déclaration
Date légale
... ... .;I
La plupart des classes composites sont définies en extension. Ceci signifie que l'ensemble des objets de la classe est mémorisé et géré par le système. Ce n'est pas le cas la plupart du temps pour les classes d'objets atomiques (on n'espère pas stocker tous les nombres entiers ... ). Toutefois, la propriété extension est indépendante du caractère atomique ou non d'une classe.
Dans l'exemple de la figure 3, les classes DateLégale et ChaîneCourte sont des classes atomiques.
La classe Conférence est définie par un attribut (acronyme) vers les chaînes courtes et par une date légale (délaiPapiers). Un objet de la classe Personne est défini par un nom et un prénom. Enfin un papier est défini par un titre, et par un ensemble de 1 à 5 auteurs.
Sous-classes et héritage
Une classe peut-être déclarée sous-classe d'une autre. C'est le cas de la classe PapierAccepté de la figure 3. On crée ainsi un lien "is_a" (spécialisation) entre les objets de la sous-classe et ceux de la super-classe. Chaque sous-classe est définie sur les mêmes attributs que sa super-classe (on dit qu'elle en hérite ses attributs) et elle peut posséder des attributs supplémentaires pour ses ob- jets. Ceux-ci peuvent donc posséder plus de caractéristiques que les objets de la super-classe. Un tel lien a une conséquence forte sur l'ensemble des objets d'une sous-classe: ils sont tous égale- ment des objets de la super-classe.
Dans l'exemple de la figure 4, la classe Session possède 2 sous-classes. Tout objet de la classe SessionScientifique est aussi un objet de la classe Session. Un tel objet possède trois attributs: un titre et une conférence de déroulement hérités de la classe Session et un attribut propre aux ses- sions scientifiques.
Les sessions qui appartiennent simultanément aux classes SessionExpos et TableRonde pos- sèdent 4 attributs (2 attributs hérités de Session et 1 attribut propre à chaque sous-classe). Ils for- ment une classe implicite d'objets héritant de deux super-classes. En d'autre termes l'appartenance à deux sous-classes d'une même classe n'est pas nécessairement exclusive.
14 Intégration des Spécifications
classe Session (titre : ChaineCourte, auCoursDe : Conférence);
tffreî
Conférence
sousclasse Dîner de Session (animateurs : Personne *(0 .. 3} );
sousclasse SessionScientifique de Session (président : Personne);
sousclasse TableRonde de SessionScientifique (intervenants: Personne •(2 .. 7) );
sousclasse SessionExpos de SessionScientifique;
présentéDans
Session
SessionScientifique
/~,
figure 4 un exemple d 'arborescence de sous-classes Contextes 1
intervenants
Un contexte est un mécanisme d' abstraction permettant de construire un certain nombre de vues (relations calculées) à partir des extensions de classes [Falquet 89], [Falquet 90). Le principal avantage d'un contexte est de permettre d'extraire du schéma logique un chemin d'accès aux ob- jets dont la sémantique est bien définie. Cette propriété devient cruciale pour l'utilisateur d'un schéma de classes lorsque ce dernier devient complexe, en particulier lorsqu'il contient un ou plu- sieurs cycles.
Un contexte est défini par un graphe dont les nœuds sont des classes d'une base et les arcs sont certains des attributs entre ces classes. Dans l'exemple suivant, les nœuds des contextes sont définis à partir de l'exemple de la figure 3.
Le contexte Soumission est formé de trois nœuds reliés par les attributs auteurs et envoyéA. Il fournit une sémantique des associations d'objets existantes à travers ces attributs. Cette sémanti- que est définie par la fonction de connexion du contexte: la connexion Soumission [Aut Conf] pro- duit un ensemble de paires (a, c) telles que a etc sont reliés par tous les chemins du contexte qui vont du nœud Aut au nœud Conf Dans notre cas, a est une personne qui a écrit un papier soumis à la conférence c. Le résultat du calcul de cette connexion est ainsi une relation calculée sur Aut et Conf dont les valeurs sont les identificateurs des classes Personne et Conférence.
La connexion Soumission[ Conf] produit elle une relation unaire qui contient tous les identi- ficateurs de la classe Conférence (y compris les conférences pour lesquelles il n'a été soumis en- core aucun papier), puisque l'ensemble des chemins est vide dans ce cas.
Dans le contexte Programme, la connexion Programme[Pap Conf] fournit une relation (p, c) telle que p a été retenu pour être présenté dans une session de la conférence c.
l . Les contextes ont été introduits par G. Falquec en .1988 sous le tenne "contextes sémanliques".
Après avoir ulilisé le terme de "VAGues" (pour vues associatives génériques), il les a finalement renommés "modules" dans un article récent [Falquet 92). Nous avons conservé sa terminologie d'origine.
contexte S:l..ni;à:;n nœuds AU:: Pas:rre
O:rt:Orêa'œ ~=~
arcs AU:auteurs~
~soumisAcat,
contexte Plo;}amre nœuds J..ga:Pas:rre
~:~A:œpé
Ses:Se!m'l Aés: Pas:rre C.crt O:rtérerr.e arcs J..g3reluPar~
~présentéDansSes SesauCoursDeO:xt SesprésidentPrés,
~~~~- a.am s::ulÉ'\---~~~--...
Pap:Papier }---{ Conf:Conférence
~--- tfi.Ry pÉ'SB'ÉDn;
..----
Juge: Personne Ses: Session
~ Conf:Conférence
figure 5 exemples de contextes Autre exemple:
On considère le schéma précédent et les collections d'objets de la figure 6.
Papier
~
Conférence
SIGMOD
figure 6 quelques objets reliés par les attributs auteurs et envoyéA
Les deux tables suivantes donnent deux exemples de connexions calculées sur cette base.
~c.ai]=
Pap P#101 P#1œ P#110 P#104
Conf
"1.0091
"1.0091 Bœ91
sa...œ
Sa.rrmJ'(O:rihl,I=
Conf Aut
"1.0091
"1.0091
"1.0091 Bœ91
Piene Paul Aœrt AgWe
16 Intégration des Spécifications
Un contexte définit un ensemble de vues possibles sur les extensions des classes, la sémanti- que partagée par toutes ces vues étant déterminée par le graphe du contexte. Chaque connexion possible dans un contexte correspond à une vue. Cette notion de contexte va nous servir d'inter- face entre les spécifications structurelles (statiques) et les spécifications dynamiques: l'impact des événements sur le système est défini en termes de processus appliqués aux objets associés par un contexte. Ainsi les contextes définissent également une unité de traitement et les opérations ou processus qui sont la conséquence d'un événement sont rapportées à un contexte plutôt qu'à une seule classe comme c'est le cas traditionnellement dans les langages et les SGBD orientés objet [Meyer 88], [Stroustrup 86], [Lécluse 88].
5.2 Structure des objets
Nous allons donner maintenant une définition formelle du modèle statique et des primitives qui s'appliquent aux collections d'objets du modèle et aux connexions des contextes.
On considère deux ensembles dénombrables:
(1) un ensemble Noms= {ni. n2, ••• } de symboles distincts, (2) un ensemble OID
= {
o1, o2, .•• } d'identificateurs d'objets,et l'ensemble des valeurs VAL= OID u {?}(?est appelée la valeur inconnue ou obscure1).
5.2.1 Schéma d'une base d'objets Définition 1 Schéma
Une classe est un élément Ce Noms.
Un attribut est un triplet A= <n, Co, Ct> où n e Noms, Co et Ct sont des classes appelées respectivement classe d'origine deA (ou simplement classe de A) et classe terminale de A.
Uu lien ISA est une paire i
=
<Csub> Csupe? où c sub et Csuper sont des daSSP.SUn schéma de base d'objets est un triplet S =<Cl, Attr, Isa> où Cl est un ensemble de classes, Attr un ensemble d'attributs, Isa un ensemble de liens ISA.
Remarques:
• à propos d'un lien ISA, on dit également que Csub est une sous-classe directe de C super et que C super est une super classe directe de Csub· Lorsqu'il existe un chemin formé de plu- sieurs liens ISA allant de la classe C1 à la classe C2, on dit que C1 est une sous-classe (in- directe) de C2 et que C2 est une super-classe (indirecte) de C1• On note Super(C) l'ensemble des superclasses et Sub(C) l'ensemble des super-classes (resp. des sous-classes) de C. Par convention, une classe C appartient simultanément à Super(C) et Sub(C). (Super(C) n Sub(C)
= {
C} ).1 . Le terme incormue est associé au symbole syntaxique ? indépendamment de toute sémantique tradirionneUement attachée aux valeurs nulles, indéterminées, impossibles, incomplètes, etc. Le terme obscure vient de [Léonard 88] où une entité obscure est une entité dont l'un au moins des attributs prend une valeur inconnue.
• il existe une correspondance immédiate entre un schéma Set un graphe G(S) =<N, Arc1,
Arc2> où les nœuds N sont les classes de S, et où il existe 2 types d'arcs (orientés): Arc1
pour l'ensemble des attributs etArc2pour l'ensemble des liens ISA. Ceci permet entre autre de donner une représentation graphique d'un schéma et d'exprimer en termes de graphes certaines contraintes et algorithmes du modèle; une étude détaillée de la correspondance entre un modèle sémantique et un graphe se trouve dans [Junet 90].
• enfin on ne considère que les schémas pour lesquels le graphe (des liens ISA seulement) est un ensemble d'arbres disjoints. Ceci implique qu'une classe ne peut posséder qu'une seule super-classe directe, et qu'il n'existe pas une classe racine unique.
5.2.2 Instance du schéma d'une base
Définition 2 Instance d'un schéma de classes
Une instance I d'un schéma <Cl, Attr, Isa> est une paire (X, a) de fonctions telles que:
a) V CE Cl, x(C) est un sous-ensemble de OID,
b) V A E Attr, a(A = <n, Co, Ct>) est une fonction totale de X(Co) dans 2VAL u {?}.
Remarques:
• lorsque I est sous-entendue, on abrège "un objet ode X( C)" par "un objet ode C', de même, on abrège (a(A))(o) par A(o),
• "2VAL,, est l'ensemble des parties de VAL (y compris 0),
• soient C une classe, A un attribut de C, et o un objet de C, alors A(o) peut prendre toutes les formes suivantes: 0, { vi}, { Vi. v2, ? } , ? , {?}, ... où v1> v2 E VAL,
• à la différence de plusieurs modèles orientés objets dans lesquels on dit qu'un objet est une instance d'une classe, une instance est définie ici sur un schéma de classes plutôt que sur une seule classe, et pour chaque classe de ce schéma elle comprend un ensemble d'objets.
5.2.3 Collections d'objets
Parmi toutes les instances possibles d'un schéma, seules celles qui vérifient certaines propriétés nous intéressent. On dira de ces instances qu'elles sont cohérentes.
Définition 3 Intégrité référentielle
Soit I une instance d'un schéma <Cl, Attr, Isa>, I satisfait l'intégrité référentielle lorsque pour tout attribut A= <n, Co, Ct> deAttr et pour tout o E X(Co),A (o) ç X(Ct) ouA(o) = ?.
En d'autres termes, A applique chaque objet ode Co soit sur la valeur inconnue, soit sur un ensemble d'objets de Ct.
Définition 4 ISA-consistance
Soit I une instance d'un schéma <Cl, Attr, Isa>, I est ISA-consistante lorsque tout liens= <Csub>
Csupe,> de Isa satisfait: X( C,ub) ç X( Csuper).
Ainsi, tous les objets d'une sous-classe appartiennent à sa super-classe.
18 Intégration des Spécifications
Définition 5 ISA-complétude
Soit I une instance d'un schéma <Cl, Attr, Isa>, I est ISA-complète lorsque V C, C'e Cl, X(C) n X(C)
*
0 => 3 C" E Cl telle que C" e Super(C) n Super(C).Ainsi, lorsqu'un objet appartient à deux classes, celles-ci possèdent une super-classe en com- mun.
Définition 6 Contrainte de cardinalité
Soitiune instance d'un schéma <Cl,Attr, Isa >et soitA= <n, Co, Ct> un attribut deAttr, I satisfait la contrainte de cardinalité cc(A) = <cardMin, cardMax> lorsque V o E X(Co),A(o) =?ou bien cardMin s; card(A (o)) s; cardMax.
En d'autres termes, lorsque la valeur de A(o) n'est pas inconnue, c'est un ensemble dont la taille est bornée par les valeurs [cardMin, cardMax].
Définition 7 Instance cohérente
Soit I une instance d'un schéma de classes, I est cohérente lorsque I satisfait l'intégrité référen- tielle, est ISA-consistante, ISA-complète et satisfait toutes les contraintes de cardinalités cc(A).
L'ensemble des objets qui forment une base à un moment donné doit définir une instance co- hérente du schéma de cette base. Pour une classe C, l'ensemble des objets qui correspondent à une instance cohérente s'appelle la collection des objets de C. Les opérations possibles sur les collec- tions d'objets devront renforcer les contraintes de façon à garantir que l'état du système évolue en respectant la cohérence ainsi définie. Elles seront construites à partir des primitives définies au pa- ragraphe 5.3.
5.2.4 Spécification du schéma d'une base
Pour enregistrer et manipuler la définition d'un schéma de classes, on va utiliser le modèle F2. On définit un schéma de clnsscs particulier (parfois appelé mF:t~-sc:héma), et on considère une instan- ce cohérente de ce schéma, qu'on appelle une spécification du modèle.
On se donne le schéma suivant: Sbase = <Cl, Attr, Isa > où
• Cl = {Classe, Attribut, Sous-Classe, Identificateur, NbreEntier}
• Attr = { < nom, Classe, Identificateur >,
< nom, Attribut, Identificateur>,
< origine, Attribut, Classe >,
< terminale, Attribut, Classe >,
< cardMin, Attribut, NbreEntier >,
< cardMax, Attribut, NbreEntier >,
< superClasse, Sous-Classe, Classe > }
• Isa = { <Sous-Classe, Classe> }
La figure 7 donne le graphe de ce schéma
~ cardMax E. r'
( Attribut , cardMin • \. Nbre ntie./
origine { ( Identificateur)
nom---• ~,~~~~-
Classe
figure 7 graphe du schéma Sbase
Définition 8 Spécification d'un schéma de classes Soit Sbase le schéma définit ci-dessus,
une spécification de schéma est une instance de Sbaseo
une spécification de schéma bien formée est une instance cohérente de Sbase·
5.3 Comportement générique des objets: primitives
Tous les changements d'états élémentaires qui peuvent intervenir sur un objet d'une base se font par application de méthodes primitives attachées à chaque classe. Pour chaque classe C d'un sché- ma S, il existe trois primitives C. Create, C.Delete, C.Enter et pour chaque attribut A de Cil existe deux primitives A.Assign et A.Eva!.
5.3.1 Create
C.CreateO ~ OID
Cette primitive retourne un nouvel objet de la classe C. Les collections de toutes les super-classes de C ainsi que celle de C sont augmentées de ce nouvel objet, tous les attributs (hérités ou non) de C prennent la valeur '?' sur cet objet. Lorsque cette primitive est appliquée à une instance co- hérente, elle produit encore une instance cohérente. Sa sémantique est définie de la façon suivante:
Définition 9 Sémantique de C.Create()
Soit I =(X, a) une instance du schéma S= <Cl,Attr, Isa>, !'= (X', a ') l'instance obtenue par ap- plication de la primitive o := C. Create() à I est définie comme suit:
• o E OID et V C' E Cl, o
e:
X(C'), (o est un nouvel identificateur encore inemployé)• V Csup e Super( C), X'( C,.P) = X( Csup) u { o} et VA un attribut de C,"P' a'(A)
=
a(A) u { (o, ?) },• V C' E (Cl- Super(C)), X'(C')
=
X(C') et VA un attribut de C, a'(A) =a(A).Si I est cohérente, on constate facilement que
r
l'est aussi:r
reste Isa-consistante puisque o ap- partient à toutes les super-classes de C, pour la même raison elle reste Isa-complète, elle respecte20 futégration des Spécifications
toujours l'intégrité référentielle puisque les nouvelles valeurs ajoutées aux attributs de C ne sont que des valeurs inconnues et pour la même raison les contraintes de cardinalités restent valides.
5.3.2 Enter C.Enter(OID) ~ OJD
Cette primitive ne s'applique qu'aux objets qui appartiennent à au moins une des super-classes de C. Son effet est d'intégrer un objet o dans la collection de C i.e. de spécialiser un objet. Il est éga- lement intégré à toutes les collections des super-classes de C (auxquelles il n'appartenait pas en- core). De cette façon, l'instance obtenue reste ISA-consistante.
Définition 10 Sémantique de C.Enter(o)
Soit I =(X, ex) une instance du schéma S,
r
=(X', ex') l'instance obtenue par application de la primitive o := C.Enter(o) à I est définie comme suit:• soit ModC
= {
C' (: Super(C) 1 oe:
X(C') },• vcmod E ModC, x'(Cl1Wd)
=
xCCmod) u {o} et VA un attribut de Cmod, ex'(A) = ex(A) u { (o, ?) },• V C' E Cl - ModC, X'( C') =X( C') et VA un attribut de C, ex'(A) =ex(A).
Si I est cohérente, I' l'est aussi: I' reste ISA-consistante puisque les inclusions des collections de sous-classes sont préservées et l'intégrité référentielle est conservée puisqu'on n'ajoute que des valeurs inconnues aux attributs de C.
5.3.3
Delete C.Delete( OID)Cette primitive vise à retirer un objet ode la collection de C. Il est clair que son application risque de violer la contrainte d'intégrité référentielle: il ne doit plus y avoir d'objet qui référence o dans C. Si on modifie les valeurs que prennent les attributs rétërençant o, ce sont les contraintes de cardinalités (minimum en particulier) qui risquent d'être violées. Dans ce cas c'est l'objet qui ré- férence o qui doit quitter sa collection 1, déclenchant éventuellement une cascade de suppressions.
Enfin si l'objet appartient aussi à des sous-classes de C, la base risque de n'être plus ISA-consis- tante, à moins qu'on ne propage la cascade de suppressions dans ces sous-classes également.
L'instance conséquente à l'application de la primitive C.Delete(o) est donc défini de la façon sui- vante:
Définition 11 Sémantique de C.Delete(o)
Soit I =(X, ex) une instance du schéma S, I' =(X', ex') l'instance obtenue par application de la pri- mivite C.Delete(o) à I est définie comme suit:
1. soit 10 l'instance (X0, <Xo) suivante:
a) V C;.!E Sub(C), Xo(C;nf)
=
X(C;.f)-{o},1. Il serait également possible d' assigner la valeur? à l'attribut A de tout objet qui référence o.
Cette solution n'a pas été retenue ici car c'est une sémantique moins primitive ( A.Assign(?) &
C.Delete(o)) que celle qui est choisie.
b) V C' E Cl- Sub(C), Xo(C')
=
X(C'),c) VA E Attr avec Co(A) E Sub(C), <Xo(A) = a:(A)- {(o, _)}.
2. /'est la plus grande instance satisfaisant l'intégrité référentielle et les contraintes de cardinalités telle que:
a)
x'ç;;xo.
b) Vo', VAEAttr,(CXo(A))(o');t:?:::> (a:'(A))(o');t:?.
L'instance/' est bien définie i.e pour une 1 donnée, elle existe et elle est unique.
Preuve (esquisse):
Pour détruire l'objet o, on définit l'ensemble de propagation de ode la façon suivante:
Prop(o) est le plus petit ensemble tel que:
• o E Prop(o),
• V o' E Xo· VA == <n, Co, Ct> un attribut de o' t.q. Ct E Sub(C), IA(o') \ Prop(o)I < cardMin(A) => o ' E Prop(o).
On obtient
r
en retirant à Xo tous les objets de Prop(o) de leur collection (et de celles de leur sous-classes) et en retirant à toutes les valeurs d'attributs de CXo les objets de Prop(o). Ainsi tous les attributs appliqués à des objets non détruits dont la valeur contenait un objet détruit conservent la cardinalité nécessaire. De même, aucune de ces valeurs d'attributs ne référence plus les objets détruits. Ainsi /'satisfait les contraintes souhaitées.Remarques:
l'instance /0 est déja ISA-consistante puisque les inclusions de collections de sous-classes de C sont préservées. /'l'est également puisque les inclusions des collections d'objets de Prop(o) avec leur sous-collections sont préservées,
si C est une sous-classe, l'application de la primitive C.Delete(o) fait sortir ode la collection de C mais il reste défini dans les super-classes de C (opération inverse de C.Enter(o)),
Si C n'a pas de super-classe (C est une racine d'un arbre de spécialisation), C.Delete(o) fait définitivement disparaitre ode la base (opération inverse de o :== C.Create()).
5.3.4 Assign
A.Assign(OID x (2VALu {?})) ~ 0/D
L'application de la primitive o :=A.Assign(o, V) permet de définir la valeur que prend l'attribut A de l'objet o. V est un ensemble d'objets de la classe terminale de A ou la valeur inconnue. Cette primitive est applicable à o si la classe d'origine de A contient o et si cardMin(A) :::;; IVl :::;; card- Max(A).
