An Event-Based Semantics for Transactions 1 ... - Semantic Scholar

An Event-Based Semantics for Transactions G. Denker and H.-D. Ehrich Technische Universitat Braunschweig, Informatik, Abt. Datenbanken Postfach 3329, D{38023 Braunschweig, Germany e{mail: fG.Denker,[email protected] Abstract

In this paper we investigate the notion of transaction in object-oriented speci cation. Transactions are a suitable concept to cover dierent aspects that arise in a variety of contexts. For example, in re nement theory a transaction may be understood as the re nement of actions, in database theory it may be understood as an abstraction from sequences of statements, or in business process modelling it may occur as a complex process with a prede ned execution order. Thus, there is a wide application area for such a notion. The focus of our work is the stepwise design and modelling of distributed information systems with object-oriented techniques. We put emphasis on the need of a well-de ned formal background. The basis of our work is the model for distributed families of concurrent objects presented in [ES95]. We syntactically introduce transactions into object-oriented speci cation and propose a temporal logic which can speak about transactions to formalize such speci cations. Moreover, we give an appropriate interpretation of speci cations which incorporate transactions based on event structures. The ideas are brie y illustrated by example.

1 Introduction Object-oriented modelling techniques are accepted as a promising approach to software design. There are contributions in dierent directions, like languages, tools, and methodologies, that are based on the object-oriented paradigm. There is a variety of languages or methods, ranging from informal analysis methods to formal speci cation languages. The informal methods were created because of the need of an appropriate counterpart on the modelling level to objectoriented programming languages (for instance OMT [RBP+91], OOA [CY91], [Boo94] and others). The formal ones have a well-de ned semantics based on a theoretical background (for instance CSML [Wie91], OBLOG [Ser91], FOOPS [RS92], ALBERT [DDPW94], ABEL [DO91], ObjectZ [DKRS91], Z++ [Lan91], Troll [HSJ+ 94] and others). These formal languages are de ned on top of dierent frameworks, including algebraic and process models, equational and temporal logics and others. The object-oriented speci cation language Troll has been developed at the database department in Braunschweig. It is supposed to be used in early phases of the design and modelling of distributed information system. Theoretical investigations accompanied the language design during the whole time. A strong background theory leaves freedom for theoretical studies which are independent from speci c languages. Therefore, the yielded results are generally applicable to object-oriented concepts. In this paper we investigate the concept of transactions in object-oriented speci cation. The need of transactions is not tied to a speci c application. There are several reasons why the notion of transaction is important. It supports dierent intentions depending on how it come into play. In the following we will give a few possibilities of using transactions for dierent purposes. The

listed cases neither exclude each other or represent orthogonal applications nor are a complete representation of application domains of transactions. They rather substantiate the need of such a notion by giving some examples.

Transactions and re nement: Re nement is a technique often applied in the design process.

A system is described as a sequence of speci cations on dierent levels of abstraction, where each speci cation is implemented by its successor. A formal re nement theory is inevitable to handle the number of documents produced during this process, since it is rapidly growing to an unwieldy amount. A re nement theory for reasoning about the correctness of each design step will be highly desirable for safety critical or data intensive applications. The objectoriented framework puts additional complexity to this technique. Objects are understood as units of structure and behaviour. Therefore, re nement includes data re nement (structural re nement) as well as action re nement (behavioural re nement). Action re nement is understood as the principle of implementing abstract actions through complex processes. The processes are built by using operators like sequence, choice, and loop. This is similar to ideas from programming languages or process theory, such that a theory of action re nement in object-oriented framework may pro t from re nement results in process theory (cf [vGG90, DG91, NEL89, Vog93] to cite a few). Therefore, understanding transactions as abstractions from processes is a possible way to handle re nement. There are some approaches in object-orientation concerned with rei cation (e.g., [SGS92, Mal94, MG94, Zuc95, WM91, Bor95, FM91, FM94]). Transactions and databases: We aim at modelling information systems with object-oriented techniques. Information systems are reactive systems which retrieve data from and manipulate data in the underlying databases due to the application programs. Thus, the concept of transactions known from databases is important for our work. A database transaction follows the ACID-principle. It is executed atomically from the users viewpoint (Atomicity), it transforms the database from one consistent state to another consistent state (Consistency), its eect is the same as it would have taken place in isolation (Isolation), and its eect is persistent in the database (Durability). The two main tasks of a database management system are (1) realizing parallel program execution and (2) ensuring error tolerance. Parallelism enables several users to access commonly used database such that no unexpected side eects occur. It is not the responsibility of the users to formulate transactions in a safe way. They may design database application as if they would do in single-user environments. Diculties may occur with synchronizing parallel executed transactions which concurrently access shared data. Concurrency control theory has been developed to avoid inconsistent con gurations which may result because of con icting transactions. Serializability and recovery are the main correctness criteria. There is a thoroughly developed theory for transaction management (cf [BHG87, GR93, LMWF94] and other text books may give a good overview). Serializability is the interleaved execution of transactions such that the resulting eect is the same as the one of a serial execution. Recovery is the possibility to reach consistent database state in case of errors. In [DE95, Den95a, Den95b] we investigate re nement in objectoriented speci cation against the background of concurrency control theory. Especially, we propose a loose sequential composition operator according to serializability. Transactions and business processes: Modelling of enterprises demands techniques which may capture dynamic aspects as well as static structure. Signi cant behavioural parts of an en terprise can be described as business processes [Ost95] (also called work ows or application processes). The behaviour of such processes is known a priori. That is the reason, why such processes are already speci able in design phases of systems. A business process uses several resources and puts together dierent services to construct a new service. Thus, a business process consists of several related units which together ful ll the intended behaviour. These

relationships correspond to the view that units deliver results which are prerequisites for further computations in other units. For that reason relationships imply coordination between the units. The object-oriented paradigm is applicable to business process modelling. In [HJ94] application processes are modelled as objects. They are speci ed on top of a system speci cation which determines the overall structure and the behaviour of single objects. The services of single objects are exploited to generically describe business processes. Language features used for specifying this long-term behaviour are choices, sequences, and parallelism. This way, business processes may be understood as transactions which are composed of actions, each of which corresponds to a unit responsible for a speci c service. In this paper, we will introduced transactions into object-oriented speci cations. Besides proposing language features for the speci cation language Troll, we will mainly develop a languageindependent theory to treat transactions semantically. Our investigations enlarge the theory given in [ES95] by transactions. In [ES95] a standard semantics for concurrent object societies is provided using event structures. We will illustrate our ideas by example. The rest of the paper is organized as follows. Sect. 2 introduces transactions syntactically. Transactions in Troll speci cations are investigated and illustrated by example. Class signatures are an abstract concept in which the structural part of Troll speci cation is translated. In Sect. 3 we handle the dynamic part of Troll speci cations. For that reason, we propose a logic which can deal with transactions. These are the prerequisites to give a semantics for speci cations which incorporate transactions. Sect. 4 closes the paper with a short summary and some future work.

2 Transaction Signature

Troll [HSJ+ 94] is a language for specifying communities of interacting objects. It is possible to model statical and behavioural aspects of the system. Moreover, Troll oers structuring

mechanism, such as spezialization, roles, composition, etc. We propose language features for specifying transactions in Troll. Our approach is conducted by ideas from programming languages. There, procedures have been introduced as abstractions from sequences of programming statements. Analogously, transactions are understood as abstractions from action sequences. Thus, features like sequences, choices, and loops of actions will be introduced.

Example 1 (transaction speci cation { insurance company) We will motivate transactions by a small example. The following speci cation roughly describes a part of an insurance company. One of the main applications run by such a company is the treatment of application for life insurances. We modelled this via a transaction with the following steps: (1) the application form has to be lled in, (2) the application form is checked for completeness, (3) depending from the result of this test either the process stops by sending an error message or it will continue with step (4) by checking the health certi cate. If this test is positiv the policy is delivered. The following speci cation is incomplete. It is not speci ed how an action determines the value of its output parameter on which the ongoing computation depends. We only focus on the transaction part. object type Insurance Company uses Application Form, Health Certificate actions fillin(in Form:Application Form) completeness-test(in form:Application Form, out complete:bool) health-test(in report:Health Certificate, out healthy:bool) error(out message:string)

transactions variables

AF: Application Form, HC: Health Certificate, TakeOutLifeInsurance(AF,HC) = fillin(AF);completeness-test(AF); if complete then health-test(HC);if healthy then deliver-policy else error



else

error



More generally, we introduce the following syntax for transaction speci cation:

De nition 1 (syntax of transactions)

the following rules:



::= ::= ::= ::= ::= ::=

The formal syntax of transaction terms is given by

] [()] = | | | | nil ; if then else while do od

transactions [variables

The new concept of transaction has to be appropriately interpreted. The semantic basis will be the theory given in [ES95]. The following investigations are made in analogy to this paper. For the sake of simpli cation we do not treat inheritance here, i.e., we do not have order sorted signatures. But this does not restrict our appraoch, since the work presented here can easily be done with inheritance (cf [Den95b]). In [ES95] class signatures are introduced as a transformation domain for the strucural part of Troll speci cations. We will not present this translation in detail, rather than refer to [ESSS94] where such a translation is presented. As far as transactions are concerned, we gave an adequate translation in [Den95b]. Class signatures consists of a set of global identities and set of action symbols for each object sort. Components and attributes are also covered by class signatures. Attributes are understood as objects which may be read or written. Actions of componentes and attributes are included in the class signature. Therefore, actions and identities are sucient for speci cations without transactions. To treat transactions adequately, we have to distinguish them from actions in an appropriate way. Therefore, we introduce transactions as an independent concept. This implies that instance generators, action symbols and transaction symbols are represented in a class signature. Moreover, we de ne built-in operators to combine (trans)actions to new transactions. De nition 2 (class signature with transactions) Let D = (SD ; D ) be a data signature. A class signature with transactions over D , CT = (SO ; I; A; T ), is given by  a set of object sorts SO ,  ;b2SO ,  an SDO  SO -indexed set of instance symbols I = fIx;bgx2SDO  ;b2SO , and  an SDO  SO -indexed set of action symbols A = fAx;bgx2SDO

 ;b2SO where T  A.  an SDO  SO -indexed set of transaction symbols T = fTx;bgx2SDO Here, SDO = SD [ SO .

The following built-in operators are de ned for transaction symbols:

Tx;b  Ty;b (t1 ; t2 ) IF : TD (X )bool  Tx;b  Ty;b (c; t1 ; t2 ) WHILE : TD (X )bool  Tx;b (c; t1 ) SEQ :

! 7 ! ! 7 ! ! 7!

Txy;b; SEQ(t1 ; t2 ); Tboolxy;b; IF (c; t1 ; t2 ); Tboolx;b; WHILE (c; t1);

The condition T  A states that every action can be understood as a transaction, namely the simplest one which consists of one action. We aim at interpreting class signature algebraically (cf [ES95]). To achieve this, we extend the underlying data signature by sorts corresponding to identities, actions, and transactions. With every object sort b three data sorts are associated: an identity sort bi , an action sort ba , and a transaction sort bt . The corresponding set of data sorts are called SOi , SOa , and SOt . SOi is pairwise disjoint with SOa and SOt .

De nition 3 (extended data signature with transactions) Let D = (SD ; SD ) be a data signature and CT = (SO ; I; A; T ) be a class signature with transactions over D . The extended data signature with transactions, T = (S; ), is given by  S = SD [ SOi [ SOa [ SOt , where SOi = fbi j b 2 SO g, SOa = fba j b 2 SO g, SOt = fbt j b 2 SO g, SOi \ SOa = ;, SOi \ SOt = ;, and  = D [ iO [ aO [ tO , where iO;xi;bi = Ix;b , aO;bi xi ;ba = Ax;b , and tO;bi xi ;bt = Tx;b for  . The other sets in the families are empty. Let every object sort b 2 SO and every x 2 SDO i i  xi := si : : : xi 2 S i where si = s for S = SD [ SO , then we de ne for x = s1 : : : sn 2 SDO j n 1 j sj 2 SD (j = 1; : : : ; n). The interpretation of an extended data signature is an algebra. Especially, the sort of identities is interpreted through a set of global identities. De nition 4 (model of an extended data signature) Let T = (S; ) an extended data signature. A T -algebra U is a model of T . Each extended data signature gives rise to a so-called instance signature. Instance signatures will be the basis for de ning models of objects. An instance signature consists of a set of identities, a set of global actions, and a set of transactions.

De nition 5 (instance signature with transactions)

An instance signature with transactions is a tripel IT = (Id; Ac; Trac) with  a set of identities Id and  a set of global actions Ac  Pf+ (LAc). Each global actionS in Ac is a nite, non-empty subset of local actions LAc. The set of local actions LAc = i2Id LAci is given as the union of the action alphabets of all objects. Moreover, all global actions  = f1 ; : : : ; n g 2 Ac satisfy :(j 2 LAci ^ k 2 LAci ), j; k = 1; : : : ; n; j 6= k;, i 2 Id; and  a set of transactions Trac = Si2Id Traci .

Global actions are set of local actions. Here, our model diers from [ES95]. The sets of local actions are disjoint, i.e., objects do not share actions. We prefer this kind of representation since it is closer to Troll speci cations. In Troll each object speci cation determines a set of action symbols. Action sharing between objects is not expressed through identical action names, rather than through interaction rules. An interaction rule establishes a synchronisation point between objects. The model used in this paper represents such points via global actions. The elements of the global actions, i.e., the local actions, will take place synchronously. This interpretation of global action restricts the form of global actions. Global actions have to be composed of local actions of dierent objects. This is due to the fact that we assume single objects to be sequential. An object can only take part in a global action with at most one local action. Concurrency comes into play via object systems, where objects may locally execute actions independent from other objects. Analogously, transactions are local to objects. The de nition of partners of a global action is de ned intuitively: De nition 6 (partner of a global action) Let  = f1; : : : ; ng 2 Ac be a global action and without loss of generality, we assume i 2 LAci , i 2 Id. We call P () = f1; : : :; ng the partners of action . An extended data signature with transactions T together with an algebra U determines an instance signature with transactions.

De nition 7 (I -instance signature with transactions) For a given extended data signa-

ture with transactions T and a T -algebra U , we derive the instance signature with transaction IT = (Id; Ac; Trac) in the following way  Id = Sbi Ubi ; b 2 SO , is the set of global identities;  Ac is the set of global actions. Let !j 2 aO;bi xi ;ba ; j = 1; : : : ; n; be local action symbol. Let U!j be the interpretation of these action symbol, let sj 2 Ubi be an identity, and let tj 2 Uxi be a data value, the local action of object sj is given as U!j (sj ; tj ). A set of local actions is a global action i all identities are dierent, i.e., s 6= s for  6= . Therefore, U! = fU!1 (s1 ; t1 ); : : : ; U!n (sn ; tn )g is a global action with partners P (U! ) = fs1 ; : : : ; sn g. We denote the set of local actions of object i by LAci and the set of all local actions by LAc = Si2Id LAci . Consequently, Ac  Pf+ (LAc).

 Trac is the set of transactions. Let ! 2 tO;bi xi ;bt , b 2 SO be a transaction symbol and let U! its interpretation in U . For data values us 2 Ubi , ut 2 Uxi we get the transaction U! (us ; ut ).

These are the prerequisites for de ning a semantics for object-oriented speci cations with transactions. The IT -instance signature with transactions derived from the Troll speci cation will be the starting point for a model de nition.

3 Transaction Semantics Interpretation structures of instance signature are labelled event structures with full concurrency. Models of single objects are sequential processes and models of systems are concurrent processes. Both of these notions are part of the concept of event structures, namely sequential event structures as specializations of concurrent event structures. Concurrent event structures are sequential event structures put together at speci c communication points. These points of synchronization are marked with global actions which involve several objects. The event structures used in this paper are similar to those introduced by Winskel in [WN95]. As in [ES95] we use sequential event structure as models for single objects. We repeat those de nitions which will be used later on for de ning a semantics of transactions, so that this paper is self-contained. The following four de nitions correspond to [ES95].

De nition 8 ((sequential) event structure) where

     

A event structure is a triple E = (Ev; ! ; #)

Ev is a set of events, !  Ev  Ev is a partial order (causality relation), #  Ev  Ev is a symmetric, irre exive relation (con ict relation). # e := fe0 j e0 ! eg, e 2 Ev, is nite (local con guration), e#e0 ^ e0 ! e00 ) e#e00 for all e; e0 ; e00 2 Ev (con ict propagation), e co e0 , e; e0 2 Ev, i :(e ! e0 _ e0 ! e _ e#e0 ) (concurrency).

It is called sequential if and only if the following conditions hold:  there exists a unique, minimal element  2 Ev,  all local con gurations # e are totally ordered,  e#e0 , :(e ! e0 _ e0 ! e) for all events e; e0 ; e00 2 Ev.

The minimal element  is the initial con guration where no action has occurred. Since the con ict relation is a derived concept in sequential event structures, we denote them by E = (Ev; !), assuming that ! is the re exive and transitive closure of the irre exive relation !.

De nition 9 (life cycle) sub-event structure of E .

A life cycle of an event structure E is a maximal, totally ordered

A life cycle of a sequential event structure is a possible run of the corresponding object. Each object is interpreted by a sequential event structure and the model of the whole system is given by the union of these event structures, linked at shared events. A shared event represents a communication point where several objects synchronously execute local actions. For a given instance signature with transactions IT , we construct a IT -event structure as the union of sequential event structures. De nition 10 (IT -event structure) Let SIT = (Id; Ac; Trac) an instance signature with transactions. A IT -event structure is the union E~ of an Id-indexed family ofSlocally sequential event structures E~ = fEi gi2Id, Ei = (Evi ; !i ). We denote by Ev+ = Ev~ + ; Ev~ + = fEvi+ gi2Id = fEvi ? i gi2Id; the set of proper events. Con ict remains to be a derived concept in IT -event structures, i.e., e#f; e; f 2 Ev if and only if there exists a local con ict: e0 ; f 0 2 Evi such that e0 #f 0 and e0 ! e and f 0 ! f . A distributed life cycles of IT -event structures is the union of life cycles of locally sequential event structures, which share events.

De nition 11 (distributed life cycle) Let E be a IT -event structure. A distributed life cycle L = (Lc;S!) inSE is a sub-event S L  E that is the union of a family of life cycle of S Estructure = E~ and L  E for i 2 Id. L  E , i.e., L = L~ = i

i2Id i

i2Id i

i

i

We use labelled event structures as interpretation structures. Since we do not assume shared action alphabets, our de nition of labelling diers from the one in [ES95]. We mark an event with a global action, which is a set of local actions.

De nition 12 (labelling) Let E = (Ev; !) a IT -event structure. A labelling  for E , ) ,  : Ev+ ! Ac  Pf+(S2Id LAc i S is a function which assigns a set of local actions, i.e., a global action, to each event.  = ~ is the union of a family of maps ~ = fi : Evi+ ! LAci gi2Id, which satisfy the condition

8e0 ; e00 2 Ev : (9e 2 Ev : e ! e0 ^ e ! e00 ) ) (e0 ) 6= (e00 ): The condition restricts the expressiveness of the models. We only consider models which represent deterministic behaviour. The consequence of the occurrence of an action at a speci c point in time is uniquely determined, i.e., there exists exactly one following state. This does not aect external non-determinism which is presented via con icts in the event structures. Extensions of this model towards taking internal non-determinism into account are currently under consideration. Now we get labelled IT -event structures as interpretation structures of instance signatures. De nition 13 (IT -interpretation structure) A labelled IT -event structure E = (E; ) is an interpretation structure for a given instance signature IT . A distributed life cycle L  E together with the restricted labelling, L = (L; jL ), is called interpretation. We derived special instance signatures from extended data signatures with transactions, which directly correspond to Troll-speci cations with transactions. The constructions of a speci c event structure, which serves as a standard model can be adapted from [ES95]. The only dierence results from the slightly dierent de nition of global and local actions. The labelling of the constructed event structure is given, such that each event of an object is labelled with the corresponding local action, and the labelling of shared events is given by the set of all local actions that are executed by objects taking part in the event in question. An extended data signature only covers the structural part of a speci cation, i.e., attributes, components, and actions. Beside that, a speci cation establishes the possible behaviour of objects via a set of axioms. These axioms are distributed over dierent speci cation constructs, like enabling conditions for actions, eects of actions on attributes, calling rules between actions, etc. The axioms derived from Troll speci cations with transactions will also involve transaction terms. Example 2 (formulas and transactions { insurance company) We will illustrate the need of formulas which involve transactions. Let assume the following part of a speci cation: object type Insurance Company attributes insurance#: nat initialized transactions

0

TakeOutLifeInsurance(AF,HC) = ...

changing insurance#=insurance#+1 The number of insurances is incremented by each TakeOutLifeInsurance that is executed. To cover this changing-rule for a transaction, we might formulate an assertion that states if the number of insurances equals n before the execution of TakeOutLifeInsurance, than it will equal n+1 after the execution of this transaction. Thus, we must be able to speak about the occurrence of a transaction. Intuitively, a transaction has occurred if and only if all corresponding actions have been executed according to the speci ed order. We propose a temporal logic as a uniform basis to cope with dierent language concepts as for instance enabling and eects of actions and transactions, respectively. The proposed logic is an extension of the one de ned in [ES95] (DTL Distributed Temporal Logic) which covers the notion of transaction.

De nition 14 (logic with transactions) Let T = (S; ) an extended data signature with transaction, X = fXsgs2S an S -indexed family of variable sets, and TT (X ) the set of T -data terms. The logic with transactions LT (X ) is inductively de ned as follows:  if t1 ; t2 2 TT (X ) then t1 = t2 2 LT (X ),  if  2 TT (X )ba or  2 TT (X )bt for some object sort b 2 SO , then   2 LT (X ) (enabled (trans)action),  if  2 TT (X )ba or  2 TT (X )bt for some object sort b 2 SO , then  2 LT (X ) (occurred (trans)action),  if ' 2 LT (X ) then :' 2 LT (X ),  if '; 2 LT (X ) then ' _ 2 LT (X ),  if ' 2 LT (X ) and x 2 Xs then 9x ' 2 LT (X ),  if ' 2 LT (X ) and i 2 TT (X )bi ; b 2 SO ; then Yi ' 2 LT (X ) (yesterday),  if ' 2 LT (X ) and i 2 TT (X )bi ; b 2 SO ; then Pi ' 2 LT (X ) (sometimes in the past),  if ' 2 LT (X ) and i 2 TT (X )bi ; b 2 SO ; then Xi ' 2 LT (X ) (tomorrow),  if ' 2 LT (X ) and i 2 TT (X )bi ; b 2 SO ; then Fi ' 2 LT (X ) (sometimes in the future).

Example 3 (a formula with transaction { insurance company) The formula representing

the changing rule for the transaction TakeOutLifeInsurance is IC :

TakeOutLifeInsurance ^ PIC( fill ) r.insurance#(n+1)

in

^ YIC r.insurance#(n))

where IC is an object identity of type Insurance Company. The formula says that when the transaction TakeOutLifeInsurance has been executed, and if the value n has been read for the attribute insurance# in the state before the execution of the rst action of this transaction, i.e., fill in, than it is possible to read the value n+1 for insurance# in the state in question. Because of space limitation, we refrain from translating Troll-speci cations into rei cation logic. Work in this direction has been done by [Jun93] who gave a semantics of Troll-speci cations by translating the language features into OSL (object speci cation logic [SSC92]). OSL is a linear temporal logic like ours, but without the locality principle. Also [Con94] presents a schematic translation of TROLL light -speci cations into a basic calculus developed for veri cation purposes. The rst author reconsidered the translation of Troll-concepts in the presence of transactions [Den95b]. Problems with temporal operators arise when transactions are introduced, corresponding to those when re nement is considered for a temporal logic. What has been \tomorrow" or \yesterday", respectively, from the action point of view, may become \sometimes in the future" or \sometimes in the past", respectively, from the transaction point of view. This is due to the fact, that action execution corresponds to exactly one step, whereas transactions are executed in several steps. In [Den95b] we gave a transformation of Troll-concepts into logic with transactions which reckons with these issues. The translation has shown, that an arbitrary temporal logic is not necessary to translate all concepts. Usually, designer only built Troll speci cations exploiting temporal formulas with a certain complexity. Since arbitrarily nested temporal formulas are not intuitive nobody will use such formulas for specifying. Also with respect to veri cation purposes, arbitrary nested temporal formulas are not feasible (cf [GJSS95]). Currently, we work on de ning a temporal logic, expressively enough to cover most of the Troll-concepts, but still reasonably with respect to proof techniques.

With our example we already showed, that it is necessary to have a function that returns the rst action of a transaction. Such a function is necessary to formulate sentences like \before a transaction a formula was valid". The rst action to be executed in a transaction is not always uniquely determined. In case the if then else-construct is used, the rst action depend on the regarded state. Therefore, the beg-function as detailed below, returns a disjunction of expressions of the form  ^ c, where c is the condition when  has to be executed.

De nition 15 (begin of a transaction) Let T = (S; ) W be an extended data signature with transactions. We de ne the function beg : TT (X )bt ! (TT (X )ba ^ TT (X )bool ), for a transaction term t 2 TT (X )bt ; b 2 SO , which assigns a disjunction of expressions of the form  ^ c,  action term, c boolean term, to each transaction term. This function is inductively de ned as follows:  beg(t) = (t ^ true) for t 2 TT (X )ba ,  beg(t) = (beg(t1) ^ true) for t = SEQ(t1 ; t2 ); ti 2 TT (X )bt ,  beg(t) = (beg(t1) ^ c) _ (beg(t2 ) ^ :c) for t = IF (c; t1 ; t2 ); c 2 TT (X )bool ; ti 2 TT (X )bt ,  beg(t) = (beg(t1) ^ c) _ (nil ^ :c) for t = WHILE (c; t1 ); c 2 TT (X )bool ; t1 2 TT (X )bt .

For the rest of the paper we assume, that the behavioural part of Troll-speci cation has been translated to temporal logic formulas in LT (X ). The structural part is re ected by an extended data signature with transactions. Models of speci cations are event structures which full l all axioms. Therfore, we need a satisfaction relation for formulas in event structures. Additionally to the one de ned in [ES95], we have to take formulas into consideration which incorporate transaction terms. Especially, formulas may involve transaction terms like   and  ,  2 TT (X )bt . Because of our de nition of global actions as sets of local actions the satisfaction relation diers in details from the one given in [ES95]. But apart from transaction terms, the ideas correspond to those given [ES95]. Transactions are speci ed as procedural expressions (s. Def. 1). The intended interpretation of  for a transaction  is, that  holds if and only if all actions belonging to the transactions have occurred. To de ne satisfaction we distinguish between the cases sequence, choice or loop for transactions.

De nition 16 (satisfaction) Let T = (S; ; ) be an extended data signature with transactions, let U be a T -algebra, and IT = (Id; Ac; Trac) be the instance signature with transactions induced by T and U . Let E = (E; ) = (Ev; !; ) be a labelled IT -event structure and L = (L; jL) a distributed life cycle in E . U 2 Ac is the action which correspond to the action symbol  2 TT (X )ba and U 2 Trac is the transaction which correspond to the transaction symbol  2 TT (X )bt , (b 2 SO ). Given a variable assignment , local formulas are interpreted in a local con guration # e of L. The satisfaction relation j= is inductively de ned in the following way: 1. (L ; # e; ) j= i : (t1 =ss t2 ) i t1U = t2U ; 2. (L ; # e; ) j= i :  i e 2 Lc[ i] U and U 2 (e); 3. (L ; # e; ) j= i :  i e 2 Lc[ i] U and (L ; # e0 ; ) j= i :  for some e0 2 Ev[ i] U such that e ![ i] U e0 ; 4. (L ; # e; ) j= i : :' i e 2 Lc[ i] U and not (L ; # e; ) j= i : ', 5. (L ; # e; ) j= i : ' ) '0 i e 2 Lc[ i] U and (L ; # e; ) j= i : '0 or (L ; # e; ) j= i : :'; 6. (L ; # e; ) j= i : 9x ' i e 2 Lc[ i] U and (L ; # e; 0 ) j= i : ' for some x-equivalent assignment 0 ;

7. (L ; # e; ) j= i : Yj ' i e 2 Lc[ i] U and (L ; # e0 ; ) j= j : ' e0 ![ i] U e or e0 ![ j] U e; 8. (L ; # e; ) j= i : Pj ' i e 2 Lc[ i] U and (L ; # e0 ; ) j= j : ' e0 ! e; 9. (L ; # e; ) j= i : Xj ' i e 2 Lc[ i] U and (L ; # e0 ; ) j= j : ' e ![ i] U e0 or e ![ j] U e0 ; 10. (L ; # e; ) j= i : Fj ' i e 2 Lc[ i] U and (L ; # e0 ; ) j= j : ' e !  e0 ;  # e0 ; ) j= i :  11. (L ; # e; ) j= i :  i e 2 Lc[ i] U and (E; 0 e ![ i] U e ;

for some e0 2 Lc[ j] U such that for some e0 2 Lc[ j] U such that for some e0 2 Lc[ j] U such that for some e0 2 Lc[ j] U such that for some e0 2 Ev[ i] U such that

12. (L ; # e; ) j= i :  i the following de nition holds:   = SEQ(1 ; 2 ), 1 ; 2 2 TT (X )bt : (L ; # e; ) j= i : SEQ(1 ; 2 ) i e 2 Lc[ i] U and (L ; # e; ) j= i : 2 and let e0 be the greatest event (according to causal ordering) such that e0 ![ i] U e and (L ; # e0 ; ) j= i : ( j ^ cj ), W beg(2 ) = j=1;:::;n (j ^ cj ), then (L ; # e0 ; ) j= i : Yi 1 .   = IF (c; 1 ; 2 ), 1 ; 2 2 TT (X )bt , c 2 TT (X )bool : (L ; # e; ) j= i : IF (c; 1 ; 2 ) i e 2 Lc[ i] U and one of the following cases holds: (1) (L ; # e;0 ) j= i : 1 and let e0 be the greatest event (according to causal ordering) such that e ![ i] U e and W W (L ; # e0 ; ) j= i : j=1;:::;n (j ^ cj ), beg(1 ) = j=1;:::;n (j ^ cj ), then (L ; # e0 ; ) j= i : Yi c. or (2) (L ; # e; ) j= i : 2 and let e0 be the event such that e0 ![ i] U e and W (L ; # e0 ; ) j= i : (j ^ cj ), beg(2) = j=1;:::;n (j ^ cj ), then (L ; # e0 ; ) j= i : Yi :c.   = WHILE (c; 1 ), 1 2 TT (X )bt , c 2 TT (X )bool : (L ; # e; ) j= i : WHILE (c; 1 ) i e 2 Lc[ i] U and (L ; # e; ) j= i : :c and (L ; # e; ) j= i : loop(c; 1 ). (L ; # e; ) j= i : loop(c; 1 ) i the0 following holds: If (L ; #0 e; ) j= i : 1 and let e be theW greatest event (according to causal W ordering) such that e ![ i] U e and (L ; # e0 ; ) j= i : j=1;:::;n ( j ^ bj ) (beg(2 ) = j=1;:::;n (j ^ bj )), than (L ; # e0 ; ) j= i : Yi c and (L ; # e0 ; ) j= i : Yi loop(c; 1 ).

We will explain the rules. Data terms are as usually interpreted state-independent. The interpretation of the occurrence predicate has changed compared with [ES95]. As already mentioned, global actions are sets of local actions, and events are marked with global actions. A local action occurred if and only if its interpretation is part of the labelling of the event in question. The formalization of the enabling predicate is a bit subtle, since it is interpreted not just in the life cycle, rather than in the whole event structure. An action is enabled if it may occur in some next step which is not necessarily belonging to the life cycle. The rules four to six are adapted from predicate calculus as already given in [ES95] and the interpretation of the temporal formulas in rules seven to ten is adopted from [ES95]. For the temporal operators the events e0 may belong to dierent life cycle. For an object i to know

whether ' holds for j or not in the next state, i and j may communicate today or tomorrow. The same applies to the \sometimes in the future" operator. The causal chain of events between e and e0 may involve several objects, each of which communicates with its predecessor and successor via event sharing. Analogously, we formulated rules for the past-tense operators. From rule eleven on, we treat occurrence and enabling of transaction. The eleventh rule says that a transaction is enabled if and only if it may happen in a succeeding con guration in the frame. Analogously to the interpretation of the enabling predicate of actions, the succeeding con guration does not necessarily belong to the life cycle considered. Moreover, the succeeding state usually will not be a direct successor, since transactions are composed of several actions. For de ning the occurrence predicate for transaction in rule twelve we distinguish between the kinds of transactions, i.e. sequences, choices or loops. Sequence: a sequence 1 ; 2 occurred in a con guration # e if the following two things hold: (1) the second part of the sequence 2 happened in e, and (2) if e0 is a preceding event of e in which the rst action of 2 occurred, then 1 occurred in the previous step. Usually e0 is not the direct predecessor of e, since 2 might be composed of several actions, each of which is executed in one step. Therefore, it takes several steps to perform 2 . Choice: a choice IF (c; 1 ; 2 ) occurred if one of the following two cases holds: (1) assume 1 occurred in the con guration, so c must have been true in the state immediately preceding the state in which the rst action of 1 happened or (2) analogously, if 2 occurred we require :c to be true in the state directly preceding the state in which the rst action of 2 happened. While: for transactions which are built using the WHILE -operator we formalized the following idea: In a local con guration e the formula WHILE (c; 1) is true, if and only if condition c is not true in e, to indicate that the loop has been terminated, and the predicate loop is valid in e. This loop-predicate re ects the idea, that as long as the condition is valid 1 will be performed. That means, if the transaction has occurred, than in the state before the rst action of the transaction happened c must have been true and again the loop predicate holds. Testing the loop predicate terminates when a state is reached, where the transaction has not been executed, at the latest when the rst event of the the examined life cycle is reached. We introduced transaction as an autonomous concept into class signatures, extended data signatures, and instance signatures. Furthermore, we enlarged DTL, which serves as a transformation domain for Troll-speci cation, by logical elements to treat transaction and gave an appropriate interpretation in our model of event structures. Now we are able to de ne system speci cations with transactions and their models. Models of system speci cations are event structures that satisfy all axioms derived from the speci cation.

De nition 17 (system speci cation with transaction) A system speci cation with transaction is a pair SysSpecT = (T ; T ) where T is an extended data signature with transactions and T is a set of local formulas, T  LlT (X ), LlT (X ) = fi : ' j i 2 TT (X )bi ; b 2 SO ' 2 LT (X )g.

De nition 18 (model class { model { run) Let SysSpecT = (T ; T ) a system speci cation with transactions. The model class is de ned as the set of all event structures E which satisfy all axioms ' 2 T , E j= '. A model is an event structure of the model class, and a run is a distributed life cycle of an event structure. An event structure models a formula if and only if all its distributed life cycles model the formula in question in every con guration for a given variable assignment.

4 Concluding Remarks In this paper we addressed the notion of transaction in object-oriented speci cation. Transactions are a suitable concept to cover dierent aspects that arise in a variety of contexts, e.g., re nement theory (re nement of actions to transactions), database theory (transactions as an abstraction

concept) or business process modelling (transactions as complex processes, which are a composition of parts with a prede ned execution order). The focus of our work is the stepwise design and modelling of information systems with objectoriented techniques. Since all problem areas mentioned are relevant for this, we introduced transactions into object-oriented speci cations. We developed a theory for object-oriented speci cations with transactions on top of the work done in [ES95]. There, a theory for distributed families of concurrent objects have been proposed based on the notion of event structures and a temporal logic with locality. We started with class signatures which serve as a transformation domain for Troll-speci cations. Class signatures cover the structural part of Troll speci cations, i.e., actions, attributes and components. The behaviour of speci cations is formalized in a temporal logic. Especially, we developed a logic which may express assertions about transactions and gave a suitable interpretation of this logic in event structures. This constitutes a uniform formal framework which might serve as a denotational semantics of object-oriented concepts in the presence of transactions. After we have now xed the technical prerequisites to syntactically and semantically handle transactions, much more work could be done. Concerning re nement issues, the question arises when re nement of actions to transactions is correct. Especially, the set of axioms established by a speci cation has to be carefully investigated under re nement. Syntactical and semantical re nement functions exploit the notion of transactions. Work in this direction has been given in [DE95, Den95a] and is subject of the thesis [Den95b]. There is a very sophisticated theory of transactions in database theory. Correctness criteria for transactions have been developed and practically converted into protocols. First steps towards a formalization of transactions in the sense of database theory have been made in [Den95b]. The results of the wide database area are still to be applied to the object-oriented eld. Our syntax for transaction speci cations is restricted in dierent ways. (1) Transactions may only be speci ed in the context of one object type by means of processes built of actions of the object type. It is much more natural to specify transactions \across" several object types through composing actions from dierent object types to a transaction. Though this can also be achieved with our approach by introducing additional composed objects, it is desirable to weaken this restriction and establish a more natural language which is closer to applications. (2) Actions used in a transaction are only allowed to occur once in the transaction. For instance it is not allowed to specify trac=;while c do ; od. This is due to our interpretation of transaction terms. For instance, a formula involving beg(trac) (=) would be evaluated to true in a state where  is true, even if this state is not necessarily a state where the rst action of trac happened.  is valid in each state in which one of the two speci ed 's occurred. The practicability of transaction de nitions as proposed in this paper has to be validated with case studies.

Acknowledgements

This paper has been developed in the context of the database group in Braunschweig. We deeply thank our colleagues from Braunschweig for fruitful and encouraging discussions. Moreover, the comments and questions of members of IS-CORE and COMPASS at former workshops have been helpful to clarify our understanding of transactions.

References [BHG87] [Boo94]

P.A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison Wesley, 1987. G. Booch. Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, Redwood City, CA, 2nd edition, 1994.

[Bor95]

P. Borba. Semantics and Re nement for a Concurrent Object Oriented Language. PhD thesis, Oxford University Computing Laboratory, Programming Research Group, Wolfson Building, Parks Road, Oxford, OX1 3QD, England 1995. [Con94] S. Conrad. Ein Basiskalkul fur die Veri kation von Eigenschaften synchron interagierender Objekte. Fortschritt-Berichte Reihe 10, Nr. 295. VDI-Verlag, Dusseldorf, 1994. [CY91] P. Coad and E. Yourdon. Object-Oriented Analysis. Prentice Hall, Englewood Clis, NJ, 2nd edition, 1991. [DDPW94] E. Dubois, P. Du Bois, M. Petit, and S. Wu. ALBERT: A Formal Agent-Oriented Requirements Language for Distributed Composite Systems. In E. Dubois, P. Hartel, and G. Saake, editors, Proc. Workshop on Formal Methods for Information System Dynamics, preceding the CAiSE'94 conference, Utrecht, 6-7 June, 1994, pages 25{38. University of Twente, 1994. Memoranda Informatica 94-33. [DE95] G. Denker and H.-D. Ehrich. Action Rei cation In Object Oriented Speci cation. In R. Wieringa, editor, Proc. Intern. Workshop on Information Systems { Correctness and Reusability (IS-CORE'94), Amsterdam, Sept. 1994, Selected Papers. World Scienti c Publishers, 1995. To appear. [Den95a] G. Denker. Transactions in Object-Oriented Speci cations. In E. Astesiano, G. Reggio, and A. Tarlecki, editors, Recent Trends in Data Types Speci cation, Proc. 10th Workshop on Speci cation of Abstract Data Types joint with the 5th COMPASS Workshop, S.Margherita, Italy, May/June 1994, Selected papers, pages 203{218. Springer, Berlin, LNCS 906, 1995. [Den95b] G. Denker. Verfeinerung in objektorientierten Spezi kationen { Von Aktionen zu Transaktionen. PhD thesis, TU Braunschweig, Abt. Datenbanken, Postfach 3329, D-38023 Braunschweig, 1995. In preparation. [DG91] P. Degano and R. Gorrieri. Action Re nement for Process Description Languages. In A. Tarlecki, editor, Proc. 16th Symp. on Mathematical Foundations of Computer Science (MFCS'91), pages 121{130. Springer, 1991. LNCS 520. [DKRS91] R. Duke, P. King, G. Rose, and G. Smith. The Object-Z Speci cation Language. In Proc. Technology of Object-Oriented Languages and Systems (TOOLS), pages 465{483, 1991. [DO91] O.-J. Dahl and O. Owe. Formal Development with ABEL. Technical Report 159, University of Oslo, 1991. [ES95] H.-D. Ehrich and A. Sernadas. Local Speci cation of Distributed Families of Sequential Objects. In E. Astesiano, G. Reggio, and A. Tarlecki, editors, Recent Trends in Data Types Speci cation, Proc. 10th Workshop on Speci cation of Abstract Data Types joint with the 5th COMPASS Workshop, S.Margherita, Italy, May/June 1994, Selected papers, pages 219{235. Springer, Berlin, LNCS 906, 1995. [ESSS94] H.-D. Ehrich, A. Sernadas, G. Saake, and C. Sernadas. Distributed Temporal Logic for Concurrent Object Families. In R. Wieringa and R. Feenstra, editors, Working papers of the International Workshop on Information Systems - Correctness and Reusability, pages 22{30. Vrije Universiteit Amsterdam, RapportNr. IR-357, 1994. [FM91] J.L. Fiadeiro and T. Maibaum. Describing, Structuring and Implementing Objects. In J.W. de Bakker, W.-P. de Roever, and G. Rozenberg, editors, Foundations of ObjectOriented Languages, Proc. REX School/Workshop, Noordwijkerhout, The Netherlands, May/June 1990, pages 274{310. Springer, 1991. LNCS 489.

[FM94]

[GJSS95] [GR93] [HJ94] [HSJ+ 94] [Jun93] [Lan91] [LMWF94] [Mal94] [MG94] [NEL89]

 [Ost95] [RBP+ 91] [RS92] [Ser91]

J.L. Fiadeiro and T. Maibaum. Sometimes \Tommorrow" is \Sometime" { Action Re nement in a Temporal Logic of Objects. In D. M. Gabbay and H. J. Ohlbach, editors, Proc. First Int. Conf. on Temporal Logic, ICTL, Bonn, Germany, July 1994, pages 48{66. Springer, 1994. LNAI 827. P. Gouveia, R. Jungclaus, G. Saake, and C. Sernadas. Feasible Object Certi cation. Technical Report 14/95, Instituto Superior Technico (IST), Dept. Mathematica, Av. Roviso Pais, 1096 Lisboa Codex, Portugal, 1995. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Data Management Systems. Morgan Kaufmann Publishers, San Mateo, California, 1993. P. Hartel and R. Jungclaus. Specifying Business Processes over Objects. In P. Loucopoulos, editor, Proc. 13th Int. Conf. on the Entity-Relationship Approach (ER'94), pages 10{27. Springer, LNCS 881, Berlin, 1994. T. Hartmann, G. Saake, R. Jungclaus, P. Hartel, and J. Kusch. Revised Version of the Modelling Language Troll (Version 2.0). Informatik-Bericht 94{03, Technische Universitat Braunschweig, 1994. R. Jungclaus. Modeling of Dynamic Object Systems|A Logic-Based Approach. Advanced Studies in Computer Science. Vieweg Verlag, Braunschweig/Wiesbaden, 1993. K. Lano. Z++: An Object-Oriented Extension to Z. In Proc. Z User Meeting. Springer, Workshops in Computer Science, 1991. N. Lynch, M. Merritt, W. Weihl, and A. Fekete. Atomic Transactions. Data Management Systems. Morgan Kaufmann, San Mateo, California, 1994. G. Malcolm. Interconnections of Object Speci cations. In Proc. of the BCS/FACS Workshop on Formal Aspects of Object-Orientated Programming, London, December 1994, 1994. To appear. G. Malcolm and J.A. Goguen. Proving Correctness of Re nement and Implementation. Technical Monograph PRG-114, Oxford University Computing Laboratory, Programming Research Group, November 1994. Submitted for publication. M. Nielsen, U. Engberg, and K.S. Larsen. Fully Abstract Models for a Process Language with Re nement. In J.W. de Bakker, W.-P. de Roever, and G. Rozenberg, editors, Linear Time, Branching Time and Partial Order in Logics and Models for Concurrency, Proc. REX School/Workshop, Noordwijkerhout, The Netherlands, May/June 1988, pages 523{549. Springer, 1989. LNCS 354.  H. Osterle. Business Engineering. Springer-Verlag, Berlin, 1995. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice-Hall, Englewood Clis, NJ, 1991. L. Rapanotti and A. Socorro. Introducing FOOPS. Technical Report Report PRGTR-28-92, Programming Research Group, Oxford University Computing Laboratory, 1992. Sernadas, A. and Sernadas, C. and Gouveia, P. and Resende, P. and Gouveia, J. OBLOG { Object-Oriented Logic: An Informal Introduction. Technical report, INESC, Lisbon, 1991.

[SGS92]

[SSC92] [vGG90] [Vog93] [Wie91] [WM91] [WN95] [Zuc95]

C. Sernadas, P. Gouveia, and A. Sernadas. Re nement: Layered De nition of Conceptual Schemata. In E.D. Falkenberg, C. Rolland, and E.N. El-Sayed, editors, Information System Concepts: Improving the Understanding, pages 19{51. North-Holland, 1992. IFIP Transactions. A. Sernadas, C. Sernadas, and J.F. Costa. Object Speci cation Logic. Internal Report, INESC, University of Lisbon, 1992. To appear in Journal of Logic and Computation. R. van Glabbeek and U. Goltz. Equivalences and Re nement. In I. Guessarian, editor, Semantics of Systems of Concurrent Processes, pages 309{333. Springer, April 1990. LNCS 469. W. Vogler. Bisimulation and action re nement. Theoretical Computer Science, 114:173{200, 1993. R.J. Wieringa. A Conceptual Model Speci cation Language (CMSL, Version 2). Technical Report IR-248, Faculty of Mathematics and Computer Science, Vrije Universiteit Amsterdam, 1991. P.J. Whysall and J.A. McDermit. Object Oriented Speci cation and Re nement. In J.M. Morris and R.C. Shaw, editors, 4th Re nement Workshop, pages 150{184. Springer, 1991. Workshops in Computing. G. Winskel and M. Nielsen. Models for Concurrency. In S. Abramsky, D.M. Gabbay, and T.S.E. Maibaum, editors, Handbook of Logic in Computer Science, Vol. 4, Semantic Modelling, pages 1{148. Oxford Science Publications, 1995. E. Zucca. Implementation of data structures in an imperative framework. In E. Astesiano, G. Reggio, and A. Tarlecki, editors, Recent Trends in Data Types Speci cation, Proc. 10th Workshop on Speci cation of Abstract Data Types joint with the 5th COMPASS Workshop, S.Margherita, Italy, May/June 1994, Selected papers, pages 483{498. Springer, Berlin, 1995. LNCS 906.