Thesis
Reference
Dynamic evolution of object behavior and object cooperation
ARAPIS, Constantin
Abstract
A multitude of data models has been proposed for specifying static aspects (data) and operational aspects (operations on data) of the real world. However, it is often desirable to describe additional aspects of the real world. For example dynamic models have been developed for the description of temporal aspects. The motivation for this thesis was to design a dynamic model reflecting the philosophy of the object-oriented approach. In particular the temporal aspects emphasized by the proposed model are the description of the temporal evolution of object behaviour and of the temporal properties and rules concerning the cooperation of a collection of objects. We have chosen the language of propositional temporal logic as the underlying formalism of our model. The satisfiability algorithm of temporal logic has been the basis for providing a rigorous and automatic procedure for the verification of user provided specifications.
ARAPIS, Constantin. Dynamic evolution of object behavior and object cooperation . Thèse de doctorat : Univ. Genève, 1992, no. Sc. 2529
DOI : 10.13097/archive-ouverte/unige:155425
Available at:
http://archive-ouverte.unige.ch/unige:155425
Disclaimer: layout of this document may differ from the published version.
1 / 1
0
("') :ri- 0 0 0
L ~ ;:; -3 ~eo eo
~ ::i- 0 <
~, Cf,- - 2 ~ ... :r, 0 t'!".l t'!".l
~ ~ - > - -
L r"'J r"'J ...
L ~ ~ -· , ""'3
~ :::; -- -
1-( > - r"'J
C· -- r"'J eo
-s -
~· -- 2 0
~ t'!".l -=
'-' ... - c 0 = <
:r, "' :or:: -<
~ > 0
::i:: L: > t'!".l <
1-( ~ I... -3 s: ::0
~ ~ -- - > 0 ""'3 -
~ ~ 2 ""'3
~ c
1-( > 0
'-' ::r: 0 2 ---.
0 2 - 2
:0 ~. 0 0
'-- :or: --
~ -3 ~ -
'.J) ~ ...
,.:t, ._ ~ -3 ::r: ~ L ~, .... ~
·..c '..C t~
Universite de Geneve Faculte des sciences Departement d'informatique Prof. D. Tsichritzis et C. Pellegrini
Geneve
DYNAMIC EVOLUTION OF OBJECT BEHAVIOR
AND
OBJECT COOPERATION
THESE
presentee
a
la Faculte des Sciences de l'Universite de Geneve pour obtenir le grade de Docteur es Sciences mention Informatiquepar Constantin ARAPIS
de Piree, Grece
These No 2529
1992
La Faculte des Sciences, sur /,e preavis des Messieurs C. PELLEGRINI, professeur ordinaire et directeur de these (Departement d'info;matique), D. TSICHRITZIS, professeur ordinaire et codirecteur de these (Centre Universitaire d'InformaUque), 0. NIERSTRASZ, maUre d'enseignement et de recherche (Centre Universitaire d'Informatique) et Madame B. PERNICI, professeur (Universite d'Udine), autorise l'impression de la presente these, sans exprimer d'opinion sur les propositions qui y sont enoncees.
These No 2529 Geneve, l.e 19 fevrier 1992
Le Doyen, Pierre BURI
©Constantin Arapis 1992. Tous droits reserves
CONTENTS
ACKNOWLEDGEMENTS . . . vii
REMERCIEMENTS . . . . viii
ABSTRACT .. . ..
RESUME SUCCINT RESUME ... .
I Motivation II Objets et messages
III RO/,es et de contextes pour objets elementaires N Roles et contextes pour objets complexes
v
verification des specifications VI Contributions1 INTRODUCTION 1.1 Motivation 1.2 Overview . 1.3 Contributions
2 MODELLING THE REAL WORLD . . . . 2.1 Design and development of database applications 2.2 Static data models
2.3 Integrated models
2.4 Object-oriented data models 2.4.1 Classes and types 2.4.2 Object identity . .
iii
ix ix
x x xii xii xv xix xx
1 1 3 4
5 5 7 10 12 13 14
iv CONTENTS 2.4.3 Encapsulation . . . 15 2.4.4 Inheritance, late binding and overriding 15
2.4.5 Object-oriented development 17
2.5 Modelling dynamic aspects . . . . 18
3 INFORMAL PRESENTATION OF TLOOM 21
3.1 Fundamental notions ofTLOOM 21
3.1.1 Objects and messages . . . 21
3.1.2 Contexts and roles for elementary objects 22 3.1.3 Contexts and roles for composite objects . 26 3.1.4 Public and component constraints . . . . 29 3.2 Contrasting TLOOM and basic notions of object-oriented models 31
3.2.1 Classes . . . 31
3.2.2 Object identity . 32
3.2.3 Inheritance . . 32
3.2.4 Encapsulation . 34
3.2.5 Late binding and overriding 35
3.3 The choice of a formalism . . . 35
4 .ELEMENTARYOBJECTS . . 38
4.1 Roles for elementary objects 38
4.1.1 Abstract states . . 39
4.1.2 Public constraints . 39
4.1.3 Ingoing and outgoing messages 42
4.2 Contexts for elementary objects 43
4.2.1 Role playing . . . 43
4.2.2 The semantics of the notions of context and role 47 4.3 More on constraints associated with contexts . . . 49 4.3.1 Examples of constraints associated with contexts . 49 4.3.2 Constraints between messages and role playing 49 4.3.3 Constraints between messages of distinct roles 51 4.4 Summary of shorthand expressions . . . 52
CONTENTS v
5 VERIFICATION OF ELEMENTARY OBJECT SPECIFICATIONS 54 5.1 The basic principles of the satisfiability algorithm 54
5.1.1 Looking into the future 55
5.1.2 Looking into the past . 60
5.2 The satisfiability algorithm . 64
5.2.1 Decomposition procedure 64
5.2.2 The graph construction procedure 67
5.2.3 Elimination procedure . . . 69 5.2.4 Infinite paths . . . 69 5.3 Verification of elementary object specifications 70 5.3.1 Starting and stopping roles . . . 70 5.3.2 Creating and deleting instances of contexts 71 5.3.3 Universalization of constraints associated with roles . 71
5.4 Monitoring elementary object specifications 72
5.4.1 The monitoring process . . 73
5.4.2 Monitoring infinite paths . 75
6 COMPOSITE OBJECTS . . . .. . . 77
6.1 Roles and contexts of composite objects 77
6.1.1 Roles for composite objects . . 77
6.1.2 Contexts for composite objects 81
6.2 Further modelling aspects of composite objects 82 6.3 Semantics of roles and contexts for components 87 6.3.1 Adapting the notion ofrole for components 87 6.3.2 Adapting the notion of context for components 88 6.4 Semantics of roles and contexts for composite objects . 89 6.5 Controlling the replacement of"in" and "out" messages 92 6.6 Summary of shorthand expressions . . . 94
6.6.1 Shorthand expressions for components 94
6.6.2 Shorthand expressions for composite objects 96
vi CONTENTS
7 VERIFICATION OF COMPOSITE OBJECT SPECIFICATIONS . . . 97 7 .1 Transformations of component specifications 97 7.1.1 Starting and stopping roles . . . 97
7.1.2 Creating and deleting a component 98
7.1.3 Universalization ofa component's role constraints 98 7.1.4 Universalization ofa component's context constraints 99 7.1.5 Replacing public messages with "in" and "out" messages . 99 7 .2 Transformations of composite object specifications . . . . 102 7 .2.1 Universalization of component constraints of roles . 103 7 .2.2 Universalization of component constraints of contexts .-103 7 .3 The correspondence property . . . . 104 7.4 Monitoring specifications of composite obJects . 105 7 .5 Component instantiations
8 RELATED WORK .... . . .. . ... . .. . . . 8. l A model for synthesizing communicating processes 8.2 Modelling life cycles with Augmented Petri nets 8.3 An approach based on temporal logic
8.4 Rule based specifications . . . . 8.5 Object evolution in object-oriented systems
9 CONCLUSIONS AND FUTURE RESEARCH DffiECTIONS 9.1 Conclusions
9.2 Future research directions
APPENDIX: PROPOSITIONAL TEMPORAL LOGIC . A Temporal operators of PTL
B Syntax of PTL . . C Semantics of PTL
D Some valid temporal formulas
. 111 . 114 . 114 . 116 . 120 . 122 . 125 . 127 . 127 . 128 . 130 . 130 . 131 . 132 . 134 REFERENCES . . . . . 136
ACKNOWLEDGEMENTS
First of all, I would like to thank my thesis advisor, Professor Dennis Tsichritzis, for the guidance, encouragement and confidence I was privileged to have from him during the past few years.
I also thank Professor Christian Pellegrini who has also accepted to become thesis advisor and helped me to arrive at the final stages of my thesis.
I thank Oscar Nierstrasz, Maitre d'Enseignement et de Recherche, and Professor Barbara Pernici for serving on my committee. The many valuable discussions, comments and suggestions they made helped me to considerably improve this work.
I would like also to thank Professor Michel Leonard. Without his encouragement and support it is doubtful whether I would have started my postgraduate studies.
Finally, I thank all my colleges of the "object-oriented" research group and all members of the Centre Universitaire d'Informatique of the University of Geneva for their moral contribution and valuable discussions I had with them during the years of my postgraduate studies.
vii
RE:MERCIEMENTS
Mes remerciements vont tout d'abord au Professeur Dennis Tsichritzis, directeur de cette these, pour la confiance qu'il m'a temoigne, pour ses precieux conseils et pour tous les encouragements qu'il m'a prodigues tout au long de ce travail.
Je remercie egalement le Professeur Christian Pellegrini qui a accepte de co-diriger cette these et qui m'a aide a mener a terme ce travail.
Mes remerciements vont en outre au Docteur Oscar Nierstrasz, Maitre d'Enseignement et de Recherche, et au Professeur Barbara Pernici pour l'honneur qu'ils m'ont fait en acceptant de faire parf:ie du jury ainsi que pour le travail de lecture qu'ils ont effectue et les precieuses critiques et suggestions qu'ils m'ont adressees.
Je tiens aussi a remercier le Professeur Michel Leonard pour son soutien et sa confiance sans lesquels il me serait difficile de commencer des etudes pour une these de doctorat.
J'adresse aussi un grand merci a tous mes collegues du groupe de recherche
"oriente objet" ainsi qu'a tous les autres collegues du Centre Universitaire d'Informatique qui ont contribue a ce travail par leur soutien moral et leurs encouragements.
viii
ABSTRACT
A multitude of data models has been proposed for specifying static aspects (data) and operational aspects (operations on data) of the real world. However, it is often desirable to describe additional aspects of the real world. For example dynamic models have been developed for the description of temporal aspects. The motivation for this thesis was to design a dynamic model reflecting the philosophy of the object-oriented approach. In particular the temporal aspects emphasized by the proposed model are the description of the temporal evolution of object behaviour and of the temporal properties and rules concerning the cooperation of a collection of objects. We have chosen the language of propositional temporal logic as the underlying formalism of our model. The satisfiability algorithm of temporal logic has been the basis for providing a rigorous and automatic procedure for the verification of user provided specifications.
RESUME SUCCINT
Pour la modelisation des aspects statiques (donnees) et operationnels (traitements sur les donnees) du monde reel, une multitude de modeles de donnees ont ete proposes. Cependant, il est souvent souhaitable de modeliser d'autres aspects du monde reel. Par exemple, pour la modelisation des aspects temporels plusieurs modeles dynamiques ont ete proposes. La motivation de cette these a ete la conception d'un modele dynamique qui reflete la philosophie de l'approche orientee objet. Plus precisement, les aspects temporels qui ont fortement influence la conception du modele ont ete la description de !'evolution dynamique du comportement des objets et la specification des regles et proprietes temporelles concernant la cooperation d'un ensemble d'objets. Comme formalisme de base pour le modele propose on a choisi d'utiliser la logique temporelle propositionnelle.
L'algorithme de satisfaction de la logique temporelle nous a permis !'elaboration d'une procedure rigoureuse et automatique pour verifier la coherence des specifications des utilisateurs.
ix
RESUME
I Motivation
La recente proliferation des systemes orientes objet [Care88) (Maie86] [Fish87]
[Bane87] [Lecl88] [Weis89) temoigne de !'influence de l'approche orientee objet dans le domaine de la modelisation des donnees. Cette influence croissante est dile essentiellement au fait que l'approche orientee objet parait etre la plus prometteuse pour integrer l'expressivite des langages de programmation orientes objet et les differents mecanismes d'abstraction des modeles de donnees semantiques [Kim88) [Banc88].
Cependant, pour qu'une telle integration soit reussie plusieurs problemes restetit encore poses [Bloo87]. Ils concement non seulement la conception et
!'implementation des modeles des donnees orientes objet mais aussi des methodologies de conception assistees d'outils divers necessaires au developpement des applications orientes objet [Tsic88] [Tsic89b) [Meye88) [Cox87] [Gibb90a].
En se penchant plus attentivement sur les divers problemes concernant l'approche orientee objet on s'aper~it que la plupart d'entre eux ne soot pas nouveaux. Ils ont ete etudies dans le passe dans le cadre d'approches differentes [Tsic89a}. Bien que cela puisse paraitre- Surprenant c'est la consequence naturelle de !'apparition d'une nouvelle tecbnologie. C'est a dire qu'il est necessaire de reevaluer les notions et Jes concepts existants par rapport awe nouvelles exigences imposees par l'approche orientee objet
La remarque precedente s'applique aussi bien aux differents modeles dynamiques qui ont ete proposesjusqu'a present. Par modele dynamique on entend un ensemble de concepts permettan.t de modeliser les aspects te.mporels d'une application. La majorite des modeles dynamiques existants [Dean81] [Hom85]
[Kung85aJ [Kung85b] [Ober87] [Rich82] [Solv86J [Stud86) [Lipe87J (Sern80) ont ete
con~us afin d'~tre utilises conjointement avec des modeles de donnees semantiques.
En consequence plusieurs notions et caracteristiques inherentes a l'approche orientee objet [Banc88] [Atki89] n'ont pas ete prises en compte.
x
Motivation xi
La motivation pour cette these a ete la conception d'un modele dynamique qui reflete la philosophie de l'approche orientee objet. Notamment, les deux aspects suivants, consideres parmi les plus essentiels pour le developpement des applications orientees objet, ont fortement influence la conception du modele.
• La description de !'evolution temporelle du comportement des objets.
• La specification des regles et proprietes temporelles concernant la cooperation d'un ensemble d'objets, ce qu'on a appele la composition temporelle du comportement des objets.
Notre volonte d'aborder le probleme de la composition temporelle n'a pas ete motive uniquement par le desir d'accroitre la puissance de modelisation du modele.
L'iniportance de la composition temporelle est directement liee aux differentes methodologies encourageant ce qui a ete appele la composition du comportement des objets [Nier91] [DeMe91] [Helm90], qui consiste
a
combiner des objets existants pour construire de nouveaux objets. On considere la composition temporelle comme etant un aspect complementaire de la composition du comportement des objets permettant la specification des proprietes temporelles.Concernant notre objectif, une importante exigence qu'on a voulu satisfaire a ete l'elaboration d'une base fonnelle sur laquelle notre modele serait fonde.
Satisfaire cette exigence nous permettrait de verifier la coherence des differentes notions integrees au modele mais aussi de verifier formellement les specifications des utilisateurs. Parmi un ensemble des formalismes consideres comme candidats, le langage de la logique temporelle propositionnelle nous a paru etre le formalisme le plus souhaitable pour notre but.
La notion du temps dans notre modele est de nature asynchrone. En d'autres termes les unites du temps sont identifiees avec !'occurrence d'evenements, un evenement etant defini par l'echange d'un message entre deux objets. La representation explicite du temps par des valeurs telles que "14:30" pour l'heure et "15/11 /1991" pour les dates, n'a pas ete abordee. Pour eviter des eventuelles ambigui:tes concernant les termes "temporel" et "dynamique", les deux termes sont utilises indifferemment dans ce texte pour qualifier la nature asynchrone d'un concept ou notion.
Dans les sections qui suivent on presentera les notions fondamentales du modele dynamique propose. Ces notions sont: objet, message, role, et contexte. A
!'avant derniere section on presentera tres brievement une procedure de la
xii RESUME verification de la coherence des specifications avant de conclure avec les contributions essentielles de cette these.
II Objets et messages
Les notions d'objet et de message sont definies de maniere semblable
a
la plupart des systemes orientes objet. La notion d'objet est utilise pour representer les differentes entites du monde reel. Chaque objet est associe avec un identificateur unique permettant d'identifier l'objet independamment de son comportement et des valeurs de ses attributs.Les objets communiquent entre eux en envoyant et recevant des messages. Des messages envoyes par un objet (expediteur)
a
un autre objet (recepteur) sont interpretes comme des requetes soit pour accomplir une tache, soit simplement pour envoyer en retour une information. La reaction du recepteura
un message peut se traduire par une modification de son etat interne, par l'envoi d'un certain nombre de messagesa
d'autres objets, ou bien par la combinaison des deux cas precedents. On suppose que l'etat interne d'un objet et la maniere de repondre aux messages envoyes sont completement caches aux autres objets.On distingue entre objets elementaires et objets complexes. La definition de la structure d'un objet complexe fait reference
a
d'autres objets complexes ou objets elementaires. La definition de la structure d'un objet elementaire ne fait referencea
aucun autre objet.Les objets sont des instances de contextes. La definition d'un contexte C comprend un ensemble de roles qu'une instance de C peutjouer. Dans ce qui suit on presentera d'abord la definition de roles et de contextes pour objets elementaires. Par la suite on presentera la definition de roles et de contextes pour objets complexes.
III ROles et de contextes pour objets elementaires
La notion de role nous permet de decrire un aspect particulier du comportement d'un objet pendant une periode donnee. Plus precisement, la definition d'un role pour objets elementaire contient deux types d' information. D'une part, il definit
!'ensemble de messages (appeles messages publics) qui peuvent etre envoyes ou
Roles et de contextes pour objets elementaires xiii re~s par un objet jouant ce role. D'autre part, il definit un ensemble de contraintes temporelles (appelees contraintes publiques) decrivent l'ordre temporel que les differents messages definis pour un rOle doivent observer.
Un exemple de definition de role se trouve
a
la Fig. I. En supposant qu'un objet jouant le role OPERATIONNEL est un avion, il peut recevoir les messages decoller et atterrir Oe signe "f-" indique les messagesa
recevoir, le signe "-/' indique les messagesa
envoyer). Dans notre exemple, role OPERATIONNEL ne definit aucun messagea
envoyer.role OPERATIONNEL { public messages
decollerf-, atterrir f-;
public constraints decoller;
0 (decoller ~ 0 atterrir);
O (atterrir ~ 0 decoller);
Fig. I Definition du role OPERATIONNEL
Les contraintes publiques associees au role OPERATIONNEL sont specifiees dans le langage de la logique temporelle propositionnelle. On suppose une correspondance de un-a-un entre les identificateurs des messages et les propositions atomiques de la logique temporelle. Cette correspondance est interpretee de la maniere suivante: une proposition atomique qui a la valeur de verite vrai a Uil instant donne correspond
a
la reception OUa
l'envoi du message avec le meme identificateur. En identifiant les messages avec les propositions atomiques, les contraintes specifiees pour le role OPERATIONNEL exigent que les messages decoller et atterrir soient re~us alternativement. Le premier message qui est re~u doit etre le message decoller.En fait, un objet peut jouer plus qu'un role pendant sa vie. En outre, plusieurs roles peuvent etre joues simultanement et le meme role peut etre joue plusieurs fois pendant des periodes differentes de la vie d'un objet. En d'autres termes, la notion de role permet de decrire des objets qui changent leur comportement de maniere dynamique pendant leur existence. On appellera extension de role d'un objet
!'ensemble des roles qui sontjoues par cet objet
a
un instant donne.xiv RESUME La modelisation de la vie d'une personne constitue un exemple typique d'un objet jouant plusieurs roles pendant son existence. Une personne qui est actuellement un ETUDIANT peut devenir un ETUDIANT _DOCTORANT une fois qu'il a reussi ses examens finaux. Un personne qui est actuellement EMPLOYEE apres sa 65 annee doit devenir RETRAITEE. Dans les deux cas, c'est la meme personne qui change de role pendant sa vie.
n
faut noter qu'un etudiant peut commencera
travailler pendant ses etudes et par consequent jouer le role d'EMPLOYE pendant qu'il joue simultanement le r6le d'ETUDIANT. Dans ce cas la meme personne joue deux roles simultanement. Finalement il peut etre souhaitable d'interdirea
un objet de jouer deux ou plusieurs roles si.multanement. Par exemple, une personne qui est RETRAITEE ne peut pas etre en meme temps EMPLOYEE.Un objet peut commencer ou arreter de jouer un r6le soit parce qu'il a decide lui meme ainsi soit parce qu'un autre objet Jui a demande de le faire. Par exemple, une personne agee de 60 ans peut decider de prendre sa retraite anticipee et par consequent changer de role. D'autre part, le changement d'un role peut etre la consequence de l'occurrence d'un evenement externe, comme par exemple l'echec d'un etudiant aux examens.
context VIE_AVION { roleAVION {
public messages public constraints } role OPERATIONNEL {
decoller f-, atterrir f-;
} role MAINTENANCE { public messages
delivery_date f-, expected_ date f-;
public constraints
public constraints
D(OPERA TIONNEL v MAINTENANCE => AVION);
D(MAINTENANCE =>..., OPERATIONNEL) D(OPERA TIONNEL =>..., MAINTENANCE)
Fig. II Definition d'un contexte decrivant le cycle de vie d'avions
Rf'Jles et contextes pour objets complexes xv
La specification d'un contexte C delimite !'ensemble de roles qui peuvent etre joues par une instance de
c
et definit l'ordre temporel dans lequel les roles du contexte peuvent etre joues. Par exemple, le contexte VIE_PERSONNE correspondanta
la description du cycle de vie d'une personne regroupera d'une part des roles tels que EMPLOYE, ETUDIANT, ETUDIANT _DOCTORANT et RETRAITE et d'autre part la specification des contraintes presentees dans les paragraphes precedentes. L'exemple de la Fig. II presente un contexte decrivant le cycle de vie d'avions. Le contexte VIE_AVION comprends trois roles AVION, OPERATIONNEL et MAINTENANCE. Le role AVION est suppose d'etre joue pendant toute la duree de vie d'un avion. On suppose qu'il contient les differentes proprietes et caracteristiques identifiant un avion, tels que la couleur, le type de l'avion, son numero d'identification et son proprietaire. Le jeu du role OPERATIONNEL s'identifie avec les periodes pendant lesquelles l'avion est utilise pour faire des voyages. Le role MAINTENANCE estjoue lorsqu'un controle de revision est en train de s'effectuer. Les contraintes associees au contexte VIE_AVION stipulent que les roles OPERATIONNEL et MAINTENANCE ne peuvent pas etre joues simultanement.IV ROies et contextes pour objets complexes
Au moyen des objets complexes il devient possible de specifier la cooperation d'un ensemble d'objets. La specification d'un objet complexe comprends un ensemble de definitions des composants (components). La definition d'un composant a la forme
K: C, indiquant que K doit referencer une instance du contexte C. En general, un objet peut etre reference par plusieurs composants d'un meme OU de differents objets complexes et par consequent etre partage par plusieurs objets complexes.
Un exemple de contexte pour objets complexes decrivant le voyage d'un avion se trouve
a
la Fig. III. Le contexte VOYAGE comprend trois composants: pi, ctt et ctl.Le composant pi est contraint dereferencer une instance du contexte VIE_AVION.
Il represente l'avion qui fait le voyage. Les composants ctt et ctl sont contraints de referencer des instances du contexte VIE_ TOUR_CONTROL. Ils representent les tours de controle des aeroports d'ou l'avion decolle et atterrit. Deux roles ont ete definis pour le contexte complexe VOYAGE: PROCESSUS_DECOLLAGE et PROCESSUS_ATTERISSAGE. Il est suppose qu'ils sont joues en sequence, le premier role qui doit etre joue est le role PROCESSUS_DECOLLAGE.
xvi RESUME Comme pour les objets elementaires, un ensemble de contraintes associees
a
uncontexte ainsi qu'aux differents r6les du contexte complexe speci.fient l'ordre temporel dans lequel les messages peuvent etre echanges. Cependant, les contraintes associees
a
un contexte complexe permettent de specifier de maniere precise l'interaction d'un ensemble d'objets qui soot references par Jes composants de l'objet complexe.context VOYAGE { components
ell: VIE_TOUR_CONTROL;
ctl: VIE_TOUR_CONTROL;
pi: VIE_AVION;
role PROCESSUS_DECOLLAGE { flllhlic: mP.RRilQP.R
execute_decollage ~.
decollage_effectue ~ public constraints
}
execute_decollage A
o
decollage_effectue;component messages
ctt$demande_decollage ~. ctt$perm_decollage ~. pl$decoller ~;
component constraints
execute_decollage A O ctt$demande_decollage;
O (ctt$perm_decollage ,,, O (pl$decoller "O decollage_effectue));
role PROCESSUS_ATIERISSAGE {
public constraints component constraints
Fig. Ill Definition du contexte VOYAGE pour objets complexes
Pour les objets complexes, on distingue entre contraintes publiques (public constraints) et contraintes complexes (component constraints). On fera aussi la distinction entre messages publics (public messages) et messages compleus (component messages).
Les messages publics d'un objet complexe w soot des messages echanges entre w et d'autres objets qui ne sont pas ses composants. Les messages complexes d'un objet complexe w soot des messages echanges entre wet un de ses composants. Pour
RfJles et contextes pour objets complexes xvii la definition des messages complexes il faut que la propriete suivante soit satisfaite:
en supposant la definition d'un composant lC: C dans un contexte C', pour la definition d'un message complexe 1C$msg f-(1C$msg ~) dans un role de C' il faut que la definition du message public msg ~ (msg f-) apparaisse dans l'un des roles specifies dans C. D'apres la description des messages publics et messages complexes, il n'est pas possible de specifier d'echange de messages entre deux composants. Par consequent l'objet complexe joue le role de coordinateur entre ses composants. Pour la specification des contraintes publiques d'un objet complexe seulement des messages publics peuvent etre utilises tandis que pour la specification des contraintes complexes des messages publics et des messages complexes peuvent etre utilises.
Le role PROCESSUS_DECOLLAGE contient deux messages publics execute_decollage et decollage_effectue. La specification de contraintes publiques exige que l'objet complexe recoive le message execute_decollage en premier et envoie le message decollage_effectue
a
l'expediteur du message execute_decollage.L'ensemble de messages complexes qui peuvent etre echanges avec l'objet complexe pendant que le role PROCESSUS_DECOLAGE est en train d'etre joue sont demande_decollage, perm_decollage et decoller. Afin d'identifier le composant qui est l'expediteur ou le recepteur d'un complexe message, le nom du message est prefixe par l'identificateur du composant suivi du caractere "$". Par exemple pendant que le role PROCESSUS_DECOLLAGE est joue aucun message complexe n'est echange avec le composant ctl.
La premiere des contraintes complexes exige que le premier message re~u par l'objet complexe soit execute_decollage. Un fois que le message execute_decollage est recu le message demande_decollage doit etre envoye au composant ctt par l'objet complexe. La deuxieme contrainte specifie que la reception du message perm_decollage de la part du composant ctt doit etre suivie par l'envoi du message decoller ayant comme expediteur l'objet complexe et comme recepteur le composant pl. Une fois que le message decoller a ete envoye
a
pi, le message decollage_effectue doit etre recu par l'objet complexe.Afin de clarifier la difference entre contraintes publiques et contraintes complexes on presentera leur utilite lors de la composition temporelle du comportement des objets. Les contraintes publiques sont considerees comme faisant partie de !'interface d'un objet complexe puisqu'elles specifient son comportement en faisant abstraction des details de la composition d'autres objets.
xvi ii RESUME
Les contraintes complexes sont considerees comme etant intemes Al'objet complexe puisqu'elles specifient sa composition A partir d'autres objets. Pour s'assurer de la coherence de la specification d'un objet co.mplexe, les contraintes publiques de ses composants doivent etre prises en compte. Pour un objet complexe w ceci se fait en composant (par conjonctjon logique) les contraintes publiques des composants de w et les contraintes complexes dew. Si par la suite west assigne A un composant d'un objet complexe x, les contraintes complexes de x sont composees avec les contraintes publiques de w pour verifier la coherence des specifications de x .
• • • • • • • • •
C3 composition = contralntes-publiques-C1 " contraintes-publiques·~ "
contraintes-publiques-C3 " contraintes-complexes-C3 C6 composition
=
contraintes-publlques-C4 "contraintes-publiques-CC5 "contraintes-complexes-C6
Fig. IV Schema d'utilisation des contraintes publiques et contraintes complexes pour la composition temporelle du comportement des objets
Yerification des specifications xix La Fig. IV presente le schema d'utilisation des contraintes publiques et contraintes complexes pour la composition temporelle du comportement des objets.
Les ovales representent des definitions de contextes. Un arc etiquete K reliant un contexte C
a
un autre contexte C' indique que la definition de C contient la definition d'un composant K: C'. Pour le contexte C4 les contraintes complexes de C4 sont composees avec les contraintes publiques des contextes C1, C2 et C3. Pour la composition de. Cs les contraintes publiques des contextes C4 et Cs sont composees avec les contraintes complexes de Cs.Le schema de composition temporel precedent exige que pour les contraintes publiques et contraintes complexes du meme objet complexe une regle de compatibilite, appelee lapropriete de correspondance, soit verifiee. En fait, on doit s'assurer que pour toute sequence de messages publics satisfaisant les contraintes publiques il existe au moins un sequence de messages publics et messages complexes satisfaisant les contraintes complexes.
V Verification des specifications
La verification de la coherence des specifications relatives aux objets elementaires et objets complexes ainsi que la verification de la propriete de correspondance s'effectue au moyen de l'algorithme de satisfaction pour la logique temporelle propositionnelle presente au chapitre 5.
Comrne entree pour l'algorithme sont donnees les specifications du comportement d'un objet complexe ou d'un objet elementaire. Si les specifications sont coherentes l'algorithme produit un graphe, appele graph de satisfaction, representant tous les modeles possibles de la formule donnee. La Fig. V presente le graphe de satisfaction correspondant
a
la formule 0 (p :::} 0 q). Au cas ou les specifications sont incoherentes l'algorithme ne produit aucun graphe.{q}
Cl
{q}r=J
{q)CJ(
(p}/>C ).
{q}
Fig. V Graphe de satisfaction correspondant
a
la formule D (p ~ O q)xx RESUME
VI Contributions
Les contributions importantes de cette these sont les suivantes:
• L'algorithme de satisfaction pour la logique temporelle propositionnelle constitue une extension d'algorithmes existants [Mann84] en prenant en compte les operateurs temporels du passe.
• Une base formelle a ere etablie pour la description de l'evolution dynamique du comportement des objets.
• Une base formelle a ete etablie pour la description des aspects temporels concernant la cooperation d'ensemble d'objets.
• Une procedure rigoureuse et automatique pour la verification de la coherence 'des specifications a ere con{!ue.
• Finalement, le modele dynamique propose a ete con{!U afin d'etre utilise conjointement avec des modeles de donnees orienres objets. Plus precisement, !'importance donnee
a
la specification de la composition temporelle du compo:rtement des objets remplit une exigence essentielle des methodologies de conception orientees objet.CHAPTER 1 INTRODUCTION
1.1 Motivation
The recent proliferation of commercial and prototype object-oriented systems [Care88] [Maie86] [Fish87] [Bane87] [Lecl88] [Weis89] reveals the increasing influence of the object-oriented approach in the area of data modelling. An important reason for this interest is that the object~oriented approach seems to be the most promising approach for integrating the expressive power of object-oriented programming languages and the various abstraction mechanisms identified for semantic data models [Kim88] [Banc88].
However, the full success of such an integration depends on several important issues which still remain to be addressed [Bloo87]. They concern the design and implementation of object-oriented data models but also design methodologies and tools necessary to assist the development of object-oriented applications [Tsic88]
[Tsic89b] [Meye88] [Cox87] [Gibb90a].
Most of the identified open issues for the object-oriented approach are in fact long standing issues. They have been addressed several times in the past but for different approaches. The need to reconsider existing ideas arises frequently either when a novel problem is faced or when a new technology becomes available [Tsic89a]. It is therefore natural to reevaluate existing ideas with respect to the object-oriented technology. From such a reevaluation existing notions and concepts may be shown to be either inconsistent, orthogonal or necessitating some tailoring and adaptation with respect to new requirements.
The above situation applies to the various proposals of notions and concepts, collectively called dynamic models, proposed for the description of dynamic aspects of database applications [Dean81] [Hom85] [Kung85a] [Kung85b] [0ber87]
[Rich82] [Solv86] [Stud86] [Lipe87] [Sem80]. The majority of existing dynamic models have been designed to be used in conjunction with semantic data models. As a consequence most of the characteristic features of the object-oriented approach
1
2 INTRODUCTION
[Banc88] [Atki89] have not been taken into account.
The motivation for this thesis was to design a dynamic model, named TLOOM1,
reflectfog the underlying philosophy of the object-oriented approach. More precisely, TLOOM emphasizes the following two essential aspects of the object-oriented application design process:
• the description of the temporal evolution of object behavior,
• the temporal composition of object behavior, that is the description of temporal properties and rules concerning the cooperation of a collection of objects.
Addressing the issue of temporal composition is not only a matter of extending the modelling capabilities of a dynamic model. The relovanco of temporal composition emerges from the bottom up style of object-oriented design methodologies which encourage the behavioral composition of objects [Helm90] [DeMe91]. That is, combine the functionality of al.ready existing objects for developing new objects. We consider temporal composition as a complementary aspect of behavioral composition where temporal aspects are emphasized.
Concerning our objective, an important requirement we have taken into account was to set up a formal basis upon which TLOOM would be founded.
Fulfilling this requirement would permit us not only to test the consistency of the various notions integrated in TLOOM but also to test the consistency of user provided specifications. From a number of candidate formaHsms the language of propositional temporal logic CPTL) appeared to us to be the most suitable formalism for our purposes.
It must be stressed that the kinds of temporal properties that can be specified with TLOOM are in fact temporal causal dependencies between events2, in other words, properties concerning the ordering of events in time. The modelling of historical information, that is, the various interpretations that can be attributed to temporal values like "14:30" for time and "15/11/1991" for dates, as well as issues concerning the storage, manipulation and query of temporal values, has not been investigated at all. In this thesis we will use both terms "temporal" and "dynamic"
1. TLOOM stands for Temporal Logic based Object Oriented Model.
2. In TLOOM, the notion of event is identified with the notion of message sent to or received from an object.
Overvi.ew 3 interchangeably to denote the time-based nature of a concept or notion.
1.2
Overview
The material included in this thesis is presented according to the following structure.
In the first part of the second chapter we present a broad classification of data models according to their contributions for modelling the various aspects of a database application. It is followed by a more or less detailed description of the various notions characterizing a data model as object-oriented. We complement the above description with the presentation of a number of critical issues concerning the development of database applications within an object-oriented framework. In the last section, we present the main characteristics of those models proposed for the description of dynamic aspects of database applications.
The third chapter is mainly devoted to an informal presentation of the various notions composing TLOOM. We complete the informal presentation by contrasting the notions of TLOOM with the various notions characteristic of object-oriented data models. In the last section of the chapter we justify our decision to use PTL for providing a formal foundation ofTLOOM.
In the fourth chapter we formally present those notions of TLOOM that are intended for the description of temporal evolution of object behavior.
In chapter five we describe an algorithm for testing the satisfiability of formulas in PTL. In addition, we discuss the usage of the satisfiability algorithm for verifying the consistency of specifications and monitoring adherence to the specifications during run time.
In chapter six we formally present those notions of TLOOM that are intended to describe the various temporal properties and rules of a collection of cooperating objects.
As we did for chapter five, in chapter seven we describe how to verify the consistency of the various rules and properties specified for a collection of cooperating objects by means of the satisfiability algorithm. In addition, we describe how to verify adherence to the specified properties during run time.
In chapter eight we present a number of dynamic models having several
4 INTRODUCTION characteristic feat ures in common with TLOOM and we point out the main differences and similarities compared with TLOOM.
Finally, in chapter nine we present our conclusions and future research directions.
1.3 Contributions
The main contributions of this thesis can be summarized as follows:
• The satisfiability algorithm constitutes an extension of existing algorithms [Mann84] to take into account past operators.
• A formal basis for the description of the temporal evolution of object behavior is established.
• A formal basis for the specification of the temporal composition of object behavior is established.
• A rigorous procedure for the verification of consistency of formal specifications is presented.
• Finally, the proposed dynamic model has been designed to be used in conjunction with object-oriented data models. More precisely, it emphasizes the composition of the temporal specification of object behavior, thus fulfilling a critical requirement expressed by object-oriented design methodologies.
CHAPTER 2
MODELLING THE REAL WORLD
This chapter is primarily devoted to presenting the main motivations that influenced the design and development of data models up to the present proliferation of object-oriented data models. More precisely, the first section identifies three basic dimensions concerning the development of database applications. These are the description of static, operational and dynamic aspects.
The second section presents the essential characteristics of those data models which have been designed for the description of static aspects. The third section presents the characteristic features of data models intended for the description of both static and operational aspects. The first part of the fourth section describes those notions characterizing a data model as object-oriented. The second part presents a number of critical issues concerning the development of database applications within an object-oriented framework. The last section presents the characteristics of those models proposed for the description of dynamic aspects.
2.1 Design and development of database applications
We consider database applications to be those applications which are designed to manage large amounts of shared persistent data, or in other words those applications for which a database constitutes a critical component. I~tially
database applications were developed in the area of business applications. Since the early eighties database applications have been found in a wide range of application domains like CAD, CASE, AI and office automation.
In a database application the contents of a database are not presented to the users of the database management system (DBMS) the way they are physically stored, that is raw bits. Rather a DBMS offers a data definition and manipulation language (DDML) allowing users to describe and manipulate the database contents in terms of a data model.
5
6 MODELLING THE REAL WORLD
We define a data model as a tool, probably formal, comprising a collection of concepts and mechanisms by means of which a computer representation of a problem of interest can be formulated. To adequately assist the designer in bis/her task the data model should support a necessary and sufficient set of abstractions for easily and faithfully describing the real world. By abstraction we mean a mechanism permitting to emphasize the relevant properties of some part of the real world while irrelevant ones can be neglected. From now on we will use the term real world to generically denote problems or situations to be described by means of some data model. In most cases the description of the real world is decomposed in the description of its stat;,c, operational and dynamic aspects.
In order to be more precise about the terms static, operational and dynamic aspects, let us assume that the real world is perceived as consisting of entities and 1·1:1laLivu::1hivs Lhat. may ut may t'1\1!. hc,ld bet.w.::.;.u MLit.ies. Entities an: .:01"1Siclo:u·eJ those elements of the real world which can be distinctly identified. A relationship is defined as an association between entities.
The description of the static aspects concern issues such as the choice of the criteria to be used for enti~y classification, the choice of the data structures to be used for entity representation, the description of the various kinds of relationships between entities, and the specification of constraints to be maintained for entities and relationships.
Operational aspects mainly concern the way entities and relationships may be accessed and manipulated. The choice of data manipulation facilities to be integrated with a data model ranges over several levels of expressive power and complexity. At one extreme a few generic operations for storing, retrieving and updating entities and relationships may be provided. At the other extreme facilities close to programming languages may be integrated with a data model.
Finally, dynamic aspects concern issues such as the specification of time-varying properties, time-dependant constraints, the temporal orde.r of operation invocations manipulating entities and relationships, the temporal order of integrity constraint validation periods.
We classify data models according to whether they include facilities to describe static, operational and dynamic aspects. Data models which we classify as static data models provide facilities for specifying only static aspects of the real world.
Models which we classify as integrated models include facilities for the specification of both static and operational aspects of the real world. Finally, the approach which
Static data models 7 is often undertaken concerning the specification of dynamic aspects is to propose a separate specification language or a collection of concepts and notions to be used in conjunction with a static data model or an integrated model. Such a specification language or collection of concepts we will call a dynamic model1.
2.2
Static data models
During the seventies, the relational data model (RM) [Codd70] gained popularity within the database community and has been extensively studied from both theoretical and implementational points of view. Its influence on the evolution of database research and especially in the area of data modelling has been very strong and has lasted for a long period of time. The success of the RM has not been limited to the academic environment. Most present commercial DBMSs provide relational interfaces to their users. Thus not surprisingly more than twenty years after its original publication, the RM remains a reference data model against which current developments are compared.
In spite of its enormous success, the relational model was too simple for extending database technology to application domains like office automation, CAD, CASE, and AI. A striking feature depicting its simplicity is that only one construct has been provided for modelling both entities and relationships between entities.
Subsequent data models which explicitly recognized the distinction between entities and relationships and provided distinct mechanisms to support that difference have been called semantic data models. Noteworthy representatives of semantic data models include the ER [Chen76], RM!l' [Codd79], SDM [Hamm81]
and DAPLEX [Ship81] data models.
The development of semantic data models is tightly coupled with numerous works which focused on studying and identifying data abstractions. In [Brod84]
four principal data abstractions are recognized: classification, generalization,
1. In general, models designed for modelling temporal information can be classified into two categories: historical models and dynamic models. Historical models are designed for storing, manipulating and querying past database states. Usually a DBMS implementing a historical model should store all past database states which have been produced due to update operations from the moment the database is created until the current moment. Dynamic models are designed for specifying and eventually enforcing the dynamic evolution of the database (this does not necessarily imply that past database states should be remembered). The difference between the two categories of models will be discussed in more detail in section 2.5.
8 MODELLING THE REAL WORLD
aggregation and association. Considerable efforts have been produced to design data models providing as much as possible direct support for various kinds of data abstractions. The aim was to provide a one-to-one correspondence between the real world and the data model. The outcome of these efforts is reflected in the increasing improvement of the modelling capabilities of semantic data models. Indeed, the majority of semantic data models provide data structures for modelling quite complex real world entities and enable the specification of complex constraints and relationships between entities.
Another category of static data models constitute the
NF2
data models. The terms complex object and non-lNF are all used to denote the same category of data models. NF2 data models extended the RM by dropping the lNF requirement for relations. In fact the lNF requirement stipulates that domains of attributes must be simple, or, m other words, that a domain cannot be decomposed into simpler domains. Dropping the lNF requirement permitted the development of relational-like models with nested data structures while inheriting an important theoretical background form the RM. The structural extensions proposed by NF2 models have been accompanied by extensions concerning the query and data manipulation language. In [Sche86] [Abit86] high-level query languages for NF2 models have been investigated and formally defined. NF2 models provided a formal framework for addressing several issues in the area of data modelling. For example, in [Hull84] and [Abit86] the issue of database schema reorganization has been formally investigated on the basis ofNF2 models.Fig. 2.1 shows a general view of a database application assuming that a static data model has been used to describe its database. Users may access the database either directly issuing DDML commands or indirectly via application programs.
Application programs are written either in DDML or in some host programming language where a predefined set of routines provided by the DBMS is used to access the database.
Concerning Fig. 2.1 the following two important points must be emphasized since they have important consequences for the design of data models:
• The need to write application programs in a host programming language arises whenever a database application reveals significant operational aspects. DDMLs of static data models fall short in expressing complex operational aspects. They are mainly intended to describe static aspects.
Static data models 9
• A DBMS acts as a shield for the contents of the database in the sense that it enforces the access and manipulation of the database to be performed in terms of the data model it supports. Note however that for static data models the above mentioned protection enforced by the DBMS is limited to static aspects.
application program written in a host
programming language
D
appllcatlon program written In DDMLFig. 2.1 Database application using a DBMS supporting a static data model
10 MODELLING THE REAL WORLD
2.3 Integrated models
While static data models have emphasized the description of the static aspects of database applications they have neglectea ope.rational aspects. Even though query languages have been designed for static data models, they fall short in expressing complex operations, and are therefore considered unsuitable for application development. As a consequence, the development of database applications requires writing application programs in a programming language incorporating communication facilities with a database system.
However, accessing a database system from a host programming language is a troublesome process. This is caused by the fact that two languages with different characteristics are forced to coexist. They have different computational models, lh"Y provide different data types, and one is set-at-a-time while the other is record-at-a-time [Banc88]. In addition the semantics of the application is disseminated in two different places: database specification and application programs.
In attempting to improve the synergy of programming language and database systems two main threads have emerged. The first thread consists of integrating the characteristic features of a particular data model in an existing programming language or vice-versa [Schm77] [Smit83] [Wass79] [Rowe79]. We call them database programming languages. The second thread consists of designing data models integrating data and operational abstractions [Mylo80J [Alba85]. We call s1.1ch data models integrated data models.
Database programming languages have significantly contributed in improving the interface between a programming language and a database system. They have lhe merit of not introducing new concepts thus relieving users from investing time to learn a new integrated model. In most cases such an integration involved a procedural language, for example PASCAL, and the RM. Examples of such efforts are PASCAIJR [Schm77], PLAIN (Wass79] and RIEGEL [Rowe79]. Although this practice improves the interface between host programming language and DBMS the picture of a database application remains essentially the same as in Fig. 2.1.
That is, they do not provide any notion or mechanism for associating and enforcing the manipulation of a database in term.s of user defined operations.
In contrast to database programming languages, the design of integrated data models is not restricted to the features of a particular programming language and
Integrated models 11 data model. Rather the designer is free to choose a collection of orthogonal operational and data abstractions to be integrated in a model. That has been one of the main motivations for designing integrated data models. Another important motivation is to provide data models permitting the description of the access and manipulation of a database in terms of user defined operations. In so doing, a DBMS implementing an integrated data model would enforce the manipulation of the database to those operations defined in the database description.
D
apl'lica~ion program written man integrated data modelFig. 2.2 Database application using a DBMS supporting some integrated data model
12 MODELLING THE REAL WORLD
In Fig. 2.2 is depicted a general view of database application assuming that an integrated model has been used to describe the database. Although Fig. 2.2 may seem identical to Fig. 2.1 except perhaps that application programs and the database description are written in the same language there is an important cliffe1·ence. The database description now includes not only the structural aspects of the stored data but also the pieces of code permitting to manipulate that data.
Two representative examples of integrated data models are TAXIS and Galileo.
TAXIS [Mylo80] was one of the first efforts designing a data model with programming language facilities as a single unit. Its more innovative contributions can be roughly summarized as follows. The model equally emphasizes the description of the static and operational aspects of real world entities. This is acmeved by associating with data values the operations that can be applied to t.hPm St?mantic constructs are equally applied to data structures and to the variou.:s programming language features. Tbus in addition to data structures, operations, integrity constraints and ex.ception handlers are organized in generalization merarcllles.
The characteristic feature of Galileo [Alba85] is the integration of the principal semantic data modelling abstractions such as classification, generalization and aggregation witmn a rich and extensible type system. In fact, a strongly typed system has been designed meaning that it is possible to determine whether a given expression is type consistent or not from a static examination of a program.
Additional features of Galileo constitu.te its exception handling facilities to cope with failure, a modularization mechanism permitting to incrementally describe the real world in terms of small related parts, support for transaction specification and the integration of several kinds of predefined integrity constraints and derived information.
2.4 Object-oriented data models
As explained in [Tsic89a], the object-oriented approach can be seen as a set of concepts, drawn from several areas in computer science, wmch researchers adapt to the idiosyncracies of their problem domain. Tms has been also the case for the database community.
Object-oriented data models constitute a subclass of integrated data models.
They have grown up from the integration of data abstractions from semantic data
Object-oriented data models 13
models and operational abstractions from object-oriented programming languages.
However, the various efforts which attempted such an integration have not been subject to strict rules. As a consequence a variety of data models implemented by object-oriented systems has been proposed. On one hand they share the same underlying philosophy and on the other hand they exhibit different and even contradictory aspects. Thus we cannot talk about a standard object-oriented data model.
The above situation motivated several efforts to provide a satisfactory definition of an object-oriented data model. Recently, a consensus seems to be emerging concerning the minimal set of concepts characterizing a data model as object-oriented [Banc88] [Atki89]. These are of classes and types, object identity, encapsulation, inheritance, late binding and overriding.
The remainder of this section is devoted to a brief presentation of the above concepts. More precisely, the presentation that follows mainly reflects the viewpoints and definitions appearing in [Banc88] and [Atki89] to which we mostly adhere. We will conclude the section with the presentation of a number of critical issues concerning the development of database applications within an object-oriented framework.
2.4.1 Classes and types
The notions of class and type can be illustrated by pointing out their respective usage. A class is used both to determine a collection of objects, and as a template from which objects may be instantiated. The set of objects that are instances of a class C is called the extension of C. Types are used for checking the consistency of expressions in the language. In other words, types are used at compile time while classes are used at run time.
Although the notions of class and type differ considerably, in almost any system a class declaration plays the role of a type declaration as well. Furthermore the notion of subtyping is identified with the notion of class inheritance introduced later in this section. A more thorough discussion contrasting the notions of class and type and the corresponding related notions of inheritance and subtyping can be found in [W egn88].
A class definition consists of a collection of operation and instance variable definitions. Each object instantiated from a class C has its own copy of the set of instance variables defined in C. The set of operations defined in C is shared by the
14 MODELLING THE REAL WORLD collection of objects forming the extension of C. Instance variables are intended for storing the various states to which an object may be found. The collection of operations implements the behavior of an object, their execution being responsible for object state transitions.
We represent an instance variable defined in a class C as a tuple of the form:
[C, iv-name: Cvl C. Cv e CL
Here CL is the set containing all classes and Cv is the class associated with the instance variable. The semantics of assignment and equality concerning the values of instance variables may be either a reference semantics [Gold83], a value semantics [Stro86] or the combination of reference and value semantics for different types of values [Meye88].
We represent an operation defined in a class Casa tuple of the form:
[C, operation_name, res: CR, par{ C1, .. . ,park: CiJ C, CR, Ci e CL i = 1, ... , k where pari represent formal parameters of the operation and Ci classes associated to parameters. Parameter res and its associated class CR are reserved for the return value of the operation.
We will call the signature of an operation the part of the tuple consisting of res: CA, par 1: C1, ... , park: Ck
2.4.2 Object identity
Object identity [Khos86] is a similar notion to that of surrogate proposed for semantic data models [Codd79]. More precisely, object identity (oid) is an inherent property possessed by each object permitting the identification of an object independently of its behavior and internal state.
An important implication of object identity is the complete independence between object updates and object sharing. That is, updating an object w does not produce any side effect to the fact that w is a shared component of a collection of objects. As a consequence, supporting object identity in a data model considerably increases the flexibility of modelling real world entities. Namely, it enables the specification of an object whose structural composition from its components may be illustrated by means of a directed graph. The independence between object sharing and object updates constitutes an important difference with respect to data models
