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 CEFRIEL and CEFRIEL
Politecnico di Milano Politecnico di Milano

Abstract much like programming in the large. That is, we deal

with the composition (and decomposition) of the sys-
This paper discusses some features provided by the tem into modules. On the other hand, the detailed
SPADE environment to support the denition, analy-
sis and enactment of large and evolving software pro-
cess models. In particular, we introduce the concept
of activity, which allows the process designer to cre-
ate and hierarchically aggregate fragments of process
description of how a single elementary activity is car-
ried out may be viewed as programming in-the-small.
Fundamental concepts of programming in-the-large
are hierarchy and encapsulation [14]. A process de-
scription is structured in dierent levels. Each level
specications. We then provide an execution model denes operations that may be used only at higher
for activities and propose dierent alternatives for ac- (more abstract) levels. Moreover, each level denes
tivity execution. Finally, we discuss the impact that and manages a set of objects. Implementation details
the activity concept has on other important problems of each object are hidden within the level in which the
such as incremental denition and evolution of large object is dened.
process models. Programming in-the-large principles emphasize and
Keywords: software processes, programming-in-the- support incremental software development and reuse.
large, software process models, software process lan- A module can be developed independently of the oth-
guages, 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, re-
ers, as long as its interface is clearly specied. Fur-
thermore, 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
acting to external events and involving the coopera-
tion and coordination of many persons. Project activ-
ities 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 is-
sues. 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: bandinelli@mailer.cefriel.it.
z E-mail: alfonso@mailer.cefreil.it.
x CEFRIEL Via Emanueli 15, I-20126, Milano. Tel: +39-2-
66100083. Fax: +39-2-66100448.
provides specic expressive constructs for the descrip-
tion 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 def-
inition includes an interface and an implementation.
The implementation may contain invocations of other
activities, and dierent execution modes may be asso-
ciated with each activity invocation.
This paper is structured as follows. Section 2 in-
troduces the basic SLANG features by means of an
example. The activity construct is described in Sec-
tion 3. Section 4 explains the execution model. Sec-
tion 5 relates our work with other similar approaches. latex
Section 6 outlines future work and draws some con-
processing
outputs
clusions. source
text files
latex
request
*
begin
2 Process modeling in-the-small with latex processing

SLANG latex
input

SLANG is a domain-specic language for software latex

process modeling and enactment. It is based on a
high-level Petri net formalism called ER nets [5]. ER latex
nets have been dened as a kernel formalismproviding output
powerful means to describe concurrent and real-time error & reference
systems. In ER nets it is possible to assign values changes detection

to tokens and relations to transitions, describing the analyzed

constraints on tokens consumed and produced by tran- latex output
detection
result
sition rings. SLANG constructs are given semantics
in terms of a translation scheme to ER nets.
In order to present the main SLANG features sup- latex
re-process
porting process modeling in-the-small we introduce a processing
ok
sample process that will be used throughout the pa-
per. A more detailed introduction to basic SLANG processed
document
characteristics can be found in [1, 2]. processing errors
2.1 An example process
successful detected

The proposed example process concerns document succesfully unsuccesfully

processing with the LaTEX formatting system. A processed
document
processed
document
LaTEX source document is composed of one or more
les. The main le can include a number of sub- Figure 1: SLANG model for the LaTEX processing of
documents using the \include directive [9]. A LaTEX a single document
document can contain cross references (e.g., bibliogra-
phy, section and gure numbers, etc.). When a change produced by the LaTEX processing, as specied in the
is applied to a document, it is necessary to process the following declaration:
document twice in order to update all these references.
Figure 1 represents a possible SLANG model of the Document
LaTEX document processing process. document name: string;
main: text le;
2.2 Slang features subdocuments: set of text le;
dvi: dvi le;
Places and Tokens. The process state is described log: text le;
by the net marking. The objects involved in the pro-
cess (documents, requests, tools results, etc.) are rep-
resented by typed tokens. A place is a token repository
that contains only tokens of its predeclared type.
For example, places latex input, latex output, an-
alyzed latex output, processed document, successfully
processed document and unsuccessfully processed doc-
ument in Figure 1 can only contain tokens of type
Document. A LaTEX document is a composite struc-
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)
ture containing a set of LaTEX source les (i.e., the Transitions. A transition ring represents the oc-
main le and all the sub-documents) and other les currence of an event taking a negligible amount of
time. Transitions are associated with a guard and an Normal Arc
action. The transition's guard is a predicate on in-
put tokens and is used to determine if there is a tuple
enabling the transition to re. The ring rule describ- Read Only Arc
ing the dynamic behavior of the net states that when
a transition res, tokens satisfying the guard are re-
moved from input places and the transition's action is Overwrite Arc
executed. Consider, for example, transition processing
ok. Its guard and action are given in the following1:
the black transition construct. Every black transition
Event ProcessingOk (ALO, DR; PD) is associated with a non-SLANG executable routine
Guard (e.g., a Unix executable le). When the black tran-
any ALO from Place(ALO) sition \res", the routine is executed asynchronously:
any DR from Place(DR) this means that other transitions in the net may be
such that DR = ok red while the black transition is being executed. This
Action means also that the black transition itself may \re"
PD = ALO many times with dierent input tuples, without wait-
ing for each routine execution to complete. In Fig-
Arcs. Weighted arcs are used to connect places to ure 1, transitions latex, error & reference changes
transitions and vice-versa. The weight indicates the detection and re-process latex are examples of black
number of tokens that may
ow through the arc. It transitions.
can be a statically dened number or it may be dy-
namically computed. In the latter case, the arc weight
is known only at run-time. This is useful to model Human interaction. User requests and user data
events requiring, for example, all tokens that verify are communicated to the SLANG specication by
a certain property. In Figure 1 the begin latex pro- translating them into tokens to be inserted in the cor-
cessing transition requires all the tokens contained in responding user interface place (depicted as double
the source text les place representing les that are circled place, e.g., latex request in Figure 1). Any
related to the document to be processed. The corre- communication from a SLANG specication to users
sponding arc is labeled with a \", which means dy-
namic 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
is managed through the activation of specic commu-
nication tools (e.g., e-mail facilities, report generators,
etc.) via the black transition mechanism.
Time notation. Every transition is associated with
transition can read and use token values from the in- a time constraint dening the time interval during
put place in order to evaluate the guard and the action, which an enabled transition may or must re. The
but no token is actually removed or modied. An over- list of SLANG time constraints that can be associated
write arc may connect a transition to a place. When with a transition is shown in Table 1. The meaning is
the transition res, the following atomic sequence of given in term of time intervals. An [;  ] time inter-
actions occurs. First the output place is emptied of all val means that the transition must or may re within
its tokens. Then, the token(s) produced by the ring [;  ] time units from the enabling time.
are inserted in the output place. The overall eect is
that the produced tokens overwrite any previous con- SLANG time notation Time interval
tent of the output place. ASAP must re within [0,1]
ASAP AFTER  must re within [,1]
Black transitions. A software development process MAY BEFORE  may re within [0,]
involves the activation of a large variety of software AFTER  AND
tools. Tool invocation is modeled in SLANG by using MAY BEFORE  may re within [, ]
1 ALO, DR and PD represent tokens taken from places an-
alyzed latex output, detection result and processed documents Table 1: SLANG time notation expressed in term of
respectively. For the sake of simplicity, we assume here that the enabling time intervals.
it is possible to process only one document at a time: we will
remove this constraint later.
Timeout. SLANG oers a timeout construct that sub-documents from the main source document le.
allows a process specier to dene the maximum time Sub-documents may be edited independently. If any
interval between the ring of two transitions, namely errors occurred in the previous LaTEX processing, the
the start-timeout and the end-timeout transitions. whole document (together with the errors list) may be
The end-timeout transition actually species two ac-
tions, 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
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 avail-
able: viewing the actual layout of the formated docu-
ment 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 activ-
ities. These activities have logical dependencies. For
example, editing cannot start until the user request
their logical precedence and, at the same time, sched-
uled to meet some global deadlines. For example we
may have dierent tasks concerning coding and qual-
ity assurance that proceed in parallel and synchronize
by accessing a set of shared resources.
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.
The concept of activity is central for the description Document verication, for example, may be activated
of a software process. In this Section we introduce a by two dierent events: the request for the generation
SLANG construct to support the activity concept. In of a new document and the request for the modica-
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
tion of an existing one. Document verication may
terminate by accepting the request for a new or exist-
ing document or by rejecting it.
Notice that the entire document generation pro-
cess may also be considered as an activity with two
possible starting events (create document and modify
document) and two possible ending events (generated
considering the whole process used to generate a docu-
ment using LaTEX. We assume the existence of a repos-
itory 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.,
document and unsatisable request). During its ac-
tivation, the document generation activity may also
need to access to the set of available documents (to
verify the user request). Figure 2 provides a possi-
ble representation of the document generation activity
book, article, report, etc.) he/she wants to produce denition using SLANG.
(create document). An activity is modeled by a SLANG net by two dis-
The rst step in the production of a document con- tinct sets of events (transitions), namely the starting
sists of verifying the user request. In particular, it and the ending events. An activity starts when one of
has to be veried that the document is available when the events of the starting set occurs and nishes when
a modify document request is issued, or, in case of a one of the events of the ending set occurs. Figure 3 is
create document request, that no document with the a general representation of a SLANG activity.
same name exists. If neither of these conditions is sat- An activity interacts with the rest of the process
ised, the request is not accepted. If necessary, the specication through interface places. They are clas-
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
si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,
 create
document
modify
document
(1) source text files
once more that the output places of the ending event
(2) latex output files
are a subset of output places of the activity.
3.3 Activity denition and invocation
An activity denition includes an interface and an
documents
Document Verification
NotOk
OkNew
OkOld implementation part. The interface is composed of:
 The interface places (i.e., the input, output and
intermediate activity places) together with their
Create
Template Split

types.
(1)
process
req  The starting and ending events of the activity.
edit

 The arcs connecting the input-output places

request

Document Document
to starting-ending events, together with their
weights.
Editing (2) Processing

NoErrors Errors

 The arcs connecting intermediate places to the

view echo activity box. The arcs weight and kind (normal,
read-only or overwrite) may not be specied at
request "errors"

Document
Viewing
end
activity
request
this level.
The implementation part of the activity is a
unsatisfiable documents SLANG net describing how tokens are transformed
between the starting and the ending events. This net
request

Figure 2: SLANG model of \Document Generation" accesses input and output places through starting and
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 tu-
ple from input places of the starting event. Note that
ending transitions respectively, whereas it accesses in-
termediate places through any other transition inter-
nal to the activity. Places internal to the implemen-
tation 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 ac-
tivity implementation of Figure 2 contains four activ-
input places of a starting event are a subset of input ity invocations (i.e., \Document Verication", \Doc-
places of the whole activity. Thus, when an activity ument Editing", \Document Processing", \Document
starts, it may remove tokens only from some of its in- Viewing"). The \Document Processing" activity de-
put places. The activity can remove or insert tokens nition, given in Figure 1, contains no activity invoca-
from/in an intermediate place at any time during its tions.
activation. When the activity nishes, the produced Using the invocation relationship among activities,
tokens are inserted in the output places of the end- it is possible to build a graph in which each node iden-
ing event that caused the ending of the activity. Note ti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 hi-
input places erarchy among activities. We assume that there is
... only one root in the hierarchy, called \root activity".
intermediate
activity

4 SLANG execution model

places

...

output places In a process centered environment, the process

model plays the role of the \code" to be executed to
Figure 3: SLANG activity. control and monitor the process during its enactment.
The execution is performed by a process model inter- SLANG guarantees that an activity cannot termi-
preter that we call SLANG interpreter. nate if it contains active instances of other activity
The dynamic behavior of a SLANG net is dened invocations. Therefore, if an activity instance A inst
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
has invoked other activities a1 , a2, etc., during its ex-
ecution, A will not be enabled to terminate until
inst
the invoked activities a1, or a2 , etc. terminate their
own processing.
The semantics of the activity construct and its be-
user intervention) and res it. The ring removes to- havior can be given in terms of the basic ER net for-
kens from the input places, executes the corresponding malism. As an example, consider the rule concerning
action, and inserts the produced tokens in the output the termination of an activity discussed in the previ-
places. This produces a state change that enables new ous paragraph. To describe the fact that an activity
rings. The procedure is iterated and this yields a r-
ing 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 distribu-
tion, the process description may be concurrently in-
terpreted by several process engines that communicate
instance A cannot terminate if any inner activity is
inst
still active, it is possible to introduce a place counter
in A . Place counter is connected to all the start-
inst
ing 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
inst
input place to every A ending transition, and every
inst
and are synchronized via shared places, as described A 's ending transition is enabled to re only when
inst
in [2]. Each process engine executes a SLANG net the number contained in counter is zero (i.e., there are
fragment. no more active instances \inside" A ).inst

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 inter-
mediate, including possible user interface places) are
shared among the dierent instances that use them.
When one of the transitions corresponding to the
Actually, an activity invocation may be performed
according to two dierent execution modes: asyn-
chronous 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 ac-
tivity is executed by the same process engine that per-
formed the call, i.e., no new process engine is started.
Note that the execution mode is independent from
ending events res, the tokens produced by this ring the activity denition. In fact, two dierent invoca-
are inserted in the corresponding output places and tions of the same activity may be one synchronous
the activity instance is destroyed. This means that and the other asynchronous. The root activity is, by
local places are deallocated and their contents are lost. denition, an asynchronous activity. A process engine
As an example consider once again Figure 2. Place is associated with it when it is activated at system
latex output les is an intermediate place for \Docu-
ment Editing" activity (DE ) and it is local to \Docu-
ment Generation" activity (DG). Let us suppose that
during the execution of an instance DG of the ac-
inst
tivity DG, activity DE is invoked, and thus an in-
stance DE is generated. Therefore, when DE
inst inst
startup.
Consider the high-level algorithm of Figure 4,
describing the execution of an activity (procedure
ExecActiv). The input parameter t of the proce-
dure is a starting transition of activ enabled by
enab tuple. The algorithm chooses at each cy-
nishes, place latex output les and its tokens persist. cle one enabled transition internal to the activity
On the other hand, when DG nishes, place la-
inst (Decide next firing) and res it. The execution
tex output les is destroyed, and all of its tokens are cycle continues until the chosen transition is one of
lost. On the contrary, place documents is an inter- the ending transitions. If the chosen transition is a
mediate place of both \Document Verication" (DV ) starting transition of an inner activity invocation of
and \Document Generation" (DG) activities. When InvActiv, the execution procedure performs a recur-
DV and DG activity instances nish, place documents sive call to ExecActiv. The way the recursive call is
and its tokens persist. executed depends on the activation mode associated
ExecActiv(activ, t, enab_tuple)
5 Related work
while (t not belongs_to ending_set) do
begin
if t belongs_to start(InvActiv)
Many process languages support the concept of ac-
then ExecActiv(InvActiv, t, enab_tuple)
tivity as a structuring construct for the hierarchical
else Fire(t, enab_tuple);
description of process models. A variety of dierent
<t, enab_tuple> := Decide_next_firing;
techniques are used to represent activities [4].
end In GeSEM [7] activities (called tasks) are organized
Fire(tran, enab_tuple); in a hierarchy. A GeSEM activity may be rened in
Deallocate local places; terms of other activities. A simple activity is infor-
mally described with a textual notation. Once cre-
ated, an activity undergoes periods of execution, per-
Figure 4: High-level algorithm for the execution of an formed by developers. The execution may be inter-
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.
leaved with periods of further specication. The dy-
namicity 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 de-
scription language that supports the concept of activ-
ity (called jobs). A transition of the net may represent
Let us describe in some detail the activation mech-
anism of an asynchronous activity. Consider an asyn-
chronous activity instance A executed by a process
inst
engine PE . The A 's implementation contains the
inst
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
invocation of another asynchronous activity a. When
PE , during A 's execution, decides to activate a,
inst
a new a's instance a is created and a new process
inst
engine pe is associated with it. While pe executes
a , PE continues executing A ; i.e., PE ana-
inst inst
lyzes A 's implementation and decides whether to
inst
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
re transitions or activate activities internal to A . inst a code, much like our asynchronous SLANG activi-
PE can possibly decide to activate a again, if a is en- ties. ProcEntities, instead, are passive elements like
abled to start. In this case, a new instance a of a
0
inst an asynchronous SLANG activity, that have to be ex-
is created, and a new process engine pe is associated
0
ecuted by some embedding task. Finally tools cor-
with it. respond to executable programs (such as compiler,
Notice that black transitions (as dened in Sec-
tion 2) may be viewed as a special case of asyn-
chronous activities where:
- There is only one starting transition and one end-
ing transition.
- The \black transition" activity implementation is
given in non-SLANG code. Thus, the process en-
gine 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 as-
sociated with the black transition is a Unix shell
script, the tool would be the Unix shell inter-
preter.
editor, text processors, etc.). High-level process ele-
ments can be statically decomposed into simpler sub-
elements through the subtyping mechanism. Process
elements can be dynamically changed through the ver-
sioning mechanism. However, there is a lack of seman-
tic 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 activi-
ties can be grouped together under a role (e.g., project
manager). Both approaches lack an adequate hierar-
chical 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
terpretative mechanisms to support dynamic process
evolution.
The SLANG constructs and mechanisms intro-
duced in this paper provide great expressive power
and
exibility for the denition and enaction of pro-
concept, and on the mechanisms supporting the exe-
cution 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 pro-
cess model and allow ecient execution by means of
multiple process engines.
cess models. It is also possible to analyze the process,
basically by simulating its execution and then observ-
ing 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 ac-
tivities are executed in parallel instead of sequentially.
We believe that these features are an important Other ways of process verication, based on reachabil-
starting point to support two fundamental issues in ity and deadlock analysis are undecidable for a general
the process modeling area, that are the main goals of SLANG specication. However, it is always possible
our current research eort: incremental denition and to perform these kind of analysis in a simplied pro-
dynamic evolution of a process model. cess specication or for limited special cases.2
Many researchers have pointed out that it must be The goals of our current work are summarized in
possible to dene software process models by progres- the following points:
sively rening and enriching a initial core model, sup-
porting only a portion of the process. Moreover, a  To develop a rst prototype of the SLANG pro-
software process changes in order to re
ect the evolu- cess engine, supporting concurrent execution of
tion of the organization, the reaction to new facts that SLANG activities and based on a central, ob-
are not anticipated in the model, or the introduction ject oriented database. We have started this task
of new technologies and methodologies. It is therefore in the rst half of 1992, using C++ and the
mandatory to provide functionalities to dene and ap-
ply 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
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 invo-
cation.
supporting the modication of a process model frag-
ment without stopping the rest of the process, and the  To develop a SLANG specication of a large, test-
ability to (re)start new or modied process model frag- case process.
ments as soon as they become available. Moreover, the
(meta)process used to carried out such modications  To integrate such process model in order to deal
must be denable and managed as any other part of with the modication and incremental denition
the process: this means that a process language must of the process model itself.
provide powerful mechanisms to manipulate a process  To enrich the process engine functionalities, in or-
model as part of the model itself. der to support the distribution and/or replication
In SLANG, we have identied a few basic mech- of activities on a network of workstations.
anisms 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. Ba-
sically, the dynamic creation of process engines allows Acknowledgements
us to incrementally enact dierent parts of a process
model. Moreover, black transitions enable to us to We are grateful to Carlo Ghezzi, who is in charge
model metaprocess tasks such as the modication of of the scientic supervision of the SPADE project, for
activities using a specialized editor. This is possi- his valuable comments and suggestions. We wish to
ble since a SLANG specication is stored as a collec- thank also Fabrizio Ferrandina for his assessment and
tion of activities that may be accessed and changed as prototyping work on object-oriented databases within
any other process data. An activity denition is not the SPADE project.
statically bound to its invocation. Instead, it is dy- 2 Most Petri net analysis algorithms have high costs in terms
namically made available to the process engine at the of computational complexity and thus, in practice, they may be
beginning of its execution. This provides a basic in- 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 Soft-
ware Process Technology, Trondheim, Norway,
September 1992.
[3] N.S. Barghouti, G.E. Kaiser, \Scaling Up Rule-
Based Software Development Environments", in
Proc. of 3rd. European Software Engineering
Conference, Milan, Italy, October 1991.
[4] M. Dowson, B. Nejmeh, W. Riddle. \Fundamen-
tal Software Process Concepts", in Proc. of First
European Workshop on Software Process Model-
ing Milan, Italy, May 1991.
[5] C. Ghezzi, D. Mandrioli, S. Morasca, M. Pezze,
[11] F. Oquendo, J. Zucker, P. Griths, \The MASP
approach to Software Process Description In-
stantiation and Enaction" First European Work-
shop on Software Process Modeling Milan, Italy,
May 1991.
[12] B. Peuschel, W. Schaefer, \Ecient Execu-
tion of Rule Based Persistent Software Process
Models in MERLIN", in Proc. of 14th. Inter-
national Conference on Software Engineering,
Merlbourne, Australia, 1992.
[13] S. Sutton, D. Heimbigner, L. Osterweil, \Lan-
guage Constructs for Managing Change in
Process-Centered Environments", Proceedings
of the 4th. ACM SIGSOFT Symposium on Soft-
ware Development Environments, Irvine, Cali-
fornia, December 1990.
[14] W.F. Tichy, \Programming in-the-Large: Past,
Present, and Future", in Proc. of 4th. Interna-
tional Conference on Software Engineering and
Knowledge Engineering, Capri, Italy, 1992.
\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 Soft-
ware Process Models", Ph. D. Thesis, Dortmund
University, 1991.
[7] G. Hulin, M. Lacroix, D.Roelants and M. Van-
hoedenaghe, \Integrated Product and Process
Modelling", in Proc. of First European Work-
shop on Software Process Modeling, Milan, Italy,
May 1991.
[8] H. Hunnekens, G. Junkermann, B.Peuschel, W.
Schafer, J. Vagts, \A Step Towards Knowledge-
based Software Process Modeling", in Proc. of
First Conference on System Development Envi-
ronments 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 Eu-
ropean Workshop on Software Process Modeling
Milan, Italy, May 1991.