Database Reference
In-Depth Information
A COHESION METRIC FOR
WORKFLOW ACTIVITIES
Introduction
In software engineering, manipulations (declarations, assignments, invocations, etc.)
that are strongly related are preferably grouped together within the same module or class
(Stevens et al., 1974). There are clear implications for the maintainability and re-usability
of programs by using this approach and there is also considerable empirical evidence that
the resulting computer programs contain fewer errors (Card et al., 1986; Selby & Basili,
1991).
Workfl ow processes are in some sense similar to computer programs, as they primarily
involve
information processing steps
: checks, decisions, computations, copying, etc. Also,
in workfl ow processes the administration of information is often vital (customer data, order
information, etc.). Furthermore, workfl ow processes consist of activities, where computer
programs are divided into modules or classes. And where modules contain statements and
classes methods, activities consist of operations. For more information on the characteriza-
tion of workfl ow processes, we refer the reader to Reijers (2003).
Because of the advantages of cohesion metrics in software design and the rough simi-
larities between programs and workfl ow processes, it seems both fruitful and plausible to
pursue something similar to a software cohesion metric for the sake of activity defi nition
in workfl ow processes.
Activity Cohesion Metric
Prior to the formulation of the cohesion metric and the discussion of some examples,
we introduce its supporting notions. For the sake of clarity, we do not consider an entire
workfl ow process. Instead we directly zoom in on a part of the process for which it is unclear
how to defi ne activities, a so-called
operations structure
. We assume as given a sense of
operations
that take place within this part. Operations in our view can be seen as information
functions, which take as
inputs
zero or more pieces of information and produce one new
piece of information, its
output
. Consider, for example, a workfl ow that handles insurance
claims. The decision whether or not a claim is acceptable to be processed could be given
form in the following operation: Only when the claimant has not issued a claim earlier in
the same year (input 1) and the damage is covered according to the policy (input 2), then the
claim would be acceptable (output). Inputs 1 and 2 and the mentioned output can be seen as
information elements being inspected and manipulated by executing operations.
The above view on the elementary operations is also used in the workfl ow design
methodology Product-based Workfl ow Design (Reijers, 2003; Reijers et al., 2003), which
is tried and tested in several cases (De Crom & Reijers, 2001; Reijers, 2003).
The formal defi nition of an operations structure is now as follows.
Defi nition 1. (Operations Structure).
An operations structure is a tuple (
D
An operations structure is a tuple ( ,
O
) with:
An operations structure is a tuple (
D
D
: the set of information elements that are being processed,
•
•
O
= {(
p
= {( ,
cs
) ∈
D
×Π((( )} is a set of operations on the information elements, such that
there are no 'dangling' information elements and no value of an information element
depends on itself:
= {(
p
