Process Modeling in-the-large with SLANG - CiteSeerX

Process Modeling in-the-large with SLANG Sergio Bandinelli, Alfonso Fuggetta, Sandro Grigolli CEFRIEL { Politecnico di Milano

GOODSTEP ESPRIT-III project No. 6115 GOODSTEP Technical Report No. 012 February, 1993 Abstract

This paper discusses some features provided by the SPADE environment to support the de nition, analysis and enactment of large and evolving software process models. In particular, we introduce the concept of activity, which allows the process designer to create and hierarchically aggregate fragments of process speci cations. We then provide an execution model for activities and propose dierent alternatives for activity execution. Finally, we discuss the impact that the activity concept has on other important problems such as incremental de nition and evolution of large process models.

Process Modeling in-the-large with SLANG Sergio Bandinelliy

Alfonso Fuggettaz

Sandro Grigolli

CEFRIELxand Politecnico di Milano

CEFRIEL and Politecnico di Milano

CEFRIEL

Abstract This paper discusses some features provided by the SPADE environment to support the de nition, analysis and enactment of large and evolving software process models. In particular, we introduce the concept of activity, which allows the process designer to create and hierarchically aggregate fragments of process speci cations. We then provide an execution model for activities and propose dierent alternatives for activity execution. Finally, we discuss the impact that the activity concept has on other important problems such as incremental de nition and evolution of large process models. Keywords: software processes, programming-in-thelarge, software process models, software process languages, process enactment, process evolution.

1 Introduction Software processes may be viewed as a set of software engineering and management activities that are needed to produce a software artifact. In large projects, these activities may proceed in parallel, reacting to external events and involving the cooperation and coordination of many persons. Project activities have to be managed and scheduled so that certain deadlines are met. In order to manage the complexity of the process, we need a language to describe it at dierent levels of abstraction. At each level, unnecessary details are hidden, allowing us to concentrate on the relevant issues. Thus, the description of complex processes is  Proceedings of the Second International Conference on the Software Process, Berlin (Germany), February 1993. y Sergio Bandinelli is partially supported by Digital Software Engineering Center, Piazza XX Settembre 1, I-21100 Varese. E-mail: [email protected]. z E-mail: [email protected]. x CEFRIEL Via Emanueli 15, I-20126, Milano. Tel: +39-266100083. Fax: +39-2-66100448.

much like programming in the large. That is, we deal with the composition (and decomposition) of the system into modules. On the other hand, the detailed description of how a single elementary activity is carried out may be viewed as programming in-the-small. Fundamental concepts of programming in-the-large are hierarchy and encapsulation [14]. A process description is structured in dierent levels. Each level de nes operations that may be used only at higher (more abstract) levels. Moreover, each level de nes and manages a set of objects. Implementation details of each object are hidden within the level in which the object is de ned. Programming in-the-large principles emphasize and support incremental software development and reuse. A module can be developed independently of the others, as long as its interface is clearly speci ed. Furthermore, standard and stable interfaces favor reuse of existing modules in new software systems. SPADE is an environment that is currently being developed at CEFRIEL and Politecnico di Milano. Its main objectives are to support the analysis, design, and enactment of software processes. SPADE includes a language called SLANG (Spade LANGuage), based on a timed high level Petri net formalism. SLANG provides speci c expressive constructs for the description of software process. The purpose of this paper is to introduce language constructs for process programming in-the-large in the SPADE environment. In particular, we present the activity construct, that allows the project manager to design the process according to the programming in-the-large principles stated above. An activity definition includes an interface and an implementation. The implementation may contain invocations of other activities, and dierent execution modes may be associated with each activity invocation. This paper is structured as follows. Section 2 introduces the basic SLANG features by means of an example. The activity construct is described in Section 3. Section 4 explains the execution model. Sec-

tion 5 relates our work with other similar approaches. Section 6 outlines future work and draws some conclusions.

latex processing outputs source text files

latex request

*

2 Process modeling in-the-small with SLANG SLANG is a domain-speci c language for software process modeling and enactment. It is based on a high-level Petri net formalism called ER nets [5]. ER nets have been de ned as a kernel formalismproviding powerful means to describe concurrent and real-time systems. In ER nets it is possible to assign values to tokens and relations to transitions, describing the constraints on tokens consumed and produced by transition rings. SLANG constructs are given semantics in terms of a translation scheme to ER nets. In order to present the main SLANG features supporting process modeling in-the-small we introduce a sample process that will be used throughout the paper. A more detailed introduction to basic SLANG characteristics can be found in [1, 2].

2.1 An example process The proposed example process concerns document processing with the LaTEX formatting system. A LaTEX source document is composed of one or more les. The main le can include a number of subdocuments using the \include directive [9]. A LaTEX document can contain cross references (e.g., bibliography, section and gure numbers, etc.). When a change is applied to a document, it is necessary to process the document twice in order to update all these references. Figure 1 represents a possible SLANG model of the LaTEX document processing process.

2.2 Slang features

Places and Tokens. The process state is described

by the net marking. The objects involved in the process (documents, requests, tools results, etc.) are represented by typed tokens. A place is a token repository that contains only tokens of its predeclared type. For example, places latex input, latex output, analyzed latex output, processed document, successfully processed document and unsuccessfully processed document in Figure 1 can only contain tokens of type Document. A LaTEX document is a composite structure containing a set of LaTEX source les (i.e., the main le and all the sub-documents) and other les

begin latex processing

latex input latex latex output error & reference changes detection analyzed latex output

latex re-process

detection result

processing ok

processed document processing successful

succesfully processed document

errors detected

unsuccesfully processed document

Figure 1: SLANG model for the LaTEX processing of a single document produced by the LaTEX processing, as speci ed in the following declaration:

Document

document name: string; main: text le; subdocuments: set of text le; dvi: dvi le; log: text le; aux: reference table le; ... Another example of typed place is the detection result place which can contain tokens of type Result. The token can assume one out of three dierent values: Result = enum (errors, reference changed, ok)

Transitions. A transition ring represents the oc-

currence of an event taking a negligible amount of

time. Transitions are associated with a guard and an action. The transition's guard is a predicate on input tokens and is used to determine if there is a tuple enabling the transition to re. The ring rule describing the dynamic behavior of the net states that when a transition res, tokens satisfying the guard are removed from input places and the transition's action is executed. Consider, for example, transition processing ok. Its guard and action are given in the following1: Event ProcessingOk (ALO, DR; PD)

Guard

any ALO from Place(ALO) any DR from Place(DR) such that DR = ok

Action

PD = ALO

Arcs. Weighted arcs are used to connect places to

transitions and vice-versa. The weight indicates the number of tokens that may ow through the arc. It can be a statically de ned number or it may be dynamically computed. In the latter case, the arc weight is known only at run-time. This is useful to model events requiring, for example, all tokens that verify a certain property. In Figure 1 the begin latex processing transition requires all the tokens contained in the source text les place representing les that are related to the document to be processed. The corresponding arc is labeled with a \", which means dynamic weight. Besides \normal" arcs, SLANG provides two other dierent kinds of arcs: read-only and overwrite. A read-only arc may connect a place to a transition. The transition can read and use token values from the input place in order to evaluate the guard and the action, but no token is actually removed or modi ed. An overwrite arc may connect a transition to a place. When the transition res, the following atomic sequence of actions occurs. First the output place is emptied of all its tokens. Then, the token(s) produced by the ring are inserted in the output place. The overall eect is that the produced tokens overwrite any previous content of the output place.

Black transitions. A software development process

involves the activation of a large variety of software tools. Tool invocation is modeled in SLANG by using

1 ALO, DR and PD represent tokens taken from places analyzed latex output, detection result and processed documents respectively. For the sake of simplicity, we assume here that it is possible to process only one document at a time: we will remove this constraint later.

Normal Arc

Read Only Arc

Overwrite Arc

the black transition construct. Every black transition is associated with a non-SLANG executable routine (e.g., a Unix executable le). When the black transition \ res", the routine is executed asynchronously: this means that other transitions in the net may be red while the black transition is being executed. This means also that the black transition itself may \ re" many times with dierent input tuples, without waiting for each routine execution to complete. In Figure 1, transitions latex, error & reference changes detection and re-process latex are examples of black transitions.

Human interaction. User requests and user data are communicated to the SLANG speci cation by translating them into tokens to be inserted in the corresponding user interface place (depicted as double circled place, e.g., latex request in Figure 1). Any communication from a SLANG speci cation to users is managed through the activation of speci c communication tools (e.g., e-mail facilities, report generators, etc.) via the black transition mechanism. Time notation. Every transition is associated with

a time constraint de ning the time interval during which an enabled transition may or must re. The list of SLANG time constraints that can be associated with a transition is shown in Table 1. The meaning is given in term of time intervals. An [; ] time interval means that the transition must or may re within [; ] time units from the enabling time. SLANG time notation Time interval ASAP must re within [0,1] ASAP AFTER  must re within [,1] MAY BEFORE  may re within [0,] AFTER  AND MAY BEFORE may re within [, ] Table 1: SLANG time notation expressed in term of the enabling time intervals.

Timeout. SLANG oers a timeout construct that allows a process speci er to de ne the maximum time interval between the ring of two transitions, namely the start-timeout and the end-timeout transitions. The end-timeout transition actually speci es two actions, one representing successful completion within the timeout, and the other signaling that the timeout has not been met. A detailed discussion of the timeout construct may be found in [2].

3 In-the-large language constructs for SLANG A software process may be viewed as a set of related activities that are executed concurrently, according to their logical precedence and, at the same time, scheduled to meet some global deadlines. For example we may have dierent tasks concerning coding and quality assurance that proceed in parallel and synchronize by accessing a set of shared resources. The concept of activity is central for the description of a software process. In this Section we introduce a SLANG construct to support the activity concept. In order to introduce this construct, we rst enrich our running example by giving an extended version of the production of a document using LaTEX.

3.1 Example extension We extend the document processing example by considering the whole process used to generate a document using LaTEX. We assume the existence of a repository of LaTEX documents. A user may require to work on an already existing document (modify document) or on a new one, specifying the type of document (e.g., book, article, report, etc.) he/she wants to produce (create document). The rst step in the production of a document consists of verifying the user request. In particular, it has to be veri ed that the document is available when a modify document request is issued, or, in case of a create document request, that no document with the same name exists. If neither of these conditions is satis ed, the request is not accepted. If necessary, the LaTEX document template is generated automatically by an ad-hoc tool. Once the request has been accepted, users in charge of the document production can edit, process with LaTEX, and view the document layout until they decide that the document production activity is terminated. During document editing, the user may add or remove

sub-documents from the main source document le. Sub-documents may be edited independently. If any errors occurred in the previous LaTEX processing, the whole document (together with the errors list) may be edited in a special error correction mode. Document processing using LaTEX has already been described in Section 2.1. Two other options should also be available: viewing the actual layout of the formated document and printing the current document.

3.2 The activity construct The previous example shows that a natural way to describe a process, such as the generation of a LaTEX document, is to structure it in dierent activities. These activities have logical dependencies. For example, editing cannot start until the user request has been veri ed. On the other hand, it is possible to edit two dierent fragments of the same document in parallel. In general, an activity may be initiated by dierent events and there is more than one way to terminate it. Document veri cation, for example, may be activated by two dierent events: the request for the generation of a new document and the request for the modi cation of an existing one. Document veri cation may terminate by accepting the request for a new or existing document or by rejecting it. Notice that the entire document generation process may also be considered as an activity with two possible starting events (create document and modify document) and two possible ending events (generated document and unsatis able request). During its activation, the document generation activity may also need to access to the set of available documents (to verify the user request). Figure 2 provides a possible representation of the document generation activity de nition using SLANG. An activity is modeled by a SLANG net by two distinct sets of events (transitions), namely the starting and the ending events. An activity starts when one of the events of the starting set occurs and nishes when one of the events of the ending set occurs. Figure 3 is a general representation of a SLANG activity. An activity interacts with the rest of the process speci cation through interface places. They are classi ed in the following categories (note that a place may belong to more than one category at the same time):  Input places: are input to any of the starting events,  Output places: are output places for any of the ending events,

(1) source text files

modify document

create document

(2) latex output files

once more that the output places of the ending event are a subset of output places of the activity.

3.3 Activity de nition and invocation documents

Document Verification NotOk

OkOld OkNew Create Template

Split

process req

(1) edit request

Document Editing

(2)

Document Processing NoErrors Errors

echo "errors"

view request

Document Viewing

unsatisfiable request

end activity request

documents

Figure 2: SLANG model of \Document Generation" activity de nition. Intermediate places: are places that may be in input or output for any transition internal to the activity. When an activity starts, it removes the enabling tuple from input places of the starting event. Note that input places of a starting event are a subset of input places of the whole activity. Thus, when an activity starts, it may remove tokens only from some of its input places. The activity can remove or insert tokens from/in an intermediate place at any time during its activation. When the activity nishes, the produced tokens are inserted in the output places of the ending event that caused the ending of the activity. Note 

input places

... activity

intermediate places

... output places

Figure 3: SLANG activity.

An activity de nition includes an interface and an implementation part. The interface is composed of:  The interface places (i.e., the input, output and intermediate activity places) together with their types.  The starting and ending events of the activity.  The arcs connecting the input-output places to starting-ending events, together with their weights.  The arcs connecting intermediate places to the activity box. The arcs weight and kind (normal, read-only or overwrite) may not be speci ed at this level. The implementation part of the activity is a SLANG net describing how tokens are transformed between the starting and the ending events. This net accesses input and output places through starting and ending transitions respectively, whereas it accesses intermediate places through any other transition internal to the activity. Places internal to the implementation part (not belonging to the interface) are called local places. The implementation part of an activity may contain invocations of other activities. For example, the activity implementation of Figure 2 contains four activity invocations (i.e., \Document Veri cation", \Document Editing", \Document Processing", \Document Viewing"). The \Document Processing" activity de nition, given in Figure 1, contains no activity invocations. Using the invocation relationship among activities, it is possible to build a graph in which each node identi es an activity and each arc represents an activity invocation. Recursive invocations are not allowed in SLANG, and thus, this invocation graph de nes a hierarchy among activities. We assume that there is only one root in the hierarchy, called \root activity".

4 SLANG execution model In a process centered environment, the process model plays the role of the \code" to be executed to control and monitor the process during its enactment.

The execution is performed by a process model interpreter that we call SLANG interpreter. The dynamic behavior of a SLANG net is de ned operationally by the ring rule that describes possible state changes. The SLANG interpreter evaluates the guards associated with the transitions and analyzes their time constraints. From all enabled transitions (feasible events), it chooses one (automatically or with user intervention) and res it. The ring removes tokens from the input places, executes the corresponding action, and inserts the produced tokens in the output places. This produces a state change that enables new rings. The procedure is iterated and this yields a ring sequence that is the net execution trace. We use the name process engine to refer to each running instance of the SLANG interpreter. In order to have an ecient execution and to favor distribution, the process description may be concurrently interpreted by several process engines that communicate and are synchronized via shared places, as described in [2]. Each process engine executes a SLANG net fragment.

SLANG guarantees that an activity cannot terminate if it contains active instances of other activity invocations. Therefore, if an activity instance A has invoked other activities a1 , a2, etc., during its execution, A will not be enabled to terminate until the invoked activities a1, or a2 , etc. terminate their own processing. The semantics of the activity construct and its behavior can be given in terms of the basic ER net formalism. As an example, consider the rule concerning the termination of an activity discussed in the previous paragraph. To describe the fact that an activity instance A cannot terminate if any inner activity is still active, it is possible to introduce a place counter in A . Place counter is connected to all the starting and ending transitions of the invoked activities. It contains, at any time, the number of currently active instances of activities internal to A . It is also an input place to every A ending transition, and every A 's ending transition is enabled to re only when the number contained in counter is zero (i.e., there are no more active instances \inside" A ).

4.1 Activity execution

4.2 Execution modes

The ring of transitions that correspond to starting and ending events of an activity invocation involves the creation and termination of the activity instance. Each time an activity is invoked, a new instance of it is created. Each instance has it own copy of the local places, while interface places (input, output and intermediate, including possible user interface places) are shared among the dierent instances that use them. When one of the transitions corresponding to the ending events res, the tokens produced by this ring are inserted in the corresponding output places and the activity instance is destroyed. This means that local places are deallocated and their contents are lost. As an example consider once again Figure 2. Place latex output les is an intermediate place for \Document Editing" activity (DE ) and it is local to \Document Generation" activity (DG). Let us suppose that during the execution of an instance DG of the activity DG, activity DE is invoked, and thus an instance DE is generated. Therefore, when DE nishes, place latex output les and its tokens persist. On the other hand, when DG nishes, place latex output les is destroyed, and all of its tokens are lost. On the contrary, place documents is an intermediate place of both \Document Veri cation" (DV ) and \Document Generation" (DG) activities. When DV and DG activity instances nish, place documents and its tokens persist.

Actually, an activity invocation may be performed according to two dierent execution modes: asynchronous and synchronous mode. If the invocation is asynchronous a new process engine is associated with each new instance of the activity. On the contrary, in a synchronous invocation, the new instance of the activity is executed by the same process engine that performed the call, i.e., no new process engine is started. Note that the execution mode is independent from the activity de nition. In fact, two dierent invocations of the same activity may be one synchronous and the other asynchronous. The root activity is, by de nition, an asynchronous activity. A process engine is associated with it when it is activated at system startup. Consider the high-level algorithm of Figure 4, describing the execution of an activity (procedure ExecActiv). The input parameter t of the procedure is a starting transition of activ enabled by enab tuple. The algorithm chooses at each cycle one enabled transition internal to the activity (Decide next firing) and res it. The execution cycle continues until the chosen transition is one of the ending transitions. If the chosen transition is a starting transition of an inner activity invocation of InvActiv, the execution procedure performs a recursive call to ExecActiv. The way the recursive call is executed depends on the activation mode associated

inst

inst

inst

inst

inst

inst

inst

inst

inst

inst

inst

inst

ExecActiv(activ, t, enab_tuple) while (t not belongs_to ending_set) do begin if t belongs_to start(InvActiv) then ExecActiv(InvActiv, t, enab_tuple) else Fire(t, enab_tuple); := Decide_next_firing; end Fire(tran, enab_tuple); Deallocate local places;

Figure 4: High-level algorithm for the execution of an activity. with InvActiv. If it is synchronous, the recursive call is executed by the same process engine that performed the call. On the contrary, if it is asynchronous, a new process engine is created to execute the recursive call. Let us describe in some detail the activation mechanism of an asynchronous activity. Consider an asynchronous activity instance A executed by a process engine PE . The A 's implementation contains the invocation of another asynchronous activity a. When PE , during A 's execution, decides to activate a, a new a's instance a is created and a new process engine pe is associated with it. While pe executes a , PE continues executing A ; i.e., PE analyzes A 's implementation and decides whether to re transitions or activate activities internal to A . PE can possibly decide to activate a again, if a is enabled to start. In this case, a new instance a of a is created, and a new process engine pe is associated with it. Notice that black transitions (as de ned in Section 2) may be viewed as a special case of asynchronous activities where: inst

inst

inst

inst

inst

inst

inst

inst

0

0

inst

- There is only one starting transition and one ending transition. - The \black transition" activity implementation is given in non-SLANG code. Thus, the process engine associated with it at activation time is not a running instance of the SLANG interpreter, but of some other tool. For example, if the routine associated with the black transition is a Unix shell script, the tool would be the Unix shell interpreter.

5 Related work Many process languages support the concept of activity as a structuring construct for the hierarchical description of process models. A variety of dierent techniques are used to represent activities [4]. In GeSEM [7] activities (called tasks) are organized in a hierarchy. A GeSEM activity may be re ned in terms of other activities. A simple activity is informally described with a textual notation. Once created, an activity undergoes periods of execution, performed by developers. The execution may be interleaved with periods of further speci cation. The dynamicity of the model is augmented by the fact that also relationships among activities may be changed. It is not clear, however, how these changes are managed. FUNSOFT nets [6] are a Petri net based process description language that supports the concept of activity (called jobs). A transition of the net may represent an activity and may be re ned by a subnet. The main dierence with our approach is that we can naturally model that an activity may be initiated (respectively terminated) by more than one event. In addition, we have de ned an execution model where each activation of an activity leads to a new independent instance of the activity. In EPOS [10] the activity concept is modeled through three dierent kinds of process elements. Tasks are execution entities that are associated with a code, much like our asynchronous SLANG activities. ProcEntities, instead, are passive elements like an asynchronous SLANG activity, that have to be executed by some embedding task. Finally tools correspond to executable programs (such as compiler, editor, text processors, etc.). High-level process elements can be statically decomposed into simpler subelements through the subtyping mechanism. Process elements can be dynamically changed through the versioning mechanism. However, there is a lack of semantic control over dynamic change mechanisms. In rule-based approaches such as Marvel [3] and Merlin [8, 12], the activity concept is modeled through rules. In particular in Merlin, logically related activities can be grouped together under a role (e.g., project manager). Both approaches lack an adequate hierarchical mechanism to group rules and structure them in complex activities. Other well-known approaches to process modeling in-the-large topics are presented in APPL/A [13] and ALF [11].

6 Conclusions and future work In this paper we have discussed the features oered by SLANG to support the creation and enactment of large process models. They are based on the activity concept, and on the mechanisms supporting the execution of a hierarchy of such activities. In particular, we have shown how to aggregate and nest activities, in order to facilitate the conceptual design of a process model and allow ecient execution by means of multiple process engines. We believe that these features are an important starting point to support two fundamental issues in the process modeling area, that are the main goals of our current research eort: incremental de nition and dynamic evolution of a process model. Many researchers have pointed out that it must be possible to de ne software process models by progressively re ning and enriching a initial core model, supporting only a portion of the process. Moreover, a software process changes in order to re ect the evolution of the organization, the reaction to new facts that are not anticipated in the model, or the introduction of new technologies and methodologies. It is therefore mandatory to provide functionalities to de ne and apply these changes to the enacted process model from within the process. A process language must take into account these requirements: in particular, it must provide features supporting the modi cation of a process model fragment without stopping the rest of the process, and the ability to (re)start new or modi ed process model fragments as soon as they become available. Moreover, the (meta)process used to carried out such modi cations must be de nable and managed as any other part of the process: this means that a process language must provide powerful mechanisms to manipulate a process model as part of the model itself. In SLANG, we have identi ed a few basic mechanisms that we think are the basis to achieve such results. These features are only sketched here and will be discussed in more detail in future works. Basically, the dynamic creation of process engines allows us to incrementally enact dierent parts of a process model. Moreover, black transitions enable to us to model metaprocess tasks such as the modi cation of activities using a specialized editor. This is possible since a SLANG speci cation is stored as a collection of activities that may be accessed and changed as any other process data. An activity de nition is not statically bound to its invocation. Instead, it is dynamically made available to the process engine at the beginning of its execution. This provides a basic in-

terpretative mechanisms to support dynamic process evolution. The SLANG constructs and mechanisms introduced in this paper provide great expressive power and exibility for the de nition and enaction of process models. It is also possible to analyze the process, basically by simulating its execution and then observing the possible resulting behaviors. For example, one may generate process scenarios that support a form of \what if" analysis, e.g. what happens if certain activities are executed in parallel instead of sequentially. Other ways of process veri cation, based on reachability and deadlock analysis are undecidable for a general SLANG speci cation. However, it is always possible to perform these kind of analysis in a simpli ed process speci cation or for limited special cases.2 The goals of our current work are summarized in the following points:  To develop a rst prototype of the SLANG process engine, supporting concurrent execution of SLANG activities and based on a central, object oriented database. We have started this task in the rst half of 1992, using C++ and the object-oriented database O2. We will start soon the assessment of the Objectivity OODB, and of the ACA services provided by the DEC Cohesion platform, to support tool encapsulation and invocation.  To develop a SLANG speci cation of a large, testcase process.  To integrate such process model in order to deal with the modi cation and incremental de nition of the process model itself.  To enrich the process engine functionalities, in order to support the distribution and/or replication of activities on a network of workstations.

Acknowledgements We are grateful to Carlo Ghezzi, who is in charge of the scienti c supervision of the SPADE project, for his valuable comments and suggestions. We wish to thank also Fabrizio Ferrandina for his assessment and prototyping work on object-oriented databases within the SPADE project. 2 Most Petri net analysis algorithms have high costs in terms of computational complexity and thus, in practice, they may be used only for small nets.

References [1] S. Bandinelli, A. Fuggetta, C. Ghezzi, \Software Processes as Real Time Systems: A case study using High-Level Petri nets", in Proc. of Inter-

national Phoenix Conference on Computers and Communications, Phoenix, Arizona, April 1992.

[2] S. Bandinelli, A. Fuggetta, C. Ghezzi, S. Grigolli, \Process Enactment in SPADE", in Proc. of 2nd. European Workshop on Software Process Technology, Trondheim, Norway, September 1992. [3] N.S. Barghouti, G.E. Kaiser, \Scaling Up RuleBased Software Development Environments", in Proc. of 3rd. European Software Engineering Conference, Milan, Italy, October 1991. [4] M. Dowson, B. Nejmeh, W. Riddle. \Fundamental Software Process Concepts", in Proc. of First European Workshop on Software Process Modeling Milan, Italy, May 1991.

[5] C. Ghezzi, D. Mandrioli, S. Morasca, M. Pezze, \A Uni ed High-Level Petri Net Formalism for Time-Critical Systems", IEEE Transactions on Software Engineering, February 1991. [6] V, Gruhn, \Validation and Veri cation of Software Process Models", Ph. D. Thesis, Dortmund University, 1991. [7] G. Hulin, M. Lacroix, D.Roelants and M. Vanhoedenaghe, \Integrated Product and Process Modelling", in Proc. of First European Workshop on Software Process Modeling, Milan, Italy, May 1991. [8] H. Hunnekens, G. Junkermann, B.Peuschel, W. Schafer, J. Vagts, \A Step Towards Knowledgebased Software Process Modeling", in Proc. of First Conference on System Development Environments and Factories, 1990.

[9] L. Lamport, \LaTEX User's Guide and Reference Manual", Addison-Wesley Publishing Company, 1986. [10] C. Liu, R. Conradi, \Process Modeling Paradigms: an evaluation", in Proc. of First European Workshop on Software Process Modeling

Milan, Italy, May 1991.

[11] F. Oquendo, J. Zucker, P. Griths, \The MASP approach to Software Process Description Instantiation and Enaction" First European Workshop on Software Process Modeling Milan, Italy, May 1991. [12] B. Peuschel, W. Schaefer, \Ecient Execution of Rule Based Persistent Software Process Models in MERLIN", in Proc. of 14th. International Conference on Software Engineering, Merlbourne, Australia, 1992. [13] S. Sutton, D. Heimbigner, L. Osterweil, \Language Constructs for Managing Change in Process-Centered Environments", Proceedings of the 4th. ACM SIGSOFT Symposium on Software Development Environments, Irvine, Cali-

fornia, December 1990. [14] W.F. Tichy, \Programming in-the-Large: Past, Present, and Future", in Proc. of 4th. International Conference on Software Engineering and Knowledge Engineering, Capri, Italy, 1992.