Active Rules for the Software Engineering platform ... - CiteSeerX

Active Rules for the Software Engineering platform GOODSTEP 1 C. Collet, P. Habraken, T. Coupaye and M. Adiba LGI-IMAG, University of Grenoble BP 53, 38041 Grenoble cedex 9, France e-mail: [email protected]

GOODSTEP ESPRIT-III project No. 6115 GOODSTEP Technical Report No. 10 December, 1993

Abstract

In the framework of GOODSTEP, rules have been introduced as a means to support the implementation of next generation of Software Development Environments (SDE), mainly for: (i) notifying users, i.e., programmers of SDE or end-users, (ii) application access logging, (iii) organizing related application programs, (iv) tools communication[22], (v) change propagation, and (vi) maintaining data consistency. Such rules are comprised of three parts : an Event(E) part, a Condition(C) part and an Action(A) part. The general semantics of an ECA rule is the following: \Whenever the event E occurs, if the Condition C holds, then execute Action A". This paper rst presents the decisions we made for integrating rules in the object-oriented database system O2 , the basis of the GOODSTEP platform. Then we concentrate on the Event part de nition of a rule and nally we discuss the rule execution model.

This report has been accepted to the 2nd International Workshop on Database and Software Engineering - 16th International conference on Software Engineering, Sorrento - Italy, May 1994. 1

1 Introduction The research presented in this paper has been done in the framework of the GOODSTEP project for developing an object-oriented database system dedicated to support Software Development Environments(SDE)1 . This database system is the basis for a platform for SDE construction with dierents tools. Rather than developing a new system, GOODSTEP will enhance and improve the O2 system [3]. The aim of SDE is to help users through the software engineering process. Many studies have concluded that better control over the processes involved in development and maintenance is necessary to obtain better products. Software engineering data are typically strongly inter related thus implying sophisticated and safe update propagation mechanisms. Also, data updates may correspond to dierent levels of granularity: changing an attribute value, editing a procedure, compiling a module, etc. Therefore, in SDE it is necessary to manage links between entities and to support in a uniform way automatic change propagation. Basic operations such as a data update can be propagated in a simple way. High-level operations (i.e., tools invocation) also have to be propagated and controlled. This is a way to introduce some degree of discipline into the process. For example, the system may support policies such as the one concerning change of a source code module: \whenever a source code module change is validated (1) call the compiler with the module as parameter and (2) call the linker with the object code of the module as a parameter as well as other object codes associated with this module." Such a policy contributes to controlling, monitoring and assisting teams in performing their activities. In order to support such policies, dierent approaches have been proposed based on AI techniques, process programming [26, 27] and rules [4, 5, 16, 20, 7]. In the framework of GOODSTEP, rules have been introduced as a means to support the implementation of next generation of SDE, mainly for: (i) notifying users, i.e., programmers of SDE or end-users, (ii) application access logging, (iii) organizing related application programs, (iv) tools communication[22], (v) change propagation, and (vi) maintaining data consistency. Rules introduced in O2 are not AI rules. They match production rules and are comprised of three parts : an Event(E) part, a Condition(C) part and an Action(A) part. The general semantics of an ECA rule is the following: \Whenever the event E occurs, if the Condition C holds, then execute Action A". From this simple ECA paradigm, dierent kinds of active rules and therefore dierent kinds of active systems have already been proposed. The features of these systems depend upon whether the rules are de ned for a general purpose DBMS or for speci c applications [2]. The approach proposed here is based on propositions done in the framework of the most representative object-oriented projects: ODE [12, 13], O2 [19], SAMOS [11] and HiPAC [9, 15, 18]. We also considered works done on the execution model of rule systems in [14, 10, 8, 17, 23, 24, 6]. The main contributions of our work are as follows:  Rules belong to a schema and thus can be used as any other component of a schema. Rules respect encapsulation and transparency: only authorized operations on objects which may or may not be persistent can produce valid events. Rules can be exported/imported, increasing reusability.  Primitive event types related to (i) operations on objects or values , and (ii) code execution have been identi ed and classi ed. Event types are subject to inheritance: operations on objects can produce events which types are related to super-classes of the objects.  Execution of rules is based on execution cycles which are related to delta structures. Imme1

This work is partly funded by the CEC under contract No 6115 (Esprit-III project GOODSTEP)

1

diate rules have an instance oriented semantics. Deferred rules have a set oriented semantics. When executed, an immediate or a deferred rule builds a delta element or a delta collection, for storing information associated to their triggering event, respectively. Operators are provided to manipulate delta structures and to allow their use in condition and action parts of a rule. This paper is organized as follows. Section 2 presents the decisions we made for integrating rules in the O2 system. Section 3 concentrates on the Event part de nition and Section 4 discusses our rule execution model.

2 Active rules in O2 O2 Rules are de ned as schema elements, at the same level as class or application de nitions.

The execution of a rule takes place within an application and interacts with one or more databases. Rules are permitted to operate on objects and values 2 . We do not allow rules to be properties of a class because this implies the notion of external and internal rules as in [11] which can be confusing from the programmer's point of view.

Rules respect encapsulation. This means that only authorized operations on objects or values can produce valid events. Such operations are public methods, programs or updates on values. By default values are public. When compiling rule de nitions, rules are classi ed by their relationship to classes. Rules associated with only one class are subject to inheritance. Event type, say E, of a rule r associated with a class C is propagated across the class hierarchy (the sub-classes of C). The condition and action parts of r are inherited but they cannot be explicitly rede ned. However, a new rule with E as event type can be de ned for a sub-class of C. An internal representation of rules as named objects allows the use of the O2 export/import mechanism for rules reusability. A rule is imported in the same way a named object is imported but it is important that the class and object or value de nition associated with the rule is imported as well, otherwise the rule cannot operate.

2.1 Rule de nition The overall structure of rule de nition is as follows: create rule [precedes ] [coupling ] on [with ] [if ] do

- Rule identi er: Each rule has a unique identi er. - Rule list: As one event may trigger several rules there is a need for ordering between the rules of a schema. The default total ordering is based on the order in which rules were

2

We assumed the reader familiar with the O2 concepts. Further details about O2 can be found in [1, 3].

2

de ned. The rule programmer can override this default order by specifying relative priorities between rules using a precedence relationship. If the programmer speci es that rule r1 precedes rule r2 , and if both r1 and r2 are triggered, then rule r1 is executed rst even in the case that r1 is de ned after r2. As in [21], priorities between rules allows to de ne a total ordering for rule processing. This order endows the rule system with deterministic behavior. - Coupling modes: It is natural to view a triggered rule as a sub-transaction of the triggering transaction. In the coupled execution mode, triggered transactions are sub-transactions of triggering transactions. By contrast, when the execution of a triggered transaction is carried out as a top-level transaction in comparison with the triggering transaction, the execution mode is decoupled. Furthermore, a decoupled triggered transaction can be said to be commitdependent or commit-independent of the triggering transaction. Based on the current at transaction model of the O2 system, it is impossible to have decoupled sub-transactions. Therefore, to separate condition evaluation from event detection and, moreover, action execution from condition evaluation, we consider coupled sub-transactions which in fact are parts of the triggering transaction. Table of Figure 1 shows the meaningful combinations of coupling modes provided. Depending on these coupling modes, the execution of rules is dierent; Section 4 details this aspect. The combination (Combination I) means that a condition is evaluated right after event detection and, if it holds, action is immediately scheduled for execution. This (default) combination characterizes immediate rules which respond to operations on a single entity. The combination (Combination II) means that a Condition evaluation and Action execution take place after the last operation of the triggering transaction, but before it validates or commits. This combination characterizes deferred rules which respond to aggregate and cumulative changes to an entity. Deferred rules are set-oriented. Condition-Action Event-Condition immediate deferred

immediate deferred I II

-

Table 1: Combinations of coupling modes

- Event type: describes situations (events) that can be recognized by the O2 system. Our

approach was rst to identify primitive event types related to object and value manipulation. In order to describe simultaneously objects and values, the entity concept is used. The value of an entity corresponds to the content of an O2 value or to the value of an O2 object. Rules respect encapsulation. This means that only authorized operations on objects or values can produce valid events. Such operations are public methods, programs or updates on values. Section 3 details the types of primitive events concerning entity manipulation. This paper does not concern composite event and temporal events. - Condition: The condition is a formula composed of predicates on objects and values. A predicate is an O2 SQL query. A predicate is true when the corresponding query's result is true or is not empty. A predicate may refer delta structures, i.e., delta elements or delta collections These concepts are described below. The result of a query is visible to the action part of the rule. 3

- Action: The action can be any executable O2C code; it may abort the current transaction in

which the corresponding event occurred. The most simple form of an Action is a method applied to the object concerned by the corresponding event. This object is generally referred to as a delta element (see below). - Delta structure name: Rule execution is based on the notion of execution cycles. A cycle describes the execution of a sequence of operations. These operations belong to a program, a user-de ned transaction or a rule. Every execution cycle is associated with an event history used to build the execution environment of each rule considered in the cycle. Such an environment is represented by a delta structure containing data related to the triggering operation and the result of the condition evaluation. There are two kind of delta structures: delta elements and delta collections which are associated with immediate and deferred rules respectively. When de ning a rule, the programmer can name it's associated delta structure and use it in the condition and action parts. delta structures are built as in [28] considering the net eect of a sequence of operations performed in the triggering transaction and the previous execution cycles. Section 4.1 discusses the notion of execution cycles and their associated delta structures.

2.2 Programming with rules Programming with rules means that the system oers speci c operations for manipulating rules and provides some guidelines for the design and management of rules with respect to an application design.  By means of the create, delete, modify, display, rename commands, rules can be manipulated as well as other elements of an O2 schema. A rule de nition can refer all the other de nitions of the schema to which it belongs.  In O2 persistency is transparent as far as the applications programmer is concerned. This persistency transparency principle is respected when programming rules; events can be produced by operations on entities which may or may not be persistent.  When an application of a schema is executed, the rules belonging to this schema are enabled. However, all these rules may not be relevant to the application execution. The enable and disable operations allow a rule to be activated or deactivated, respectively. In order to stay in the O2 object-oriented programming world, the syntax used for specifying such operations is similar to those used for applying a method to an object. Deactivation or reactivation messages can only be sent to rules in an action part.  The introduction of rules constitutes a programming paradigm which allows applications to be structured. They should be considered at a higher level than programs, methods and data manipulation. Program executions can be dependent on rules. Rules are isolated from programs and methods. A rule can be manipulated only through rules, e.g., the deactivation of rules cannot be done directly in the body of a program but only in the action part of a rule. Therefore, the programmer can better separate what has to be coded in methods and programs from what needs to be speci ed in rules.

3 Event types Only primitive events which are produced when manipulating entities or when executing programs or transactions of an application are considered. These events are detected by the 4

O2 engine. They occur when objects are created(new), values are modi ed, entities become

persistent, messages are send to objects, transactions start, commit, validate or abort, and also when programs start or nish.

3.1 Entity manipulation event types 3.1.1 De nition An entity manipulation event type is comprised of:

- An operation type. The following operation types are proposed: 1. CREATE which characterizes an entity creation; 2. DESTROY which characterizes an entity deletion; 3. RETRIEVE, INSERT, DELETE et UPDATE which characterize the manipulation (access and modi cation) of entity components, i.e. the value of an object , the content of an O2 value, an atomic or complex sub-value; 4. ATTACH et DETACH which characterizes the persistence change for an entity; 5. METHOD BEGIN et METHOD END which are related to the execution of a method at an object; - An entity type. This is the entity type concerned by the operation which generates an event of this type. This type is given by the name of of a class, a type, an object or a value (a persistency root). - A path in the tree which represents the entity type. This path allows to determine the type of the component value concerned with the operation. This path is only speci ed when dealing with an event type which characterizes an entity component value manipulation. - A moment of generation. The moment at which an instance is generated. The generation of an event is linked to the execution of an operation or a method. As already stated an event can be generated either before or after an operation is executed. The de nition of an event type indicates a moment of generation which is either BEFORE or AFTER and which can be associated with the operation type. Depending on the operation under consideration, a BEFORE or AFTER event generated by this operation is not necessarily signi cant and of use. Also it is not obligatory to specify the moment of generation in an event type. Table 2 shows the default generation moments for each event type. Meaningless events are not available. Note that using BEFORE allows to express as in [25] an action which has to be performed instead of the operation which caused the rule to execute. The Action block of the rule is preceded of the instead key-word.

3.2 Application event types Applicative event types describe events associated to execution of O2 applications. They characterize the events generated by the beginning and end of application, program or transaction 5

Event type

CREATE DESTROY RETRIEVE UPDATE INSERT DELETE ATTACH DETACH METHOD BEGIN METHOD END

BEFORE    not available

 

not available

AFTER  

not available

   

not available not available



Table 2: Default generation moments of event types execution respectively. This section does not cover user event produced explicitly by applications. Types of these events are de ned independently of a rule de nition. They characterize situations not necessarily associated with an entity manipulation operation, a program execution, etc. Kind of events involved in an O2 application follows:  Transaction events which are de ned by the start or the termination of a (user de ned) database transaction; TRANSACTION BEGIN, TRANSACTION VALIDATE, TRANSACTION COMMIT and TRANSACTION ABORT event types describe transaction events.  Program events which are de ned by the start or the termination of a (user de ned) program; PROGRAM BEGIN and PROGRAM END event types describe program events.  Application events which are de ned by the start or the termination of an application; APPLICATION BEGIN and APPLICATION END describe application events. Rules de ned with the above event types are immediate rules. For example, a rule with the event type \TRANSACTION BEGIN prog" will be executed at the beginning of the prog transaction. If the condition of the rule holds, the action part is immediately scheduled for execution.

4 Rule execution Our rule execution model deals with several aspects: (i) Coupling modes, (ii) Execution of several rules arising from the same event, (iii) Cascading execution of rules, and (iv) delta structures for representing rule execution environments. Section 2.1 introduced the combinations of coupling modes for conditions and actions and the precedence relationship for managing multiple rule executions. In the following we concentrate on two aspects of rule execution: Cascading execution of rules and delta structures.

4.1 Cascading execution of rules The execution of a cascade of immediate or deferred rules is based on the concept of execution cycles adapted from [8]. An execution cycle describes the execution of a series of operations which belong to a transaction or to the action part of a rule. Whatever the coupling mode under consideration, the rules triggered are always executed in a new execution cycle distinct from the execution cycle to which the triggering operation belongs. Furthermore, within a given cycle deferred rules are executed in the order corresponding to their respective priorities. 6

Figure 1 shows the execution of rules r1, r2 with event type E1, r11 and r12 with event type E2. These rules are de ned under the following precedence relationships: r1 precedes r2 and r11 precedes r12. ... T e1 cycle 0

e1 1

r1

r2

4 1

r1

r2

2

e2 e2

r11

cycle 1

r12

2

3

3

e3 cycle 2

r11

r12

4 cycle 2

e3

cycle 1 cycle 0

Immediate rules

Deferred rules

Figure 1: Execution cycles

4.1.1 Immediate rules Immediate triggered rules are executed in a \depth rst execution order". This approach is closely related to the one proposed in [28] but rules considered here respond to operations on a single entity. The sequence of operations executed up to the triggering event de nes an initial execution cycle. Then, every subsequent rule execution de nes a new nested execution cycle. On the left-hand side of Figure 1 the rules are considered to be immediate assuming a transaction in which an event e1 of type E1 occurs. The operations of the current transaction executed before e1 de nes the initial execution cycle (cycle 0) and some set of rules can triggered. In our case rules r1 and r2 are triggered. One rule is chosen from this set: r1 precedes r2, so r1 is executed rst and de nes a new execution cycle(cycle 1 in Figure 1). In this cycle, the condition of r1 is checked. If the condition is true then the action part is executed. Otherwise, the other rule r2 is chosen from the set. Let us assume r1 has been executed. Another rule of the set, i.e., r2, is now considered and executed taking into account the composition of the initial execution cycle and the r1 execution cycle(cycle 1). That is, r2 sees the eect of operations executed on the entity in the initial cycle and in the r1 execution cycle. As we can see in Figure 1, r1 produces event e2 of type E2 which in its turn triggers rules r11 and r12 (r11 precedes r12). Both rule executions de ne (sub) execution cycles. The depth rst execution order implies that r2 is executed after r11 and r12 even if r2 precedes r11 and r12. Events produced in an execution cycle are treated without considering rules already triggered but still to be executed. For example, when event e2 occurs, selection of rules concerns r11 and r12 and we consider the precedence relationship between these two rules only. We do not consider the fact that rules r11 and r12 have to be added to the initial set of triggered rules.

4.1.2 Deferred rules Triggered deferred rules are executed after the transaction in which the triggering event occurs and before its commit or validate (the \commit" point of the transaction). Operations of the 7

transaction create an initial execution cycle and then deferred rules are executed in a \width rst execution order", i.e., in consecutive execution cycles. On the right-hand side of Figure 1 the rules are taken to be deferred and r1 and r2 are executed in the same cycle (cycle 1). r11 and r12 are triggered by r1 and are thus executed after r2 in another cycle(cycle 2). r11 and r12 see the eects of the operations executed in the initial cycle (cycle 0) and in the r1 and r2 execution cycles (cycle 1). More generally, deferred rules of a cycle see the eect of operations performed since the beginning of the transaction or the previous execution cycle. When there are no more deferred rules to be considered, the transaction is validated or committed. According to whether the rules are immediate or deferred, the processing of rules in each cycle diers. The semantics of the processing is closely linked to the environment constructed for the rule execution.

4.2 Delta structures 4.2.1 Delta elements The triggering event of an immediate rule corresponds to an operation on an entity. The execution environment of an immediate rule is known as a delta element. It refers (i) the entity which is concerned with the operation producing the event and, (ii) the inserted, deleted or updated data or the actual parameters of a method or a program. Condition and action parts of a rule may refer to the data of a delta element using the four operators: current, old, new, and delta. The current operator is the one assumed if none is speci ed. In that case a delta element identi er, in the condition or action part, denotes the entity before or after modi cation depending of the manipulation event type. The delta constructor is used with INSERT or DELETE event types.

4.2.2 Delta collections A deferred rule responds to cumulative changes to entities. When a deferred rule with event type E is executed, the system considers every event of type E which occurs during the previous execution cycles. These events may concern the same entity or dierent entities. Therefore, the execution environment of a deferred rule re ects the changes that have occurred on a set of entities. These changes are necessarily of the same type. To each entity is associated the modi ed, inserted or deleted data. A delta collection can be seen as a set of delta elements. The operators we introduced in the previous section can be used to refer data of delta collections. In that case, the operators build set of entities.

5 Rule examples Let us consider an Employee class which is a subclass of Person and describes employees of a company. The Task class describes tasks of a project, and The boss is the name of an instance of Employee. 8

class end; class

end; name

Employee inherits Person public type tuple ( pro le: list(string), salary: integer) Task public type tuple( group: set(Employee), manager: Employee, documents: set(Document), name: string)

The Boss: Employee;

The following rules are used to control salaries of employees and the deletion of a task, respectively. create rule Update employee salary coupling (immediate, immediate) on before update Employee- salary with e if new(e)- salary 2 * current(e)- salary do instead f

>

g

>

>

>

notify(The Boss);

create rule Destroy task coupling (deferred, immediate) on destroy Task with t if select task- name

>

into non empty from task in t where task->documents != set()

do f

g

display("Following tasks are still having documents. They cannot be destroyed !"); display(non empty); abort;

The event type of the rst rule: before update Employee->salary characterizes modi cation of the salary attribute of Employee's instance. When rule Update employee salary is triggered, its associated delta element built by the rule system and denoted by e is a tuple composed of an Employee's instance and the new value for its salary attribute. The operators current and old build new values, respectively with type Employee: (i) current(e) is the instance of Employee before modi cation and, (ii) new(e) is the instance of Employee after modi cation. The condition holds if the updated employee has a salary with a value twice its previous value. This condition part could also have been written: new(e)-> salary > 2 * e->salary. If the condition holds, the employee named The Boss is noti ed instead of updating the salary of current(e). Rule Destroy task displays and rollbacks the deletion of any tasks still having documents linked to them. This rule is triggered at the end of a transaction (or a deferred execution 9

cycle) when Task's instances are deleted. The delta collection t denotes the set of deleted Task instances. The into clause allows data to be visible to the action part of the rule.

References [1] M. Adiba and C. Collet. Objets et Bases de Donnees : Le SGBD O2 . Hermes, 1993. [2] M. Adiba, C. Collet, T. Coupaye, P. Habraken, J. Machado, H. Martin, and C. Roncancio. Trigger Systems: Dierent approaches. Rapport de Recherche Aristote-SUR007, LGIIMAG, France, June 1993. [3] F. Bancilhon, C. Delobel, and P. Kanellakis. Building an Object-Oriented Database - The story of O2 . Morgan Kaufmann, 1992. [4] N.S. Barghouti and G.E. Kaiser. Modeling Concurrency in Rule-Based Software Development Environments. In Object-Oriented Programming, IEEE Expert, December 1990. [5] N.S. Barghouti and G.E. Kaiser. Scaling up Rule-Based Software Development Environments. In 3rd European Software Engineering Conf., ESEC'91, Milan - Italy, October 1991. [6] C. Beeri and T. Milo. A Model for Active Object Oriented Database. In Proc. of the 17th International Conference on Very Large Data Bas, pages 337{349, Barcelona, Spain, September 1991. [7] N. Belkhatir, W.L. Melo, J. Estublier, and M. Ahmed-Nacer. Supporting Software Maintenance Evolution Processes in the Adele System. In Proc. of the 30th Annual ACM Southeast Conference, Raleigh - NC, April 1992. [8] A. Dayal, M. Hsu, and R. Ladin. Organizing Long-Running Activities with Triggers and Transactions. In Proc. of the ACM SIGMOD International Conference on Management of Data, pages 204{214, Atlantic City, USA, May 1990. [9] U. Dayal, A. Buchmann, and D. McCarthy. Rules Are Objects Too : A Knowledge Model For An Active, Object-Oriented Database System. In Proc. 2nd Inernational Workshop on Object-Oriented Database Systems, pages 129{143, September 1988. [10] U. Dayal et al. The HIPAC Project: Combining Active Databases and Timing Constra ints. SIGMOD Record, 17(1), March 1988. [11] S. Gatziu, A. Geppert, and K.R. Dittrich. Integrating Active Concepts into an ObjectOriented Database System. In Proc of the 3rd International Workshop on Database Programming Languages: Bulk Types & Persistent Data, pages 399{415, Nafplion, 1991. Morgan Kaufmann. [12] N. Gehani and H.V. Jagadish. Ode as an Active Database: Constraints and Triggers. In Proc. of the 17th International Conference on Very Large Data Bas e, pages 327{36, Barcelona, Spain, September 1991. [13] N. Gehani, H.V. Jagadish, and O. Shmueli. Event Speci cation in an Active ObjectOriented Database. In Proc. of the ACM SIGMOD International Conference on Management of Data, pages 81{90, San Diego, USA, 1992. 10

[14] E. Hanson. An Initial Report on the Design of Ariel A DBMS with an Integrat ed Production Rule System. SIGMOD Record, 18(3):12{19, September 1989. [15] M. Hsu, R. Ladin, and D. McCarthy. An Execution Model for Active Database Management Systems. In Proc. 3rd International Conference on Data and Knowledge Bases, pages 171{179, June 1988. [16] S. Jarwah and M.F Bruandet. Elen Prototype: an Active Hypertext System for Document Management in Software Engineering. In Proc. of the 3th DEXA Conference, Valencia Spain, September 1992. [17] G. M. Lohman, B. Lindsay, and H. Pirahesh and K. B. Schiefer. Extensions to Starburst: objects, types, functions, and rules. Communications of the ACM, 34(10):94{109, October 1991. [18] D. McCarthy and U. Dayal. The Architecture of An Active Data Base Management System. In Proc. of the ACM SIGMOD, pages 215{223, May 1989. [19] C. Bauzer Medeiros and P. Pfeer. A mechanism for managing rules in an Object-Oriented Database. Altair report, 65-91, GIP Altair, 1991. [20] F. Oquendo, JD. Zucker, and G. Tassart. Suppport for software tool integration and process-centered software engineering environments. In Proceedings of the third International workshop on Software Engineering and its Applications, Toulouse, France, December 1990. [21] R. Cochrane R. Agrawal and B. Lindsay. On Maintaining Priorities in a Production Rule System. In Proc. of the 17th International Conference on Very Large Data Bases, pages 479{487, Barcelona, Spain, September 1991. [22] U. Schreier, H. Pirahesh, and R. Agrawal and C. Mohan. An Architecture for Transforming a Passsive DBMS into an Active DBMS. In Proc. of the 17th International Conference on Very Large Data Base, pages 469{478, Barcelona, Spain, September 1991. [23] E. Simon, J. Kiernan, and C. de Maindreville. Supporting Deductive and Active Rules on Top of a Relational DBMS. Rapport de Recherche RR1580, INRIA-ROCQUENCOURT, France, January 1992. [24] M. Stonebraker, A. Jhingran, and J. Goh and S. Potamianos. On rules, procedures, caching and views in data base systems. In Proc. of the ACM SIGMOD, pages 281{290, Atlantic City, USA, May 1990. ACM Press. [25] M. Stonebraker and G. Kemnitz. The Postgres next generation database management system. Communications of the ACM, 34(10):78{93, October 1991. [26] S.M. Sutton, D. Heimbigner, and L.J. Osterweil. Language constructs for managing change in process-centered environments. In Proc. of the 4th Symposium on Software Development Environments, pages 206{217, Irvine CA, December 1990. ACM Press. [27] S. Sarkar V. Venugopal. A language-based approach to building CSCW systems. In Proc. of the 24th Annual Hawaii International Conference on System Sciences, Kona HI, 1991. [28] J. Widom, R.J. Cochrane, and B.G. Lindsay. Implementing set-oriented production rules as an extension to Starburst. In Proc. of the 17th VLDB, pages 275{285, Barcelona - SP, September 1991. 11