Parameterizable Views for Process Visualization [original]

Parameterizable Views for Process Visualization?

Ralph Bobrik1, Manfred Reichert2, and Thomas Bauer3

1Institute of Databases and Information Systems, Ulm University, Germany,

[email protected]

2Information Systems Group, University of Twente, The Netherlands,

[email protected]

3DaimlerChrysler Group Research & Adv. Engineering, GR/EPD, Ulm, Germany,

[email protected]

Abstract. In large organizations different users or user groups usually

have distinguished perspectives over business processes and related data.

Personalized views on the managed processes are therefore needed. Ex-

isting BPM tools, however, do not provide adequate mechanisms for

building and visualizing such views. Very often processes are displayed

to users in the same way as drawn by the process designer. To tackle

this inflexibility this paper presents an advanced approach for creating

personalized process views based on well-defined, parameterizable view

operations. Respective operations can be flexibly composed in order to

reduce or aggregate process information in the desired way. Depending

on the chosen parameterization of the applied view operations, in addi-

tion, different "quality levels" with more or less relaxed properties can

be obtained for the resulting process views (e.g., regarding the correct-

ness of the created process view scheme). This allows us to consider the

specific needs of the different applications utilizing process views (e.g.,

process monitoring tools or process editors). Altogether, the realized view

concept contributes to better deal with complex, long-running business

processes with hundreds up to thousands of activities.

1 Introduction

In order to streamline their way of doing business, companies have to deal with a

large number of processes involving different domains, organizations, and tasks.

Often, these business processes are long-running, comprise a large number of ac-

tivities, and involve a multitude of user groups. Each of these user groups needs

a different view on the process with an adapted visualization and a customized

granularity of information [1]. For example, managers usually prefer an abstract

overview of the process, whereas process participants need a more detailed view

on the process parts they are involved in. In such scenarios, personalized process

visualization is a much needed functionality. Despite its practical importance,

current BPM tools do not offer adequate visualization support. Very often, pro-

cesses are displayed to the user in more or less the same way as drawn by the

?This work has been funded by DaimlerChrysler Group Research

designer. There are some tools which allow to alter the graphical appearance of

a process and to hide selected process aspects (e.g., data flow). Sophisticated

concepts for building and managing process views, however, are missing.

In the Proviado project we are developing a generic approach for visualizing

large processes consisting of hundreds up to thousands of activities. To elabo-

rate basic visualization requirements we conducted several case studies in the

automotive domain [2]. This has led us to three dimensions needed for process

visualizations [3]. First, it must be possible to reduce complexity by discarding

or aggregating process information not relevant in the given context. Second,

the notation and graphical appearance of process elements (e.g., activities, data

objects, control connectors) must be customizable. Third, different presentation

forms (e.g., process graph, swim lane, calendar, table) should be supported.

This paper focuses on the first dimension, i.e., the provision of a flexible com-

ponent for building process views. Such a view component must cover a variety

of use cases. For example, it must be possible to create process views which

only contain activities the current user is involved in or which only show non-

completed process parts. Often, process models contain technical activities (e.g.,

data transformation steps) which shall be excluded from visualization. Finally,

selected process elements may have to be hidden or aggregated to meet confi-

dentiality constraints. To enable such use cases, the Proviado approach allows

to create process views based on well-defined, parameterizable view operations.

Basically, we distinguish between two kinds of view operations either based on

graph reduction or on graph aggregation techniques. While the former can be

used to remove elements from a process graph, the latter are applied to abstract

process information (e.g., by aggregating a set of activities to an abstract one).

Proviado allows to flexibly compose basic view operations in order to reduce or

aggregate process information in the desired way.

The realization of view operations is by far not trivial, and may require

complex process transformations. Regarding activity aggregations, for example,

they may be more or less complex depending on the set of activities to be

aggregated. In particular, the aggregation of not connected activities constitutes

a big challenge, which requires advanced aggregation techniques. Furthermore,

it is of fundamental importance that view properties (e.g., regarding the created

process view scheme) can be flexibly set depending on application needs. If

process visualization is in the focus, for example, these properties may be relaxed.

Opposed to this, more rigid constraints with respect to process views become

necessary if these views shall be updatable. In Proviado we achieve this flexibility

by the support of parameterized view operations.

The remainder of this paper is structured as follows: Section 2 gives back-

ground information needed for the understanding of this paper. In Section 3 we

introduce our theoretical framework for realizing parameterizable and config-

urable process views. Section 4 gives insights into practical issues and presents

a more complex example for defining and creating process views. Section 5 dis-

cusses related work. The paper concludes with a summary and an outlook in

Section 6.

UT V

N O

activity

AND split AND join

control flow edge

XOR split XOR join

branching condition

activity states:

completed

running

activated

SESE block

(Single Entry Single Exit)

Fig. 1. Example for a process instance

2 Backgrounds

We introduce backgrounds needed for the understanding of the paper. In a

process-aware information system each business process is represented by a pro-

cess scheme P; i.e., a process graph which consists of (atomic) activities and

control dependencies between them (cf. Fig. 1). For control flow modeling we

use control edge as well as structural activities (e.g., ANDsplit, XORsplit).

Definition 1. A process scheme is a tuple P= (N, E, EC, NT)where

–Nis a set of activities;

–E⊂N×Nis a precedence relation (notation: e= (nsrc, ndest)∈E)

–EC :E→Conds ∪ {True}assigns transition conditions to control edges.

–NT :N→ {Activity, ANDsplit, ANDjoin, ORsplit, ORjoin, XORsplit,

XORjoin}assigns to each node n∈Na node type NT (n);Ncan be divided

into disjoint sets of activity nodes A(NT =Activity) and structural nodes

S(NT 6=Activity) (N=A˙

∪S)

This definition only covers the control flow perspective. However, the view

operations presented in Sec. 3 consider other process aspects (e.g., data elements

and data flow) as well. Though loop backs are supported by our framework we

exclude them here; i.e., we only consider acyclic process graphs. Further, process

schemes have to meet several constraints: First, we assume that a process scheme

has one start and one end node. Second, each process scheme has to be connected;

i.e., each activity can be reached from the start node, and from each activity the

end node is reachable. Third, branchings may be arbitrarily nested. Fourth, a

particular path in a branching must be merged with an eligible join node (e.g.,

a branch following an XORsplit must not merge with an ANDjoin).

Definition 2 (SESE). Let P= (N, E, EC, NT )be a process scheme and let

X⊆Nbe a set of activity nodes. The subgraph P0induced by Xis called SESE

(Single Entry Single Exit) iff P0is connected and has exactly one incoming edge

and one outgoing edge connecting it with P.

At run-time new process instances can be created and executed based on

a process scheme P. Regarding the process instance from Fig. 1, for example,

activities Aand Bare completed, activities Cand Nare activated (i.e., offered

in user worklists), and activities Hand Kare running.

Definition 3 (Process Instance). A process instance Iis defined by a tuple

(P, NS, H)where

BCHK

IA PQ

UT V

N O

TUV

build view

Aggregate(B,C,H,K)

Aggregate(L,J)

Reduce(E,F,G)

Reduce(R,S)

Aggregate(T,U,V)

Fig. 2. Example for a process view

–Pdenotes the process scheme on which Iis based

–NS :N→ExecutionStates := {NotActivated, Activated, Running,

Skipped, Completed}describes the execution state for each node n∈N

–H=he1, . . . , enidenotes the execution history of Iwhere each entry ekis

related either to the start or completion of a particular process activity.

We informally summarize selected properties regarding the consistency of

instance states. For an activity n∈Nwith NS(n)∈ {Activated, Running}all

activities preceding neither must be in state Completed or in state Skipped, and

all activities succeeding nmust be in state NotActivated. Furthermore, there is

a path πfrom the start node to nwith NS(n0) = Completed ∀n0∈π.

3 View Fundamentals

We introduce basic view operations and argue about properties of resulting pro-

cess views. As a first example consider the process instance from Fig. 2a. Assume

that each of the activity sets {B, C, H, K},{J, L}, and {T, U, V }shall be ag-

gregated, i.e., each of them shall be replaced by one abstract node. Assume

further that activity sets {E, F, G}and {R, S}shall be "removed" from this

process instance. A possible view resulting from respective aggregations and

reductions is depicted in Fig. 2b. Generally, process views exhibit an informa-

tion loss when compared to the original process. As an important requirement

view operations should have a precise semantics and be applicable to both pro-

cess schemes and process instances. Furthermore, it must be possible to remove

process elements (reduction) or to replace them by abstracted elements (aggre-

gation). When building process views it is also very important to preserve the

structure of non-affected process parts. Finally, view building operations must

be highly parameterizable in order to meet application requirements best and to

be able to control the degree of desirable or tolerable information loss.

We first give an abstract definition of process view. The concrete properties of

such a view depend on the applied view operations and their parameterization.

Definition 4 (Process View). Let P= (N, E, EC, NT)be a process scheme

with activity set A⊆N. Then: A process view on Pis a process scheme

V(P) = (N0, E0, EC0, NT0)whose activity set A0⊆N0has been derived from P

by reducing and/or aggregating activities from A⊆N. Formally:

–AU=A∩A0denotes the set of activities present in Pand V(P)

–AD=A\A0denotes the set of activities present in P, but not in V(P);

either these are reduced or aggr. activities: AD≡AggrNodes ∪RedNodes

–AN=A0\Adenotes the set of activities present in V(P)but not in P. Each

a∈ANis an abstract activity aggregating a set of activities from A:

1. ∃AggrNodesi, i = 1, . . . , n with AggrNodes =

•

i=1,...,n

AggrNodesi

2. There exists a bijective function aggr with:

aggr :{AggrNodes1, . . . , AggrNodesn} → AN

For a given process scheme Pwith corresponding view V(P)we introduce

function V Node :A→A0based on the notions from Def. 4. V Node(n)maps

each process activity n∈AU∪AggrNodes to a corresponding view activity:

V Node(c) = (c c ∈AU

aggr(AggrNodesi)∃i∈ {1, . . . , n}:c∈AggrNodesi

Further, for each activity c0∈A0,V Node−1(c0)denotes the corresponding ac-

tivity in the original scheme or the set of activities aggregated by c0.

In Proviado, a process view is created by composing a set of view building

operations: V(P) = Opn◦. . . ◦Op1(P). The semantics of the generated view is

then determined by these operations. Proviado uses a multi-layered operational

approach (cf. Fig. 8). There are elementary view operations of which each is

describing how a given set of activities has to be processed (e.g., reduce or

aggregate) considering a particular process structure (e.g., sequence of activities,

branching). On top of this, basic view operations are provided which analyze the

structure of the activity set and then decide which elementary operations have

to be applied.

3.1 Views Based on Graph Reduction

One basic requirement for a view component constitutes its ability to remove

process elements (e.g., activities) if desired. For this purpose, Proviado provides

a set of elementary reduction operations as depicted in Fig. 3. Based on these

elementary operations, higher-level reduction operations (e.g., for removing an

arbitrary set of activities) can be realized. Usually, reduction is applied if ir-

relevant information has to be removed from a process scheme or confidential

process details shall be hidden from a particular user group.

In the following we characterize the view operations based on different formal

properties. Reduction of activities always comes along with a loss of information

AED F

RedComplBranch

A Z

SESEC D EBA

A E

RedSequence RedSESE c)

Fig. 3. Different elementary reduction operations

while preserving the overall structure of the remaining activities (i.e., the activ-

ities being present in the original process scheme as well as the view scheme).

The latter property can be expressed taking the notion of order preservation.

For this purpose we first introduce a partial order relation (⊆N×N) on the

process scheme Pwith n1n2:⇔ ∃ path in Pfrom n1to n2.

Definition 5 (Order-preserving Views). Let P= (N, E, EC, NT)be a pro-

cess scheme with activity set A⊆Nand let V(P)=(N0, E0, EC0, NT 0)be a

view with actvities A0⊆N0. Then: V(P)is denoted as order-preserving iff

∀n1, n2∈A:n0

1=V Node(n1)∧n0

2=V Node(n2)∧n1n2⇒ ¬(n0

2n0

This property reflects the natural requirement that the order of two activ-

ities in a process scheme must not be reversed when building a corresponding

view. Obviously, the elementary reduction operations depicted in Fig. 3 are or-

der preserving. More generally, this property is basic for the integrity of process

schemes and corresponding views. A stronger notion is provided by Def. 6. This

stronger property is also met by reduced views. As we see later, however, there

are view operations which do not comply with the property specified by Def. 6.

Definition 6 (Strong Order-preserving Views). Let P= (N, E, EC, NT)

be a process scheme with activity set A⊆Nand let V(P) = (N0, E0, EC0, NT 0)

be a corresponding view with A0⊆N0. Then: V(P)is strong order-preserving

iff ∀n1, n2∈A:n0

1=V Node(n1)∧n0

2=V Node(n2)∧n1n2⇒n0

1n0

We first look at elementary reduction operations (cf. Fig. 3). The reduction

of an activity sequence (RedSequence) is realized by removing the respective

activities from the process scheme and by adding a new control edge instead.

Reduction of a SESE block (cf. Fig. 3b) is performed similar to RedSequence.

Since there are only two edges connecting the block with its surrounding, the

SESE block is completely removed and a new edge between its predecessor and

successor is added. In order to reduce not connected activity sets the basic view

operation Reduce is provided. Reduction is performed stepwise. First, the ac-

tivities to be reduced are divided into subsets, such that each sub-graph induced

by a respective subset is connected. Second, to each connected sub-graph, the

operation RedSESE is applied; i.e., Reduce is based on the reduction of con-

nected components using the elementary operation RedSESE. The algorithms we

apply in this context are generic, and can therefore result in unnecessary process

elements, e.g., non- needed structure nodes, empty paths in a parallel branching,

etc. Respective elements are removed in Proviado afterwards by applying well-

defined graph simplification rules to the created view scheme. Note that this is

ED A

p s

p t

A F

AED F

A ED F

r s

Fig. 4. Examples of Process Graph Simplification Rules

not always straightforward. For example, when reducing a complete branch of a

parallel branching, the resulting control edge can be removed as well. As opposed

to this, in case of an XOR- or OR-branching the empty path (i.e., control edge)

must be preserved. Otherwise an inconsistent process scheme would result (cf.

Fig. 3c). Similarly, when applying simplification rules to XOR- or OR-branchings

the respective conditions EC must be recalculated as depicted in Fig. 4.

3.2 Views Based on Graph Aggregation

As opposed to reduction-based views the aggregation operation aims at summa-

rizing several activities into one abstracted activity. Depending on the concrete

structure of the sub-graph induced by the set of activities to be aggregated,

different graph transformations may have to be applied. In particular the aggre-

gation of not connected activity sets necessitates a more complex restructuring

of the process graph. Fig 5a-c show the elementary operations for building aggre-

gated views. Elementary operations for activity sets contained within branching

structures are shown in Fig. 5f-g. All these elementary operations follow the

same policy to substitute the activities in-place with the abstract one if possible

and maintaining the order-preservation. Note that in-place substitution is always

possible when aggregation a SESE block. Otherwise a new branch is added (with

additional split/join nodes if needed; cf. Fig 5c). Alternatively, the aggregation

of not connected activities, as illustrated in Fig. 5d, can be handled by two sep-

arate elementary operations of type AggrSequence. Note that this alternative is

handled by more complex (i.e. higher level) operations as will be explained in

Section 4.

When aggregating activities directly following/preceding a split/join node

there exist two alternatives for aggregating the activities (cf. Fig. 5e). Alter-

native 1 aggregates the activities applying AggrAddBranch, alternative 2 shifts

the activities in front of the split node (AggrShiftOut). We discuss differing

properties of the resulting views later.

All presented operations except AggrAddBranch are strong order-preserving.

AggrAddBranch violates this property as, for example, the order relation DE

is not maintained when applying this operation (cf. Fig. 5c).

Before further investigating properties of aggregation operations we need the

following definition.

C D EBA

A EBCD

AggrSequence

C D FBA E

D FA

BCE

AggrAddBranch

A Z

SESE

AggrSESE c)

D FA E’BC

AggrSequence AggrSequence

Alternative 1:

Alternative 2:

AggrAddBranch

AggrShiftOut

CFBD

HED

AGF H

r s

AggrComplBranches

BCDE

r s CD

AggrAddBranch

Fig. 5. Different elementary aggregation operations

Definition 7 (Dependency set). Let P= (N, E, EC, NT)be a process scheme

with activity set A⊆N. Let further DP⊆A×A. Then DPis denoted as depen-

dency set. It contains all direct and indirect control flow dependencies between

activities.

DP={(n1, n2)∈A×A|n1n2}

We are interested in the relation between the dependency set of a process

and a related process view. For this purpose, let DPbe the dependency set of P

and DV(P)the dependency set of view V(P)on P. We further need a projection

of the dependencies from V(P)on Pdenoted by D0

V(P). It can be derived by

substituting the dependencies of the abstract activities by the dependencies of

the original activities. As example consider AggrShiftOut in Fig. 5e. We obtain

DP={(A, B),(B, C),(C, F),(A, D),(D, E),(E, F )}and DV(P)={(A, BD),

(BD, C),(BD, E),(C, F),(E, F)}. Further D0

V(P)={(A, B),(B, C),(D, C),

(C, F ),(A, D),(B, E),(D, E),(E, F)}holds. As one can see D0

V(P)contains ad-

ditional dependencies. We denote this property as dependency generating.

Calculation of D0

V(P):For n1∈AN,n2∈A0: remove all (n1, n2)∈DV(P); insert {(n, n2)|n∈

aggr−1(n1)}instead (analogously for n2∈AN); finally insert the dependencies between

AggrNodes, i.e. DP[AggrNodes] = {d= (n1, n2)∈DP|n1∈AggrNodes ∧n2∈AggrNodes}

We now can classify exactly what happens to the dependencies between ac-

tivities when building a view.

Definition 8 (Dependency relations). Let P= (N, E, EC, NT )be a pro-

cess scheme and let V(P)be a corresponding view. Let DPand D0

V(P)be the

dependency sets as defined above.

–V(P)is denoted as dependency erasing iff there exist dependency relations

in DPnot existing in D0

V(P)anymore.

–V(P)is denoted as dependency generating iff D0

V(P)contains dependency

relations not contained in DP.

–V(P)is denoted as dependency preserving iff it is neither dependency

erasing nor dependency generating.

Alternative 1:

Alternative 2:

AggrAddBranch

AggrShiftOut

C DBA

AggrSequence

RedSequence

H: ‹S(A),E(A),S(B),E(B),S(C)›

H’: ‹S(A),E(A)›

H: ‹S(A),E(A),S(B),E(B),S(C)›

H’: ‹S(A),E(A),S(BC)›

Fig. 6. View operations for process instances

Taking this definition it should be clear that every reduction operation is de-

pendency erasing. When aggregating activities there exist elementary operations

of all three types. In Fig. 5, for instance, AggrSESE is dependency preserving;

by contrast AggrAddBranch is dependency erasing since (B, C)/∈D0

V(P); finally,

AggrShiftOut is dependency generating: (B, E)∈D0

V(P).

Theorem 1 explains the relation of dependency properties (cf. Def. 8) and

order-preservation (cf. Def. 5).

Theorem 1 (Dependencies and order preservation). Let P= (N, E, EC,

NT )be a process scheme and V(P)a corresponding view. Then:

–V(P)is dependency erasing ⇒V(P)is not strong order-preserving

–V(P)is dependency preserving ⇒V(P)is strong order-preserving

The proof of Theorem 1 follows directly from the definition of the properties and

the dependency sets and is omitted here. In summary, we have presented a set of

elementary aggregation operations. Each of them fits for a specific constellation

of the activities to be aggregated. In Sec. 4.2 we describe how these operations

can be combined to more complex operations taking advantage of the discussed

properties.

3.3 Applying Views to Process Instances

So far we have only considered views for process schemes. In this section we

additionally deal with view on process instances (cf. Def. 3). When building

respective instance views the execution state of the created view, i.e. states of

concrete and abstract activities, must be determined and the "history" for the

instance view has to be adapted. Examples are depicted in Fig. 6a (reduction)

and Fig. 6b (aggregation). The following function V NS calculates the state of

an abstract activity based on the states of the underlying activities.

V NS(X) =











NotActivated ∀x∈X:NS(x)/∈ {Activated, Running,

Completed} ∧ ∃x∈X:NS(x) = NotActivated

Activated ∃x∈X:NS(x) = Activated ∧

∀x∈X:NS(x)/∈ {Running, Completed}

Running ∃x∈X:NS(x) = Running ∨

∃x1, x2∈X:NS(x1) = Completed ∧

(NS(x2) =NotActivated ∨NS(x2)=Activated)

Completed ∀x∈X:NS(x)/∈ {NotActivated, Running,

Activated}∧∃x∈X:NS(x) = Completed

Skipped ∀x∈X:NS(x) = Skipped

Definition 9 (View on a Process Instance). Let I= (P, NS, H)be an in-

stance of process scheme P= (N, E, EC, NT ). Let further V(P) = (N0, E0, EC0,

NT 0)be a view on Pwith AggrNodes and RedNodes as corresponding aggre-

gation and reduction sets (cf. Def. 4).

Then: A view V(I)on Iis a tuple (V(P), NS0,H0)with

–NS0:N0→ExecutionStates with NS0(n0) = V NS(V Node−1(n0)) assigns

to each view activity a corresponding execution state.

–H0is the reduced/aggregated history of the instance. It is derived from Hby

(1) removing all entries eirelated to activities in RedNodes and (2) for all j:

replacing the first (last) occurrence of a start event (end event) of activities

in AggrNodesjand remove the remaining start (end) events.

Examples of instance views with corresponding history are depicted in Fig. 6a-b.

Fig. 6c shows the example from Fig. 5e with execution states added. Inter-

estingly, applying AggrShiftOut yields an inconsistent state as two subsequent

activities are in state Running. For characterizing this situation consider Def. 10.

Definition 10 (State consistency). Let I= (P, NS, H)be a process instance

and let V(I)be a corresponding view on I. Then:

–V(I)is strong state consistent iff for all paths in V(I)from start to

end and not containing activities in state Skipped, there exists exactly one

activity in state Activated or Running.

–V(I)is state consistent iff for all paths in V(I)from start to end and

not containing activities in state Skipped, there exists not more than one

activity in state Activated or Running

Theorem 2 shows how state inconsistency is correlated with the degree of pre-

served of dependencies.

Theorem 2 (State consistency). Let Ibe a process instance and V(I)a cor-

responding view. V(I)is dependency-generating ⇒V(I)is not state-consistent.

Proof. Let I= (P, NS, H)be a process instance of process P= (N, E, EC, NT )

and V(I) = (V(P), NS0,H0)a view on Iwith V(P) = (N0, E0, EC0, NT0)

dependency-generating. Then there exist n0

1, n0

2∈N0in between of which V

generated a dependency, i.e. n0

1n0

2. Let n1=V Node−1(n0

1)∈Nand n2=

V Node−1(n0

2)∈N. Then holds n1n2. Further there are two paths in Pfrom

BCDEA

data

element

data flow

edge

optional data flow

AggrShiftOut

BA C

start: 01.08.2007

end: 05.08.2007

cost: 2500

start: 07.08.2007

end: 14.08.2007

cost: 4100

start: 06.08.2007

end: 07.08.2007

cost: 600

ABC

start: 01.08.2007

end: 14.08.2007

cost (sum): 7200

AggrSequence

start = min(ni.start)

end = max(ni.end)

cost = sum(ni.cost)

Aggregation Functions

Fig. 7. Aggregation of (a) data elements and (b) attributes

start to end through n1and n2. Therefore there exists a state of the base pro-

cess instances Iwith NS(n1) = Running and NS(n2) = Running. Thus also

NS(n0

1) = Running and NS(n0

2) = Running. Since there is a path from start

to end in V(P), that contains both n0

1and n0

2, follows the claim. ut

This theorem shows that an aggregation using AggrShiftOut always provokes

an inconsistent execution state while applying AggrAddBranch maintains a con-

sistent state.

Regarding the aggregation of process instances in Proviado we also deal with

the aggregation of collections of instances. Here multiple instances of the same

process scheme are condensed to an aggregated one in order to provide ab-

stracted information about business progress or to allow the calculation of key

performance indicators.

3.4 Further Issues

Due to space limitation this paper focuses on control flow views. Generally,

additional process aspects have to be covered including process data elements,

data flow, and the many attributes defined for the different process objects.

When building a process view, Proviado considers and processes these aspects

as well. Regarding data elements, for instance, Fig. 7a shows an example of a

simple aggregation. Here the data edges connecting activities with data elements

must be re-routed when aggregating {B, C, D, E}in order to preserve a valid

model. Similarly, when performing an aggregation operation activity attributes

must be processed as well by applied aggregation functions. Proviado offers a

variety of attribute aggregation functions in this context. In Fig. 7b, for example,

we applied a MIN-function to the aggregation set for determining start time, a

MAX-function for calculating end time, and a SUM-function for aggregating cost

attributes.

3.5 Discussion

The elementary operations presented so far allow to deal with all possible con-

stellations of activities to be reduced or aggregated. Regarding reduction the

completeness of the set of provided elementary operations is guaranteed by the

way not connected activity sets are split into connected subsets and by applying

RedSESE to the connected sub-graphs. Similarly, AggrAddBranch ensures com-

pleteness for aggregation. In Proviado basic view operations for dealing with the

different reduction and aggregation scenarios are provided on top of the stated

elementary operations. In particular, these basic operations analyze the positions

of the selected activities in a process scheme and determine the appropriate el-

ementary operation to build the view.

Table 1 gives an overview of the properties that can be guaranteed for the

different elementary operations. Based on this we can also argue about view

properties when applying a set of elementary operations. Further, in Proviado

we use these properties for parameterizing view operations, i.e. basic operations

may be expanded by a set of properties the resulting view schema. For instance,

when aggregating activities directly succeeding an AND-split (cf. Fig.5e) and

the resulting view has to be state-consistent, Alternative 1 (i.e. AggrAddBranch)

will be applied. Altogether the parameterization of view operations increases the

flexibility of our view concept and allows defining exactly what properties must

be preserved by view generation.

Of course, the parameters specified may be too strict, i.e. no elementary

operation can be found guaranteeing the compliance with desired properties

Sec. 4 introduces mechanisms for dealing with such scenarios.

4 View Application

So far we have presented a set of elementary and basic operations for manipulat-

ing a process schema when building a view. In practice, the user needs higher-

level operations hiding the complexity of view generation as far as possible. The

sketched basic view operations take as parameter a set of activities to be reduced

or aggregated and then determine the appropriate elementary operations to be

applied. What is still needed are view operations allowing for a predicate-based

specification of the relevant set of activities. Even operations with more inherent

intelligence are required, like "show only activities of a certain user".

In order to meet these requirements Proviado organizes view building opera-

tions in five layers (cf. Fig. 8). Doing so, operations at more elevated layers may

access all underlying operations. For defining a view the user or application can

make use of all operations provided in the different layers:

Table 1. Overview of elementary operations properties

Operation Properties

str. order

preserving

order

preserving

str. state

consistent

state

consistent

depend.

preserv.

depend.

erasing

depend.

generat.

RedSequence + + - + - + -

RedSESE + + - + - + -

AggrSequence + + + + + - -

AggrSESE + + + + + - -

AggrComplBranches + + + + + - -

AggrShiftOut + + - - - - +

AggrAddBranch - + + + - + -

High-level Operations

View Operations

Basic Operations

Elementary Operations

Primitive Graph Operations

Control Flow Attributes Application Data

Process

DeleteEdgeDeleteNode InsertEdgeInsertNode

AggrSequence AggrSESE

AggrComplBranch

AggrShiftOut RedSESE

AGGREGATECF REDUCECF

Aggregate Reduce

ShowMyActivities ...

AggrAddBranch Simplify

Data Flow Operat.

Attribute Operat.

Fig. 8. Organization of view operations

Primitive graph operations are used for inserting and deleting nodes and

edges at the process graph level. These operations build the bridge to the internal

representation of process schemes.

Elementary operations are tailored for a specific constellation of selected

activity set within the process scheme (cf. Sec. 3).

Basic operations receive a set of activities as input that has to be processed.

They analyze the structure of the activities inside the process scheme and select

the appropriate elementary operation.

View operations receive a predicate to determine the selected activity set. At

this level there exists exactly one view operation for aggregation and reduction

of control flow elements. The differentiation of layers basic and view becomes

clear when considering operations for data flow and attributes (cf. 3.4).

High-level operations are independent from aggregation or reduction. They

combine lower-level reduction and aggregation operations to realize more sophis-

ticated functionalities. Currently we support selected operations. One of them

extracts exactly those parts of the process the user is involved in (ShowMyActiv-

ities). The UnfinishedProcessPart operation only shows that part of the process

which still has to be executed, and reduces or aggregates the already finished

activities. The Range operation retrieves the subprocess between two activities.

The set of high-level operations is intended to be extensible for operations added

later. Below we give an example illustrating the way high-level operations are

translated into a combination of basic, respectively elementary operations.

It should be noted here, that Proviado supports additional operations at the

different levels for also manipulating data flow and for calculating of attribute

values of aggregated activities. All these operations are triggered by the control

flow operations at basic and elementary level.

4.1 Translating User-defined Views into View Building Operations

This section provides an example of a view based on a high-level operation

and a predicate (cf. Fig. 9). The view shall generate a reduced process scheme

that contains only activities the current user is involved in. For this purpose

a high-level operation ShowMyActivities generates a predicate for a given user

name. This predicate identifies all activities executed without participation of

the user (Step 1; note the negation of the before mentioned set). Step 2 invokes

O P

L M

X,Y

X X

WW V

Y X X

V,Y W,V V

X,Y Y

Step 1

Step 2

Step 3

B HGA NO

X,Y

X X XXX,Y

Step 4

B HG

A N O

X,Y

XXXXX,YX

Step 5

REDUCE S

Basic Operation:

Find components

S1= {C,D,E}, S2= {F},

S3= {I,J,K}, S4= {L},

S5= {P}

ReduceComp S1

ReduceComp S2

ReduceComp S3

ReduceComp S4

ReduceComp S5

Elementary Operations:

Simplification Operations

Initial process schema with

activities of user X

Reduce(pred)

View Operation:

Evaluate pred:

ShowMyActivities(user X)

High-level Operation:

Define predicate pred:

Find all activities where

actor X is not involved

S = {C,D,E,F,I,J,K,L,P}

O P

L M

X,Y

X X

WW V

Y X X

V,Y W,V V

X,Y Y

O P

L M

X,Y

X X

WW V

Y X X

V,Y W,V V

X,Y Y

Fig. 9. Performing a complex view-operation

the view operation Reduce that calculates the set of relevant activities S. The

basis operation ReduceCF then subdivides Sinto connected components Si

(Step 3). These connected components are then processed by the elementary

operation RedSESE (step 4). Applying the appropriate simplification rules yields

the compactified process scheme (Step 5). Obviously, the creation of a view

results in a schema for which a new graph layout has to be recalculated. This

is by far not trivial. Though there exist graph layout algorithms for aligning

control flow graphs, there is still some need to deal with complex process graphs

(including data elements, data flow, etc.).

4.2 Parameterization of View Building Operations

The primary use case of our view approach is the visualization of complex busi-

ness processes. However, other applications can be supported as well. Thus dif-

ferent requirements regarding the consistency of the resulting process scheme

exist. In our experience, for visualization purposes minor inconsistencies will

acceptable if a better presentation can be obtained. Obviously, such inconsis-

tencies are not acceptable in case certain manipulations shall be applied to the

views (e.g. view updates). To comply with these sometimes contradictory claims

Proviado allows for the parameterization of view building operations. We al-

ready mentioned this concept in Sec. 3.2 where different elementary operations

for aggregation are elected depending on parameters (cf. Fig. 5e).

Similarly, these parameters can influence view generation at a higher level.

Think of a view operation AggregateCF{B,C,H,K,T,U,V} to be applied to the pro-

cess scheme of Fig. 1. A direct translation into basic and elementary operations

then leads to invocation of AggrAddBranch({B,C,H,K,T,U,V}). This inserts a

new branch between the split after Aand the end. Parameterization allows to

execute AggregateCF with the additional claim to preserve dependencies. Then

three possibilities exist: (1) by subdividing the activities set into connected sub-

sets, the view operation invokes basic operation Aggregate two times. Finally,

AggrShiftOut({B,C,H,K}) and AggrShiftOut({T,U,V}) is called resulting in

a state inconsistent view model. (2) If state inconsistency is forbidden by a pa-

rameter, the set {B, C, H, K, T, U, V }is expanded until forming a SESE. Finally,

AggrSESE({B,...,V}) produces a high-quality but quite small process. (3) An

additional parameter inhibits the extension of the node set. In this case a view

generation is not possible revealing an error message to the user.

Considering reduction, a parameterization is useless at the level of view op-

erations since reduction of a complex set of activities can be realized by calling

RedSESE repeatedly. By contrast, for high-level operations a parameter that in-

hibits loss of information can be set to force view generation by aggregation.

5 Related Work

Process views have been an emerging topic in research for the last years. The

majority of approaches focuses on inter-organizational processes. Here process

views are used to build an abstracted version (public process) of an internal

process (private process) in order to hide implementation details [4,5,6,7]. In

[8,9] a top-down approach is used. Starting with a global process describing the

interactions between partners, each participant details his part of the process in-

serting activities. For the insertion ’inheritance preserving transformation rules’

are defined. All these approaches do not follow an operational approach, i.e. the

process view are modeled by the process designer.

Regarding user-specific views, [10,11] provide techniques to extract the sub-

graph induced by the activities conducted by the user. We also have presented

a high-level operation that accomplishes this task by applying reduction opera-

tions. Only few papers propose operations similar to reduction and aggregation.

[12] uses graph reduction to verify the structural correctness of process schemes.

Control flow structures are removed stepwise following certain rules. If no struc-

tural flaws were contained in the original model, this leads to a trivial graph.

View generation by aggregation is described in [13]. So called "Virtual" pro-

cesses are built by aggregating connected sets of activities. [13] introduces a no-

tion of order-preserving that corresponds to strong order-preserving as defined

in this paper. This property is mandatory and, consequently, an aggregation of

not connected activity sets is not possible in this approach. Furthermore, view

building by reduction is not provided. In total, this approach constitutes the

most comprehensive view building mechanism. Even loops are discussed in de-

tail in conjunction with order preservation. [14] extends the approach with a

state mapping function allowing views on process instances. An implementation

of a view model for monitoring purposes is presented in [15]. The view compo-

nent can be plugged to existing workflow management systems using their APIs.

[15] focuses on the mapping between original instance and process view at run

time. Respective views are pre-modeled manually.

6 Summary and Outlook

For the personalized visualization of large, long-running processes with hundreds

up to thousands activities the process schemes must be customizable retaining

only the information relevant to the current user. In this paper we have intro-

duced the theoretical framework of the Proviado view mechanism and have given

an idea of the flexibility introduced by high-level operations in combination with

parameterization. With this mechanism an adaptation of process schemes to spe-

cific user groups becomes feasible for the first time. Reduction operations provide

techniques to hide irrelevant parts of the process, while aggregation operations

allow for abstracting implementation details by summarizing arbitrary sets of

activities in one activity. Additionally, parameterization of the operations allow

for specifying the quality level to comply with.

We have been working on the implementation of the view mechanism and

realized large parts of the concept. This mechanism is one component of the

Proviado framework for flexible and user-specific visualization of business pro-

cesses [3,16]. The framework shall be transferred to industrial practice in the

context of business process monitoring. Thus, from the very beginning we have

been interested in covering practical issues as discussed in Sec. 4 as well. There

are still some topics left to be worked on. For usability reasons it is important

to provide an acceptable way to define and maintain process view definitions.

For this purpose, besides a comprehensive set of user-oriented high-level opera-

tions, we are thinking about a view definition language and/or a GUI. A future

research topic of great interest for the BPM community is the development of so-

phisticated graph layout algorithms capable of handling complex process graphs.

References

1. Streit, A., Pham, B., Brown, R.: Visualization support for managing large business

process specifications. In: Proc. BPM ’05. Volume 3649 of LNCS. (2005) 205–219

2. Bobrik, R., Reichert, M., Bauer, T.: Requirements for the visualization of system-

spanning business processes. In: Proc. DEXA Workshops. (2005) 948–954

3. Bobrik, R., Bauer, T., Reichert, M.: Proviado - personalized and configurable

visualizations of business processes. In: Proc. EC-Web ’06. LNCS 4082 (2006)

4. Chebbi, I., Dustdar, S., Tataa, S.: The view-based approach to dynamic inter-

organizational workflow cooperation. Data Knowl. Engin. 56(2) (2006) 139–173

5. Chiu, D.K.W., Cheung, S.C., Till, S., Karlapalem, K., Li, Q., Kafeza, E.: Work-

flow view driven cross-organizational interoperability in a web service environment.

Information Technology and Management 5(3-4) (2004) 221–250

6. Kafeza, E., Chiu, D.K.W., Kafeza, I.: View-based contracts in an e-service cross-

organizational workflow environment. In: Techn. for E-Services (TES ’01). (2001)

7. Schulz, K.A., Orlowska, M.E.: Facilitating cross-organisational workflows with a

workflow view approach. Data Knowledge Engineering 51(1) (2004) 109–147

8. Aalst, W.v., Weske, M.: The P2P approach to interorganizational workflows. In:

Proc. Conf. on Adv. Inf. Sys. Engineering (CAiSE). Volume 2068 of LNCS. (2001)

9. Aalst, W.v.: Inheritance of interorganizational workflows: How to agree to disagree

without loosing control? Inf. Techn. and Mgmt Journal 2(3) (2002) 195–231

10. Avrilionis, D., Cunin, P.Y.: Using views to maintain petri-net-based process mod-

els. In: Proc. of Int. Conf. on Software Maintenance (ICSM ’95). (1995) 318–326

11. Shen, M., Liu, D.R.: Discovering role-relevant process-views for recommending

workflow information. In: DEXA’03. Volume 2736 of LNCS. (2003) 836–845

12. Sadiq, W., Orlowska, M.E.: Analyzing process models using graph reduction tech-

niques. Information Systems 25(2) (2000) 117–134

13. Liu, D.R., Shen, M.: Workflow modeling for virtual processes: an order-preserving

process-view approach. Information Systems 28(6) (2003) 505–532

14. Liu, D.R., Shen, M.: Business-to-business workflow interoperation based on

process-views. Journal of Decision Support Systems 38(3) (2004) 399–419

15. Shan, Z., Yang, Y., Li, Q., Luo, Y., Peng, Z.: A light-weighted approach to workflow

view implementation. In: Proc. APWeb. Volume 3841 of LNCS. (2006)

16. Bobrik, R., Bauer, T.: Towards configurable process visualizations with proviado.

In: WS on Agile Coop. Proc.-Aware Inf. Sys. (ProGility’07). (2007) to appear.