7 EVOLVING LOGICALSPECIFICATION IN INFORMATIONSYSTEMSStefan Conrad,Jaime Ramos,Gunter Saake,and Cristina SernadasAbstract: Traditional logic-based speci�cation approaches �x the structureand the dynamics of an object system at speci�cation time. Information systemsare applications with a very long life-time. Therefore, object and speci�cationevolution is needed to react to changing requirements. Hence, this is a relevantaspect of describing information systems as object societies.We present a logical speci�cation framework for evolving objects. Our frame-work is based on the concepts of object developed for the languages Troll andGnome and the underlying temporal logic OSL. The syntactic notion of ob-ject descriptions is extended to explicitly manipulate temporal axioms duringbehaviour evolution. An extension of OSL called dyOSL establishes a logicalframework where basic temporal formulae are evaluated by a second logicallayer. dyOSL allows to explicitly manipulate state-dependent sets of temporalformulae to model evolution of object axioms. 199

200 LOGICS FOR DATABASES AND INFORMATION SYSTEMSThe Syntax and semantics of dyOSL are given together with a translationof the speci�cation language constructs into dyOSL. The corresponding prooftheory is discussed together with guidelines for formally certifying object prop-erties. Additionally, we show the use of the formalism for some speci�c infor-mation system scenarios.7.1 INTRODUCTIONIn the last years, logic-based approaches to specifying information systems weredeveloped and investigated. Especially, in combination with object-orientedprinciples for the design of information systems [SRGS91] a lot of work was doneto �nd adequate logic-based approaches to describe the dynamic behaviour aswell as the interaction of objects in information systems.Mainly for describing the dynamic behaviour of objects in information sys-tems, temporal logic [MP92; CT98] and dynamic logic [Har84] are good andwidely accepted choices. Because we prefer to regard information systems asstate-based systems, we adopt the state-based approach of temporal logic fordescribing information systems (c.f., [KM89]).The temporal speci�cation of information systems became a popular re-search area, especially because it is based on a clean and well-understood the-ory (c.f., e.g., [FM91; EDS93; Con96; SSR96]). Furthermore, several speci-�cation languages based on temporal logics like Albert [DDP93], Oblog[SSE87; SSG+91], Gnome [SR94], and Troll [JSHS96] have been developedfor supporting the speci�cation of objects and their dynamic behaviour.Of course there are other formal approaches to specifying dynamic behaviourof objects. For instance, conditional term rewriting [Mes93] is another way ofdescribing object behaviour and is the formal foundation behind the speci�ca-tion language Maude [Mes92; MQ93]. In the database area a lot of interestingwork concerning the description of database dynamics (e.g., in [LT93; BK98])can be found.In contrast to other approaches (like the evolving algebra approach by[Gur91; Gur93] where evolution can be seen as \state rewriting") in our con-text the notion of evolution refers to the evolution of speci�cations during theruntime of a system.However, all these approaches to specifying information systems assume thatthe dynamic behaviour of the system and its parts is totally known at speci�-cation time. In addition, once speci�ed the behaviour is �xed for the entire life(or run) time of the information system. This restriction seems not to be ade-quate for a large number of typical information system applications. Becauseof the long life- (or run-) time of information systems changes of the dynamicbehaviour are often required within the lifetime of a system.

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 201Typical examples for such changes of the dynamic behaviour can already befound in usual application areas for information systems like libraries and banks.For a library it may happen that the rules for borrowing and returning bookschange in order to avoid too much administrative work in writing reminders.Due to changes of laws (or bank rules) it could become necessary to changethe computation of yearly interests or to restrict the evolution of an account insome way. These changes are modi�cations of axioms describing the dynamicbehaviour of the system. In consequence, we have to �nd a framework fordescribing evolving speci�cations where we can specify the evolution of �rst-order dynamic behaviour speci�cations.In this paper we continue the work started in [SSS95] where a �rst, veryrestricted form of evolving temporal speci�cation was proposed. In [CS96] and[CS97] a �rst ad hoc formalization of a temporal logic allowing evolving be-haviour was presented and discussed. Di�erent ways of handling the evolutionof speci�cations within a speci�cation language were investigated in [TCS96].After having consolidated this preparatory work we are now able to present aproposal for an adequate speci�cation language together with a formal de�ni-tion of an extended temporal logic for specifying objects and their behaviourwhich may be dynamically modi�ed.For the logical part we build on the Object Speci�cation Logic OSL proposedin [SSC95]. For our purposes we need to distinguish two logical levels: the �rstlevel allows the usual temporal speci�cation of the objects' behaviour by meansof OSL, and the second level allows us to deal with behaviour evolution. By thisseparation into two levels we are able to de�ne a clean extension of OSL. For thepurposes of this paper, we focus the presentation on the treatment of behaviourevolution and ignore object-oriented concepts like inheritance. Incorporatingthose concepts into our logic can be done in the same way as it has been donefor the original OSL in [SSC95].The remainder of this paper is organized as follows: In Section 7.2 we in-troduce and discuss an example speci�cation for documents in an informationsystem managing o�ers and contracts in a sales department. By means ofthis example we motivate the need for evolving behaviour speci�cation and weadditionally introduce the basic parts of a corresponding object speci�cationlanguage. In Section 7.3 we de�ne syntax and semantics of the logic, calleddynamic OSL (dyOSL). Afterwards, we show how to translate the interestingparts of speci�cations, namely the evolving behaviour part, into dyOSL (Sec-tion 7.4). The usage of our logical framework in proving properties of objectsfrom their speci�cation is brie y dealt with in Section 7.5. Finally, we concludeby summarizing the approach presented in this paper and by pointing out openquestions for future work.

202 LOGICS FOR DATABASES AND INFORMATION SYSTEMS7.2 MOTIVATION AND LANGUAGEIn this section, we discuss the limitations of current object-oriented speci�ca-tion approaches using temporal logic for describing the dynamic behaviour ofobjects. In order to overcome these limitations we propose an extension allow-ing evolution of the dynamic behaviour of objects. As starting point we useTroll [JSHS96]. By means of examples we motivate the extensions of thelogic that are needed.Example 1 In an information system for the sales department of an enterpriseall o�ers made to customers and all contracts with customers are to be managed.In Figure 7.1 a speci�cation of an object class for documents (as a unifying notionfor o�ers and contracts) is given using a Troll-like speci�cation language.Here, documents have four attributes. The document number `DocNo' is uniquefor each document. In the identi�cation part the attribute `DocNo' is speci�ed tobe used for identifying document objects. Therefore, there must not be duplicatedocument numbers. The document type `DocType' states whether a document iscurrently an o�er made to a customer, a preliminary contract which has to be con-�rmed by the customer, or already an o�cial (legal) contract. The attribute `Valid'provides a date until an o�er or a preliminary contract is valid. The document textis stored as a value of the attribute `Content'.There are �ve kinds of events (actions) which may occur for document ob-jects. The occurrence of a `create' event denotes the birth of a document object,i.e., a new document is created. During the existence of the object `revise', `pre-pare contract', and `�x contract' events may occur. A document is deleted whena `resolve' event occurs for the corresponding object. The e�ect of each of theseevents is described in the rigid axioms part. Therefore, the occurrence of a `cre-ate' event results in the speci�ed values for the attributes. Moreover, the event`addDocToO�ers' is called in another object which has the name `DocManager'(assuming that this object is speci�ed elsewhere).In addition to their e�ect on attribute values and the \calling" of other eventswe impose enabling conditions for `revise', `prepare contract', and `�x contract'events. We use the term \calling" for events in the sense of [SE91]: if one eventcalls another event this means that the occurrence of the �rst event causes asimultaneous occurrence of the second event. In this way we have a means tospecify a directed synchronization of event occurrences.By imposing enabling conditions, events are only allowed to occur if the corre-sponding enabling condition is satis�ed. The calling of other events can also becombined with additional pre-conditions. For instance, the occurrence of a `re-solve' event may cause the occurrence of two di�erent events in the object called`DocManager'. Which of these two events is called depends on the value of theattribute `DocType'.

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 203object class Documentsidenti�cation DocId: (DocNo)templateattributesDocNo: int,DocType: fo�er, pre contract, contractg,Valid: date,Content: text;actionsbirth create(DocNo:int,Content:text),revise(NewContent:text),prepare contract,�x contract,death resolve;rigid axiomscreate(D,C)changing DocType = o�er,DocNo = D,Content = C,Valid = now + 30calling DocManager.addDocToO�ers(self);revise(C)enabled DocType = o�er and Valid � now,changing Valid = now + 30,Content = C;prepare contractenabled DocType = o�er and Valid � now,changing DocType = pre contract,Valid = now + 10,Content = C;�x contractenabled DocType 6= contract and Valid � now,changing DocType = contract,calling DocManager.mvO�erToContracts(self);resolvecalling[DocType6=contract] DocManager.mvO�erToArchive(self),[DocType=contract] DocManager.mvContractToArchive(self);end object classFigure 7.1 A speci�cation of documents.

204 LOGICS FOR DATABASES AND INFORMATION SYSTEMSThe possible evolution of a document is speci�ed such that, when it is created,it is an o�er being valid for 30 days. O�ers may be revised during their validity.After each revision the o�er is again valid for 30 days. In case the customer issatis�ed by the o�er, the document can be changed to a contract. There are twoways for an o�er to become a contract. The direct way is �xing the o�er andturning it immediately into a contract. For that, the `�x contract' event can beused.Sometimes, it might be useful to have an additional phase for preparing theo�cial contract. By means of the `prepare contract' event the o�er can be turnedinto a pre-contract. A pre-contract is only valid for 10 days. Within that periodthe contract must be �xed �nally. Otherwise, the pre-contract becomes invalid. 2Considering the speci�cation it becomes obvious that problems might occurin the future during the runtime of the system. The complete behaviour is�xed at speci�cation time, i.e., the speci�cation can only respect the possibledynamic behaviour of document objects in the information system as far as itcan be foreseen at that moment. Of course, if we already expect that certainchanges of requirements will occur later, we are able to specify that in the usualobject speci�cation framework.However, if we look at the evolution of information systems in practice,we have to face the fact that there often are changes of requirements whichcould not be foreseen at speci�cation time. Such changes may be due to theenacting of new laws or due to the adaptation of a business rule to an unforeseenevolution of the market.In the usual speci�cation approaches such changes are not allowed. In casethe speci�cation of an information system has to be modi�ed the implementedsystem which is already running for some time does not ful�ll the modi�edspeci�cation anymore. In consequence, the implementation must be modi�edaccording to the changes in the speci�cation. However, considering the com-plete lifetime of an information system there is an obvious problem. For eachinstant of time the current implementation �ts the current speci�cation.Unfortunately, neither the original nor the modi�ed speci�cation describesthe complete evolution of the objects in the information system. This is due tothe fact that the modi�cation of the dynamic behaviour was not described inthe original speci�cation and that the modi�ed speci�cation does usually notinclude the evolution of the system before the speci�cation was modi�ed.In order to overcome this dilemma which is due to the restrictions of usualspeci�cation approaches we are developing a novel speci�cation framework withmore exibility. The main idea of our approach is that we distinguish betweenrigid axioms and non-rigid axioms. Rigid axioms are axioms which cannot

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 205be changed at all. In contrast non-rigid axioms may be added, removed, orchanged during runtime. For that additional actions must be introduced intothe speci�cation. We call this special kind of actions \mutators" or \mutationactions" (\mutation events" for concrete instances) because their occurrencecauses a mutation of the object speci�cation. In order to be able to introducenew axioms by occurrences of such mutation actions, a special type for axioms(spec) is provided. This type must not be used within rigid axioms. Onlymutation events may have axioms as parameter.For managing the set of currently valid non-rigid axioms we have to introducea special kind of attribute called \axiom attribute". In any case one axiomattribute is needed in which the set of currently valid non-rigid axioms is stored.In the following examples we call this axiom attribute `Axioms'. In fact, itmight be useful for certain applications to have several such axioms attributes,e.g., for being able to switch between di�erent sets of behaviour axioms (c.f.,[TCS96]). In that case one of these axiom attributes must be marked as theone containing the currently valid axioms. For simplifying the presentation weonly use one axiom attribute in the examples of this paper.Example 2 Continuing our example, we now add a simple mechanism for al-lowing evolving behaviour. Due to the fact that the rigid part of the behaviourspeci�cation has already been given in Figure 7.1, we only present the extension ofthe speci�cation in Figure 7.2.The extension given here is a rather unrestricted one. It allows to add arbitrarybehaviour axioms (and remove those axioms later on). For doing so, special actions,called mutators, are introduced. By means of an occurrence of an `add new rule'mutation action we are able to add an arbitrary formula as a behaviour axiom fordocument objects. For instance, this formula may describe additional e�ects of anaction or impose an additional enabling condition for some action. 2From a logical point of view, adding a new axiom can be considered as re-stricting the further behaviour of the object. Thereby, it is not possible tochange that part of the behaviour which is speci�ed in the rigid axioms sec-tion. It is only possible to specify additional e�ects of actions and to introducerestrictions, e.g., with regard to enabling of actions. In this way it is alsopossible to disallow certain actions to occur at all.Example 3 In the following we present examples for non-rigid axioms which couldbe added and lateron removed during runtime of our information system for man-aging documents. The syntax for representing those axioms is close to that we usefor object speci�cations.1. Due to a change of law it might become necessary to store the date when acontract was �xed. In order to bring this new requirement into our speci�-

206 LOGICS FOR DATABASES AND INFORMATION SYSTEMSobject class Documentsidenti�cation DocId: (DocNo)templateattributes...actions...rigid axioms...axiom attributesAxioms initialized f gmutatorsadd new rule(Rule:spec)remove rule(Rule:spec)dynamic speci�cationadd new rule(Rule)changing Axioms = Axioms + f Rule gremove rule(Rule)changing Axioms = Axioms � f Rule gend object classFigure 7.2 Extending the speci�cation for documents.cation an occurrence of a mutation event `add new rule' with the followingparameter can be used:�x contractchanging Valid = nowThereby, `�x contract' events will have an additional e�ect. They will set theattribute `Valid' to the current date. Thereby, the date of �xing the contractcan later be accessed.2. Another kind of additional e�ects of an event can also be speci�ed in the sameway as it would be done for rigid axioms. For instance, let us assume thatthere is a special supervisor object called `DocManager' which is responsiblefor keeping track of the evolution of documents. This supervisor object maycause the occurrence of a mutation event `add new rule' with the followingparameter:revise(C)calling DocManager.inform me(DocNo, C)

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 207From that moment each occurrence of a `revise' event causes an occurrenceof an `inform me' event in the supervisor object. This is new e�ect of `revise'events|in addition to the e�ects described as rigid axioms.3. In the same way we can restrict the enabling of events. For instance, due toa change of laws it might become necessary to keep document objects aliveforever in case they have reached to state of an o�cial contract. In order toadapt the system to this new requirement we could add to following axiomwhich allows the occurrence of `resolve' events only in case the document isnot already a contract:resolveenabled DocType 6= contract4. By imposing a pre-condition which cannot be ful�lled we can even disallowevents to occur at all. For instance, we can forbid `prepare contract' eventsby adding the following axiom:prepare contractenabled falsePlease note that we now have two enabling conditions which both have tobe ful�lled in case a `prepare contract' is to occur. The enabling condition`DocType = o�er' which is speci�ed as a rigid axiom is still valid. In addition,the new enabling condition `false' must be respected.5. Of course, we may also add other kinds of axioms. For example, the followingaxiom is an integrity constraint restricting the allowed states of an object:Valid > now !(DocType = o�er or DocType = pre contract)This axiom requires documents to be an o�er or a pre-contract in case thevalidity date is set to some date in the future. 2Due to the fact that everything which is speci�ed in the rigid axioms sectioncannot be changed during runtime of the information system, we have to bevery careful in specifying our system. In case we expect (or it could be possible)that the e�ect an event has on a certain attribute might change we should notspecify the e�ect of this event in the rigid axioms section. Instead we canspecify the default e�ect as part of the initial value of the axiom attribute`Axioms'. Then, it is possible to change it later.Of course, we should avoid to specify objects in a way that everything canbe changed later. In that case, it will be rather di�cult to prove interestingproperties for those objects. Therefore, specifying objects requires a thorough

208 LOGICS FOR DATABASES AND INFORMATION SYSTEMSdesign concerning the question which properties are rigid and which propertiesmay be a�ected by evolution.For being able to specify the evolution of dynamic behaviour as adequate aspossible we can also impose enabling conditions to mutation events. Thereby,changes of the set of currently valid non-rigid behaviour axioms (the contentsof the axiom attribute Axioms) can be better controlled. In certain cases itmight even be useful to have integrity constraints restricting the contents ofthe axiom attribute to ful�ll certain properties. The following example presentsthe restriction of a mutation event by imposing an enabling condition.Example 4 The enabling of mutation actions can be restricted in the same wayas it is possible for other events:...dynamic speci�cationadd new rule(Rule)enabled DocType 6= contractchanging Axioms = Axioms + f Rule g...Here, we require that the document type of a document must be di�erent from`contract' in order to allow occurrences of `add new rule' mutation events. 2Considering the evolution of information systems in practice clearly showsthat there is a real need for allowing behaviour evolution. Although there areseveral possibilities for extending existing speci�cation language in an ad hocmanner, the question how evolving behaviour can adequately be re ected onthe semantical level has still to be answered. In the next section we de�nesyntax and semantics of a logic for that purpose.7.3 SYNTAX AND SEMANTICS OF THE LOGICIn this section, we will present syntax and semantics of the logic dyOSL. dyOSLextends the logic OSL presented in [SSC95] with a second temporal level, themeta level, allowing evolving axiom attributes. We refer to the �rst level asbase level.We will mainly present the speci�c features of the presented logic and referto [Con98] for those parts adopted from the classical de�nition steps.

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 2097.3.1 SignaturesWe assume as given once and for all the underlying data signature �DT =hSDT ; OP i, with bool 2 SDT and OP�;bool = ffalse; trueg. We also assume asgiven a set of sorts SOB (object identi�ers). The symbol � denotes disjointunion.De�nition 5 dyOSL is based on the following sets of sorts : the data sorts S =SDT �SOB , the base sorts S = S�f�g and the meta sorts S = S�f�g�f�g.2The sort � is called the action sort , the sort � is called the mutation sortand the sort � is called the speci�cation sort . Generally, the concepts of thebase level are underlined (like S for the base sorts) to distinguish them fromconcepts of the meta level which are overlined. The speci�cation sort � will beused to manipulate formulae of the base level as values on the meta level.De�nition 6 An object signature � is a tuple hACT;ATT;MUT;MAT i suchthat: ACT is an S�-indexed family of �nite sets such that ? 2 ACT� where S�denotes (possibly empty) �nite sequences of sorts (action symbols);ATT is an S� � S-indexed family of �nite sets such that occ 2 ATT�;�(attribute symbols);MUT is an (S�f�g)�-indexed family of �nite sets such that ? 2MUT�(mutation action symbols);MAT (mutation attributes) is an S�-indexed family of �nite sets suchthat:{ occ 2MAT�;�;{ Ax 2MAT�;�. 2Given an object signature � = hACT;ATT;MUT;MAT i, each elementz 2 ACTw is said to be an action symbol with parameter sorts w, each elementa 2 ATTw;s is said to be an attribute symbol with parameter sorts w and resultsort s, each element m 2 MUTw is said to be a mutation action symbol withparameter sorts w, and each element q 2 MATw;s is said to be a mutationattribute symbol with parameter sorts w and result sort s. An attribute symbolin ATT�;s with s 2 S is said to be a slot symbol . A mutation attribute symbolinMAT�;� is said to be a speci�cation attribute symbol . Speci�cation attributesstore sets of temporal axioms. The special speci�cation attribute Ax contains

210 LOGICS FOR DATABASES AND INFORMATION SYSTEMSthe currently active set of axioms, whereas other speci�cation attributes maybe used to store sets of axioms for example during exceptional situations wherethe usual behaviour is overwritten for a period of time.The de�nition of object signatures introduces some special concepts whichare needed to describe the relation between base and meta level. The attributeocc is true in all states where the parameter action currently occurs. occ isthe analogon on the meta level for mutators. The ? action is an \idle" actionwhich occurs in all states where no other base action occurs. Again, ? is theanalogon on the meta level.In the sequel we assume a given signature � = hACT;ATT;MUT;MAT i.7.3.2 Terms and FormulaeWe assume as given once and for all an S-indexed family X of in�nite, pairwisedisjoint sets of base variables .The S-indexed family T of sets of base terms can be inductively de�nedusing the standard construction (c.f., [Con98]). Besides base variables as terms,terms are built from function symbols, action symbols and attribute symbolsby substituting other terms for their parameters. Each element of T s is calleda base term of sort s.The set L of base formulae is inductively de�ned in the usual way. It containsthe boolean terms t for t 2 T bool, the equations (t = t0) provided that t; t0 2 T s,and as composed formulae (:') (negation), (') '0) (implication), (' U '0)(temporal until operator) and (8y ') (universal quanti�cation).As usual we are free to introduce abbreviations. In the sequel we use: ('_'0)for ((:'))'0) (disjunction), ('^'0) for (:((:')_(:'0))) (conjunction), (','0) for ((')'0)^ ('0)')) (equivalence), (9y ') for (:(8y (:')) (existentialquanti�cation), (X') for ((' ^ (:')) U ') (nexttime operator), (F') for ((' _(:')) U ') (sometime in the future), and (G') for (:(F(:'))) (always in thefuture).De�nition 7 The set L of base formulae contains besides the standard con-structions the following base formula:? 2 L (birth predicate). 2Additionally, we will use the weak until operator . It is de�ned as follows:(' U? ) is an abbreviation of ((G') _ (' U )). In the case of ' U? ? thisoperator means that ' must hold until the next mutation (provided that anext mutation occurs).The �rst level of our logic (the base level) de�ned so far is a usual lineartemporal logic. The following de�nitions extend this logic to a second level (themeta level) manipulating sets of axioms.

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 211As for the base level, we also assume as given once and for all an S-indexedfamily X of in�nite, pairwise disjoint sets of meta variables , such that Xs = Xsfor each s 2 S. The meta variables therefore contain the base variables.A formula without temporal operators and without the attribute symbol occis called a state formula. We denote the set of all state formulae (at the baselevel) by stL.The base level was de�ned using the standard techniques for a linear tempo-ral logic. Now we will extend this framework with the corresponding de�nitionsfor the meta level.De�nition 8 The S-indexed family T of sets of meta terms is inductivelyde�ned as follows:y 2 T s, provided that y 2 Xs (variables as terms);t 2 T s, provided that t 2 T s (embedding of base terms);m(t1; : : : ; tn) 2 T �, provided that m 2MUTs1:::sn and ti 2 T si , for everyi = 1; : : : ; n (mutators);b(t1; : : : ; tn) 2 T s, provided that b 2MATs1:::sn;s and ti 2 T si , for everyi = 1; : : : ; n (mutation attribute symbols);['] 2 T � , provided that ' 2 L (re ection: base formulae embedded asterms of the speci�cation sort). 2Each element of T s is called a meta term of sort s. A set f'0; : : : ; 'ng ofbase formulae can be denoted by the term ['0 ^ : : : ^ 'n] 2 T � .The meta formulae are de�ned in direct analogy to the base level: booleanterms, equations, logical connectives. Like for the base level, we are also freeto introduce the �rst-order and temporal abbreviations for meta formulae.Analogously to stL, a meta formula without temporal operators and withoutthe meta attribute symbol occ is called a state meta formula. We denote theset of all state meta formulae by stL.7.3.3 Pre-interpretation structuresWe assume given an algebra dt over �DT = hSDT ; OP i such that dtbool =ffalsedt; truedtg. We also assume given an SOB-indexed family pop (pop forpopulation) of carrier sets for SOB , and we extend the notation so that popsstands for dts when s 2 SDT , and pop� stands for the elements of L.For a pre-interpretation structure, we use the free construction of terms tode�ne populations for actions, attributes, mutators, and mutation attributes.

212 LOGICS FOR DATABASES AND INFORMATION SYSTEMSFor example, the set act of actions over � for pop is as follows:act := [hs1:::sni2S�fz(u1; : : : ; un) : z 2 ACTs1:::sn ; ui 2 popsi ; for i = 1; : : : ; ngIn the sequel we write pop� for act. Analogously, we de�ne the set atts ofattributes of sort s over �. We denote the union of all atts as att.For the meta level, the set mut of mutations over � for pop and the sets matsof mutation attributes of sort s are de�ned analogously. In the sequel we writepop� for mut. Again, we denote the union of all mats as mat.We use the S-indexed family obs (for observations) to denote att � mat,de�ned as follows:obss = atts �mats, for each s 2 S;obss = mats, for each s 2 (S n S).For each element o 2 obss, called observation symbol of sort s, we say that popsis the domain Do of o.De�nition 9 A pre-interpretation structure over � is a tripleI = hdt; fpopgs2SOB ; �i;with � = f�k(o)gk2IN ;o2obs;such that:�k(o) 2 pops whenever o 2 obss;�k(occ) 6= ?) �k(occ) = ?;if �k(occ) = ? then �k+1(o) = �k(o) for each o 2 att such that o 6= occ;if �k(occ) = ? then �k+1(o) = �k(o) for each o 2 mat such that o 6= occ.2In this de�nition, � is an in�nite sequence of mappings which give for eachstate k 2 IN the current values for the observation symbols. To be a pre-interpretation structure, the following properties has to be satis�ed (as formal-ized in the above de�nition):Observation symbols are mapped into the corresponding domains.

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 213The base and the meta level are synchronized: Whenever an action (ora mutator) happens on one level, the corresponding \idle" action of theother level happens.\Idle" actions and \idle" mutators will not change the observations oftheir level.7.3.4 SatisfactionAfter having de�ned the syntax of the logic and the underlying semantic struc-tures, we can now start to de�ne the satisfaction relation between formulae andstructures.An assignment � for pop is an S-indexed family of maps �s : Xs ! pops.Let y 2 Xs and �; �0 be assignments. We say that � and �0 are y-equivalent i�for every s0 2 S and y0 2 Xs0 , �s0(y0) = �0s0(y0) whenever y0 6= y.Based on assignments, we can de�ne the semantics of terms and formulae.The semantic de�nition of base terms for a given interpretation structure I , anassignment � and a given point k follows the standard procedure for de�ningterms. The semantics of variables is state-independent, we have rigid variables.The only state-dependent part is the semantics of attributes, where � is used:[[a(t1; : : : ; tn)]]I;�;k;s = �k(a)�[[t1]]I;�;k;s1 ; : : : ; [[tn]]I;�;k;sn�The semantics of meta terms have to de�ne the connection between the twolevels:De�nition 10 The interpretation of meta terms in I for � at point k 2 IN isinductively de�ned as follows:[[y]]I;�;k;s = �s(y) (variables);[[t]]I;�;k;s = [[t]]I;�;k;s (embedding of base terms in the meta level);[[m(t1; : : : ; tn)]]I;�;k;� = m([[t1]]I;�;k;s1 ; : : : ; [[tn]]I;�;k;sn) (free constructionof mutators);[[b(t1; : : : ; tn)]]I;�;k;s = �k(b)([[t1]]I;�;k;1 ; : : : ; [[tn]]I;�;k;sn) (state-dependentvalues of mutation attributes);[[[']]]I;�;k;� = ', (re ection: speci�cation terms are interpreted as formu-lae of the base level). 2Again, the de�nition of the satisfaction of base formulae in I for � at pointk 2 IN , denoted with , is pretty standard and follows the usual rules for

214 LOGICS FOR DATABASES AND INFORMATION SYSTEMStemporal logic de�nition. As special predicate we have to de�ne the meaningof the ? symbol, which establishes a connection between base and meta level:I; �; k ? i� [[occ]]I;�;k;� 6= ?Given a pre-interpretation structure I and a base formula ' 2 L we say thatI satis�es ', written I ', i� I; �; 0 ' for every assignment �.It should be remarked, that we use an anchored version of temporal logic fordyOSL. This is due to the fact that we do not want to have an implicit neces-sitation to all formulae dynamically added to the speci�cation by mutations.Exactly that would be the case in a uent version of temporal logic. Becauseit should be possible to again remove an axiom dynamically added before, wemust avoid the implicit necessitation which states that something holds for everand cannot be removed.The satisfaction of meta formulae, denoted with , follows the standardprinciples of de�ning a linear temporal logic, too. However, because of itsimportance for the two level approach we show it completely:De�nition 11 The satisfaction of meta formulae in I for � at point k 2 IN isinductively de�ned as follows:I; �; k t i� [[t]]I;�;k;bool = truedt;I; �; k (t = t0) i� [[t]]I;�;k;s = [[t0]]I;�;k;s;I; �; k (: ) i� not I; �; k I; �; k ( ) 0) i� not I; �; k or I; �; k 0;I; �; k ( U 0) i� there is k0 2 IN such that k < k0, I; �; k0 0, and foreach k00 2 IN if k < k00 < k0 then I; �; k00 ;I; �; k (8 y ) i� I; �0; k for every �0 y-equivalent to �. 2The following de�nition gives the criterion, whether a pre-interpretationstructure is a correct interpretation structure for a two level speci�cation ornot:De�nition 12 Given a pre-interpretation structure I = hdt; fpopgs2SOB ; �i wesay that I is an interpretation structure i�, for every assignment � and k 2 IN ,I; �; k �k(Ax)whenever �k�1(occ) 6= ?. 2

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 215This de�nition shows the central role of the speci�cation attribute Ax. Axholds the currently relevant meta formulae which have to be satis�ed by thebase level between meta-level modi�cations.Finally, we will introduce the basic notations for working with the logicalframework. Given an interpretation structure I and a meta formula 2 L,we say that I satis�es , written I , i� I; �; 0 for every assignment �.Let � L and 2 L. We say that entails , written � i�, for everyinterpretation structure I , if I �', for every ' 2 , then I � . The closure byentailment of set of formulae � L is the set � = f : � g.7.3.5 Speci�cations and TheoriesFinally, we can de�ne the notions of speci�cation and theory for the logicdyOSL. These de�nitions follow the usual conventions for logics. An objectspeci�cation is a pair h�;�i such that � is an object signature and � is againa pair h�;�i such that � � L and � � L. By splitting � into � and � we areable to distinguish between rigid axioms and non-rigid axioms, respectively.An object theory is an object speci�cation h�;�i such that �� = �.From now on we concentrate on a given object speci�cation spec = h�;�i.7.4 TRANSLATION OF LANGUAGE INTO LOGICIn this section, we present the basic principles for translating object speci�-cations with evolving behaviour into corresponding sets of dyOSL formulae.Due to the fact that the translation of the standard parts of object speci�ca-tions, i.e., the speci�cation of the rigid behaviour, into OSL is already describedin detail in [Jun93], we here concentrate on the parts for specifying evolvingbehaviour.We are going to show the translation of the language into the logic by ex-ample. For the sake of simplicity we use a simpler example than the one wepresented in Section 7.2. Although the example of a modi�able timer describednext is not a typical example for an information system, it is more adequatefor focussing on the main aspects in translating speci�cations into the logic.Furthermore, it allows us to present a proof of an invariant property in fulldetail in the subsequent section.Example 13 The speci�cation of a modi�able timer is given in Fig. 7.3. Thetimer can be started by setting time and duration. The timer will then decreasethe time until zero, then the alarm will be raised. The alarm will stop when theduration has been decreased to zero. For the action `press button' there is no e�ectspeci�ed as rigid axiom.

216 LOGICS FOR DATABASES AND INFORMATION SYSTEMSobject Timertemplateattributestime: nat initialized 0,duration: nat initialized 0,alarm: bool initialized false;actionsstart(time:nat,duration:nat),tic,press button;rigid axiomsstart(t,d)changing alarm = false,time = t,duration = d;ticenabled time6= 0 or duration6= 0,changing if time � 1 then time = time-1,if time = 1 then alarm = true,if time = 0 then duration = duration-1,if time = 0 and duration = 1 then alarm = false;axiom attributesAxioms initialized fg;mutatorsm1,m2,reset;dynamic speci�cationm1changing Axioms = Axioms +f press buttoncalling start(100,10) if alarm=true g;m2changing Axioms = Axioms +f press buttonchanging if alarm=falsethen time=time+60 g;resetchanging Axioms = fg;end object Figure 7.3 Speci�cation of a Timer.

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 217By means of the mutation actions `m1' and `m2' it is possible to change thebehaviour of the timer. Each of these two mutation actions assign a certain e�ectto the `press button' action. `m1' introduces an axiom that if `press button' occurswhen the alarm is raised then the timer has to be restarted such that an alarm willbe raised after 100 seconds (and this alarm will then last for 10 seconds). `m2'adds an axiom describing that, if `press button' occurs when the timer has beenstarted but the alarm has not yet be raised, then the raising of the alarm is delayedby 60 additional seconds. 2We now illustrate how to translate this speci�cation into the logic. We willonly sketch the main transformation steps. The �rst step is the extraction ofthe signature.Example 14 (Timer signature) For the previous example, we get the followingsignature �Timer = hACT;ATT;MUT;MAT i:ACT� = f?; tic; press buttong, ACTnat nat = fstartg;ATT�;nat = ftime; durationg, ATT�;bool = falarmg, ATT�;� = foccg;MUT� = f?;m1;m2; resetg;MAT�;� = foccg, MAT�;� = fAxg.The dyOSL signature can be directly derived from the speci�cation signature of aTroll speci�cation. The special signature elements ?, ?, occ and Ax have tobe added for each speci�cation. 2The next step is to extract the speci�cation (note: we have to change thede�nition of speci�cation, so that it includes the part corresponding to the rigidaxioms)Example 15 (Timer speci�cation) For the previous example, we get the followingspeci�cation h�; h�;�ii:� includes the following axioms:1. time = 0 ^ duration = 0 ^ alarm;2. G(occ = tic) (time 6= 0 _ duration 6= 0));3. G(occ = start(t; d) ^ 'time;duration;alarmt;d;false ) (X')), for ' 2 stL;4. G((occ = tic ^ time > 1 ^ 'timetime�1)) (X')), for ' 2 stL;5. G((occ = tic ^ time = 1 ^ 'time;alarmtime�1;true)) (X')), for ' 2 stL;

218 LOGICS FOR DATABASES AND INFORMATION SYSTEMS6. G((occ = tic ^ time = 0 ^ duration 6= 1 ^ 'durationduration�1)) (X')), for' 2 stL;7. G((occ = tic^ time = 0^ duration = 1^'duration;alarmduration�1;false)) (X')),for ' 2 stL;Rule 1. results from the initialization of state attributes. Rule 2. is thetranslation of the enabling condition for the action tic. The remaining rules 3.to 7. model the e�ect of the actions on state formulae stating that valid stateformulae are valid after the state change if we substitute in these formulaeattribute names with the new attribute values (see [SSR96] for more details).� includes the following axioms:1. Ax = fg;2. G(occ = m1^'AxAx+f 1g) (X')) for ' 2 stL and 1 is (?) ((occ =press button) alarm = true)U? ?))^ (?) ((occ = press button)X(occ = start(100; 10)))U? ?));3. G(occ = m2^'AxAx+f 2g) (X')) for ' 2 stL and 2 is (?) ((occ =press button)alarm = false)U? ?))^ (?) ((occ = press button^ timetime+60 ) (X )) U? ?)), where 2 stL;4. G((occ = reset ^ 'Axfg )) (X')) for ' 2 stL.Again, rule 1. models the initialization of the meta attribute Ax. The re-maining rules 2. to 4. model the valuation of the mutation actions in analogyto the previous rules for the base level. 2Invariants to be proven can also be formulated in a Troll-like style. Forinstance, the invariant that as long as the attribute time has a value di�erentfrom zero, an alarm is not raised could be expressed as:invariant time 6= 0 ) alarm = falseIn the following section we will use this invariant to show in which wayinvariants can be proven from evolving speci�cations.7.5 USING THE LOGICAL FRAMEWORKIn this section we illustrate the use of the logic to prove some properties aboutdyOSL speci�cations (c.f., [SSR96] where a more detailed description of proofscan be found for the basic OSL).

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 2197.5.1 A Hilbert calculusWe start by introducing a Hilbert calculus for the logic. We have to provide twoconsequence operators, one to reason at the base level and another to reasonat the meta-level. These must be de�ned within the scope of a speci�cation.De�nition 16 The closure by consequence of a speci�cation h�;�;�i is thetuple h�;�`;�`i such that �` and �` are inductively de�ned as follows:1. 2 �` provided that 2 � (rigid part of the speci�cation);2. 2 �` provided that is a theorem of an anchored linear temporal, �rstorder logic with equality (inclusion of valid formulae of the used temporalframework);3. 0 2 �` provided that is a rigid data formula such that �; dt for every assignment � (inclusion of valid formulae for data types, forexample arithmetics);4. 0 2 �` provided that ; ( ) 0) 2 �` (modus ponens, base level);5. 0 2 �` provided that ; ( ) 0) 2 �` (modus ponens, meta level);6. ' 2 �` provided that ' 2 �`, for each ' 2 L (inclusion of base level intometa level);7. ((z(x1; : : : ; xn) = z(x01; : : : ; x0n))) ((x1 = x01) ^ : : : ^ (xn = x0n))) 2 �`provided that z 2 ACTs1:::sn ;8. (:(z(x1; : : : ; xn) = z0(x01; : : : ; x0n0))) 2 �`provided that z 2 ACTs1:::sn , z0 2 ACTs01:::s0n0 and z 6= z0;9. (8y(Ws1:::sn2(S�f�g)(Wz2ACTs1:::sn (9y1 : : : yn (y = z(y1; : : : ; yn)): : :)))) 2 �`;10. Rules analogous to rules 7, 8, and 9 for mutators;11. ((occ = m(t1; : : : ; tn)^m(t1; : : : ; tn) 6= ?), ?) 2 �` (connection of birthsymbol on the base level with mutator occurrences on the meta level) ;12. (occ 6= ? ) occ = ?) 2 �` (base actions and meta mutators do nothappen synchronously);13. ((occ = ?)) ((a(x1; : : : ; xn) = y)) (X(a(x1; : : : ; xn) = y)))) 2 �`provided that a 2 ATTs1:::sn;s and a 6= occ (base level \idle" action);

220 LOGICS FOR DATABASES AND INFORMATION SYSTEMS14. ((occ = ?)) ((b(x1; : : : ; xn) = y)) (X(b(x1; : : : ; xn) = y)))) 2 �`provided that b 2MATs1:::sn;s and b 6= occ (meta level \idle" action). 2We brie y explain some of these rules and give them names for later reference(note that some of these are very similar to the ones presented in [SSR96]).Rule 1 states that each axiom of the speci�cation is a theorem: AX . Rule 2captures the �rst-order linear temporal logic reasoning: LPO. Rules 4 and 5are modus ponens : MP . Rule 6 states that the theorems of the base level arealso theorems of the meta-level. Rules 7{9 re ect that actions (resp. rule 10 formutation actions) are not interpreted and are generated: ACT (resp. MUT ).Rule 11 re ects a property of ? and mutations: STAR. Rules 12-14 re ectproperties for the life-cycles: RUN .The presented logical system is sound that is if ' 2 �` then � � ' wherethe latter means: an interpretation structure I satis�es ' whenever I satis�esall the formulae in �.Due to the fact that the logical system is based on temporal logic, it is notstrongly complete (c.f., [Gol92]). There may be formulae ' with � � ' but' 62 �`. Furthermore, the logical system is at most semi-decidable because itincludes �rst-order logic.The following de�nition of consequence follows the standard principles oflogical systems. However, we have to distinguish base and meta level.De�nition 17 Let spec = h�;�;�i be a speci�cation and = h;i suchthat � L and � L. The consequence of on spec is the tuple spec` =h�;�`;�`i where �` and �` are inductively de�ned as follows:' 2 �` provided that ' 2 �`;' 2 �` provided that ' 2 ; 2 �` provided that (') ); ' 2 �`;' 2 �` provided that ' 2 �`;' 2 �` provided that ' 2 ; 2 �` provided that (') ); ' 2 �`. 2We denote ' 2 �` (resp. ' 2 �`) by `' (resp. `').

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 2217.5.2 An invariant calculusIn this section we present a calculus for proving invariants following the ideasin [MP92].Our aim is to give a proof-theoretic approach to certifying invariants foran evolving speci�cation. Evolving sets of formulae are usually interpreted atruntime which is very exible but does not allow for proving interesting globalinvariants, i.e., formulae that are to be satis�ed all over.We restrict ourselves to prove base invariants, i.e., invariants not contain-ing meta formulae as subformulae. To prove invariants, we have to check theinvariant against each possible set of base axioms arising during speci�cationevolution. We call such formulae sets completions . A completion is a set of base-formulae, that completely specify the e�ects of actions, and which includes theset of rigid axioms. A completion is reachable if it can be constructed in thefollowing way:For a given value of the meta attribute Ax, a completion is the union offollowing sets:{ the rigid axioms rigidaxioms,{ the values of Ax, and{ a frame rule for each action act which has no explicit valuation rulein rigidaxioms or Ax:(?) (((occ = act ^ ')) (X')) U? ?))The value of Ax is the initial value or the result of an enabled sequenceof mutation events.The number of reachable completions is �nite, if we use constant terms oftype spec and set-operations on the Ax meta attribute only. For a proof, wehave to consider all reachable completions.However, the general framework allows formulae as parameters of muta-tors on the meta level and therefore maybe even in�nite number of reachablecompletions. For these cases, new techniques have to be developed based onproperties of completions which have to be guaranteed (= proven) in a genericway.Some invariants can even be proven based on the rigidaxioms only. In gen-eral, this is only possible for invariants containing no state-dependent attributeor in the situation where all actions are fully speci�ed | for more interestingassertions, we have to use the presented method relying on completions.

222 LOGICS FOR DATABASES AND INFORMATION SYSTEMSExample 18 In the case of our example, from the speci�cation of the Timer, wecan \derive" the following completions:C1 = rigidaxioms+f (?) (((occ = press button ^ ')) (X')) U? ?))g;C2 = rigidaxioms+f (?)(((occ = press button^alarm = true))X(occ = start(100; 10)))U??));(?) (((occ = press button ^ ') X')) U? ?)) g;C3 = rigidaxioms+f (?)((occ = press button^alarm = false^'timetime+60))(X')))U??)) g;C4 = rigidaxioms+f (?)(((occ = press button^alarm = true))X(occ = start(100; 10)))U??));(?) ((occ = press button^alarm = false^'timetime+60)) (X')))U? ?)) g;The formula added in completion C1 models the frame rule for the actionpress button: As long as nothing additional is stated in the meta part of thespeci�cation, this action has no e�ect on the object state. Completion C2 includesthis frame rule as well. For completion C3 this frame rule is overruled by a rulechanging all properties by modifying the time attribute. Completion C4 includesall axioms added by the mutation actions `m1' and `m2'. In addition it containsthe same frame rule as C3 due to the fact that the frame rule overrules the one ofC2.Obviously, we can only derive four reachable completions in our example. Thisis due to the fact that there are only two formulae as possible values for Ax. Inconsequence, there exist only four possible combinations as basis for reachablecompletions, i.e., each reachable completion corresponds to an element of thepower set of possible values for Ax. 2In what follows, the results only hold when ' is a state formula (i.e., aformula without temporal operators and without the symbol occ).De�nition 19 (Global invariant rule) Let h�;�;�i be a speci�cation, and letC1; : : : ; Cn be its completions. Then:(G') 2 �` provided that:{ `';{ Ci`((' ^ ?)) (' U? ?)) for i = 1; : : : ; n. 2

EVOLVING LOGICAL SPECIFICATION IN INFORMATION SYSTEMS 223Informally, the global invariant rule expresses the fact that an invariant isvalid if it holds in the initial state and is respected by all completions as longas they are active.Beside the global invariant rule we also need the following local invariantrule.De�nition 20 (Local invariant rule) Let h�;�;�i be a speci�cation, and letC be one of its completions. Then:C`((' ^ ?)) (' U? ?)) provided that:{ C`(('^ ?)) (((occ = a^')) (X'))U? ?)) for every a 2 ACTw;2Informally, the local invariant rules formalize the notion of \being respectedas long as a completion is active". Again the formula ' has to hold at the acti-vation point of a completion. Additionally, each base action has to respect theformulae, i.e., each state modi�cation will result in a state where the invariantholds (provided it held before).Note that in order to prove the soundness of the local invariant rule, we mayuse the following result: (? ^ ') (X')) (? marks an \idle" action).Example 21 Assume that we want to prove the following property:`(G((time 6= 0)) (alarm = false)))From example 18 we now that we have four possible completions, so we have touse rule 20 for each one of these completions. We only consider one of these. Theothers are similar. Let us consider C3. Let � be ((time 6= 0)) (alarm = false)).(A) `((time 6= 0)) (alarm = false))1. time = 0 ^ duration = 0 ^ alarm = true 2 � AX2. (time 6= 0)) (alarm = false) 2 �` LPO : 13. `(time 6= 0)) (alarm = false) by de�nition of derivation(B) C3`((� ^ ?)) (((occ = start(t; d) ^ �)) (X�)) U? ?))1.G((occ = start(t; d) ^ (t 6= 0) false = false))) (X�)) 2 � AX2.G((occ = start(t; d))) (X�)) 2 �` LPO : 13.G((occ = start(t; d) ^ �)) (X�)) 2 �` LPO : 24.((� ^ ?)) (((occ = start(t; d) ^ �)) (X�)) U? ?)) 2 �` LPO : 45.C3`((� ^ ?)) (((occ = start(t; d) ^ �)) (X�)) U? ?)) def of derivation

224 LOGICS FOR DATABASES AND INFORMATION SYSTEMS(C) C3`((� ^ ?)) (((occ = press button ^ �)) (X�)) U? ?))1.(?) ((occ = press button^((time+ 60) alarm = false)) (X�))) U? ?)) 2 C3 def of der.2.(?) ((occ = press button) alarm = false)U? ?)) 2 C3 def of der.3.((� ^ ?)) (((occ = press button ^ �)) (X�)) U? ?)) 2 C3 LPO : 1; 2The rest of the proof is similar. The reader is referred to [SSR96] for moredetailed proofs of this sort. 2Here, we only deal with proving invariants because invariants are the mostimportant properties of evolving systems we are interested in. Other properties,like liveness, can in general not be proven.7.6 CONCLUDING REMARKSIn this paper, we presented an extension of object speci�cation for capturingevolving behaviour. For motivating the necessity of dealing with evolving be-haviour we used an extended object speci�cation language. Furthermore, wede�ned the logic dyOSL. Thereby, we provided a semantics based on an ex-tended linear temporal logic. We discussed the translation of the speci�cationlanguage into that logic and, �nally, we demonstrated the usage of the logicalframework for proving object properties from their (dynamic) speci�cations.The extensions we are considering form a stable basis for future work inwhich we aim at integrating additional aspects like normative speci�cation(based on deontic logic). In [SCT95] we sketch a vision of a future speci�ca-tion language incorporating several speci�cation concepts going beyond currentobject-oriented speci�cation formalisms. The work presented here is a majorstep into that direction. This is due to the fact that we leave the level of �rst-order temporal logic by allowing the manipulation of �rst-order speci�cationaxioms within the speci�cation. Thereby, we introduce some kind of reasoningcapabilities into the objects.We do not strive for a real higher-order approach. Nevertheless, we thinkthat some higher-order aspects (as they have recently been investigated in sev-eral areas, for instance for algebraic speci�cation in [M�ol94; Sch94]) could help.Another approach using a 2-level logic is presented in [GH93]. There, the sec-ond level in the logic is introduced for handling inconsistencies on the �rstlevel.The presented proof-theoretic approach seems to be very restricted becausewe have to be able to compute all completions. However, we can see thissituation from the opposite: If we can prove for each given non-rigid axiom

REFERENCES 225as part of the evolving part of a speci�cation in isolation, that it respects theinvariant together with the rigid axioms, all of them can be safely added (byunion) to Ax during object lifetime. This holds because of the constructionof completions where the number of `frame rules' may only decrease if we addadditional formulae to Ax.Of course, there still is a large number of open questions due to the fact thatthe work presented here has to be considered as a starting point for furtherresearch. Among the issues for future work developing guidelines for specifyingobjects having an evolutionary behaviour is very important. We have to sup-port speci�ers in making their decisions which axioms should be rigid and whichshould be part of the dynamic speci�cation part. Concerning the speci�cationlanguage syntactic restrictions must be provided for specifying behaviour evo-lution in a more controlled way. Furthermore, we have not dealt with schemaevolution in this paper. It may happen that changing the dynamic behaviour ofobjects requires to introduce new attributes or to modify the types of existingattributes. For that, appropriate extensions of dyOSL are needed.AcknowledgmentsWe are grateful to Amilcar Sernadas for discussing with us this di�cult prob-lem. Work presented here was partially supported by PRAXIS XXI Programand JNICT, as well as by PRAXIS XXI Projects 2/2.1/MAT/262/94 SitCalc,PCEX/P/MAT/46/96 ACL plus 2/2.1/TIT/1658/95 LogComp, ESPRIT IV Work-ing Groups 22704 ASPIRE and 23531 FIREworks, ESPRIT III Working Group 8319ModelAge, and DFG Project Ne 592/4-1.References[BK98] A. Bonner and M. Kifer. Logic Programming for Database Transac-tions. In Chomicki and Saake [CS98], chapter 5, pp. 117{166.[Con96] S. Conrad. A Basic Calculus for Verifying Properties of InteractingObjects. Data & Knowledge Engineering, 18(2):119{146, 1996.[Con98] S. Conrad. A Logic Primer. In Chomicki and Saake [CS98], chapter 2,pp. 5{30.[CS96] S. Conrad and G. Saake. Specifying Evolving Temporal Behaviour. InJ. Fiadeiro and P.-Y. Schobbens, editors, Proc. of the 2nd Workshopof the ModelAge Project (ModelAge'96), Sesimbra, Portugal, pp. 51{65. Departamento de Informatica, Universitade de Lisboa, 1996.[CS97] S. Conrad and G. Saake. Extending Temporal Logic for CapturingEvolving Behaviour. In Z. Ra�s and A. Skowron, editors, Foundationsof Intelligent Systems (Proceedings, 10th International Symposium,

226 LOGICS FOR DATABASES AND INFORMATION SYSTEMSISMIS'97, Charlotte, North Carolina, USA, October 1997), volume1325 of Lecture Notes in Arti�cial Intelligence, pp. 60{71. Springer-Verlag, Berlin, 1997.[CS98] J. Chomicki and G. Saake, editors. Logics for Databases and Infor-mation Systems. Kluwer Academic Publishers, Boston, 1998.[CT98] J. Chomicki and D. Toman. Temporal Logic in Information Systems.In Chomicki and Saake [CS98], chapter 3, pp. 31{70.[DDP93] E. Dubois, P. Du Bois, and M. Petit. O-O Requirements Analysis: AnAgent Perspective. In O. Nierstrasz, editor, ECOOP'93 | Object-Oriented Programming, Proc. 7th European Conf., Kaiserslautern,Germany, July 1993, number 707 in Lecture Notes in Computer Sci-ence, pp. 458{481. Springer-Verlag, Berlin, 1993.[EDS93] H.-D. Ehrich, G. Denker, and A. Sernadas. Constructing Systems asObject Communities. In M.-C. Gaudel and J.-P. Jouannaud, editors,Proc. Theory and Practice of Software Development (TAPSOFT'93),number 668 in Lecture Notes in Computer Science, pp. 453{467.Springer-Verlag, Berlin, 1993.[FM91] J. Fiadeiro and T. Maibaum. Temporal Reasoning over Deontic Spec-i�cations. Journal of Logic and Computation, 1(3):357{395, 1991.[GH93] D. Gabbay and A. Hunter. Making Inconsistency Respectable: Part2 { Meta-level handling of inconsistency. In M. Clarke, R. Kruse, andS. Moral, editors, Proc. ECSQARU'93, number 747 in Lecture Notesin Computer Science, pp. 129{136. Springer-Verlag, Berlin, 1993.[Gol92] R. Goldblatt. Logics of Time and Computation. CLSI, 2 edition,1992.[Gur91] Y. Gurevich. Evolving Algebras: A Tutorial Introduction. EATCSBulletin, 43:264{284, 1991.[Gur93] Y. Gurevich. Logic in Computer Science. In G. Rozenberg andA. Salomaa, editors, Current Trends in Theoretical Computer Sci-ence, number 40 in Series in Computer Science, pp. 223{394. WorldScienti�c Press, 1993.[Har84] D. Harel. Dynamic Logic. In D. Gabbay and F. Guenthner, editors,Handbook of Philosophical Logic II: Extensions of Classical Logic,chapter II.10, pp. 497{604. D. Reidel, Boston, 1984.[JSHS96] R. Jungclaus, G. Saake, T. Hartmann, and C. Sernadas. Troll { ALanguage for Object-Oriented Speci�cation of Information Systems.ACM Transactions on Information Systems, 14(2):175{211, 1996.[Jun93] R. Jungclaus. Modeling of Dynamic Object Systems|A Logic-BasedApproach. Advanced Studies in Computer Science. Vieweg Verlag,Braunschweig/Wiesbaden, 1993.

REFERENCES 227[KM89] S. Khosla and T. Maibaum. The Prescription and Description ofState Based Systems. In B. Banieqbal, H. Barringer, and A. Pnueli,editors, Temporal Logic in Speci�cation, number 398 in Lecture Notesin Computer Science, pp. 243{294. Springer-Verlag, Berlin, 1989.[LT93] U. Lipeck and B. Thalheim, editors. Modelling Database Dynamics:Selected Papers from the 4th Int. Workshop on Foundations of Mod-els and Languages for Data and Objects. Workshops in Computing.Springer-Verlag, London, 1993.[Mes92] J. Meseguer. Conditional Rewriting as a Uni�ed Model of Concur-rency. Theoretical Computer Science, 96(1):73{156, 1992.[Mes93] J. Meseguer. A Logical Theory of Concurrent Objects and Its Re-alization in the Maude Language. In G. Agha, P. Wegener, andA. Yonezawa, editors, Research Directions in Object-Oriented Pro-gramming, pp. 314{390. MIT Press, 1993.[M�ol94] B. M�oller. Ordered and Continuous Models of Higher-Order Speci-�cations. In J. Heering, K. Meinke, B. M�oller, and T. Nipkow, edi-tors, Proc. Int Workshop on Higher-Order Algebra, Logic, and TermRewriting (HOA'93), number 816 in Lecture Notes in Computer Sci-ence, pp. 223{255. Springer-Verlag, Berlin, 1994.[MP92] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Con-current Systems. Vol. 1: Speci�cation. Springer-Verlag, New York,1992.[MQ93] J. Meseguer and X. Qian. Logic-Based Modeling of Dynamic ObjectSystems. In P. Buneman and S. Jajodia, editors, Proc. of the 1993ACM SIGMOD Int. Conf. on Management of Data, Washington,D.C., SIGMOD RECORD 22(2), pp. 89{98. ACM Press, 1993.[Sch94] P.-Y. Schobbens. Extensions of Initial Models and their Second-orderProof Systems. In J. Heering, K. Meinke, B. M�oller, and T. Nip-kow, editors, Proc. Int Workshop on Higher-Order Algebra, Logic,and Term Rewriting (HOA'93), number 816 in Lecture Notes in Com-puter Science, pp. 326{344. Springer-Verlag, Berlin, 1994.[SCT95] G. Saake, S. Conrad, and C. T�urker. From Object Speci�cation to-wards Agent Design. In M. Papazoglou, editor, OOER'95: Object-Oriented and Entity-Relationship Modeling, Proc. of the 14th Int.Conf., Gold Coast, Australia, number 1021 in Lecture Notes in Com-puter Science, pp. 329{340. Springer-Verlag, Berlin, 1995.[SE91] A. Sernadas and H.-D. Ehrich. What Is an Object, After All?In R. Meersman, W. Kent, and S. Khosla, editors, Object-OrientedDatabases: Analysis, Design and Construction (Proc. 4th IFIP WG2.6 Working Conference DS-4, Windermere (UK)), pp. 39{70. North-Holland, Amsterdam, 1991.

228 LOGICS FOR DATABASES AND INFORMATION SYSTEMS[SR94] A. Sernadas and J. Ramos. The GNOME Language: Syntax, Se-mantics and Calculus. Research report, Instituto Superior Tecnico,1994.[SRGS91] C. Sernadas, P. Resende, P. Gouveia, and A. Sernadas. In the LargeObject-Oriented Design of Information Systems. In F. Van Assche,B. Moulin, and C. Rolland, editors, The Object-Oriented Approach inInformation Systems, pp. 209{232. North Holland, Amsterdam, 1991.[SSC95] A. Sernadas, C. Sernadas, and J. Costa. Object Speci�cation Logic.Journal of Logic and Computation, 5(5):603{630, 1995.[SSE87] A. Sernadas, C. Sernadas, and H.-D. Ehrich. Object-Oriented Speci-�cation of Databases: An Algebraic Approach. In P. M. Stoecker andW. Kent, editors, Proc. 13th Int. Conf. on Very Large Data Bases(VLDB'87), pp. 107{116. VLDB Endowment Press, Saratoga (CA),1987.[SSG+91] A. Sernadas, C. Sernadas, P. Gouveia, P. Resende, and J. Gouveia.OBLOG | Object-Oriented Logic: An Informal Introduction. Tech-nical Report, INESC, Lisbon, 1991.[SSR96] A. Sernadas, C. Sernadas, and J. Ramos. A Temporal Logic Approachto Object Certi�cation. Data & Knowledge Engineering, 19:267{294,1996.[SSS95] G. Saake, A. Sernadas, and C. Sernadas. Evolving Object Speci�ca-tions. In R. Wieringa and R. Feenstra, editors, Information Systems| Correctness and Reusability. Selected Papers from the IS-COREWorkshop, pp. 84{99. World Scienti�c Publishing, Singapore, 1995.[TCS96] C. T�urker, S. Conrad, and G. Saake. Dynamically Changing Be-havior: An Agent-Oriented View to Modeling Intelligent InformationSystems. In Z. W. Ra�s and M. Michalewicz, editors, Foundationsof Intelligent Systems, Proc. of the 9th Int. Symposium on Method-ologies for Intelligent Systems, ISMIS'96, Zakopane, Poland, number1079 in Lecture Notes in Computer Science, pp. 572{581. Springer-Verlag, Berlin, 1996.