Providing Support for Process Model Enaction in the ... - CiteSeerX

Providing Support for Process Model Enaction in the Metaview Metasystem Garry Froehlich Jean-Paul Tremblay

Paul Sorenson

Department of Computational Science University of Saskatchewan Saskatoon, Sask. S7N 0W0 [email protected]

Department of Computing Science University of Alberta Edmonton, AB. T6G 2J9 [email protected]

Abstract

Process modeling is a means of formally de ning many aspects of the software development process through the use of models. Partial automation of a process model can help to improve the software process. Menial or tedious tasks, such as collecting metrics, no longer have to be the responsibility of the developer. Coordination of eort can also be enhanced through automation. Automation can be achieved through the development of a process modeling support environment and the appropriate CASE tools. This is one of the major goals of the Metaview project, which involves the design and development of a metasystem to generate such an environment. A key requirement for this type of support environment is to use an active database. Active databases can react through an action to events, such as changes to a particular data item, thereby giving them the exibility needed for process modeling. This paper presents an execution model for the support of process model enaction in the Metaview system. The execution model is intended to support a wide variety of process models and process modeling languages. The model is based upon the event-rule model used in active databases.

1 Introduction

Process modeling is used by software (process) engineers to improve the manner in which software is produced. It formally models the software development process, making it explicit and open to examination. The software development process, also called the software process, includes every aspect of the production and maintenance of software and generally consists of activities, products and resources [4]. Software process models for large software systems can be very complex due to the amount of detail involved in any software process. Automation is key to dealing with this complexity. A combination of both human and machine enacted activities within a process can help the software process run more eciently. In addition, the machine can handle tasks such as automatically collecting measurement data on the pro-

cess and ensuring that all prerequisites of an activity within the process are performed before that activity can proceed. The human developers are then freed to perform the creative tasks involved in actually designing a software system. The main goal of this paper is to present an execution model for the Metaview system that supports the enaction of process models. A major challenge in this work is to propose a model that is general and semantically rich enough to support a wide-variety of process environments that we wish to model in Metaview. Our main goal is achieved through the completion of several subgoals. First, several process modeling languages are examined and their common components are described in Section 2. The event-rule model of active databases is then described in general and in the context of one particular active database in Section 3. A modi ed version of the event-rule model is proposed in Section 4 as the execution model in which to enact process models in Metaview. Also in this section, an overview of the language concepts needed to represent the execution model is presented. Section 5, via an example, gives an indication of how the language can be used to link process modeling languages de ned in Metaview to the execution model. The rest of this introductory section provides some background to the Metaview system, which is important in order to understand the context of this research activity. Ideally, the automation of process models takes place in an integrated CASE (Computer Aided Software Engineering) environment [15]. Such an environment provides a single interface to the user, and automatically connects all of the tools while providing the data to the tools in the proper format. There are many components needed to enact a process model, including a database, a process interpreter, a user interface and a tool set. With the addition of an eective and ecient process interpreter, Metaview [17] is a metasystem that is capable of producing integrated CASE environments. Metaview is not committed to a single speci cation or process model, as most CASE systems are, but instead is able to accommodate a wide variety

of both speci cation methods and process modeling languages. The current Metaview prototype contains three languages that are used to model speci cation methods (such as Data ow Diagrams [8] or ObjectOriented methods such as OMT [19]), a database, and a generic tool set facility. The basic data model used by Metaview is an augmented version of the EntityRelationship model [3] called the EARA (Entity, Aggregate, Relationship and Attribute) model [14, 16]. A speci cation method and a process model, represented in the Metaview languages EDL, ECL and ETL, are compiled to the database. The database is combined with a particular set of tools to comprise a Metaview environment. These three languages cover separate aspects of an environment de nition as follows:  



EDL: the Environment De nition Language describes the static structure of the model. ECL: the Environment Constraint Language describes any constraints that are a part of the speci cation method. ETL: the Environment Transformation Language provides the dynamics needed for execution support such as transformations between environments, metrics calculation in an environment or process modeling support.

Using these three languages, it is possible to describe a wide variety of speci cation methods. Speci cation methods that have already been modeled include Data ow Diagrams, and Higher Order Software (HOS) diagrams [9]. Process modeling languages can also be modeled with these languages as in [2].

2 Process Modeling 2.1 Description

A software process consists of activities, products and resources. Activities are actions performed in a software process and can be anything from high-level design to the compilation of a program. Performance of an activity is called enaction or execution of the process model. Products are the documents and programs produced during the software process. Resources consist of things such as people, time, money and equipment which are used during a software development process. A process modeling language is used to represent a software development process and the resulting representation is called a process model. Conventional programming languages are often inappropriate for process modeling, as they lack features to accommodate the special requirements of process modeling. Many new languages have appeared that attempt to ll the need for special process modeling languages. These can be categorized into four broad classes of enactable process modeling languages: process programming such as APPL/A [18], rule-based such as Marvel [11], functional such as HFSP [12] and Petri-net based such as DesignNet [13]. However, most languages do not t neatly into a single category; there is signi cant overlap between the basic types.

2.2 Requirements for process modeling support

Process modeling has several requirements that any execution model must address. The following requirements are based on the survey of process modeling languages conducted in [7] and in [4].  Control ow: the sequence of activities in the process must be represented and enforced.  Iteration: certain sequences of activities may need to be repeated.  Concurrency: multiple concurrent activities need to be handled.  Human interaction: people must be able to interact with the computer automated sections.  Data Storage: persistent and reliable storage of all of the data involved in the process.  Measurements: automatic collection of metrics from the data.  Temporal support: support of time constraints.  Dynamic adaptation: change of the process itself on the y as development requirements change.  Tool execution: support for interaction with various types of tools.  Resource allocation: what resources are needed for a certain activity. Each of these requirements must be met by the execution model that will enact process models. Most importantly, the execution model must be able to smoothly interact with both human users and outside tools. Further, the execution language must be exible enough to support changes to the process model as it is being enacted.

3 Active Databases

Active databases can provide the basis of the execution model of a CASE environment tailored to process modeling. The event-rule model [10], also called the active model, used in active databases is both exible and dynamic, both key issues when trying to enact many dierent types of process models. Active databases are essentially passive databases augmented with rules. Rules react to events in the database or in the environment and perform some actions in response to the event. These actions can be anything from altering a value in the database to invoking an outside tool. An event is an actual occurrence in the system, typically involving the update of the database or the beginning of a transaction. An event de nition is the template for an event. It generally consists of the event name and any parameters that are bound to the event. A parameter might be the value that is being updated during an update event. An event detector is used to detect the occurrence of an event and

signal that occurrence to a rule manager for further processing. Rules consist of three parts: an event, a condition and an action. The rst part of a rule is an event that triggers a rule. Once the event occurs, the rule is triggered, or is said to re. The second part of a rule consists of a condition that must be satis ed before the rule executes its action. The condition consists of a sequence of predicates (database queries). These predicates often nd additional data values that the rule will act upon. If the condition fails, then the rule aborts, otherwise the rule's action is executed. The action, the third part of the rule, can be almost anything. An action might be the modi cation of the database or the invocation of an outside tool. Active databases such as HiPAC [5], use a nested transaction system to handle rule execution. There are two levels of transactions, top-level and nested transactions. In the proposed execution model, each rule is considered to be a transaction. Nested transactions are also called subtransactions. A top-level transaction is an original transaction and forms the basis for atomic transactions. They are atomic, serializable and permanent. A subtransaction is contained within another transaction, its parent, either a toplevel transaction or another subtransaction. A parent transaction is suspended while its subtransactions execute. Subtransactions can be aborted within a root transaction without aborting the root transaction. If the root transaction should be aborted then an abort-top command can be issued in the subtransaction. If a transaction does abort, then all updates done by its subtransactions are rolled back. The subtransactions are considered to be part of the atomic top-level transaction. The transaction system allows constraints to be expressed as rules and executed in the same atomic transaction as rules which modify the database. It also allows automated chains of rules to be executed in the same atomic transaction. The types of connections between transactions are termed coupling modes. Coupling modes form the basis for linking multiple transactions into single atomic transactions. The immediate coupling mode causes a subtransaction to be executed immediately. The deferred coupling mode delays the execution of the subtransaction until the parent transaction is ready to commit. Both the immediate and deferred coupling modes add the transaction to the current atomic transaction. The decoupled coupling mode creates a new atomic transaction in which to execute the subtransaction. The rules in active databases are the major factor that makes active databases suitable to support process modeling. The rules can be used to encode the process model itself within the database. Any tools the process model requires can be provided outside the database and can be invoked through the rules. Transaction support, failure recovery and of course data storage are also required to support the enaction of process models.

4 Process Modeling Support

Process model enaction is supported in Metaview through an intermediate level language and an execution model. The execution model is based upon the event-rule mechanism just described and, in particular, adopts both the ECA rule structure and nested transaction model from HiPAC [5]. However, HiPAC does not contain the notion of a cluster or of a procedure. Procedures are dierent from rules in that they can be called directly by a rule and they can return data. Clusters allow for modularization of the process model by grouping related rules and events together and insulating them from other groups of rules and events. The number of rules devoted to a single process model can be signi cant, and this clustering helps to reduce unwanted rule interactions. Explicit failure coupling has also been introduced in which rules specify whether or not their failure aects the execution of their parent transactions. The language that supports the concepts of the execution model is called ecode (an abbreviated form of execution code). Ecode is not meant to be a language for developing process models. It lacks many highlevel features that would make it easy to write and understand process models, such as exist in DesignNet [13]. It is instead meant to be able to represent and execute process models, much as assembly code can represent and execute higher-level languages. It is an intermediate form to which other process modeling languages can be translated and then executed. For some languages, such as DesignNet [13], it is relatively easy to de ne their rules of execution in ETL which is then translated into ecode. It is also possible for more detailed languages, such as Marvel [11], to translate their rules of execution directly into ecode. In our example in this paper, we chose to illustrate this direct form of translation in order to exhibit many of the features of ecode.

4.1 Execution model

The execution model is split into three main parts: the tools, the database and the execution engine. The tools perform much of the work within the process. Tools can consist of anything from a compiler to an editor to a structured design tool. The database handles the storage of all information needed within the development environment. The execution engine coordinates the other parts, and embodies the process model being used. The focus of the execution model in this work is the execution engine itself. A standardized interface is provided through which the tool and database components can interact. Users of the completed software system do not directly interact with the process model being enacted by the execution engine. This interaction occurs through tools. Tools provide the front end from which users can manipulate the database and interact with the process model. Figure 1 shows how a process centered environment might be used. A user interacts with an interface tool. The interface tool presents the user with a set of activities based on the user's role within the process. This information is taken from the database. The user can select activities, caus-

User

Interface Tool

Execution Engine

Other Tools

Database

Figure 1: Execution Environment. ing the interface tool to send an event noti cation to the execution engine to start the activity. The execution engine invokes the tool related to the activity and the user performs the desired activity. The tool can interact with the database to retrieve any information needed in the activity and to store information. The database generates events based on the actions requested of it. These events can trigger constraints and consistency checks within the execution engine. When the use of the tool is complete, the execution engine places the results of the activity in the database and performs any additional automated activities possible. Control is then passed back to the interface tool to continue the session.

4.2 Ecode

The major constructs within ecode are events, rules, clusters, procedures, tool interfaces and database operations. There are two types of events: primitive and composite. Primitive events represent single events and are either prede ned in the system, as is the case with temporal events, or are de ned through an event de nition. Composite events combine two or more single events into a more complex event pattern. Composite events also contain preconditions that operate upon the parameters of the events within the event pattern. A rule consists of an event that triggers the rule, a set of preconditions, called the condition, and a sequence of action statements. The preconditions both collect additional data needed in the rule from the database and ensure that the correct conditions exist for the rule to execute. The action statements perform the work of the rule, such as manipulating data in the database or invoking tools. Clusters are collections of related rules, events, procedures and other clusters. They form an aggregation hierarchy to aid in the construction of large process programs. Procedures are rules that are not triggered by events, but respond to direct procedure calls. They consist of input and output parameters, preconditions and action statements. The tool interface and database operations provide links to outside tools and to the database. Each tool has an interface statement de ned for it. The tool interface statement de nes the input and output parameters of the tool and the location of the tool or its envelope so that it can be executed. Database op-

erations similarly provide both input and output parameters for a wide variety of database manipulation statements such as reading, writing, creation and deletion.

4.3 Justi cation

The execution model presented here is appropriate for process model enaction. Control ow is accommodated by linking rules together through events and coupling modes. Control ow includes enforcing a sequence of activities and the preconditions of those activities. Sequences of activities are enforced through the requirement of speci c events to trigger a rule. Preconditions are supported through the condition section of a rule. These conditions are enforced; if the rule's condition is not satis ed the rule's action cannot occur. Iteration is accomplished simply by triggering the event that starts the sequence. Rules can be executed many times, and so sequences of rules can be executed many times. Persistent storage and recovery of data are mostly the concern of the database system. Temporal support is provided through temporal events. Execution of support tools is built into the active database model as well. Active databases were designed to work with outside tools. A simple tool invocation statement is used to execute tools from the execution engine. A tool execution is treated as a transaction and the execution of tools is smoothly integrated into the execution model. Roles and available resources can be modeled through EDL. Preconditions allow for activities to potentially be blocked if their required resources are not available. Concurrency is not explicitly dealt with yet. Locking is done in active databases, but this may be inappropriate for software engineering purposes. A more cooperative model may be needed such as the one found in Marvel [1]. However, as stated earlier, the proposed execution model does not currently deal with concurrency issues. The event-rule model is exible. This exibility means that things such as the automatic collection of metrics can be triggered by events without having to call the collection routines directly from the main activities of the process in a procedural manner. Flexibility is also a key in supporting one of the most important requirements of process modeling: dynamic adaptation. The event-rule model is exible

enough to allow for additions and changes to the process on the y. This possibility is realized through the use of meta-operations that operate on the representation of the process itself. Process models are sophisticated plans for the development of software systems and often things do not proceed as planned. A process model will regularly be changed as unanticipated circumstances arise while it is being enacted. A collection of fairly independent rules is much easier to change than a similar collection of interdependent procedures. The nested transaction model, combined with events, is well suited to building automation chains, both forward and backward. The nested transaction model provides a controlled means of allocating resources to groups of rules by allowing child processes access to the resources held by their parents and allowing parent processes to acquire resources used by their children. Resources can be passed from one rule to the next in a chain. Rules can provide for single activities, but the transaction model is needed to coordinate sequences of activities. Interaction with people is largely the responsibility of the tools. Tools must provide any front end interface required as well as supporting the activities themselves. The primary means of interaction, particularly in a system such as Metaview, are tools. Editors, diagramming tools, compilers, report generators, etc., provide the interface to the human users, while the underlying execution model merely coordinates them. Finally, the active database model is not tied to any one process modeling language. Execution models designed to support one language will be suitable for that one language and no others. Metaview is intended to support many types of environments, including many types of process models. The active database model provides the exibility to support many dierent process models.

5 Example

This example is intended to show how one particular process modeling approach (Marvel's) can be realized in Metaview using a combination of EDL and ecode statements. Several other process modeling frameworks were examined and expressed using Metaview and these results are reported in [7]. The example shows the partial representation of a editcompile cycle in the Marvel process modeling language and its corresponding representation in Metaview. Within a larger context, this fragment can be used as a breakdown of the code modi cation activity as part of the implementation section of a more complete process model as shown in Figure 2. The example shows how events simulate the forward and backward chaining of Marvel and uses many of the constructs of ecode.

5.1 Modeling

Marvel represents all of its data as objects. These are translated to entities in Metaview. The CFILE object in Figure 3 represents a C program module. The program code is held in a text le referenced by the attribute contents, inherited from the superclass FILE, and the compiled object code is held in a binary le referenced by the attribute object code. An

Implementation Reserve Code Modification

Edit Compile

Test Module

Testing Fails

Figure 2: Context of Marvel Example. HFILE object represents a C header le. C programs and header les are connected in the Marvel model by the link attribute of CFILE called ref. Similarly, any submodules used by a C program are linked to the program through the submodule attribute. CFILE :: superclass FILE; compiled : boolean = false; compile_log : text; object_code : binary; ref : set_of link HFILE; submodule : set_of link CFILE; end

Figure 3: Marvel CFILE Object De nition. In general, objects in Marvel translate to entities in Metaview. Metaview entities allow inheritance just as Marvel does so the inheritance hierarchy translates directly to Metaview. The corresponding Metaview EDL representation is shown in Figure 4. The link attribute ref within CFILE in Figure 5 is really a relationship between a CFILE and an HFILE. In Marvel this relationship is an attribute of the participants, but in Metaview it must explicitly be represented as a RELATIONSHIP-TYPE as shown in Figure 5. Tools are represented as objects in Marvel. In ecode they become tool interface statements. The de nition

ENTITY-TYPE CFILE IS-A FILE ATTRIBUTES (compile_status : string, compiled : boolean, compile_log : text, object_code : text);

Figure 4: EDL CFILE Entity De nition. RELATIONSHIP-TYPE C_TO_HEADER ROLES (program, header) PARTICIPANTS (CFILE, HFILE);

Figure 5: EDL CFILE to HFILE Relationship. in Figure 6 only represents the interface to the tool. The Shell clause holds the name of the shell that actually invokes the tool. The shell is called from the execution engine and the shell performs all of the interactions necessary with the tool such as giving the tool input parameters and returning output parameters to the execution engine. Tool COMPILER In (c_program : String, header : List_Of String, submodule : List_Of String) Out (log : String, object_code : String) Shell 'compiler' End_Tool

Figure 6: Ecode COMPILER Tool De nition. Flow of control is built into the Marvel interpreter and is not explicitly represented in Marvel's rules. Marvel executes rules by either direct user invocation, or by chaining. Chaining is accomplished by comparing the preconditions of one rule, R1, with the postconditions of another rule, R2, and chaining between them if the preconditions match the postconditions. Backward chaining occurs when R1 chains to R2 in order to satisfy the preconditions of R1. Forward chaining occurs when R2 chains to R1 as a means of automating a small part of the overall software process. Flow of control must be explicitly represented in the rules of Metaview to match that of Marvel. This is done by deciphering the possible chaining in Marvel and producing events to represent that chaining. The parameters of the events come from the parameters of the corresponding Marvel rule. The Marvel compile rule in Figure 7 receives a CFILE object from the Marvel interface. It collects all HFILE objects linked to the CFILE and then checks if the CFILE has already been analyzed but not yet compiled. If the conditions succeed then the COMPILER tool is called. Based on the success of the COMPILER tool, the compiled attribute of the

CFILE is either set to true or false. compile[?c:CFILE, CurrentUser:user]: (and (forall HFILE ?h suchthat (linkto [?c.ref ?h])) (forall CFILE ?d suchthat (linkto [?c.submodule ?d]))) (?c.compiled = false) { COMPILER compile ?c.contents ?c.compile_log ?c.object_code ?h.contents ?d.contents } (?c.compiled = true) [?c.compiled = false]

Figure 7: Marvel compile Rule. The precondition of the edit rule in Figure 8 states that a CFILE must be owned by the CurrentUser, the one who is trying to edit the le, and must be reserved. If these conditions are met then the EDITOR tool is called. If the edit session succeeds, as is usually the case, the attributes of the CFILE are set to indicate that the CFILE needs to be compiled because changes to the le were made.

edit[?c:CFILE, CurrentUser:user]: ( ?c.reserved = true ) { EDITOR cfile ?c.contents } (?c.compiled = false)

Figure 8: Marvel edit Rule. This Marvel process de nition can be supported in Metaview and is expressed in ecode as shown in Figures 9 and 10. Only the corresponding compile rule and its triggering events are shown. The entire ecode representation is contained in the single cluster Modify Module which is not shown here. The start compile composite event in Figure 10 is the actual trigger for the compile rule. It states that the compile rule can be triggered by a user request (the compile event) or by a forward chain from the edit rule through the edit success event. The C program will automatically be compiled after it has been successfully edited. The compile rule in Figure 9 has a coupling type of immediate and it is independent of its parent rule. The immediate coupling mode causes the compile rule to be executed as soon as it is triggered. If the compile rule fails, then the parent rule can continue to execute normally due to the independent failure coupling. The parent rule is the rule that generated the event that triggered the compile rule. As in Marvel, the failure of the compile rule will not cause any changes made to the le to be rolled back. The condition of the compile rule in Figure 9 rst gathers all of the HFILE and CFILE objects linked to the C program being compiled into two lists just as in Marvel's compile rule. These values are all held in

Rule compile Within Modify_Module Priority 5; Immediate, Independent; Declarations hlist : List_Of HFILE; h : HFILE; d : CFILE; dlist : List_Of CFILE; c_stat : String; contents, c_log, obj_code : String; Event start_compile(aggr: MODULE, c : CFILE) Condition ALL get_assoc_role('MODULE', aggr, 'C_TO_HEADER', 'program', c, 'header', h) (Add_Front_List(hlist, h)) AND ALL get_assoc_role('MODULE', aggr, 'SUBMODULE', 'program', c, 'sub', d) (Add_Front_List(dlist, d)) AND get_attribute('MODULE' ,aggr, 'Entity', 'CFILE', c, 'compiled' ,c_stat) == FALSE AND get_attribute('MODULE',aggr,'Entity', 'CFILE', c, 'contents',contents) Action Check (Invoke COMPILER (contents, hlist, dlist, c_log, obj_code)) On_Success put_attribute('MODULE', aggr, 'Entity', 'CFILE', c, 'compiler_log', c_log); put_attribute('MODULE', aggr, 'Entity', 'CFILE', c, 'object_code', obj_code); put_attribute('MODULE' ,aggr, 'Entity', 'CFILE' c, 'compiled', TRUE); Generate_Event compile_success(aggr, c); On_Failure put_attribute('MODULE' ,aggr, 'Entity', 'CFILE', c, 'compiled', FALSE); End_Check End_Rule

Figure 9: Ecode Compile Rule. Composite_Event start_compile (aggr: MODULE, c : CFILE) Within Modify_Module compile(aggr, c) OR edit_success(aggr, c) End_Event Event compile (aggr : MODULE, c : CFILE) Within Modify_Module End_Event

Figure 10: Ecode Compile Event De nitions. Metaview's database and are accessed by the database operation get assoc role whose parameters specify the logical location of the EDL relationship that contains the needed information. The rule then checks to make sure that the compiled attribute of the CFILE entity is equal to FALSE. If these conditions are passed then all of the information needed by the action part of the rule is gathered. This consists of the actual le containing the program (contents). The action invokes the COMPILER tool with all of the necessary information. The Marvel compile rule has statements that are executed based on whether or

not the compiler was successful. This is simulated here with the Check statement. This statement indicates to the calling rule the success or failure of the operation being checked (in this case the compiler invocation). If successful, the statements in the On Success part are executed which store the compiler log and object code les, change the compile status of the CFILE entity to TRUE and generate a compile success event. If the operation fails then the statement in the On Failure part is executed.

5.2 Execution

In the execution model, if a user chooses to edit a le F , the interface tool would generate an edit event for F . The execution diagram is given in Figure 11. The edit event starts the transaction. This triggers the edit rule which invokes the editor tool and the user edits the le. When completed, an edit success event is generated. This event satis es the start compile event de nition so the start compile event is triggered. The compile rule is now executed and successfully compiles the le using the compiler tool. A compile success event is generated but no new rules are triggered. Since there is no further processing to be done, the changes made by the rules in the transaction are committed and the transaction terminates.

6.2 Future work

edit event

edit

editor tool

edit success

start compile

compile rule

compiler tool

compile success

Figure 11: Edit-Compile Execution.

6 Conclusions and Future Work

6.1 Summary

The major goal of this work was to produce a model for the execution of process models within the Metaview environment. This goal was realized through several subgoals. First, several process modeling languages and active databases were examined and the basic components of both process modeling and active databases were identi ed in Sections 2 and 3. Next, an execution model was developed based on the elements of active databases that were deemed essential to process modeling. The model proposed is a modi ed form of the HiPAC model { the major dierences come from the special needs of process modeling and of the Metaview system such as failure control and the EARA data model. The execution model and a language called ecode which represents the concepts described within the execution model were presented in Section 4. Primarily, the language describes the event and rule structures used in the execution engine, as well as the interfaces to the tools and the database. The nature of how process modeling concepts can be represented in Metaview was illustrated using an example originally expressed in a rule-based process modeling language Marvel. The generality of our approach is illustrated in much more detail in [7].

Based on this work, several avenues of future work present themselves. First, some changes can be made to the ETL language to make it better suited to representing process modeling languages. At present, ETL has a very limited capability for interaction with outside tools { all that is provided is an external rule invocation construct. ETL also has no means to deal with the failure of activities. The simplifying assumption of a single thread of execution was made in developing our execution model. This must be expanded to include concurrent execution. Concurrency control is a key issue in multi-user CASE environments. Presently, the execution model views tools in a simplistic way. A tool is called with some set of data and is expected to return another set of data. A truly interactive process-centered environment needs a more exible tool model, one in which tools can respond to events themselves. An executing tool could then interactively respond to requests from the execution engine. Such a model may require tools to be written in a new way. This interaction must also be tied to the concurrency model. What has been presented thus far is a model of execution. The behavior of the execution engine within the execution model was de ned, including how it executes rules and how it interfaces with the tool set and the database. However, for a process-centered Metaview CASE environment to be fully functional, the execution engine must be implemented. There are several implementation options. As a rst option, the execution engine might be written as a program that interprets the event-rule language proposed. As a second option, the event-rule language, along with the underlying execution model might be translated to an active database. A third option is to have the event-rule paradigm translated to the current Metaview database in PD-Prolog [6]. Our initial approach will be the third choice, which is the easist to accomplish but ultimately the most restrictive option. After gaining experience with this approach, we will then decide between the rst two options.

6.3 Contributions

The main contributions of this paper fall within the area of providing support for the execution of process models. First, it was demonstrated that it is possible to incorporate support for process modeling in a metasystem. The Metaview metasystem already provides support for the generation of CASE environments for a wide variety of speci cation methods. With the addition of an execution model, Metaview can also support process modeling and enactment. Second, a language and execution model was devised to support a range of dierent process modeling languages and paradigms. This is a novel approach. Other support environments concentrate upon execution support for a single process modeling language. Examples of dierent types of process models written in dierent process modeling languages were shown in [7] to be expressible in the ecode language and executable in the proposed execution model. Third, the feasibility of using an active database

paradigm for the support of process model enaction was established. The proposed execution model is based upon the event-rule model found in active databases. Although the use of an event-rule model for process modeling is not new, the use of an eventrule model within a metasystem to support a wide variety of process modeling languages is new.

Acknowledgements

The authors would like to thank Piotr Findeisen for his careful reading of a draft of this paper and acknowledge the nancial support of this work through NSERC and the IRIS Project which is a part of the Canadian Federal Network of Centres of Excellence Program.

References

[1] Barghouti, S. Supporting Cooperation in the Marvel Process-Centered SDE. in Proc. of the 5th ACM SIGSOFT Symposium on Software Development Environments, Dec. 1992, pp. 21-31. [2] Boloix, G., Sorenson, P.G. and Tremblay, J.P. Process Modeling Using a Metasystem Approach to Software Speci cation., Technical Report TR 92-11, Department of Computing Science, University of Alberta, Edmonton, Alberta, Canada, Sept. 1992. [3] Chen, M. The Entity-Relationship Model - Toward a Uni ed View of Data. ACM Transactions on Database Systems, 1, 1, March 1976, pp. 9-36. [4] Curtis, B., Kellner, M.I. and Over, J. Process Modeling. Communications of the ACM, 35, 9, Sept. 1992, pp. 75-90. [5] Dayal, U., Buchmann, A.P. and McCarthy, D.R. Rules are Objects Too: A Knowledge Model for an Active, Object-Oriented Database System. in Proc. of the 2nd International Workshop on Object-Oriented Database Systems, Sept. 1988, pp. 129-143. [6] Findeisen, P.S. Environment De nition for Database Engine. Manuscript, Department of Computing Science, University of Alberta, Edmonton, Sept. 1992. [7] Froehlich, G. Process Modeling Support in Metaview. M.Sc. Thesis, Department of Computational Science, University of Saskatchewan, Saskatoon, 1994. [8] Gane, C. and Sarson, S. Structured Systems Analysis: Tools and Techniques. IST, Inc. (New York 1977).

[9] Hamilton, M. and Zeldin, S. Higher Order Software A Methodology for De ning Software. IEEE Transactions on Software Engineering, 2, 1, March 1976, pp. 9-32. [10] Hsu, M., Ladin, R. and McCarthy D.R. An Execution Model for Active Data Base Management Systems. in Proc. of the 3rd International Conference on Data and Knowledge Bases, June 1988, pp. 171-179. [11] Kaiser, G.E., Feiler, P.H. and Popovich, S.S. Intelligent Assistance for Software Development and Maintenance. IEEE Software, 5, 3, May 1988, pp. 40-49. [12] Katayama, T. A Hierarchical and Functional Software Process Description and its Enaction. in Proc. of the 11th International Conference on Software Engineering, 1989, pp. 343-352. [13] Liu, L. and Horowitz, E. A Formal Model for Software Project Management. IEEE Transactions on Software Engineering, 15, 10, Oct. 1989, pp. 1280-1293. [14] McAllister, A.J. Modeling Concepts for Speci cation Environments. Ph.D. Thesis, Department of Computational Science, University of Saskatchewan, Saskatoon, 1988. [15] Perry, D.E. and Kaiser, G.E. Models of Software Development Environments. IEEE Transactions on Software Engineering, 17, 3, March 1991, pp. 283-295. [16] Protsko L.B., Sorenson, P.G., Tremblay, J.P. and Schaefer, D.A. Towards the Automatic Generation of Software Diagrams. IEEE Transactions on Software Engineering, 17, 1, Jan. 1991, pp. 10-21. [17] Sorenson, P.G., Tremblay, J.P. and McAllister, A.J. The Metaview System for Many Speci cation Environments. IEEE Software, 5, 2, March 1988, pp. 3038. [18] Sutton, S.M., Heimbinger, D. and Osterweil, L.J. Language Constructs for Managing Change in Process-Centered Environments. in Proceedings of the 4th International Symposium on Practical Software Development Environments, SIGSOFT Notes 15, 6, 1990, pp. 206-217. [19] Zhuang, Y. Object-Oriented Modeling in Metaview. M.Sc. Thesis, Department of Computing Science, University of Alberta, Edmonton, 1994.