MAINTAINING SHARED WORKSPACES CONSISTENCY DURING SOFTWARE DEVELOPMENT

Maintaining Shared Workspaces Consistencyduring Software DevelopmentHala SkafGroup ECOO, LORIA, BP. 23954506 Vandoeuvre-Les-Nancy Cedex, France,[email protected] CharoyGroup ECOO, LORIA,BP. 23954506 Vandoeuvre-Les-Nancy Cedex, France, [email protected] GodartGroup ECOO, LORIA,BP. 23954506 Vandoeuvre-Les-Nancy Cedex, France, [email protected] development of large software is always done by teams of people working togetherand struggling to produce quality software within their budget. Each person in theseteams generally knows his job and wants to do it, without being bothered by otherpeople. However, when people work towards a common goal they have to exchange dataand create dependencies between each other regarding these data. If these people haveto follow a process, cooperating and synchronizing with co-workers and trying to reachone's own goal becomes too di�cult to manage. This may leads to frustration, lowerproductivityand reluctancy to follow the prede�ned process. This is why some support isneeded to avoid common mistakes that occur when people exchange data. In this paper,a hybrid approach to support cooperation is presented. The originality of this approachis the ability to enforce general properties on cooperative interactions while using thesemantic of applications to �t particular situations or requirements. This paper gives abrief idea about the general enforced properties on activity interactions. It describes indetail the semantic rules that control activity results, the impacts of the cooperation onthese rules and how both of dimensions interact.Keywords: Cooperation, Cooperative Environment, Constraints, Consistency.1. IntroductionThe development of large software is always done by teams of people workingtogether. Most of the time, these people are struggling to produce qualitysoftware within their budget. Each person in these teams generally knows his1

job and wants to do it in the best conditions, without being bothered by otherpeople. However, when people work towards a common goal, it is very commonthat they have to exchange data and that they create dependencies betweeneach other regarding these data. If their common organization tries to imposea process to them, it may happen that, following this process, cooperating andsynchronizing with co-workers and trying to reach one's own goal becomes toodi�cult for them to manage. This may lead to frustration, lower productivityand reluctancy to follow the prede�ned process. This is why some support isneeded to help people in one of the less interesting part of their jobs: be surethat the process will look like it has been followed and avoid common mistakesthat occur when people exchange data.In this paper, we will consider people who cooperate in a shared workspacein order to reach their goal. This goal is a sub-goal of the team common goal.We suppose that these people are willing to cooperate and to produce the bestresult they can. We also suppose that they agree to follow some prede�nedprocess but that they don't want to lose precious time due to this process.In this context, two approaches are usually proposed to support cooperationamong people: encapsulate their activities in transactions to enforce generalproperties on activity interactions, or describe the cooperation process withsemantic rules as part of the general development process.The transactional approach is based on advanced transaction models thatallow more concurrency between activities[1]. The transactional point of viewconsiders each person's activity as a transaction that has to be completed toreach the sub-goal. The process point of view [2, 3, 4] considers each person'sactivity as a task which has to be completed in a prede�ned order and withsome speci�c conditions. Most of the time, approaches that cover these twopoints of view are biased towards one of them.However, these two points of view are essential in cooperative applicationsbecause there is no single correctness criterion like those proposed by the trans-actional approach to support cooperation. Rather, the notion of what is correctmay vary from application to application and from task to task. Hence we needsemantic rules. But unfortunately semantic rules do not allow to enforce generalproperties on activity interactions.In this paper, we address this limitation by proposing a hybrid approachto support cooperation. This approach enforces general properties on activityinteractions and uses the semantic of applications to �t particular situations orrequirements. This paper gives a brief idea about the general enforced proper-ties on activity interactions, describes in detail the semantic rules that controlactivity results and how both of dimensions interact.The rest of the paper is organized as follows: The next section providesan overview of the context in which we are placing this work and gives themain principles of the hybrid approach. Section 3 shows how the correctness2

of activities results is speci�ed by means of constraints de�ned on states andstate sequences of the shared workspace. Section 4 illustrates the impacts ofcooperation on constraints and the impacts of constraints on cooperation. Itde�nes a new algorithm for monitoring constraints in cooperative applicationsand provides three strategies to evaluate them in this context. Section 5 givesa brief idea about the implementation done in the COO software developmentenvironment. Section 6 concludes the paper.2. Cooperation and Software DevelopmentCooperation can be considered from many points of view [5]. In this pa-per, we consider cooperation from the point of view of working and exchangingdata asynchronously in a shared and persistent workspace. This correspondsto something very common in software development environment. Develop-ment objects (speci�cation, code . . . ) are stored in a repository (a database,a con�guration management system or a �le system). Users associated to thedevelopment activities access these objects to modify them.Specify(graph) Build(graph) Build(graph,app)

Developmentactivities

Repository

Users Fig. 1. Development EnvironmentEach development activity has its own goal which may be divided in sub-goals. For example, in �gure 1, the goal of the activity Build(graph) is to buildthe library graph. In order to achieve their goal, activities cooperate.2.1. Cooperation PrinciplesIn our context, we consider only speci�c kind of cooperation. We say thattwo activities cooperate if they exchange results during their execution througha shared workspace. We distinguish between two kinds of results: intermediate3

results and �nal results.Intermediate Results are preliminary results produced by activities duringtheir execution.Final Results are development objects produced by activities at their termi-nation.To illustrate this, let us consider the activities A1: Build(graph) and A2:Build(graph,app). A1 builds a graphical library graph and A2 uses this libraryto build an application app.The �gure 2 shows the history of the activities A1, A2 and the di�erentstates of the repository. A state of a repository is a collection of the values ofall objects in the repository at a given time.A1 : Build(graph) repository A2 : Build(graph; app)begin(A1) (spec; v0) begin(A2)spec1 read(spec)graph1 = edit()write(graph; graph1) (graph; v1) (spec; v0)graph1 = edit(graph1) graph2 read(graph)app2 = edit()end (graph; v2)(spec; v0) graph2 read(graph)(graph; v2)(app; v3)(spec; v0) endFig. 2. Cooperative ExecutionAn object in the repository is de�ned by a couple (id; v) where id is theobject identi�er and v is its value. The above execution can be interpreted asfollows:� At the beginning of A1, the repository contains only the object spec withv0 as value. We represent the initial state of the repository by: (spec, v0) .� The user working in A1 starts building the context of his activity. Heaccesses the speci�cation of the library spec, then creates a local copy spec1of that object in the local memory of his activity (spec1 read(spec)).� He invokes a tool to create a local object graph1 (graph1 = edit()).� Then he publishes a result of graph. This result is intermediate since it isproduced during the execution of A1. We represent the intermediate resultof the object graph by: (graph, v1) . When A1 produces the intermediate4

result of graph, it produces at the same time a new state of the repository.This is an intermediate state. We represent it by: (graph, v1) (spec, v0) .Each time A1 publishes an intermediate result, it also produces a newintermediate state of the repository.The user of A1 repeats the previous steps until the end of his activity.� At its termination, A1 produces the �nal result of graph and a new stateof the repository. This state is represented by: (graph,v3)(spec,v0) . The�nal value of graph in this state is persistent in the repository. The onlyway of modifying this value is to restart a new activity.� In the same way, the user of the activity A2 builds the working context ofhis activity by reading the intermediate result of graph. Notice that theintermediate result of graph produced by A1 allows A2 to start buildingthe application app earlier, before the termination of A1.� A2 edits the application app. It reads again graph and modi�es the ap-plication. Finally, it produces the �nal result of app and terminates itsexecution.This execution is a simple example of a cooperation between two activities.It shows how cooperation can be useful and harmful at the same time. In thiscase, the user of A2 can start his work early with a preliminary version of graph.This is good for productivity. Users do not have to lose their time waiting forsome result to start their work. This can also be harmful if A2 does not takecare to update his work with the �nal version of graph. This may cause somemajor inconsistencies that would not exist without cooperation.Our proposal tries to overcome these problems while providing users withmore exibility. We want users to keep the control, i.e., how, when and withwhom they cooperate, and to help them to avoid possible inconsistencies thatmay be induced by the cooperation. To reach this goal, we propose an approachthat takes into account at the same time the correction of interaction betweenactivities and the correction of activity results in order to ensure what we willcall hybrid correctness.2.2. Hybrid Correctness PrincipleOur approach to support useful cooperation while avoiding its dark side is toseparate correctness into two dimensions: correctness of cooperative interactionsand correctness of individual behavior [6].Correctness of cooperative interactions tackles the problem of concurrencycontrol. In other words, it synchronizes the exchange of shared objectsbetween activities. This correctness dimension is ensured by a syntacticprotocol described in section 2.3.Correctness of individual behavior avoids semantic errors introduced bythe users associated to an activity. It takes into account the values of the5

products (is the product tested, is the code compiled without errors ?) andthe sequences of values of products (the product is tested before its deliveryto the client ..). This dimension is ensured by a constraint monitoringalgorithm that we detail in section 3.We want to be sure that both dimensions are taken into account duringdevelopment activities, i.e. that neither cooperative interactions nor individualbehaviors introduce inconsistencies. We want to be sure that all executions thatare accepted by our system belong to the intersection between activities thathave consistent results and those that have correct interactions (Fig. 3).Consistent Results Correct InteractionsExecutions Set Fig. 3. Executions setsOne of the main issue in this context is that we cannot consider activitiesand their executions one by one but as a whole. Interactions due to cooperationintroduce dependencies that have to be managed. Another fundamental issueis that users are behind activities. They are working interactively and areconducting creative actions. They do not want to be bothered by other usersactions and they do not want to see their work corrupted by others. Users needto keep control on the way they cooperate.Our general philosophy regarding both dimensions is to allow users to doalmost anything that they want, provided that, at the end of their activities,from an external point of view, everything appears just as if things had beendone following the right process and without inconsistencies. Both dimensionsthat are described in the following sections have been de�ned with this idea inmind.2.3. Correctness of Cooperative InteractionsTo overcome synchronization problems between activities which are executedin parallel, we use a transactional approach: each activity is executed as a6

cooperative transaction (COO-transaction) [7].The main di�erence between COO-transactions and classical transactions(ACID transactions) [8] is that COO-transactions are not isolated.Two COO-transactions can cooperate by exchanging data during execution through therepository. Of course, the others properties Atomicity, Consistency and Dura-bility [9] are preserved.The COO-transaction model proposes a syntactical correctness criterion: theCOO-serializability [7]. This criterion can be seen as an evolution of the classicalcorrectness criterion of transactions, serializability [9] to support cooperativeexecution. The COO-serializability criterion guarantees that during cooperativeinteractions, dirty read will be compensated and that there will be no lostupdate (all �nal results will be taken into account) [7]. These properties ofcooperative interactions are enforced by a syntactical protocol (COO-protocol)which synchronizes the exchange of results among cooperative transactions. Itis based on the following synchronization rules:1. If a transaction produces an intermediate result then it must produce thecorresponding �nal result at the commit time.2. If a transaction reads an intermediate result of another transaction thenit must read the corresponding �nal result.3. If a transaction reads an intermediate result of another transaction then itbecomes dependent on that transaction. This dependency is deleted whenthe transaction reads the corresponding �nal result.4. In the case of a cyclic dependency among transactions, the transactions aregrouped. They form a group of cooperative transactions. All transactionsin a group must terminate their execution at the same time and in anatomic way (all or nothing).The execution of the �gure 2 is COO-serializable: A2 has read the �nal resultof graph produced by the transaction A1. This means that the cooperativeinteraction of A1 and A2 is correct. Imagine now that transaction A2 does notread the �nal result of graph (Fig. 4).The execution of the �gure 4 is not COO-serializable: the user of A2 hasread an intermediate result of graph but he has not read the corresponding �nalresult. In this case, the dirty read of the object graph has not been compensated.The transaction A2 can not terminate its execution. The termination operationof A2 is canceled and A2 remains active. The COO-protocol based on COO-serializability never oblige a transaction to abort its work.To summarize, the COO-protocol has the following advantages. It leavesto the users all the initiative regarding cooperation. A user may publish anintermediate result at any time. A user may or may not read intermediateresults published by other users. If he does so, he will have to pay some priceat the end to resynchronize himself with the �nal version of the result he read.From the outside, things will look like he did his work from this last version,7

A1 : Build(graph) repository A2 : Build(graph; app)begin(A1) (spec; v0) begin(A2)spec1 read(spec)graph1 = edit()write(graph; graph1) (graph; v1) (spec; v0)graph1 = edit(graph1) graph2 read(graph)app2 = edit()end (graph; v2)(spec; v0)(graph; v2)(app; v3)(spec; v0) endFig. 4. Incorrect Cooperative Interactionwithout having to wait until the end of the activity on which he did depend. Inthis context, we say that activities are not isolated but insulated [10].The syntactical protocol, introduced above, allows to control the correctnessof cooperative interactions, but it does not avoid errors due to inconsistentbehaviors of activities users.Let us consider the execution of the �gure 2. The cooperative interaction ofthis execution is correct according to the COO-serializability: the transactionA2 has read the �nal result of graph. However, we do not have any guarantee onthe quality of graph (is graph tested ?, compiled without errors ? ) nor abouthow graph has been produced (is graph compiled before it has been tested . . . ).The goal of the individual correctness is to provide such a guarantee withoutrestricting the ability for users to cooperate.3. Correction of Activity ResultsA common way to provide guarantees on product quality is to de�ne a set ofconstraints in the repository and to check that these constraints are veri�ed.It is widely recognized that the quality of a product is not only a�ected byits properties but also by its production process. In our context, where activitiesdo not produce simple database update but actual products, constraints shouldnot only guarantee properties on states but also on the way these states areproduced. To support that, we need to express constraints that cover bothdimensionsStatic constraints describe the properties of objects that must hold in eachstate of the repository. These constraints represent, in some way, quality criteriaof a product. For example, \the design of a module is approved". Intuitively,this constraint describes the fact that at each moment the design of each module,which is accessible in the repository, is approved.8

Static constraints do not allow to de�ne constraints on process i.e. con-straints on states transition and on state sequences. For instance, we can notde�ne constraints like \the product is never delivered to a customer before itsveri�cation". This is why we need dynamic constraints.Dynamic constraints de�ne properties that must hold on states sequence ofthe repository. They de�ne, in some way, criteria on the quality of processes.For example, \the code of a module is never produced before the validation ofits design", means that it is necessary to have in the repository a state in whichthe design of a module is approved before having a state in which the code ofthat module is developed.3.1. Constraints De�nitionOur model to de�ne constraints is based on the work of [11, 12]. Each constraintis de�ned as follows: ci(x1 : t1; : : : ; xn : tn) : �(x1; : : : ; xn)where ci is the constraint identi�er, x1; : : : ; xn are free variables, t1; : : : ; tnare types respectively of x1; : : : ; xn (our objects are typed, each object has atype. For example, d: Design means that the object d is of type Design).� is the formula to verify. A formula is built from non temporal formula(�rst order predicate, by iterative applying of logical connectives: ^; _; ); :)extended with temporal operators (always, sometime, after, before . . . ) [13].For example, the static constraint \The design of a module is approved" canbe de�ned by: c1(d : Design) : always approved(d)approved is a predicate. It is true if the variable d is approved and falseotherwise. The dynamic constraint \A product delivered to a client has beentested before" can be de�ned by:c2(prod : Product) : sometimeapproved(prod)beforedelivered(prod)approved (delivered) is a predicate. It is true if the product is approved(delivered) and false otherwise.Temporal logic has been used in our environment because it provides us witha unique formalism to describe both static and dynamic constraints declara-tively [14]. However, the approach we propose in the following sections couldbe applied with other formalisms (Petri nets, for example).3.2. Monitoring Constraints in a Cooperative EnvironmentThe fundamental hypothesis on which are based all constraints monitoring algo-rithm is that transactions are serializable and atomic [15]. Everything appearsjust like if the transactions were executed one after the other. Thus algorithms9

do not have to consider any kind of interaction between them. Moreover, trans-actions can be rolled back and in the case of constraints violation, the transac-tion is aborted.These hypothesis cannot be applied in our case. Transactions are neitherisolated nor serializable and they are of long duration. We cannot force themto abort. Moreover, we cannot consider that each state of the repository willbe consistent regarding constraints. Our approach does not only break isolationbut it also breaks consistency.3.2.1. Basic PrinciplesA new state is produced each time a result, �nal or intermediate, is produced.However, constraints cannot be checked with intermediate values. Constraintschecking on intermediate values would reduce greatly the ability of users tocooperate as they would be obliged to publish only consistent values. Just asintermediate values can be published without considering serializability, theymay also be published without considering consistency. This means that asin the case of classical transactions, intermediate results produced during thetransaction execution, are not controlled by constraints. In fact, monitoringthe consistency of intermediate results would reduce their usefulness [16]. Pro-ceeding in this way allows to con�rm that the constraints do not reduce the exibility of the environment: in spite of the presence of the constraints, theuser of a cooperative transaction can work as \he wishes" and especially he cancooperate (exchange intermediate results) without actually taking care of theprocess.3.2.2. Impact of cooperationThe main impact of cooperation on constraints evaluation is related to the factthat activities do not execute in isolation and can share intermediate results.As a consequence, if, as traditionally, constraints are checked on the new stateproduced at the end of the activities, all the constraints cannot be checked.Let us take two activities t1 and t2. t1: Modify(dA), t1 modi�es the designof module A and t2: Modify(cA) modi�es its code. Suppose also that we havethe following constraints:� c1: The designs of the modules are approved, which is de�ned by: \c1(d :Design) : always approved(d)", approved is a predicate which is trueif the variable d is approved and false otherwise. Only the transactionswhich manipulate objects of type \Design" can instantiate this constraint.� c2 The code of all the modules is compiled which is de�ned by: \c2(c :Code) : always compiled(c)", compiled is a predicate which is true if thevariable c is correctly compiled and false otherwise. Only the transactionswhich manipulate objects of type \Code" can instantiate that constraint.10

These constraints are de�ned in the repository. Figure 5 shows a possibleexecution of t1 and t2.t1 :Modify(dA) repositoryc1(d : Design) : alwaysapproved(d)c2(c : Code) : always compiled(c) t2 :Modify(cA)begin(t1) (dA; approved)(cA; compiled) begin(t2)dA1 read(dA)dA1 = edit(dA1) cA2 read(cA)write(dA; dA1) (dA; v0) (cA; compiled) dA2 read(dA)cA2 = edit(cA2)(dA; v0) (cA; v1) write(cA; cA2)dA1 = edit(dA1)dA1 = approve(dA1)end (dA; approved) (cA; v1) dA2 read(dA)cA2:obj = compile(cA2)(dA; approved)(cA; compiled) endFig. 5. Cooperative execution of t1 and t2 in the presence of the constraints c1 and c2 .� t1 modi�es the design of the module A (dA), then it produces an interme-diate result of dA.� t2 reads this intermediate value, modi�es the code and produces an inter-mediate result of the code.� After some modi�cations of the design, t1 tries to terminate its execution.t1 can terminate its execution: the Coo-protocol is veri�ed (t1 does notread an intermediate result of t2) and the constraint c1 is veri�ed (the�nal result of t1 (the design of module A dA) is approved).� The state of the repository produced at the termination of t1 is con-sistent with respect to the constraint c1. We symbolize such a a stateby: (dA; approved) (cA;:compiled) . In this state, dA veri�es the constraint c1.However, the constraint c2 is not considered, as the result of t1 has noimpact on it. Thus although there is an intermediate result in the repos-itory that prevents constraints checking, we may accept t1 termination.We suppose that in some future state, t2 will produce the valid �nal resultthat will satisfy all the constraints.� At the end of t1, the object dA is consistent and at the end of t2, theobject cA is consistent. Thus, at the end of t1 and t2 all the objects inthe repository are consistent i.e. the repository is in a consistent state.11

Formally, the degree of consistency ensured by cooperative transactions isweaker than the one ensured by classical transactions: we can not say that therepository is in a consistent state at the end of each transaction. However, weconsider that it is su�cient in a cooperative framework because it allows toensure users that they are working in a correct way and that a consistent statewill be reached in the future.In other words, in cooperative framework, only objects modi�ed by trans-actions must be consistent. In contrast, it is important to ensure that all theobjects will be consistent at the end of all cooperative transactions. In the COOenvironment, this is ensured on the one hand, by the syntactical protocol (Sec-tion 2.3) and on the other hand, by the constraints monitoring algorithm whichensures the consistency of �nal results.One of the main issues that remains is that sometimes a transaction can-not terminate because some intermediate values prevent the evaluation of theconstraints that are concerned by the transaction results. These intermediatevalues may have been produced by another transaction.As we said before, our general philosophy implies that users do not want tobe bothered by cooperation. However, they have sometime to pay some pricefor that. This is what is explained in the following section.4. Constraints Evaluation with Intermediate ResultsA constraint is evaluable if all the objects that can instantiate this constraintare �nal results, i.e. are not intermediate results.For example, if we consider the constraint \c1(x; y): always (x < y)" whichmeans that the value of x is always smaller than the value of y. The initial valueof x is 100, the initial value of y is 150, the transaction t1 modi�es the object xand the transaction t2 modi�es the object y, as shown in the �gure 6.t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x) y2 read(y)x1 = x1 + 50 y2 = y2 � 30write(x; x1) (x; 150) (y; 150)x1 = x+ 20 (x; 150) (y; 120) write(y; y2)end! annulateFig. 6. The constraint c1 is not evaluable at the end of t1.12

� The transaction t1 modi�es the object x and publishes an intermediateresult of x.� The transaction t2 modi�es the object y and publishes an intermediateresult of y.� At the termination of t1, constraints are checked. c1 is not evaluablebecause of the object y which can instantiate c1 and it is an intermediateresult of t2. In this situation the constraint c1 is not evaluable. Thetermination operation of t1 is aborted.To overcome this kind of problem, we have studied the three following strate-gies:1. The transaction terminates its execution and delegates the validation ofits constraints to other active transactions.2. It evaluates its constraints on the last �nal results of the objects, whichare not �nal.3. It delays its termination until it can evaluate its constraints, i.e., new �nalvalues are produced.In the following, we detail these di�erent strategies and explain the advan-tages and the disadvantages of each one.4.1. First strategy: The Other Will Validate the ConstraintsAccording to this strategy, the transaction t1 of the �gure 6 can terminate itsexecution. t1 supposes that t2 will validate c1 at its termination. Thus, we canhave the state: (x,170) (y, 120) at the end of t1 (Fig. 7).t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x) y2 read(y)x1 = x1 + 50 y2 = y2 � 30write(x; x1) (x; 150) (y; 150)x1 = x1 + 20 (x; 150) (y; 120) write(y; y2)end (x; 170) (y; 120)Fig. 7. t1 terminates its execution without validating the constraint c1This solution can lead to di�erent kind of problems:13

1. If t2 wants to abort, the repository becomes inconsistent.2. t2 may also do the same with other transactions (with other constraints)and at the end none will be able to produce a consistent state.This solution removes the responsibility of activity to produce consistentresults. This is incompatible with our vision of cooperation.4.2. Second strategy: Constraints are Validated Against the LastConsistent ResultsAnother possible solution is to evaluate constraints on the last �nal consistentresults. The execution in the �gure 8 illustrates this strategy.t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x) y2 read(y)x1 = x1 + 50 y2 = y2 � 30write(x; x1) (x; 150) (y; 150)x1 = x1 + 20 (x; 150) (y; 120) write(y; y2)end! annulatex1 = x1 � 30end (x; 140) (y; 120)Fig. 8. At its termination t1 evaluates the constraint c1 on the last consistent value of y.� At the end of t1, its constraint c1 is not evaluable because of the interme-diate result of y produced by t2.� t1 can evaluate c1 on the last �nal consistent value of y. In the aboveexecution, the last �nal consistent value of y is (y = 150).� Now the transaction t1 can terminate its execution: the constraint c1 isvalid for (x = 140; y = 150).Note that, in some cases, the constraint may be evaluated to false. In thiscase, the user of the transaction has to continue working until the satisfactionof the constraint.This is a valid solution when at least two versions of each object are kept. Ithas the advantage of avoiding t1 to be bothered by t2 when t1 does not want to14

cooperate with t2. In this case, t1 is actually serialized before t2 as in a classicalcase without cooperation.This strategy has two main disadvantages. On the one hand, it comparesobjects of di�erent generations. In some cases this does not have sense. Forexample, it is not really interesting to compare the speci�cation and a codeof the same module but of two di�erent generations (versions). On the otherhand, it is necessary to store at least the last two values (versions) for eachobject. The current value and the last consistent one. This means that weneed a multi-versions repository (at least two versions) to control the di�erentversions of objects.However, it has a main advantage which is avoiding t1 to be bothered by t2,if it does not want to, i.e. t1 is not obligated to cooperate.4.3. Third Strategy: Waiting for the new �nal resultsIf at the termination of a transaction, its constraints are not evaluable then itstermination operation is aborted and the transaction waits for the terminationof other transactions (Fig. 9).t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x)x1 = x1 � 20 y2 read(y)y2 = y2 � 30(x; 100) (y; 120) write(y; y2)end! wait (x; 100)(y; 120) endend (x; 80)(y; 120)Fig. 9. t1 is waiting for the termination of t2� At the end of t1, the constraint c1 is not evaluable because of the inter-mediate result of y produced by t2. t1 waits for the termination of t2.� After the termination of t2, the constraint c1 becomes evaluable. t1 checksc1 and terminates its execution.This strategy can introduce in some cases a \deadlock" between the transac-tions. Suppose now that the transaction t1 has produced an intermediate resultof x and t2 has also produce an intermediate result of y (Fig. 10).15

t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x) y2 read(y)x1 = x1 � 20 y2 = y2 � 30write(x; x1) (x; 80) (y; 150)(x; 80) (y; 120) write(y; y2)end! wait end! waitFig. 10. t1 waits for t2 and t2 waits for t1.In this execution, t1 must wait for the termination of t2 and in the sametime t2 must wait also for the termination of t1. In this situation, there is adeadlock between t1 and t2.In fact, reaching a deadlock between transactions means that each transac-tion needs the other one. A very rough solution in this case is to apply the �rststrategy to remove the deadlock. A better solution to this problem is to invitethe transactions to cooperateain order to terminate their execution simultane-ously.If we apply this strategy to the previous example, the two transactions t1,t2 can cooperate by reading their intermediate results reciprocally (Fig. 11).� t1 reads the intermediate result of y produced by t2 and starts a cooper-ation with t2.� Then t2 reads the intermediate result of x produced by t1 and starts acooperation with t2.� t1 has read an intermediate result of t2 and t2 has read an intermediateresult of t1. These two transactions are grouped by the syntactical protocolof COO (cf. section 2.3). t1 and t2 form a group of cooperative transactionsand must terminate their execution at the same time. The termination ofa group of cooperative is inspired from two phases commit protocol [8] aswe shall see below.Constraints and Cooperative Transaction GroupsIn the case of a cyclic dependency between cooperative transactions, the trans-actions are grouped by the syntactical protocol and form a group of cooperativeaOf course, starting a cooperation with other users is under the individual responsibility ofeach user. The environment does not obligate users to cooperate.16

t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x) y2 read(y)x1 = x1 � 20 y2 = y2 � 30write(x; x1) (x; 80) (y; 150)(x; 150) (y; 80) write(y; y2)y1 read(y) x2 read(x)Fig. 11. t1 and t2 cooperate to make the constraint c1 evaluable.transactions [17]. A cyclic dependency appears between two transactions whenthe �rst one reads an intermediate result of the second and reciprocally. Trans-actions in the same group terminate their execution together in an indivisibleway (all the transactions terminate or none) and produce only one state of therepository.With respect to the constraints, a group of cooperative transactions can beseen as a unique transaction. This transaction terminates its execution whenthe last transaction in the group terminates. The constraints of the group arethe union of the constraints of the transactions composing the group. Thus, thetermination of the last transaction of the group is the same as a terminationof an ordinary transaction: at its termination, the transaction must produce a\consistent state" of the repository. In this state, all the constraints must beevaluable and valid.Consider again the execution of the �gure 11. In this execution, the trans-action t1 and t2 can terminate their execution as depicted in the �gure 12.(Remember that the transaction t1 cooperate with t2 in order to make the con-straint c1 evaluable).The execution of the �gure 12 is interpreted as follows:� t1 reads an intermediate result of y produced by t2. t1 becomes dependantof t2 on the object y: t1 y! t2.� In the same way, t2 reads an intermediate result of x produced by t1. t2becomes dependant of t1 on the object x: t2 x! t1. The transactions t1and t2 form a group of cooperative transactions.� The transaction t1 starts the termination of the group by trying to termi-nate. It produces a set of \potentially" �nal results and becomes \readyto terminate". 17

t1 repositoryc1(x; y) : always (x < y) t2begin(t1) (x; 100)(y; 150) begin(t2)x1 read(x) y2 read(y)x1 = x1 � 20 y2 = y2 � 30write(x; x1) (x; 80) (y; 150)(x; 80) (y; 120) write(y; y2)y1 read(y)x1 = x1 + 10 x2 read(x)end : ready to terminate (x; 90) (y; 120) x2 read(x)end end(x; 90)(y; 120)Fig. 12. t1 and t2 terminate their execution at the same time� The transaction t2 tries to terminate its execution, its termination oper-ation is rejected since t2 has not read the \potentially" �nal result of xproduced by t1. t2 continues its execution. It reads the value of x andaccepts to terminate with this value. At the termination of t2 (the lasttransaction of the group), the constraint c1 of t1 and t2 is evaluable andvalid. Thus, t2 can terminate its execution. The termination operation oft2 terminates the execution of t1 and t2 simultaneously.The above example shows how the cooperation allows the transactions t1and t2 to satisfy their constraints.4.4. SummaryIn summary, in the case of cooperative activities, the monitoring algorithmcan be de�ned as:if the constraint is not evaluable thenapply the second or the third evaluation strategyelse if the constraint is not veri�ed thencontinue workingelseproduce a new state (Commit)endifendifThe second strategy evaluates the constraints on the last �nal results of the18

objects while the third strategy delays the transaction termination and invitesit to cooperate with other transactions.To check the validity of the constraints, we have adapted the approach de-veloped in [18, 12] as detailed in [14, 19]. If a constraint is not valid, it is theresponsibility of the user to continue working until the satisfaction of the con-straint. Notice that in some situations although the user continues working, heis unable to validate the constraints. To solve this problem, we propose in [20]two forward recovery technics but this is out of the scope of this paper.5. ImplementationThe syntactical protocol and the constraints monitoring algorithm described inthis paper have been implemented in the COO software engineering environ-ment. COO is organized in services [21]. The Transactional Service implementsthe syntactical protocol. The Constraints Service implements the constraintsmonitoring algorithm. The constraints are represented by formulae of temporallogic. As we said, we have adapted the approach developed in [18, 12] to checkthe validation of the constraints as described in [14].The implementation of the algorithm has been done in the case of a atorganization of the activities (all the activities are at the same level and theyshared the same database) and in the case of a hierarchical organization (modelof nested transactions) [19, 20].6. ConclusionIn this paper, we have shown from a theoretical point of view that it is pos-sible in a software development environment to reconcile the need of freedomof developers and the control mania of managers. The hybrid approach of Cooprovides a framework which allows people to exchange informations informally(intermediate results), provided that they synchronize at some point in orderto get back to some consistent state from the concurrency and process pointof views (�nal result). Thus we allow users to break isolation and consistencyproviding that at some time, they pay the price and do some work to reestab-lish isolation and consistency. We expect that this approach is viable in designenvironments as it is the case in software development.We have also pointed out the synergy which exists between synchronizationand constraints checking. Sometimes, constraints checking triggers some infor-mation exchange between activities that will avoid subsequent process iteration;sometimes, cooperation is used to allow to validate constraints that could not bevalidated by an activity alone. The feasibility of the approach has been provedby a prototype implementation that integrates the Coo-protocol and constraintschecking.Today, we are designing a new version of the prototype that will be easierto deploy in order to conduct middle scale experimentation of the approach in19

software development and in other domains[22]. This will help us to assess theapproach and to identify more precisely actual user needs.References1. A.K. Elmagarmid, editor. Database transaction models for advanced applica-tions. Morgan Kau�man, 1992.2. G. Junkerman, B. Peushel, W. Sch�afer, and S. Wolf. MERLIN : Supporting Co-operation in Software Development Through a Knowledge Based Environment. InJ. Kramer A. Finkelstein and B. Nuseibeh, editors, Software Process Modellingand Technology. Research Study Press, 1994.3. N. Belkhatir and J. Estublier. ADELE{TEMPO : An Environment to Support Pro-cess Modelling and Enaction. In J. Kramer A. Finkelstein and B. Nuseibeh, editors,Software Process Modelling and Technology. Research Study Press, 1994.4. N. Barghouti. Supporting Cooperation in the MARVEL Process-Centered SDE.Proceedings of the Fifth ACM SIGSOFT Symposium on Software Develop-ment Environments, 17(5):21{31, December 1992.5. A. Clarke. A Theoretical Model of Cooperation. In Proc. 2nd InternationalConference on the Design of Cooperative Systems (COOP'96), Juan-les-Pins,France, june 1996.6. K. Ramamritham and P.K. Chrysanthis. A taxonomy of correctness criteria indatabase applications. The VLDB Journal, 5:85{97, 1996. voir ramamritham93.7. P. Molli. COO-Transaction: Enhancing Long Transaction Model with Coopera-tion. In 7th Software Con�guration Management Workshop (SCM7), LNCS,Boston, USA, May 1997.8. J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques.Morgan Kaufmann, 1993.9. A.K. Elmagarmid, Y. Leu, J.G. Mullen, and O. Bukhres. Introduction to AdvancedTransaction Models. In A.K. Elmagarmid, editor, Database transaction modelsfor advanced applications. Morgan Kau�man, 1992.10. S. Dart. Spectrum of functionality in con�guration management systems. Techni-cal Report CMU/SEI-90-TR-11, Software Engineering Institute, Carnegie MellonUniversity, Pittsburgh, Pennsylvania 15213, December 1990.11. U. W. Lipeck. Stepwise Speci�cation of Dynamic Database Behaviour. In ACMSIGMOD, pages 387{397, 1986.12. U. W. Lipeck and M. Gertz. Transitional Mointoring of Dynamic Integrity Con-starints. Bulletin of the Technical Committee on Data Engineering, IEEEComputer Society, 17(1):38{42, June 1994.13. E. Allen Emerson. Temporal and Modal Logic, chapter 16, pages 977{1069. Hand-book of the Computer Science. Elsevier Sciences B.V., 1990.14. H. Skaf, F. Charoy, and C. Godart. Maintaining Consistency of Cooperative Soft-ware Development Activities. In 6th International Workshop on Foundations ofModels and Languages for Data and Objects, pages 103{118, Schloss Dagstuhl,Germany, september 1996.15. P.W. Grefen and P.M. Apers. Integrity Control in Relational Database Systems {An Overview. Data and Knowledge Engineering, 10(2), pages 187{223, 1993.16. C. Godart. COO: a Transaction Model to support COOperating software developersCOOrdination. In 4th European Software Engineering Conference (ESEC4),Garmisch, LNCS 717, 1993.17. G. Canals, P. Molli, and C. Godart. Concurrency control for cooperating software20

processes. In Proceedings of the 1996 Workshop on Advanced TransactionModels and Architecture (ATMA'96), Goa, India, 1996.18. U. W. Lipeck. Transformation of Dynamic Integrity Constraints into TransactionSpeci�cations. In North-Holland, editor, Theoretical Computer Science, pages115{142, 1990.19. H. Skaf, F. Charoy, and C. Godart. A Hybrid Approach to Maintain Consistencyof Cooperative Software Development Activities. In The Ninth InternationalConference on Software Engineering and Knowledge Engineering, SEKE'97,Madrid, 1997.20. Hala Skaf. Une approche hybride pour g�erer la coh�erence dans les environ-nements de d�eveloppement coop�eratif. Th�ese en informatique, Universit�e deNancy I { Centre de Recherche en Informatique de Nancy, 1997.21. C. Godart, G. Canals, F. Charoy, P. Molli, and H. Skaf. Designing and Implement-ing COO: Design Process, Architectural Style, Lessons Learned. In InternationalConference on Software Engineering (ICSE18), 1996. IEEE Press.22. K. Benali, M. Munier, and C. Godart. Cooperation models in co-design. In Con-current Engineering Symposium, SAE, Detroit, february 1998.

21