Enabling Personalized Visualization of Large Business Processes through Parameterizable Views [original]

Enabling Personalized Visualization of Large Business

Processes through Parameterizable Views

Manfred Reichert,

Jens Kolb

Ulm University, Germany

{manfred.reichert,

jens.kolb}@uni-ulm.de

Ralph Bobrik

Detecon AG

Switzerland

ralph.bobrik@

detecon.com

Thomas Bauer

Hochschule Neu-Ulm

Neu-Ulm, Germany

thomas.bauer

@hs-neu-ulm.de

ABSTRACT

Process-aware information systems (PAISs) need to support

personalized views on business processes since different user

groups have distinguished perspectives on these processes

and related data. Existing PAISs, however, do not provide

mechanisms for creating and visualizing such process views.

Typically, processes are displayed to users in exactly the

same way as originally modeled. This paper presents a flex-

ible approach for creating personalized process views based

on parameterizable operations. Respective view-building

operations can be flexibly composed in order to hide pro-

cess information or abstract from it in the desired way. De-

pending on the chosen parameterization of the operations

applied, we obtain process views with more or less relaxed

properties (e.g., regarding the degree of information loss or

soundness). Altogether, the realized view concept enables a

more flexible visualization of large business processes satis-

fying the needs of different user groups.

1. INTRODUCTION

The field of Enterprise Engineering combines system en-

gineering and strategic management to streamline compa-

nies in terms of organisational structure, products and busi-

ness processes. Therefore process-aware information sys-

tems (PAISs) are an integral part to support business pro-

cesses at an operational level. Further, PAISs strictly sepa-

rate process logic from application code, relying on explicit

process models. This enables a separation of concerns, which

is a well established principle in computer science to increase

maintainability and to reduce costs of change [1]. In this con-

text, companies have to deal with a large number of business

processes involving different domains, organizational units,

and tasks. Generally, these processes are stored in central

process repositories [2]. In large companies, such reposito-

ries can easily contain several thousands of process models

[3]. Each of these process models comprises a large number

of activities, and involve a multitude of user groups. Usu-

ally, each of these user groups needs a different view on the

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that copies

bear this notice and the full citation on the first page. To copy otherwise, to

republish, to post on servers or to redistribute to lists, requires prior specific

permission and/or a fee.

SAC EE’12 March 25-29, 2012, Riva del Garda, Italy.

process with customized visualization and information gran-

ularity [4]. For example, managers rather prefer an abstract

overview, whereas process participants need a detailed view

of those process parts they are involved in. Thus, person-

alized process visualization is a much needed PAIS feature.

Despite its practical importance, current PAISs do not of-

fer adequate visualization support. Often, process models

are displayed to the user as drawn by the process designer.

Generally, these process models are too complex and, hence

not comprehensible to most users, e.g. due to the numer-

ous technical activities to execute the process. Some tools

allow altering the graphical appearance of a process and hid-

ing selected aspects (e.g., data flow). However, sophisticated

and flexible concepts for creating and managing user-specific

views are missing.

To elaborate basic visualization requirements several case

studies [5] were conducted resulting in three dimensions of

process visualization [6]. First, it must be possible to re-

duce complexity by hiding or aggregating process informa-

tion not being relevant in the given context. Second, the

notation and appearance of process nodes (e.g., activities

and data objects) should be customizable [6]. Third, differ-

ent presentation formats (e.g., process graph, table) need to

be supported.

Our Proviado project provides a generic framework for visu-

alizing large processes, which considers these three dimen-

sions. Fig. 1 sketches the corresponding architecture. For vi-

sualizing application-spanning processes, process data from

heterogeneous sources is integrated and translated into the

Proviado process format (a) [7]. The way a process shall be

displayed to a particular user role is defined by a Visualiza-

tion Model comprising relevant configuration data (b), like

the process part to be visualized or the notation to be used.

Taking this information the Visualization Engine generates

an abstracted process schema (c) and adapts the graphi-

cal representation of its nodes (d). Finally, the user-specific

view, which may include run-time data (e.g., status infor-

Visualization

Engine

Vis.Model A

source system II Process Schema in Generic

Representation Format

Process Model

Data

Transformation

and Integration

Vis.Model B

run-time data

Workflow

Mgmt System

User Manager

Visualization According to

Vis.Model A

Process Execution

PDM

System

Visualization According to

Vis.Model B

...

Visualization Engine

Process Model

Transformation

and Integration

Run-Time Data

Workflow Mgmt

System

User Manager

View According to Vis.Model A

Process

Execution

PDM System

View According to Vis.Model B

Generic

Process Schema ...

Structure

Transformation Notation

Transformation

Visualization

Creation

Vis.Model A Vis.Model B ...

Figure 1: Proviado Framework

mation, application data) is created (e). Using multiple

Visualizations Models allows us to realize customized and

personalized process visualizations (f).

This paper focuses on the parameterizable Structure Trans-

formation component (Fig. 1c), i.e., on the provision of a

flexible component for building process views. Such a com-

ponent must cover a variety of use cases. For example, it

should be possible to build views only containing activi-

ties the current user is involved in or only showing non-

completed process regions. As another example, consider

executable process models which often contain technical ac-

tivities (e.g., data transformation steps) to be excluded from

visualization. Finally, selected process nodes may have to

be hidden or aggregated to meet confidentiality demands.

Proviado allows creating respective process views based on

well defined, parameterizable view operations. These rely

on both graph reduction and graph aggregation techniques.

While the former can be used to remove nodes from a process

model, the latter are applied to abstract from certain pro-

cess information (e.g., aggregating several activities to one

abstract node). Proviado additionally supports the flexible

composition of such basic view operations to realize more

sophisticated process abstractions. The basic idea of build-

ing process views has been already sketched in [8, 9]. In

this paper we introduce more advanced view operations and

their formal properties. Further, we use the view-building

operations for enabling parameterization of high-level view

operations.

The implementation of view operations is by far not triv-

ial and may require complex process schema transforma-

tions. Besides activity aggregations may become complex,

e.g. when aggregating non-connected activities. Further-

more, it should be possible to flexibly configure the proper-

ties of a process view depending on application needs. If the

focus is on process visualization, for example, view proper-

ties may be relaxed. Opposed to this, more rigid constraints

become necessary if views shall be updatable or executable.

Section 2 gives background information needed for un-

derstanding this paper. In Section 3 we introduce the for-

mal foundations of parameterizable process views. Section

4 gives insights into practical issues and presents more com-

plex examples for defining and creating process views. Sec-

tion 5 discusses related work and Section 6 concludes with

a summary.

2. BACKGROUNDS

Each process is represented by a process schema consist-

ing of process nodes and the control flow between them (cf.

Fig. 2). For control flow modeling, control gateways (e.g.,

ANDsplit, XORsplit) and control edges are used.

Definition 1. Aprocess schema is defined by a tuple P=

(N, E, EC, NT) where:

•Nis a set of process nodes,

•E⊂N×Nis a precedence relation

(notation: e= (nsrc, ndest)∈E),

•EC :E→Conds ∪ {True}assigns optionally transi-

tion conditions to control edges,

•NT :N→{Activity, ANDsplit, ANDjoin, ORsplit,

ORjoin, XORsplit, XORjoin}assigns to each n∈Na

node type NT (n); Nis divided into disjoint sets of ac-

tivity nodes A(NT =Activity) and gateways S(NT 6=

Activity).

Note that this definition focuses on the control flow per-

spective. In particular, it can be applied to existing activity-

oriented modeling languages (e.g. BPMN). However, the

view operations presented in Section 3 consider other pro-

cess perspectives as well (e.g., data elements, data flow).

Furthermore, Proviado also considers loop structures. We

exclude the latter in the paper due to lack of space (see [10]

for details); i.e., we only consider acyclic process graphs.

We assume that a process schema has one start and one

end node. Further, it has to be connected; i.e., each activity

can be reached from the start node, and from each activity

the end node is reachable. Finally, branches may be arbi-

trarily nested, but must be safe (e.g., a branch following a

XORsplit must not merge with an ANDjoin).

Definition 2. Let P= (N, E, EC, NT) be a process schema

and let X⊆Nbe a subset of activity nodes. The subgraph

P0induced by Xis called SESE (Single Entry Single Exit)

fragment iff P0is connected and has exactly one incoming

and one outgoing edge connecting it with P.

Based on a process schema Prelated process instances can

be created and executed at run-time. Regarding the process

instance from Fig. 2, for example, activities Aand Bare

completed, Cand Nare activated (i.e., offered as work items

in user worklists), and Hand Kare running.

Definition 3. Aprocess instance Iis defined by a tuple

(P, NS, H) where

•Pdenotes the process schema on which Iis running,

•NS :N→ExecutionStates := {NotActivated, Acti−

vated, Running, Skipped, Completed}describes the ex-

ecution state of each node n∈N,

• H =he1,...,enidenotes the execution history of I

where each entry ekis related either to the start or

completion of a particular process activity.

For an activity n∈Nwith NS(n)∈ {Activated, Running}

all preceding activities either must be in state Completed

or Skipped, and all succeeding activities must be in state

NotActivated. Further, there is a path πfrom the start

node to nwith NS(n0) = Completed ∀n0∈π.

3. FUNDAMENTALS ON BUILDING VIEWS

We first introduce basic view-building operations and rea-

son about properties of resulting view schemas. As first

example consider the process instance from Fig. 3a. As-

sume that each of the activity sets {B, C, H, K},{J, L},

and {T, U, V }shall be aggregated, i.e., replaced by one ab-

stract node. Assume further that activity sets {E, F, G}and

{R, S}shall be hidden. Fig. 3b shows a possible view result-

ing from respective aggregations and reductions. Generally,

process views exhibit an information loss when compared

to the original process. As important requirement, view-

building operations should have a precise semantics and be

UT V

N O

activity

AND split

control flow edge

XOR split XOR join

branching condition

activity states:

completed

running

activated SESE block

(Single Entry Single Exit)

AND join

Figure 2: Example of a process instance

applicable to both process schemas and instances. Further,

it should be possible to remove process nodes (reduction)

or to replace them by abstracted ones (aggregation). When

building views it is fundamental to preserve the structure

of non-affected process regions. Finally, the effects of view-

building operations should be parameterizable to meet ap-

plication needs best and to be able to control the degree of

information loss.

We first give an abstract definition of a process view. The

concrete properties of such a view depend on the applied

view operations and their parameterization.

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

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

process schema V(P) = (N0, E0, EC0, NT0) whose activity

set A0⊆N0can be derived from Pby reducing and aggre-

gating activities from A⊆N. Formally:

•AU=A∩A0denotes the set of activities present in

both Pand V(P),

•AD=A\A0denotes the set of activities present in P,

but not in V(P); i.e., reduced or aggregated 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 :{AggrNodesi|i= 1,...,n} → AN

Using the notions from Def. 4 for a given process schema P

and related view V(P) we introduce function V Node :A→

A0, which maps each process activity c∈AU∪AggrNodes

to a corresponding activity in the view :

V Node(c) =











c c ∈AU

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

c∈AggrNodesi

undefined c /∈AU∪AggrNodes

For each view activity c0∈A0,V Node−1(c0) denotes the

corresponding activity or the set of activities aggregated by

c0in the original schema. Finally more complex process

views are created by composing a set of view operations,

which also define the semantics of the view (cf. Sec. 4).

3.1 Building Process Views Based on Schema

Reduction

Any view component should be able to remove activities

in a process. For example, this is required to hide irrelevant

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)

Figure 3: Example of a process view

REDUCECF({B,C,D})

C D EA

C D EBA

D EA

A E

RedActivity(B)

RedActivity(C)

RedActivity(D)

ADF

A D F

r Ú s

d) e)

RedActivity(B)

Figure 4: Recution and simplification operations

or confidential process details from a particular user group.

For this purpose, Proviado provides an elementary reduction

operation (cf. Fig. 4b). Based on it, higher-level reduction

operations for hiding a set of activities at once can be re-

alized. Reduction of an activity (RedActivity) is realized

by removing it together with its incoming/outgoing edges

from the schema. Then a new control edge is inserted be-

tween the predecessor and successor of the removed activity

(cf. Fig. 4b). For reducing activity sets, the single-aspect

view operation ReduceCF is provided. Single-aspect op-

erations focus on elements of one particular process aspect.

Reduction is performed stepwise, i.e., for all activities to be

removed, RedActivity is applied (cf. Fig. 4a). Note that the

algorithms we apply are context-free and may introduce un-

necessary process nodes (e.g. empty branches). Respective

nodes are purged afterwards by applying well-defined sim-

plification rules to the created view schema. For example,

when reducing a complete branch of a parallel branching, the

resulting control edge may be removed as well (cf. Fig. 4d).

In case of an XOR-/OR-branching, however, the empty path

(i.e., control edge) needs to be preserved. Otherwise an in-

consistent schema would result (cf. Fig. 4b). Similarly, when

applying simplification rules to XOR-/OR-branches respec-

tive transition conditions must be recalculated (cf. Fig. 4c).

Reduction of activities always comes along with an informa-

tion loss, while preserving the structure of the non-reduced

schema parts, i.e., the activities being present in both pro-

cess and view schema. The latter can be expressed using

the notion of order preservation. For this we introduce par-

tial order relation (⊆N×N) on process schema Pwith

n1n2⇔ ∃ path πin Pfrom n1to n2.

Definition 5. Let P= (N, E, EC, NT) be a process schema

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

be a view on Pwith activity set A0⊆N0. Then: V(P) is

called order-preserving iff ∀n1, n2∈A with n16=n2and n1

n2:n0

1=V Node(n1)∧n0

2=V Node(n2)⇒ ¬(n0

2n0

1).

This property reflects that the order of two activities in

a process schema must not be reversed in a correspond-

ing view. Obviously, the reduction operations depicted in

Fig. 4ab are order preserving. Generally, this property is

fundamental for ensuring the integrity of process schemas

and corresponding views. A stronger notion is provided by

Def. 6. As we will see later, in comparison to Fig. 4ab there

are view operations which do not comply with Def. 6.

Definition 6. Let P= (N, E, EC, NT) be a process schema

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 with n16=n2and n1n2:

1=V Node(n1)∧n0

2=V Node(n2)⇒n0

1n0

3.2 Building Process Views Based on Schema

Aggregation

The aggregation operation enables merging a set of activi-

ties into one abstracted node. Depending on the structure of

the subgraph induced by the respective activities, different

schema transformations may have to be applied. In par-

ticular, the aggregation of non-connected activities necessi-

tates a more complex restructuring of the process schema.

Fig. 5 shows the elementary operations for building aggre-

gated views. The depicted operations follow the policy to

substitute the activities in-place by an abstract one (if possi-

ble) while maintaining order-preservation (cf. Def. 5). Note

that in-place substitution is always possible when aggregat-

ing a SESE fragment (cf. Def. 2). If none of the oper-

ations from Fig. 5ade can be applied, AggrAddBranch (cf.

Fig. 5b) is used. It identifies the nearest common ances-

tor and successor of all activities to be aggregated and adds

a new branch between them (cf. Fig. 5b). Alternatively,

aggregation of non-connected activities can be handled by

applying elementary operations of type AggrSESE (cf. Sec.

4). Finally, when aggregating activities directly following a

split node there exist two alternatives (cf. Fig. 5e). The first

one aggregates activities applying AggrAddBranch, the sec-

ond one shifts activities to the position preceding the split

node (AggrShiftOut).

Except AggrAddBranch the operations presented are strong

order-preserving (cf. Def. 6). However, AggrAddBranch vi-

olates this property. For example, in Fig. 5b order relation

DEis not preserved after applying this operation.

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

with activity set A⊆N. Then: DP={(n1, n2)∈A×

A|n1n2}is denoted as dependency set and reflects all

direct and transitive control flow dependencies between any

two activities.

We are interested in the relation between the dependency

set of a process and a related process view. For this pur-

pose, let DPbe the dependency set of Pand DV(P)be

the dependency set of view V(P). We further introduce a

projection of the dependencies from V(P) on Pdenoted as

V(P). It can be derived by substituting the dependencies

of the abstract activities by the ones of the original activ-

ities. 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)con-

tains additional 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)}in-

stead (analogously for n2∈AN); finally insert the depen-

dencies between AggrNodes, i.e., DP[AggrNodes] = {d=

(n1, n2)∈DP|n1∈AggrNodes ∧n2∈AggrNodes}

Now we can classify effects on the dependencies between

activities when building a view.

C DBA E

BCE

AggrAddBranch

A Z

SESE

AggrSESE b)a)

Alternative 1: Alternative 2:

AggrAddBranch

AggrShiftOut

AGF

r Ú s

AggrComplBranches

BCDE

AB C

r Ú s CD

AggrAddBranch

Figure 5: Elementary aggregation operations

Definition 8. Let P= (N, E, EC, NT) be a process schema

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 ex-

ist 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.

Generally reduction operations are dependency-erasing. When

aggregating activities, however, there exist elementary op-

erations of all three types. In Fig. 5, for instance, Ag-

grSESE is dependency-preserving, while AggrAddBranch is

dependency-erasing as (B, C)/∈D0

V(P)holds; finally, Aggr-

ShiftOut is dependency-generating: (B, E)∈D0

V(P). The-

orem 1 explains the relation of dependency properties (cf.

Def. 8) and order-preservation (cf. Def. 5).

Theorem 1. Let P= (N, E, EC, NT ) be a process schema

and let V(P) be 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 can be based on the definition of

the properties and dependency sets, and is omitted here. In

summary, we have presented a set of elementary aggregation

operations. Each of them fits to a specific ordering of the

activities to be aggregated. In Section 4.1 we combine these

operations into more complex ones utilizing the discussed

properties.

Generally, additional aspects have to be covered includ-

ing data elements, data flow, and attributes of process el-

ements. Regarding data elements, for example, aggrega-

tion operations (e.g., to create abstract business objects)

and reduction operations (e.g., to hide technical data ele-

ments) are provided by the Proviado framework. Fig. 6a

shows an example of a simple aggregation. Here, data ele-

ments {D1, D2}are aggregated and data edges connecting

activities with data elements are re-linked when aggregating

{B, C, D, E}to preserve a valid process model.

Further, Proviado offers functions enabling attribute ag-

gregations. Fig. 6b, for example, applies a MIN-function to

the aggregation set in order to determine start time, a MAX-

function for calculating end time, and a SUM-function for

aggregating cost attributes.

BCDEA

D3 D1D2

data

element

data flow

edge optional data flow

AggrShiftOuta)

BA C

start: 01.08.11

end: 05.08.11

cost: 2500

start: 07.08.11

end: 14.08.11

cost: 4100

start: 06.08.11

end: 07.08.11

cost: 600

ABC

start: 01.08.11

end: 14.08.11

cost (sum): 7200

AggrSESEb)

start = min(ni.start)

end = max(ni.end)

cost = sum(ni.cost)

Aggr. Functions

Figure 6: Aggregation of (a) data elements, (b) at-

tributes

3.3 Applying Views to Process Instances

So far, we have only considered views on process schemas.

This section additionally introduces views on process in-

stances (cf. Def. 3). When building respective instance

views their execution state (i.e. states of concrete and ab-

stract activities) must be determined and the trace relating

to the instance view logically needs to be adapted. Exam-

ples are depicted in Fig. 7a (reduction) and Fig. 7b (aggre-

gation). Function V NS calculates the state of an abstract

activity based on the states of the aggregated activities.

V NS(X) =











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

ning, 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. Let I= (P, NS, H) be an instance of schema

P= (N, E, EC, NT) and V(P)=(N0, E0, EC0, NT0) be a

view on Pwith corresponding aggregation and reduction

sets AggrNodes and RedNodes (cf. Def. 4). Then: 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 ei

related 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 are depicted in Fig. 7. Fig. 7c shows the sce-

nario from Fig. 5e with execution states added. Note that

applying AggrShiftOut yields an inconsistent state as two

subsequent activities are in state Running.

Definition 10. 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 π

(cf. Sec. 2) in V(I) from start to end and not contain-

ing 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 does not exists more than one activity

in state Activated or Running.

As indicated in Fig. 7a, reducing activities from a process

instance may result in a “gap” during instance execution,

if no activity is Running or Activated. Hence, reduction

is not strong state-consistent. A similar gap occurs if the

process instance has entered a deadlock. Since we solely

use our view mechanism for visualizing processes executed

by heterogeneous source systems and run-time information,

deadlock issues can be excluded here. Theorem 2 shows how

state inconsistency is correlated with dependency relations

(cf. Def. 8):

Theorem 2. 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 pro-

cess P= (N, E, EC, NT ) and V(I) = (V(P), NS0,H0) be a

view on Iwith V(P) = (N0, E0, EC0, NT0) being dependency-

generating. Then, there exists n0

1, n0

2∈N0in Vwhich gener-

ates a dependency, i.e. n0

1n0

2. Let n1=V Node−1(n0

1)∈

Nand n2=V Node−1(n0

2)∈N. Then: n1n2. Fur-

ther there are two paths in Pfrom start to end containing

n1and n2. Therefore, there exists a state of instance I

with NS(n1) = Running and NS(n2) = Running. Thus,

NS(n0

1) = Running and NS(n0

2) = Running. Since there

is a path from start to end in V(P), containing both n0

1and

2, the claim follows.

C DBA

AggrSESERedSESE b)a)

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)›

Alternative 1:

AggrAddBranch

BDA E

Alternative 2:

AggrShiftOut

Figure 7: View operations for process instances

Table 1: Overview of operations properties

Properties

Operation

str. order preserving

order preserving

str. state consistent

state consistent

depend. preserv.

depend. erasing

depend. generat.

RedActivity + + - + - + -

AggrSESE + + + + + - -

AggrComplBranches + + + + + - -

AggrShiftOut + + - - - - +

AggrAddBranch - + + + - + -

Theorem 2 shows that AggrShiftOut always causes an in-

consistent execution state, whereas applying AggrAddBranch

maintains a consistent state.

Concerning aggregation of process instances, Proviado al-

lows aggregating collections of instances; i.e. multiple in-

stances of the same process schema are condensed to an ag-

gregated one to provide abstracted information about their

progress or to aggregate key performance data.

4. ADVANCED VIEW-BUILDING

CONCEPTS

To enable more sophisticated view-building concepts, the

presented elementary operations may be combined. Table 1

gives an overview of view properties we can guarantee for

the different elementary operations. Based on this, we can

also reason about properties of views resulting from the com-

bined use of elementary operations. For any process visu-

alization component, however, manual selection of the ele-

mentary operations to be applied is not convenient for users

since this would require indepth knowledge of these opera-

tions and their semantics. Thus, Proviado additionally pro-

vides single-aspect view operations on top of the elementary

ones for coping with more complex use cases. Single-aspect

operations analyze the context of the activities to be reduced

or aggregated in a process schema, and determine the ap-

propriate elementary operations to build the view with the

desired properties.

4.1 Parameterizable View-building Operations

The primary use case for our view-building approach is

process visualization. However, other use cases (e.g., process

modeling) can be covered as well. Thus, different require-

ments regarding the consistency of the resulting view schema

Table 2: Overview of parameters for AggregateCF

Parameter Values1Description

dependencies preserving,

non-erasing,

non-generating,

any

The view operation applied

should be dep.-preserving,

not dep.-erasing, or not dep-

generating. Otherwise no

restrictions regarding depen-

dencies are considered.

exec. states inconsist., con-

sistent

The view operation applied

should be state consistent or

may be state inconsistent.

strategy as-is,subdivide,

expand

Activity set should be aggre-

gated as-is, may be subdi-

vided or expanded.

1default values are printed in bold face

exist. Our case studies have shown that for the visualiza-

tion of large processes minor inconsistencies or information

loss will be tolerated if an appropriate visualization can be

obtained. Obviously, inconsistencies will be not acceptable

if process updates based on views shall be enabled.

To deal with these varying goals, Proviado expands single-

aspect operations with a parameter set. This allows spec-

ifying the properties the resulting view schema shall have.

For example, the parameters of operation AggregateCF

are summarized in Table 2; e.g., when aggregating activities

directly succeeding an ANDsplit (cf. Fig. 5e) and requir-

ing that the view has to be state-consistent, Alt. 1 (i.e.

AggrAddBranch) is chosen.

In certain cases, the specified parameters may be too strict;

i.e., no elementary view operations can be found to realize

the desired properties. We provide two strategies for ad-

dressing such scenarios. The first one subdivides the set of

activities until elementary operations can be applied. The

second strategy expands the activity set. Regarding reduc-

tion, in turn, view generation is always possible due to the

way activity sets are split into single activities and the ap-

plication of RedActivity.

Fig. 8 illustrates the use of the single-aspect operation Ag-

gregateCF. It depicts a process schema together with the

set of activities to be aggregated. The view operation an-

alyzes the structure of the activities and determines which

elementary operation shall be applied. If the application

of these operations results in a view schema complying with

the properties defined by the desired parameters (dependen-

cies,execution states ) it is applied as shown in Alt. 1. If

parameter strategy forces us to process the set of activities

as it is, and an appropriate operation cannot be found, view

generation is aborted with an error message. Alt. 2 shows

the result when expanding the activity set to be aggregated

to the minimum SESE-block containing all activities to be

aggregated. This strategy has been proposed in literature

as well [11, 12]. Generally, for visualization purpose it is

not always acceptable to aggregate activities originally not

contained in the aggregation set.

Alt. 3ab+ and 4 can be derived by subdividing the set of

activities to be aggregated. This is done stepwise: First, all

connected fragments are identified (Alt. 3). If the aggrega-

tion of these fragments does not meet the required proper-

ties, the fragments are further subdivided until each subset

constitutes a SESE (Alt. 4).

Altogether, parameterization of view operations signifi-

cantly increases the flexibility of our view-building approach

and allows defining exactly the view properties to be pre-

served. Considering reduction, a parameterization at the

level of single-aspect operations is not useful since reduction

of a complex set of activities is realized by calling RedActivity

repeatedly as explained in Sec. 3.1.

4.2 A Leveled Operational Approach for Re-

alizing Views

So far, we have presented a set of elementary and single-

aspect view buliding operations. Additionally, Proviado of-

fers high-level operations hiding as much complexity from

end-users as possible. As configuration parameter the single-

aspect view operations take the sets of activities to be re-

duced or aggregated, and then determine appropriate ele-

mentary operations. What is still needed are view opera-

tions allowing for a predicate-based specification of the re-

TA BCDEFGHIJKLMNOPQRS

AggrAddBranch

({B,F,G,J,M,N,P,Q,R})

AggrSESE({B,C,D,E,F,G,H,

I,J,K,L,M,N,O,P,Q,R,S})

AGGREGATE({B,F,G,J,M,N,P,Q,R})

(Single-Aspect Operation)

AggrAddBranch({B,J,M,N})

AggrSESE({F,G})

AggrSESE({P,Q,R})

AggrShiftOut({B,J,M,N})

AggrSESE({F,G})

AggrSESE({P,Q,R})

AggrSESE({B})

AggrSESE({J})

AggrSESE({M,N})

AggrSESE({F,G})

AggrSESE({P,Q,R})

OM S

EIT

BFGJMNPQR

OM S

EIT

BJMN

CFG

PQR

KA S

EITBJMN

CFG

PQR

OM S

tIT

PQR

C E

(Elementary Operation)

Base Process Model

strategy = as-is

states = default

dependencies = default

View Parameterization:

strategy = expand

states = consistent

dependencies = preserving

View Parameterization:

strategy = subdivide

states = default

dependencies = default

View Parameterization:

strategy = subdivide

states = consistent

dependencies = default

View Parameterization:

strategy = subdivide

states = consistent

dependencies = preserving

View Parameterization:

Figure 8: Views depending on quality parameters

spective activity sets. Besides, operations with built-in in-

telligence are useful, e.g. ”show only activities of a certain

user role”. To meet these requirements, Proviado organizes

view operations in four layers (cf. Fig. 9a). Thereby, high-

level operations may access lower-level ones. For defining a

view, operations from all layers can be used.

Elementary operations are tailored for a specific ordering

of the selected activity set within the process schema (cf.

Sec. 3). Single-aspect operations receive a set of activities

as input to be processed. They analyze the structure of

the activities in the process schema and select the appropri-

ate elementary operations based on the chosen parameteri-

zation. Multi-aspect operations consider elements of differ-

ent type (e.g., activities, data elements) and delegate their

processing to single-aspect operations. High-level operations

abstract from the aggregations or reductions neccessary to

build a particular view: ShowMyActivities extracts exactly

those parts the user is involved in. AggrExecutedPart only

shows those parts of the process which still may be exe-

cuted, and aggregates already finished activities. Fig. 9b

gives an example illustrating the way high-level operations

are translated into a combination of single-aspect and ele-

mentary operations, respectively.

Proviado supports additional operations at the different

levels for considering data flow and for aggregating attribute

values; e.g., to handle adjacent data elements when aggre-

gating activities (remove, aggregate, or maintain) [10].

5. RELATED WORK

IEEE 1471 recommends user-specific viewpoints for soft-

ware architectures [13]. These viewpoints are templates

from which individual views are created for a concrete soft-

ware architecture. Since this standard does not define any

methods, tools or processes, Proviado could provide there-

fore a powerful framework in the context of PAIS.

Some view-building approaches deal with inter-organizational

processes and apply views to create abstractions of private

processes just hiding implementation details [14, 15, 16, 17].

Thereby views are specified by the designer.

[18] presents an approach with predefined view types (i.e.

human tasks, collaboration view). As opposed to Proviado,

it is limited to the specified view types and it is not pos-

sible to define own user-specific views. [19] applies graph

reduction to verify structural properties of process schemas.

Proviado accomplishes this via aggregation and high-level

operations. [20] uses SPQR-tree decomposition for abstract-

ing process models. This approach neither provides high-

level abstractions nor does it take other process aspects (e.g.

data flow) into account.

[21] determines semantic similarity between activities by

analysing the structural information of a process model. The

discovered similarity is used to abstract the given process

model. However, the approach neither distinguish between

different user perspectives on a process model nor provides

concepts to manually create process views.

An approach for building aggregated views is provided

by [22]. It proposes a two-phase procedure for aggregating

parts of a process model that must not be exposed to public.

However, it focuses on block-structured graphs and neither

data flow nor attributes are considered.

Implementations of view models for monitoring purposes

are presented in [23, 24]. These approaches focus on the

mapping between original instance and process view at run-

time. Respective views have to be pre-specified manually by

the designer.

M AB

HF G L

AggrExecutedPart

High-level Operation:

Aggregate(A,B,C,E,H,I)

Multi-Aspect Operation:

AGGREGATECF(

A,B,C,E,H,I

)

Single-Aspect Operation:

AggrShiftOut

(A,B,C,E,H,I)

Elementary Operation:

Initial Process

Result

Attribute Op.

High-level Operations

Data Flow Op.

Multi-Aspect Operations

Single-Aspect Operations

Elementary Operations

AGGREGATECF REDUCECF

Aggregate Reduce

ShowMyActivities ...AggrExecutedPart

Control Flow Attributes Application Data

Process

b) J

GF K

ABCEHI

AggrSESE

AggrShiftOut

AggrAddBranch

RedActivity

AggrComplBranch

...

Figure 9: Multi-Layer view operations

Proviado provides a holistic framework for user-centric

view-building with elementary and highl-level operations on

both control and data flow. Additionally, it takes run-time

information into account. None of the existing approaches

covers all these aspects. Further, existing approaches for

building views are based on rigid constraints not taking

practical requirements into account. For example, our first

design of a visualization-oriented view mechanism was based

on reduction and aggregation techniques for block-structured

process graphs [10]. Presenting this solution to business

users, however, we figured out that block-structured aggre-

gation does not always meet the practical requirements com-

ing with the visualization of large processes. For this reason

Proviado allows to flexibly specify the acceptable degree of

imprecision. A validation of Proviado was conducted in the

automotive domain, where users are confronted with with

complex, long-running development processes [10].

6. SUMMARY AND OUTLOOK

We introduced the Proviado view mechanism and its for-

mal foundation. Further, high-level view building opera-

tions provide the required flexibility since process schemas

can be adapted to specific user groups. Reduction opera-

tions provide techniques hiding irrelevant parts of the pro-

cess, whereas aggregation operations allow abstracting from

process details by aggregating arbitrary sets of activities in

one node. Finally, parameterization of the respective oper-

ations allows specifying the quality level the resulting view

schema must comply with. This enables adaptable process

visualization not feasible with existing approaches. We have

implemented large parts of the described view mechanism in

a prototype. For usability reasons it is important to provide

appropriate methods for defining and maintaining process

views. Therefore, we are working on a comprehensive set

of user-oriented, high-level operations as well as on a view

definition language. Both will be evaluated in a user exper-

iment.

7. REFERENCES

[1] Weber, B., Sadiq, S., Reichert, M.: Beyond Rigidity -

Dynamic Process Lifecycle Support: A Survey on

Dynamic Changes in Process-Aware Information

Systems. Computer Science - Research and

Development 23 (2009) 47–65

[2] Weber, B., Reichert, M.: Refactoring Process Models

in Large Process Repositories. In: Proc. 20th CAiSE,

Montpellier, France (2008) 124–139

[3] Weber, B., Reichert, M., Mendling, J., Reijers, H.A.:

Refactoring Large Process Model Repositories.

Computers in Industry 62 (2011) 467–486

[4] 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

[5] Bobrik, R., Reichert, M., Bauer, T.: Requirements for

the visualization of system-spanning business

processes. In: Proc. DEXA Workshop. (2005) 948–954

[6] Bobrik, R., Bauer, T., Reichert, M.: Proviado -

personalized and configurable visualizations of

business processes. In: Proc. EC-Web ’06. (2006)

61–71

[7] Reichert, M., Bassil, S., Bobrik, R., Bauer, T.: The

Proviado Access Control Model for Business Process

Monitoring Components. EMISA International

Journal 5(2010) 64–88

[8] Bobrik, R., Reichert, M., Bauer, T.: View-based

process visualization. In: International Conference on

Business Process Management (BPM’07). (2007)

[9] Rinderle, S., Bobrik, R., Reichert, M., Bauer, T.:

Business process visualization - use cases, challenges,

solutions. In: Proc. ICEIS. (2006) 204–211

[10] Bobrik, R.: Konfigurierbare Visualisierung komplexer

Prozessmodelle. Phd thesis, Ulm University (2008) (in

German).

[11] Liu, D.R., Shen, M.: Workflow modeling for virtual

processes: an order-preserving process-view approach.

Information Systems 28 (2003) 505–532

[12] Shen, M., Liu, D.R.: Discovering role-relevant

process-views for recommending workflow information.

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

[13] IEEE 1471-2000: Recommended Practice for

Architectural Description for Software-Intensive

Systems. IEEE Standards Association (2000)

[14] Chebbi, I., Dustdar, S., Tataa, S.: The view-based

approach to dynamic inter-organizational workflow

cooperation. Data Knowl. Eng. 56 (2006) 139–173

[15] Chiu, D.K.W., Cheung, S.C., Till, S., Karlapalem, K.,

Li, Q., Kafeza, E.: Workflow view driven

cross-organizational interoperability in a web service

environment. Inf. Techn. and Mgmt. 5(2004) 221–250

[16] Kafeza, E., Chiu, D., Kafeza, I.: View-based contracts

in an e-service cross-organizational workflow

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

[17] Schulz, K.A., Orlowska, M.E.: Facilitating

cross-organisational workflows with a workflow view

approach. Data Knowl. Eng. 51 (2004) 109–147

[18] Tran, H.: View-Based and Model-Driven Approach for

Process-Driven, Service-Oriented Architectures. TU

Wien, PhD thesis (2009)

[19] Sadiq, W., Orlowska, M.E.: Analyzing process models

using graph reduction techniques. Information

Systems 25 (2000) 117–134

[20] Polyvyanyy, A., Smirnov, S., Weske, M.: The

Triconnected Abstraction of Process Models. In: Proc.

7th Int’l Conf. Business Process Management. (2009)

[21] Smirnov, S., Reijers, H., Weske, M.: A Semantic

Approach for Business Process Model Abstraction. In:

Advanced Information Systems Engineering. Volume

6741. (2011) 497–511

[22] Eshuis, R., Grefen, P.: Constructing customized

process views. Data Knowl. Eng. 64 (2008) 419 – 438

[23] Shan, Z., Yang, Y., Li, Q., Luo, Y., Peng, Z.: A

light-weighted approach to workflow view

implementation. In: Proc. APWeb. (2006) 1059–1070

[24] Schumm, D., Latuske, G., Leymann, F., et al.: State

Propagation for Business Process Monitoring on

Different Levels of Abstraction. In: Proc. 19th ECIS,

Helsinki, Finland (2011)