Using Dynamic Classes and Role Classes to ... - Semantic Scholar

Using Dynamic Classes and Role Classes to Model Object Migration Roel Wieringa1

Wiebren de Jonge

Paul Spruit

Faculty of Mathematics and Computer Science, Vrije Universiteit De Boelelaan 1081a, 1081 HV, Amsterdam Email: [email protected], [email protected], [email protected] Tel: +31 20 4447771, Fax: +31 20 4447653

Appeared in Theory and Practice of Object Systems, 1(1), 1995, pages 61{83 Abstract

In this paper, we argue that object-oriented models must be able to represent three kinds of taxonomic structures: static classes, dynamic classes, and role classes, that behave dierently with respect to object migration. If CAR is a static subclass of V EHICLE , then a vehicle that is not a car can never migrate to the CAR subclass. On the other hand, if EMP loyee is a dynamic subclass of PERSON object class, then a PERSON that is not an employee may migrate to EMP . In both cases, an instance of the subclass is identical to an instance of the superclass. By contrast, if EMP is modeled as a role class of PERSON , then every employee diers from every person, but a PERSON instance can acquire one or more EMP instances as roles. The distinctions between the three kinds of classes are orthogonal, so that we can have, for example, dynamic subclasses of object or role classes, or role classes of dynamic or static classes. The paper is divided into two parts. In the rst, informal part, we present an analysis of the dierences between the three kinds of classes and motivate their utility by a number of examples. We argue that the inheritance of object life cycles is downward in the static class hierarchy and upward in the dynamic class hierarchy. We summarize this analysis by giving a number of modeling heuristics that can be used to make sound modeling decisions, and we compare our approach to class migration with other approaches. In the second, formal part of the paper, we outline one possible approach to formalizing the speci cation of static classes, dynamic classes, role classes and class migration, based on order-sorted dynamic logic and process algebra. We illustrate this approach by giving a number of small example speci cations and by proving some useful properties of these speci cations. This paper is an updated and extended version of [74]. Keywords: Object migration, OO analysis and design, dynamic logic

1

This research is partially supported by Esprit Basic Research Action IS-CORE (working group 6071).

1

1 Introduction Object migration is the phenomenon exhibited when an object changes classes during its lifetime. In this paper, we argue that there are two ways to model object migration between classes. Consider a situation in which a PERSON becomes an EMP loyee. One way to model this is to let EMP be a dynamic subclass of PERSON . Each EMP instance is then identical to a PERSON instance, because each employee is modeled as a person in a certain state. In database terms, the EMP instance has the same identi er as the PERSON instance whose mode it is. As a consequence, if we count the number of persons in a set of ve employees, the answer will be ve. If, on the other hand, we want to model the situation that one PERSON instance can be many dierent EMP instances (simultaneously or in sequence), then we have to give EMP instances their own identi ers, dierent from each other and from PERSON identi ers. In this modeling approach, we call EMP a role class of PERSON and instances of EMP are called roles of PERSON instances. Since roles have their own identi ers, if we count the number of persons in a set of ve employees, we may very well get the answer one (because this person plays ve EMP roles). It is clear from these examples that there is a close connection between object classi cation and object identi cation. The connection becomes apparent when we count objects, for in order to count objects, we must know what to count as identical objects and what to count as dierent objects; and in order to do that, we must classify the objects we are counting. It has been known for some time in philosophical logic that some classes provide an identi cation principle for their instances [26, 39, 65, 76]. Our distinction between object and role classes on the one hand (that provide an identi cation principle for their instances) and dynamic classes on the other (that do not provide an identi cation criterion for their instances), is also derived from this insight. The phenomenon of object migration has been studied for some time in object-oriented systems modeling, but until now it was not realized that, due to the close connection between object classi cation and identi cation, an adequate representation of object reclassi cation requires an adequate theory of object (re)identi cation. For example, do we allow a change of object identi er when an object changes class? In a companion paper, we provide a detailed analysis of object identi cation and show how object identi ers can and cannot be used [73]. In the current paper, we give the concept of object identi er de ned there without further argument, and concentrate on the phenomena of object migration and role playing. The paper is divided into two parts. In the rst, informal part, we give a detailed analysis of the concept of object migration and argue that for an adequate representation, we need to provide the representation mechanisms of dynamic class and role class. In the second, formal part, we present one possible formalization of these mechanisms, using dynamic logic and process algebra as speci cation tools. The rst part of the paper is independent of any formal speci cation language and can be read without knowledge of formal speci cation. The second part is one way to formalize the ideas in the rst part, but the reader may try to replace this with his or her own favorite approach to formal speci cation. In section 2, we look at the connection between object classi cation and identi cation, and de ne static classes, dynamic classes, and role classes. We discuss two inheritance mechanisms, inheritance by identity, which is appropriate for static and dynamic classes, and inheritance by delegation, which is appropriate for role classes. Finally, we argue that object migration constraints can be represented by object life cycles, and that object life cycles are inherited downward in the static class hierarchy but upward in the dynamic class hierarchy. In section 3, we summarize the discussion by extracting from it a number of methodological principles that can be used as quality checks during object-oriented modeling. The principles provide simple questions that can be asked about the taxonomic structures, with simple answers that make clear to the modeler which modeling choices are open to him or her, and that give hints as to which choices to make. 1

In section 4, we compare our approach to object migration with that of others. Section 5 gives a logic for specifying updates in general, called DDL (Dynamic Database Logic), which is a variant of dynamic logic. Section 6 applies this logic to the speci cation of classes, static taxonomies, dynamic taxonomies, and role playing in a way that agrees with the analysis of section 3. In section 7, we discuss the possibility of the speci cation of the life cycle specialization relationship, and compare our approach to other modal logic formalizations of objects. Section 8 concludes the paper and lists a number of topics for further research.

2 An analysis of object migration

2.1 Classes and object identi ers

A class is a set of possible individuals, called class instances. If the instances are objects, the class is called an object class, if the instances are roles, then the class is called a role class. The dierence between objects and roles is explained later; for the time being, both objects and roles can be understood to be individual objects with a local state and a local behavior. In each state  of the world and each class C , there is a (possibly empty) set ext (C ) of instances that exist in . We call this the existence set of C in . The set of all existing objects of all classes in state  is Exists = ext (C ):

[ C

This existence set may dier in dierent possible states of the world. By contrast, the following two sets are state-independent: 1. The extension of a class is the set of all possible objects in the class, de ned as

ext(C ) =

[ ext (C ): 

Thus, each instance in ext(C ) exists in some possible state of the world. 2. The intension of a class is the set of all properties shared by all possible class instances. The intension of class C is written as int(C ). We regard int(C ) as the type of C . Thus, the type of a class expresses the set of properties shared by all class instances. It is now well-accepted that in object-oriented modeling, each object should have a unique identi er [8, 27, 35]. Elsewhere [73], we argue that object identi ers are always de ned relative to an object identi cation scheme. An object identi cation scheme maintains in each possible state  in the world an object identi cation relation between a set of values V and a set of objects O, that satis es the following requirements:  Each value in V is the name of at most one possible object, and each possible object is named by at most one value in V .  Once an object is named by a value, the connection between this value and this object remains forever (even after this object ceases to exist). Thus, the existence set of the object identi cation relationship between values and objects is monotonically increasing. This de nition is motivated and analyzed in detail elsewhere [73]. Here, we point out a number of features that may seem puzzling at rst sight. First, we use values rather than symbols as object identi ers because this gives us the freedom to represent the same identi er by dierent symbols (e.g. 2

as a binary number, as a hexadecimal number, as a character string, as a bar code) in dierent media (e.g. paper, computer memory). Second, we do not require that an object that in state  of the world has an object identi er, actually exists in state . Thus, cars that are not yet built or that have been demolished may still have an identi er. Third, we do not require all existing objects to have an object identi er. Objects such as needles and pins usually have no object identi er. Fourth, note that it is possible to use several object identi cation schemes simultaneously, each of which only guarantees uniqueness over a limited set of objects O and set of identi ers V . For example, we give unique numbers to the employees within one company, or to les within one system, or to objects in one database. In each of these examples, the monotonically increasing relationship between identi ers and objects is only guaranteed for a limited set of objects and within a limited set of identi ers. Fifth, the de nition above does not mention visibility or invisibility of identi ers. We do not consider an object identi er used in an object base system necessarily as an implementation detail that should be hidden from the user. It depends upon the use of the identi er whether or not it must be considered part of the implementation of the object system. For example, in an object-oriented database system, we may represent real-world employees by database objects. The employee number would then be an external identi er of the real-world employee, visible to the user. In addition, we may have an internal identi er of the surrogate in the system that represents the real-world employee. The internal identi er would be system-generated and would be invisible to the user, because it would be part of the implementation. Lastly, we want to point out that it follows from our de nition that an object identi er is totally independent from the object state and even from the existence of the object. This corresponds to an underlying philosophical assumption we make, viz. that the identity of an object is independent from its state. This point is important when we look at dynamic class partitions below. In database terms, we should not encode any state information in the object identi er. Note that an identi er is a name; it is not something that is in any sense \part of" the object that it names. However, using identi ers for real-world objects presupposes that these objects have an identity that is unique and never changes for as long as we use this identi er. The use of identi ers presupposes therefore that the identi ers refer to distinct and enduring objects. Masses like water, gold, and pro t are not the kind of thing we can name by means of a globally unique identi er. The characteristic feature of a mass is that we can add parts of the mass without changing the kind of the mass. Every sum of parts of water is itself water [47, page 91]. By contrast, if we put objects together, we have a set of objects and not a bigger mass. It makes sense to ask how many objects there are, not how much of it there is. So in order to use identi ers, we must identify objects; and to identify objects, we must classify them as a certain category of things. In particular, they must be classi ed as distinct, so that we can identify them among a set of similar objects, and they must be classi ed as enduring, so that we can reidentify them. Taking this one step further, the class as which we classify them must provide a principle of counting, i.e. of identi cation. As an illustration, consider the problem of counting the number of passengers that traveled in a bus in one week. If we count persons, we may count 1000, but if we count passengers, we may count 4000. Since the identi cation principles of the classes PERSON and PASSENGER are dierent, we get dierent answers depending upon which class instances we are counting. We may count one person where we count four passengers (at dierent times). Similarly, we may count one building where we count three shops (at dierent times), we may count one person where we count three employees (possibly at the same time), we may count one lump of clay where we count dierent statues (at dierent times), etc. This relationship between classi cation and identi cation is well-known in philosophical logic [17, 3

39, 38, 65, 76]. There are two views concerning the relationship between classi cation and identi cation: 1. For each class C there is an equals sign =C that says whether individuals are identical or not if they are viewed as instances of C . In this view, if p1 and p2 are PASSENGERs, we can have p1 =PERSON p2 and p1 6=PASSENGER p2 . 2. There is only one equals sign, that is applicable to any pair of arguments from any pair of classes. However, we may have that dierent instances of dierent classes in some sense coincide in time and space. Thus, in this view, if p is a PERSON and t1 and t2 are PASSENGERs, we can have t1 6= t2 but that both t1 and t2 \coincide" with p. In this paper, we have chosen the second option. Thus, in the logic introduced later, we have the choice of modeling the PASSENGER as a dynamic subclass of PERSON , in which case each passenger is a person in a certain state. Or we may model PASSENGER as a role class of PERSON , in which case each passenger is an object in its own right, that depends for its existence on the existence of a person who plays the passenger role. If PASSENGER is a dynamic subclass of PERSON , we have t1 = t2 = p and counting passengers gives the same answer as counting persons. If it is a role class of PERSON , then t1 , t2 and p are three dierent identi ers and counting passengers may give a dierent answer from counting persons. However, t1 and t2 are roles played by (\coincide with") the same object, viz. p, and therefore in some sense share the properties of p.

2.2 Subclasses

Class C1 is de ned to be a subclass of C0 if ext (C1 )  ext (C0 ) for all possible states  of the world. is a is a C0 . By the de nition of ext, we have that C1 ?! C0 implies We write this as C1 ?!

ext(C1 )  ext(C0 ): If ext(C1 )  ext(C0 ), there is an opposite subset relationship between the intensions of C1 and C0 : int(C0 )  int(C1 ). We have ext(C1 )  ext(C0 ) ) int(C0 )  int(C1 ): For example, CAR is a subclass of V EHICLE because ext(CAR)  ext(V EHICLE ); and this is implies

int(V EHICLE )  int(CAR);

i.e. a car has all vehicle properties and possibly more. The containment relationship between intensions represents the inheritance relation from superclass to subclass. Note that we take a strong view towards subclassing as set inclusion. A weaker view is formulated by the principle of substitutability [68]: An instance of a subtype can always be used in any context in which an instance of a supertype was expected. Because an instance of CAR is also an instance of V EHICLE , our subclassing relation satis es the principle of substitutability. A weaker subclassing relation would merely require that the instances of the subclass C1 share at least the properties shared by all instances of the superclass C0 , e.g.

int(C0 )  int(C1 ); 4

TRUCK

CAR

is a

V EHICLE

is a OTHER V EHICLE GAS

DIESEL

OTHER ENGINE

Figure 1: Two is a partitions of a class. without requiring an inclusion relationship between the extensions of the classes. It is possible to follow this weaker view of subclassing without aecting the de nition of dynamic classes and role classes. However, because of the close relationship between classi cation and identi cation in the real is a relationship de ned above is the world, we think that for object-oriented analysis models, the ?! appropriate subtyping relationship.

2.3 Static partitions

We now turn to the dierent ways to de ne subclasses for a given class. We require a subclass always to be an element of a (full) partition of its immediate superclass. The reasons for this are explained at the end of this subsection. We say that C1 ; : : : ; Cn is a static partition of C0 if we have for all state  and 0 of the world ext (Ci ) = ext (C0 );

[

i=1;:::;n

ext (Ci ) \ ext0 (Cj ) = ; for i 6= j:

It follows that for extensions we have analogous properties:

[

i=1;:::;n

ext(Ci ) = ext(C0 );

ext(Ci ) \ ext(Cj ) = ; for i 6= j: Static partitions are represented graphically as in gure 1. (In all V EHICLE examples we make the

limiting assumptions that we are only talking about motor vehicles and that vehicles cannot change engine type.) Each class is represented in the Coad/Yourdon way [7] by a rectangle containing three boxes for, from top to bottom, the class name, the attributes local to the class, and the events (i.e. messages) local to the class. To save space, most examples drop the attributes and events. Each 5

partition fC1 ; : : : ; Cn g of C0 is represented by a set of is a arrows from Ci (i = 1; : : : ; n) to C0 that merge before they reach C0 . There are two hidden cardinality constraints associated with each is a arrow:  Each instance of Ci is related to exactly 1 instance of C0 ;  Each instance of C0 is related to exactly one instance of exactly one Ci in the partition; this is represented by the merging of is a arrows. Note that each is a arrow represents the inclusion function is a : ext(Ci ) ! ext(C0 ). A partition of a class into subclasses can have any nite number of elements, as long as it contains at least two elements. We exclude the degenerate case where n = 1 (which would collapse into C1 = C0 ). We allow any number of partitions per class. If o is an instance of C0 , it is an instance of exactly one subclass in every partition. Each pair of partitions of a class creates a number of intersection classes. For example, in gure 1 we have, among others, intersection classes CAR  DIESEL, CAR  GAS , TRUCK  DIESEL, and TRUCK  GAS . The number of intersection classes grows exponentially in the number of partitions per class. All intersection classes that can be formed this way are considered to be part of the model. However, they are not shown in the diagram. Note that in gure 1 we assume that a truck cannot be converted into a car or vice versa, and that a vehicle with a gas engine cannot be rebuilt into a vehicle with a diesel engine. The last assumption is not very realistic, and even the rst one is questionable. In general, we found it very dicult to nd examples of static partitions outside the realm of biology. A static class is a member of a static partition or a ( nite) intersection of static classes. We can now state the reason why we require a subclass to always be an element of a partition: This way, we know that the universe of all possible objects is partitioned in a unique way into minimal static classes. By taking all possible intersections of all static classes, we get a set of smallest static classes, that  are pairwise disjoint,  jointly cover the set of all possible objects, and  have no static subclasses (other than the empty subclass). We call these smallest static classes species. Species give methodological and logical advantages. First, a fundamental principle of classical taxonomies is to have, for each specialization, an unambiguous dividing principle and exhaustively list all subclasses that follow from this dividing principle, without leaving an unnamed restclass [33, 50]. This enhances the clarity of the model and reduces the chance that we miss important classes in the model. Details on this are given in section 3. Second, the dynamics of the model is easier to specify and understand if we specify creation events only for species and not for other classes. Suppose we subdivide a class C into subclasses but leave an unnamed restclass. We must then still be able to create instances of this unnamed restclass, and the creation event for the unnamed restclass must be declared somewhere. Now, it cannot be declared in the speci cation of C , because then it would be inherited by all subclasses of C , including all named ones. The only possibility is to declare it only for the restclass; but then this class must be speci ed, i.e. it must at least get a name. Note that this argument still holds if we declare creation events as 6

class methods or even as database methods. In whatever way we declare creation events, if there is an unnamed restclass of C , we must be able to say \create an instance of C that is not an instance of any named subclass of C ". To de ne such a creation event, we must give a name to this restclass. When we look at migration constraints for dynamic subclasses later, we will re ne the rule of allocation of creation events.

2.4 Dynamic partitions

Let C0 be a class and  be a state of the world. We say that C1 ; : : : ; Cn is a dynamic partition of C0 if we have for all states  that [ ext (Ci) = ext (C0); i=1;:::;n

ext (Ci ) \ ext (Cj ) = ; for i 6= j; ext(Ci ) = ext(C0 ) for i = 1; : : : ; n:

The rst requirement also holds for static partitions. The second requirement says that in each state of the world, the dynamic classes in a partition must have disjoint existence sets, but allows overlap in dierent states of the world. This allows objects to migrate between dynamic classes. The third requirement is a consequence of the principle that the identity of an object is independent from its state. To see this, rst note that fC1 ; : : : ; Cn g partitions the state space of any instance of C0 exhaustively into disjoint subspaces. Now, we assume that there is at least one object that can move to each of these subspaces, i.e. for which there is at least one state of the world in which it is an instance of Ci , i = 1; : : : ; n. If there is no instance of C0 that can ever be an instance of a particular Ci for i0 2 f1; : : : ; ng, then we should drop this Ci from the subclass partition. So there is an instance of C0 that can move to each subspace. But since we make no assumptions about the identity of this instance, and since there is no connection between object identity and object state, then all instances of C0 can do so. But this means that ext(Ci ) = ext(C0 ) for i = 1; : : : ; n. To give an example, if any instance of PERSON can move to the dynamic subclass STUDENT , then, in principle, all instances of PERSON can move to this subclass (even if this never actually happens for many persons). Just as for static partitions, we allow any nite number of elements in a dynamic partition, provided that the partition contains at least two elements. The dashed arrows in gure 2 mean that in each state of the world, the existence set of V EHICLE is partitioned by the existence sets of ACTIV E and WRECK , so that each V EHICLE is either ACTIV E or a WRECK . However, in a state transition, a V EHICLE may move from one of these subclasses to the other. (If there is a constraint that it can only move from ACTIV E to WRECK and not from WRECK to ACTIV E , then this must be represented in the life cycle of a V EHICLE class.) Note that by inheritance, each subclass of V EHICLE is also partitioned into an ACTIV E and a WRECK subclass. This gives us, among others, the following intersection classes: ACTIV E  CAR, ACTIV E  TRUCK , WRECK  CAR, and WRECK  TRUCK . A dynamic class is an element of a dynamic partition of a (dynamic or static) class C . Each intersection of a dynamic class with another (static or dynamic) class is itself a dynamic class. All of the above intersection classes are dynamic classes. If C1 is a dynamic subclass of C2 , we write is a C1 ??! C2 . It follows from our de nitions that we cannot have a static partition of a dynamic class. For example, consider the taxonomic structure in gure 3. This taxonomy says that 0

7

TRUCK V EHICLE

is a CAR

is a ACTIV E reg nr : NATURAL

OTHER V EHICLE

WRECK destruct(DATE )

owner PERSON

Figure 2: Dynamic partitioning of a class.

C0 is a

C1

C2

is a

C3

C4

Figure 3: A dynamic class cannot be partitioned by static classes.

8

PERSON

is a

NON STUDENT

STUDENT

Figure 4: A PERSON can move from one subclass to another in this dynamic partition.

and therefore that

ext(C1 ) = ext(C3 ) [ ext(C4 ) and ext(C1 ) = ext(C0 ); ext(C0 ) = ext(C3 ) [ ext(C4 ):

So each C0 is a C3 or a C4 . But according to the taxonomy in gure 3, a C3 (or C4 ) is never a C2 . It follows that instances of C0 can never move to the dynamic subclass C2 . This means that C2 cannot have any instances. We disallow this kind of structure, because it introduces unnecessary complexity. Disallowing static partioning of dynamic classes results in simpler models, and does not reduce the modeling power of the taxonomy. So if we descend in the taxonomic structure, once we meet a dynamic partition, we will not meet a static partition anymore. We now have a nice duality between dynamic classes and static classes. A dynamic class partition divides the state space of instances of its superclass exhaustively into disjoint subspaces; a static class partition divides the object space (i.e. extension) of instances of its superclass exhaustively into disjoint subclasses.

2.5 Object migration

What is often expressed by saying that an object \migrates to a subclass" must be modeled in our approach as an object that changes subclass in a dynamic partition of a superclass. Figure 4 shows how we can model the situation that a person \moves to the student subclass". NON STUDENT s have the same properties as persons in general, except that NON STUDENT s have the additional property that they can move to STUDENT . (This property is not shared with STUDENT s and therefore not with PERSON s.) STUDENT s have a number of additional properties, plus the property that they can move to NON STUDENT . (This property is not shared with NON STUDENT s.) Note that an object never changes its identi er when \migrating to a subclass"; this is because it must not change its identi er at all. If dynamic classes would not be required to be a part of a dynamic partition, then we could have, for example, the dynamic class STUDENT as the only subclass of PERSON . The event become student occurs in the life of a PERSON , not of a STUDENT , and would therefore have to be allocated to PERSON . But then, intuitively, STUDENT would have to inherit this event, 9

which results in a paradox: a person in the state of being a student cannot become a student. This problem is avoided by requiring dynamic classes to be elements of a dynamic partition that exhausts its immediate superclass.

2.6 Role-playing and delegation

Earlier, we promised to distinguish roles from objects. Intuitively, a role is just like an object, except that it has a special relationship to other objects (or roles), which are said to play the role. A role can be played by an object or by another role but, as explained below, indirectly, a role is always played by an object. More formally, we assume that there is a function played by in the model such that if R is a role class, then there is a player class P that is the union of object or role classes such that in each state  of the world we have

played by : ext (R) ! ext (P ): For r 2 ext (R), we call played by(r) the player of r. This implies the following: 1. There is exactly one player of r. 2. r is existence-dependent upon its player, i.e. r cannot exist if its player does not exist. 3. There may be any number of roles played by a player, even if these roles are instances of the same role class. We additionally require there to be no cycles in the played by relationship. Together with the existence-dependency of roles on their player, this implies that in any state of the world, if we traverse a path of player by links starting from a role, we may encounter a number of roles, but after a nite number of roles, we will meet an existing object and there the role-playing path ends. It is possible to de ne delegation from roles to players. For example, suppose we model an employee e as a role of a person p, and age is an attribute of persons but not of employees. Then age(e) would be a type error. We can recover from this error by delegating the evaluation of age to played by(e) [40]. This amounts to replacing age(e) by age(played by(e)). Delegation can also be de ned for events. Role-playing is represented in a way similar to static classes ( gure 5). Role-playing has the following characteristics:  Each class (including a role class) can be specialized into one or more sets of role classes, called role groups. Each role group represents a set of mutually exclusive role classes, i.e. at any moment, any player can play roles from at most one role class in each role group simultaneously.  Unlike is a partitions, a role group is not \exhaustive". There may be instances of the player class that do not play any role in a role group.  For each role class, a cardinality constraint must be given, that says how many instances of the role class a player can play simultaneously. Absence of a visible constraint means unrestricted cardinality. This is dierent from the cardinality of a subclass in an is a relationship, which is always 0, 1. In an is a partition, each instance of the superclass is related to at most one instance of each class in the partition (and to precisely one instance of some class in its partition).  Role groups may consist of only one role class, which is also a dierence with respect to is a partitions.

10

EMPLOY EE

 10 played by

PERSON

STUDENT 0, 1

Figure 5: Role classes with cardinality constraints. A PERSON can play at most 10 EMPLOY EE roles or, alternatively at most 1 STUDENT role. The two role classes are exclusive (a person cannot play roles of both classes simultaneously) but the cardinality constraints show that they are not exhaustive: Each role class allows cardinality 0, i.e. it is possible that a PERSON plays neither role.

EMPLOY EE

 10

played by PERSON

STUDENT 0, 1

played by

Figure 6: A PERSON can play at most 10 EMPLOY EE roles simultaneously and at the same time at most 1 STUDENT role. The two role classes are not exclusive, because they are in dierent role \groups", nor are they exhaustive, for each allows cardinality 0, i.e. it is possible that a PERSON plays neither kind of role.

11

PERSON

EMP

played by

is a

MALE

is a

FEMALE

TEMP

PERM

played by PROJECT LEADER

Figure 7: Role classes and object classes can both be partitioned statically as well as dynamically. To illustrate the last point, suppose we want to allow the possibility that a PERSON plays the roles of EMPLOY EE and STUDENT at the same time. Then we should put these in dierent role groups, as shown in gure 6 (both role groups have only one element in this gure). We now have made two orthogonal distinctions: There are role classes and object classes, and each of these can be partitioned statically or dynamically. For example, gure 7 expresses the facts that the employee role can be played by persons, that employees can migrate between the statuses TEMP orary and PERM anent, and that only permanent employees can play the role of project leader.

2.7 Life cycle inheritance and migration constraints

Objects and roles are subject to dynamic integrity constraints, which are constraints on the behavior of the system that involve at least two dierent states of the system. Dynamic integrity constraints of objects can at least partly be represented by object life cycle diagrams. There are several diagram techniques in use to represent life cycles, such as state charts [52], nite state machines [58] and process graphs [72]. Among the non-object-oriented methods, Jackson System Development represents entity life cycles by entity structure diagrams [31]. In what follows, we will use a simple nite state machine representation of life cycles. What concerns us here is the way in which we can represent constraints on object migration by means of object life cycle diagrams. We should point out that the following discussion of life cycles is applicable to object as well as role life cycles. As will become apparent below, the subject of migration constraints is actually closely related to the subject of life cycleis inheritance, so we rst take a brief look at this. Following the principle of substitutability, if C1 ?!a C0 the life cycle of instances of C1 should be such that an instance of C1 12

sell

V EHICLE

destroy

produce

sell wreck CAR

produce

repair

find

destroy

steal

write off

Figure 8: Life cycle specialization. The start nodes are labeled with the name of the class whose instance life cycle is represented. can be used in any context where an instance of C0 was expected. There are several proposals for inheritance mechanisms that satisfy this requirement. One proposal has been developed independently by a number of authors, including Schre [55], Ebert and Engles [10] and Saake et al. [54]. The idea is that every life cycle diagram de nes a set of possible traces, where each trace is a sequence of event occurrences that constitutes a possible history allowed by the diagram. If S1 is the trace set of a specialized life cycle and we simply omit from every trace in the set the events that are not de ned for the supertype, then we should get a trace set that is a subset of the trace set S0 of the supertype. According to this criterion, the CAR life cycle in gure 8 is a valid specialization of the V EHICLE life cycle. This proposal interprets substitutability as follows: A trace of an instance of a subclass, restricted to events de ned for the superclass, can occur in any context that expected a trace of an instance of the superclass. There are more stringent interpretations of substitutability, which additionally take the communication behavior of objects into account. For example, Wieringa [69] requires that the communication behavior of an instance of the subtype, restricted to the events declared for the supertype, is indistinguishable from the communication behavior of an instance of the supertype. Nierstrasz [45] proposes a more relaxed criterion, in which an instance of the subtype refuses a request to perform an event declared for the supertype, only if this request would also be refused by an instance of the supertype. In both proposals, the CAR life cycle in gure 8 is not a valid specialization of the V EHICLE life cycle. 13

PERSON

is a

SINGLE

MARRIED

DIV ORCED

WIDOWED

create person

PERSON

SINGLE

marry

MARRIED divorce

become widowed marry

WIDOWED

marry

DIV ORCED

Figure 9: A dynamic class partition of PERSON and its corresponding migration diagram. We do not want to evaluate these approaches to life cycle inheritance here, but want to point out a common aspect: In all proposed de nitions of life cycle specialization, the life cycle of class instances becomes more complex if we descend in the taxonomic hierarchy. In the case of life cycle specialization for dynamic classes, this is dierent. If fC1 ; : : : ; Cn g is a dynamic class partition of C0 , then at each moment, any existing instance of C0 is in one of its subclasses, and during its life, it may migrate to some other subclasses according to the applicable dynamic integrity constraints. Now, these constraints must be laid down by the life cycle de nition of C0 . In other words, the life cycle diagram of C0 must in some way contain a description of the way in which instances of C0 can move through the dynamic class partition. One possible way to do this is to give for each dynamic class partition a migration diagram, as illustrated in gure 9. Each of the nodes in the migration diagram is labeled by the dynamic subclass with which it corresponds, and all dynamic classes of a partition appear in the migration diagram. The state transitions in the migration diagram are object migration events. The nodes correspond to dynamic classes, i.e. to subspaces of the total state space of instances of PERSON . We could expand each of the nodes in the migration diagram to the life cycle de ned for the corresponding subclass; doing this for all nodes, we get a full-blown life cycle diagram for PERSON . A small arrow points to the start node of the migration diagram, and this node is labeled by the name of the class being partitioned. We must be careful with the allocation of the creation event of 14

 Classi cation principle. For each is a partition of C there should be a classi cation principle that

governs the division in subtypes. This principle should be clear, unambiguous, singular, and uniform for all subtypes.  Comparable rank. All members of an is a partition should be of comparable rank.  Informativeness. By locating an object in one of the classes in an is a partition, we should learn more about it than the classi cation itself tells us already.

Figure 10: Classi cation checks for is a partitions.

PERSON . We said earlier that the universe of all possible objects is partitioned into smallest classes,

called species, and that creation events must be allocated to these classes. We have also seen that dynamic partitions must only appear below static classes; we exclude a static partition of a dynamic class. Now, the creation event of a species must put the created object in the starting class of the appropriate migration diagram. But then we should allocate this creation event to this particular dynamic class. For example, in the model of gure 9, we should allocate the PERSON creation event to SINGLE . Contrast this life cycle with that of V EHICLE in 8. In a static class hierarchy, we nd the most complex life cycle at the leaves of the taxonomy. In the dynamic hierarchy, the most complex diagram is at the top. However, this diagram can be simpli ed by hiding the life cycle of each dynamic class in a node, which then represents a subspace of the total state space. Note that the migration diagram (or the life cycle diagram) of PERSON is not inherited by its dynamic subclasses, as it would be in the case of static subclasses. Rather, there is a kind of upward inheritance in which each dynamic subclass contributes a part to the overall life cycle of the superclass instances. Thus, whatever the solution is to the problem of de ning life cycle specialization for static subclasses, this solution diers from what we need to specify dynamic life cycle specialization.

3 Methodological aspects of object migration We can summarize the above discussion in the form of a number of heuristic principles, that can be used when building an object-oriented conceptual model of a domain. The principles yield a number of simple questions that can be asked of taxonomic structures, and that lead to simple answers by which the quality of the taxonomic structure can be evaluated. A preliminary version of some of these principles appeared earlier [71].

3.1 Classi cation principles

We insisted that a (static or dynamic) subclass should always be member of a partition. In this section, we show that this corresponds to classical principles of taxonomic structures, that can be fruitfully applied in object-oriented modeling. These principles were studied extensively in Aristotelian logic [33, 50]. They are listed in gure 10. The rst principle says that for each (static or dynamic) subclass partition there should be a classi cation principle that is clear, unambiguous, singular, and uniform. What this means can best be explained by giving counterexamples to these principles.  Vague classi cation principle: A division of people into talented and untalented people. It is unclear what the criterion applied here is. 15

is a is a C , then ext(C )  ext(C ), but if C ??!  Equal extensions. If C1 ?! C0 , then ext(C1 ) = 0 1 0 1

ext(C0 ).

is a C0 i the existence set of C1 can change without a  Independent existence set change. C1 ??!

change in the existence set of C0 .

Figure 11: Checks to distinguish static classi cations from dynamic classi cations. The second check also distinguishes static classes from role classes.

 Ambiguous classi cation principle: A division of documents into those about statistics, those

about economics and others. This is ambiguous because some documents may be classi ed as having statistic as well as an economic subject matter.  Multiple classi cation principles: A division of documents into books, non-borrowable periodicals and borrowable periodicals. There are really two is a partitions here, not one.  Non-uniform classi cation principle: A division of animals into domestic animals, poisonous snakes and others. One subclass is de ned along the dimension domestic-wild animals and another along the dimension poisonous-nonpoisonous. The principle of comparable rank rules out an is a partition of people into those living in Amsterdam, Americans, and others. There is a clear, unambiguous, single and uniform classi cation principle, viz. location of the place of birth, but the classes of entities grouped together according to this principle are not of comparable order of magnitude. Finally, the principle of informativeness rules out a classi cation of documents into  those that can be borrowed for three weeks,  those that can be borrowed for one week, and  those that can be borrowed for one day. Unless, say, extra attributes were applicable to instances of some of these subtypes, locating a document into one of those classes does not give any extra information above the information what the borrowing period is. Incidentally, this is one reason why an intersection class like CAR  DIESEL should not be shown on a class diagram if the properties of instances of this class are just the sum of the properties of the intersected classes, CAR and DIESEL.

3.2 Distinguishing static classes from dynamic classes and role classes

The two important distinguishing features of dynamic classi cations versus static classi cations are listed in gure 11. The rst criterion leads us to ask whether, say, in our model we want to allow that all possible V EHICLE instance are also possible CAR instances. If so, then CAR is a dynamic subclass of V EHICLE . If not, then it is a static subclass of V EHICLE . The second principle looks at the existence sets of classes. If we can extend the existence set of STUDENT (\create" a student) without creating a PERSON , then STUDENT is a dynamic subclass of PERSON ; if not, then it is a static subclass of PERSON . Similarly, if we cannot create a CAR without by the same creation event also creating a V EHICLE , then CAR is a static subclass of V EHICLE ; otherwise, it is a dynamic subclass. The second principle can also be used to distinguish static classes from role classes. We can, for example, change the existence set of the EMP role class without changing the existence set of its player class PERSON . 16

 Counting.

| If C1 is a C0 , then if we count the number of C1 's in a set of C1 's, we get the same answer as when we count the number of C0 's in that set. played by

| If C1 ???! C0 , then if we count the number of C1 's in a set, we may get dierent answer as when we count the number of C0 's represented by the same set.  Identity. | If C1 is a C0 , then an instance of C1 is identical to an instance of C0 . played by

| If C1 ???! C0 , then an instance of C1 cannot be identical to any instance of C0 .

Figure 12: Tests to distinguish (static and dynamic) is a classi cations from role-playing. C1 is a C2 is a is a C2 . C1 and C1 ??! stands for C1 ?!

3.3 Distinguishing role classes from (static and dynamic) subclasses

The dierence between role classes and (static and dynamic) subclasses lies in the fact that an instance of a subclass is identical to (i.e. has the same identi er as) an instance of its superclass but that an instance of a role class is dierent from any instance of its player class. Figure 12 contains dierent ways to formulate this principle. For example, if counting the number of passengers in a set of passengers gives the same answer as counting the number of persons in the same set, then played by PASSENGER is a PERSON ; otherwise, PASSENGER ???! PERSON . Consider the dierence between modeling EMPLOY EE as a dynamic class and as a role class ( gure 13). In both cases, a PERSON instance who is not an EMPLOY EE may become an employee. However, in the rst case, an instance e of EMPLOY EE is identical to a PERSON in a certain state. A person is therefore related by the is a arrow to at most one employee. In the second case, an instance e of EMPLOY EE is dierent from any PERSON instance. A person can be related by the played by arrow to any number of employees (including 0), but every existing employee is related by the played by arrow to exactly one existing person. Modeled as a role, e is a state related to a person, but modeled as an instance of a dynamic subclass, it is a person in a certain state. Note that if the cardinality constraint on the played by arrow would be 0, 1, then one person could still play many dierent employee roles in sequence.

4 Comparison with other approaches to object migration and role playing There is no uniform terminology connected with object migration. The term \role" has been used for what we call dynamic class as well as what we call role. Other terms that have been used are \aspect" [51], \perspective" [5] and \mode" [67]. Reimer [48] surveys the uses and meanings of the role concept until 1985. The concept of a role seems to have surfaced in data modeling around 1977, when Bachman and Daya [2] introduced it in the context of a network approach to data modeling. For Bachman and Daya, a role is a \behavior pattern which may be assumed by entities of dierent kinds." They allow a role to be played by instances of dierent types of entities (e.g. the employer role can be played by persons, companies and government organizations) but confuse this with the possibility of one role to be played by several entities simultaneously. They do not consider the possibility of roles being played by other roles and have no concept of role (or object-) identi er. 17

EMPLOY EE

is a

PERSON

NON EMPLOY EE

EMPLOY EE

played by

PERSON

Figure 13: In the upper diagram, EMPLOY EE is a dynamic subclass of PERSON and any person is at any moment either exactly one EMPLOY EE or exactly one NON EMPLOY EE . In the lower diagram, EMPLOY EE is a role class of PERSON and any PERSON can at any moment be 0, 1 or more employees. Sciore [56] de nes roles in a system that follows a prototype-based paradigm. There are no class names in Sciore's language, and objects must be created by cloning them from a template. All objects in Sciore's system are roles (in our terminology), related to each other by what we call a played-by relationship. Just as in our approach, a role can delegate the answering of a message to its player in the played-by tree. The analyst can de ne objects that act as classes and are used as templates for the creation of other objects. The cardinality of each role is at most one, i.e. an object can play at most one role of each class. There is a template hierarchy that constrains the role-playing hierarchies, but any role-playing structure that is compatible with the template hierarchy is allowed. Like all prototype-based approaches, Sciore's system is very exible but pays for this exibility in terms of complexity of the resulting structure. Our approach attempts to preserve some of the exibility of instance-based inheritance (i.e. delegation) as used in prototype-based systems, while at the same time also preserving the structural simplicity of class-based systems. Taivalsaari [67] de nes a mode of a class as an implementation of the operations provided by the class. Each class can have several modes, in which it reacts dierently to incoming messages. For example, the WINDOW class may have modes OPEN , CLOSED and ICONIFIED, and in each of these modes will react dierently on messages open, refresh and iconify. A mode can provide mode-speci c operations, not de ned for the class whose mode it is. There are two ways to change mode. One is by means of explicit mode transition events, and the other is by means of implicit mode transitions, which may be triggered as a side-eect of other operations. For example, a pop event may change the mode of a stack from non-empty to empty. Modes are inherited by subclasses. Due to the complexity of the interaction between the class inheritance hierarchy and mode de nition, only single inheritance is allowed. Modes are clearly equivalent to our dynamic subclasses. Pernici [46] introduces roles in a language for oce automatization. As in our approach, she allows multiple instances of a role class per player. However, she does not allow roles to play roles, as we do. 18

There is no explicit consideration of role identi ers or cardinality constraints in her model. However, she de nes life cycles of roles and considers the issue concerned with parallel execution of roles. Richardson and Schwarz [51] introduce roles under the name of aspects. Although they do not de ne identi ers explicitly, aspects and objects have dierent identity criteria. They do allow aspects to have aspects, but do not use role identi ers and hence cannot represent the possibility of one object (or role) playing several instances of one role class simultaneously. Roles can be played by entities of dierent types in their model. Their model is very similar to the Clover model of Stein and Zdonik [64]. In both models, an object consists of a core of attributes and methods that it has throughout its life, and a set of extensions, which are chunks of attributes and methods that it may acquire or lose during its lifetime. Albano et al. [1] introduce the dynamic class concept under the name of roles in their data modeling language Fibonacci. In this language, an object consists of a set of \roles " and a message dispatcher, which resolves incoming messages by dispatching them to the appropriate \role" of the object. If the message cannot be answered by any of the \roles", the system searches for the most speci c \role" below the object in the inheritance hierarchy. If there is more than one such role, the most recently acquired is chosen to answer the message. \Role" types can be dynamically de ned in Fibonacci. Elmasri et al. [14, 15] introduces the concept of role in the entity-relationship approach to data modeling. In this approach, an entity is a conceptual object that represents real-world entities, and a role of an entity is part of the life-span of an entity. A role has access to all attributes of the entity whose role it is and conversely the entity has access to all role attributes. Thus, a role class in this approach corresponds most closely to our concept of a dynamic class. In this context it is useful to point out the dierence between our concept of role and the entityrelationship concept of a weak entity. For both, existence dependence is crucial. However, roles are identi ed in a globally unique way whereas a weak entity only needs a unique identi er within the set of weak entities dependent on one parent entity. In addition, even if a weak entity would receive a globally unique identi er (thereby ceasing to be a weak entity), we would probably get an object and not a role. For example, in an employee database, CHILD is typically modeled as a weak entity belonging to the entity EMPLOY EE . If the CHILD entity type is given its own identi er, the children of an employee are not roles played by this employee. Gottlob, Schre and Rock [25] de ne a role concept that is very close to ours and show how it can be implemented in a SmallTalk-like language. The most signi cant dierences with respect to our approach are that they do not allow multiple role groups per class and that they do not specify cardinality constraints for role classes. They do allow multiple roles of one role class per player. Another similar approach to roles and dynamic classes can be found in the Troll language [13, 12, 30]. The concept of dynamic role in Troll is similar to our role concept, although there is no separate identi cation mechanism for dynamic roles and there is no possibility to play multiple roles of the same role class. Dynamic roles inherit properties of the player by a standard inheritance mechanism rather than by delegation. Our concept of dynamic class corresponds roughly to the concept of derived role in Troll. For each derived role a specialization condition on attributes of the player object de nes when the player starts or ceases playing the role. We have not mentioned such a specialization condition here but in the formalization presented next we will de ne a class predicate for each dynamic class, which can be de ned to be equivalent to an arbitrary dynamic logic formula. Su [66] de nes object migration constraints as sets of dynamic subclass sequences, where each sequence represents a trace of an object through the subspaces of its state space de ned by the dynamic class partitions of the model. Allowable sequences for a person are for example

SINGLE SINGLE . MARRIED SINGLE . MARRIED . DIV ORCED SINGLE . MARRIED . DIV ORCED . MARRIED, 19

etc. He de nes several update languages, in which one can specify update programs. An update program is sound with respect to migration constraint if it only generates sequences that are contained in the set of allowable migration sequences in the migration constraint, and it is complete with respect the migration constraint if it can generate all sequences in the set. Su's results can be applied to the study of migration diagrams for dynamic subclasses. The dierence between our approach and those discussed above is that we have a clear distinction between dynamic classes and role classes, and base this distinction on a clear identi er concept. Moreover, we concentrate on methodological and logical properties of roles and dynamic classi cation, whereas most of the above approaches concentrate on implementation techniques.

5 Order-sorted dynamic database logic In this section, we present a version of dynamic logic [28, 37] that can be used to reason about database updates. This logic is a generalization of Dynamic Database Logic (DDL) de ned by Spruit [62, 63, 59]. For reasons of space, we only present the syntax and axioms, and give only a brief impression of declarative semantics. Operational semantics is not discussed at all. Details are given elsewhere [75, 60].

5.1 Syntax of order-sorted logic

We start with an exposition of order-sorted logic, following the expositions by Goguen and Meseguer [19, 21, 23]. An order-sorted signature  = ((S; ); F; P) consists of the following sets:  A partially ordered set (S; ) of sort names. We use w as a metavariable over S (strings of sort names) and extend  pointwise to strings in S of equal length. Strings over S are written as s1 


 sn .  A set F of function declarations of the form f : w ! s for w 2 S and s 2 S. s is called the result sort of f . If w = , then f is called a constant and s is called the sort of f .  A set P of predicate declarations of the form P : w for w 2 S. We only consider order-sorted signatures that are equational and that satisfy the covariance and regularity conditions:  An order-sorted signature is equational if there is a distinguished universal sort U 2 S such that s  U for all s 2 U , and there is a declaration =: U  U 2 P. We write x = y instead of = (x; y).  F satis es the covariance condition if f : w ! s, f : w0 ! s0 and w  w0 , then s  s0 .2  F satis es the regularity condition if for each w 2 S for which there is a (w0 ; s0 ) 2 S with w  w0 and f : w0 ! s0 2 F, there is a least arity (w00 ; s00 ) 2 S with w  w00 and f : w00 ! s00 2 F. Regularity guarantees that each term always has a least sort.  P satis es the regularity condition if for each w 2 sort for which there is a P : w0 2 P with w  w0 , there is a least arity w00 2 S with w  w00 and P : w00 2 P. This guarantees that dierent declarations of P are not mutually inconsistent. 2 Goguen and Meseguer call this the monotonicity condition. It is also possible to base order-sorted logic on

Cardelli's [6] contravariant condition, e.g. see [11].

20

We assume that for every sort, there is an in nite set Xs of variables and that the sets Xs are mutually disjoint for dierent s 2 S. In the following, we use a set X = fXs j s 2 Sg. The set T;s (X ) of terms of sort s over  and X is de ned as the smallest set that satis es the following conditions:  Xs  T;s (X ).  If (f : s1 


 sn ! s) 2 F, t1 ; : : : ; tn are terms of sort s1 ; : : : ; sn then f (t1 ; : : : ; tn ) 2 T;s0 (X ) for all s0  s. A term is closed if it does not contain variables, otherwise it is open. The smallest sort of a term t is called sort(t). We de ne sorts(t) = fs 2 S j sort(t)  sg. The language L (X ) of formulas over  and X is de ned inductively as follows:  If P : s1 


 sn 2 P and sort(ti )  si for terms ti , i = 1; : : : ; n, then P (t1 ; : : : ; tn ) is a formula.  If  and are formulas, then  _ and : are formulas.  If  is a formula and x a variable of sort s, then 8x : s ::  is a formula. The operators ^, $ and 9 can be introduced as usual by de nition. A formula is called closed if each variable in it is bound by some quanti er. For a treatment of the semantics of L (X ), the reader is referred to Goguen and Meseguer [21, 23]. In particular, it is shown there that speci cations over the Horn clause fragment of L (X ) (that contains only positive conditional formulas of the form  ! with  and conjunctions of positive atomic formulas) have an initial semantics.

5.2 Syntax of order-sorted dynamic database logic

We now add a requirement on signatures that will allow us to de ne the language of DDL. A dynamic database logic (DDL) signature DDL = ((S; ); F; E ; P) satis es the following requirements.  DDL contains a covariant and regular order-sorted equational signature  = ((S; ); F; P).  F is partitioned into sets FU and FN of updatable and nonupdatable function symbols, and P is partitioned into sets PU and PN of updatable and nonupdatable predicate symbols, respectively.  =: U  U 2 PN (i.e. the equality sign is declared to be nonupdatable).  There is a sort name EV ENT 2 S such that for all s 2 S dierent from EV ENT we have EV ENT 6 s and s 6 EV ENT .  E FN is a set of event declarations of the form e : w ! EV ENT , with w 2 S.  EV ENT only occurs in declarations in E , and occurs only as result sort. Note that the equality sign and event symbols are nonupdatable. A term of sort EV ENT is called an event term. The sort EV ENT is reminiscent of the msg sort in Maude [42, 44]. The logic of events in DDL is however dierent from the logic of event application in Maude (which is based on rewriting logic). Other versions of DDL contain process operators to build process terms from event terms [62, 63, 59]. We ignore process terms for now but return to them when we discuss life cycle speci cation and specialization in section 7.1. The language LDDL (X ) of formulas over DDL is de ned inductively as follows: 21

 L (X )  LDDL (X ).  If  2 LDDL (X ) and e is an event term, then [e] 2 LDDL (X ).

[e] means, intuitively, that after every possible execution of e,  is true. The dual hei is de ned as :[e]: and means that there is a possible execution of e after which  is true. A DDL speci cation Spec = (DDL ; ) is a DDL signature DDL and a nite set of closed formulas   LDDL (X ). An example of a speci cation is

sorts NATURAL, PERSON; FEMALE; MALE taxonomy MALE  PERSON , FEMALE  PERSON nonupdatable functions | Declarations of operators on NATURAL : : : updatable functions age : PERSON ! NATURAL nonupdatable predicates | Declarations of Boolean operators on NATURAL : : : updatable predicates Married : PERSON  PERSON events inc age : PERSON ! EV ENT marry : MALE  FEMALE ! EV ENT axioms 8m : MALE; f : FEMALE :: [marry(m; f )]Married(m; f ) 8m : MALE; f : FEMALE :: hmarry(m; f )itrue ! :Married(m; f )

| Axioms for inc age and for operators on NATURAL : : : Comments in the above start with a |. The rst axiom says that after an occurrence of event marry(m; f ), Married(m; f ) is true. The second axiom says that an execution of marry(m; f ) is only possible if (currently) m and f are not married. The fragment of LDDL(X ) that does not contain modal operators is interpreted in models which we call possible worlds. A formula containing modal operators is interpreted in models M each of which consists of a set of possible worlds plus, for each closed event term e, a transition relation on possible worlds. The meaning of updatability and nonupdatability is that in each M, the nonupdatable symbols have the same interpretation in all possible worlds, whereas the updatable symbols may have dierent interpretations in dierent possible worlds. For example, in a model M of the above speci cation, there are sets [ NATURAL] M, [ MALE ] M  [ PERSON ] M , [ FEMALE ] M  [ PERSON ] M , and [ EV ENT ] M, together with functions on these sets that interpret age, inc age, marry and the operators on NATURAL. In each possible world of M, Marry is interpreted as a subset of [ MALE ] M  [ FEMALE ] M . In addition, M contains a transition relation on possible worlds that says what the result of an event is. For example, if m and f are closed terms of sorts MALE and FEMALE , respectively, the transition relation that interprets marry(m; f ) leads from worlds in which :Marry(m; f ) to worlds in which Marry(m; f ) is true. The intended semantics of a LDDL (X ) speci cation is that the nonupdatable part is interpreted as an initial algebra (this puts strong restrictions on the form of axioms for nonupdatable symbols). The nonupdatable part of a speci cation thus de nes an abstract data type, which we then use as domain of the possible worlds of the model. All possible worlds have the same domain, but they may dier in the interpretation of the updatable symbols. There are several minimal-change semantics that can be given to events. More on the formal de nition of the semantics of LDDL (X ) appears elsewhere [63, 59, 70, 75]. The intended minimal change semantics of LDDL (X ) is de ned in [61]. 22

5.3 Axioms for order-sorted dynamic database logic

In the following, t stands for an arbitrary term, e stands for an arbitrary term of sort EV ENT , V ar(t) is the set of variables in the term t, sort(t) is the unique smallest sort of t (which we require to exist), t[t0 =x] is t with all occurrences of x replaced by t0 , FV () is the set of free variables in , and [t=x] is  with all free occurrences of x replaced by t. x is called free for t in  i for all variables y 6= x that occur in t, there is no subformula 8x or 9y of  such that x is free in . If x is free for t in , then replacing all free occurrences of x by t does not cause a variable in t to be \caught" by a quanti er in phi. D  X is a nite set of variable declarations. The axiom system DDL consists of the following axioms and inference rules: (Prop) All substitution instances of propositional tautologies (Inst) 8x : s ::  ! [t=x] with x free for t in  and sort(t)  sort(x) (K) [e]( ! ) ! ([e] ! [e] ) 8D :: e1 = e2 (R) 8D :: [e1 ] $ [e2 ] (Barcan) 8x : s :: [e] ! [e]8x : s ::  for x 62 V ar(e) 8D :: P (t1 ; : : : ; tn ) ! [e]P (t1 ; : : : ; tn ) where P 2 PN and ti contains only nonup(PosFr) datable function symbols (i = 1; : : : ; n). 8D :: :P (t1 ; : : : ; tn ) ! [e]:P (t1 ; : : : ; tn ) where P 2 PN and ti contains only (NegFr) nonupdatable function symbols (i = 1; : : : ; n). (Re ) 8D :: t = t where all variables in t are declared in D. 8D :: t1 = t2 (Subst) 8D :: t1 [t=x] = t2 [t=x] where sort(t)  sort(x) and all variables in ti are declared in D (i = 1; 2). 8D :: t1 = t2 (ConF) 8D :: t[t1 =x] = t[t2 =x] provided that sort(ti )  sort(x) and all variables in ti are declared in D (i = 1; 2). 8D :: t1 = t2 provided that P : C 2 P, sort(t )  C and all variables in t are i i (ConP) P (t1 ) $ P (t2 ) declared in D (i = 1; 2). 8D :: t1 = t2 (Abs) 8D [ fx : sg :: t1 = t2 provided that x : s 62 D and all variables in ti are declared in D (i = 1; 2).  ! ; (MP) (N) (U)

 [e]  8x : s :: 

This axiom system is a part of DDL axiom systems given elsewhere [63, 59, 70, 75]. The (K) axiom together with the (N) inference rule says that we have a normal (multi)modal system. The (R) axiom says that if event terms e1 and e2 are interpreted as the same element in [ EV ENT ] M, then they denote the same transition on possible worlds. This is an extremely important axiom to reason about events. Note that we may have [ e1 ] M 6= [ e1 ] M but stil [e1 ] $ [e2 ] for all . This causes no problems. The event algebra [ EV ENT ] M de nes equality of events without looking at their eect 23

on the state of the world. In the Kripke structure more events may be equivalent than are identi ed in [ EV ENT ] M , because we take additionally the eect of events into account. (PosFr) and (NegFr) are positive and negative frame assumptions for nonupdatable predicates (including =). This tells us nothing about what frame axioms to assume for updatable symbols, but, as we will see below, we can use it to prove some interesting properties of speci cations. The Barcan formula enforces a constant domain in all possible worlds. (Re ) axiomatizes the re exivity property of equality. (Transitivity and symmetry of equality is derivable from the system.) (Subst) formalizes substitution of equals for equals, and (ConF) and (ConP) require all function, attribute and predicate symbols to behave like a congruence with respect to equality. The explicit quanti cation in front of the equations is needed to avoid problems with empty sorts; completeness of the equational fragment of the logic in turn requires the (Abs) inference rule [19].

6 Using DDL as a logic for objects, class migration and roleplaying In this section we use DDL as a logic for reasoning about objects. To do this we impose a few restrictions on signatures, and thus on the generated language. The resulting language is called Dynamic Object Language (DOL). The logic of DOL speci cations is the same as that of DDL speci cations. The speci cation language LCM [16] is a syntactically sugared version of DOL.

6.1 Class speci cation

An object signature DOL = ((S; ); C ; F ; E ; A ; P; B ) consists of the following sets:  ((S; ); F; E ; P) is a DDL signature.  C  S is a set of class names such that if C 2 C , then all sort names compatible with C by  are in C .  A  F is a set of attribute declarations, which all have the form a : C ! s for C 2 C and s 2 S. All updatable function symbols are attribute symbols.  B  P is a set of predicate declarations of the form P : C for C 2 C . All updatable predicate symbols are in B .  There is a universal class CU 2 C such that C  CU for all C 2 C .  There is an updatable predicate symbol Exists : CU 2 B . Thus, an object signature is just a DDL signature with some distinguished sets of declarations and an existence predicate and with all updatable symbols unary. As will be explained in a moment, the restriction of updatable symbols to unary function and predicate symbols is not overly restrictive. A class speci cation over DOL is a pair (DOL ; E ), where E is a nite set of formulas over DOL . In the following example class speci cation, the speci cations of NATURAL and PERSON (a class) are not shown.

classes V EHICLE functions

v0 : V EHICLE next : V EHICLE ! V EHICLE

attributes

24

weight : V EHICLE ! NATURAL owner : V EHICLE ! PERSON price : V EHICLE ! NATURAL registration nr : V EHICLE ! NATURAL

updatable predicates Wreck : V EHICLE events

change owner : V EHICLE  PERSON  NATURAL ! EV ENT change weight : V EHICLE  NATURAL ! EV ENT

axioms | 1. Static integrity constraint. 8v : V EHICLE :: weight(v) < 10000 | 2. Static integrity constraint. 8v1 ; v2 : V EHICLE :: v1 = v2 $

registration nr(v1 ) = registration nr(v2 ) | 3. Axiom de ning the eect of change owner. 8v : V EHICLE; p : PERSON; m : NATURAL :: [change owner(v; p; m)]owner(v) = p ^ price(v) = m | 4. Necessary precondition for success of change owner. | A vehicle can only be sold when it is not a Wreck. 8v : V EHICLE; p : PERSON; m : NATURAL :: hchange owner(v; p; m)itrue ! :Wreck(v) | 5. Eect axiom for change weight. 8v : V EHICLE; n : NATURAL :: [change weight(v; n)]weight(v) = n The function declarations for the V EHICLE class de ne in nitely many closed terms of sort V EHICLE of form nextn (v0 ) for n  0. We view these as formal counterparts of internal (system-generated) V EHICLE identi ers. Thus, in our intended initial algebra semantics of the nonupdatable part of the speci cation, for each n  0 the congruence class of nextn (v0 ) serves as internal identi er of a vehicle. It is this congruence class that in the initial algebra approach represents a data value; and we said earlier that it is this value that can serve as identi er for an object. Because our approach is based on algebraic speci cation of abstract data types, it is easy to extend the speci cation technique to the speci cation of relationship objects, and this in turn allows the de nition of n-ary updatable functions and predicates disguised as unary updatable functions and predicates. If we want to de ne an n-ary function or predicate for n > 2, then we can de ne a relationship class with the appropriate components and declare the desired function or predicate in this relationship class with a unary arity. For example, suppose we want to de ne the updatable binary Overdue(d; m) to express that a library member m is overdue with his or her obligation to return a document d. We then de ne a relationship class, say LOAN = DOCUMENT  MEMBER, whose instances are relationships that are identi ed by a tuple hd; mi, where d is a DOCUMENT identi er and m a MEMBER identi er. The Overdue predicate can then be de ned as a unary updatable predicate with argument type LOAN . More details on de ning relationship classes are given elsewhere [16]. The attributes and predicates hold the state of V EHICLE s and the events de ne the local state changes of V EHICLE instances. Axioms using updatable symbols but containing no modalities are called static integrity constraints. By axiom 2, the value of registration nr(v) can be used as external (visible to the user) identi er of v. The proof system of DDL can be used to prove properties of speci cations. For example, we can derive a precondition for the application of change weight. The bracketed numbers in the following refer to axioms in the vehicle speci cation, the unbracketed numbers refer to lines in the proof. 25

1 8v : V EHICLE; n : NATURAL :: [change weight(v; n)]weight(v) = n 2 8v : V EHICLE :: weight(v) < 10000 3 weight(v) < 10000 4 8v : V EHICLE; n : NATURAL :: [change weight(v; n)]weight(v) < 10000 5 8v : V EHICLE; n : NATURAL :: [change weight(v; n)]n < 10000 6 8v : V EHICLE; n : NATURAL :: hchange weight(v; n)itrue ! hchange weight(v; n)in < 10000 7 8v : V EHICLE; n : NATURAL :: :n < 10000 ! [change weight(v; n)]:n < 10000 8 8v : V EHICLE; n : NATURAL :: hchange weight(v; n)in < 10000 ! n < 10000 9 8v : V EHICLE; n : NATURAL :: hchange weight(v; n)itrue ! n < 10000

(5) (1) 2, (Inst) (U), (N), 3 1, 4, (ConF) 5 (NegFr) 7 6, 8

6.2 Generating frame axioms

The axioms in the speci cation of the events change owner and change weight have a minimal change, maximal reachability semantics as intended semantics. This intended semantics is not captured by the axioms that the user has given. Instead of burdening the user with the requirement that he or she must state all frame axioms for everything that doesn't change, we generate the frame axioms from the above speci cation. Four kinds of axioms are generated. determinism axioms The execution of an event can't lead to two dierent states. inertia axioms Attributes that don't explicitly get a new value, remain unchanged. locality axioms Attributes that are explicitly updated, keep the same values for objects dierent from the object currently updated. maximal reachability axioms Whenever the axioms of a speci cation allow for the existence of a successor world, a successor world exists. Generation of frame axioms is proposed by Reiter [49, 41] as one possible way to solve the frame problem. We leave the explanation of how the above kinds of frame axioms can be generated in our framework to a dierent paper [61]. Here, we just list the axioms that are generated for the change owner and change weight events in the example V EHICLE speci cation.

generated determinism axioms 8v : V EHICLE; p : PERSON; m : NATURAL; FV () :: hchange owner(v; p; m)i ! [change owner(v; p; m)] 8v : V EHICLE; n : NATURAL; FV () :: hchange weight(v; n)i ! [change weight(v; n)] generated inertia axioms 8v; v0 : V EHICLE; p : PERSON; m; n : NATURAL :: weight(v0 ) = n $ [change owner(v; p; m)]weight(v0 ) = n 8v; v0 : V EHICLE; p : PERSON; m; n : NATURAL :: registration nr(v0 ) = n $ [change owner(v; p; m)]registration nr(v0 ) = n 8v; v0 : V EHICLE; p : PERSON; m : NATURAL :: Wreck(v0 ) $ [change owner(v; p; m)]Wreck(v0 ) 26

8v; v0 : V EHICLE; p : PERSON; n : NATURAL :: owner(v0 ) = p $ [change weight(v; n)]owner(v0 ) = p 8v; v0 : V EHICLE; m; n : NATURAL :: price(v0 ) = m $ [change weight(v; n)]price(v0 ) = m 8v; v0 : V EHICLE; p : PERSON; n; n0 : NATURAL :: registration nr(v0 ) = n0 $ [change weight(v; n)]registration nr(v0 ) = n0 8v; v0 : V EHICLE; n : NATURAL :: Wreck(v0 ) $ [change weight(v; n)]Wreck(v0 ) generated locality axioms 8v; v0 : V EHICLE; p; p0 : PERSON; m : NATURAL :: v0 = 6 v ! (owner(v0 ) = p0 $ [change owner(v; p; m)]owner(v0 ) = p0 ) 0 8v; v : V EHICLE; p : PERSON; m; m0 : NATURAL :: v0 = 6 v ! (price(v0 ) = m0 $ [change owner(v; p; m)]price(v0 ) = m0 ) 0 8v; v : V EHICLE; p : PERSON; n; n0 : NATURAL :: v0 = 6 v ! (weight(v0 ) = n0 $ [change weight(v; n)]weight(v0 ) = n0 ) generated maximal reachability axioms 8v : V EHICLE; p : PERSON; m : NATURAL :: :Wreck(v) ! hchange owner(v; p; m)itrue 8v : V EHICLE; n; : NATURAL :: true ! hchange weight(v; n)itrue

In the generated determinism axiom, FV () is short for all variable declarations for variables occurring free in . The generated axioms can be used to prove properties of the change owner event. For instance, we need the generated axioms to prove that if a car is not a wreck, then after changing its weight, it is still possible to change the owner of the car (because changing the weight of the car can't turn it into a wreck). We prove this as follows. 1 8v; v0 : V EHICLE; n : NATURAL :: Wreck(v0 ) $ [change weight(v; n)]Wreck(v0 ) 2 8v : V EHICLE; n : NATURAL :: :Wreck(v) ! [change weight(v; n)]:Wreck(v) 3 8v : V EHICLE; p : PERSON; m : NATURAL :: :Wreck(v) ! hchange owner(v; p; m)itrue 4 8v : V EHICLE; p : PERSON; m; n : NATURAL :: :Wreck(v) ! [change weight(v; n)]hchange owner(v; p; m)itrue

inertia 1 max reach 2, 3

6.3 Specifying static partitions

We saw in the vehicle example that the extension of a class is just the set of internal identi ers generated for the class, and that we generate these identi ers by declaring a constant v0 , which we will call a seed, and a function next, which we will call a generator. This idea is generalized to all static partitions: We specify a seed and a generator for every species and we do not specify a seed or generator for any other class. Note that the requirement that we have species makes the implementation of this idea simpler than would otherwise have been the case. To implement the above idea, we must explicitly declare all species, and, in general, this can require the declaration of a large number of intersection classes. To avoid this, we drop all seeds and generators from a speci cation and add some syntactic sugar to indicate what the static partitions in a speci cation are:

classes

CAR; TRUCK; OTHER V EHICLE static partition of V EHICLE GAS; DIESEL; OTHER ENGINE static partition of V EHICLE

This suces to declare the static taxonomic structure in the intended semantics of the speci cation. That is, in the initial semantics of the abstract data type de ned by the nonupdatable part of the 27

speci cation, a static taxonomic structure is de ned by placing a seed and a generator in every species. The details of this are straightforward but tedious and we omit them.

6.4 Specifying dynamic partitions

A dynamic object signature DOL is a tuple ((S; ); C S ; C D ; F; E ; A ; P; B ) that satis es the following requirements:  ((S; ); C S [ C D ; F; E ; A ; P; B ) is an object signature.  C S and C D are disjoint. Their elements are called static and dynamic class symbols, respectively.  If C 0 2 C D and C  C 0 , then C 2 C D .  For each C 2 C D , the set fC 0 2 C S jC  C 0 g is non-empty and has a unique smallest element, which we call the natural kind of C , written as C 0 = nk(C ).  For each C 2 C D , there is an updatable function symbol rnk C !C : nk(C ) ! C , called a retract for C .  For each C 2 C D , there is a class predicate PC : C 2 B . Thus, classes are partitioned into static and dynamic classes. All subclasses of a dynamic class are dynamic, and each dynamic class has a unique least upper bound in the set of static classes. Finally, each dynamic class has a retract and an updatable class predicate. The use of retracts and class predicates is illustrated in a moment. Retracts have been introduced by Goguen, Jouannaud and Meseguer [18]. Class predicates are used in FOOPS, OBJ and EQLOG [20, 22]. Retracts have not been used before to de ne dynamic subclasses. A dynamic subclass speci cation is a class speci cation over L(DOL) containing for each retract rC0 !C : C 0 ! C , an axiom ( )

8x : C 0 ::  $ rC0 !C (x) = x: The formula  says exactly when an object is an instance of the dynamic subclass C . The intended semantics of a dynamic subclass speci cation is that seeds and generators are only de ned for static subclasses and not for dynamic subclasses. The use of retracts and class predicates is illustrated in the following example.

static classes V EHICLE dynamic classes ACTIV E; WRECK taxonomy ACTIV E  V EHICLE WRECK  V EHICLE updatable functions

rV EHICLE!ACTIV E : V EHICLE ! ACTIV E rV EHICLE!WRECK : V EHICLE ! WRECK

updatable predicates

Active : V EHICLE Wreck : V EHICLE

events

28

wreck the car : V EHICLE ! EV ENT create : V EHICLE ! EV ENT

axioms | 1, 2. Active and Wreck partition the states of a V EHICLE . 8x : V EHICLE :: :(Active(x) ^ Wreck(x)) 8x : V EHICLE :: Active(x) _ Wreck(x) | 3. All Active vehicles have sort ACTIV E . 8x : V EHICLE :: Active(x) $ rV EHICLE!ACTIV E (x) = x | 4. All Wrecked vehicles have sort WRECK . 8x : V EHICLE :: Wreck(x) $ rV EHICLE!WRECK (x) = x | 5. All ACTIV E vehicles are Active. 8x : ACTIV E :: Active(x) | 6. All WRECK s are Wrecked. 8x : WRECK :: Wreck(x) | 7. Object creation 8x : V EHICLE :: [create(x)]Exists(x) ^ Active(x) | 8. Class migration. 8x : ACTIV E :: [wreck the car(x)]Wreck(x)

V EHICLE is the natural kind of ACTIV E and WRECK . Note that we may very well have static subclasses like CAR and TRUCK of V EHICLE . Thus, the natural kind of a dynamic class need

not itself be a smallest class in the set of static classes. Axioms 1 and 2 are called the partition axioms for the Active, Wreck partition. The retract axiom (3) states that the retract of ACTIV E is the identity function precisely when the sort predicate Active is true. Axiom (4) says something analogous for WRECK . These axioms show that there is a redundancy between class predicates and retracts. We still introduce class predicates as well as the retract, because both are convenient at dierent places for reasoning about dynamic subclasses. Axioms (5, 6) are called class predicate axioms. They say that Active is a necessary condition for being an instance of ACTIV E and that Wreck is a necessary condition for being a WRECK . This is the converse of the retract axioms (3, 4), which say that if for a V EHICLE x we have Active(x), then x is of type ACTIV E . Together, these axioms provide the connection we want between dynamic subclasses and class predicates.3 Axioms 1, 7 and modal reasoning allow us to prove from the speci cation that 8x : V EHICLE :: [create(x)]Exists(x) ^ Active(x) ^ :Wreck(x): We simplify the examples by adding some syntactic sugar in the form of a declaration of a dynamic subclass partition for each dynamic partition, that summarizes the declaration of class predicates, conditional retracts, and their axioms. Using this syntactic sugar, the above example can be abbreviated to the following:

classes ACTIV E; WRECK dynamic partition of V EHICLE events wreck the car : V EHICLE ! EV ENT create : V EHICLE ! EV ENT axioms 8v : V EHICLE :: [create(v)]Exists(v) ^ Active(v)

3 Dynamic subclasses could also have been de ned by means of sort constraints [18, 43]. We use retracts, because the logic of sort constraints is not yet clear to us.

29

8v : ACTIV E :: [wreck the car(x)]Wreck(x)

Note that it is useful to have both sort names for dynamic classes as well as class predicates. The sort names allow us to declare predicates and attributes that are applicable to dynamic subclasses only; the class predicates allow us to specify class migration easily.

6.5 Specifying roles

A role signature DOL is a tuple ((S; ); C S ; C D ; R; F ; E ; A ; P; B ) that satis es the following requirements.  ((S; ); C S [ R; C D ; F; E ; A ; P; B ) is a dynamic object signature.  R is disjoint from C S .  For every R 2 R there is exactly one C 2 C S [ C D [ R such that there is a declaration played by : R ! C 2 A .  A contains no loop of declarations played by : C0 ! C1 , : : :, played by : Cn ! C0 . played by   and played by are disjoint, i.e. at most one of s1  s2 and s1 ???! s2 can be the case.

Thus, roles can have static and dynamic partitions and they can be played by an instance of a static or dynamic subclass, as well as by a role. Note that we require there to be exactly one player class for each role class. This player class may however have subclasses. An example role speci cation follows:

static classes PERSON role classes STUDENT , EMP functions

s0 : STUDENT e0 : EMP next : STUDENT ! STUDENT next : EMP ! EMP

attributes

played by : STUDENT ! PERSON played by : EMP ! PERSON

events become student : PERSON  STUDENT ! EV ENT axioms | 1, 2. A role is dierent from its player. 8s : STUDENT :: :played by(s) = s 8e : EMP :: :played by(e) = e | 3. De ne STUDENT , EMP as role group of PERSON . 8s : STUDENT; e : EMP :: :played by(s) = played by(e) | 4, 5. Existence of players required. 8s : STUDENT :: Exists(s) ! Exists(played by(s)) 8e : EMP :: Exists(e) ! Exists(played by(e)) | 6, 7. become student is a role creation event. 8p : PERSON; s : STUDENT :: hbecome student(p; s)itrue ! :Exists(s) 8p : PERSON; s : STUDENT :: [become student(p; s)]Exists(s) ^ played by(s) = p 30

Axioms 1 and 2 are called player dierence axioms. Axiom 3 is called a role group axiom and axioms 4 and 5 player existence axioms. It is easy to prove with the above axioms that

8p : PERSON; s : STUDENT :: [become student(p; s)]Exists(p) ^ Exists(s) and

8p : PERSON; s : STUDENT; e : EMP :: [become student(p; s)]played by(e) = 6 played by(s):

We can generate a locality axiom (similar to the generated axioms for the V EHICLE example) which tells us that the truth value of Exists(p) doesn't change when we execute the event become student(p; s). (Note that in this view, become student(p; s) is local to s, and a name like create student(s; p) would therefore be more intuitive.) With this locality axiom, we can derive

8p : PERSON; s : STUDENT :: hbecome student(p; s)itrue ! Exists(p) ^ :Exists(s):

This gives us a necessary precondition for the occurrence of become student(p; s). A possible addition is to ensure that upon creation, a role has a fresh identi er, never used before. This can be easily done by introducing a predicate Used that in every state of the world has as extension the set of all instances of STUDENT and EMP that have been created (added to the existence set). It is a trivial matter to add the appropriate axioms to the speci cation, and we omit it here. We can again de ne some syntactic sugar, in the form of a role group declaration, to abbreviate the speci cation:

classes STUDENT; EMP role group of PERSON events become student : PERSON  STUDENT ! EV ENT axioms 8p : PERSON; s : STUDENT; e : EMP :: hbecome student(p; s)itrue ! :Exists(s) ^ Exists(p) ^ :played by(e) = p 8p : PERSON; s : STUDENT :: [become student(p; s)]Exists(s) ^ played by(s) = p The role group of section abbreviates the part of the functions section that In addition, it is shorthand for the player dierence, role group and player existence axioms.

6.6 Delegation

In the syntax introduced so far, an attribute application like age(s) for s of type STUDENT is a type error. This can be circumvented by having the parser of an application a(t) resolve any type mismatches between the expected argument sort of a and the sort of t by the insertion of played by functions. Thus, if a : C1 ! C2 and C1 is not among the sorts of t, then the parser would replace a(t) by a(played by(t)) and see if the mismatch still exists. If the mismatch still exists and sort(played by(t)) is a role class, then this can be repeated. Because there are no loops in played by declarations and the  and played by relations are disjoint, the played by graph does not contain cycles, this replacement process will terminate. The term a(s) will now be replaced, by the parser, by age(played by(s)) and this term can be parsed correctly. This replacement process is a compile-time version of delegation: 31

s delegates the answering of the age message to its player. Note that in DOL, we allow only one player class of a role class. This means that if we want to let objects of class C1 ; : : : ; Cn be possible players of roles of class R, then we should de ne a supertype C  Ci (i = 1; : : : ; n) and de ne C to be the player class of R.

6.7 Cardinality constraints

Until now, we have not discussed the formalization of cardinality constraints. In general, we may want to specify constraints such as each person can only play at most one STUDENT role at the same time. Cardinality constraints can be speci ed by de ning an inverse of the played by attribute, say inv played by : PERSON ! STUDENTS , where STUDENTS is the type of nite sets of STUDENT instances. The speci cation of a (parametrized) set type and of the axioms relating played by and inv played by are straightforward and are omitted here. We can then specify a cardinality constraint on the STUDENT role by an axiom like 8p : PERSON :: card(inv played by(p))  1: More details on this are given elsewhere [69].

7 Discussion

7.1 Life cycle speci cation

DDL contains the regular operators + (choice) ; (sequence) and * (iteration) to build process terms [62, 63, 59] out of atomic actions. The idea is that these process terms are update programs and that DDL can be used as a logic to reason about the pre{ and postconditions of these programs. In DOL, we use process terms at a higher level of aggregation to de ne life cycles. The postconditions of these life cycles are not of interest for us, so we do not intend to reason about these (possibly nonterminating) life cycles by means of dynamic logic. In order to de ne life cycles, we add a sort PROCESS such that EV ENT  PROCESS to the nonupdatable part of the speci cation, and we de ne operators + (choice), ; (sequence), k (parallel composition) and & (event synchronization) with arity

PROCESS  PROCESS ! PROCESS:

There is a wide choice of possible axioms for these operators, provided by the theory of process algebra [3]. For example, most process theories include axioms such as X +Y =Y +X X +X =X (X + Y ); Z = X ; Y + X ; Z , where X , Y and Z are variables of sort PROCESS . In the semantics, the event algebra is extended to a process algebra [ PROCESS ] M . The life cycle of the instances of a class C is de ned in DOL by adding a recursive process de nition to the speci cation of C . This consists of a set of equations in which the main variable has the same name as C . The equations may be recursive, i.e. the same variable may occur on the left as well as on the right hand side of an equals sign. The set is to be viewed as a conjunctive formula, that has a set of solutions in [ PROCESS ] M . Under certain conditions, spelled out in the theory of process algebra, the equations have exactly one solution [3]. We require a life cycle de nition to have exactly one solution, which is the life cycle de ned for instances of C . For example, the V EHICLE life cycle of gure 8 can be speci ed in the V EHICLE class de nition as follows: 32

V EHICLE = produce; V EHICLE LIFE . V EHICLE LIFE = sell; V EHICLE LIFE + destroy. The V EHICLE and V EHICLE LIFE variables are implicitly declared as process variables. Because V EHICLE is also the name of the class whose instance life cycle is being de ned, the value of V EHICLE in the solution of this set of equations is the life cycle of V EHICLE instances. This value can be represented as the graph shown in gure 8. In the same way, the CAR life cycle can be de ned in the CAR class speci cation as follows: CAR = produce; CAR LIFE . CAR LIFE =sell; CAR LIFE + wreck; POSSIBLE DESTROY + steal; POSSIBLE WRITE OFF . POSSIBLE DESTROY = repair; CAR LIFE + destroy. POSSIBLE WRITE OFF = find; CAR LIFE + write off . As stated earlier, it depends upon the theory of life cycle specialization whether this is a valid specialization of the V EHICLE life cycle. Currently, the life cycles of the elements of a dynamic partition must be speci ed integrally as part of the life cycle of the superclass. This is not a satisfactory situation, and we are currently searching for extensions to the process de nition mechanism of process algebra to deal with this situation. One possibility is the mode transfer operator de ned by Bergstra [4], which allows one to jump out of a process to start another process. The marry operator would then for example terminate the SINGLE subprocess of PERSON and start the MARRIED subprocess. Outside the theory of process algebra, possible formalizations include StateCharts [29] and Schre 's behavior diagrams [55], which are based on Petri nets. Formalization of dynamic life cycle specialization is still a subject of current research.

7.2 Comparison with other modal logic formalizations of objects

DOL resembles Modal Action Logic [24, 32, 36, 53], which has been introduced as a variant of dynamic logic to specify database updates. Just like DOL (and DDL), the intended semantics of MAL models have a constant domain, and an existence predicate is used to allow quanti cation over the set of currently existing objects. Unlike DOL (and DDL), the constants in the MAL intended semantics are not rigid designators, i.e. in dierent possible worlds they may refer to dierent entities. Interpreting constants as rigid designators is essential to formalize our view of object identi ers, and it makes reasoning about equality simpler. MAL uses a slightly dierent axiom system than DDL and DOL (e.g. determinism of actions is not required in MAL). MAL has been used as a vehicle of research in the speci cation of database views [36], the speci cation of object-oriented systems [53], and the speci cation of reactive systems [32]. Another closely related logic-based language is Troll [30], itself developed on the basis of the Oblog language [9, 57]. Troll uses temporal logic to de ne the eect of events, dynamic integrity constraints, and object life cycles. As discussed earlier, it contains constructs to de ne dynamic roles (reminiscent of our roles) and derived roles (our dynamic subclasses). The language-independent part of this paper is intended to be compatible with the use of these other speci cation languages.

8 Conclusions We have shown that there is a clear dierence between static and dynamic subclasses, and, independently from that, between object classes and role classes. We have also shown how these taxonomic structures can be speci ed in an order-sorted logic and how we can specify class migration and role 33

playing in a subset of Dynamic Database Logic. For each of the taxonomic constructs, we gave methodological principles which can be used to discover which kind of class is being modeled. These principles are language-independent. Conditional retracts and class predicates are used to specify class migration, and a very simple delegation mechanism is de ned for roles. These constructs are not completely language-independent, but they are presented in such a way that they may feasibly be combined with particular logical object speci cation languages, such as LCM [16], Troll [34] and Oblog [9]. Acknowledgements: This paper pro ted from discussion with Jacques van Leeuwen and from comments given on an earlier versions by Remco Feenstra, Wiebe van der Hoek and Maarten de Rijke. A discussion with Gerti Kappel and Michael Schre clari ed upward life cycle inheritance. Thanks are due to the anonymous referees for their constructive comments, which led to the elimination of some errors as well as the addition of some signi cant material.

References

[1] A. Albano, R. Bergamini, G. Ghelli, and R. Orsini. An object data model with roles. In R. Agrawal, S. Baker, and D. Bell, editors, Proceedings of the 18th International Conference on Very Large Databases, pages 39{51, Dublin, Ireland, August 24{27 1993. [2] C.W. Bachman and M. Daya. The role concept in data models. In Proceedings of the Third International Conference on Very Large Databases, pages 464{476, 1977. [3] J.C.M. Baeten and W.P. Weijland. Process Algebra. Cambridge Tracts in Theoretical Computer Science 18. Cambridge University Press, 1990. [4] J.A. Bergstra. A mode transfer operator in process algebra. Technical Report P8808b, Programming Research Group, University of Amsterdam, 1988. [5] D.G. Bobrow and T. Winograd. An overview of KRL, a knowledge representation language. Cognitive Science, 1:3{46, 1977. [6] L. Cardelli. A semantics of multiple inheritance. In G. Kahn, D. MacQueen, and G. Plotkin, editors, Semantics of Datatypes, pages 51{67. Springer, 1984. Lecture Notes in Computer Science 173. [7] P. Coad and E. Yourdon. Object-Oriented Analysis. Yourdon Press/Prentice-Hall, 1990. [8] E.F. Codd. Extending the database relational model to capture more meaning. ACM Transactions on Database Systems, 4:397{434, 1979. [9] J.F. Costa, A. Sernadas, and C. Sernadas. OBL-89 User's Manual, version 2.3. Instituto Superior Tecnico, Lisbon, May 1989. [10] J. Ebert and G. Engels. Structural and behavioural views on omt-classes. In S. Urban E. Bertino, editor, Proceedings of the International Conference on Object-Oriented Systems, Methodologies, and Applications (ISOOMS'94), Palermo (Italy), September 21-23 1994. [11] H.-D. Ehrich, M. Gogolla, and U.W. Lipeck. Algebraische Spezi kation abstrakter Datentypen. B.G. Teubner, 1989. [12] H.-D. Ehrich, R. Jungclaus, and G. Denker. Object roles and phases. In U.W. Lipeck and G. Koschorreck, editors, Proceedings of the International Workshop on Information Systems { Correctness and Reusability (IS-CORE'93), pages 114{121. Institut fur Informatik, Universitat Hannover, Postfach 6009, Hannover, Germany, 1993. [13] H.-D. Ehrich and A. Sernadas. Fundamental object concepts and constructions. In G. Saake and A. Sernadas, editors, Information Systems | Correctness and Reusability, pages 1{24. TU Braunschweig, 1991. Informatik Bericht 91-03. [14] R. Elmasri, I. El-Assal, and V. Kouramajian. Semantics of temporal data in an extended er model. In H. Kangalasso, editor, Entity-Relationship Approach: The Core of Conceptual Modelling, pages 239{154. Elsevier, 1991.

34

[15] R. Elmasri and V. Kouramajian. A temporal query language based on conceptual entities and roles. In G. Pernul and A.M. Tjoa, editors, Entity-Relationship Approach {ER'92, pages 375{388. Springer, 1992. Lecture Notes in Computer Science 645. [16] R.B. Feenstra and R.J. Wieringa. LCM 3.0: a language for describing conceptual models. Technical Report IR-344, Faculty of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, December 1993. [17] D. Gabbay and J.M. Moravcsik. Sameness and individuation. The Journal of Philosophy, 70:513{526, 1973. [18] J. Goguen, J.-P. Jouannaud, and J. Meseguer. Operational semantics of order-sorted algebra. In W. Brauer, editor, Proceedings, 1985 International Conference on Automata, Languages and Programming, pages 221{231. Springer, 1985. Lecture Notes in Computer Science, Volume 194. [19] J.A. Goguen and J. Meseguer. Completeness of many-sorted equational logic. SIGPLAN Notices, 17(1):9{ 17, 1982. [20] J.A. Goguen and J. Meseguer. EQLOG: Equality, types, and generic modules for logic programming. In D. DeGroot and G. Lindstrom, editors, Logic Programming: Functions, Relations, and Equations, pages 295{363. Prentice-Hall, 1986. [21] J.A. Goguen and J. Meseguer. Models and equality for logical programming. In H. Ehrig, R. Kowalski, G. Levi, and U. Montanari, editors, Proceedings of the International Joint Conference on Theory and Practice of Software Development (TAPSOFT'87) Volume 2, pages 1{22. Springer, 1987. Lecture Notes in Computer Science 250. [22] J.A. Goguen and J. Meseguer. Unifying functional, object-oriented and relational programming with logical semantics. In B. Shriver and P. Wegner, editors, Research Directions in Object-Oriented Programming, pages 417{477. MIT Press, 1987. [23] Joseph Goguen and Jose Meseguer. Order-sorted algebra I: Equational deduction for multiple inheritance, overloading, exceptions and partial operations. Theoretical Computer Science, 105:217{273, 1992. [24] F. Golshani, T.S.E. Maibaum, and M.R. Sadler. A modal system of algebras for database speci cation and query/update support. In Proceedings of the Nineth International Conference on Very Large Databases, pages 331{359, 1983. [25] G. Gottlob, M. Schre , and B. Rock. Extending object-oriented systems with roles. ACM Transactions on Information Systems, To be published. [26] N. Guarino, M. Carrara, and P. Giaretta. An ontology of meta-level categories. In J. Doyle, E. Sandewall, and P. Torasso, editors, Principles of Knowledge Representation and Reasoning, pages 270{280, Bonn, Germany, 1994. Morgan Kaufmann. Proceedings of the Fourth International Conference. [27] P. Hall, J. Owlett, and S. Todd. Relations and entities. In G.M. Nijssen, editor, Modelling in Database Management Systems, pages 201{220. North-Holland, 1976. [28] D. Harel. Dynamic logic. In D.M. Gabbay and F. Guenthner, editors, Handbook of Philosophical Logic II, pages 497{604. Reidel, 1984. [29] D. Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8:231{274, 1987. [30] T. Hartmann, G. Saake, P. Hartel, and J. Kusch. Revised version of the modelling language TROLL (TROLL version 2.0). Technical Report 94-03, Abt. Datenbanken, Tech. Universitat Braunschweig, P.B. 3329, Braunschweig, Germany, April 1994. [31] M. Jackson. System Development. Prentice-Hall, 1983. [32] P. Jeremaes, S. Khosla, and T.S.E. Maibaum. A modal (action) logic for requirements speci cation. In D. Barnes and P. Brown, editors, Software Engineering 86, pages 278{294. Peter Peregrinus Ltd., 1986. [33] H.W.B. Joseph. An Introduction to Logic. Clarendon Press, 1916. [34] R. Jungclaus, G. Saake, T. Hartmann, and C. Sernadas. Object-oriented speci cation of information systems: The TROLL language. Technical report, Abt. Datenbanken, Tech. Universitat Braunschweig, P.B. 3329, Braunschweig, Germany, 1991.

35

[35] S.N. Khosha an and G.P. Copeland. Object identity. In Object-Oriented Programming Systems, Languages and Applications, pages 406{416, 1986. SIGPLAN Notices 22 (12). [36] S. Khosla, T.S.E. Maibaum, and M. Sadler. Database speci cation. In T.B. Jr. Steel and R. Meersman, editors, Database Semantics (DS-1), pages 141{158. North-Holland, 1986. [37] D. Kozen and J. Tiuryn. Logics of programs. In Jan van Leeuwen, editor, Handbook of Theoretical Computer Science, pages 789{840. Elsevier Science Publishers, 1990. [38] J. van Leeuwen. Individuals and Sortal Concepts: An Essay in Logical Descriptive Metaphysics. PhD thesis, University of Amsterdam, 1991. [39] J. van Leeuwen and H. Zeevat. Identity and common nouns in intensional logic. In J. Groenendijk, M. Stokhof, and F. Veltman, editors, Proceedings of the Sixth Amsterdam Colloquium, pages 219{241, Amsterdam, 1987. Institute for Language, Logic and Information. [40] H. Lieberman. Using prototypical objects to implement shared behavior in object oriented systems. In N. Meyrowitz, editor, Object-Oriented Programming: Systems, Languages and Applications, pages 214{223, October 1986. [41] F. Lin and R. Reiter. State Constraints Revisited. Technical report, Department of Computer Science, University of Toronto, 1994. To appear in the Journal of Logic and Computation, Special Issue on Action and Processes. [42] J. Meseguer. Solving the inheritance anomaly in concurrent object-oriented programming. In O.M. Nierstrasz, editor, European Conference on Object-Oriented Programming (ECOOP'93), pages 220{246, Kaiserslautern, July 1993. Springer. Lecture Notes in Computer Science 707. [43] J. Meseguer and J.A. Goguen. Order-sorted algebra solves the constructor-selector, multiple representation, and coercion problems. Information and Computation, 103:114{158, 1993. [44] J. Meseguer and X. Qian. A logical semantics for object-oriented databases. In Proceedings of the 1993 ACM SIGMOD International Conference on the Management of Data, pages 89{98. ACM Press, May 26{28 1993. Sigmod Record 22(2), June 1993. [45] O. Nierstrasz. Regular types for active objects. In A. Paepcke, editor, Object-Oriented Programming: Systems, Languages and Applications/European Conference on Object-Oriented Programming, pages 1{ 15. ACM, 1993. Sigplan Notices 28, number 10. [46] B. Pernici. Objects with roles. In IEEE/ACM Conference on Oce Information Systems, Cambridge, Mass., 1990. [47] W.V.O. Quine. Word and Object. MIT Press, 1960, 1964. [48] U. Reimer. A representation construct for roles. Data and Knowledge Engineering, 1:253{251, 1985. [49] R. Reiter. The Frame Problem in the Situation Calculus: A Simple Solution (Sometimes) and a Completeness Result for Goal Regression. In V. Lifschitz, editor, Arti cial Intelligence and the Mathematical Theory of Computation: Papers in Honor of John McCarthy, pages 359{380. Academic Press, San Diego, CA, 1991. [50] N. Rescher. Introduction to Logic. St. Martin's Press, 1964. [51] J. Richardson and P. Schwartz. Aspects: Extending objects to support multiple, independent roles. In ACM-SIGMOD International Conference on Management of Data, pages 298{307, Denver, Colorado, May 1991. ACM. Sigmod Record, Vol. 20. [52] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-oriented modeling and design. Prentice-Hall, 1991. [53] M. Ryan, J. Fiadeiro, and T. Maibaum. Sharing actions and attributes in modal action logic. In T. Ito and A.R. Meyer, editors, Theoretical Aspects of Computer Software, pages 569{593. Springer, 1991. Lecture Notes in Computer Science 526. [54] G. Saake, P. Hartel, R. Jungclaus, R.J. Wieringa, and R.B. Feenstra. Inheritance conditions for object life cycle diagrams. In U.W. Lipeck and G. Vossen, editors, Formale Grundlagen fur den Entwurf von Informationsystemen, pages 79{88. Institut fur Informatik, Universitat Hannover, Postfach 6009, D-30060, Hannover, May 1994. Informatik-Berichte Nr. 03/94.

36

[55] M. Schre . Behavior modeling by stepwise re ning behavior diagrams. In H. Kangassolo, editor, EntityRelationship Approach: The Core of Conceptual Modelling, pages 119{134. North-Holland, 1991. [56] E. Sciore. Object specialization. ACM Transactions on Information Systems, 7(2):103{122, 1989. [57] A. Sernadas, C. Sernadas, and H.-D. Ehrich. OBLOG | Object-Oriented Logic: an informal introduction. Technical report, INESC, Lisbon, 1991. [58] S. Shlaer and S.J. Mellor. Object Lifecycles: Modeling the World in States. Prentice-Hall, 1992. [59] P.A. Spruit. Function symbols in dynamic database logic. Technical report, Department of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, 1993. [60] P.A. Spruit. Logics of Database Updates. PhD thesis, Faculty of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, 1994. [61] P.A. Spruit, R.J. Wieringa, and J.-J.Ch. Meyer. First-order dynamic database logic. Submitted for publication. [62] P.A. Spruit, R.J. Wieringa, and J.-J.Ch. Meyer. Axiomatization, declarative semantics and operational semantics of passive and active updates in logic databases. Technical Report IR-294, Department of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, June 1992. To be published, Journal of Logic and Computation. [63] P.A. Spruit, R.J. Wieringa, and J.-J.Ch. Meyer. Dynamic database logic: The rst-order case. In U.W. Lipeck and B. Thalheim, editors, Modelling Database Dynamics, pages 103{120. Springer, 1993. [64] L.A. Stein and S.B. Zdonik. Clovers: the dynamic behavior of types and instances. Technical Report CS-89-42, Brown University, November 1989. [65] P. Strawson. Individuals. Methuen, 1959. [66] J. Su. Dynamic constraints and object migration. In G.M. Lohman, A. Sernadas, and R. Camps, editors, Proceedings of the Seventeenth International Conference on Very Large Databases, pages 233{ 242, Barcelona, Spain, September 3-6 1991. [67] A. Taivalsaari. Object-oriented programming with modes. Journal of Object-Oriented Programming, 6(3):25{32, June 1993. [68] P. Wegner and S.B. Zdonik. Inheritance as an incremental modi cation mechanism, or what like is and isn't like. In S. Gjessing and K. Nygaard, editors, European Conference on Object-Oriented Programming (ECOOP'88), pages 55{77, Oslo, August 1988. Springer. Lecture Notes in Computer Science 322. [69] R.J. Wieringa. Algebraic Foundations for Dynamic Conceptual Models. PhD thesis, Department of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, May 1990. [70] R.J. Wieringa. A formalization of objects using equational dynamic logic. In C. Delobel, M. Kifer, and Y. Masunaga, editors, 2nd International Conference on Deductive and Object-Oriented Databases (DOOD'91), pages 431{452. Springer, 1991. Lecture Notes in Computer Science 566. [71] R.J. Wieringa. Steps towards a method for the formal modeling of dynamic objects. Data and Knowledge Engineering, 6:509{540, 1991. [72] R.J. Wieringa. A method for building and evaluating formal speci cations of object-oriented conceptual models of database systems (MCM). Technical Report IR-340, Faculty of Mathematics and Computer Science, Vrije Universiteit, December 1993. [73] R.J. Wieringa and W. de Jonge. Object identi ers, keys, and surrogates. Theory and Practice of Object Systems, 1993. To be published. [74] R.J. Wieringa, W. de Jonge, and P.A. Spruit. Roles and dynamic subclasses: a modal logic approach. In M. Tokoro and R. Pareschi, editors, Object-Oriented Programming, 8th European Conference (ECOOP'94), pages 32{59. Springer, 1994. Lecture Notes in Computer Science 821. [75] R.J. Wieringa and J.-J.Ch. Meyer. Actors, actions, and initiative in normative system speci cation. Annals of Mathematics and Arti cial Intelligence, 7:289{346, 1993. [76] D. Wiggins. Sameness and Substance. Basil Blackwell, 1980.

37

Contents

1 Introduction 2 An analysis of object migration 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Classes and object identi ers : : : : : : : : : : Subclasses : : : : : : : : : : : : : : : : : : : : : Static partitions : : : : : : : : : : : : : : : : : Dynamic partitions : : : : : : : : : : : : : : : : Object migration : : : : : : : : : : : : : : : : : Role-playing and delegation : : : : : : : : : : : Life cycle inheritance and migration constraints

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

1 2

: 2 : 4 : 5 : 7 : 9 : 10 : 12

3 Methodological aspects of object migration

15

4 Comparison with other approaches to object migration and role playing 5 Order-sorted dynamic database logic

17 20

3.1 Classi cation principles : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15 3.2 Distinguishing static classes from dynamic classes and role classes : : : : : : : : : : : : 16 3.3 Distinguishing role classes from (static and dynamic) subclasses : : : : : : : : : : : : : 17

5.1 Syntax of order-sorted logic : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20 5.2 Syntax of order-sorted dynamic database logic : : : : : : : : : : : : : : : : : : : : : : 21 5.3 Axioms for order-sorted dynamic database logic : : : : : : : : : : : : : : : : : : : : : : 23

6 Using DDL as a logic for objects, class migration and role-playing 6.1 6.2 6.3 6.4 6.5 6.6 6.7

Class speci cation : : : : : : Generating frame axioms : : Specifying static partitions : Specifying dynamic partitions Specifying roles : : : : : : : : Delegation : : : : : : : : : : : Cardinality constraints : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

: : : : : : :

24 24 26 27 28 30 31 32

7 Discussion

32

8 Conclusions

33

7.1 Life cycle speci cation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 32 7.2 Comparison with other modal logic formalizations of objects : : : : : : : : : : : : : : : 33

i