©Copyright by Kazimierz Subieta.

AS2 Store Model: Dynamic Object Roles[1] and Dynamic Inheritance

by Kazimierz Subieta

Back to Description of SBA and SBQL.

Back to Abstract Object Store Models

Back to AS0 Store Model

Back to AS1 Store Model


The idea of dynamic object roles is simple and natural. It assumes that every real or abstract entity during its life can acquire and lose many roles without changing its identity. The roles appear during the life of a given object, they can exist simultaneously, and they can disappear at every moment. For example, a certain person can at the same time be a student, a worker, a patient, a club member, etc., Fig.10. Similarly, a building can be an office, a house, a magazine, etc.

Fig.10. Roles of a person object

Typical object models have a possibility to express static properties, e.g., the fact that a student is a person. However, it is more precise to say that a person becomes a student for some time and later he or she terminates the student role. Moreover, some person at the same time can be a student two or more times. Similarly, a person may become an employee, a patient, etc. only for some time.

The concept of dynamic object roles assumes that an object is associated with other objects (subobjects), which are modeling its roles. Object-roles cannot exist without their parent object (in Fig.1, without the Person object). Deleting an object causes deleting all of its roles. Roles can exist simultaneously and independently. A role can have its own additional attributes and methods. It is normal that two roles can contain attributes and methods with the same names, and this does not lead to any conflict. This is a fundamental difference in comparison to the concept of multiple inheritance.

Relationships (associations) between objects can connect not only objects with objects, but also objects with roles and roles with roles. For example, a relationship works_in connects an Emp role with a Dept object. This makes the referential semantics clean in comparison to the traditional object models. Roles can be further specialized as sub-roles, sub-sub-roles, etc. For example, the specialization of a role Club_Member can be a role Club_President.

The role concept requires introducing composite objects with special structure and semantics. The structure should be supported by proper generic operations. In this section we describe the structure formally, as the AS2 store model. In next chapters we precisely describe how such a feature can be involved into a query/programming language.

Dynamic object roles have had for several years the reputation of a notion on the brink of acceptance. There are many papers advocating the concept, however, many researchers consider applications of the concept not sufficiently wide to justify the extra complexity of conceptual modeling facilities. The concept is totally neglected on the implementation side - as far as we know, none of popular object-oriented programming languages or database systems introduces it explicitly. It is implemented in prototypes, e.g. the Fibonacci and Loqis systems. Some authors assume a tradeoff, where the role concept is the subject of special design patterns applied both on the conceptual modeling and the implementation sides. We doubt if all aspects of the concept can be reflected in this way and if indeed such design patterns simplify the programmers’ job.

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, which seems to be very natural, but on the other hand leads to anomalies, which are evident in the case of multiple, multiple-aspect and repeating inheritance. Another assumption, which impedes the popularity of dynamic roles, is strong static (polymorphic) typing, which in case of dynamic roles must be redesigned.

We will try to convince the reader that the mentioned impediments of wide usage of roles can be avoided. We show that the dynamic object roles are useful both for conceptual modeling and implementation. The concept could much facilitate modeling tools such as UML and could be an important paradigm on object databases built e.g. in the spirit of the ODMG standard. Moreover, dynamic object roles allow us to avoid some limitations, pitfalls and inconsistencies in object-oriented database models.


Formal definition of the AS2 store model

In our definition of the AS2 store model we accept all the definitions of the AS0 and AS1 model and extend them by few new concepts. In AS2 an object store is defined as a six-tuple <S, C, R, CC, SC, SS>, where:

·         S is a set of (perhaps nested and linked) objects, as in AS0.

·         C is a set of classes, as in AS1.

·         R is a set of identifiers of root (start) objects, as in AS0.

·         Relation CC Ì IC IC determines static inheritance among classes, as in AS1.

·         Relation SC Ì IS IC determines membership of objects in classes, as in AS1.

·         New relation SS Ì IS IS determines dynamic inheritance among objects. If <i1, i2> SS, then the object identified by i1 inherits from the object identified by i2. In our intention, the object identified by i1 is a dynamic role of the object identified by i2. The relation SS should not contain cycles and should be pure hierarchy, i.e. no role can be a property of two or more objects.

A role cannot exist alone, i.e. if the object identified by i2 is deleted, then the object identified by i1 is automatically deleted too. Roles of an object should be distinguished by some flag, but in our examples for simplicity we drop it considering self-evident. Note that we subdivide inheritance into static and dynamic, because the first kind of inheritance can be a compile-time property, while the second kind must be a run-time property. Usually we assume that all identifiers of roles are among root objects identified by R.

 

S – Objects (and roles)

<i1, Person, { <i2, name, ”Doe” >, <i3, born, 1948 > } >,

<i4, Person, { <i5, name, ”Poe” >, <i6, born, 1975 >} >,

<i7, Person, { <i8, name, ”Lee” >, <i9, born, 1951 >} >,

<i13, Emp, { <i14, sal, 2500 >, <i15, worksIn, i127> } >,

<i16, Emp, { <i17, sal, 1500 >, <i18, worksIn, i128> } >,

<i19, Student, { <i20, studentNo, 223344 >, <i21, faculty, ”Physics” >} >

.....

C - Classes

<i40, PersonClass , { <i41, age, (...code of the method Age...) >, ...other properties of PersonClass...}>,

<i50, EmpClass , {<i51, changeSal, (...code of the method changeSal...) >, <i52, netSal, (...code of the method netSal...) >, ...other properties of EmpClass... }>,

<i60, StudentClass , { <i61, avgScore, (... code of the method AvgScore...) >, ...other properties of StudentClass ... }>,

.....

R – Root identifiers

i1, i4, i7, i13, i16, i19, ...

CC - Inheritance between classes

Empty.

SC - Membership of objects and roles in classes

< i1, i40>, < i4, i40>, < i7, i40>, < i13, i50>, < i16, i50>, < i19, i60> , ...

SS – Inheritance between roles and objects

< i13, i4>, < i16, i7>, < i19, i7> , ...

Fig.11. Example of an AS2 object store

 

Fig.12. Graphical representation of the example AS2 object store

In Fig. 11 and Fig.12 we have omitted the static inheritance relation from EmpClass and StudentClass to PersonClass. It is substituted by the dynamic inheritance and object membership in classes. For instance, a Student role inherits dynamically properties of its Person object, hence indirectly imports properties of the PersonClass.

We will use the terminology in which each object consists of roles and one of them is the main role. For instance, a Lee’s object consists of three roles, Person, Emp and Student, and Person is its main role. Each object can be bound (retrieved) by using the name of any of its roles. However, the result of the binding will be a reference to the proper role (roles).

In our intention the AS2 model will have a natural delete and copy semantics. Deleting a role implies deleting all its sub-roles. In particular, deleting a main role means deleting of the whole object. Similarly for copying: we assume that copying a role implies automatic copying of all its sub-roles.

As for the AS1 model, the nature of dynamic inheritance will be explained later, when we define the query execution engine.


Peculiarities of the Object Model with Dynamic Object Roles

Below we list several features, which make the concept of dynamic roles different in comparison to the classical object-oriented concepts.

·         Substitutability. The AS2 model gives up the substitutability principle. It is no more necessary. For instance, the typical statement that a Student object can be used in any place where the Person object can be used makes little sense for the AS2 model. An object consists of many roles, each with own name, and the programmer makes an explicit choice which role is proper in the given place of the program. If Lee has three roles Person, Emp and Student, the programmer uses Person if he/she would like to abstract from specialized roles, and uses Emp or Student in other program contexts which require these roles. Of course, we can think on some mix of AS1 and AS2 models, where substitutability coexists with dynamic roles.

·         Object identity. An object has as many unique object identifiers as roles. One of the identifiers (of the main role) is distinguished, but binding the object through a name of its role returns an identifier of the role rather than this distinguished identifier.

·         Multiple inheritance. Because roles are encapsulated there is no name conflict even if the super classes would have different properties with the same name. There is no need for EmployeeStudentClass, which inherits both from EmployeeClass and StudentClass.

·         Repeating inheritance. An object can have two or more roles with the same name; for instance, Brown can be an employee in two companies, with different Salary and Job. Such a feature cannot be expressed by the traditional inheritance or multi-inheritance concepts.

·         Multiple-aspect inheritance. A class can be specialized according to many aspects. For example, a vehicle can be specialized according to environment (ground, water, air) and/or according to a drive (horse, motor, jet, etc.). Some modeling tools (e.g. UML) cover this feature, but it is neglected in object-oriented programming and database models. One-aspect inheritance makes problems with conceptual modeling and usually requires multiple inheritance. Roles allow for avoiding problems with this feature.

·         Multiple interfaces. Dynamic object roles in natural, universal and semantically consistent way accomplish the idea of multiple interfaces to an object.

·         Variants (unions). This feature, introduced e.g. in C++, CORBA and ODMG object models, leads to a lot of semantic and implementation problems. Some professionals argue that it is unnecessary, as it could be substituted by specialized classes. However, if a given class can possess many properties with variants, then modeling this situation by specialized classes leads to the combinatorial explosion of classes (e.g. for 5 properties with binary variants - 32 specialized classes). Dynamic object roles avoid this problem. Each branch of a variant can be considered a role of an object.

·         Object migration: Roles may appear and disappear at run time without changing identifiers of other roles. In terms of classical object models it means that an object can change its classes without changing its identity. This feature can hardly be available in classical object models, especially in models where binding objects is static.

·         Referential consistency: In the presented model relationships are connected to roles, not to the entire objects; thus, e.g. it is impossible to refer to Salary and Job of Smith when one navigates to its object from the object School. In classical object-oriented models this consistency is enforced by strong typing, but is problematic if the typing is semi-strong, weak or absent.

·         Overriding: Properties of a super-role can be overridden by properties of a sub-role. The possibilities of overriding are extended in comparison to the classical object models: not only methods but also attributes (with values) can be overridden.

·         Binding: An object can be bound by the name of any of its roles, but the binding returns the identifier of a role rather than the identifier of the object. By definition, the binding is dynamic, because in a general case during compilation it is impossible to decide that a particular object has a role with a given name.

·         Typing: A role must be associated with a name, because this is the only feature allowing the programmer to distinguish a role from another one. Hence, the role name is a property of its type (unlike classical programming languages, where a type usually does not determine the name of a corresponding object/variable). Because an object is seen through the names of its roles, it has as many types as it has different names for roles. Hence typing systems for the model with object roles must be redesigned.

·         Subtyping: It can be defined as usual; for instance, the Emp type is defined with the use of the Person type. However, there is no sense to introduce the StudentEmployee type. Due to encapsulated roles, properties of a Student object and properties of an Emp object are not mixed up within a single structure.

·         Temporal properties: Dynamic object roles are enormously useful for temporal databases, as roles can represent any past facts concerning objects, e.g. the employment history through many Employee roles within one Person object. Without roles, historical objects present a hard design problem, especially if one wants to avoid redundancy, to preserve reuse of unchanged properties through standard inheritance, and to avoid changing objects’ identifiers.

·         Aspects of objects and heterogeneous collections. A big problem with classical database object models, for instance ODMG, is that an object belongs to at most one collection. This is contradictory with multiple inheritance, substitutability and open-close principle. For instance, we can include a StudentEmp object into the extent Students, but we cannot include it at the same time into the extent Emps (and vice versa). This may leads to inconsistent processing. Dynamic roles have the natural ability to model heterogeneous collections: an object is automatically included into as many collections as the types of roles it contains. For instance, in Fig.12 we can see three collections: Person (3 objects), Emp (2 objects) and Student (1 object) which in a specific way share information and overlap, but this does not lead to any conceptual problems. Note that if Lee will decide to study in parallel on two universities, his object will have two roles Student. Hence in the collection Student the Lee object will occur two times. This is logical and consistent, but such a situation is very hard to handle by the typical collection concept.

·         Aspect-Oriented Programming. AOP makes it possible to encapsulate cross-cutting concerns within separate modules, for example, such concerns as: history of changes, security and privacy rules, visualization, synchronization, etc. As follows from the previous feature, dynamic object roles have conceptual similarities with AOP or can be considered as a technical facility supporting AOP.

·         Metadata support. Metadata are a particular case of crosscutting concerns. Meta-information, as assumed e.g. in Dublin Core (such as authorship, validity, legal status, ownership, coding, etc.) can be implemented as dynamic roles of information objects.

As follows from the above, dynamic object roles have the potential to create new powerful qualities, which are difficult or impossible to achieve in the classical object model.


Last modified: December 31, 2007



[1] The term role is overloaded. Dynamic object roles have nothing in common with association roles, as introduced in UML. Our understanding of the term is also different from the role of a person in some software development methodologies and in the workflow terminology. Our role is also different from the concept of role, as understood in the Object Role Modeling (ORM) developed by Terry Halpin and other authors.