HieraStates: Supporting Workflows which Include Schematic and Ad-hoc Aspects. Gunnar Teege Technische Universit¨at M¨unchen, Germany email:
[email protected] Abstract The mixture of production and ad-hoc aspects in organizational work is a ubiquitous phenomenon which potentially occurs on all levels of detail in a workflow. In this paper I first describe how this problem is addressed in the Object-oriented Activity Support Model. The model supports the manual modifications of the subactivity tree in collaboration with a workflow engine, and it supports the mixture of activities with and without an execution scheme. Then I describe in more detail how the HieraStates mechanism for specifying and running execution schemes supports schemes which allow several degrees of flexibility during execution of an activity. These schemes provide support for activities where the ad-hoc and production aspects cannot be easily separated into different substeps. Throughout the paper the example of a purchase order is used to illustrate the approach.
1 Introduction Workflows involving both production and ad-hoc aspects are characteristic for larger projects which follow a general plan but include responses to specific urgent needs. However, similar situations appear on every level of workflows, even on the level of small activities performed by a single person as a step in a larger workflow. Usually, the necessity of ad-hoc activities on that level has been accounted to the occurrence of exceptions: events for which no organizational rules exist and new rules are needed (Saastamoinen and White 1995). Of course, exception handling, like most other cases of situated actions, do not occur in isolation. They normally are a part of a larger well-structured process which need not be disturbed by an ad-hoc handling of subactivities. Similarly, well-structured activities may occur as parts of a larger process which is organized in an ad-hoc way. Thus, the mixture of production and ad-hoc aspects is a ubiquitous phenomenon in organizational work. For the sake of clarity and due to the limited space I will use the small-scale example of requesting a registration number to illustrate my point in this paper. I will address the issue of scalability at the end of the paper. Consider the case of a purchase order. The 1
initiator usually needs some kind of registration number. Let us assume that it is assigned by the purchase department and must be requested. Note that this is only one specific instance of the generic case where an actor needs an input before proceeding with an activity. I will describe a new modeling mechanism and the corresponding support provided by information technology. However, I think that a crucial point for adaptive workflow support is the fact, that the process model is available during process execution and can be used and adapted by the workflow actors as a part of the actual work. Thus, the modeling mechanism cannot be designed purely according to the needs of process modeling. Its design must also be directed by the support services which will be provided to the actors for manipulating process models. Hence, I will describe the modeling mechanism together with the support features which motivated its design.
2 A Framework for Adaptive Workflows I present a specific modeling formalism for adaptive process schemes, the HieraStates formalism. This formalism is integrated in a larger context, the Object-oriented Activity Support Model (OOActSM). The OOActSM addresses already several aspects of adaptive workflows. Therefore I give a short description of this framework before I turn to the HieraStates formalism. A deeper description of the OOActSM is given by Teege (1996). In the OOActSM all activity instances are represented by objects which have subobjects for subactivities. A workflow instance corresponds to a tree of objects representing the activity-subactivity structure1 . This tree is not kept isolated from the actors in a central “workflow engine”. Instead, it may be accessed and modified by the actors, individually or collaboratively, with any required scheme of access rights and concurrency control. The actors may change the activity-subactivity structure of a process instance by creating additional subactivities manually, as needed, in an ad-hoc manner. The “workflow engine” becomes a “software agent” which manipulates the activity tree and invokes operations for executing activities in collaboration with the actors, usually accounting for the standard cases. Figure 1 depicts a part of the activity instance tree in the case of our purchase order. The object ord1 represents the whole purchase order workflow. The subactivity prep1 represents its preparation phase. The subactivity drn1 specifically represents determining the registration number. The objects in the tree provide the support facilities for the corresponding activities. Support facilities include time management, interfaces to tools, execution of primitive activities, communication channels, history management, and more. Since the facilities are ultimately programmed, any kind of support which is possible by information technology can be provided for an activity. The provided support facilities are specific for each activity instance. Here, OOActSM uses the model of fine-grained feature combination: all support facilities available in the system are broken up into fine-grained support features. These features can be freely 1
The tree may contain other objects representing arbitrary entities in the activity context, such as documents or actors, related by links and forming a hypertext-like structure.
2
ord1 Purchase Order
prep1
(subsequent phases)
Preparation Phase
drn1
(remainder of preparation)
Determination of Registration Number
Figure 1: Activity Instances in the Example
mixed for every object. The feature mix may be determined upon instance creation. However, it is also possible to add features later when their need is detected. Thus, the support features provided for a single activity instance may evolve over time, paralleling the activity’s execution. Moreover, the feature mix used for one activity instance can be reused for other activity instances later. The manual collaborative manipulation of the activity instance tree and the selection of support features for activity instances primarily provides support of ad-hoc activities. They are supported by specific features for modeling and executing, e.g., articulation work, conversations, multimedia communication links, goals, or causal dependencies. I will not discuss these kinds of features here any further, and instead turn to the characteristics of production workflows: the execution scheme. The main idea of using execution schemes in the OOActSM is that of treating execution schemes and parts of execution schemes as features. This has the following consequences:
Each activity instance on any level in the activity instance tree may or may not have an execution scheme. If each activity has a scheme, the usual hierarchical decomposition of the execution scheme results. However, it is also possible to freely mix activities with and without a prescribed way of executing them. The execution scheme may be associated manually with each activity instance. Hence it is possible to decide in an ad-hoc manner to include an additional subactivity which is performed according to a specific scheme. The execution scheme is broken up into small parts and these parts are represented as single features. Thus execution schemes can be composed by mixing the corresponding features. As for other features, this may be done upon instance creation or incrementally while the instance is performed. Since the user has direct access to the activity instance tree, it is possible to choose manually among different possible paths in an execution scheme. 3
Execution scheme of ord1: verify
order
need
ordered goods await
prepare
prepared
supplier-selected
nished invoice await receive
receive
choose-supplier
received
tenders-and-select
received
Execution scheme of prep1: reg-num
initial
ll-form
number-ready
send-form
form-ready
nished
Execution scheme of drn1: request initial
expected
set-manually receive
noanswer
nished
Figure 2: Execution Schemes in the Purchase Order Example
In the remainder of this paper I will describe HieraStates, a mechanism for representing execution schemes which has been developed for use in the OOActSM. I will describe in some detail the composition of scheme parts and the manual selection of alternative paths. Note, that these possibilities provide a milder form of ad-hoc choice than the case in which no execution scheme is used at all. Hence, they address the case where ad-hoc and production aspects are not just mixed by mixing corresponding subactivities in the same workflow. They address the case where a single activity is performed in a way which lies somewhere between ad-hoc and schematic. The HieraStates mechanism is described in detail by Teege (1994).
3 Normal Execution HieraStates execution schemes are state-transition diagrams where a state may contain subdiagram(s) describing the object’s possible behavior in more detail while it is in the corresponding state. Figure 2 depicts the schemes associated with the three instances of Figure 1. The particulars of the schemes have been adapted from a real world example 1
4
described by Saastamoinen and White (1995). The example shows alternative paths leading from state prepared to supplier-selected and it shows independent subdiagrams in state ordered. Performing the transition prepare for activity ord1 includes creating and performing the subactivity prep1. Performing the transition reg-num for activity prep1 includes creating and performing the subactivity drn1. These relations between transitions and subactivities are not yet included in the graphical diagram representation, however, they are supported by the implementation. Transitions may be invoked manually through a corresponding user interface, or automatically by a programmed agent in response to certain events or conditions. In the case of determining the registration number we assume that the transition request is invoked manually by the initiator of the purchase order. A transition in HieraStates is usually associated with an operation which is executed when the transition is performed. In our example the transition request will pass the request to the purchase department, e.g., by composing and sending a corresponding electronic mail. Operations are currently specified by programming them and they do not show up in the diagrams. Future versions of HieraStates will identify more high-level specification mechanisms for operations which can be depicted as parts of the diagrams. The state expected models the state of the subactivity drn1 after requesting the number from the purchase department. The state contains two substates, modeling the state of the request. In state noanswer the request is not yet answered, in state finished the number is known and stored in an attribute of the activity instance drn1. The two states are connected by the transition receive. This transition is implemented by accessing the answer received from the purchase department, extracting the number and storing it into the attribute. The state noanswer is the initial substate of the state expected. It is entered when the transition request enters the state expected. The sequence initial – noanswer – finished constitutes the normal execution of determining a registration number in our example.
4 Handling Exceptions Barthelmess and Wainer (1995) define an exception to be any departure of a work case from its prescribed flow. Hence, exceptions occur only on the activity instance level. There are also exceptions which can be expected in advance. Then they may be added to the execution scheme as a possible path. However, Abbott and Sarin (1994) note that this tends to make the scheme unwieldy and hard to understand.
4.1 Expected Exceptions HieraStates supports modeling expected exceptions with the help of transitions which may be invoked in several states. In the example the additional transition set-manually may be used to handle some exceptional situations. This transition starts in the state expected. Hence, it is applicable in every substate of expected. However, it is a “local transition” and does not leave the state expected. Instead, it specifies the substate finished to be entered. This is a typical way of specifying exception handling: defin5
ing a mechanism for escaping from an arbitrary state and reaching a specific state. As the example demonstrates, the HieraStates formalism extends this concept. It allows the designer to restrict the escaping mechanism to a group of states. In the example, the transition set-manually may be used to escape from any substate of expected to the substate finished. However, it may not be invoked in the state initial. The execution scheme guarantees that the exception handling mechanism is only available after requesting the registration number. The transition set-manually is implemented by interactively entering the registration number and storing it in the attribute. It is useful in the following exceptional situations: 1. The purchase department does not answer and the number has been determined in some other way. The number may be entered by invoking set-manually in the state noanswer. 2. The number must be replaced after setting it. The new number may be entered by invoking set-manually in the state finished. 3. The purchase department sends an unexpected answer which does not contain the registration number. In this case the transition receive will stop before entering the state finished. After determining the number in some other way, it may be entered by invoking set-manually in this “stopped in transition” situation. In all three cases, as a result of exception handling the task drn1 is in the state finished and it has a defined registration number attribute. Hence, after exception handling, the activity may proceed as if the exception had never occurred. The third case demonstrates an additional feature of the HieraStates formalism. The implementation of a transition method may actuate a stoppage of the transition between its starting state and its destination state. If the transition receive is stopped, the task is not in any substate of the state expected. However, the task is still in the surrounding state expected. Hence, the transition set-manually is still applicable. The possibility to stop a transition is an important way in which the system can react to exceptional situations which prevent the completion of an operation. If a part of the operation has already been performed, neither the starting state nor the destination state of the transition is adequate for the task. Stopping the task “in the transition” correctly models the situation. The hierarchical states of the HieraStates formalism are an important means for handling this situation. Although no transition on the same level as the stopped transition may be invoked, there is always a surrounding state, such as the state expected. All transitions starting in this state are still applicable and may be invoked for handling the situation.
4.2 Unexpected Exceptions Unexpected exceptions are not reflected in the execution scheme. They must be treated in an ad-hoc manner on the instance level, typically by manually creating additional subactivities. The subactivities, however, may have an associated scheme. If this is the case, only selecting the features for the additional subactivity and its creation is done in an ad-hoc manner. The situation is then handled according to the subactivity’s scheme. 6
... drn1 dd1
drn2
Figure 3: Adding Subactivities to drn1
In the example, the transition set-manually handles only part of the exception; it does not include determining the registration number. Imagine that the case 3 from above occurs because the number must be requested from some other department. This may be handled with the help of two manually created subtasks of drn1: a task dd1 for determining the department, and a task drn2 for requesting the number. Note, that drn2 is of the same type as drn1, thus it may employ the same features, and, in particular, the same execution scheme. When drn2 is in state finished, the registration number may be retrieved from drn2’s attribute and may be transferred to drn1’s attribute with the help of set-manually. Although the manual subtask drn2 has no connection to the execution scheme of the main task drn1, there are two important differences between the concept of a manual subtask and the concept of simply escaping from the scheme and handling the exception manually, without support by the system. First, the subtask itself has its own execution scheme. The execution of the manual subtask is fully supported by the system, only its integration with the main task must be done manually. Second, the exception handling is represented as a subtask of the main task. The subtask is statically associated with the main task in the same way as regular subtasks are associated with it (see Figure 3). This results in a similar, yet more general mechanism for associating exception handling with predefined steps, as it is described by Agostini, Michelis, Grasso, and Patriarca (1993) for the combination of WooRKS and UTUCS.
5 Modifying Execution Schemes Until now, I have only described how to work with a static predefined execution scheme, i.e., with a diagram resulting from a specific feature mix. Let’s call the third diagram in Figure 2 ReqNum. Now consider the case in which, for some reason, the registration number is already known before the request is performed. The transition request cannot be used if we want to avoid the unnecessary request. Another way of switching from state initial to the state expected is needed, such as the transition expect-manually in the scheme ManNum, as depicted in Figure 4. This scheme specifies another kind of task than the scheme ReqNum. The number is not requested, it is determined in some other way and then entered manually. The schemes ManNum and ReqNum have several common aspects. Both define variants of the task “determine registration number”, and they have a related structure. It is useful 7
expect-manually expected initial
set-manually
noanswer
nished
Figure 4: Execution Scheme ManNum
expected initial
set-manually
noanswer
nished
Figure 5: Execution Scheme DetNum
to extract the similarities and to put them into a separate scheme DetNum as depicted in Figure 5. The HieraStates formalism supports the reuse of the execution scheme DetNum by modeling the differences between DetNum and the other two schemes as features which may be added to DetNum. The scheme ReqNum results by adding the transitions request and receive, the scheme ManNum results by adding the transition expect-manually. Moreover, as soon as the specific extensions of DetNum are modeled as separate features, they can be combined, resulting in the scheme depicted in Figure 6. The inclusion hierarchy of states in the HieraStates formalism has been an important prerequisite for defining this kind of scheme combination in a useful and general manner. Modeling parts of execution schemes as features supports the incremental specification of schemes. Scheme parts can be combined in a toolkit-like manner. The user can modify the scheme of a specific work case by adding features to the corresponding object.
expect-manually request initial
expected noanswer
set-manually receive nished
Figure 6: Combination of Execution Schemes 1ReqNum and ManNum
8
This is possible at any time, even if the work case has already proceeded to a certain point in the scheme. For instance, consider a work case using the scheme ReqNum, which stops in the transition request due to problems in sending the request. Then it is possible to add the feature corresponding to the scheme ManNum, thus extending the scheme to that depicted in Figure 6. Then the transition expect-manually can be used to proceed without a request. Note, that in general it is necessary to adapt the instance’s current state to a change in its execution scheme. The HieraStates formalism includes an intricate mechanism for automatically adapting the current state of an instance to changes in its execution scheme. The mechanism handles all kinds of situations and works even in the presence of stopped transitions. It is described in detail by Teege (1994). Extending the scheme of an existing instance through the addition of predefined parts complements the use of manual subtasks in a useful way. It supports the specification of several ways of handling exceptions for a kind of task, without the need for integrating all of them into the scheme of every instance. When an exception occurs for an instance, one way of handling the situation may be selected and added to the scheme.
6 Summary and Discussion HieraStates and its integration in the OOActSM is a fairly complex mechanism, providing several different means to support adaptive workflows. Stepping back from the example presented in the previous sections, I now give a summary of the mechanism’s different ways of application. These can roughly be grouped into three aspects: The kind of scheme, how the scheme is specified for an activity, and how the scheme is used. The kind of scheme determines the degree to which a specific semantics is imposed on the activity: 1. No scheme: The semantics is determined by the operations available for the activity. The user may decide when each operation should be invoked and how often it is applied. 2. Scheme not connected to operations: The scheme is used as a memory aid for the user. The semantics of the states and transitions is only informal and must be known by the user. 3. Scheme with transitions connected to subactivities: Performing a transition corresponds to performing one or more explicit subactivities. The degree of semantics depends on the amount of features specified for the subactivities. 4. Scheme with transitions connected to operations: Performing a transition corresponds to performing a specific operation implemented by the system. The semantics of the transition is operationally fully specified. Of course, all four cases may also be mixed. Some transitions may be connected to operations, some may be connected to subactivities, some may be unconnected, and there may be operations which can be invoked independent from the scheme. The next aspect is the way in which the scheme is specified for an activity: 9
1. Automatically specified upon creation by the surrounding activity: the scheme is determined by the system depending on the activity’s context. 2. Manual selection upon creation: the user selects the scheme from a number of possible alternatives. 3. Manual composition upon creation: the user composes the scheme from a number of scheme parts. 4. Incremental composition while the activity is performed: the user adds scheme parts when they are needed. Again, these cases can be mixed. A scheme specified by the surrounding activity may be extended manually by additional parts, either upon creation of the activity or incrementally. In general, a scheme comprises several alternative ways of performing the activity. The structure of the HieraStates schemes allows different ways of selecting among these alternatives: 1. Selecting alternative transitions starting in the current state. This corresponds to different “normal” continuations in the activity. 2. Selecting transitions starting in states surrounding the current state. This corresponds to handling the situation that there is no “normal” continuation. 3. Selecting transitions starting in surrounding states after a transition has stopped and could not be completed. This corresponds to handling an erroneous situation by “resetting” the state in a controlled manner. The complexity provides a great deal of flexibility. On the other hand it becomes a drawback if the user is not guided. This problem is not restricted to the HieraStates mechanism, it is a more general problem in the OOActSM. A user can design useful feature mixes only if he understands the feature’s semantics and how they work together. There must be tools which guide the user in composing a feature mix. They must help conveying the semantics of features, identifying features useful for the user’s goals, and providing feedback about the properties of a composed feature mix. Since features may correspond to very different kinds of object properties, we assume that different tools are needed, specialized to different kinds of features. One such kind are features corresponding to HieraStates scheme parts. In the case of HieraStates schemes there are at least two levels of understanding by the user: The user must understand how certain features are related to the structure of the scheme and the user must understand the semantics of the states and transitions in the resulting scheme. HieraStates is by its nature a visual formalism. Hence, it is straightforward to base tools supporting the composition of its schemes on an adequate visual representation. The hierarchical and modular structure of the schemes additionally support their flexible visualization. However, due to the extreme flexibility of the connection between the scheme and the semantics of its states and transitions, we have not yet found a visual representation of this connection. We do not expect a general solution to this 10
problem, instead we will try to identify typical patterns of this connections and visualize these specific cases. Additional complexity results on the instance level: an activity tree may become rather large and the information contained in it is distributed among the nodes. However, in this case the complexity has two advantages: it provides abstraction and scalability. If an activity tree is well structured, each level provides an abstract view of the underlying levels. Consider the schemes depicted in Figure 2. The scheme of ord1 gives a rather coarse view of the activity, abstracting from the details given in the two other schemes. The resulting levels of abstraction, stemming from the structure of the activity tree, must be complemented by tools supporting a flexible visualization and navigation in the tree. The mechanism is suited for activities of all scales. Large activities do not mean complex objects or large execution schemes. Instead, they simply correspond to deeper activity trees where the objects occurring on different levels may roughly be of the same complexity. Moreover, since the support functionality is associated with the objects, each level may provide its own adequate kind of support. For instance, a level corresponding to a whole project may provide project management support while levels corresponding to small subactivities provide specialized support for individual or collective execution. Note, however, that the OOActSM and HieraStates only provides the technical basis for representing an activity on different levels of abstraction. They do not include a methodology for finding appropriate levels for a specific kind of activity and for associating the adequate support functionality with it.
7 Related Work When comparing the HieraStates formalism with existing systems for workflow support, we must respect the fact that the HieraStates formalism covers only one (although important) aspect of those systems: the execution scheme. In a complete system for activity support, the formalism must be complemented with the means for providing a task context containing, e.g., documents, means for protocoling and accessing a task history, etc.. Hence, we will look at existing systems only with respect to their mechanisms for dealing with an execution scheme. In particular, HieraStates can be used both in folder based systems, such as ProminanD (Karbe, Ramsperger, and Weiss 1990), and in process based systems, such as Regatta. Moreover, it can be applied to help a user in the structuring of his private non-collaborative tasks. The Action Workflow system (Medina-Mora et al. 1992) is one of the most prominent current industrial systems. Its execution schemes are based on the specific form of “request loops”. The scheme is only used by the workflow management server and by workflow management applications. A user executing a subtask is not directly led by the execution scheme, hence the schemes do not support user reactions to exceptional or unstructured situations. The schemes cannot be modified during task execution and they cannot be configured to individual needs. The system Regatta (Swenson 1993; Swenson et al. 1994) is an experimental sys11
tem which tries to integrate collaborative planning of task execution with the execution itself. The user directly works with a visual representation of the execution scheme. The system supports manually created subtasks which are integrated into the current scheme. Schemes may be instantiated from scheme templates, however, templates or template parts cannot be reused and combined. The nodes (“stages”) in a scheme correspond to the transitions in HieraStates diagrams. There is no direct equivalent to HieraStates’ states, hence a grouping of states for preplanned exception handling is not possible. Finally, in Regatta the scheme and context of a task are always shared by all participants. This is usually a good choice in small or medium-sized groups. However, it prohibits privacy issues for parts of a task. These are important for tasks involving several organizations. In HieraStates a task object may be shared or private, using asynchronous communication for accessing other task objects in the latter case. The system InConcert (Abbott and Sarin 1994) is similar, however, it is more specialized to document processing. Its underlying model (Sarin, Abbott, and McCarthy 1991) focuses mainly on tasks which manipulate linked documents. No specific means for exception handling other than manual subtasks are supported. An important theoretical base of execution scheme specification are petri nets. Their general expressiveness is similar to HieraStates, however, they lack a hierarchical structure. There are approaches which extend petri nets with a hierarchical structure for using them in workflow support (Keller, Shen, and v. Bochmann 1994; van der Aalst, van Hee, and Houben 1994), however, they do not employ reuse and combination. Ellis and Rozenberg (1995) treat the dynamic change of petri net based schemes. Similar to HieraStates it is possible to apply modifications in the scheme immediately to running activities. Victor and Sommer (1991) use a petri net based mechanism for planning a task. After the planning phase the net is translated into a procedural workflow language for execution and cannot be modified any more. The HieraStates formalism has been strongly influenced by the Statechart formalism of Harel (1987). Statecharts have been developed for specifying the behavior of reactive systems, i.e., event-driven systems. Like HieraStates they use an inclusion hierarchy of states and they associate operations with transitions. However, state charts are only used in the design phase of a system, not for interacting with the user at run-time. As a consequence, an important aspect of Statecharts are capabilities for representing nondeterminism. These are omitted in HieraStates. Instead, capabilities for handling exceptions and unstructured situations have been realized in HieraStates. These are not present in Statecharts. Moreover, although the idea of refinement is central to Statecharts, it is not used in the form of features for producing and combining execution schemes.
8 Conclusion and Outlook I have presented the most important capabilities of our new mechanism HieraStates for specifying task execution schemes in a flexible and adaptable manner. The mechanism is only one aspect which is smoothly integrated in the larger framework of the OOActSM. It has been specifically developed for specifying the possible ways of execution for activities which are neither executed in a fully schematic way, neither in a fully ad-hoc way. 12
The OOActSM has been implemented in our prototype system TACTS. In its current state it contains a full implementation of the HieraStates mechanism including run-time support and a language for scheme specification. Starting from this technical basis we will investigate (graphical) tools for working with the schemes. We will also apply the mechanism to several different kinds of real-world activities with the goal of developing a toolkit of useful scheme parts and a methodology for their application and composition.
References Abbott, K. R. and S. K. Sarin (1994). Experiences with Workflow Management: Issues for the Next Generation. In R. Furuta and C. Neuwirth (Eds.), Proc. of the Conf. on Computer Supported Cooperative Work CSCW’94, New York, pp. 113–120. ACM Press. Agostini, A., G. D. Michelis, M. Grasso, and S. Patriarca (1993, November). Reengineering an Business Process with an Innovative Workflow Management System: A Case Study. In S. Kaplan (Ed.), Proc. of the Conf. on Organizational Computing Systems COOCS’93, pp. 154–165. ACM: ACM Press. Barthelmess, P. and J. Wainer (1995). WorkFlow Systems: a few definitions and a few suggestions. In N. Comstock and C. Ellis (Eds.), Proc. of the Conf. on Organizational Computing Systems COOCS’95, New York, pp. 138–147. ACM Press. Ellis, C. and G. Rozenberg (1995). Dynamic Change Within Workflow Systems. In N. Comstock and C. Ellis (Eds.), Proc. of the Conf. on Organizational Computing Systems COOCS’95, New York, pp. 10–21. ACM Press. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming 8, 231–274. Karbe, B., N. Ramsperger, and P. Weiss (1990). Support of Cooperative Work by Electronic Circulation Folders. In F. Lochovsky et al. (Eds.), Conference on Office Information Systems (SIGOIS Bulletin). ACM. Keller, R. K., X. Shen, and G. v. Bochmann (1994). Macronet – A Simple yet Expressive and Flexible Formalism for Business Modelling. In G. D. Michelis, C. Ellis, and G. Memmi (Eds.), Computer-Supported Cooperative Work, Petri Nets and related formalisms. Proc. of workshop within the 15th Int. Conf on Applications and Theory of Petri Nets, Zaragoza, June 94, pp. 51–56. Medina-Mora, R. et al. (1992, Nov). The action workflow approach to workflow management technology. In Proc. of the Conf. on Computer Supported Cooperative Work CSCW’92. Saastamoinen, H. and G. M. White (1995). On Handling Exceptions. In N. Comstock and C. Ellis (Eds.), Proc. of the Conf. on Organizational Computing Systems COOCS’95, New York, pp. 302–310. ACM Press. Sarin, S. K., K. R. Abbott, and D. R. McCarthy (1991, November). A Process Model and System for Supporting Collaborative Work. In P. de Jong (Ed.), Proc. of the 13
Conf. on Organizational Computing Systems COOCS’91, pp. 213–224. ACM: ACM Press. Swenson, K. D. (1993, November). Visual Support for Reegineering Work Processes. In S. Kaplan (Ed.), Proc. of the Conf. on Organizational Computing Systems COOCS’93, pp. 130–141. ACM: ACM Press. Swenson, K. D. et al. (1994). A Business Process Environment Supporting Collaborative Planning. Collaborative Computing 1(1), 15–34. Teege, G. (1994, December). Hierastates: Flexible interaction with objects. Technical Report TUM–I 9441, Inst. f¨ur Informatik, Technische Universit¨at M¨unchen, Munich, Germany. also available from URL http://www11.informatik.tumuenchen.de/. Teege, G. (1996). Object-oriented activity support: A model for integrated cscw systems. Computer Supported Cooperative Work 5(1), 93–124. van der Aalst, M. P., K. M. van Hee, and G. J. Houben (1994). Modelling and analysing Workflow using a Petri Net based Approach. In G. D. Michelis, C. Ellis, and G. Memmi (Eds.), Computer-Supported Cooperative Work, Petri Nets and related formalisms. Proc. of workshop within the 15th Int. Conf on Applications and Theory of Petri Nets, Zaragoza, June 94, pp. 31–50. Victor, F. and E. Sommer (1991). Supporting the Design of Office Procedures in the DOMINO System. In J. M. Bowers and S. D. Benford (Eds.), Studies in Computer Supported Cooperative Work, Amsterdam, pp. 119–130. North-Holland.
14
