See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2778439

SPADE: An Environment for Software Process Analysis, Design and Enactment

Article · November 1994

Source: CiteSeer

CITATIONS READS
9 395

5 authors, including:

Alfonso Fuggetta Carlo Ghezzi

Politecnico di Milano Politecnico di Milano
109 PUBLICATIONS 6,282 CITATIONS 366 PUBLICATIONS 10,987 CITATIONS

SEE PROFILE SEE PROFILE

Luigi Lavazza
University of Insubria
214 PUBLICATIONS 2,939 CITATIONS

SEE PROFILE

All content following this page was uploaded by Luigi Lavazza on 05 December 2013.

The user has requested enhancement of the downloaded file.

 SPADE: An Environment for Software Process
Analysis, Design and Enactment

Sergio Bandinelli, Alfonso Fuggetta, Carlo Ghezzi, Luigi Lavazza

CEFRIEL { Politecnico di Milano

GOODSTEP ESPRIT-III project No. 6115

GOODSTEP Technical Report No. 020

March, 1994
Abstract
The SPADE project aims at developing an environment to de ne, analyze, and execute process models
de ned in the SLANG process modeling language. This paper presents SLANG through a case-study
and highlights the main features of the rst prototype implementation of the SPADE concept, called
SPADE-1. It illustrates the facilities provided by SLANG to support process evolution and shows how
the SPADE-1 architecture supports integration of the process interpreter with external tools available
in the environment.
 SPADE:
An Environment for Software Process Analysis,
Design, and Enactment
Sergio Bandinelli ? y Alfonso Fuggetta?
Carlo Ghezzi Luigi Lavazza ?
 Dip. di Elettronica e Informazione ? CEFRIEL

Politecnico di Milano Politecnico di Milano

Piazza Leonardo da Vinci, 32 Via Emanueli, 15
I-20133 Milano I-20126 Milano
Fax: +39-2-23993587 Fax: +39-2-66100448
e-mail: ffuggetta, ghezzig@ipmel2.elet.polimi.it
flavazza, bandinellig@mailer.cefriel.it

Abstract
The SPADE project aims at de ning and developing a software process-
centered environment to describe, analyze, and enact software process
models. These models are speci ed in SLANG (Spade LANGuage),
a process modeling language that provides process speci c modeling
facilities. This paper presents SLANG through a case study which
illustrates SLANG main features, including process modularization,
interaction with tools, and process evolution. In addition, it describes
the architecture of the rst implementation of SPADE, called SPADE-
1, showing how the environment supports concurrent enaction of pro-
cess activities, integration of external tools, and storage of persistent
data in an object-oriented database.
Keywords and phrases: software process, process-centered environ-
ment, computer-supported cooperative work, process language, Petri
net, object-oriented database.
 This work has been partially supported by ESPRIT projects GoodStep and Promoter,
and by Progetto Finalizzato Sistemi Informatici e Calcolo Parallelo
y Sergio Bandinelli is partially supported by Digital Software Engineering Center, Gal-
larate, Italy

1
1 Introduction
Software production is accomplished through a set of activities that are
concurrently carried out by interacting agents. Agents cooperate to develop
software applications, support their evolution, deliver new releases, produce
and maintain reusable components, etc. These activities are performed by
managers, software designers, programmers, end-users, etc. with di erent
backgrounds, roles, objectives, and views of the process. The software pro-
cess is the common framework within which these people interact. Despite
its importance, however, the process is usually left implicit, incomplete, or
ambiguous and little or no attention is paid to make it clearly understood
by the people involved in software development activities.
By providing an explicit process description, aws in the process can be
found and corrected. Communication and cooperation can also be improved,
resulting in an overall improvement of the process e ectiveness. In addition,
if a formal operational notation is used for modeling, it is also possible to
automate (parts of) the process, to support interaction and cooperation
among people, and to provide them with guidance during enactment.
The SPADE project [BFGG92, BFG93b, BF93] aims at designing and
developing a process-centered software engineering environment. The project
is carried out at Poliecnico di Milano and CEFRIEL and its ultimate goal
is to provide a software engineering environment to support Software Pro-
cess Analysis Design and Enactment. The environment is based on a process
modeling language, called SLANG (SPADE Language), which is a high-level
Petri net based formalism1 . SLANG o ers features for process modeling,
enaction, and evolution. In addition, it describes interaction with exter-
nal tools and humans in a uniform manner. The main features of SLANG
modeling facilities can be summarized as follows:
 Process models can be structured in a modular way using the activ-
ity construct. Activities (i.e., process fragments) can be dynamically
instantiated.
 Activities can be manipulated as data by other activities; i.e., SLANG
supports computational re ection.
 Process artifacts, including process models, are kept and maintained
in an object-oriented database.
1
We assume here that the reader knows the basic concepts of Petri nets and of high-level
nets. For a general background, the reader can refer to [Rei85]

2
 It has been a deliberate decision in the design of SLANG to provide the
necessary mechanisms for process modeling, without freezing any process-
speci c policy in the language. The result is the structuring of the language
de nition in two levels. Kernel SLANG is a low-level and very powerful
formal notation, which provides the basic constructs and mechanisms for
process modeling. Kernel SLANG is thus a minimum set on top of which
new process speci c constructs may be de ned (by giving semantics in terms
of primitive SLANG cosntructs) and incorporated to the language. The
language augmented with these new constructs is called Full SLANG (or
SLANG).
A rst implementation of the SPADE environment, called SPADE-1,
has been completed by mid 1993. SPADE-1 includes a process interpreter,
which is able to enact process models written in SLANG. The environment
architecture is based on the principle of separation of concerns between
process model enactment and user interaction. The process enactment en-
vironment includes facilities to execute a SLANG speci cation, by creating
and modifying process artifacts. The user interaction environment manages
the interaction between users and tools in the environment. It is based on an
enhanced version of DEC FUSE [DEC92]2 . Software artifacts manipulated
during process enactment are stored in a central repository managed by the
O2 object-oriented DBMS [Tec92]. Tools in the user environment may also
access the database and share data among them and with the process.
This paper is an overview of the SPADE Project. It provides a guided
tour through SLANG and presents the mechanisms needed for process enact-
ment, and the main features of SPADE-1 architecture. Section 2 gives a brief
assessment of existing approaches to process modeling and puts SPADE in
the context of current e orts. Section 3 presents the case-study that is used
through the paper as a running example. Section 4 introduces basic con-
structs of SLANG, which constitute Kernel SLANG. Section 5 de nes Full
SLANG process-speci c constructs and facilities. Section 6 brie y describes
SPADE-1 architecture. A complete process model of the running example,
using Full SLANG, is presented in Section 7. Section 8 discusses evolution
issues. Finally, Section 9 draws some conclusions and outlines future work.
2
DEC FUSE is a product that provides service-based tool integration. In DEC FUSE,
a tool is viewed as a set of services that can be invoked through a programmatic interface
that de nes a protocol to manage tool cooperation. The protocol is based on a standard
set of messages that are exchanged using a multicast mechanism.

3
2 Related Work
Much research e ort is being carried out in the software process eld, yield-
ing a number of di erent approaches to process representation and execu-
tion. These e orts range from the use of full- edged programming lan-
guages [HSO90] to active database extensions [BEM91] and abstract spec-
i cation formalisms, including Statecharts [Kel91], rule based languages
[PS92, BK91], attribute grammars [SIK93], and Petri nets. An introduc-
tion and comparison of existing approaches can be found in [ABGM92]. A
number of di erent approaches are also described in this volume.
Several process modeling e orts have been based on languages derived
from Petri nets. FUNSOFT nets [Gru91] are based on PrT nets, a class
of high-level Petri nets. PROCESS WEAVER [Fer93], developed by Cap
Gemini Innovation in the context of the Eureka Software Factory project,
provides a set of tools to add process support to UNIX-based environments.
In PROCESS WEAVER a process is described as a hierarchy of activity
types. Each activity is associated with a procedure that speci es how the
activity is carried out. Procedures are described by transition nets, a data-
ow notation similar to Petri nets.
A software process can be viewed as a set of interacting software en-
gineering activities that are carried out in parallel by multiple cooperating
agents and must be scheduled in order to meet some global time constraints.
Building on this view and on past research done in the area of formal speci -
cations of real-time systems, SLANG has been formally based on a high-level
timed Petri net formalism, called ER nets [GMMP91].
One of the main concerns in designing SLANG is to o er expressive and
powerful constructs that can be used for process modeling in-the-large. A
SLANG process model can be hierarchically structured as a set of activities,
each described by a net that may include invocations to other (sub)activities.
Another distinguished feature of SPADE/SLANG is the mechanism sup-
porting process evolution. Petri net based process languages have been
criticized because of their inability to support process evolution. SPADE
incorporates re ective mechanisms to support changes to process de nitions
and process states, even while the process is being enacted. The problem of
supporting process evolution is addressed also by other process languages,
such as EPOS [JLC92] and IPSE 2.5 [BPR91], in the context of other for-
malisms.

4
3 A running example
In this paper, SLANG is illustrated through the example proposed for the
6th and 7th International Software Process Workshops [KFF+91]. The ex-
ample deals with the modi cation of a program unit caused by changes in
the global speci cation of a system. For each unit that has to be modi ed a
change unit speci cation is written. The design is changed according to the
new speci cation, and a new design unit together with a new unit interface
is produced.
In general, changes in the implementation of a unit U do not a ect other
units. Changes in the interface of U , instead, need to be agreed upon by the
designer responsible for U and those responsible for all units which \use"
U . Thus, once the new design of U has been completed, the new interface is
proposed to all U 's users, who are asked to either accept the new interface or
to reject it. If no reply is sent back within the given deadline, it is assumed
that there are no objections to changing the unit interface. If any U 's user
rejects the proposed interface, the unit's designer makes a new proposal,
which is in turn reconsidered by all users. This process is iterated until all
U 's users agree on the interface. Only after this condition is satis ed, U 's
coding and generation of test cases for the unit may start.
Coding implies editing the unit and compiling it. Preparation of data for
unit test proceeds in parallel with coding. The unit is then linked together
with drivers and stubs in order to obtain an executable program. The unit
is then run on the test cases one after the other. The errors that may be
discovered in each execution are accumulated in an error report. The test
continues until all test cases have been run. Only if no error is found, the
unit is accepted. Otherwise the unit is rejected and a report is produced
with a list of all the errors found.

4 Kernel SLANG
This section describes the basic constructs and mechanisms for process mod-
eling de ned in Kernel SLANG. It rst presents the Kernel SLANG type
system; and then, Kernel SLANG nets and their interpretation, since Kernel
SLANG is the language understood by the SLANG interpreter

5
4.1 Kernel SLANG type system
Kernel SLANG o ers a rich type system to model the variety of data pro-
duced, used, and manipulated in a software process. These data may be
of very di erent kinds, including, for example, graphical software speci ca-
tions, failure reports, test data, and executable code. The representation
of such information may require complex data structures, containing many
relationships of di erent nature (e.g., abstract syntax trees, program de-
pendency graphs, etc.). In addition, the process model may need to access
data at di erent levels of granularity. For example, it may refer to an entire
system that has to be validated, or to a unit that has to be compiled, or
even to a single procedure that has to be removed.
All process data in Kernel SLANG are typed. Type de nitions follow
an object-oriented style, organized in a type hierarchy, de ned by an \is-a"
relationship. Each type de nes an abstract data type, i.e., a data structure
that may only be accessed by the exported operations. A type de nition
contains the type name (which uniquely identi es the type), the speci cation
of the types from which the type inherits, the list of attributes, and the list
of operations to access instances of the type3 .
Kernel SLANG o ers a built-in set of basic types, including integer,
real, char, string, boolean, text, bitmap, etc. Types may be combined
using the type constructors tuple, set, list, etc.. The attribute list is in
fact a tuple that de nes the structure of the type. The structure can be
made arbitrarily complex by combining basic types and other user-de ned
types via type constructors.
Being Kernel SLANG process models based on a high-level Petri net
notation, process data are represented by tokens. Each token is a typed
object, upon which it is possible to apply the operations de ned in its type
description or inherited from its super types. The SPADE type hierarchy
provides a prede ned type Token. All tokens in a Kernel SLANG process
model are of type Token, or of one of its subtypes. Process speci c user-
de ned types, which characterize the particular process being modeled, are
represented by a subtree of Token in the \is-a" hierarchy rooted ModelType.
Example: Type de nitions. Figure 1 shows the \is-a" type hierarchy
for some of the types used in the case-study. The textual type de nitions
are given in Figure 2. Type Unit represents a general source code unit.
3
SLANG type de nitions correspond to O2 classes.

6
 Token

ModelType

Unit TestCase TestResult TestSummary UnitInterface Change

SpecDoc

ExecUnit

ExecTest

Figure 1: Type hierarchy for some of the types of the running example.

ExecUnit de nes executable units (i.e., a unit that has been compiled and
linked with drivers and stubs). TestCase de nes test cases for unit testing.
The information needed to apply a test case to a unit is described by the
type de nition ExecTest. Test results are described by TestResult and
the complete report of a series of tests is described by TestSummary. Type
de nitions may also include operations on the de ned data (in this example
operations have been omitted for simplicity).
4.2 Kernel SLANG nets
This section provides the de nition of Kernel SLANG nets and the interpre-
tation algorithm used to execute them. A Kernel SLANG net SN is de ned
as a triple:
SN = (P; T; A)
P is the set of places, T is the set of transitions, and A  (P  T ) [ (T  P )
is the set of arcs. The standard notation used in Petri net literature will be
followed. In particular,  t denotes the preset of transition t (the set of input
places of t) and t denotes the postset of t (the set of output places of t). A
Kernel SLANG net satis es the following properties:
P 6= ;; T 6= ;; A 6= ;
8t 2 T; t 6= ;; t 6= ;
7
class Unit inherit ModelType
type tuple (public name: unitName,
public authorName: personName
public language: string,
public sourceCode: Text)
end;
----------------------------------------------
class ExecUnit inherit Unit
type tuple (public compilerUsed: string,
public execCodePath: pathName)
end;
----------------------------------------------
class TestCase inherit ModelType
type tuple (public name: unitName,
public testData: Text)
end;
----------------------------------------------
class ExecTest inherit ExecUnit, TestCase
end;
----------------------------------------------
class TestResult inherit ModelType
type tuple (public usedTest: moduleName,
public failures: list (Failure))
end;
----------------------------------------------
class TestSummary inherit ModelType
type tuple (public testingUnit: unitName,
public results: set (TestResult),
public pendingTestsNb: integer)
end;

Figure 2: Type de nitions of some of the types of the running example.

8
Places. Each place has a name and a type. A place is a token repository
that may only contain tokens of its type or of any subtypes. Contents of
places change through transition rings. The only exceptions to this rule are
user places, which are a special kind of places that change their contents as
a consequence of an event occurring in the user environment. They are used
to communicate external events caused by humans or tools to the system.
While normal places are graphically represented by a single circle, user places
are represented by double circles. The type of a place must be Token, or
one of its subtypes.
Transitions. Transitions represent events whose occurrence takes a neg-
ligible amount of time. Each transition is associated with a guard and an
action. The guard is a predicate on tokens belonging to the transition's
input places. The action speci es how the output token tuple is computed
as a function of the input token tuple. Black transitions are a special kind
of transitions in which the action part includes the asynchronous invocation
of a non-SLANG executable routine (e.g., a Unix executable le).
Arcs. Arcs are weighted (the default weight being 1). The weight indicates
the number of tokens owing along the arc at each transition ring: it can
be a statically de ned number or it may be dynamically computed (this is
indicated by a \*"). In the latter case, the weight is known only at run-
time and may vary at each ring occurrence. This is useful to model events
requiring, for example, all tokens that satisfy a certain requirement.
An active copy of a Kernel SLANG net SN is a net de nition associated
with a state. The net state is given by a marking, i.e., an assignment of
tokens to places.
An active copy can be executed by a tool, called the SLANG interpreter.
The SLANG interpreter works in the following way. Starting from an ini-
tial state, it evaluates the guards associated with the transitions to check
whether an input tuple of tokens enables the transition. Then, one enabled
transition is chosen (automatically or with user intervention) and it is red.
The ring of a transition t is accomplished by removing the enabling input
tuple from  t, executing t's action and, as a result, producing an output
tuple to be inserted into t . The number of tokens removed and inserted de-
pends on the weight of the corresponding arc. Transition ring is an atomic
action, i.e., no intermediate state of the ring is made visible to the outside
(i.e., to other process engines).

9
 The ring of a black transition represents the invocation of an external
tool. The tool is executed asynchronously. This means that other transitions
may be red while the tool associated with the black transition is still being
executed. It is also possible to re the same black transition many times
with di erent input tuples, without waiting for each activation to complete.
The occurrence of an event (transition ring) produces a state change
that may enable new rings and/or disable previously enabled rings. The
execution cycle is then repeated and produces a ring sequence, which rep-
resents the execution history of the net.
4.3 Kernel SLANG example
The Kernel SLANG model of the test phase example (originally presented
in [BFG93a]) is shown in Figure 3. The Kernel SLANG net shows that
an executable unit and test cases for that unit must be available to start
testing. All of the test cases developed for the unit must be run (this is
represented by the label \*" on the arc from Test cases to Start test).
Test cases are then taken one at a time and executed. This is represented
by the black transition Execute test. The test results obtained in place
Test results are then added to the results in Cumulative test results.
When there are no more pending tests, All tests cases run res and the
test phase for that unit is completed.
With reference to the type de nitions of Figure 2, in the Kernel SLANG
net of Figure 3, place Exec unit has type ExecUnit, place Test cases
has type TestCase, Data for test execution and Executable test have
type ExecTest, Test results being computed has type TestResult, and
nally places Cumulative test results and Test results summary have
type TestSummary.
Each of the transitions of the example has a guard and an action at-
tached. Figure 4 describes the guard and action code associated with events
Prepare test, All test cases run, and Start test. Variable names in
capital letters (corresponding to the initials of place names) are used to rep-
resent both the tokens that are removed from input places and the tokens
that are inserted in output places when a transition res. The type of these
variables coincides with the corresponding place type, except for places that
are connected with a \*" arc. In this latter case, the variables are of type
\set", since the number of tokens that may be removed/inserted may be
greater than one. For example, transition Start test removes from place
Test cases all tokens representing the test cases that refer to a given unit.

10
For each event, input variables are separated from output variables by a
semicolon. Some prede ned self-explaining operations on sets are used in
the example.

5 Full SLANG
Kernel SLANG is the language executed by the SLANG interpreter. With
respect to such kernel language,
Full SLANG introduces a set of prede ned types to support process
evolution (as explained in Section 8) and new constructs that do not modify
the semantic power of the language, but provide a set of shorthand notations
to improve the language usability4 .
A Full SLANG process model is a pair of sets:
SLANGModel = (ProcessTypes, ProcessActivities)
where ProcessTypes is a set of type de nitions and ProcessActivities is a set
of activity de nitions.
Type de nitions are given using the Kernel SLANG type system de-
scribed in Section 4.1. The Process Types set includes user de ned process
speci c type de nitions. In order to support process evolution it also in-
cludes a number of prede ned type de nitions that become part of Full
SLANG. The reasons for this are clari ed later on in this section.
Activities are Kernel SLANG nets that encapsulate a set of logically
related process operations. Each activity de nition has an interface part
and an implementation part. The activity interface contains a set of starting
events, and a set of ending events. When one of the starting events occurs,
an active copy of the activity is dynamically instantiated and its execution
starts. Eventually, if the activity is well designed, one of the ending events
occurs and the active copy execution terminates. The activity interface also
contains a set of input places, that are the preset of starting events; a set
of output places, that are the postset of ending events; and a set of shared
places, that are connected directly to non-interface transitions.
An activity may include invocations of other activities. A Full SLANG
process model is thus structured as a hierarchy of activities. This hierarchy
has a unique root, which is a sort of \main activity" of the model. The
root activity is not called by other activities and is automatically activated
4
In the following, when it is clear from the context, we write only SLANG to refer to
Full SLANG.

11
 Exec unit Test cases
(EU) (TC)
*

Start test
*
Cumulative
Data for test results
test execution (CTR)
(DFTE)
Prepare
test

Executable
test (ET)
All test
cases run
Test results
Execute being
test computed
(TRBC)
Test
results

Add test
result

Test results
summary
(TRS)

Test not ok Test ok

Unit with Tested

errors unit

Figure 3: Test phase model using Kernel SLANG.

12
event StartTest (EU: ExecUnit, TC: set (TestCase);
DFTE: set (ExecTest), CTR: TestSummary)
local test: TestCase, data: ExecTest;
guard
forall test in TC: test->name = EM->name
action {
DFTE = set();
for (test in TC) {
data = new ExecTest;
data->name = EU->name;
data->authorName = EU->authorName;
data->sourceCode = EU->sourceCode;
data->compilerUsed = EU->compilerUsed;
data->execCodePath = EU->execCodePath;
data->testData = test->testData;
DFTE = DFTE + set(data);
}
CTR->testingUnit = EU->name;
CTR->results = set();
CTR->pendingTestsNb = count(TC)
}
end
----------------------------------------------
event PrepareTest (DFTE: ExecTest, CTR: TestSummary;
ET: ExecTest, TRBC TestSummary)
guard
CTR->pendingTestsNb > 0
action {
ET = DFTE;
TRBC->testingUnit = CTR->testingUnit;
TRBC->results = CTR->results;
TRBC->pendingTestsNb = CTR->pendingTestsNb - 1
}
end
----------------------------------------------
event AllTestCasesRun (CTR: TestSummary; TRS: TestSummary)
guard
CTR->pendingTestsNb == 0
action {
TRS = CTR
}
13
end

Figure 4: Guards and actions for events Start test, Prepare test, and
All test cases run.
 ProcessData

Place Token Arc Transition

Activity MetaType Active Copy Type ModelType SLANG Types

User-defined Types

Unit TestCase TestResult TestSummary UnitInterface Change

SpecDoc

ExecUnit

ExecTest

Figure 5: SLANG type hierarchy, including prede ned SLANG types and
user de ned ones.
when the model is enacted. By using the activity construct, a process model
can be viewed at di erent levels of abstractions. At each level, unnecessary
details are hidden, so that the complexity of the process can be mastered. In
addition, de ning activities facilitates the reuse of process model fragments
in di erent contexts.
The term \meta-process" is generally used to denote the process of
changing a process model. To support modeling of the meta-process, pro-
cess types must not only describe the data manipulated by the process, but
also process models (i.e., data manipulated by the meta-processes). In or-
der to support process evolution, SLANG provides re ective features that
allow the process modeler to view and manipulate type de nitions, activity
de nitions and active copies as any other data in the model, i.e., as tokens.
This is achieved in SLANG by providing types Activity, Metatype, and
ActiveCopy as subtypes of type Token in the ProcessTypes set, that respec-
tively describe activity de nitions, type de nitions, and active copies. All
these types are part of the hierarchy shown in Figure 5.

14
5.1 Full SLANG constructs
Full SLANG provides all Kernel SLANG constructs; in addition, it pro-
vides special features (special arcs and activity invocation, see below) whose
semantics can be described using Kernel SLANG's basic constructs.
5.1.1 Special arcs
Besides \normal" arcs, Full SLANG provides two other special kinds of
arcs: read-only (represented by a dashed line) and overwrite (represented
by a double arrow). A transition can read token values from an input place
connected by a read-only arc in order to evaluate the guard and the action,
but no token is actually removed. On the other hand, when an overwrite arc
is used to connect a transition to an output place, the transition ring causes
the following atomic sequence of actions. First, all tokens are removed from
the output place; then the token(s) produced by the ring are inserted in
the output place. The overall e ect is that the produced tokens overwrite
any previous contents of the output place.
5.2 Activity invocation
In Kernel SLANG, the process is described as a at net. In order to model
large processes, in Full SLANG it is possible to structure the process model
as a hierarchy of activities. The execution of an activity may be invoked by
another activity. An activity invocation basically consists of the invocation
of the SLANG interpreter on the called activity. The SLANG interpreter is
a tool and thus its invocation is modeled in Kernel SLANG by a black tran-
sition. Activities are executed asynchronously. When an activity invocation
has to be executed, the calling activity spawns a new process engine to enact
the called activity. That is, the child active copy runs concurrently with its
parent, and with other sibling active copies. These active copies can share
places, that are used for communication and synchronization purposes.
Full SLANG provides an activity invocation construct that involves a
series of actions that have to be done when an activity is invoked. This con-
struct is designed as a box that hides the activity implementation, showing
only its interface. In the following we provide some hints on the implemen-
tation (in Kernel SLANG) of the activity invocation construct and discuss
its bene ts. For a thorough explanation the reader is referred to [BFG93a].
Suppose that activity A contains an invocation of activity B . Figure 6
shows how the activity call is expanded in a Kernel SLANG net, obtaining

15
the following behavior when activity B is invoked from a A's active copy.
 An active copy of the activity B is created.
 A process engine for the new active copy of B is spawned. This
operation is accomplished by means of a black transition that asyn-
chronously executes the SLANG interpreter on B 's active copy.
 When B terminates (i.e., when an ending event res) the process en-
gine stops, yielding a result in the output place of the black transition
in A's implementation part. This result is then stored in the corre-
sponding places of the calling activity A.
Let us emphasize some important aspects of the above execution scheme:
 An activity invocation is dynamically bound to the corresponding ac-
tivity de nition (and to the types used within such de nition). This
interpretive mechanism supports late binding and provides the basis
for our solution to process evolution, as discussed in Section 8.
 The execution of an activity de nition is carried out through a black
transition invoking the SLANG Interpreter tool. That is, the mecha-
nism used by the language to invoke the interpreter is the same used
to invoke any other tool.
 Activities are executed asynchronously, i.e., the calling active copy
continues executing while the newly created active copy is enacted by
a process engine.
 The process engines executing di erent active copies may access shared
places and the output places belonging to the parent activity. Con-
sequently, process engines must be synchronized in order to discipline
access to shared and output places in mutual exclusion.
An activity can terminate execution if all invoked (sub)activities have
already terminated. SLANG guarantees that the ending transitions of an
activity are not enabled as long as all the (sub)activities that have been
spawned are still active5 .
5
This feature is reminiscent of Ada's tasking. It does not require a semantic extension;
it may be implemented in Kernel SLANG by adding a counter place that holds information
on the number of spawned active copies that are still running. This place is in input to
each ending event.

16
 Starting Activities
Events

Start Types
State
Create
Starting Active
Events Copy
Active Copy
To Execute
B
Ending SLANG
Events Interpreter

End
State

Ending
(a) Events

(b)

Figure 6: (a) Invocation of activity B within activity A; (b) corresponding

series of steps in Kernel SLANG.

17
6 SPADE architecture
This section describes the architecture of the rst prototype based on the
SPADE concept, called SPADE-1. For a detailed description the reader can
refer to [BBFL94]. The design of SPADE-1 is centered on the principle of
separation of concerns between process model interpretation and user inter-
action. Following this principle, the architecture of SPADE-1 is structured
in three main components: the user interaction environment, the process
enactment environment, and the lter, as shown in Figure 7:
 The user interaction environment is responsible for performing the
interaction with users through tools in the environment.
 The process enactment environment is responsible for executing the
process model. The execution is concurrently performed by a set of
process engines that are dynamically created during enactment.
 The lter performs the communication between these two environ-
ments.
SPADE-1 supports multiple users distributed in a network of worksta-
tions. Each user interacts with the process through a set of integrated tools.
Two classes of tools may be distinguished: black-box tools and structured
tools. Black-box tools are viewed by the process engines as functions per-
formed on some input and producing some output. The process has no
control on the tool while it is working. A structured tool, instead, is de-
composed into fragments that are visible through a programmatic interface.
This makes it possible to achieve a ne-grained tool integration in the pro-
cess model.
The interaction with tools and users is modeled in SLANG through black
transitions and user places. Black transitions represent the asynchronous
execution of a tool. For example, they may model the execution of a C
compiler, or of a \send message" tool, that sends a message to a structured
tool (e.g., ask an editor to open a le).
User places are used to capture relevant events that may occur in the
external environment. These events | generated by the users by using, for
example, a tool in the environment | are captured and transformed into
tokens stored in user places. Depending on how the process is modeled, the
presence of the token may produce the ring of one or more transitions in
the net.

18
USER INTERACTION ENVIRONMENT

tool1 tool2 tooln tool1 tool2 tooln

FUSE MSG Server FUSE MSG Server

USER_1 USER_n

FILTER

SPADE Communication Interface

PEroot PE1 PEn

O2Client O2Client O2Client

O2Server

OODB

PROCESS ENACTMENT ENVIRONMENT

Figure 7: SPADE architecture.

19
 The user interaction environment of SPADE-1 is based on a commer-
cially available tool integrated environment, called DEC FUSE [DEC92].
DEC FUSE provides a set of structured tools to support basic development
activities (editing, compiling, con guration building, etc.) In addition, DEC
FUSE o ers a utility, called EnCASE, to integrate new tools in the environ-
ment.
For data storage and management, SPADE-1 relies on the O2 object-
oriented database system [Tec92]. O2 has a client-server architecture and
provides a programmatic interface that is suitable to support SPADE evo-
lution features. Each process engine is a client of the centralized object-
oriented database server.

7 An example using Full SLANG

This section presents a SLANG process model for the running example of
Section 3. Figure 8 represents a high-level view of the whole example. The
part inside the dashed box corresponds to the implementation of activity
Change unit, while places and transitions outside the dashed box represent
the activity interface.
 Design change represents the production of a new design for the unit,
according to the given speci cations. It produces a new unit design
and a unit interface de nition.
 Propose interface change represents the activity of proposing the
unit interface to unit users for approval. It is invoked only if the unit
interface has been modi ed. Otherwise, the unit interface is considered
to be automatically approved by transition Interface not new. Note
that a copy of the interface de nition is also produced as input to the
test case generation.
 Unit coding, Compile, Generate test cases, and Run tests rep-
resent the usual activities of converting design into code, compiling,
generating test cases and testing. In particular the testing activity
de nition is given by the Kernel SLANG net described in Figure 3.
Figure 9 represents activity Propose interface change de nition. This
activity has one starting event, represented by transition Produce interface
change proposal, which is enabled as soon as the modi ed unit interface is
available in place Unit interface. The ring of this transition produces a
20
 Change
specification

Start change

Change
spec. doc.

Design Unit
change dependency
Unit
interface

New
design Interface
not new Propose
Unit interface change
repository
Approved
interface
Interface
Unit coding
for test

Unit with
errors Generate
Coded test cases
unit

Exec Test
unit
Compile cases

Run tests

Tested
unit
Change unit

End change

New
unit

Figure 8: The SLANG de nition of activity Change unit.

21
 Unit Unit
interface dependency

Produce interface
change proposal

*
Proposal
Interface change
approval proposal
document
Add item
to agenda
Item in Item
Item agenda selected
* added
Remake
proposal
Evaluate new
Remove item interface
after deadline

*
* Response
to proposal Propose
interface change
Produce
approved interface

Interface Approved
for test interface

Figure 9: The SLANG de nition of activity Propose interface change.

token containing the proposal description and the list and number of clients
that are expected to approve the proposal in place Proposal approval
document. It also produces in place Interface change proposal as many
tokens as there are users of the unit (since this number is not known stati-
cally, a dynamically weighted arc is used). Each of these tokens represents
an interface proposal document that is submitted to each of the unit users.
The rest of the activity is based on the assumption that the participants
in the process interact with the process interpreter through a tool called
agenda. This is a service level integrated tool that manages a to-do list that
is displayed on the screen. The tool provides two main services:
 Add item inserts a given task description (passed as a parameter) into
the to-do list.

22
  Remove item removes a given task description (passed as a parameter)
from the to-do list.
In addition, the agenda tool produces state change noti cations when some
relevant event occurs:
 Item selected produced each time an item is selected by a user from
the to-do list.
 Item in agenda produced each time an item has been inserted in the
to-do list.
Black transition Add item to agenda represents the execution of a tool
that invokes the agenda service Add item with parameter \Examine inter-
face change proposal". This transition res once for each token in Interface
change proposal and each ring causes a new task to be inserted in the cor-
responding user's agenda. As soon as the service has been invoked, the black
transition execution terminates producing a token in place Item added. Af-
ter the task has been e ectively inserted in the agenda, the tool reports this
fact and a token is inserted in the user place Item in agenda.
When a user selects such task from the list displayed in his/her agenda,
a token is produced in the user place Item selected. Such a token en-
ables activity Evaluate new interface. An instance of such activity is
created for each user of the changed interface: its task is to communicate
the proposal to the unit clients and collect the responses (either acceptance
or motivated reject).
At this point of enactment, we have an active copy of Change unit,
an active copy of Propose interface change, and as many active copies
of Evaluate new interface as the number of interface clients, running in
parallel.
Answers from the users are accumulated in Response to proposal, un-
til their number equals the number of users stored in the place Proposal
approval document. In such a case there are two possibilities:

1. All the answers indicate acceptance: the ending event Produce approved
interface is enabled.

2. There is at least one reject and thus activity Remake proposal is en-
abled. Such activity is concerned with the revision of the new interface
based on the comments of the users. It is performed by the designer
who is responsible for the unit interface and produces the same outputs
as the starting event.

23
8 Process evolution in SPADE
Processes are by no means static entities. Since processes are long lived
entities, they must be allowed to evolve, even during enactment, in order
to cope with a variety of change requests. Changes may arise, for example,
because better ways are found for doing things, because of restructuring in
the organization, or because of technological improvements.
Process evolution is a process too, and thus it can be modeled and en-
acted as any other process. SLANG provides re ective language features
which allow process models to be treated as process data and thus pro-
cess evolution can be described as part of the process. In particular, type
descriptions, activity de nitions and active copies are tokens in a SLANG
net, of type Metatype, Activity, and ActiveCopy, respectively. In this
scheme, process models and process states can be accessed both as code to
be executed and as data to be modi ed (i.e., as regular tokens).
For example suppose that while activity Propose interface change of
Figure 9 is being enacted, a new client decides to use the unit whose interface
is being discussed. According to the speci ed process, the new client would
ignore that the interface is currently being discussed, and would not be
asked to approve or reject the proposed change. To overcome this problem,
we would like to rede ne activity Propose interface change as illustrated
in Figure 10. In the new de nition the ending event Produce approved
interface and the starting event of activity Remake proposal are enabled
only if the list of users recorded in the Proposal approval document cor-
responds to the current list of users (deduced from Unit dependency). If
the lists di er, the approved interface is suspended until the new user also
approves it. This is accomplished by transition Make proposal for new
user, that compares the present list of users of the unit, taken from Unit
dependency with the list of users that was copied in place Read depend and
last check time when the Produce interface change proposal activ-
ity was initiated. If there are new users, they are also sent the interface
proposal, in place Interface change proposal, and the counter in the
Proposal approval document is incremented. If there are no new users,
the activity ends with an ending event Produce approved interface, that
produces the approved interface token in places Approved interface and
Interface for test.
All activity de nitions in a SLANG process model are contained in a
place called Activities (of type Activity) and all type descriptors, in a
place called Types (of type Metatype). We assume that the new de nition of

24
 Unit Unit
interface dependency

Produce interface
change proposal

* *
Proposal Interface change
approval proposal
document Add item
to agenda
Read depend. and
last check time
Item in
Item agenda
* added Item
Remake selected
proposal
Evaluate new
Remove item interface
after deadline
Response
Make proposal to proposal
for new user *
*

Propose
interface change
Unit Produce
dependency approved interface

Interface Approved
for test interface

Figure 10: A new de nition of activity Propose interface change.

activity Propose Interface Change (Figure 10) has been edited and gen-
erated as a token by a SLANG process (not described here). We call the
time at which the editing of an activity de nition terminates the Change
De nition Time (CDT). This time may be di erent from the Change Im-
plementation Time (CIT) that is the time at which the change is applied to
the running process.
Several di erent strategies may be identi ed to apply a change to a run-
ning process. On one extreme, we identify a lazy strategy in which the new
activity de nition does not a ect running active copies of the activity, but
is only used in new instantiations of the activity. On the other extreme,
an eager strategy may be necessary. According to the eager strategy, ac-
tive copies under enaction have to be suspended, producing tokens of type
ActiveCopy, that contain the activity state. Then the activity de nition is
changed and the state has to be modi ed consistently. Finally, when new

25
active copies are ready, their execution is restarted. The environment pro-
vides the basic mechanisms to support this \on the y" change, but no rules
or methodology are provided on how this state adaptation has to be done.
In fact, the way this process state migration is done strongly depends on
the speci c characteristics of the process and of the modi cation applied.
Other policies can be implemented. For example, instead of suspending
all the active copies a ected by the modi cation of an activity de nition,
the process manager might decide that the active copies that were created
before a given date must not be suspended. This means that all the active
copies that have been operating for a long time are terminated according to
the old de nition, while those that have been recently started are suspended
and modi ed. A SLANG meta-process can involve the modi cation of type
de nitions as well. Types are modi ed by means of a net fragment accessing
place Types.
In summary, SPADE meta-processes are like any other process, and can
thus be speci ed, re ned, changed, and improved. In particular the policies
chosen to make de nition changes visible in the running active copies are
fully speci able in the meta-process.

9 Conclusions and future work

This paper provides an overview of the SPADE project. In particular, it
presents a case study that highlights the basic features provided by SLANG
to support modeling, enactment, and dynamic process evolution. The ar-
chitecture of the rst prototype of SPADE, called SPADE-1, is also brie y
described.
The main features of SPADE are the following:
 It provides a process modeling language.
 It provides an interpreter based on O2, an object-oriented database for
the storage of process data (including software artifacts and process
models).
 It uses DEC FUSE, a message-based integrated tool environment, to
achieve ne grained tool integration in the process.
 It supports distributed development activities.
 It supports speci cation and enaction of the software process as well
as meta-process.
26
 In parallel with the design of SPADE-1, the practical use of SLANG has
been investigated by modeling a large portion of a real software production
environment. The modeling activity has provided valuable insight into the
process and has shown inconsistencies and incompleteness of existing process
de nitions [Pic93]. SPADE-1 has been used to run a version of the case study
reported in this paper.
Future activities include:
 Improving the user interface, by adding user oriented tools such as a
graphical editor, an enactment monitor, a fully functional agenda, etc.
 Continuing the experimentation with real-life test cases.
 Introducing the possibility of writing the activity de nitions in a declar-
ative style.
 Adding measurement-oriented features to the language.

Acknowledgements
We wish to thank the DEC Engineering Center in Gallarate supporting this
work. In particular, we are indebted to Marco Braga for his constructive
help. The implementation of SPADE-1 is mainly due to the work of Paolo
Battiston, Guido Galli de' Paratesi and Marco Signori.

References
[ABGM92] P. Armenise, S. Bandinelli, C. Ghezzi, and A. Morzenti. Soft-
ware Process Representation Languages: Survey and Assess-
ment. In Proceedings of the 4th International Conference on
Software Engineering and Knowledge Engineering, pages 455{
462, Capri (Italy), June 1992. IEEE.
[BBFL94] S. Bandinelli, M. Braga, A. Fuggetta, and L. Lavazza. The
Architecture of the SPADE-1 Process-Centered SEE. In 3rd
European Workshop on Software Process Technology, Grenoble
(France), February 1994.
[BEM91] N. Belkhatir, J. Estublier, and W.L. Melo. ADELE 2 - An
Approach to Software Development Coordination. In Alfonso

27
 Fuggetta, Reidar Conradi, and Vincenzo Ambriola, editors,
Proceedings of the First European Workshop on Software Pro-
cess Modeling, Milano (Italy), May 1991. AICA{Italian Na-
tional Association for Computer Science.
[BF93] S. Bandinelli and A. Fuggetta. Computational Re ection in
Software Process Modeling: the SLANG Approach. In Proceed-
ings of the 15th. International Conference on Software Engi-
neering, Baltimore, Maryland (USA), May 1993.
[BFG93a] S. Bandinelli, A. Fuggetta, and C. Ghezzi. Process Model Evo-
lution in the SPADE Environment. To appear in IEEE Trans-
actions on Software Engineering. Special Issue on Process Evo-
lution, December 1993.
[BFG93b] S. Bandinelli, A. Fuggetta, and S. Grigolli. Process Modeling-
in-the-large with SLANG. In Proceedings of the 2nd Interna-
tional Conference on the Software Process, Berlin (Germany),
February 1993.
[BFGG92] S. Bandinelli, A. Fuggetta, C. Ghezzi, and S. Grigolli. Process
Enactment in SPADE. In Proceedings of the Second European
Workshop on Software Process Technology, Trondheim (Nor-
way), September 1992. Springer-Verlag.
[BK91] N. Barghouti and G. Kaiser. Scaling up rule-based software
development environments. In Axel van Lamsweerde and Al-
fonso Fuggetta, editors, Proceedings of ESEC 91{Thrid Eu-
ropean Software Engineering Conference, volume 550 of Lec-
ture Notes on Computer Science, Milano (Italy), October 1991.
Springer-Verlag.
[BPR91] R.F. Bruynooghe, J.M. Parker, and J.S. Rowles. PSS: A system
for Process Enactment. In Proceedings of the First International
Conference on the Software Process. IEEE Computer Society
Press, 1991.
[DEC92] DEC. DEC-FUSE manual. Digital Equipment Corporation,
1992.

28
[Fer93] C. Fernstrom. PROCESS WEAVER: Adding Process Support
to UNIX. In Proceedings of the 2nd International Conference
on the Software Process, Berlin (Germany), February 1993.
[GMMP91] Carlo Ghezzi, Dino Mandrioli, Sandro Morasca, and Mauro
Pezze. A Uni ed High-level Petri Net Formalism for Time-
critical Systems. IEEE Transactions on Software Engineering,
February 1991.
[Gru91] V. Gruhn. Validation and Veri cation of Software Process Mod-
els. PhD thesis, University of Dortmund, 1991.
[HSO90] D. Heimbigner, S. M. Sutton, and L. Osterweil. Managing
change in process-centered environments. In Proceedings of 4th
ACM/SIGSOFT Symposium on Software Development Envi-
ronments, December 1990. In ACM SIGPLAN Notices.
[JLC92] L. Jaccheri, J. Larsen, and R. Condadi. Software Process
Modeling and Evolution in EPOS. In Proceedings of SEKE
'92{Fourth International Conference on Software Engineering
and Knowledge Engineering, pages 574{581, Capri (Italy), June
1992. IEEE Computer Society Press.
[Kel91] M. Kellner. Software Process Modeling Support for Manage-
ment Planning and Control. In Proceedings of the 1st. Interna-
tional Conference on the Software Process, Redondo Beach CA
(USA), October 1991.
[KFF+ 91] M. Kellner, P. Feiler, A. Finkelstein, T. Katayama, L. Oster-
weil, M. Penedo, and D. Rombach. ISPW6 Software Process
Example. In Proc. of the 1th. International Conference on the
Software Process, Redondo Beach CA (USA), October 1991.
[Pic93] G. Picco. Modeling a real software process with slang. Internal
Report RI93059, CEFRIEL, Via Emanueli, 15 - 20126 Milano
(Italy), June 1993.
[PS92] B. Peuschel and W. Schafer. Concepts and Implementation
of a Rule-based Process Engine. In Proceedings of the 14th
International Conference on Software Engineering, pages 262{
279, Melbourne (Australia), May 1992. ACM-IEEE.

29
 [Rei85] W. Reisig. Petri Nets: an Introduction. Springer Verlag, New
York, 1985.
[SIK93] M. Suzuki, A. Iwai, and T. Katayama. A Formal Model of
Re-execution in Software Process. In Proceedings of the 2nd
International Conference on the Software Process, Berlin (Ger-
many), February 1993.
[Tec92] O2 Technology. The O2 manual. 1992.

30

View publication stats