AS2
Store Model: Dynamic Object Roles[1] and Dynamic
Inheritance
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