Object Roles - Aj 2002

8/12/2019 Object Roles - Aj 2002

1/172

.

The Institute of Computer Science

The Polish Academy of Sciences

Andrzej Jodowski

Dynamic Object Roles

in Conceptual Modeling and Databases

Ph. D. Thesis

Advisor:

Doc. Dr. Hab. Kazimierz Subieta

Warsaw, November 2002


2/172


3/172

3

Table of Contents

1. Introduction ................................................................................................................7

2. Choosing Notions in Conceptual Modeling .................... .......................................... 10

2.1. Conceptual Modeling ............................................................................................. 10

2.2. Notions of Object-Oriented Conceptual Modeling .................................................. 13

3. Inconveniences of Multiple Inheritance ................................................................... 15

3.1. The Concepts of Class and Inheritance ................................................................... 15

3.2. The Concept of Multiple Inheritance ...................................................................... 18

3.3. Multiple Classification ................................................. .......................................... 21

3.4. Types and Substitutability ...................................................................................... 21

3.4.1. The Concept of Type ..................................................................... ................... 21

3.4.2. Subtypes and Substitutability............................................................................ 23

3.5. Well-Known Programming Languages and Multiple Inheritance ............................ 24

3.5.1. Smalltalk .......................................................................................................... 24

3.5.2. Modula-3 ........... .............................................................................................. 24

3.5.3. Eiffel ................................................................................................................ 25

3.5.4. C++ .................................................................................................................. 26

3.5.5. O2 .................................................................................................................... 26

3.5.6. Java .................................................................................................................. 26

3.5.7. General Observations ....................................................................................... 27

3.6. Multiple Inheritance in the Object-Oriented Methodologies and Notations ............. 27

3.7. Multiple-Inheritance Problems ............................................................................... 28

3.7.1. Semantical Context and Multiple Inheritance ................................................... 28

3.7.2. Human Factor ............................................................................... ................... 30

3.7.3. The Name Conflict ................................................. .......................................... 31

3.7.4. Typological Problems....................................................................................... 33

3.7.5. The Multiple Inheritance and Object Migration ................................................ 34

4. Well-Known Approaches to Dynamic Object Roles ................................................ 36

4.1. The Concept of Roles by Bachman and Daya ......................................................... 39

4.2. Aspects .................................................................................................................. 40

4.3. Fibonacci Approach ............................................................................................... 43

4.4. The Concept of Roles by Kristensen ...................................................................... 45


4/172

4

4.5. Prototypes .............................................................................................................. 46

4.6. Subtables in SQL99 ............................................................................................... 47

4.7. Roles Realized by Design Patterns ......................................................................... 48

5. Dynamic Object Roles in Stack-Based Approach .......... .......................................... 52

5.1. The Concept of Dynamic Object Role ................................................. ................... 525.2. Object Store Model with Dynamic Roles ............................................................... 53

5.2.1. Links among Objects and Roles ....................................................................... 55

5.2.2. Dynamic Roles - a Formal Model of an Object Store ..................... ................... 56

5.3. Dynamic Roles vs. Classical Object-Oriented Models ............................................ 60

5.3.1. Multiple Inheritance ......................................................................................... 60

5.3.2. Repeating Inheritance ....................................................................................... 61

5.3.3. Multiple-Aspect Inheritance ............................................................................. 61

5.3.4. Temporal and Historical Properties .................................................................. 61

5.3.5. Variants (Unions) ............................................................................................. 61

5.3.6. Object Migration .............................................................................................. 62

5.3.7. Referential Consistency ................... ................................................................. 62

5.3.8. Overriding .......... .............................................................................................. 62

5.3.9. Binding ......................................................................................... ................... 62

5.3.10. Typing ............................................................................................................. 62

5.3.11. Subtyping ........... .............................................................................................. 63

5.3.12. Substitutability ................................................................................................. 63

5.3.13. Dynamic Inheritance ..................................................................... ................... 63

5.3.14. Aspects of Objects and Heterogeneous Collections........................................... 64

5.3.15. Aspect-Oriented Programming and Separation of Concerns .......... ................... 64

5.3.16. Meta-Data Support ................................................. .......................................... 64

5.4. Specification of Dynamic Roles in Database Schemata .......................................... 64

5.4.1. Concepts for Building Database Schemata ....................................................... 65

5.4.2. Naming Issues ............................................................................... ................... 67

5.4.3. A Sample Construction of an Object Schema with Dynamic Roles ................... 68

5.4.4. Declarations of Data Structures .............................. .......................................... 71

5.4.5. Metadata Management .................... ................................................................. 73

5.5. Query Language for the Object Model with Dynamic Roles ................................... 77

5.5.1. The Environment Stack ................... ................................................................. 78

5.5.2. Opening a New Scope on the Environment Stack ............................................. 81


5/172

5

5.5.3. Thin and Thick Sections ................................................................................... 82

5.5.4. Private, Protected, and Public Properties .......................................................... 82

5.5.5. Binding ......................................................................................... ................... 83

5.5.6. Polymorphism and Overriding .......................................................................... 84

5.5.7. Creating and Deleting Roles ............................................................................. 845.5.7.1. Create Operator ......................................................................................... 84

5.5.7.2. Delete Operator ......................................................................................... 86

5.5.8. Role-Specific Operators ................................................................................... 86

5.5.8.1. Casting Operator ....................................................................................... 86

5.5.8.2. Hasrole Operator ....................................................................................... 88

5.5.8.3. Roles Operator ........................................................................................... 88

5.5.9. Query Optimization .......................................................................................... 89

6. Extending UML with Dynamic Object Roles .......................................................... 91

6.1. Dynamic Classification vs. Dynamic Object Roles .............................. ................... 92

6.2. Composition vs. Dynamic Object Roles ................................................................. 94

6.3. RoleOfRelationship ............................................................................................... 96

6.4. Combining Class and Role Hierarchies .................................................................. 98

6.5. Multiple-Aspect Inheritance ................................................................................. 100

6.6. Classical Inheritance vs.RoleOfRelationship ....................................................... 101

6.7. Notation forRoleOfInstances .............................................................................. 102

7. Implementation ........... ............................................................................................ 104

8. Conclusions ........................................ ..................................................................... 109

Appendix A. The Prototype - General Description ........................................ ................. 111

A.1. The Physical Level ............................................................................................... 111

A.2. The Logical Level ............................................................................... ................. 113

A.2.1. The Definition of an Object: ........................................................................... 113

A.2.2. The Definition of Atomic Value ..................................................................... 114

A.2.3. Creating Objects ............................................................................................. 115

A.2.4. Information Retrieval Functions ..................................................................... 117

A.2.5. Updating Functions ........................................................................................ 119

A.3. The Conceptual Level .................................................. ........................................ 121

A.3.1. Class .............................................................................................................. 121

A.3.1.1. Attribute .................................................................................................. 122

A.3.1.2. Method .................................................................................................... 123


6/172

6

A.3.1.3. Relationship ............................................................................................ 123

A.3.2. Role Class .......... ............................................................................................ 125

A.3.3. Class Instance ............................................................................... ................. 125

A.3.4. Role Class Instance ........................................................................................ 128

A.3.5. Other Functions .............................................................................................. 129A.4. Metabase, ODL, SBQL with Dynamic Roles ....................................................... 130

A.4.1. The Grammar of ODL .................................................................................... 131

A.4.2. ODL Parser .................................................................................................... 133

A.4.3. SBQL Parser .................................................................................................. 135

A.4.4. The Grammar of SBQL ................... ............................................................... 136

A.5. Query Evaluation Module .................................................................................... 138

A.5.1. The Organization of Environment Stack ........................................ ................. 138

A.5.2. The Organization of Query Result Stack ........................................ ................. 139

A.5.3. Query Evaluation ........................................................................................... 140

A.6. Types and Reserved Names.................................................................................. 143

Appendix B. The Stack-Based Approach ........................................................................ 146

B.1. Introduction ........................................................................................ ................. 146

B.2. Objects, Classes and Abstract Object-Oriented Store Model ................................. 147

B.3. Example Database ............................................................................... ................. 148

B.4. Stacks .................................................................................................................. 151

B.5. Binding ................................................................................................................ 152

B.6. Query Language ........................................................... ........................................ 154

B.6.1. SBQL Syntax ................................................................................ ................. 155

B.6.2. Results of SBQL Queries ............................................................................... 156

B.6.3. SBQL Semantics ............................................................................................ 156

B.6.3.1. Algebraic Operators................................................................................. 158

B.6.3.2. Non-Algebraic Operators .......... ............................................................... 160

B.7. An Example of Query Evaluation .......... ............................................................... 163

Appendix C. List of Figures ............................................................................................. 164

Bibliography ..................................................................................................................... 166


7/172

7

1.IntroductionFor several years, dynamic object roles have had the reputation of a notion on the brink of

acceptance. There are many articles advocating the concept [ABGO93, BD77, BG95,

Fowler97, GSR96, Kristensen95, K96, KRR00, LL98, LW99, Papazoglou91, Pernici90,

RS91, WJ89, WL95, Wong99], but many researchers do not consider its applications

sufficiently broad to justify the extra complexity of conceptual modeling facilities.

Furthermore, the concept is neglected on the implementation side. As far as we know, no

popular object-oriented programming language or database system supports it explicitly.

Some authors assume a tradeoff, where the role concept is the subject of special design

patterns [BRSW00, Fowler97, GHJV95, RG98], applied both on the conceptual modeling and

the implementation sides. The notion has already been adapted by the SQL:1999 standard

[ANSI99], although the name is different, it has specific semantics, and some limitations.

SpeakerSpeaker

Author

Person

Programmee

Committee

Member

Speaker

ParticipantReviewer AuthorAuthor

SpeakerSpeakerSpeakerSpeaker

AuthorAuthor

PersonPerson

Programmee

Committee

Member

SpeakerSpeaker

ParticipantParticipantReviewerReviewer AuthorAuthorAuthorAuthor

Fig. 1.1Roles played by a person

The idea of dynamic object roles assumes that a real or abstract entity can acquire and get

rid of some roles during its lifetime without changing its own identity. The roles appear

during the life of a given object; they can exist simultaneously or disappear at any moment.

For instance, a person can be a reviewer, an author, a speaker, or a participant of a conference

at the same time, as depicted in Fig. 1.1. Similarly, a building can be an office, a house, amagazine headquarters, and so on.

Trying to develop a class model in UML and then to implement it in a certain

programming language, one can face three main difficulties:

(i) Due to some objects have many specializations at the same time, this leads to multiple

or multiple-aspect inheritance;


8/172

8

(ii) Some objects have many specializations of the same type (repeating inheritance). For

instance, a person can be a member of many clubs at the same time;

(iii) Some objects have specializations that depend on time. For instance, a person was a

student a year ago, but he or she can be an employee of a company currently.

Furthermore, a person can be an employee several times, at different times andcompanies.

Similar problems, mostly related to recording historical information, have occurred with

other entities such as institutions, companies and documents. One should conclude that the

classical inheritance concept, as presented in UML, for instance, is not fully adequate for data

environments dependent on historical data.

Another disadvantage of the design is complexity, chiefly after mapping it to a relational

DBMS. Very complex relational structures imply very complex SQL queries. We have

concluded that such cases are poorly dealt with in UML and cause difficulties during

implementation. The only radical cure is to introduce dynamic object roles both at the level of

UML class diagrams and at the level of data structures implemented in object-oriented or

object-relational DBMS.

In this dissertation, we show that dynamic object roles are useful both for conceptual

modeling and for implementation. We argue, the concept could much facilitate modeling tools

such as UML [UML01] and could be an important paradigm for object databases, which are

built on the spirit of ODMG [ODMG00].

Our idea to deal with dynamic roles in a query language [JHPS02] is based on the stack-

based approach (SBA) [PK00, Podzie00, SKL95]. A version [SMSRW93] was

implemented in the prototype system Loqis [Subieta91]. The SBA includes a data definition

language (DDL) and query language SBQL (Stack-Based Query Language) that are similar to

ODMG ODL and OQL respectively and have a clean and precise semantics. SBA constitutes

a uniform conceptual platform for integrated query and programming languages. One of its

central concepts is naming, scoping and binding principle, which enables us to deal with

naming issues effectively.

In our opinion, SBA is a universal, simple and powerful object data model, and is the only

formalism able to accommodate the concept of dynamic object roles naturally. We introduce

an extended SBA object model that defines roles as composite objects with a special

structure, semantics and generic operations. We describe the structure formally, present a

sketch of a data definition and query programming languages supporting generic operations to

define and process such structures.


9/172

9

The rest of the dissertation is organized as follows. Chapter 2 presents a short discussion

about notions in conceptual modeling. Chapter 3 analyzes inconveniences of multiple

inheritance. Chapter 4 presents the state of the art concerning dynamic object roles. Chapters

5 and 6 are the main parts of the thesis. Chapter 5 introduces our object model with roles and

discusses its differences with traditional objects models introduced in programming languagesand database management systems. Chapter 6 describes changes to the UML notation that

allows defining dynamic roles in the UML class diagrams. Chapter 7 briefly presents the

implementation of the prototype. Chapter 8 reports on our conclusion and future research

plans.

The objectives of this dissertation are

The introduction of an extended SBA object model with roles formally.

The development of a prototype of a data definition language that makes it possible

defining class schema with roles, and the development of a prototype of a

query/programming language supporting generic operations to act on objects with

dynamic roles.

The introduction of an extension of the UML class diagram encompassing modeling

dynamic roles.


10/172

10

2.Choosing Notions in ConceptualModeling

Due to different viewpoints about modeling real-world phenomena and about the ways to

perform this process by computer systems, it is necessary to introduce and use various notions

and languages. Efforts of object-oriented paradigm are heading for unification and limitation

of this variety. However, the complete unification cannot be entirely accomplished given

different natures of needed descriptions or various requirements imposed by recipients who

use a computer system. Peoples who are involved in constructing information systems,

wrestle with many problems, especially with: choice of the level of generality of the world to

be described and of its model, decisions about the meaning and localization of conceptual

schema within global data schema, and difficulties related to great complexity of conceptual

modeling process. The problems mentioned will be briefly presented and discussed in this

chapter.

2.1. Conceptual ModelingAttempts at representing fragments of real world have disclosed the necessity for introducing

several basic notions. These concepts characterize most often a descriptive kind of

knowledge, so they are related to certain sets of states of real world as well as to state

changes, which describe dynamic phenomena. Conceptual modeling makes it possible to

build mental images with the help of given notions in order to ensure good comprehension of

essential properties of characterized beings.

An image of programmers, who arduously code given algorithms in certain programming

language, is a rather common stereotype of works on software. However, an essence ofcreativity process is rather poorly illustrated by this stereotype. It does not encompass whole

complexity of images and mental processes, which occur in the mind of an analyst, designer

or programmer before beginning of programming and during programming works. A designer

or a programmer, before he/she starts coding, should very precisely understand a problem and

a method of its solution. According to common opinion, it is impossible to develop correctly


11/172

11

software, if a what to do and how it to do plan is incomplete or imprecise. It follows that

fundamental processes related to software development occur in a human mind and they do

not need to be connected with any programming language. The conceptual modeling and

conceptual model notions are related to all informal mental processes, which accompany the

works on software.Conceptual modeling takes place at different phases of system life cycle. It is supported

by proper semiformal means reinforced by a human memory and imagination. As a rule, those

means are based on graphical representation of mental images related to the reality and

characterized by the data, or related to data structures and processes needed for developing an

information system. Such tools as class diagrams, functional diagrams, and use cases

diagrams make communication within and among project teams possible. The same means

allow also communication between a designer/analyst and a customer. They also make it

possible to document results of phases: analysis, design and implementation.

In any information project, it is possible to distinguish three general forms of a conceptual

model [Subieta98]:

Mental model of real world defines a subject of information system. This model,

representing domain knowledge, is seldom formalized. It should include whole

knowledge about a given institution, organization, or company and about scopes and

aspects of their activities, which is necessary to comprehend functions fulfilled by the

information system.

Abstract conceptual model defined by means of proper formal or semiformal notation

(e.g. class diagrams). It usually represents only some part of domain knowledge;

Conceptual model of data structures for making basis of the information system (e.g.

relational schema written down in SQL).

Each of these models plays a certain role in the software development. Mental model of

real world is necessary to understand: what for are the data and what significance has

processing of these data. The aspects of domain knowledge, which are important for an

information system under development, are described by an abstract conceptual model. At

last, during programming works, a schema of data structures is necessary in order to

understand correctly their structure, organization, manners of data processing, etc.

The following consistencies relate to conceptual modeling of a given programming

venture:


12/172

12

Consistency between a mental model of real world and an abstract conceptual model of

this world described with the aid of a given formal language;

Consistency between a conceptual model and schema of data structures, expressed by

programming language type (or class) system and/or expressed by schema description

language (data description language) supported by a given database management

system.

The consistencies mentioned above mean that the differences between thinking about the

real world, comprehension of abstract conceptual model, and understanding of stored data

structures should be as small as possible. Minimization of these differences is crucial for

many phases of software developments life cycle and it is conducive to its high quality and

modifiability.

Aspirations for achieving these consistencies is the driving force behind the developmentof semantic data models and the introduction of some elements of these models (also object-

oriented) as programming language and DBMS features. Since both a mental model of real

world and its abstract conceptual model do not include elements related to computer

environment, aspirations for obtaining the foregoing consistencies lead to increasing an

abstraction level, and independence between data and programs too. This process makes that

designers, programmers, and users are gradually disengaged from taking some elements of

system environment into consideration.

On the other hand, one can consider the tendency mentioned above as a factor, slowingdown the development and the applications of conceptual modeling tools. Assuming

constraints on data structures and other features of certain programming language and DBMS,

many differences between conceptual models and data structure schemata cause more

difficulties in understanding of data semantics as well as goals and manners of processing

them. Thus, one may question the point in introducing those tools to conceptual schema,

which cannot be directly mapped onto properties of data structures within certain realization

base. The tendency to enrich conceptual modeling tools with more and more new concepts

encounters a poorly perceptible barrier related to an excessive complexity of representation

and differences between the conceptual schema and the implemented data structure.

It is worth a notice that relational model is not capable of representing some features of

the conceptual model in a direct way (such as e.g. inheritance hierarchy, multi-valued or

compound attributes, and many-to-many relationships). That for many projects can destroy in

effect a direct connection between abstract conceptual model and data structures. Both more


13/172

13

flexibility and accidentalness of choices made by designers and programmers during

realization of system and more complex understanding of developed data structures cause

many disadvantages in software quality.

Increasing consistency between abstract model of system domain knowledge and its

concrete realization in the form of implemented data structures and programs is a fundamentalgoal of object-orientedness. It has important consequences for many aspects of developing

information systems, including speed and cost of their constructing as well as quality,

reliability, openness, modifiability, modularity, portability and possibility for reuse.

2.2. Notions of Object-Oriented ConceptualModeling

Growing complexity of information systems applications has resulted in new demands to the

conceptual modeling of business domains, databases and application programs. The

conceptual modeling is supported by various formal or semiformal notations such as class,

functional, use case, dynamic and other diagrams. Mapping a piece of reality into a

conceptual model requires notions, which follow natural ways of human thinking and

understanding, and, on the implementation level, should be easily mapped into data and

programming abstractions.

Object-oriented conceptual modeling notions are supported in programming languages by

proper data structures and behavioral properties defined on the algorithmic level of semantic

precision. A long-term tendency in the development of programming languages and database

management systems is that (usually semi-formal) conceptual modeling notions after some

time are becoming data and programming abstractions. Object databases are an illustration of

the thesis. Considering the entity-relationship model as a tool for conceptual modeling of

relational databases, we observe that many of its notions (such as entities/classes,

relationships, inheritance, and others) are further materialized as constructs of database

structures, query languages and programming languages.

Despite a large collection of various conceptual modeling facilities it is still difficult to

model directly and precisely some typical situations in the business reality. An example is the

concept of multiple inheritance, which supports conceptual modeling, but leads to various

semantic anomalies. Inaccurate modeling causes communication difficulties between projects


14/172

14

members, increases the probability of errors, causes additional consumption of resources

during system construction, and has negative impact on the code length, documentation,

transparency, maintainability and reliability of software. Thus conceptual modeling facilities

should contain all necessary notions which allow the analyst and designer to express their

design vision as precisely as possible.On the other hand, excessive extension of conceptual modeling notions may cause

difficulties concerning their learning and proper use by project members. Thus there is an

opposite tendency to minimize the number of notions and express new notions in terms of

known notions. For instance, some methodologies do not deal with aggregation considering it

a special case of association; some others do not involve inheritance assuming it can be

expressed otherwise, etc. Another disadvantage of a large number of conceptual modeling

notions is their inherent semi-formal semantics (they enhance humans thinking rather than

computer operation), which could cause difficulties in recognizing proper usage of the notions

and semantics of their particular combinations.

The tendency to extend conceptual modeling notions is also reduced by implementation

environments. If some conceptual notion has no direct counterpart on the implementation

side, then it hast to be mapped into other implementation notions; thus, the original idea of the

analyst/designer is misshapen. In consequence, there is little motivation to use those notions,

which have no direct counterparts in implementation. For example, because relational

databases do not support inheritance directly, the corresponding analysis and design

methodologies (except a few) avoid this concept.

In our opinion, the dynamic object roles are useful for both conceptual modeling and

implementation. The low popularity of the notion is caused by the already established object-

oriented principles, especially in programming languages. The basic assumption is that

objects conform to the substitutability principle (LSP), which seems to be very natural, but on

the other hand leads to anomalies, which are evident in case of multiple, multiple-aspect

and/or repeating inheritance. Another assumption, which impedes the popularity of dynamic

roles, is strong static (polymorphic) typing, which in case of roles must be much relaxed or

redesigned. We will try to convince the reader that both mentioned impediments of wide

usage of roles can be avoided.


15/172

15

3.Inconveniences of Multiple InheritanceMultiple inheritance is one of conceptual modeling mechanisms in object-orientedness, which

has been applied with varying success. This section introduces the discussion on multiple

inheritance, and presents advantages and disadvantages of the concept. For clarity, the

presentation is made in an informal manner, apart from needless theoretic and technical

details, and in favor of general intuitions. The approach is supposed to bring closer the

essence of difficulties, which are related to the formulation and applications of multiple

inheritance in conceptual modeling and in widely-known object-oriented programming

languages. A careful look at mechanism of multiple inheritance is essential for

comprehension of role concept.

3.1. The Concepts of Class and InheritanceThe concept of class represents a certain abstraction in thinking and programming. This

notion is supposed to capture static properties of objects (their structures) and their behavioral

specifications, including operations, which can be performed for a given object group. In this

study, a class is treated as a place, storing invariants, shared properties, and those properties,which are connected with the whole population of objects. Among others, one can include the

following properties: attributes methods, class names, interfaces, common and default values,

relationships with objects of other classes (associations).

The concept of inheritance is one of fundamental mainstays of object-orientedness. This

concept describes a relationship between classes, in which:

Properties1of a certain class can be accessed within a given class, which is related to a

certain class by inheritance relation;

Properties, which are available through inheritance, are called as inherited properties;

1It may concern only some properties of a given class; for instance, most often a class name

is not inherited.


16/172

16

Person

name

birth_year

age()

Student

semester

album_no

insert_mark( mark )

avg_mark()

Person

name

birth_year

age()

Student

semester

album_no

insert_mark( mark )

avg_mark()

Fig. 3.1An example of inheritance

A class, from which properties are inherited, is called a superclass (a more general class,

a parent class), and a class, which is extended by inherited properties, is called a

subclass (a more specific class, a child class).

A relation of inheritance is a partially ordered relation that organizes classes into a hierarchy

(see Fig. 3.1). A class hierarchy is most often a tree, having one common root. Classes, which

are nodes of tree of hierarchy, possess (inherit) properties from more general classes within

this tree, as far as from its root. In case of multiple inheritance, which is further discussed, a

hierarchy structure is more general and it becomes a lattice.

Person class

Employee class

inheritance

Person class

Person

instance

generalization membership availability

Person class

Employee class

inheritance

Person class

Person

instance

generalization membership availability

Fig. 3.2Inheritance and availability

In object-oriented studies the distinction between structural inheritance and behavioral

inheritance is drawn. In structural inheritance2, subclasses inherit a whole structure from their

superclass, i.e. attribute and method specifications, as well as their type (and signature)

specifications. The structure of such a subclass should not be visible to other classes.

Structural inheritance does not support substitutability principle (discussed in Chapter 3.4).

2It is also called implementationinheritance orprivate inheritance.


17/172

17

However, behavioral inheritance involves a semantic use of generalization. It is important and

meaningful in a conceptual model. A presented distinction does not concern other aspects of

inheritance and further features that can be a subject of inheritance (e.g. class extension).

Karowska

01/01/1963

-age()

2460chgSalary( newSalary )

avgSalary( year )

Smith

12/03/1956

6498237

age()Warsaw Uniwersity

3236457

850

chgScholarship( NewRate )

Person

name

birth_date

tel_no.

Employee

salary

Student

university

album_no.

scholarship

age()

chgScholarship( newRate )

chgSalary( newSalary )

avgSalary( year )

Smith

12/03/1956

6498237

McDuck

02/16/1975

2357673age()

Jagiellonian University

3234434

0


Karowska

01/01/1963

-age()

2460chgSalary( newSalary )

avgSalary( year )

Smith

12/03/1956

6498237

age()Warsaw Uniwersity

3236457

850


Person

name

birth_date

tel_no.

Employee

salary

Student

university

album_no.

scholarship

age()

chgScholarship( newRate )

chgSalary( newSalary )

avgSalary( year )

Smith

12/03/1956

6498237

McDuck

02/16/1975

2357673age()

Jagiellonian University

3234434

0


Fig. 3.3An example of class diagram with objects

Availability of properties, another relationship, is determined by class membership of

objects. This relationship, defined between a class and its member (an instance), makes

properties of a given class (perhaps not all) available within its instances. The concept of

availability, sometimes occurring erroneously in the studies as inheritance, should be clearly

distinguished from inheritance; see Fig. 3.2. Further in this work, availability will be

sometimes considered as one of inheritance features, but these concepts will not be identified

with each other. An application of inheritance and availableness means that objects, which are

instances of a given subclass, possess both properties of this subclass, as well as properties of

its superclass (or superclasses), e.g., as attributes or methods. Fig. 3.3 presents a simple class

hierarchy and exemplary instances of classes. Attributes and methods, which are inherited by

Student and Employee classes or which are available within instances of these classes, are

enclosed by dashed-line ellipse, as distinct from properties, which are own attributes andmethods of StudentorEmployeeclasses.

In conceptual modeling and in object-oriented programming languages, one can use the

mechanism of inheritance:

For defining a new, more specific class on the basis of another class;


18/172

18

For creation of more general class (often this class is an abstract one) for several specific

classes, enclosing their common properties (before parenthesis).

3.2. The Concept of Multiple InheritanceDuring the conceptual modeling of even a small system it may occur that some groups of

objects should get properties of different natures. Generally, one can distinguish two cases. In

the themselves, the first one assumes, that two (or more) object natures usually manifest in the

same time when in the second one, the ambivalence of objects is strictly related to a specific

Person

first name

last namedate_of_birthaddressinsurance_no.email

getMessages()

Student

index_no.emailscholarship

getMessages()

Employee

date_of_employmentsalaryemail

getMessages()

Working Student

school_hours

Person

first name

last namedate_of_birthaddressinsurance_no.email

getMessages()

Student

index_no.emailscholarship

getMessages()

Employee

date_of_employmentsalaryemail

getMessages()

Working Student

school_hours

Fig. 3.4An example of class diagram with multiple inheritance (in UML3)

period. An object at some moment manifests properties of a given nature, but later it can

manifest other properties, which are properties of different nature. A simple example is

depicted in Fig. 3.4. Working Student class inherits both properties of Student class and

properties of Employee class. There is defined a multiple inheritance between Working

Studentclass and Student, Employeeclasses. StudentandEmployeeclasses are not related by

inheritance relation; therefore they represent object categories with different behavior. It

3Unified Modeling Language


19/172


20/172


21/172

21

i2? The problem mentioned is an example of difficult object-orientedness issues, related

to notions such as compound object content, object migration and schema evolution.

Those concepts will be discussed in the next sections of this work.

3.3. Multiple ClassificationIn many object-oriented languages, an object has one direct class. However, there is no

necessity to support that restriction; we typically look at real-world objects from many

viewpoints simultaneously.Multiple classificationis a special kind of generalization in which

an object may belong directly to more than one class. An example of class diagram with

multiple classification, so-called multiple-aspect inheritance, is depicted in Fig. 3.7.

Although multiple classification matches logic and everyday discourse well, it complicates

implementation of a programming language and is not supported by the popular programming

languages([UML01], p. 345).

Female

Male

Person

Manager

Engineer

Salesman

Sex Job

Fig. 3.7An example of multiple-aspect inheritance in UML.

3.4. Types and Substitutability3.4.1. The Concept of TypeA type is a linguistic expression or certain semantical structure which can be assigned to a

variable, an expression or another programming being (value, object, function, procedure,

operation, method, method parameter, module, ADT5, exception, event). It specifies either a

kind of values which can be assumed by this being or it specifies external properties

(interface) (e.g. for a procedure, a function, an operation or a method). On the one hand, a

5Abstract Data Type


22/172

22

type is a formal constraint, imposed on a structure of programming being (or on its parameters

and its result). On the other hand, it is a formal restriction of context, in which it can be

called/accessed while a program is executed.

Types are useful in the conceptual modeling, because a type name of a given data carries

information about meaning (semantics) of certain data. For example, date type or Persontypebrings connotations from the external world; because of that, types improve the readability of

programs.

A type concept is, in fact, orthogonal to the object-orientedness, e.g. well-known object

language Smalltalk does not possess types and it has a limited ability of type checking

(characterized as dynamic checking). However, many of studies and languages (Java, C++,

and Eiffel) treat a type notion as a basic system feature, with respect to connections with a

class notion. Sometimes, it is considered incorrectly that the type and the class mean the

same. It partly results from the fact that in many famous object-oriented languages, e.g. in

C++, a class name is simultaneously used as a type name too. However, treating the notions

of class and type seems to arise from oversimplification or incomprehension of this problem.

An object type can be one of the invariants stored in the class (not mandatory), but the class

can store many other invariants and features (such as constraints, exceptions), which are

irrelevant to the type concept.

In others studies, one considers a class as a definition of objects (object group), while

types are definitions of values. This kind of distinction seems controversial too. In those

studies, classes and types are often distinguished according to the principle: a class is an

implementation of a type. Thus, a type is there responsible for the external specification of a

class, while a class holds all implementational details, including method bodies. This

definition can be found as correct one in many object-oriented conceptions and languages.

Unfortunately, object-oriented models, which are used in most object database management

systems (e.g. ODMG standard), violate the above-mentioned connection between types and

classes. For example, in case of multiple inheritance, an object type is composed of two or

more class types. What is its implementation in this case? Types can be defined recursively,

but this kind of definition is unhelpful for classes. Also models, which assume that one object

has many types at the same time, according to the inheritance hierarchy (e.g. ODMG

standard), disagree with dealing with classes as type implementations.

Because of various ways of comprehension of types and classes, of misunderstandings

about these concepts, and of different expectations for their significance in languages and in


23/172

23

whole systems, it is very difficult to provide a coherent model, allowing a simple explanation

of these notions and their mutual relation.

3.4.2. Subtypes and SubstitutabilityThere exist two somewhat different subtype definitions. First one is based on a concept of

set inclusion: T1type is a subtype of T2type, if a set of values defined by T1is enclosed in a

set of values defined by T2. For instance, the natural number type is a subtype of the integer

type. Second one, a more important definition, is based on another dependence: T1type is a

subtype of T2type, if T1contains more attributes (operations, methods, etc.) than T2type. For

example, the type

typedef EmployeeType = struct { string name, int year_of_birth,

intsalary}

is a subtype of the type

typedefPersonType = struct{ stringname, intyear_of_birth }.

The definition of a type is supposed to be consistent with the class hierarchy:

EmployeeTypecan concernEmployee objects, while PersonType Personobjects.Employee

class is a subclass of Personclass.Defining subtype relation tends towards the substitutability

concept. The substitutability consists in the fact that in every place of a program (context),

where a given being of T type can be used, a being of a type, which is a subtype of T type,

can be used there too.

For instance, wherever an integer can be used, a natural number can be used there too;

wherever a Person object can be used, an Employee object can be used there too. Since a

subtype has more attributes than its supertype, the substitutability means that every attribute,

which protrudes an expected type, is ignored. For example, a program can contain:

PersonType p, p1; EmployeeType e; //Declarations of p, p1, e

variables

p := (name: White, year_of_birth: 1960);

e := (name: Brown, year_of_birth: 1950, Salary: 3000);

p1 := p;

p1 := e; // use of substitutability


24/172

24

Subtyping, substitutability, covariance and contravariance [Subieta98] conduct to certain

anomalies connected with the substitution process. In this work, we do not discuss this issue

in detail; however, the further presented role concept will allow avoiding the use of the

substitutability and anomalies related to this notion.

3.5. Well-Known Programming Languages andMultiple Inheritance

At the design stage, one has to make several important decisions, related to the system under

construction. Among other things, one chooses a database management system (DBMS),

definition and manipulation data languages (DDL, DML). In the development of databases,

lasted since the mid-sixties, many programming languages have been created, which have

been mostly used in the academic environment, but some of them have been used in

commercial environment too. Various language philosophies are represented also, which

differ in attitude to multiple inheritance. Many languages knowingly avoid supporting

multiple inheritance. Some languages introduce mechanisms of multiple inheritance, but to a

different extent. In this section, several well-known programming languages will be briefly

presented in the context of multiple inheritance.

3.5.1. SmalltalkThis object-oriented programming language was constructed in 1976-83 years at Xerox Palo

Alto Research Center in California. It introduces such notions as class, subclass, dynamic

binding for methods, message passing, metaclasses. Its main principle consists in the fact that

everything is an object (e.g. classes, literals, and constant values). Smalltalk is not capable of

specifying subclasses of more than just one class. Lack of multiple inheritance, simplicity,

and possibility to quick dynamic modifications cause that Smalltalk has become a tool often

used for rapid development of prototypes.

3.5.2. Modula-3Modula-3 is an object-oriented successor of Modula-2, which does not include problematic

features of other object-oriented programming languages as, e.g., multiple inheritance.


25/172

25

3.5.3. EiffelIt is an object-oriented programming language, which has been introduced and developed by

Bertrand Meyer. It includes classes, abstract classes (deferred classes), parametric classes,

class clusters, and multiple inheritance. Objects can be typed statically or dynamically.

In Eiffel, name conflicts occur, when two or more properties with the same name are inherited

from different classes:

classCLASS_A

featuredata: REAL;

end;

classCLASS_B

featuredata: INTEGER;

end;

classCLASS_C

inherit CLASS_A;

CLASS_B // Error

end;

end

To avoid name conflicts, one can specify (by selection mechanism), which properties are

inherited from a given class:

classCLASS_C1

inherit

A selectdata;

B;

end;

end;

classCLASS_C2

inherit

A;

B selectdata;

end;

end;


26/172

26

When there is a necessity to inherit more than one property with the same name from different

classes, then one can make use of rename mechanism for some inherited properties:

classWorking_Student

inherit Student

renameno_tel asno_tel_university Employee;

end;

feature

hours_schol: INTEGER;

...

end;

3.5.4. C++C++ has been constructed as an extension of C language with classes, subclasses, abstract and

parametric classes, and virtual methods. It combines functionality of high-level language with

elements of an assembly language (pointer arithmetic). C++ supports multiple inheritance.

When properties with the same name are inherited from different classes, then to avoid name

conflicts, these properties must be qualified by class name where they are defined.

3.5.5. O2An object-oriented language and DBMS with the same name have been developed by O2

Technology in France. It supports multiple inheritance. An inherited attribute name can be

locally renamed in a given class.

3.5.6. JavaThis language has been developed by Sun Microsystem. It combines features of C++,

Smalltalk, and Objective-C languages. Java is a high-level object-oriented language, which

was supposed to substitute C++ language, considered as too extensive and getting out of clear

rules. Java does not support, inter alia, controversial pointer arithmetic, and does not support


27/172

27

multiple inheritance in the sense of multiple inheritance of implementation, because a class in

Java can have at most just one superclass. However, it is possible in Java to specify interfaces

of a given class, which are repeatedly inherited by interfaces, defined for subclasses of this

class. Some researchers consider it as multiple inheritance of interfaces. Abstract methods and

constants can be specified within an interface, which are visible by accessing a given class viathis interface. Many interfaces may be defined for a given class. Since interfaces are subject to

inheritance, class specializations inherit all interfaces, defined within classes that are more

general.

3.5.7. General ObservationsFounders of languages which do not support multiple inheritance consider that only single

inheritance has a simple and smart form, which is soundly specified and commonlycomprehensible. They treat languages with multiple inheritance as inelegant [Joyner96]. Such

a situation has been presented in BETA: Beta does not have multiple inheritance, due to the

lack of a profound theoretical understanding, and also because the current proposals seem

technically very complicated [MMN93]. Similarly, Modula-3, Ada95, and Java are

languages without multiple inheritance. Some other researchers perceive that multiple

inheritance is a notion which helps to solve some problems in conceptual modeling; thus, they

claim the necessity to specify features of this notion, even if it requires very extensive further

research. Although a list of difficulties, which appear by multiple inheritance, seems to be

incomplete up to this day, some classes of identified problems can be solved in an automatic

manner.

3.6. Multiple Inheritance in the Object-OrientedMethodologies and Notations

Most of object-oriented analysis and design methodologies and object-oriented notations of

conceptual models introduce the multiple inheritance as a basic feature, e.g. OMT6, UML.

Their authors argue that the absence of the multiple inheritance in programming tools must

cause a disadvantageous gap between the conceptual model and the implementational model.

6Object Modeling Technique


28/172

28

Unfortunately, semantics of multiple inheritance is not fully specified in methodologies and

notations which only recommend (or order) avoiding name conflicts through the use of

unique method name in the proper classes or suggest evading multiple inheritance by means

of class permutations (or by means of the delegation mechanism, which is semantically

unclear too7

) [UML97]. Fig. 3.4 presents an instance of a class hierarchy with the multipleinheritance and with name conflicts, in UML notation.

3.7. Multiple-Inheritance ProblemsThe construction of information systems cannot be made by ad hoc design. Before the

implementational tasks can start, a project must pass, i.a., requirement specification and

analysis phases. Works in every phase are supported by various tools. Their results are written

down with different notations. Therefore, transfer of results from one phase into another is

connected with making compromise decisions are often incoherent. They deform some

elements of the initial project. Multiple inheritance belongs to these difficult issues. Although

the multiple inheritance concept is undertaken by all who have interest in object-orientedness,

and especially in object programming languages, a uniform approach has not been developed

so far. Studies making attempts to discuss this subject are usually concerned with only

particular solutions in a given programming language.

The concept of multiple inheritance is well-intelligible at the stage of mentalrepresentation of real world, but it causes much controversy during the further works on the

information system. Some of such controversies are caused by the lack of adaptation of given

programming language to define and to manipulate class hierarchies supporting multiple

inheritance. Others are caused by incompetence of designers and programmers, who easy get

into semantic traps, set by the implementation of the multiple inheritance in various

programming languages.

3.7.1. Semantical Context and Multiple InheritanceLet us assume that an information system on students is created, which includes also

information about their employment, if they work while they study. Fig. 3.4 presents a class

7The delegation (in UML) represents a situation; if an object after receiving a message sends

it to another object and it delegates an interpretation of a given message to another object.


29/172

29

diagram with multiple inheritance, where Working Student class is a specialization of Student

and Employee classes. Working Student class defines school_hours, specifying weekly

number of hours, when an employee is released from the work to help him continue the

studies. It is assumed that the value of school_hoursattribute is related to the kind of studies

as well as to the amount of working time (full time, part time). Working Studentclass inheritsall attributes from Studentclass and fromEmployeeclass. Only this information is expressed

by the notation (in this case: UML). It is fixed by the notation that all (inherited) attributes are

inherited in the same way. They are merged in the common environment of Working Student

class. The notation does not specify more of the semantics of multiple inheritance. As a result,

attributes of different classes, coexist side by side. They are mixed in the new common

semantical space, partially loosing the information about their initial environments. From the

conceptual modeling point of view, the degeneration of abstraction levels, the commonality of

space scopes, or the weakness of bonds among beings, which were strongly related to each

other, are negative phenomena. A clear and precisely defined semantics of the system

components has grown in importance, especially in the face of necessity for continuous

systems increase, i.e. with the use of reverse engineering methods (e.g., through the reuse).

Local environments, determined by StudentandEmployeeclasses, are mixed in objects of

Working Studentclass. However, the execution of inherited method or the plucking of values

from inherited attributes is delegated to classes, which define these properties. Lack of

operational semantics of the multiple inheritance at the stage of conceptual modeling leads to

a gap between the system design (created at this stage) and its implementation in the specific

programming language. Quite a lot of free choice with the solutions results from different

understanding and application of the multiple inheritance mechanisms by programmers.

The combination of various semantic properties can sometimes lead to mistaken

conclusions. Fig. 3.4 can serve an example. GetMessagesmethods get new messages. The

semantics of these methods seems to be clear and natural in all classes, except Working

Studentclass, which multiply inherits from both StudentandEmployeeclasses. The working

students possess two (or three) email accounts. First account is a school account, the second

one is an account at the workplace (and third one is a personal account). It is hard to find an

example, whether a given person should be treated as a student, as an employee, and as a

regular person at the same time. Thus, there is no doubt in most cases that ambiguity of

representation of a given person should not be considered, especially to specify his most

relevant email address. It should be stated, without questioning legitimacy of multiple

inheritance that problems mentioned may lead to changes or at least to semantic obscurities. It


30/172

30

concerns particularly such cases when one must stress the ambiguity (e.g. duality) of

semantics of a given object group through the multiple inheritance. Their different semantics

are not manifesting never or almost never at the same time, because they are mutually

exclusive. A class hierarchy with the multiple inheritance (lattice) seems to be too fixed

construction for defining objects with the changeable nature. It is all the more important indatabases, considering usually long time periods of stored data and requirements in the

preserving of high flexibility, i.a., considering rather quickly varying needs of users.

3.7.2. Human FactorUp to this day, the issue of multiple inheritance concept has not reached any coherent and

general solution. Therefore, the understanding and application of this notion can cause many

problems, especially in languages, in which multiple inheritance is only one of thesupplementary features. Problems that arise may concern matters of different nature, e.g.:

Not sufficient general acquaintance of authors of information system with the multiple

inheritance concept;

Lack of enough skill in correct identification of cases, for which solutions can take

advantage of the multiple inheritance mechanism;

The choice of proper programming language and consistent translation of conceptual

schema components into adequate logical schema constructions, including the choice of

programming language without multiple inheritance;

How to arrange the works for takeover or continuation by persons until now have not

been involved in the project or in a part of it?

How a dedicated (specialized) company should be instructed in connection with

constructing some functions?

How to ensure proper understanding of semantics of other languages, which is essential

during the creation or further life of the information system8;

8 It concerns especially the works performing the extension of an existing system to new

features by using of reengineering methods and new rapid application development systems

(RAD).


31/172

31

What are the necessary modifications of the system, related to changes of some vital

system requirements?

Each of the given examples requires a systematic approach in defining various methods,

which can be applied to remedy difficulties that arise. To this end, it is necessary to have a

coherent and consistent approach to issues related to multiple inheritance, by many people,

with different profiles and experiences. Lack of rule and recipe in this area leads to using

divergent methods. They are the cause of errors and incoherencies in the system. Usually, this

kind of errors is very laborious to correct. If these errors are made at initial stage of the

systems life (e.g. in the analysis stage), they then determine the further form of the project

completely, because their correction or improvement are too expensive. It often leads strange

constructions within the system, which are difficult to understand and can cause other

mistakes.

3.7.3. The Name ConflictA substantial problem of multiple inheritance is the inheritance of properties with the same

name from different classes. An example is presented in Fig. 3.4. Working Student class

inherits multiply from Student class and from Employee class. A doubt arises: in what way

emailattribute will be inherited from Student classand the attribute with the same name from

Employeeclass? It is unclear too, which of these attributes should be used by the getMessages

method. The situation discussed is known as a name conflict. The arbitration methods are

often seen by opponents of multiple inheritance as an example of pathologies that occur in

understanding this concept.

In typical programming languages (structural languages), the execution of program block,

in which a name conflict appears, either ends by the error signalization or proceeds by using

binding priority rules for multiple inheritance9, which are fixed in a given language. Priority

rules are usually defined through syntactic ordering of super classes, which are used in a

program block or by assigning an inheritance priority for super classes of a given class.

Although both solutions seem to be sufficient for most occurrences of name conflicts, the use

of them leads to much harder readability of the program, and they are also inflexible against

small semantic changes (e.g. in reversing of the priority order) of this mechanism. It may

cause errors, which are unforeseen and difficult to identify. For example, the use of different

9It may be possible, e.g., by using of the dynamic binding.


32/172

32

visual code generators can lead to creation of program codes with different appearance

sequences of super classes.

Orion [BCGKWB87] and CLOS10are instances of systems supporting the arbitration of

name conflicts, based on super class sequence in the program code. If one assumes that there

are defined methods in classes AandBwith the same name m, and Cclass multiple inheritsfromAandBclasses (defined in the code in given order), then a call for m method means the

use of mmethod defined inA class, for all objects, they are members of Cclass.

Usually, languages supporting multiple inheritance do not possess built-in priority rules

for the multiple inheritance. Then it remains only to avoid name conflicts. It may be supported

by additional mechanisms in the language, during the construction of the code (e.g. in C++) or

by a proper construction of classes (e.g. in Eiffel). Detailed methods, how to solve name

conflicts, are:

Local renaming (change) of inherited property in a given subclass O2, Eiffel. It is an

effective solution, even if it leads to some inconsistency in scope of the inheritance

concept. Advantages of renaming are a possibility of inheritance of all properties with

certain common name, and manifesting in some features of another mechanism which is

known as import of properties with renaming;

A limitation of scope for inherited properties a selection mechanism for the

inheritance in Eiffel. Through selection are pointed properties, which should be

primarily inherited. The selection mechanism concerns only these properties, which areexplicitly pointed and all others (potential) properties are rejected during inheritance.

A specification (in case of name conflict) of a class qualifier in all (or some) places,

wherever inherited properties are used C++. This method is much more laborious than

for example local renaming applied in Eiffel, because it forces using the class qualifier

(with scope operator ::) for every instance of a given name in the program code. It

significantly decreases flexibility of changes in the program (particularly in class

definitions) and increases probability that programmers can make mistakes during reuse

of class definition to specify another class with similar properties.

Possibility to rename properties in one or more superclasses can be obviously applied in

all languages. Though this solution seems to be trivial, it may be very inconvenient or

even impossible. Unfortunately, a source code including class definitions may be often

10Common Lisp Object System


33/172

33

unavailable. It is worth a notice that the automatic or semiautomatic renaming is a

solution that causes much waste of time by many programmers, searching for errors in

the incorrectly working program.

B

C

E

D

Fig. 3.8Different inheritance paths

A dilemma of another general phenomenon another phenomenon dilemma is related to a

problem of inheritance paths choice (Fig. 3.8). It is particularly important for inheritance of

the methods, which are defined and called in a specific environment. Let us assume that a

given method is defined in Bclass and called from an instance ofE class. A question arises,

whether the execution of the method is dependent on chosen inheritance path, BCE orBDE?

Generally, authors argue that in both cases a method should be executed in the same way.

They are not sure however whether it takes place in all well-known languages.

The original sin of all presented methods is their strong connection with a specific

programming language. Lack of setting more uniform rules increases an aversion to apply

them by the wider group of users. The semantics of priority arrangement constructions and

avoiding name conflicts are often too complicated. Therefore, their applications should be

recognized as relatively difficult. Moreover, the researches in program portability and in reuse

require much expenditure of work, more advanced knowledge and experience.

3.7.4. Typological ProblemsSubstantial problems arise when considering multiple inheritance from the point of view of

type theory. It is not easy to create a type system which could meet simultaneously simplicity

(for a user) criterion, conceptual cohesion and universality. Existing ideas in this field are not

satisfying or are very complicated. Solutions such as in C++ are a subject of common

criticism. As another potential problem, which arises in multiple inheritance, an object

representation can be seen. In many systems, to save the memory, an attribute value has a

fixed offset, relative to the beginning of the object representation. If these relative attribute


34/172

34

positions are fixed for both Student andEmployee classes, then it cannot be possibly fit them

with adequate positions of Working Students attributes. It leads to the necessity of using

solutions that are more complex (e.g. in C++). This complicates the semantics of a language

from the point of view of programmers. It can also cause errors in the software and can

increase time of execution.

3.7.5. The Multiple Inheritance and Object MigrationIn typical general programming languages, a class structure usually is unchangeable all the

time or for a long time during systems life. In many languages, classes do not exist during

the program execution11(e.g. in C++). Most often, a modification of a class structure during

the program execution is not possible, even if classes are first-category citizenship beings12.

Generally, in object-oriented systems, and particularly in object-oriented databasemanagement systems, one assumes classes (and types) are first-category citizenship beings.

This means that a class definition exists not only at program analysis stage, but it is also

programming object. It has own localization in the computer address space, and it is

(theoretically or practically) a subject of manipulations during the execution. Addition of a

new method or attribute for a given class, a modification of security rules for instances of this

class, and a modification of constraints on these instances belong to such manipulations

(especially those often performed).

Citizenship of a given programming concept can often be a little fuzzy. This takes place in

a given language or system if a certain concept is postulated as second-category, but it exist in

the executing time, and/or there is a possibility to perform on it some (usually limited)

operations. For example, some languages make it possible to use type_of operator. This

11The second-category citizenship being is characterizing a programming language concept,

existing only in the program code (used at static analysis stage). These being are unavailable

during the program execution, e.g., a variable name, a parameter name, a type, a class, a

procedure signature.

12The first-category citizenship being is characterizing a programming language concept (e.g.

a type, a class, a module, a variable value, and a variable name), meaning, that a given

programming being occurs and can be manipulated (changed, deleted, and created) during the

program execution. For an instance, an attribute value is a first-category citizenship being, but

an attribute name usually is a second-category citizenship being.


35/172

35

operator returns for given programming beings (e.g. for objects) their actual type in the form

of string or reference to certain structure. This means that the type information exists and is

available during the run time. This kind of fuzzy citizenship of class is e.g. a standard feature

of ODMG and Objective-C13. It is often submitted to a critical examination by experts in type

theory who emphasize that in this way effectiveness of the strong type checking is powerfullyrestricted. Moreover, like in case of the shifting of concepts into first-category citizenship

concepts, also the fuzzy citizenship can result in the worst executing time.

Java language is an instance of another situation. Classes in Java are static beings.

However, their dynamic representations exist in the program run time, in the form of special

objects, representing classes. For an object representing certain class, it is possible to execute

some operations. This simulates the class behavior in Java (in certain cases) as first-category

citizenship beings14.

13For example objc_getClass(STR)construction in Objective-C.

14For example Class.forName(String)construction.


36/172

36

4.Well-Known Approaches to DynamicObject Roles

The idea of dynamically changing object roles was proposed for the network database model

by Bachman and Daya in 1977 [BD77], far earlier than object-oriented methodologies and

tools were popularized. During the era of the relational model and relational systems the

concept was not considered in the context of databases because it did not fit well with the

relational ideology. Thus for many years the idea was forgotten. The interest to dynamic

object roles has increased after computer professionals have realized the meaning of

conceptual modeling in software construction. In effect, object-orientedness has been

popularized in various domains of information technology, and together with object-

orientedness, the role concept is considered more and more frequently.

The dynamic role concept often appears in papers devoted to object design, programming

languages and databases, sometimes under other names, in different contexts and with various

semantics. The classical object-oriented model assumes that each object is associated with its

most specific class. A deviation from this rule can be treated as a certain variant of the role

concept. In particular, the Iris system [Fishman87] supports many types for a single object. A

similar proposal can be found in [BG95]. The dynamic role notion appears in different

contexts, in particular, in papers related to modeling office information systems [Pernici90],

computer aided manufacturing [WL94, WL95], workflow management [KRR00], multimedia

[WCL96b, Wong99], semantic modeling [RS91, Sciore89, Stein87], and object modeling

[Papazoglou91]. These papers propose to take advantage of dynamic roles for various

dynamic properties, such as object migration, schema evolution, conceptual object clustering,

creation of several views for one object, and others.

Recently new proposals to deal with roles have appeared. They can be subdivided into

two groups. The first of them assumes that dynamic object roles are represented informally

through the already existing notions of the conceptual modeling by using design patterns

[K96, BRSW00, Fowler97, GHJV95, RG98], which have been popularized in the context of

object-orientedness. The design pattern decorator[GHJV95] is considered in [Fowler97] as a


37/172

37

good mapping of dynamic roles. The decorator pattern allows one to insert additional

functionality to a class without subclassing. This approach corresponds (to some extent) to

Aspect-Oriented Programming [KLMM+97] and the separation of concerns principle

[Dijkstra76]. Also the motivation for Subject-Oriented Programming presented in [HO93]

shows that dynamic roles and SOP have conceptual similarities. The second approachintroduces the role concept as an explicit notion of conceptual modeling and a database

feature orthogonal to other features. Such an approach has been implemented in Aspects

[RS91] and Fibonacci [ABGO93, AGO95, AAG00] prototypes. A feature called subtable,

having some correspondence to roles, is introduced in the emerging standards SQL3 and

SQL1999 [ANSI99] for object-relational systems.

In Fibonacci it is assumed that a role does not have its own behavior. The support for

contextual object behavior was introduced first time in the Clovers system [SZ89], in the

proposal presented in [WJ89], in Multiple View in the Smalltalk context [GSR96], in the

ORM model [SN88], and in Aspects [RS91]. In these approaches, however, the roles do not

possess their own classes and they do not support inheritance among roles. There is also no

possibility to move a role from an object to another one (what could be essential for some

applications, e.g. a project managerrole can be moved to another person). The proposals do

not define operators, which support the programmer to switch dynamically from one object

role to another one.

The proposals can be essentially distinguished depending on their attitude to strong static

typing and depending on whether introduced classes have first-class or second-class

citizenship. In [Sciore89] classes are first-class citizens (so-called prototypes). ORM [SN88]

is a similar proposal, but classes have the second-class citizenship. On one hand, for

performance reasons, in commercial programming languages it is usually assumed that

classes have the second-class citizenship, which enables static binding of program entities. On

the other hand, the first-class citizenship of classes supports flexibility and robustness. For

this reason, in database systems many program entities have the first-class citizenship, in

particular, database procedures, views and triggers. Some systems, e.g. Oracle-8, assume also

classes and methods to be first-class citizens stored on the side of a database server rather than

on the side of a client application.

An essential aspect of roles concerns a method lookup strategy after receiving a message

by an object. In Fibonacci, DOOR [WCL96a, WCL96b] and ADOME [LL98] two strategies

are assumed. The first one, called upward lookup, consists in lookup within a direct role class

and then within its ancestors. The second one, called double lookup, consists in lookup within


38/172

38

the direct role class, then within classes of sub-roles, and finally within its ancestors. The

rationale for different strategies is however not clear, since the given examples do not show

explicitly the essence of the problem (considering that - eventually - everything is in the hands

of designers and programmers of applications). It seems that the research presented in the

papers [LCW97, LL94, LL98, LW99, WL94, WL95, WCL96a, WCL96b, WCL97, Wong99]is currently most advanced.

Some papers (e.g. [WJ89]) pay attention to the fact that in case of dynamic roles a unique

object identifier becomes problematic. Indeed, for consistent referential semantics (e.g. for

implementing relationships among object and roles) each object role should possess its own

unique identifier. This means some distinction between object identityand object identifier:

having the unique identity an object can have many identifiers. This is an essential semantic

novelty.

Multiple interfaces, which are a feature of Java and Microsofts COM/DCOM, have some

associations with dynamic object roles. Indeed, the programmer is able to define interfaces in

such a way that a single interface represents a single object role. However, multiple interfaces

do not support all dynamic roles features, in particular, do not deal with the inherent dynamic

roles property to be inserted to (and removed from) an object at run time.

Te following is list of features of dynamic object roles that occur in the literature on roles

(taken from [Steimann2000]). It is worth a notice that some features conflict with others.

1.A role comes with its own properties and behavior.

2.Roles depend on relationships [BO98, CZ97, EWH85, Guarino92, Sowa88].

3.An object may play different roles simultaneously [Kristensen95, MD93, Pernici90,

RS91, WJS95, WCL97].

4.An object may play the same roles several times, simultaneously [Kristensen95,

Pernici90, RS91, WJS95, WCL97]. (Not in [ABGO93, BD77, Reimer85].)

5.An object may acquire and abandon roles dynamically [ABGO93, GSR96,

Kristensen95, LL98, Papazoglou91, RS91]. (Object migration or dynamic classificationalso in [MMW94, Su91]; dynamic classification vs. role playing in [WJS95].)

6.The sequence in which roles may be acquired and relinquished can be subject to

restrictions [Pernici90, Su91, WJS95].

7.Objects of unrelated types can play the same role [BD77].


39/172

39

8.Roles can play roles [CZ97, Kristensen95, RH95, WJS95, WCL97].

9.Roles can be transferred from one object to another [Kristensen95, WCL97].

10.The state of an object can be role-specific [Kristensen95, Pernici90, WJS95].

11.Features of an object can be role-specific [ABGO93, GSR96, LL98, Pernici90, RS91].

12.Roles restrict access [GSR96, Kristensen95, Pernici90, WCL97].

13.Different roles may share structure and behavior [CM99, GSR96, Kristensen95,

RH95].

14.An object and its roles share identity [Booch94, GSR96, Kristensen95, RS91].

15.An object and its roles have different identities [WJS95].

4.1. The Concept of Roles by Bachman and DayaA historically first approach to extend data model with roles has been proposed by Bachman

and Daya [BD77]. The authors introduce the concept of integrated database, assuming that

every single record should represent all aspects of a given real-world being. They introduce a

concept of role, which describes the prototype of a class of roles with similar properties. They

introduce also a concept of entity type that defines the prototype of a class of entities, which

are capable of playing the same roles. Some role types can be played by more than one entitytype; then they are declared as shareable (e.g., an employee role can be played by entities:

person, supplier, and customer). Some entity types should always be characterized

Object Roles - Aj 2002

Documents

Transcript of Object Roles - Aj 2002