Modeling coordination as resource flow

Material Information

Modeling coordination as resource flow an object-based approach
Billinger, Bryce
Publication Date:
Physical Description:
x, 42 leaves : ; 28 cm


Subjects / Keywords:
Workflow -- Mathematical models ( lcsh )
System analysis -- Mathematical models ( lcsh )
Process control -- Mathematical models ( lcsh )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )


Includes bibliographical references (leaves 39-42).
General Note:
Department of Computer Science and Engineering
Statement of Responsibility:
by Bryce Billinger.

Record Information

Source Institution:
|University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
47120809 ( OCLC )
LD1190.E52 2000m .B54 ( lcc )

Full Text
Bryce Billinger
B.S., University of Colorado, 1999
A thesis submitted to the
University of Colorado at Denver
in partial fulfillment
of the requirements for the degree of
Master of Science
Computer Science

This thesis for the Master of Science
degree by
Bryce Billinger
has been approved
Dianne Kumar
li ^7-
"Lei Date

Billinger, Bryce (M.S., Computer Science)
Modeling Coordination as Resource Flow an Object-based Approach
Thesis directed by Professor John Noll
Much work has been done to develop models of processes. In general,
processes are simply a set of actions that need to be performed. What differen-
tiates one process from another is the process flow. The flow of a process is the
sequence of actions that, when completed, produce a product. The ordering of
when actions can be performed, in relation to each other, is the control flow
of a process. A process model is a formal representation of the process and its
flow. A coordination model is also needed in a process model when activities
in a process share resources. This need for coordination becomes obvious when
these activities that use the same resource are preformed by different users.
Often a process model is written in terms of a process modeling language. A
process modeling language is similar to a programming language and provides
the control flow through control structure (i.e. loops, jumps, etc). What is
missing, however, is the coordination model to go with the control flow to ade-
quately model processes. An object model is used to add conditions to actions
and, in turn, resource coordination to a process modeling language. This addi-
tion gives a complete tool to model both the control flow and user coordination

of a process.

I dedicate this thesis to my wife for her support and love during all of the
research and writing for this paper.

I want to thank my advisor John Noll for his guidance and inspiration. I also
want to acknowledge my thesis committee for their guidance and help.

Figures ......................................................... ix
Tables........................................................... x
1. Introduction.................................................... 1
1.1 The Problem..................................................... 2
1.2 The Approach.................................................... 8
2. Related Work................................................... 12
2.1 Agent-based Control Flow....................................... 13
2.2 Graph-based Control Flow....................................... 14
2.3 Rule-based Control Flow........................................ 15
2.4 Procedural Control Flow........................................ 16
2.4.1 Repository Specific......................................... 16
2.4.2 Repository Independent...................................... 17
3. Approach....................................................... 20
3.1 The PML Language .............................................. 21
3.2 New Specification.............................................. 23
3.2.1 Objects for a heterogeneous repository...................... 24
3.2.2 Process Flow using Object Model............................. 24
3.3 Process Enactment Operating System............................. 25
4. Conclusion..................................................... 30

A. PML Example..................................................... 32
B. Virtual Machine Code Example.................................... 34
References.......................................................... 39

1.1 Pseudocode Process Example...................................... 4
1.2 Control Flow Example............................................ 4
1.3 Resource and Control Flow Example............................... 7
1.4 Initial PML Example............................................ 10
3.1 Action Statement Example....................................... 22
3.2 PEOS Architecture.............................................. 27

2.1 Related Work............................................... 12

1. Introduction
Using an object model to represent artifacts and deliverables in a pro-
cess modeling language provides an effective basis for modeling resource flow.
One definition of process modeling is: modeling formalisms emphasize concise
descriptions of the normal operation of a process [9]. In other words, a process
model is a formal description of a set of activities. The process model describes
a sequence of activities that, when completed, produce a product. In addition,
the process model can describe the coordination required between individuals
involved in the process. For example, if the process is simply cooking a meal,
then the process model is the description of every activity needed to perform
that process, how the cooks will interact to finish each activity, and the prod-
uct produced by the process. The goal is to have the ability to model any
process used by a company or group. For instance, if the process is a software
engineering process, then the process model will describe the activities that
are needed in the process, how the developers will work together, and the final
software product that is produced.
Once a process model is created to adequately model a process, there

should be the capability to use the model as a guide to individuals performing
the process. The process model will show users which activities in the process
can be executed at any given time. If the process is a software engineering
process, then the users of the process would be developers and testers. The
users will ask the process model which activities are available. When one
activity is completed, the model specifies which activity is next. For instance, if
the user of a process model says that the activity of designing code is complete,
then the process model specifies that the next activity is to write the code. In
addition, some process models can be executed to provide automatic guidance.
For example, if a process model could somehow be compiled and run, then
the executable form of the model would be a program that guides individuals
through the process. In summary, a process model is a model that describes
how activities are to be performed to follow a specific process and produce a
product. The goal of process modeling is to create a modeling tool that is
simple enough to be used by anyone and, at the same time, powerful enough
to model any process.
1.1 The Problem
The most important part of modeling a process is to model the process
flow correctly. A process model is a specification of the sequence of activities

that produces a product. The sequence of the activities is the flow of the
process. The flow of the process is dictated by two things: the control flow
and the coordination between users of the process. Control flow is the logical
sequence of activities in a process. Certain activities in a process logically come
before others. In other processes, some activities can logically be executed
concurrently, or some activities can be executed more than one time. All of
these logical sequences make up the control flow of a process.
Consider a simple software development process to add, test, and
release a new feature. The process starts off with two main activities that
can be executed at the same time. One activity is for a developer to edit the
code, compile the code, and then check in the code. At the same time, a tester
can execute the activities of writing a test plan and then executing the test
plan. When both the tester and developer are done with their activities, the
last activity is to release the product to the public. The logical sequence of
activities in this process is described by the pseudo-code in Figure 1.1. Thus,
we want to do the coding and testing concurrently. When both tasks are
complete, the product will be released and the process will be complete. This
logical sequence is called control flow, which is depicted as a flow graph in
Figure 1.2.

Start process
Do concurrently {
code {
edit code
compile code
check in code
test -[
write test plan
execute test plan
release product
Figure 1.1. Pseudocode Process Example
Figure 1.2. Control Flow Example

Coordination is managing dependencies between activities [14]. Of-
ten processes have more than one process performer. In these cases, coordina-
tion needs to occur between the users so activities are completed in the correct
order. Coordination between users can be achieved by controlling access to the
resources used for each activity. For example, if one activity produces an out-
put and another activity requires the same item as input, then a dependency
is created. This dependency represents a flow of resources from one activity
to the next, called resource flow. Returning to the example above, the coder
needs, as input, a piece of code before the code can be edited. By editing
the code, a new modified piece of code is created. The modified code is used
as input to the compile activity. The compile activity creates an executable.
The checkJn activity uses the modified piece of code and creates a piece of
code that is now checked in. On the test side, the plan activity creates a test
plan. The activity of testing the code requires a piece of executable code to
test with and the output is tested code. Finally, the activity of releasing the
product requires a tested program and results in an available program. The
thing to notice is that the dependency created between the coder and tester is
captured by the flow of the executable code from the compile activity to the
test-code activity. Now the tester must wait for the coder to complete several
of his/her activities before the tester can complete all of his/her activities. It

does not make sense to start testing when there is not executable code to test.
The combination of control flow and resource flow is shown in Figure 1.3. The
dashed lines in the figure represent resource flow, and the solid lines represent
control flow. Thus, it is more effective to use both control flow and resource
flow to dictate the overall flow of a process.
One of the issues in representing coordination in a modeling language
is the fact that when a process model is executed, the resources are actually
real and not just models themselves. The resources can be any data ranging
from a plain text file to an executable piece of code. To have the ability
to model any process creates the need to model any type of data that the
process might use. Many approaches rely on an object-oriented database or
specialized repositories to store the artifact and deliverables in the process.
These approaches are analyzed in the next chapter. The intent of this project,
however, is to not be limited by a specific repository or by a specific format for
the resources. Thus, the goal is to model resource flow using a representation
for any resource that can be produced or used by a process. The approach to
accomplishing this goal is explained next.

Figure 1.3. Resource and Control Flow Example

1.2 The Approach
This research shows how resource flow is added to a process modeling
language, which already has control flow, to enable a more effective process
flow model. By using an object model to represent artifacts and deliverables,
a process modeling language can be used to properly represent the resource
flow of the process, and in turn properly represent the coordination between
users of the process. Process programming proposes that it is feasible and
valuable to represent software processes using programs written in compilable,
executable coding languages [24]. A process programming language can be
used to model a sequence of process steps, just as a simple programing language
is used to develop executable programs. By adding the ability to model resource
dependencies, a process programming language can model both control flow
and coordination. The process modeling language needs certain syntax and
semantics to allow a processs control flow to be represented. Similar control
structures that are used in popular programming languages today give the
foundation for representing control flow in a process programming language.
The control flow is specified by the control structures of the process
language itself. For example, the process modeling language that was chosen
for representation of control flow in this work (called PML) gives the ability to
specify actions or tasks, the sequence in which those tasks should be preformed,

as well as iteration over tasks, selection of alternate sequences, and branching
among concurrent tasks. There is, also, a branch control structure to allow
steps to be executed concurrently. Thus, PML has all of the pieces needed
to model the control flow of a process. The missing piece is the coordination.
PML can easily represent the pseudo code in the previous section (see Figure
1.4), but it cannot represent the coordination that is inherited by the process.
In Figure 1.3, the coordination is shown along with the control flow. The
diagram shows that the test code step needs a resource (compiled code) from
the compile step before it can continue. PML does not have a way to enforce
that dependency between the two steps, and there is not a way to rewrite the
control flow to represent the dependency. Thus, an addition is needed to PML
to allow the modeling of coordination among concurrent control flows.
Resource flow is simply a way to capture coordination in a process.
Resource flow will cause one user of a process to wait until the resource needed
is produced. If that resource is produced from another user, then there is now a
coordination between the two users. One way to add resource flow to PML, or
any process modeling language, is to add pre- and post-conditions to the steps.
The pre-conditions will specify which resources are needed for the step to begin,
and the post-conditions will specify which resources will be produced from the
step. The PML syntax has requires and provides clauses. These clauses provide

process example {
branch {
sequence code {
action edit O
action compile O
action {}
sequence test {
action plan O
action test.code {}
action release.product {>
Figure 1.4. Initial PML Example

pre- and post-conditions for a given action. These clauses provide the base for
the enhancements to PML. The enhancements will allow us to model resource
flow along with control flow. Within the requires and provides clauses, an
object model is used to make sure the artifacts and/or deliverables needed are
there before the action is started, and the correct artifacts and/or deliverables
exist after the action is finished. For instance, there might be an action to
represent the compilation of a piece of code. The requires clause needs to
make sure that there is a piece of code that needs to be compiled before the
action starts. The provides clause needs to make sure that the action produced
some sort of executable from the compilation. The statement for the requires
clause, using the new object model, would be code.status == modified.
The provides clause would be prog.type == executable. Thus, before the
action there must be an object named code whose status is modified, and after
the action there is an object of type executable. This model allows a very
simple and straight-forward way to represent resource flow with artifacts and
The next chapter describes some of the related work in the area of
process modeling and to place this work in context. Next, the approach is ex-
plained in more detail along with a sample process. Lastly, the final conclusions
will be made to summarize the work.

2. Related Work
The related work can be categorized by how they model control and
resources, and by resource management. Table 2.1 shows the divisions and
examples of work that falls into each category. The first division made was
between different types of models to represent control flow. This division is
shown by the columns in the table. There are four primary control flow models
used today. The models are procedural, rule-based, graph-based, and agent-
based. The procedural model looks just like any procedural based programming
language. The rule-based model uses logic rules to dictate the flow of the
process. The graph model uses graphs, such as flow graphs, to show process
flow. Lastly, the agent based model is an attempt to move the process model
into a distributed model of intelligent agents. The next division split the
Control-flow model
Resource Model Procedural Rule-based Agent-based Graph-based
Homogeneous/ centralized/ tightly coupled JIL, APPL/A, MVP-L Marvel SLANG, PROMO
Heterogeneous / distributed/ loosely coupled Merlin METEOR, DartFlow, APMS Petri-Nets
Table 2.1. Related Work

projects based on the underlying resource model. Some projects rely on a
homogeneous and/or centralized database to model resources or rely on a very
specific database to model resources. Other projects enable a heterogeneous
and/or distributed database to represent resources in the process model. The
result of the divisions is a mapping of the current work in the field of process
modeling. The following sections describe the areas of related work in more
detail, some sample projects that fall into the divisions, and exactly where this
work fits.
2.1 Agent-based Control Flow
Agent-based process modeling has become a very unique way to model
process flow. An agent is a program that is design to make an intelligent de-
cision of what to do next based on its current states. Much of the work is
based on the field of artificial intelligence. The goal is to have agents that are
distributed and can act independently of other agents. This distributed archi-
tecture is the reason why all of the examples fall into the bottom of the table
for their resource model. An example of a agent-based model is the DartFlow
project that uses the world wide web and transportable agents to model pro-
cess flow [7]. The Agent-based Process Management System (APMS) and the
METEOR project use agents as a framework for workflow management [23, 19].

The work with agents has leaned towards the control flow model of process flow
and has separated the data and resources from the model. The separation is
due to the fact that agent-based models are focused on a process state and
not the process model. For agent-based processes, the process model can be an
ever changing model. The agent should be able to use the process state and the
current environment, such as a process model, to intelligently determine the
next state. On the other hand, this work is interested in the process model and
how to create a model to represent process flow. The agent-based approach
does not have this focus, and, therefore, is not the correct control flow model
to use in this case.
2.2 Graph-based Control Flow
The graph-based process models are simply a graphical representation
of actions and resources. Flow can be shown between actions and resources
with lines and arrows. If one state needs to occur after another state, then
there is usually a simple arrow from the first action to execute to the next
action. The Petri Net is one of the most used graph-based modeling examples.
The projects SPADE/SLANG and PROMO are based on Petri-Nets[2, 8]. The
benefit of graph-based models is the fact that all of them are very easy to

read and create, and thus make them suitable for many users. The graph-
based control-flow model is the closest model to the procedural model that is
explained in a later section. While graph-based models may be easy to read and
understand, their flaw is they are not as powerful as other process models. It is
simple to show a resource as a node on some graph, but what is the format of
the resource and where does it need to be stored? This question is one example
of some of the limitations of graph-based models. Because graph-based models
do not have all of the capabilities as other process modeling languages, they
were not chosen as the control flow model to use in this work.
2.3 Rule-based Control Flow
A rule-based control flow model comes from rule based programming
languages. The main idea behind a rule-based model is to use the rules of
logical statements to determine which actions can be executed at any given
time. The Merlin project is based on PROLOG and uses these rules to model
processes[10]. Marvel also uses rules to model processes, with a object-oriented
database in the back-end to keep the data[12]. A rule-based modeling language
is a very powerful way to model processes, just as rule based programming
languages can be very powerful programming languages. The problem is, rule-
based languages are hard to understand. It can be difficult to read a rule-based

modeling language and be able to understand how the process being modeled
should work. Since the rule-based languages are hard to understand for the
developer, they are not the right model for this work.
2.4 Procedural Control Flow
A procedural model is based on some of the most popular program-
ming languages used today, procedural programming languages. There are
many projects that use a procedural based control flow model, they include
JIL, MVP-L, PML, and APPL/A. Yet, the projects differ in several ways.
2.4.1 Repository Specific
One of the man differences between procedural modeling languages
is the fact that they depend on specific types of repositories. In JIL, artifact
definition and management is done using Pleiades, a persistent object manage-
ment system [27]. In MVP-L, a relational database is used to store product
(artifact) objects[5]. In APPL/A, the repository used is Triton, a persistent
object system built on top of the EXODUS storage manager [26]. The re-
source model for all of these examples are dependent on a very specific model.
Thus, the resource model is tightly coupled to its underlying implementation.
If the resource model needed to change, often the specific repository would

need to change also. Since resources are the enforcer of coordination for pro-
cesses, limitations are added to the coordination model when a specific resource
implementation is used. If the coordination of users crosses boundaries, such
as a certain computer or network, for a given process, then there is a good
chance the resource implementation will not be able to handle the needs of the
2.4.2 Repository Independent
In the related works table, there is one box left that has no examples
in it. The box represents a procedural based control flow model that has a
resource model that is heterogeneous, distributed, and/or loosely coupled to a
specific repository. By using an object model to represent artifacts and deliv-
erables in a process modeling language, the goal is to have a way to represent
coordination via resource flow. PML is a procedural modeling language that
has all of the control flow structure needed to represent the control flow of a
process. An object model that can represent a resource and not be dependent
on a specific implementation will be the basis of representing the resource flow.
This object model is combined with PML to enable the modeling of both coor-
dination and control flow. Thus, this work fits into the empty box in the table
under procedural flow.

In summary, there is a lot of work in the field of process modeling.
The agent-based control flow models are focused on a process state and not the
process model itself. The main focus of this work is to develop a process model
that can powerfully model any process. Thus, the two approaches are really
not related. The graph-based model is a very simple way to represent a process
model. What the graph-based model gains in readability is lost in power. In
a graph-based model it is difficult, if not impossible, to give all of the details
that are shown with other modeling languages. On the other hand, rule-based
models are very powerful. The concern with rule-based models, however, is
the difficulty in understanding them and being able to read a process language
and understand it. Procedural modeling languages are a median between power
and understandability. The languages are fairly straightforward to understand,
and are powerful enough to do most things needed in modeling a process.
An occurring theme in procedural modeling languages is the fact that they
use a specific repository for the resource model. The work presented here
differentiates from the other procedural languages by allowing any repository
to be used. The object model will add a new functionality to the procedural
language PML to allow resource flow to be modeled. The object model will
provide a resource model that creates an abstraction from the repository. This
abstraction allows the new process modeling language to have a loosely coupled

relation between its resource model and the underlying repository. The details
of the approach and solution are given in the next chapter.

3. Approach
The goal is to have the ability to model both control flow and coordi-
nation with a process modeling language. Control flow is the ordering of when
steps in a process should occur. Control flow can be represented by simple con-
trol structures of a programming language. If a procedural process modeling
language, such as PML, is used, then the simple structures are built into the
syntax and semantics of the language.
The second piece needed in a modeling language is a representation
for the coordination model. Our coordination model is simply a way to manage
resource dependencies between activities. This dependency between activities
is called resource flow. If one step in the process creates a resource, and an-
other step in the process uses that same resource, then there is resource flow
between the two steps in the process. The approach to adding resource flow to
a procedural process language is to add a resource model and use it in the pre-
and post-conditions of each action of the process. Resource flow is added to
the language by adding constructs to the language that allows one to describe
resources conforming to an object model. The language constructs specify a

query against the pool of resources available to the process. For example, the
object model should enable a process to check if a specific resource exists, or if
a resources state has changed. The pre-conditions ensure the query is satisfied
before the action starts. The post-conditions will make sure that the query
is satisfied before the action is completed. The result is a process modeling
language that models both resource flow and control flow.
The remainder of this chapter describes the details of how coordina-
tion was added to a control flow process language. First, some of the details
of the original specification will be presented, and briefly how the language is
used to model control flow. Secondly, the changes to the specification will be
presented, along with the new functionality allowed by the changes to model
resource flow. Lastly, a system that can execute an instance of a process mod-
eling language code is presented to complete the implementation of the process
3.1 The PML Language
PML specifies process steps within common control-flow structures,
including concurrency [21]. The idea is to be able to represent any process with
a simple language that is similar to many programming languages. PML was
developed by John Noll at the University of Southern California. PML gives

action compile {
requires { "code to compile" }
provides { "compiled code" }
agent { "the programmer" }
Figure 3.1. Action Statement Example
a simple syntax and semantics to give the ability of modeling a wide variety
of processes. PML has syntax very similar to many of the common program-
ming languages used today. The main component is what is called an action.
Within the action, several specifications of the action can be listed. The types
of specifications are the clauses requires, provides, tool, agent, script, input,
output, and creates. The two most important specifications from this list are
the requires and provides clauses. The purpose of these clauses are to provide
a pre-condition and post-condition for the action. These clauses will be the
basis for the changes of the PML specification. See Figure 3.1 for an example
of the syntax for an action statement. To allow flow control for these action
statements there are several control structures. The control structures are
task, sequence, iteration, branch, and selection. The task structure is simply a
means to group a section of code into a block. The sequence structure specifies
that the actions must be done in the order given. The iteration structure is
a loop that repeats the actions an unspecified number of times. The branch

structure provides a way to do actions concurrently. Lastly, the selection struc-
ture means that only one of the actions in the structure is to be preformed. All
of these structures can be nested within each other and allow practically any
type of control flow needed by a process. An example of a full PML program
showing some of these structures is shown in Figure 1.4. This example PML
code is the same example from the first section of the paper. It is an example
of a simplified software engineering process. The semantics of the code says
that there are two sets of tasks that can occur concurrently, the coding and
the testing. The coding task is made up of three actions: edit, compile and
checkJn. The test task is made up of two actions: plan and test-code. Once all
of these actions are completed the last action is to release the product. This
code represents the control flow shown in Figure 1.1 exactly.
3.2 New Specification
The basis to model process flow was already included in PML. There
were control structures to specific the control flow of the process, and there
were clauses in the action statements to allow pre- and post-conditions for
the actions. The changes to the PML specification were in the requires and
provides clauses to allow the artifacts and deliverable in a process to dictate
the resource flow.

3.2.1 Objects for a heterogeneous repository
The intent is to allow a heterogeneous repository for the artifacts and
deliverables used in the process. Thus, the syntax and semantics of the changes
to PML could not rely on a specific database or format for the data. Thus,
a generic object model was used to represent the artifacts and deliverables in
the process. The syntax for the object is of the form object_name.attribute.
A unique object name specifies an unique object within the process. These
objects were then used in the requires and provides clauses. The format for
the clauses are now in the form clause { objectjname.attribute op value }. If an
action requires a template before it starts, then the PML code would be requires
{ a-template.type == template }. This simple syntax allows any underlying
repository to check if it contains some data that is a template and return it.
This model will allow the PML language to model resource flow. A detailed
example is in the next section.
3.2.2 Process Flow using Object Model
A complete example of the new syntax is given in Appendix A. This
example is for a process modeling the coding and testing process often used in
software engineering. The example has a branch statement at the beginning,
with two sequence statements underneath. Therefore, the sequence code and

test can be done at the same time. Before the changes just mentioned above,
the flow of this process would be to preform the code and test sequences con-
currently, and when both sequences were completed the checkJn action would
be preformed. Now, notice that with the requires and provides clauses there
is a dependency between the actions compile and test_code. It is still true
that the actions edit and plan can be done concurrently, but now the tester
must wait for the compile action to complete before the test-code action can
be started. Thus, the objects representing deliverables give a representation to
model resource flow.
3.3 Process Enactment Operating System
In addition to the PML language itself, a process enactment operating
system (PEOS) was developed to allow the compilation and running of PML
code. PEOS give the ability to actually run the process, that is modeled in
PML, and make sure it gives the same results as intended. As of today, the
PEOS system is still under development and the basic parts and functionality
are working. PEOS is made up of several components, see Figure 3.2 for a
picture of the overall architecture. There is one component that gives a visual
way to create a piece of PML code. Another component takes the PML code
and compiles it into code that can be interpreted by a virtual machine. The

virtual machine is the base process for running the process, using another
component as its operating system for system calls. The last component is
another user interface that enables users to start processes and run them from
start to finish. For this project, the compiler, virtual machine, and operating
system were changed to implement the new functionality.
In the PEOS system PML code can be compiled into a language that
can be interpreted by a virtual machine. The virtual machine is a stack based
interpreter that runs a PML compiled program and computes which actions
are available at any given time. For example, if there is a sequence statement
in the PML code with three actions, then the virtual machine is going to give
the user a choice between the three actions. Once one action is selected to be
performed, the other actions become unavailable to the user. Thus, the virtual
machine enforces the semantics of the language. An example of a complete set
of code for the virtual machine can be found in Appendix B. The code works
in a way that is similar to some assembly level languages. There are calls to
manipulate variables on the stack, jump calls to give the program the ability
to loop and skip, and special code that makes system calls to the operating
system. The system calls are used for setting the states of actions, i.e. ready,
done, etc., and for blocking for an event. A new system call was added for the
new PML specification and will explained in the next paragraph.

User Inter face
! PKIL code
J Compiler
User Interface
VM code
\ Virtual Macliinc
{ Operating system
Figure 3.2. PEOS Architecture

The real work for the changes in the PEOS system comes in the virtual
machine. The compiler was changed to create a system call for every requires
and provides clause found in the PML code. The virtual machine now has the
task of keeping track of every object created and a pointer to the matching
data in the repository. An example of what the virtual machine code looks like
and how the clauses are interpreted can be found in Appendix B. The virtual
machine code had to be changed slightly to allow the new functionality added
to the PML language. The largest change was the addition of a new system
call, the select system call. The select system call is how the virtual machine
makes a query to the repository asking about an object. This system call blocks
until an object can be returned that meets the query. Thus, if an artifact does
not exist and the action should wait for the artifact before starting, then the
system call will not return until the object (artifact) exists. This system call
provides the functionality needed to allow the objects to control the resource
flow of the process. Now, all of the pieces needed to implement a process
modeling language that supports both control flow and resource flow exist in
The goal was to have a process modeling language that could repre-
sent both the resource flow and control flow of a. process. The control flow is
modeling by using control structures in a procedural modeling language. The

modeling language that was used, PML, was then modified to model resource
flow. The resource flow was modelled by adding an object model to represent
resources in a process. The objects were used in pre- and post-conditions of
the modeling language to enforce resource flow between action in the process.
The resulting modeling language can now model resource and control flow in
a very simple and powerful manor. Another step was taken to allow this new
modeling language to compile and run. This system, called PEOS, uses the
new modeling language to create a process execution tool. This tool enable
users of the process being modeled to actually run the process and use the
process as a software program.

4. Conclusion
An object model was used to represent artifacts and deliverables in a
process modeling language. The object model, in turn, was used to model the
resource flow in the process modeling language by its use in the pre- and post-
conditions of the action statements. This object model gave a resource model
that was not tightly coupled to a specific repository. Much of the related work
was either focused on a different control flow model, or used a resource model
that was tightly coupled to a specific repository. The goal of this project was
to allow the most flexibility possible for an underlining repository. The generic
object model used gives the modeling language this ability to allow any type
of repository available.
The resource flow, or resource coordination, is modeled after resource
management in UNIX systems. If a resource, or artifact, is not available,
then the process, or action, must wait. When the resource(artifact) becomes
available, the process (action) can then run. The changes made to the PML
specification and code in the PEOS system allow this type of modeling to
be available. Now, the flow of a process can be defined in terms of control

structures and resource conditions, which makes the modeling of processes
easier and more robust.

process example {
branch {
sequence code {
action edit {
requires { code.type == module >
provides { code.status == modified }
action compile {
requires { code.status == modified }
provides { progA.type == executable }
action check_in {
requires { code }
provides { code.status == checked_in >

sequence test {
action plan {
requires { dtp.type == test_plan }
provides { dtp.status == modified }
action test_code {
requires { progA >
provides { progA.status == tested }
action release_product {
requires { progA.status == tested >
provides { progA.status == beta >

B. APPENDIX Virtual Machine Code Example
0 name_0 type branch children ( code test )
1 edit type action mode manual requires { code. type==module } providi
{ code.status==modified >
2 compile type action mode manual requires { code.status==modified }
provides { proga.type==executable }
3 check_in type action mode manual requires { code } provides {
code.status==checked_in }
4 plan type action mode manual requires { dtp.type==test_plan }
provides { dtp.status==modified }
5 test_code type action mode manual requires { proga } provides {
proga.status==tested >
6 release_product type action mode manual requires {
proga.status==tested > provides { proga.status==beta >
7 start
8 push 0
9 call fork 23

10 jzero 86
11 pop
12 incr
13 call fork 54
14 jzero 86
15 pop
16 incr
17 call join
18 jzero 86
19 pop
20 deer
21 jzero 75
22 goto 17
23 call select type==module
24 pop code
25 call set ready edit
26 jzero 86
27 pop
28 call wait done edit
29 jzero 86

30 pop
31 call select status==modified&&id==$code
32 pop
33 call select status==modified&&id==$code
34 pop
35 call set ready compile
36 jzero 86
37 pop
38 call wait done compile
39 jzero 86
40 pop
41 call select type==executable
42 pop proga
43 call select type==module&&id==$code
44 pop
45 call set ready check_in
46 jzero 86
47 pop
48 call wait done
49 jzero 86

50 pop
51 call select status==checked_in&&id==$code
52 pop
53 call exit
54 call select type==test_plan
55 pop dtp
56 call set ready plan
57 jzero 86
58 pop
59 call wait done plan
60 jzero 86
61 pop
62 call select status==modified&&id==$dtp
63 pop
64 call select type==executable&&id==$proga
65 pop
66 call set ready test_code
67 jzero 86
68 pop
69 call wait done test_code

70 jzero 86
71 pop
72 call select status==tested&&id:==$proga
73 pop
74 call exit
75 call select status==tested&&id==$proga
76 pop
77 call set ready release_product
78 jzero 86
79 pop
80 call wait done release_product
81 jzero 86
82 pop
83 call select status==beta&&id==$proga
84 pop
85 end
86 call error

[1] P. Armenise, S. Bandinelli, C. Ghezzi, and A. Morzenti. A Sur-
vey and Assessment of Software Process Representaton For-
malisms. In Int. Journal on Software Engineering and Knowl-
edge Engineering, 3(3):401-426, 1993.
[2] S. Bandinelli, A. Fuggetta, C. Ghezzi, L. Lavazza. SPADE: An
Enviornment for Software Process Analysis, Design, and Enact-
ment. In A. Finkelstein and J. Kramer and B. Nuseibeh (eds.)
Software Process Modeling and Technology, Research Studies
Press Limited, 1994.
[3] Sergio Bandinelli, and Alfonso Fuggetta. Computational Reflec-
tion in Software Process Modeling: the SLANG Approach. In
Proc. of the 15th Int. Conf. on Software Engineering, Baltimore,
Md, IEEE Computer Society Press, 1993.
[4] N. S. Barghouti, W. Emmerich, W. Schfer and A. H. Skarra. In-
formation Management in Process-Centered Software Engineer-
ing Enviornments. ESPRIT-III Project GOODSTEP (6115),
January 1995.
[5] A. Brokcers, C. Lott, H. D. Rombach, and M. Verlage. MVP-L
Language Report Version 2. University of Kaiserslautern, Febru-
aury 1995.
[6] A. Brockers, et. al. A Graphical Representation Schema for
the Software Modeling Language MVP-L. University of Kaiser-
slautern, June 1995.
[7] Ting Cai, Peter A. Gloor, Saurab Nog. DartFlow: A Workflow
Management System on the Web using Transportable Agents.
Department of Computer Science, Dartmouth College, Hanover,
NH 03755.
[8] John C. Doppke. Software Process Modeling and Execution
Within Virtual Environments. In ACM Transactions on Soft-
ware Engineering and Methodology (TOSEM), Vol. 7, No. 1, pp.
1-40, January 1998.

[9] Dennis Heimbigner. The ProcessWall: A Process State Server
Approach to Process Programming. In Fifth SIGSOFT Sympo-
sium on Software Development Enviomments, December 1992.
[10] G. Junkermann, B. Peuschel, W. Schfer, and S. Wolf. MER-
LIN: Supporting Cooperation in Software Development through
a Knowlege-based Environment. In A. C. W. Finkelstein, editor,
Advances in Software Process Technology. John Wiley, 1994.
[11] Knutilla, A., et. al. Process Specification Language: Analysis
of Existing Representations. NISTIR 6133, National Institute of
Standards and Technology, Gaithersburg, MD (1998).
[12] Marvel: Process-Centered Enviornments. Columbia Univer-
sity, Department of Computer Science, Programming Sys-
tems Laboratory,
sheets / marvel-fact-sheet.html.
[13] METEOR Suite
of Enterprise Application Services: Exploiting CORBA, Java
and Internet for Enterprise Application Integration and Process
[14] Thomas W. Malone and Kevin Crowston. The Interdisciplinary
Study of Coordination. In ACM Computing Surveys, Vol. 26,
March 1994, pp. 87-119.
[15] Peiwei Mi and Walt Scacchi. A Meta-Model for Formulating
Knowledge-Based Models of Software Development. In Decision
Support Systems, Vol. 17, No. 3, 1996, pp. 313-330.
[16] John Noll and Walt Scacchi. A Hypertext System for Integrating
Heterogeneous, Autonomous Software Repositories. In Proceed-
ings of the 3rd. Irvine Software Symposium, ACM SIGSOFT and
UC Irvine, Irvine, CA, April, pp. 49-59, 1994.
[17] John Noll and Walt Scacchi. Specifying Process-Oriented Hy-
pertext for Organizational Computing. In Journal of Networking
and Computer Applications, December 9, 1999.
[18] John Noll and Walt Scacchi. Supporting Software Development

in Virtual Enterprises. In Journal of Digital Information, 1(4),
February 1999.
[19] P.D. OBrien and W.E. Wiegand. Agent based process manage-
ment: applying intelligent agents to workflow. In The Knowledge
Engineering Review, Vol. 13:2, 1998, 1-14.
[20] Jurgen Petry. The MILOS Project: Overview. milos/Overview.html.
[21] Walt Scacchi and John Noll. Process-Driven Intranets: Life-
Cycle Support for Process Reengineering. In IEEE Internet
Computing, Vol. 1, No. 5, September, 42-49.
[22] A. Sheth, D. Georgakopoulos, S. Joosten, M. Rusinkiewicz, W.
Scacchi, J. Wileden, ad A. Wolf. Reoprt from the NSF Workshop
on Workflow and Process Automation in Information Systmes.
In SIGMOD Record, Vol. 25, No. 4, December 1996.
[23] Amit Sheth. METEOR: Brief Overview. Large Scale Distributed
Information Systems Lab, University of Georgia and Infocosm,
[24] Stanley M. Sutton, Jr. and Leon J. Osterweil. The Design of a
Next-Generation Process Language. In ESEC/FSE 97, LNCS
1301, Springer, 1997, pp.142-158.
[25] Stanley M Sutton, Jr., Peri L. Tarr, and Leon J. Osterweil. An
Analysis of Process Languages. Computer Science Department,
University of Massachusetts, Aug. 1, 1995, Amherst, MA 01003.
[26] Stanley M. Sutton, Jr., Dennis M. Heimbigner, and Leon J. Os-
terweil. Language Constructs for Managing Change in Process-
Centered Environments. In Proceedings of the Fourth ACM SIG-
SOFT Symposium on Software Development Environments, pp.
206-217, Dec. 3-5, 1990, Irvine, CA.

[27] Stanley M. Sutton, Jr., Barbara Staudt Lerner and Leon J. Os-
terweil. Experience Using the JIL Process Programming Lan-
guage to Specify Design Processes. Computer Science Depart-
ment, University of Massachusetts, Sept. 6, 1997, Amherst, MA