1. Introduction
According to the Workflow Management Coalition (WFMC) [1]Workflow is concerned with the automation of procedures where documents, information or tasks are passed between participants according to a defined set of rules to achieve, or contribute to, an overall business goal. Whilst workflow may be manually organized, in practice most workflow is normally organised within the context of an IT system to provide computerized support for the procedural automation…
Use of workflow-based systems is typically said to lead to better use of staff as well as to better work, management, and productivity [2].
An investigation of current practices in workflow modeling supports the need for further research for improvement in this area. According to [3]Situation [of Workflow technology] is comparable to the early seventies in “databaseland” (ER-model by Chen 76, Relational model by Codd 70). Today’s [2007] situation: We need a conceptual model for WFM (Work flow management]! A unifying process modeling technique!
The first phase in building a workflow-based system is capturing a real-world process in a conceptual representation amenable to formalization and implementation. The representation may be specified in text or diagram form or written in a formal language. “The resulting definition is sometimes called a process model, a process template, process metadata, or a process definition… A process definition normally comprises a number of discrete activity steps, with associated computer and/or human operations and rules governing the progression of the process through the various activity steps.” [1]. A process may also be defined as “[consisting] of a number of tasks that need to be carried out and a set of conditions that determine the order of the task… Task is a logical unit of work that is carried out as a single whole by one resource” [2].
The notion of process is important in the context of workflow and appears in many terms such as business process reengineering, continuous process improvement, and business process management, and many modeling techniques and tools are used in conjunction with process, such as DFD, UML, and Petri nets. For example, [4] used UML activity diagrams as a workflow specification language.
Process modeling techniques are utilized for the purpose of gaining understanding and insight, facilitating analysis, and building a system [3]. An illustration of the relationship between process modeling and actual realization is shown in Figure 1.
This paper deals with this level of description, where the focus is on the methods of specification, the level of a process definition in which the required steps are specified in order of execution, as in a routing definition, and in workflow script, as in the cases of purchase order, insurance claims process, and so forth. The paper proposes
Figure 1. Process modeling techniques are used in many application domains (reformulated from [3]).
a flow-based diagrammatic methodology as a tool for workflow specification. The expressiveness of the method is appraised for its ability to capture workflow-based applications. We show that the proposed diagrams are able to express situations arising in practice as an alternative to tools currently in use for workflow systems.
2. Related Work
Information systems, including software systems, pass through a series of stages in their life cycles. In particular, the requirements phase in software engineering is very rich area, with multiple approaches to workflow specification and business process modeling. Accordingly, this section highlights only a few samples from these approaches in this field.
Process modeling is a central concept in this area. Workflow management (WfM) and business process modeling (BPM) are two ventures in the area of processoriented perspective with different emphases. Processes can be specified using control flow, hierarchical decomposition, and/or generic relations. In this paper our emphasis, without loss of generality, is on workflows.
The notion of workflow is more general than that of a process and consists of a series of connected steps, with an emphasis on the concept of flow.
Process specification is often based on networked activities, objects, transformations, and events utilized in developing more precise and formalized specifications. State charts [5], Petri nets [6], and activity diagrams [7] have been utilized by many studies. Issues of intuitiveness, ease, and rigorousness of semantics are discussed repeatedly in these works.
3. Sample Motivations
While several justifications can be given for venturing into a new modeling method for workflow-based applications, we present in this section, without loss of generality, one aspect that provides some motivations for our work.
In the workflow area, Control flow patterns are abstracted forms of recurring situations related to the ordering of activities and execution in a workflow [4,8,9]. The simplest of these patterns is the sequence pattern, which is an ordered series of activities, with one activity starting after a previous activity has been completed (see Figure 2). Other patterns include parallel, choice, and iteration patterns.
We believe that the sequence pattern embeds ambiguity in many current workflow diagrams in general. Further exposure of conceptual vagueness will be demonstrated by contrasting these workflow diagrams and our methodology using a sample descriptive schema.
According to White [10]The direction of the Sequence Flow arrowheads determines the order of the Sequence. The behavior of this pattern can be described by the use of a conceptual “Token” that travels down a Sequence Flow from the source object to the target object—as shown by the directionality of the arrows. For this pattern, when an activity completes, a Token will travel through the Sequence Flow from that activity to the next activity in the Sequence. There is no conditionality or any other type of control put upon the Token.
The arrow has overlapping semantics: control flow and token flow. Control is usually visualized as a process with input and output. Also, control is described as “the process of monitoring activities to ensure that they are being accomplished as planned and correcting any significant deviation” [11]. In UML, control is visualized in the context of the general notion of behavior, as follows:
Behavior models, in general, determine when other behaviors should start and what their inputs are... In particular, the UML 2 activity models follow traditional control and data flow approaches by initiating sub-behaviors according to when others finish and when inputs are available. It is typical for users of control and data flow to visualize runtime effect by following lines in a diagram from earlier to later end points and to imagine control and data moving along the lines. Consequently a token flow semantics inspired by Petri nets is most intuitive for these users, where “token” is just a general term for control and data values [12].
Notice how the “flow” is qualified by “control and data” and then connected to “token flow” in Petri nets. “Control flow,” or “flow of control,” is typically described as the order in which statements (of an imperative program), processes, operations, etc. are executed—but does “control” flow?
Little has been written about the concept of flow, as discussed in this paper. It is typically described in terms of steps “where each step follows the precedent without delay or gap and ends just before the subsequent step
Figure 2. Sequence—business process diagram.
may begin” [13]. In another perspective and according to [14]The word “flow” sprang up as the word fluxus in Latin, long before many of us can remember. Its root definition has remained intact, with the primary meaning “to move in a (steady) stream.” The cognitive image of a liquid is therefore fused into every metaphor using flow.
Returning to Figure 2, superimposing movement of control and flow of things is conceptually a poor practice. The arrow could represent movement of control, flow of things, or both.
1) Suppose that the token is created at B in Figure 2. Then the first arrow is a pure sequence of control, while the second arrow is both token and control flows.
2) It is possible that A generates tokens that flow to B, but not to C, hence, the B-C arrow is a pure control flow. This is analogous to tying an electrical station to current flow. Station A is turned on first, then B, then C. But this does not necessarily mean that current flows from A to B to C.
3) Conceptually, the token that flows from A to B is not necessarily the same token that flows from B to C. For example, an invoice is sent to B, who creates and sends a money order to C.
This discussion raises the issue of the roles of A, B, and C. It is possible that any of them creates, processes, sends, or receives tokens. In 1) above, B is the creator and sender of tokens, while, say, C is a processor. A is not in the flow path of the tokens. In 2), A is a creator and a processor (e.g., consumer) of tokens, while B and C are not “flow systems” with respect to the tokens.
Control in the workflow sequence pattern seems to indicate activation signals: execute A, then execute B, then execute C. Activation seems to mean doing something with tokens (else, why would tokens flow from A to B to C). Assuming one token, A creates the token, which is somehow processed in B and C. As we stated previously, the superimposing of control and token flows may indicate different semantics, such as B is the creator of the token.
Next we review our proposed flow-based methodology to be contrasted to the workflow diagrams. The described model has been used in many applications [15-17].
4. Flowthing Model
The Flowthing Model (FM) is a uniform method for representing things that flow, called flowthings. Flow in FM refers to the exclusive (i.e., being in one and only one) transformation among six states (also called stages) of transfer, process, create, release, arrive, and accept. All other states are not generic states. For example, we may have stored created flowthings, stored processed flowthings, stored received flowthings, etc. Flowthings can be released but not transferred (e.g., the channel is down), or arrived but not accepted…
The fundamental elements of FM are as follows.
Flowthing: A thing (e.g., information, material) that has the capability of being created, released, transferred, arrived, accepted, and processed while flowing within and between systems.
A flow system: (referred to as flowsystem) is depicted in Figure 3, showing the internal flows of a system with the six stages and the transactions among them.
Spheres and subspheres: Spheres and subspheres are the environments of the flowthing, such as a department, a computer, and a customer, which form the sphere of the flowthing.
Triggering: Triggering is a transformation (denoted by a dashed arrow) from one flow to another, e.g., a flow of electricity triggers a flow of air.
We will use Received as a single stage combining Arrived and Accepted whenever arriving flowthings are always accepted.
5. Example
Consider a complaint handling process as given in [18], where:
• An incoming complaint is recorded
• The client and the department affected are contacted (can be done in parallel)
• Afterwards, the data are gathered and a decision is taken
• Either (1) a compensation payment is made, or (2) a letter is sent.
• Finally, the complaint is filed.
Figure 4 shows modeling of complaint handling as a Petri net, but FM representation, as shown in Figure 5, reveals many flowthings in addition to the complaint. It “starts” when a customer creates a complaint (circle 1) that flows to the complaint department (2). There, it is processed (3) to trigger creation and sending of an initial response to the customer (4). Note that initial response is a different flowthing from the complaint; hence, a dashed arrow indicates a triggering, not a flow. In FM, “flowing