There are a number of frameworks for the representation and exchange of process information vying for attention in the modeling and knowledge sharing communities. We do not wish to propose yet another; existing frameworks are generally quite adequate as far as they go. However, in this paper we will highlight several related issues--both philosophical and formal--that we believe have not been clearly addressed by existing frameworks, but which we believe must be addressed by *any* general framework for representing process information. We will also point in the general direction of a solution. We hope thereby to contribute an important component to the general theory of processes and thus, in turn, to the development ofsound standards for the representation, exchange, and integration of process models.
1. A robust type/instance distinction
The distinction between types and instances is critical for the accurate expression of process information. In process modeling, one encounters two particularly prominent types: object types and activity types. Processes are typically--and no doubt rightly--viewed as structured collections of activity types. For instance, the process depicted in the following simple model consists of five activity types.
/\
---------- -------- / \ then ----------
|Paint-part| --> |Dry-part| --> / Test \ ----> |Pack-part|
---------- -------- \ part / ----------
\ /
\/
|
|else
|
| ----------
-----> |Scrap-part|
----------
Figure 1: A simple process model
Note that these are indeed types: each is a general, repeatable pattern of action whose *instances* consist of specific, time-bound, real world events.
Now, in general, activity types involve object types. Otherwise put, the description of an activity involves the description of certain kinds of object (e.g., agents, mechanisms, resources, etc.) possessing certain properties, playing certain roles, standing in certain relations, etc. Thus, the Paint-part activity in the above example would likely involve (at least) a Part object type and a Paint-sprayer type. An *instance* of the activity type will then, correlatively, involve instances of the associated object types, i.e., a real world part being painted by the paint sprayer at some definite time.
Proper representation of processes, then, requires the ability to talk about both types and instances, and the ability to express contraints on those instances. In this paper we will discuss existing approaches to the rerepresentation of types and instances and explore some new approaches, in particular an approach suggested by situation theory.
2. Processes and their instances
The need for a robust type/instance does not stop with activities and objects. For processes themselves (as described by typical enterprise process models) are themselves type level entities: they are general *patterns* of activity types that are exemplified by specific real world courses of events. The structure of a process--that which distinguishes it from a mere *set* of activity types--is determined by a collection of temporal constraints. These constraints in turn determine what can count as an instance of the process. Thus, Figure 1 depicts a process whose instances consist in an instance of Paint-part, followed by an instance of Dry-part, followed by an instance of Test-part, followed *either* by an instance of Pack-part or Scrap part, depending on the outcome of the Test.
Proper representation of processes, then, requires the ability in particular to talk about process types and process instances. However, as we will discuss, there are few *explicit* accounts of processes and their instances per se to be found in the current literature; most approach the issue obliquely at best. There is a reason for this. The development of a rich characterization of processes and instances immerses one quickly in a host of complex issues. In this paper we will illustrate this by concentrating on (at least) two challenging problems.
3. Two challenges
Challenge 1: "Object flow" The activity types in a process are often characterized "modularly". That is, the object types in a given activity are listed, constraints are specified, etc. Thus, the Paint-part and Dry- part activities might be specified (simplistically) along the following lines:
(define-activity-type Paint-part (?x)
(obj-types: Part Paint-sprayer)
(constraints: (= (duration ?x) 10sec)
(paints (the ?y (Paint-sprayer ?y) (the ?z (Part ?z))))))
(define-activity-type Dry-Part (?x)
(obj-types: Part Blower)
(constraints: (= (duration ?x) 30sec)
(dries (the ?y (Blower ?y) (the ?z (Part ?z))))))
The question then is this: how does one specify that in an *instance* of the process in question the part in the instance of Paint-part is the same as the the part in the subsequent instance of Dry-part? How does one "hook" these independently specified modules together to ensure this?
Challenge 2: Indeterminate cycles. Suppose we alter the simple process above so it is not so wasteful above and put a loop in it that repaints poorly painted parts:
/\
---------- -------- / \ then ----------
|Paint-part| --> |Dry-part| --> / Test \ ----> |Pack-part|
---------- -------- \ Part / ----------
^ \ /
| \/
| |
| |else
| |
------------------------------
Figure 2: A simple process with a cycle
Thus, in instances of this process, a part goes through the paint/dry cycle until it passes the test, and then it is packed. The problem of object flow arises here as well. The new challenge in this example is simply to be able to specify the notion of an activity instance in such a way that all and only the "right" collections of activity instances count as instances of the given process. In particular, a notion of process instance is needed that will (i) distinguish between instances that differ in the number of times the cycle is repeated, and (ii) counts as instances of the process all and only those collections of activity instances that loop some arbitrary number of times through the cycle.
In this paper we will explore the implications of these problems for the representation of processes and their instances, and we will use them to set a context both for critiquing existing approaches and for exploring several new approaches.