An Operational Semantics for the Extended Compliance Rule ... · An Operational Semantics for the...

Ulmer Informatik Berichte | Universität Ulm | Fakultät für Ingenieurwissenschaften und Informatik

An Operational Semantics for the Extended

Compliance Rule Graph Language

David Knuplesch, Manfred Reichert

Ulmer Informatik-Berichte Nr. 2014-06

Juni 2014

An Operational Semantics for the ExtendedCompliance Rule Graph Language

David Knuplesch and Manfred Reichert

Institute of Databases and Information Systems,Ulm University, Germany

[email protected]

[email protected]

Abstract

A challenge for any enterprise is to ensure conformance of its business processes with im-posed compliance rules. Usually, the latter may constrain multiple perspectives of a businessprocess, including control flow, data, time, resources, and interactions with business part-ners. Like for process modeling, intuitive visual languages have been proposed for specifyingcompliance rules. However, business process compliance cannot completely be decided atdesign time, but needs to be monitored during run time as well. In previous work we in-troduced the extended Compliance Rule Graph (eCRG) language that enables the visualmonitoring of business process compliance regarding the control flow, data, time, and re-source perspectives as well as the interactions a process has with business partners. Thistechnical report introduces an operational semantics of the eCRG language. In particular,the state of a visual compliance rule is reflected through markings and annotations of aneCRG. The proposed operational semantics not only allows detecting compliance violationsat run-time, but visually highlights their causes as well. Finally, it allows providing recom-mendations to users in order to proactively ensure for a compliant continuation of a runningbusiness process.

This work was done within the research project C3Pro funded by the German Research Foun-dation (DFG) under project number RE 1402/2-1.

2 David Knuplesch and Manfred Reichert

1 Introduction

The correctness of business process models has been intensively discussed in literature formore than a decade [1–3]. While earlier work focused on syntactical correctness and sound-ness constraints (e.g., absence of deadlocks and lifelocks), the compliance of business pro-cesses with semantic constraints has been increasingly considered during the last years [4, 5].Usually, compliance rules stem from domain-specific constraints, e.g., referring to corporatestandards, legal regulations or evidenced best practices [6, 7] , and need to be ensured in allphases of the process life cycle [8, 9].

Approaches dealing with the compliance of business processes during their execution arecovered by the notion of compliance monitoring. In order to detect and report run-timeviolations of compliance rules, events of running business process instances need to be con-sidered (cf. Fig. 1). Note that two kinds of monitoring need to be distinguished: reactiveand proactive monitoring. Regarding reactive monitoring, the process-aware informationsystem only reports a compliance violation once it has occurred. In turn, proactive moni-toring aims to proactively prevent potential compliance violations that might occur duringthe further course of process execution; e.g. by suggesting appropriate tasks that still needto be executed to meet the compliance rule.

WfMS

System

CRM

System

ERP

System

...

Single

Client

...

Compliance Monitoring

Event Bus

Compliance

Rules

Compliance

Reporting

Fig. 1: Compliance monitoring [10, 5]

A multitude of approaches focusing on compliance monitoring at run-time were intro-duced during the last years [11–13]. While early suggestions focused on the control flowperspective, later proposals for monitoring compliance considered additional process per-spectives as well [14, 15]. In particular, the data, resource, and time perspectives have beenaddressed. Other approaches, in turn, have focused on the traceability of compliance vio-lations [10, 16]. Furthermore, [5] proposed 10 fundamental compliance monitoring function-alities (CMFs) that may be used to compare existing approaches for monitoring businessprocess compliance. In this context, the authors stated that existing approaches do notprovide a satisfactory solution that combines an expressive language with full traceabilitycapabilities [5].

To close this gap, this report introduces an operational semantics for the extended Com-pliance Rule Graph (eCRG) language. The latter has been introduced in [17, 18] and enables

An Operational Semantics for the eCRG Language 3

the visual monitoring of business process compliance. In particular, the operational seman-tics annotates eCRGs with text, colors and symbols. In order to deal with compliance rules,which are triggered multiple times during the execution of a business process instance, theoperational semantic creates and annotates multiple instances of an eCRG in parallel. Theannotated instances of an eCRG not only indicate compliance violations, but may be alsoutilized for recommending the next process steps (i.e. activities), whose execution will en-sure compliance. Furthermore, they provide a suitable basis for compliance metrics. Notethat the eCRG language is a powerful visual notation for compliance rules that adequatelysupports the control flow, data, time, and resource perspectives as well as interactions withbusiness partners. Consequently, this report not only provides the operational basis for mon-itoring control flow constraints, but enables the monitoring of the latter perspectives as well.Altogether the provided operational semantics provides the basis for

– utilizing the eCRG language for monitoring business process compliance during processexecution.

– monitoring the conformance with compliance rules related to any process perspective;i.e., the control flow, data, time, resource perspectives as well as the interactions a processhas with business partners.

– dealing with compliance rules, which are are triggered multiple times.– reasoning about the violation of compliance rules – reactively & proactively.– specifying compliance metrics and measures.

The remainder of this report is structured as follows: Section 2 discusses related work.Section 3 provides a motivating example. Backgrounds on the extended Compliance RuleGraph (eCRG) language are introduced in Section 4. Section 5 provides an operationalsemantics for the eCRG language. In particular this operational semantics formally specifiesthe transitions between the states of compliance rules. In turn, Section 6 evaluates andclassifies the compliance of an eCRG. Furthermore, the specification of compliance metricsand measures is introduced as well as the provision of recommendations to users. Finally,Section 7 concludes the paper and provides an outlook on future research.


2 Related Work

For a decade, business process compliance has increasingly gained attention and several sur-veys have been published in the meantime (e.g., [19, 8, 20, 21, 5]). Along this trend, interestin compliance monitoring and continous auditing [12] has grown as well. For example, [11]enriches process models with a semantic layer of internal controls. In [13, 22], in turn, thedetailed architectures of an online auditing tools (OLAT) are described. An OLAT allowsmonitoring the operations of an organization in detective, corrective and preventive modes.The spectrum of techniques applied for compliance monitoring is wide spread: Behaviouralprofiles [23] utilize ordering relations in this context, whereas Supeverisory Control Theory[24] prevents users from performing actions leading to compliance violations. Furthermore,visual declarative constraints [25], which are transformed into Event Calculus and LinearTemporal Logic (LTL), have shown increasing popularity. Fuzzy conformance checking [26]calculates an evaluation score that indicates how much the observed process instance com-plies instead of providing a simple yes/no answer.

In order to enable fine-grained compliance diagnostics at run-time, Compliance RuleGraphs [10] and colored automata [16] have been suggested. However, both mainly focus oncontrol flow perspective. In turn, [5] compares approaches for monitoring business processcompliance based on 10 compliance monitoring functionalities (CMF). In particular, it isemphasized that existing approaches do not provide a satisfactorily solution that combinesan expressive language (CMF 1-5) with full compliance traceability (CMF 8+9). Table 1summarizes the results from [5].

Table 1: Compliance monitoring functionalities [5]CMF 1 CMF 2 CMF 3 CMF 4 CMF 5 CMF 6 CMF 7 CMF 8 CMF 9 CMF 10time data resources non life- multi- reactive proactive root compl.

Approach atomic cycle instance mgmt mgmt cause degree

Mubicon LTL [16] +/- - - + - - + + + +/-Mubicon EC [25, 15] + +/- + + + + + - +/- +/-ECE Rules [26] + +/- + + - - + - +/- +SCT [24] +/- - + + + - - + - -SeaFlows [10] +/- +/- +/- + +/- + + + + +/-

As opposed to the approaches described above, [27] monitors performance measures inthe context of artifact-centric process models. In turn, [28, 14, 29] provide techniques to aposteriori verify the compliance of execution logs with a set of constraints. Some of theseapproaches not only focus on the control flow perspective, but take the time perspective [14]or resource perspective [28] into account as well.

A priori or design time compliance checking has been addressed by a multitude of ap-proaches for a long time. Most of them apply model checking techniques (e.g., [30–33]). Inaddition, some of these design time approaches use visual compliance rules and not onlyconsider the control flow perspective, but the data, interaction or time perspectives as well.Other compliance checking approaches, in turn, are based on Petri-Nets [34] and Mixed-Integer Programming [35].

Finally, there are few frameworks, which address the integration of business processcompliance throughout the entire process lifecycle [9, 36, 8, 37, 38].


3 Motivating Example

This section introduces a motivating example, which refers to the event log from Fig. 2and deals with an order-to-delivery process. The latter is subject to three compliance rules,which stem from internal guidelines.

Note that compliance rule c1 is satisfied in one case, but violated in another. In partic-ular, the depicted log refers to two different request items related to customers Mr. Smithand Mrs. John. These items, in turn, trigger two different instances of compliance rule c1.In both cases, the amount is greater than 10,000e and hence a solvency check is required.However, the latter was only performed for the request item of Mr. Smith, but not for theone of Mrs. John (i.e., c1 is violated in the latter case). Besides the violation of c1, compli-ance rule c2 is violated twice as well. While the violated instance of rule c1 will never besuccessfully completed, the violations of c2 still may be healed by informing the agent, whosent the requests, about the results of the approvals.

The compliance rule examples further indicate that solely monitoring control flow de-pendencies between tasks is not sufficient in order to ensure compliance at run-time. Inaddition, constraints in respect to the data, time and resource perspectives of a businessprocess as well as the interactions this process has with partner processes must be moni-tored [39, 21, 17, 18]. For example, the data perspective of compliance rule c1 is addressedby the request item and its amount. In turn, receiving the request item (cf. c1) representsan interaction with a business partner. The phrase ”by different staff members” deals withthe resource perspective, whereas the condition ”at max three days” refers to the time per-spective. To meet practical demand, compliance monitoring must not abstract from theseprocess perspectives.

# date time type id details

37 1/7/2013 15:27 receive 124 Request

38 1/7/2013 15:27 write 124 customer = Mr.Smith

39 1/7/2013 15:27 write 124 amount = 15.000€

39 1/7/2013 15:27 end 124 Request

55 1/7/2013 18:03 receive 592 Request

56 1/7/2013 18:03 write 592 customer = Mrs.John

57 1/7/2013 18:03 write 592 amount = 27.000€

58 1/7/2013 18:03 end 592 Request

77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)

78 2/7/2013 15:43 read 234 customer = Mr.Smith

79 2/7/2013 15:54 write 234 rating= high

80 2/7/2013 15:55 end 234 SolvencyCheck

91 2/7/2013 18:13 start 453 Approval (Mr. Muller)

92 2/7/2013 18:14 read 453 customer = Mr.Smith

93 2/7/2013 18:14 read 453 rating = high

94 2/7/2013 18:17 write 453 result= granted

95 2/7/2013 18:18 end 453 Approval

96 2/7/2013 18:19 start 642 Approval (Mrs. Brown)

97 2/7/2013 18:20 read 642 customer = Mrs.John

98 2/7/2013 18:23 write 642 result = granted

99 2/7/2013 18:23 end 642 Approval

When a request item with an amount

greater then 10,000 is received from

an agent, the request must not be

approved unless the solvency of the

respective customer was checked.

The latter task must be started at max

three days after the receipt. Further,

task approval and task solvency check

must be performed by different staff

members.

After approval of a request item, the

agent must be informed about the

result within one days.

After starting the production related to

a particular order the latter may only

be changed by the head of

production.

c1

c2

c3

Compliance rules

......

......

...

Fig. 2: Event log of order-to-delivery processes and compliance rules


4 Fundamentals of Extended Compliance Rule Graphs

This paper utilizes the extended Compliance Rule Graph (eCRG) language for compliancemonitoring. Since this language is based on the Compliance Rule Graph (CRG) language,we first introduce CRGs before presenting eCRG fundamentals.

4.1 Compliance Rule Graphs

The Compliance Rule Graph (CRG) language was introduced in [40, 10, 41]. It allows forthe visual modeling of compliance rules that focus on the control flow perspective (i.e.,sequence flow) of business processes. A CRG corresponds to an acyclic graph that consistsof an antecedence pattern as well as one or multiple related consequence patterns. Bothkinds of patterns are modeled using occurrence and absence nodes, which either express theoccurrence or absence of events (e.g. events related to the execution of a particular task).Furthermore, the edges connecting these nodes express control flow dependencies.

As illustrated in Fig. 3, an event trace (i.e., a finite sequence of events related to thesame process instance) is considered as compliant with a CRG iff for each match of theantecedence pattern there is at least one corresponding match for one of the consequencepattern. In turn, a trace is considered as trivially compliant iff there is no match of theantecedence pattern at all. As example consider the CRG from Fig. 3. It expresses that foreach B not preceded by an A, a D must occur. Further, there must be no C that precedesB and D.

C D C D

Antecedence pattern Consequence pattern

only match < E, D, F, G, B >

only match < D, F, C, E, B >

no match (A is before B)

only match < C, F, B, G, E >

1st match < B, C, D, E, B >

2nd match < B, C, D, E, B >

< E, D, F, G, B >

< D, F, C, E, B > (C is after D)

-

no match (missing D)

< B, C, D, E, B >

no match (C is before B and D)

A BA B

A B

< E, D, F, G, B >

< D, F, C, E, B >

< A, B, C, E, D >

< C, F, B, G, E >

< B, C, D, E, B >

compliant

compliant

trivially compliant

violation

violation

Antecedence

OccurrenceAntecedence

Absence

Consequence

Absence

Consequence

Occurrence

CRG

Traces

Fig. 3: CRG example and semantics [8]

4.2 Extended Compliance Rule Graph

The CRG language focuses on the control flow perspective of compliance rules, but ignoresother perspectives. In [17, 18], therefore, we introduced the extended Compliance Rule Graph(eCRG) as a visual language for modeling compliance rules not only covering the control flowperspective, but providing integrated support for the resource, data and time perspectives aswell as for interactions with business partners. To cover these various perspectives, the eCRGlanguage allows for attachments in addition to nodes and connectors (i.e. edges). Thereby,nodes refer to entities (e.g. a data object) or events, whereas edges and attachments areused to refine the nodes or edges they are affiliated to. Furthermore, an eCRG may containinstance nodes referring to particular objects, which exist independently from the respectiverule (e.g. Mr. Smith, postnatal ward, physician). Hence, instance nodes are neither part of


the antecedence nor the consequence pattern, but constitute the instance patter. Fig. 4 givesan overview of the elements of the eCRG language.

Oc

cu

ren

ce

Ab

se

nc

e

Antecedence Consequence

Task

Task Task

Task

Data

Object

Data

Object

Data Nodes

An

tec

ed

en

ce

Co

ns

eq

ue

nc

e

GroupOrganizational

UnitStaff

Member

Role

GroupOrganizational

UnitStaff

Member

Role

Resource Nodes

Requests

Request

Pa

rtic

ula

r

Da

ta N

od

es

Quality

Managers

Radiology

Department

Computer

ScientistMr X

Antecedence

Consequence

Time Conditions

>2d

>2d

March 23th

2013

Point in Time

Extended Compliance Rule Graph Language (eCRG)

Process Perspective Time Perspective

Resource Perspective Data Perspective

< value

> valueAntecedence

Consequence

Data Conditions

An

tec

ed

en

ce

Co

ns

eq

ue

nc

e

Pa

rtic

ula

r

Re

so

urc

es

Antecedence Consequence Antecedence Consequence

Sender

ReceiverMessage

Message

Sender

Message

Receiver

Message

Sender

ReceiverMessage

Message

Sender

Message

Receiver

Message

ReceiveSend

Oc

cu

ren

ce

Ab

se

nc

e

Interaction Perspective

Sequence

Exclusion

Antecedence

Alternative

Basic Connectors

Sequence

Exclusion

Consequence

Alternative

property

propertyAntecedence

Consequence

Resource Conditions

Data Container

Data Container

Resource Connectors

Time Nodes

Performing

Relation

Antecedence

assigned to

Performing

Relation

Consequence

assigned to

Data Connectors

Data Flow

Antecedence

Data Flow

Consequence

Knuplesch, Reichert, Ly, Kumar, Rinderle-Ma: Visual Modeling of Business Process Compliance Rules with the Support of Multiple Perspectives. In: ER 2013, LNCS, Springer (2013), pp. 106-120

Fig. 4: Elements of the eCRG language [17, 18]

The elements of the eCRG language are partitioned into the control flow, data, time,resource and interaction perspectives that will be described in the following in more detail(cf. Fig. 4).

Control flow perspective. Modeling the control flow perspective of compliance rules issupported through four kinds of task nodes, i.e., antecedence occurrence, antecedence ab-sence, consequence occurrence, and consequence absence task nodes. Based on these nodesit can be expressed whether or not particular tasks shall be executed. In addition, two kindsof sequence flow connectors are provided that allow constraining the execution sequence oftasks. Note that the absence of a sequence flow indicates parallel flow. Furthermore, ex-clusive connectors express mutual exclusion of the tasks they refer to. Finally, alternativeconnectors express that at least one of the connected tasks must occur.

Interaction perspective. The interaction perspective supports the exchange of messageswith business partners. According to task nodes, four kinds of sending and four kinds ofreceiving message nodes are provided, i.e., antecedence occurrence, antecedence absence,consequence occurrence, and consequence absence nodes.

Time perspective. The eCRG language offers the following elements for modeling the timeperspective: Point-in-time nodes, time condition attachments, and time distance connectors.Point-in-time nodes express a particular date or point-in-time (e.g. 26th October 2014).Time conditions, in turn, may be attached to task nodes and sequence flow connectors toconstrain the duration of a task or the time distance between task nodes, message nodes andpoint-in-time nodes. Finally, time distance connectors allow constraining the time distancewithout implying a particular sequence.


Data perspective. Data container nodes and data object nodes support the modeling ofthe data perspective in eCRGs. Furthermore, data flow connectors, data relation connectorsand data condition attachments are provided. Data container nodes refer to process dataelements or global data stores. By contrast, data object nodes refer to particular data valuesand data object instances. Both kinds of data nodes may be part of the antecedence orconsequence pattern, or represent a particular data container and data object, respectively.Data flow connectors define which process tasks read or write which data objects or datacontainers. To constrain data containers, data objects and data flow, data conditions maybe attached. In turn, data relation connectors allow comparing data objects.

Resource perspective. For modeling the resource perspective of compliance rules, resourcenodes are provided, i.e., staff member, role, group, and organizational unit nodes. Similar totask nodes, resource nodes may be part of the antecedence or consequence pattern. Alter-natively, they may represent a particular resource instance (e.g. Mr. Smith, postnatal ward,physician). To specify dependencies among resources, resource relation connectors are pro-vided. In turn, resource condition attachments constrain a particular resource node. Finally,the performing relation indicates the performer of a task node.

Fig. 5 applies the eCRG language in order to model the compliance rules from ourmotivating example in Section 3, which have been presented in verbalized form in Fig. 2.In particular, Fig. 2(c1) addresses all process perspectives, i.e., the control flow, data, timeand resource perspectives as well as interactions with business partners. In turn, Fig. 2(c2)does not refer to the resource perspective, whereas time and interaction perspectives are notaddressed in Fig. 2(c3).

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

-

c1

customer

amount

> 10,000

Agent

Inform Approval

-

- – - < 1d

result

c2

Change O.

-

- – -

Start Prod.

-

- – -

head of

productionc3

has role

order

<3d

Fig. 5: Modeling compliance rules c1−3 with the eCRG language


A formal specification of an eCRG is provided in Def. 1 (for a more detailed definitionof eCRGs including a formal definition of φ see [42]).

Definition 1 (Extended Compliance Rule Graph (eCRG)).Let T be the set of points in time, R be the set of human resources, and Ω be theset of all data objects. Then: An extended Compliance Rule Graph (eCRG) is a tupleΨ = (N,E,, type, src, tgt, at, pt) with

– N ∶= T ∪MN ∪ O ∪ C ∪ R ∪ P being the set of nodes that may be partitioned into thesets of task nodes T , message nodes MN , data object nodes O, data containernodes C, resource nodes R, and point-in-time nodes P ⊂ T.

– E ∶= # »

sf ∪ #»

df ∪ # »

pfm ∪ #»rr being the set of edges that may be partitioned into the setsof sequence flow edges

# »

sf , data flow edges#»

df , performing relations# »

pfm, andresource relations #»rr.

– ∶= dc ∪ tc ∪ rr being the set of attachments that may be partitioned into the setsof data conditions dc, time conditions tc, and resource conditions rc,

– type ∶ T ∪ MN ∪ #»

df → T mapping each task node (message node, data flow edge) to atask type ( message type, parameter name),

– src ∶ E → N (tgt ∶ E → N) mapping each edge to its source ( target) node,– at ∶ → N ∪ E mapping each attachment to the underlying node or edge it is

attached to, and– pt ∶ N ∪ E ∪ → AO,AA,CO,CA, I mapping each element of an eCRG to the

corresponding pattern.

Further:

– ΛΨ ∶= N ∪ E ∪ is the set of all elements,– ΓΨ ∶= T ∪ MN is the set of task and message nodes,– φΦ ∶ ΛΨ → ΛΨ maps each element to its affiliation; i.e., the element to which it is

affiliated3.– For each set X ⊂ ΛΨ of elements of an eCRG and each patterny ∈ AO,AA,CO,CA, I, we define Xy ∶= x ∈ X ∣pt(x) = y as thepattern y of X.

AO

AA

CA

CO

I

Fig. 6: Dependencies of eCRG pattern

Function pt partitions the elements of an eCRG in five patterns, which are the instancepattern (I) as well as the antecedence occurrence (AO), antecedence absence (AA), con-sequence occurrence (CO), and consequence absence (CA) patterns. Dependencies amongthese patterns are shown in Fig. 6, whereas the lower ones depend on the upper ones they


are connected to. Based on the latter, Def. 2 formally specifies how connected elements con-strain and depend on each other. In particular, a node, edge or attachment λ1 depends onanother element λ2, if they are connected and the pattern of λ1 depends on the one of λ2.For example, task node production depends on its outgoing sequence flow edge in Fig. 5(c3).In turn, in Fig. 5(c3), message node request does not depend on both outgoing sequenceflows. Instead, the latter depend on the message node.

Definition 2 (Pattern Dependency Order).Let Ψ = (N,E,, type, src, tgt, at, pt) be an eCRG and let λ1, λ2 ∈ ΛΨ be two elements ofthe eCRG. Then:

– defines the partial dependency order over the set of patterns as specified in Fig. 6(e.g. I AA),

– We say λ1 has a higher dependency level than λ (i.e., λ1▷λ2), iff the pattern of λ1 isgreater than the one of λ2 according to the dependency order , i.e.,

λ1 ▷ λ2 ∶⇔ pat(λ1) pat(λ2)

– and ⊵, ≜, ◁ and ⊴ are defined accordingly.


5 eCRG Operational Semantics

This section introduces the operational semantics of the eCRG language that enables visuallymonitoring business process compliance at run-time. As discussed in Section 1, the latter isbased on event streams that occur during the execution of business processes. In particular,compliance monitoring shall detect or, if possible, prevent compliance violations. For thispurpose, first of all, Section 5.1 introduces the different events that are supported. Second,the fundamental states of a compliance rule are introduced in Section 5.2. Third, Section 5.3specifies markings that annotate the elements of an eCRG with text, colors and symbols.Finally, Section 5.4 specifies the processing of events and discusses how the latter evolve andunfold markings of an eCRG (cf. Section 5.4).

5.1 Events

As this report addresses compliance monitoring in respect to multiple process perspectives,we not only monitor events that refer to the start and end of tasks. In addition, we considerevents that correspond to the sending and receiving of messages as well as data flow eventsthat log how activities read from and write to data sources. Furthermore, events may includetemporal information as well as information about involved resources.

Table 2 summarizes the event types supported by our approach. Note that each eventincludes the time it occurs as well as a unique id. The latter enables us to identify correlationsbetween the start, end and data flow events related to the same task or message.

Table 2: Supported Events

Task eventsstart(time, id, tasktype, performer)end(time, id, tasktype, performer)

Message eventssend(time, id, message)receive(time, id, message)end(time, id, message)

Data flow events write(time, id, valueparamÐÐÐ→ source)

read(time, id, valueparam←ÐÐÐ source)

Based on the events from Table 2, Def. 3 formally specifies event logs and streams.

Definition 3 (Event Log or Event Stream).Let E be the set of events (cf. Table 2) and let T be the discrete set of points in time. Then:

– L ∶ N→ E ∪ ∅ is an event stream or event log,– time ∶ E → T ∶ time(event(ϑ, . . . )) ∶= ϑ maps each event to the corresponding point-

in-time.

Note that we assume that event streams are correct; i.e., they do not deviate (cf. [43])from the real process, ids are unique, and events are provided in an ascending order (i.e.,∀i, j ∈ [1..posL] ∶ i < j ⇒ time(L(i)) ≤ time(L(j))).

5.2 States of Compliance Rules

When monitoring the compliance of running process instances, compliance rules take vary-ing states [10, 8]. Fig. 7 outlines the states that are supported by our approach. The most


fundamental state is Not Activated, i.e., the compliance rule does not concern the run-ning process instances until now. The opposite state Activated means that the compliancerule affects the process instance and includes the sub-states TempSatisfied and Tem-pViolated. TempSatisfied is further partitioned into Violable and Satisfied, whereasTempViolated includes the sub-states Pending and Violated. As explained by our mo-tivating example in Section 3, business process can multiply trigger (i.e. activate) compliancerule. Hence, a compliance rule can be in state Activated multiple times as indicated bysuperscript ”+”. Note that each of these activations of a compliance rule can take a differentsub-state. For instance, the event log of our motivating example activates compliance rule c1twice (cf. Fig. 2). The first activation is Satisfied, whereas the second activation remainsin state Violated.

ACTIVATED

TEMPVIOLATED

(non-compliance)

TEMPSATISFIED

(compliance)

VIOLABLE

SATISFIED

PENDING

VIOLATED

NOT_ACTIVATED

(trivial compliance)

+

Fig. 7: States of compliance rules

5.3 eCRG Markings

To monitor the state of a compliance rule, we annotate and mark the elements of an eCRG(cf. Section 4, [17, 18]) with symbols, colors and text (cf. Figs. 8). Such a marking of aneCRG (i.e., annotated eCRG) highlights whether or not the events corresponding to a nodehave occurred so far. Further, it describes whether conditions corresponding to edges andattachments are satisfied, violated, or still will be evaluated (cf. Figs. 8). Since there maybe different activations and instantiations of a particular compliance rule, Def. 4 defines thestate of an eCRG in terms of a set of markings, which, in turn, can be utilized to calculatethe corresponding states of compliance as introduced in Section 5.2.

Po

ints

in

tim

eT

as

ks

an

d M

es

sa

ge

s

no

t a

cti

va

ted

sk

ipp

ed

co

mp

lete

d

run

nin

g

ac

tiv

ate

d

abs

occ

Task

date

performer

timestart–timeend

Sender

Messagedate time

Task

performer

dateend timeend

datestart timestart timestart

Receiver

Messagedate time

December

23th 2023

future

October

26th 2013

past

< 2d

< 2d

an

tec.

co

ns

.

< 2d

< 2d

< 2d

< 2d < 50

< 50

< 50

< 50

< 50

< 50

sa

tis

fie

d

Time

Condition

Resource/Data

Condition

no

t m

ark

ed

Attachments

an

tec.

co

ns

.a

nte

c.

co

ns

.

an

tec.

co

ns

.

≠

≠

≠

≠

≠

≠

sa

tis

fie

d

Sequence

Flow

Data

Flow

Performing

RelationResource/Data

Relation

no

t m

ark

ed

Edges

an

tec.

co

ns

.a

nte

c.

co

ns

.

vio

late

d

vio

late

d

Nodes

Fig. 8: Annotations of eCRG elements


Definition 4 (Markings and State of an eCRG).Let I be a set of unique identifiers. Let further T be the set of points intime, R be the set of human resources, and Ω be the set of all data ob-jects, whereas ε is the empty value, i.e., the placeholder for not yet set iden-tifiers, points in time, human resources, and data objects. Furthermore, letΨ = (N,E,, type, src, tgt, at, pt) be an eCRG. Then: A marking M of Ψ is a tupleM = (m,res, val, id, ts, te) where

– m ∶ ΛΨ → ◻,,,,⨉ marks each element of the eCRG with eitherNot Activated/Not Marked (◻), Activated (), Running (), Completed/Satisfied (), or Skipped (⨉).

– res ∶ T ∪ R ∪ # »

pfm→ ε ∪ R assigns a resource to each task node, resource node andperforming relation edge,

– val ∶ O ∪ #»

df → ε ∪ Ω assigns a value to each data object node and data flow edge,

– id ∶ T ∪ MN ∪ C ∪ #»

df → ε ∪ I assigns an unique identifier to each task node,message node, data container node, or data flow edge,

– ts ∶ T ∪ MN ∪ P → ε ∪ T (and te ∶ T ∪ MN ∪ P → ε ∪ T respectively) assigns astarting ( ending) time to each task node, message node, and point-in-time node.

Further, we define

– M inΨ ∶= (m,res, val, id, ts, te) as the initial marking of eCRG Ψ , where m(x) ∶= ◻ marks every element x with ◻, ts(x) ∶= te(x) ∶= ε sets starting and ending times to ε, and

res(x) ∶= ε, iff x ∉ Ix, else

val(x) ∶= ε, iff x ∉ Ix, else

id(x) ∶= ε, iff x ∉ Ix, else

only assign resources, values and identifiers to elements of the instance pattern.– MΨ as the set of all markings of Ψ ,– ML,i

Ψ ⊆ MΨ as the state of eCRG Ψ after processing event stream Luntil entry i ∈ N, and

– MinΨ ∶= M in

Ψ as the initial state of Ψ .

5.4 Operational Semantics

In order to enable the processing of events in the context of the extended Compliance RuleGraph (eCRG) language, this section introduces the eCRG operational semantics. In par-ticular Defs. 5-10 specify how the different event types are processed (cf. Fig. 9). First, allmarkings must be updated to the point-in-time of the event occured (cf. Def. 5). Second,effects of the update (i.e., the updated annotations) are propagated to adjacent elements (cf.Def. 10). Third, Defs. 6-9 specify the actual handling of an event based on its type. Finally,annotations are propagated once again before completing the processing of an event.Note that the first two steps may be skipped if time does not differ from the one of the eventdirectly processed before. In turn, these two steps may be applied without the subsequentones in order to calculate the current state of a compliance rule at any point-in-time betweentwo events.

5.4.1 Update Marking

Def. 5 specifies the update of a marking to the current point-in-time. In particular, theannotation of point-in-time nodes changes from Not Marked ◻ to Completed , if the


UpdateMarking

EffectPropagation

Start EventHandling

Message EventHandling

EffectPropagation

End EventHandling

Data Event Handling

start(…)

end(…)

receive(…)send(…)

read(…)write(…)

Fig. 9: Processing of start, message, data and end events

points in time to which the nodes refer have passed (t1). Furthermore, time conditions onrunning task nodes or sequence flow edges will be Skipped (⨉) if they are no longer satis-fiable (t2).

Definition 5 (Update Marking).Let M ∶= (m,res, val, id, ts, te) ∈ MΨ be a marking of eCRG Ψ and let ϑ ∈ T be apoint-in-time. Then: updϑ ∶ MΨ → MΨ with updϑ(M) ∶= (m′, res, val, id, ts, te) calculatesthe update of marking M to point-in-time ϑ, where

m′(λ) ∶=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

, if λ ∈ P ∧m(λ) = ◻ ∧ λ ≤ ϑ, (t1)

⨉, if λ ∈ tc ∧m(λ) = ◻ ∧ (t ∶= at(tc) ∈ T ) (t2)∧ (∀ς ∈ T ∶ (ς ≥ ϑ)⇒ ¬tc(ts(t), ς)) ,

⨉, if λ ∈ tc ∧m(λ) = ◻ ∧ ((n1, n2) ∶= at(tc) ∈# »

sf) (t2)∧ (∀ς ∈ T ∶ (ς ≥ ϑ)⇒ ¬tc(te(n1), ς)) ,

m(λ), else

Fig. 10 updates marking B of compliance rule c1 from our motivating example (cf.Fig. 2) to the point in time 4/7/2013 16:05. According to Def. 5(t2), the time conditionon the sequence flow edge from message node is marked as skipped, because it can not besatisfied any more.

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

B

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000

58 1/7/2013 18:03 end 592 Request

+ propagation of effects

> 10,000

<3d

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

B‘

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

<3d

## 4/7/2013 16:05 update

Fig. 10: Update of markings


5.4.2 Start and Message Event Handling

Def. 6 (Def. 7) non-deterministically handles start events (message events), in order todeal with different instantiations of a compliance rule. In particular, the set of matching andactivated task nodes (message nodes) is determined first. Then, for each subset a new mark-ing is instantiated, which solely changes the marking of the selected nodes from Activated() to Running (), and, accordingly, sets the identifiers, resources and starting times (cf.Fig. 11). Node that the empty set is among the subsets and the result hence includes theunchanged original marking as well.

Definition 6 (Start Event Handling).Let M ∶= (m,res, val, id, ts, te) ∈ MΨ be a marking of eCRG Ψ and σ = start(ϑ, ι, τ, ρ)be a start event. Then:

– ∆σ(M) ∶= λ ∈ T ∣m(λ) = ∧ type(λ) = τ is the set of matching and activated tasknodes,

– For each subset δ ⊆∆σ(M), hdlσδ ∶MΨ →MΨ with hdlσδ (M) ∶= (mδ, resδ, val, idδ, tδs, te)calculates the handling of start event σ by node set δ and marking M :

mδ(λ) ∶= , iff λ ∈ δm(λ), else

resδ(λ) ∶= ρ, iff λ ∈ δres(λ), else

idδ(λ) ∶= ι, iff λ ∈ δid(λ), else

tδs(λ) ∶= ϑ, iff λ ∈ δid(λ), else

– hdlσ ∶ MΨ → 2MΨ with hdlσ(M) ∶= hdlσδ (M)∣δ ∈ ∆σ(M) calculates all handlingsof σ by M .

Definition 7 (Message Event Handling).Let M ∶= (m,res, val, id, ts, te) ∈ MΨ be a marking of eCRG Ψ and let σ = send(ϑ, ι, τ)(and receive(ϑ, ι, τ) respectively) be a message event. Then:

– ∆σ(M) ∶= λ ∈ MN ∣m(λ) = ∧ type(λ) = τ is the set of matching and activatedmessage nodes,

– For each subset δ ⊆∆σ(M), hdlσδ ∶MΨ →MΨ with hdlσδ (M) ∶= (mδ, resδ, val, idδ, tδs, te)calculates the handling of message event σ by node set δ and marking M :

mδ(λ) ∶= , iff λ ∈ δm(λ), else

idδ(λ) ∶= ι, iff λ ∈ δid(λ), else

tδs(λ) ∶= ϑ, iff λ ∈ δid(λ), else

– hdlσ ∶ MΨ → 2MΨ with hdlσ(M) ∶= hdlσδ (M)∣δ ∈ ∆σ(M) calculates all handlingsof σ by M .

Fig. 11 illustrates the handling of a start and message events. In particular, the receiptof the message request starts the corresponding message node of marking 0 in the upperexample; i.e., the node is marked as Running () and labeled with the receive time of themessage. The lower example handles the start-event of task solvency check. The correspond-ing task node is marked as Running. Furthermore, its the start time and performer of thetask are specified.


Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

-

0

customer

amount

> 10,000

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a1

customer

amount

> 10,000

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 18:03

B

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

Solvency C.

... ... – ...

37 1/7/2013 15:27 receive 124 Request

<3d <3d

<3d

## 1/7/2013 15:27 update

propagation of effects

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 18:03

d1

customer

Mrs.

Johnamount

27,000M

rs. Jo

hn

27,000> 10,000

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ... <3d

Mrs.

Brown


58 1/7/2013 18:03 end 592 Request

+ propagation of effects

Fig. 11: Handling of start and message events

5.4.3 End Event Handling

Since we use unique identifiers for start, message and end events, the latter can be pro-cessed deterministically (cf. Def. 8). In particular, the annotations of all nodes assigned tothe identifier of the end event and marked with Running (), are changed to Completed() and their ending time is set accordingly (cf. Fig. 12).

Definition 8 (End Event Handling).Let M ∶= (m,res, val, id, ts, te) ∈ MΨ be a marking of eCRG Ψ and σ =end(ϑ, ι, τ, ρ)(and end(ϑ, ι, τ) respectively) be an end event. Then: hdlσ ∶ MΨ → 2MΨ withhdlσ(M) ∶= (m′, res, val, id, ts, t

′

e) calculates the the handling of end event σ by mark-ing M :

m′ ∶= , iff id(λ) = ιm(λ), else

t′e(λ) ∶= ϑ, iff id(λ) = ιid(λ), else

Fig. 12 shows the handling of an end event. In particular, the processing of the messagerequest is finished and the the corresponding message node of marking a5 is marked asCompleted ().


Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a6

customer

Mr.

Smithamount

15,000

Mr.

Sm

ith

15,000

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a5

customer

Mr.

Smithamount

15,000

Mr.

Sm

ith

15,000> 10,000


57 1/7/2013 18:03 write 592 amount = 27.000€

<3d

> 10,000

<3d

39 1/7/2013 15:27 end 124 Request+ propagation of effects

Fig. 12: Handling of end events

5.4.4 Data Event Handling

We can also process data events deterministically, since the combination of the usedunique identifiers and the used parameter names clearly refers to the data flow edges con-cerned (cf. Def. 9). In particular, the latter is marked as Satisfied () and annotated withthe data value and the identifier of the data source or data target; i.e., the identifier of adata container (cf. Fig. 13).

Definition 9 (Data Event Handling).Let M ∶= (m,res, val, id, ts, te) ∈ MΨ be a marking of eCRG Ψ . Further, let

σ =write(ϑ, ι, υ parÐÐ→ ω) (and read(ϑ, ι, υ par←ÐÐ ω) respec-tively) be a data event. Then: hdlσ ∶ MΨ → 2MΨ , withhdlσ(M) ∶= (m′, res, val′, id′, ts, te) calculates the handling of data event σ bymarking M :

m′(λ) ∶= , if λ = (n, t) ∈ #»

df ∧m(λ) = ◻ ∧ id(n) = ι ∧ m(n) = ∧ type(λ) = parm(λ), else

val′(λ) ∶= υ, if λ = (n, t) ∈ #»

df ∧m(λ) = ◻ ∧ id(n) = ι ∧ m(n) = ∧ type(λ) = parval(λ), else

id′(λ) ∶= ω, if λ = (n, t) ∈ #»

df ∧m(λ) = ◻ ∧ id(n) = ι ∧ m(n) = ∧ type(λ) = parid(λ), else

Fig. 13 illustrates the handling of a data events. The writing data flow event amountof the message request is handled in the upper example. In particular, the correspondingoutgoing data flow edge of message node request is marked as Satisfied () and annotatedwith the amount of 15.000. The lower example handles the reading data flow event customerthat marks the incoming data flow edge of task solvency check as Satisfied () and anno-tates it with the customer Mr. Smith. Note that the latter annotation Mr. Smith does notmeet the value Mrs. John of the data object customer ; i.e., the handling of data flow eventsallows for conflicts. Furthermore, note that we omit the identifiers of data sources (i.e., datacontainers) in our examples for the sake of simplicity.


Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a3

customer

amount


15,000> 10,000

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

d3

customer

Mrs.

Johnamount

27,000M

rs.

Jo

hn

27,000> 10,000

Mr. Smith

<3d

<3d

Mrs.

Brown

38 1/7/2013 15:27 write 124 amount = 15.000€

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a2

customer

amount

> 10,000

<3d

37 1/7/2013 15:27 receive 124 Request

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 18:03

d2

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ... <3d

Mrs.

Brown

propagation of effects 78 2/7/2013 15:43 read 234 customer = Mr.Smith


Fig. 13: Handling of data events

5.4.5 Propagation of effects

After each update or event handling, we propagate the corresponding effects (i.e., changesto annotations) on adjacent nodes and edges in order to ensure correct annotations (e.g.,activation of subsequent task nodes). Further, we detect contradictory annotations relatedto the data and resource perspectives (cf. Def. 10).

In particular, resources are propagated from task nodes to Not Marked (◻), dependentresource nodes (r2) by following resource edges (r1). In turn, data values and the identifiersof data containers are propagated from data flow edges to Not Marked (◻), dependentdata object nodes (d1) as well as data container nodes (d2). Next, the edge and its targetnode are marked with Satisfied () (x3).

Note that the aforementioned propagation steps are not performed, if resources, datavalues or identifiers of target resource nodes, data objects or data containers were alreadyset to another value before. To highlight such conflicts, the corresponding data flow andresource edges will be marked with Skipped (⨉) (x4). Not Marked (◻) data flow edgeswill be also marked with Skipped (⨉) if the corresponding task or message node is completed(d5). Afterwards, all conditions (x6) and relations are reevaluated (x7). If any elementof the eCRG, affiliated to a dependent task or message node, is now Skipped (⨉), thecorresponding task or message node will be marked with Skipped (⨉) as well (x8).

Next, the outgoing sequence flows of completed nodes are marked with Satisfied ()(cf1). In turn, Not Marked (◻), incoming sequence flow edges of already started nodes aremarked with Skipped (⨉). Further, sequence flow edges from and to Skipped (⨉) nodes


are marked with Skipped (⨉) as well (cf2). Task and message nodes become Activated() when all incoming sequence flows, on which it depends, are marked as Satisfied ()satisfied (cf3). In turn, task or message nodes will be marked with Skipped (⨉) when theydepend on incoming sequence flows being Skipped (⨉) before (cf4). Note that the lattermight trigger (cf2) again.

Definition 10 (Effect Propagation).Let M ∶= (m,res, val, id, ts, te) ∈ MΨ be a marking of eCRG Ψ . Then: prop ∶ MΨ → MΨ ,prop(M) ∶= (m(⋆), res(1), val(1), id(1), ts, te) propagates effects on M , whereby

res(1)(λ) ∶=⎧⎪⎪⎪⎪⎨⎪⎪⎪⎪⎩

ρ, if (λ = (t, r) ∈ # »

pfm ∧ m(λ) = ◻ ∧ res(t) = ρ) (r1)∨ (λ ∈ R ∧ res(λ) = ε ∧ (∃e ∶= (t, λ) ∈ # »

pfm ∧ λ ≜ e ∧ res(e) = ρ)) (r2)res(λ), else,

val(1)(λ) ∶= υ, if λ ∈ O ∧ val(λ) = ε ∧ (∃e ∶= (n,λ) ∈ #»

df ∶ λ ≜ e ∧ res(e) = υ) (d1)val(λ), else,

id(1)(λ) ∶= ω, if λ ∈ C ∧ id(λ) = ε ∧ (∃e ∶= (n,λ) ∈ #»

df ∶ λ ≜ e ∧ id(e) = ω) (d2)id(λ), else,

m(1)(λ) ∶=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

, if (λ ∈ R ∧ m(λ) = ◻ ∧ res(1)(λ) ≠ ε) (x3)∨ (λ ∈ O ∧ m(λ) = ◻ ∧ val(1)(λ) ≠ ε) (x3)∨ (λ ∈ C ∧ m(λ) = ◻ ∧ id(1)(λ) ≠ ε) (x3)∨ (λ = (t, r) ∈ # »

pfm ∧ m(λ) = ◻ ∧ res(1)(r) = res(1)(λ)) (x3)∨ (λ = (n, o) ∈ #»

df ∧ o ∈ O ∧ m(λ) = ◻ ∧ val(1)(o) = val(1)(λ)) (x3)∨ (λ = (n, c) ∈ #»

df ∧ c ∈ C ∧ m(λ) = ◻ ∧ id(1)(c) = id(1)(λ)) (x3)⨉, if (λ = (t, r) ∈ # »

pfm ∧ m(λ) = ◻ ∧ res(1)(r) ≠ res(1)(λ)) (x4)∨ (λ = (n, o) ∈ #»

df ∧ o ∈ O ∧ m(λ) = ◻ ∧ val(1)(o) ≠ val(1)(λ)) (x4)∨ (λ = (n, c) ∈ #»

df ∧ c ∈ C ∧ m(λ) = ◻ ∧ id(1)(c) ≠ id(1)(λ)) (x4)∨ (λ = (n, o) ∈ #»

df ∧ o ∈ O ∧ m(λ) = ◻ ∧ m(n) =) (d5)∨ (λ = (n, c) ∈ #»

df ∧ c ∈ C ∧ m(λ) = ◻ ∧ m(n) =) (d5)m′(λ), else,

m(2)(λ) ∶=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

, if (λ ∈ ∧ m(1)(at(λ)) = ∧ λ(at(λ))) (x6)∨ (λ = (r1, r2) ∈ #»rr ∪ ∧m(1)(r1) = ∧ m(1)(r2) = ∧ λ(r1, r2)) (x7)∨ (λ = (o1, o2) ∈

#»

dr ∪ ∧m(1)(o1) = ∧ m(1)(o2) = ∧ λ(o1, o2)) (x7)⨉, if (λ ∈ ∧ m(1)(at(λ)) = ∧ λ(at(λ))) (x6)

∨ (λ = (r1, r2) ∈ #»rr ∪ ∧m(1)(r1) = ∧ m(1)(r2) = ∧ λ(r1, r2)) (x7)∨ (λ = (o1, o2) ∈

#»

dr ∪ ∧m(1)(o1) = ∧ m(1)(o2) = ∧ λ(o1, o2)) (x7)m(1)(λ), else,

m(3)(λ) ∶= ⨉, if ∃λ′ ∈ Λ ∶ φ(λ′) = λ ∧ λ′ ≜ λ ∧ m(2)(λ′) = ⨉ (x8)m(2)(λ), else,

m(4)(λ) ∶= , if λ = (n1, n2) ∈# »

sf ∧ m(λ) = ◻ ∧ m(3)(n1) = (cf1)m(3)(λ), else,

m(5)(λ) ∶=⎧⎪⎪⎪⎨⎪⎪⎪⎩

, if λ ∈ T ∪ MN ∧ m(4)(λ) = ◻∧ (∀e = (n,λ) ∈ # »

sf ∶ e ≜ λ⇒m(4)(e) =) (cf3)m(4)(λ), else,


.

for i ≥ 6:

m(i+1)(λ) ∶=

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

⨉, if (λ = (n1, n2) ∈# »

sf ∧ m(i)(λ) = ◻ ∧ m(i)(n1) = ⨉) (cf2)∨ (λ = (n1, n2) ∈

# »

sf ∧ m(i)(λ) = ◻ ∧ m(i)(n2) ∈ ,,⨉) (cf2)∨ (λ ∈ T ∪ MN ∧ m(i)(λ) = ◻∧ (∃e = (n,λ) ∈ # »

sf ∶ e ≜ λ ∧ m(i)(e) = ⨉)) (cf4)m(i)(λ), else, and

m(⋆) ∶= m(j)(j ∶= mini ∈ N∣i ≥ 6 ∧ m(i) = m(i+1)) is the final marking, which isreached, when the propagation terminates.

Figs. 14-17 highlight the propagation after updates as well as after the handling of start,message, end, and data events. In particular, Fig. 14 transfers the annotation Skipped (⨉) ofthe time condition on the corresponding sequence flow edge that was marked with Satisfied() before. Based on this change, the subsequent task node solvency check is marked withSkipped (⨉) as well and its Non Marked (◻), incoming and outgoing sequence flow edges.Finally, the annotation Skipped (⨉) is propagated to the consequence absence task nodeapproval as well as the consequence occurrence task node approval. Hence, the final markingFig. 14(B′′) shows a temporal conflict.

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 18:03

B‘‘

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

<3d

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

B‘

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

<3d

+ propagation of effects## 4/7/2013 16:05 update

Fig. 14: Effect propagation after updates and temporal conflict

In Fig. 15, the effects of a start event are propagated. In particular, the adjacent resourceedge and resource node become Completed () and are annotated with resource Mrs.Brown. Further, the Non Marked (◻), incoming sequence flow edge of the just startedtask node solvency check is marked with Skipped (⨉). Finally, the consequence absencetask node approval becomes also Skipped (⨉).

Fig. 16 propagates the effects of an end event. In particular, the outgoing sequenceflow edges of the just completed message node request are marked with Satisfied ().Furthermore, the subsequent task nodes solvency check and approval become Activated().

The effects of data events are propagated in Fig. 17. In the upper example, the value15,000 of the data flow edge used is written on the target data object amount that alsobecomes Satisfied (). Further, the antecedence data condition the respective data flow issuccessfully evaluated and hence also marked as satisfied. As opposed to this, the comparisonof the data object customer and its just written outgoing data flow edge fails. Hence, thelatter data flow edge changes from Satisfied () to Skipped (⨉). Due to this change, thesubsequent task node solvency check is marked with Skipped (⨉) as well and its outgoing


Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 18:03

d1

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000


Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

d2

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ... <3d <3d


Mrs.

Brown

Fig. 15: Effect propagation after handling start events

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a6

customer

Mr.

Smithamount

15,000

Mr.

Sm

ith

15,000

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

A

customer

Mr.

Smithamount

15,000

Mr.

Sm

ith

15,000> 10,000 > 10,000

propagation of effects39 1/7/2013 15:27 end 124 Request

<3d <3d

Fig. 16: Effect propagation after handling end events

sequence flow edge. Finally, the annotation Skipped (⨉) is also propagated on the followingconsequence occurrence task node approval. Hence, Fig. 14(D) highlights a data conflict.

Finally, Def. 11 formally specifies the update of the state of an eCRG to the currentpoint in time as well as the processing of a particular event based on Defs. 5-10 and Fig. 9.

Definition 11 (Event processing procedure).

Let ML,iΨ be the state of an eCRG Ψ after processing event stream L until the ith position

(i ∈ N), and let σ ∶= L(i + 1) be the upcoming event on the following position of L andϑ ∶= time(σ) ∈ T be the current point in time. Then:

– ML,i→ϑΨ ∶= M ′∣M ′ = prop(updϑ(M)) ∧ M ∈ML,i

Ψ is the state of Ψ after processingevent stream L until position i and after the update to the current point in time ϑ and

– ML,i+1Ψ ∶= prop(M ′)∣M ′ ∈ hdlσ(M) ∧ M ∈ML,i→ϑ

Ψ is the state of Ψ after processingσ, i.e. after processing event stream L until position i + 1.

Table 3 outlines the set of markings that results when completely processing the eventstream from Fig. 1 for compliance rule c1. Note that marking F ensures that c1 is satisfied forthe request of Mr. Smith as highlighted in Fig. 18. In turn, Figs. 14(B′′), 17(D), 18(I), and18(J) highlight conflicts regarding the data, control flow, time, and resource perspectives.


Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a3

customer

amount

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

a4

customer

amount

15,00015,000

> 10,000


15,000> 10,000

Agent

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

d3

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

Mr. Smith

Agent

Mrs.

Brown

rating

≠

Request

Approval

-

- – -

Approval

-

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

D

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

Mr. Smith

78 2/7/2013 15:43 read 234 customer = Mr.Smith propagation of effects

<3d <3d

<3d <3d

Mrs.

Brown

38 1/7/2013 15:27 write 124 amount = 15.000€

Fig. 17: Effect propagation after handling data events and data conflict

Note that such conflicts only indicate why the considered events do not constitute a solutionof a particular compliance rule. However, there might be another set of events that provide asatisfaction. In turn, Fig. 15(d2) indicates, which data values shall be read by task solvencycheck and how task approval shall be performed afterwards in order to satisfy c1. Hence,Fig. 15(d2) may be utilized as recommendation to users in order to proactively ensurecompliance.

Table 3: Compliance state ML,99c1

Request Approval Solvency Approval customer cust→ cust→ amount rating Activated# (CA) Check (CO) App.(CA) Solv.C

0 ◻ ◻ ◻ ε ε ε ε ε

A 124 ◻ Smith ε ε 15.000 ε B 592 ◻ John ε ε 27.000 ε C 124 ⨉ 234 Brown Smith ε Smith 15.000 high

D 592 ⨉ 234 Brown ⨉ John ε Smith 27.000 ε

E 592 ⨉ 453 Muller ◻ John Smith ε 27.000 ε

F 124 ⨉ 234 Brown 453 Muller Smith ε Smith 15.000 high

G 124 453 Muller ◻ Smith Smith ε 15.000 high

H 124 ⨉ 234 Brown ⨉ 642 Brown Smith ε Smith 15.000 ε

I 592 642 Brown ◻ John John ε 27.000 ε

J 129 ⨉ 642 Brown ◻ Smith John ε 25.000 ε


Agent

rating

≠

Request

Approval

-

- – -

Approval

2/7/2013

Mr. Muller

18:13 – 18:18

Solvency C.

2/7/2013

Mrs. Brown

15:43 – 15:55

1/7/2013 15:27

F

customer

Mr.

Smithamount

15,000

Mr.

Sm

ith

15,000> 10,000

Mr. Smith

high

<3d

Mrs.

Brown

Mr.

Muller

Agent

rating

≠

Request

Approval

-

- – -

Approval

2/7/2013

Mrs. Brown

18:19 – ...

Solvency C.

2/7/2013

Mrs. Brown

15:43 – 15:55

1/7/2013 15:27

J

customer

Mr.

Smithamount

15,000

Mrs

. S

mith

15,000> 10,000

Mr. Smith

high

<3d

Mrs.

Brown

Mrs.

Brown

Agent

rating

≠

Request

Approval

2/7/2013

18:19 – 18:23

Approval

-

- – -

Solvency C.

-

- – -

1/7/2013 15:27

I

customer

Mrs.

Johnamount

27,000

Mrs

. Jo

hn

27,000> 10,000

<3d

Mrs. Brown

Mrs

. Jo

hn

27,0

00

Fig. 18: Fulfilling marking as well as control-flow and resource conflicts


6 Compliance Analytics

Another fundamental requirement of any compliance monitoring approach is to providedetailed user feedback. In this context, Section 6.1 introduces well-defined compliance as-sessments that not only highlight compliance violations, but also identify their causes. Inaddition, Section 6.2 shows how compliance metrics can be specified and how correspondingmeasurements can be obtained. Finally, Section 6.3 provide recommendations that supportusers in selecting the next process steps, whose execution will ensure compliance.

6.1 Compliance Assessments

Providing compliance assessments requires the analysis of the state of an eCRG and themarkings it contains in order to clearly determine the corresponding states of compliance; i.e.,either Not Activated, Violable, Satisfied, Pending, or Violated (cf. Section 5.2).For this purpose, first of all, Def. 12 introduces a partial order over markings. The latterallows clustering the markings that correspond to each other as well as to specify and distin-guish between different activations of an eCRG in Def. 13. Based on the latter, Def.14 finallyprovides compliance assessments; i.e., calculates the state of compliance (cf. Section 5.2) inorder to enable simple and intuitive classifications.

Definition 12 (Extensions of Markings).Let Ψ = (N,E,, type, src, tgt, at, pt) be an eCRG and MΨ the current state of complianceof Ψ . Further, let M = (m,res, val, id, ts, te) and M ′ = (m′, res′, val′, id′, t′s, t

′

e) be twomarkings of Ψ ; i.e., M,M ′ ∈M. Then: We say

– We say M is extended by M ′ and write M ⪯ M ′, iff M ′ only differs from M inmarkings that are neither Running () nor Completed () in M , i.e.,

M ⪯M ′ ∶⇔ ∀n ∈ T ∪ M ∶m(n) ∉ , ∨ id(n) = id′(n)

Definition 13 (Activated Markings).Let Ψ = (N,E,, type, src, tgt, at, pt) be an eCRG and MΨ be the current state of com-pliance of Ψ . Further, let M = (m,res, val, id, ts, te) be a marking of Ψ ; i.e., M,M ′ ∈M.Then: We say

– M is activated or an activation of Ψ (written as Activated(M)), iff M markseach element of the antecedence occurrence pattern as satisfied, but does not satisfy anyelement of the antecedence absence pattern. Furthermore, neither extends M anotheractivated marking nor exists a marking in M that extends M and satisfies a conditionof the antecedence absence pattern.

Activated(M) ∶⇔ ((∀λ ∈ ΛAOΨ ∶m(λ) =)∧(∀α ∈ ΓAA,CO,CAΨ ∶m(α) ∈ ◻,,⨉) ∧ id(α) = ε)∧(∀M2 ∈M with M ⪯M2 ∶ ∀α ∈ ΓAAΨ ∶m2(α) ≠)∧(∀M3 ∈M with M3 ⪯M ∶ ¬Activated(M3))


Definition 14 (Compliance Assessments).Let Ψ = (N,E,, type, src, tgt, at, pt) be an eCRG and MΨ be the current state of Ψ .Further, let M ∈M be an activated marking; i.e. Activated(M).Then: We say

– M is temporally satisfied (written as TempSatisfied(M)), iff there exists amarking M2 that extends M and satisfies the consequence; i.e. M2 marks each elementof the consequence occurrence pattern with Satisfied() and does not satisfy anyelement of the consequence absence pattern. Further, there exists no marking in Mthat extends M2 and satisfies a condition of the consequence absence pattern.

TempSatisfied(M) ∶⇔ ( ∃M2 ∈M with M ⪯M2 ∶ (∀λ ∈ ΛCOΨ ∶m2(λ) =)∧(∀α ∈ ΓCAΨ ∶m2(α) ∈ ◻,,⨉ ∧ id(α) = ε)∧(∀M3 ∈MwithM ⪯M2 ⪯M3 ∶ ∀α ∈ ΓCAΨ ∶m3(α) ≠))

– M is violable (violably satisfied) (written as Violable(M)), iff M is temporallysatisfied, but for each M2 extending M and satisfying the consequence pattern, thereremains at least one consequence absence node that has not been marked with Skipped(⨉) yet; i.e. that node might be executed in the following steps.

Violable ∶⇔ TempSatisfied(M)∧ ( ∀M2 ∈M with M ⪯M2 ∶ (∀λ ∈ ΛCOΨ ∶m2(λ) =)

∧ (∀α ∈ ΓCAΨ ∶m2(α) ∈ ◻,,⨉ ∧ id(α) = ε)∧ (∀M3 ∈MwithM ⪯M2 ⪯M3 ∶ ∀α ∈ ΓCAΨ ∶m3(α) ≠)∧ (∃α ∈ ΓCAΨ ∶m2(α) ∈ ◻,))

– M is (permanently) satisfied (written as Satisfied(M)), iff M is temporally sat-isfied, but not violable; i.e.,

Satisfied(M) ∶⇔ TempSatisfied(M) ∧ ¬Violable(M)

– M is (permanently) violated (written as Violated(M)), iff each marking M2 ex-tending M marks an element of the consequence occurrence pattern with Skipped (⨉)or there exists a marking M3 extending M2 and satisfying a condition of the conse-quence absence pattern.

Violated(M) ∶⇔ (∀M2 ∈M with M ⪯M2 ∶ (∃λ ∈ ΛCOΨ ∶m2(λ) = ⨉)∨ (∃M3 ∈M with M ⪯M2 ⪯M3 ∶ ∃α ∈ ΓCAΨ ∶m3(α) =))

– M is pending (written as Pending(M)), iff M is neither (temporally) satisfied norviolated yet.

Pending(M) ∶⇔ ¬TempSatisfied(M) ∧ ¬Violated(M)

Table. 4 applies Def. 14 to markings A and B from Table 3. Note that A and B arethe only activations of c1 in ML,99

c1 , since all other markings extend either marking A orB (except the initial marking 0). In particular, Table 4 shows that c1 is activated twice;once satisfied and once violated. Further, Table 4 emphasises the events that complete theactivations (39+58), the fulfillment (95), and the violation (99).


Table 4: Compliance assessments and metrics# Extensions Activated TempSatisfied Violable Satisfied Violated PendingA A, C, F, G 39-. . . 95-. . . 95-. . . 39-95B B, D, E, H 58-. . . 99-. . . 58-99

6.2 Compliance Metrics and Measures

In the context of multiple instances and activations of compliance rules, providing compli-ance assessments for single activations is no longer sufficient. In turn, additional summarieson an higher level are required. For this purpose, compliance assessments (cf. Sec. 6.1) arecombined to realize more sophisticated compliance metrics and measures. First of all, thissection formally specifies the cardinality of properties in Def. 15 and, then, shows how thelatter can be utilized for calculating compliance metrics and measures.

Definition 15 (Cardinality of a Property).Let Ψ = (N,E,, type, src, tgt, at, pt) be an eCRG and MΨ be the current state of compli-ance of compliance rule Ψ . Then:

#PropΨ ∶= ∣M ∈MΨ ∣Prop(M)∣ is the cardinality of property Prop; i.e., the number

of markings with property Prop ∈ Activated, TempSatisfied, Violable, Satis-fied, Violated, Pending.

Note that it is easy to specify metrics based on Def. 15. As example consider Table. 5,which refers to 3 metrics. In particular, the compliance rate µ1, the critical rate µ2, and theviolation rate µ3 are defined and calculated with respect to the motivating example fromSection 3. (cf. Fig. 2 and Table 4).

Table 5: Compliance assessments and metricscompliance rate µ1(c1) critical rate µ2(c1) violation rate µ3(c1)

µ1(c1) =#TempSatisfiedc1#Activatedc1

µ2(c1) =#Violablec1

+#Pendingc1

#Activatedc1

µ3(c1) =#Violatedc1

#Activatedc1

# date time

0 1/7/2013 15:00 n.d. n.d. n.d.

1 1/7/2013 17:00 01 = 0.00 0+1

1 = 1.00 01 = 0.00

2 1/7/2013 19:00 02 = 0.00 0+2

2 = 1.00 02 = 0.00

3 2/7/2013 17:00 02 = 0.00 0+2

2 = 1.00 02 = 0.00

4 2/7/2013 18:18 12 = 0.50 0+1

2 = 0.50 02 = 0.00

5 2/7/2013 19:00 12 = 0.50 0+0

2 = 0.00 12 = 0.50

Table. 5 shows the progress of the compliance rate µ1(c1), critical rate µ2(c1) and vio-lation rate µ3(c1) for compliance rule c1 over time and along the event log from Fig. 2. Aslong as no request is received, there is no activation of c1 and hence all rates are not yetdefined (cf. line 0). Due the request from Mr. Smith at 1/7/2013 – 15:27 compliance rule c1


is activated once in state Pending. Therefore, the critical rate µ2(c1) becomes 1.00, but thecompliance rate µ1(c1) as well as violation rate µ3(c1) become 0.00 (cf. line 1). In turn, thevalues of µ1(c1), µ2(c1) and µ3(c1) are neither changed by the request from Mrs. John at1/7/2013 – 18:03, which activates c2 the second time, nor by the solvency check at 2/7/2013– 15:43 (cf. line 2+3). This is due to the fact that the second activation of c1 starts also instate pending as well as the first activation remains pending even after the solvency check.However, when the request of Mr. Smith is approved at 2/7/2013 – 18:13, the correspondingactivation is Satisfied. Hence, the compliance rate µ1(c1) increases to 0.50 and criticalrate µ2(c1) decreases to 0.50 as well, whereas the violation rate µ3(c1) stagnates at 0.00 (cf.line 4). Finally, the second activation of c1 becomes Violated by the approval at 2/7/2013– 18:19. Accordingly, no activation remains Pending and the critical rate µ2(c1) drops to0.00 In turn, the violation rate µ3(c1) increases to 0.50 as the compliance rate µ1(c1) didbefore.

6.3 Recommendations

Section 5.4 argues that steps ensuring the compliant continuation of business process in-stances can be recommend based on markings. However, this requires the selection of appro-priate markings. Note that the simple approach taking the marking that provides the mostextensive extension of an activation does not always fit. Consider Table 6, which providesthe set of markings M95

Ψ after processing the event log from Fig. 2 up to event 95. Forboth activations A and B there is an extending marking (A ⪯ C and B ⪯ D). However,in the first case, C provides the adequate recommendation, whereas in the second case therecommendation is not D, but B.

Table 6: Compliance state ML,80c1

Request Approval Solvency Approval customer cust→ cust→ amount rating Activated# (CA) Check (CO) App.(CA) Solv.C

0 ◻ ◻ ◻ ε ε ε ε ε

A 124 ◻ Smith ε ε 15.000 ε B 592 ◻ John ε ε 27.000 ε C 124 ⨉ 234 Brown Smith ε Smith 15.000 high

D 592 ⨉ 234 Brown ⨉ John ε Smith 27.000 ε

Def. 16 provides a more advanced and proper selection of markings that may then beused as recommendation.

Definition 16 (Recommendations).Let Ψ = (N,E,, type, src, tgt, at, pt) be an eCRG and MΨ be the current state of compli-ance rule Ψ . Further, let M ∈MΨ be an activated and not violated marking; i.e., it holds:Activated(M) ∧ ¬Violated(M). Then: We say

– M2 ∈MΨ is a simple recommendation for activation M of compliance rule Ψ (writ-ten as M ⪯rM2), iff M2 extends M and M2 neither skips any part of the consequenceoccurrence pattern nor satisfies any part of the consequence absence pattern nor it thereis another marking M3 ∈MΨ further extending M2, i.e.,

M ⪯rM2 ∶⇔M ⪯M2

∧ (∄α ∈ ΓCOΨ ∶m2(α) = ⨉)∧ (∄M3 ∈M with M ⪯M2 ⪯M3 ∶ ∃α ∈ ΓCAΨ ∶m3(φ(α)) =)


.

– M2 ∈MΨ is a (real) recommendation for the activation of Ψ through marking M(written asM ⪯RM2), iff M2 is a simple recommendation for M and there is no otherrecommendation M3 ∈MΨ for M extending M2, i.e.,

M ⪯RM2 ∶⇔M ⪯rM2

∧ ∄M3 ∈M with M ⪯rM3 ∶M2 ≺M3 (i.e., M2 ⪯M3 ∧ M2 ≠M3)

– R ∶Mψ → 2Mψ ∶ R(M) ∶= M ′ ∈MΨ ∣M ⪯RM ′ is the set of all recommendationsfor M .

Note that each marking M , which is Activated and not Violated, must have at least onesimple and, hence, also one real recommendation. Otherwise, it would match the definitionof Violated (cf. Def. 14).

The application of Def. 16 on our example results in R(A) = C and R(B) = B. Notethat the application of R to an activation might still result in more than one recommen-dation. In this case, each recommendation corresponds to another, already started solutionapproach ensuring compliance with the respective rule. However, if only a single recom-mendation is desired, the most advanced recommendation (i.e., satisfying most consequenceoccurrence nodes) or the latest one can easily be selected.


7 Summary and Outlook

This report introduces an operational semantics for the extended compliance rule graph(eCRG) language [17, 18]. Beyond the control flow perspective, the latter supports the mon-itoring of the data, time, and resource perspectives as well as the monitoring of the inter-actions with partners. In particular, eCRGs are annotated with text, colors and symbols inorder to visually highlight the current state of compliance. Furthermore, formal definitionsspecify how observed events continuously change and evolve these annotations. Further-more, formal criteria for assessing compliance are provided, which, in turn, constitute thebasis for compliance metrics introduced as examples. Finally, the recommendations are pro-vided, which support users in selecting the next process steps, whose execution will ensurecompliance.

As opposed to other approaches enabling the monitoring of business process complianceat run-time, the operational semantics of the eCRG language supports all 10 compliancemonitoring functionalities (CMF) that have been proposed in [5] (cf. Table 7). In particular,full support of the control flow, data, time, and resource perspectives (CMF 1-3) is providedas well as interactions with partners are considered. The proposed approach assumes activ-ities to be non-atomic, but stateful (CMF 4+5). Different instantiations (i.e., activations)of compliance rules are explicitly identified and are further extended to highlight the causesof compliance violations (CMF 6+9). Beyond detecting the latter (i.e. reactive monitoring),recommendations (i.e., proactive monitoring) are provided as well (CMF 7+8). Finally, theoperational semantics of the eCRG language builds a suitable basis for the specification ofcompliance metrics in order to measure different degrees of compliance (CMF 10).

Table 7: Compliance monitoring functionalities [5]CMF 1 CMF 2 CMF 3 CMF 4 CMF 5 CMF 6 CMF 7 CMF 8 CMF 9 CMF 10time data resources non life- multi- reactive proactive root compl.

Approach atomic cycle instance mgmt mgmt cause degree

Mubicon LTL [16] +/- - - + - - + + + +/-

Mubicon EC [15] + +/- + + + + + - +/- +/-

ECE Rules [26] + +/- + + - - + - +/- +

SCT [24] +/- - + + + - - + - -

SeaFlows [10] +/- +/- +/- + +/- + + + + +/-

eCRG Op. Semantics + + + + + + + + + +

Next steps will be the implementation of a proof-of-concept prototype in order to eval-uate the operational semantics for the eCRG language.

Note that this work was done within the research project C3Pro that deals with changeand compliance in cross-organizational business processes [21]. Accordingly, our overall aimis to ensure multi-perspective compliance for all phases of the process life cycle. Hence, wewill investigate a priori compliance checking with the eCRG at design time as well as weplan to consider compliance checking in the context of cross-organizational process changesand change propagation [44].


References

1. Reichert, M., Weber, B.: Enabling Flexibility in Process-Aware Information Systems - Chal-lenges, Methods, Technologies. Springer (2012)

2. van der Aalst, W.M.P.: Verification of workflow nets. In: ICATPN’97. Volume 1248 of LNCS.,Springer (1997) 407–426

3. Reichert, M., Dadam, P.: A framework for dynamic changes in workflow management systems.In: DEXA’97. (1997) 42–48

4. Ly, L.T., Knuplesch, D., Rinderle-Ma, S., Goser, K., Pfeifer, H., Reichert, M., Dadam, P.:SeaFlows toolset - compliance verification made easy for process-aware information systems.In: Information Systems Evolution - CAiSE Forum 2010. Volume 72 of LNBIP., Springer (2011)76–91

5. Ly, L.T., Maggi, F.M., Montali, M., Rinderle-Ma, S., van der Aalst, W.M.P.: A framework forthe systematic comparison and evaluation of compliance monitoring approaches. In: EDOC’13,IEEE (2013) 7–16

6. Sadiq, S., Governatori, G., Naimiri, K.: Modeling control objectives for business process com-pliance. In: BPM’07. Volume 4714 of LNCS., Springer (2007) 149–164

7. Lenz, R., Reichert, M.: IT support for healthcare processes premises, challenges, perspectives.Data & Knowledge Engineering 61(1) (2007) 39–58

8. Knuplesch, D., Reichert, M.: Ensuring business process compliance along the process life cycle.Technical Report 2011-06, Ulm University (2011)

9. Ly, L.T., Rinderle, S., Dadam, P.: Integration and verification of semantic constraints in adap-tive process management systems. Data & Knowledge Engineering 64(1) (2008) 3–23

10. Ly, L.T., Rinderle-Ma, S., Knuplesch, D., Dadam, P.: Monitoring business process complianceusing compliance rule graphs. In: CoopIS’11. Volume 7044 of LNCS. (2011) 82–99

11. Namiri, K., Stojanovic, N.: Pattern-Based design and validation of business process compliance.In: CAiSE’07. Volume 4803 of LNCS., Springer (2007) 59–76

12. Alles, M., Kogan, A., Vasarhelyi, M.: Putting continuous auditing theory into practice: Lessonsfrom two pilot implementations. Information Systems 22(2) (2008) 195–214

13. van der Aalst, W.M.P., van Hee, K.M., van der Werf, J.M.E.M., Kumar, A., Verdonk, M.:Conceptual model for online auditing. Decision Support Systems 50(3) (2011) 636–647

14. Ramezani Taghiabadi, E., Fahland, D., van Dongen, B.F., van der Aalst, W.M.P.: Diagnos-tic information for compliance checking of temporal compliance requirements. In: CAiSE’13.Volume 7908 of LNCS., Springer (2013) 304–320

15. Montali, M., Maggi, F.M., Chesani, F., Mello, P., van der Aalst, W.M.P.: Monitoring businessconstraints with the event calculus. Transactions on Intelligent Systems and Technology 5(1)(2014) 17.1–17.30

16. Maggi, F., Montali, M., Westergaard, M., van der Aalst, W.M.P.: Monitoring business con-straints with linear temporal logic: an approach based on colored automata. In: BPM’11.(2011) 132–147

17. Knuplesch, D., Reichert, M., Ly, L.T., Kumar, A., Rinderle-Ma, S.: Visual modeling of businessprocess compliance rules with the support of multiple perspectives. In: ER’2013. Volume 8217of LNCS., Springer (2013) 106–120

18. Semmelrodt, F., Knuplesch, D., Reichert, M.: Modeling the resource perspective of businessprocess compliance rules with the extended compliance rule graph. In: BPMDS’14. Volume 175of LNBIP., Springer (2014) 48–63

19. Kharbili, M.E., de Medeiros, A., Stein, S., van der Aalst, W.M.P.: Business process compliancechecking: Current state and future challenges. In: MobIS’08. (2008) 107–113

20. Becker, J., Delfmann, P., Eggert, M., Schwittay, S.: Generalizability and applicability of model-based business process compliance-checking approaches. BuR - Business Research 5(2) (2012)221–247

21. Knuplesch, D., Reichert, M., Mangler, J., Rinderle-Ma, S., Fdhila, W.: Towards complianceof cross-organizational processes and their changes. In: BPM’12 Workshops. Volume 132 ofLNBIP., Springer (2013) 649–661

22. Accorsi, R.: An approach to data-driven detective internal controls for processaware informationsystems. In: DUMW’12. (2012) 29–33


23. Weidlich, M., Ziekow, H., Mendling, J., Gunther, O., Weske, M., Desai, N.: Event-based mon-itoring of process execution violations. In: BPM’11. Volume 6896 of LNCS., Springer (2011)182–198

24. Santos, E., Francisco, R., Vieira, A., de F.R. Loures, E., Busetti, M.: Modeling business rulesfor supervisory control of process-aware information systems. In: BPM’11 Workshops. Volume100 of LNBIP. Springer (2012) 447–458

25. Maggi, F.M., Montali, M., van der Aalst, W.M.P.: An operational decision support frameworkfor monitoring business constraints. In: FASE’12. Volume 7212 of LNCS., Springer (2012)146–162

26. Bragaglia, S., Chesani, F., Mello, P., Montali, M., Sottara, D.: Fuzzy conformance checking ofobserved behaviour with expectations. In: AI*IA’11. Volume 6934 of LNCS., Springer (2011)80–91

27. Liu, R., Vaculn, R., Shan, Z., Nigam, A., Wu, F.: Business artifact-centric modeling for real-time performance monitoring. In: BPM’11 Workshops. Volume 6896 of LNCS., Springer (2012)265–280

28. Baumgrass, A., Baier, T., Mendling, J., Strembeck, M.: Conformance checking of RBAC policiesin process-aware information systems. In: BPM’12 Workshops. Volume 100 of LNBIP., Springer(2012) 435–446

29. Outmazgin, N., Soffer, P.: A process mining-based analysis of business process work-arounds.Software & Systems Modeling (2014) 1–15

30. Awad, A., Weidlich, M., Weske, M.: Specification, verification and explanation of violation fordata aware compliance rules. In: ICSOC’09. Volume 5900 of LNCS., Springer (2009) 500–515

31. Knuplesch, D., Ly, L.T., Rinderle-Ma, S., Pfeifer, H., Dadam, P.: On enabling data-awarecompliance checking of business process models. In: ER’2010. Volume 6412 of LNCS., Springer(2010) 332–346

32. Knuplesch, D., Reichert, M., Fdhila, W., Rinderle-Ma, S.: On enabling compliance of cross-organizational business processes. In: BPM’13. Volume 8094 of LNCS. Springer (2013) 146–154

33. Knuplesch, D., Reichert, M., Pryss, R., Fdhila, W., Rinderle-Ma, S.: Ensuring compliance ofdistributed and collaborative workflows. In: CollaborateCom’13, IEEE (2013) 133–142

34. Accorsi, R., Lowis, L., Sato, Y.: Automated certification for compliant cloud-based businessprocesses. Business & Information Systems Engineering 3(3) (2011) 145–154

35. Kumar, A., Yao, W., Chu, C.: Flexible process compliance with semantic constraints usingmixed-integer programming. INFORMS Journal on Computing 25(3) (2013) 543–559

36. Ly, L.T., Rinderle-Ma, S., Goser, K., Dadam, P.: On enabling integrated process compliancewith semantic constraints in process management systems. Information Systems Frontiers 14(2)(2012) 195–219

37. Ramezani, E., Fahland, D., van der Werf, J.M., Mattheis, P.: Separating compliance man-agement and business process management. In: BPM’11 Workshops. Volume 100 of LNBIP.,Springer (2012) 459–464

38. Koetter, F., Kochanowski, M., Weisbecker, A., Fehling, C., Leymann, F.: Integrating compliancerequirements across business and it. In: EDOC’14, IEEE (2014)

39. Cabanillas, C., Resinas, M., Ruiz-Cortes, A.: Hints on how to face business process compliance.Jornadas de Ingeniera del Software y Bases de Datos 4(4) (2010) 26–32

40. Ly, L.T., Rinderle-Ma, S., Dadam, P.: Design and verification of instantiable compliance rulegraphs in process-aware information systems. In: CAiSE’10. Volume 6051 of LNCS., Springer(2010) 9–23

41. Ly, L.T.: SeaFlows - A Compliance Checking Framework for Supporting the Process Lifecycle.Dissertation Thesis, University of Ulm, Germany (2013)

42. Knuplesch, D., Reichert, M., Ly, L.T., Kumar, A., Rinderle-Ma, S.: On the formal semanticsof the extended compliance rule graph. Technical Report 2013-05, Ulm University (2013)

43. Gou, Y., Ghose, A.K., Chang, C.F., Dam, H.K., Miller, A.: Semantic monitoring and compen-sation in socio-technical processes. In: ER’2014 Workshops. Volume 8823 of LNCS., Springer(2014) 117–126

44. Fdhila, W., Indiono, C., Rinderle-Ma, S., Reichert, M.: Dealing with change in process chore-ographies: Design and implementation of propagation algorithms. Information Systems 49(April 2015) 1–24

Liste der bisher erschienenen Ulmer Informatik-Berichte Einige davon sind per FTP von ftp.informatik.uni-ulm.de erhältlich

Die mit * markierten Berichte sind vergriffen

List of technical reports published by the University of Ulm Some of them are available by FTP from ftp.informatik.uni-ulm.de

Reports marked with * are out of print 91-01 Ker-I Ko, P. Orponen, U. Schöning, O. Watanabe

Instance Complexity

91-02* K. Gladitz, H. Fassbender, H. Vogler Compiler-Based Implementation of Syntax-Directed Functional Programming

91-03* Alfons Geser Relative Termination

91-04* J. Köbler, U. Schöning, J. Toran Graph Isomorphism is low for PP

91-05 Johannes Köbler, Thomas Thierauf Complexity Restricted Advice Functions

91-06* Uwe Schöning Recent Highlights in Structural Complexity Theory

91-07* F. Green, J. Köbler, J. Toran The Power of Middle Bit

91-08* V.Arvind, Y. Han, L. Hamachandra, J. Köbler, A. Lozano, M. Mundhenk, A. Ogiwara, U. Schöning, R. Silvestri, T. Thierauf Reductions for Sets of Low Information Content

92-01* Vikraman Arvind, Johannes Köbler, Martin Mundhenk On Bounded Truth-Table and Conjunctive Reductions to Sparse and Tally Sets

92-02* Thomas Noll, Heiko Vogler Top-down Parsing with Simulataneous Evaluation of Noncircular Attribute Grammars

92-03 Fakultät für Informatik 17. Workshop über Komplexitätstheorie, effiziente Algorithmen und Datenstrukturen

92-04* V. Arvind, J. Köbler, M. Mundhenk Lowness and the Complexity of Sparse and Tally Descriptions

92-05* Johannes Köbler Locating P/poly Optimally in the Extended Low Hierarchy

92-06* Armin Kühnemann, Heiko Vogler Synthesized and inherited functions -a new computational model for syntax-directed semantics

92-07* Heinz Fassbender, Heiko Vogler A Universal Unification Algorithm Based on Unification-Driven Leftmost Outermost Narrowing

92-08* Uwe Schöning On Random Reductions from Sparse Sets to Tally Sets

92-09* Hermann von Hasseln, Laura Martignon Consistency in Stochastic Network

92-10 Michael Schmitt A Slightly Improved Upper Bound on the Size of Weights Sufficient to Represent Any Linearly Separable Boolean Function

92-11 Johannes Köbler, Seinosuke Toda On the Power of Generalized MOD-Classes

92-12 V. Arvind, J. Köbler, M. Mundhenk Reliable Reductions, High Sets and Low Sets

92-13 Alfons Geser On a monotonic semantic path ordering

92-14* Joost Engelfriet, Heiko Vogler The Translation Power of Top-Down Tree-To-Graph Transducers

93-01 Alfred Lupper, Konrad Froitzheim AppleTalk Link Access Protocol basierend auf dem Abstract Personal Communications Manager

93-02 M.H. Scholl, C. Laasch, C. Rich, H.-J. Schek, M. Tresch The COCOON Object Model

93-03 Thomas Thierauf, Seinosuke Toda, Osamu Watanabe On Sets Bounded Truth-Table Reducible to P-selective Sets

93-04 Jin-Yi Cai, Frederic Green, Thomas Thierauf On the Correlation of Symmetric Functions

93-05 K.Kuhn, M.Reichert, M. Nathe, T. Beuter, C. Heinlein, P. Dadam A Conceptual Approach to an Open Hospital Information System

93-06 Klaus Gaßner Rechnerunterstützung für die konzeptuelle Modellierung

93-07 Ullrich Keßler, Peter Dadam Towards Customizable, Flexible Storage Structures for Complex Objects

94-01 Michael Schmitt On the Complexity of Consistency Problems for Neurons with Binary Weights

94-02 Armin Kühnemann, Heiko Vogler A Pumping Lemma for Output Languages of Attributed Tree Transducers

94-03 Harry Buhrman, Jim Kadin, Thomas Thierauf On Functions Computable with Nonadaptive Queries to NP

94-04 Heinz Faßbender, Heiko Vogler, Andrea Wedel Implementation of a Deterministic Partial E-Unification Algorithm for Macro Tree Transducers

94-05 V. Arvind, J. Köbler, R. Schuler On Helping and Interactive Proof Systems

94-06 Christian Kalus, Peter Dadam Incorporating record subtyping into a relational data model

94-07 Markus Tresch, Marc H. Scholl A Classification of Multi-Database Languages

94-08 Friedrich von Henke, Harald Rueß Arbeitstreffen Typtheorie: Zusammenfassung der Beiträge

94-09 F.W. von Henke, A. Dold, H. Rueß, D. Schwier, M. Strecker Construction and Deduction Methods for the Formal Development of Software

94-10 Axel Dold Formalisierung schematischer Algorithmen

94-11 Johannes Köbler, Osamu Watanabe New Collapse Consequences of NP Having Small Circuits

94-12 Rainer Schuler On Average Polynomial Time

94-13 Rainer Schuler, Osamu Watanabe Towards Average-Case Complexity Analysis of NP Optimization Problems

94-14 Wolfram Schulte, Ton Vullinghs Linking Reactive Software to the X-Window System

94-15 Alfred Lupper Namensverwaltung und Adressierung in Distributed Shared Memory-Systemen

94-16 Robert Regn Verteilte Unix-Betriebssysteme

94-17 Helmuth Partsch Again on Recognition and Parsing of Context-Free Grammars: Two Exercises in Transformational Programming

94-18 Helmuth Partsch Transformational Development of Data-Parallel Algorithms: an Example

95-01 Oleg Verbitsky On the Largest Common Subgraph Problem

95-02 Uwe Schöning Complexity of Presburger Arithmetic with Fixed Quantifier Dimension

95-03 Harry Buhrman,Thomas Thierauf The Complexity of Generating and Checking Proofs of Membership

95-04 Rainer Schuler, Tomoyuki Yamakami Structural Average Case Complexity

95-05 Klaus Achatz, Wolfram Schulte Architecture Indepentent Massive Parallelization of Divide-And-Conquer Algorithms

95-06 Christoph Karg, Rainer Schuler Structure in Average Case Complexity

95-07 P. Dadam, K. Kuhn, M. Reichert, T. Beuter, M. Nathe ADEPT: Ein integrierender Ansatz zur Entwicklung flexibler, zuverlässiger kooperierender Assistenzsysteme in klinischen Anwendungsumgebungen

95-08 Jürgen Kehrer, Peter Schulthess Aufbereitung von gescannten Röntgenbildern zur filmlosen Diagnostik

95-09 Hans-Jörg Burtschick, Wolfgang Lindner On Sets Turing Reducible to P-Selective Sets

95-10 Boris Hartmann Berücksichtigung lokaler Randbedingung bei globaler Zieloptimierung mit neuronalen Netzen am Beispiel Truck Backer-Upper

95-11 Thomas Beuter, Peter Dadam: Prinzipien der Replikationskontrolle in verteilten Systemen

95-12 Klaus Achatz, Wolfram Schulte Massive Parallelization of Divide-and-Conquer Algorithms over Powerlists

95-13 Andrea Mößle, Heiko Vogler Efficient Call-by-value Evaluation Strategy of Primitive Recursive Program Schemes

95-14 Axel Dold, Friedrich W. von Henke, Holger Pfeifer, Harald Rueß A Generic Specification for Verifying Peephole Optimizations

96-01 Ercüment Canver, Jan-Tecker Gayen, Adam Moik Formale Entwicklung der Steuerungssoftware für eine elektrisch ortsbediente Weiche mit VSE

96-02 Bernhard Nebel Solving Hard Qualitative Temporal Reasoning Problems: Evaluating the Efficiency of Using the ORD-Horn Class

96-03 Ton Vullinghs, Wolfram Schulte, Thilo Schwinn An Introduction to TkGofer

96-04 Thomas Beuter, Peter Dadam Anwendungsspezifische Anforderungen an Workflow-Mangement-Systeme am Beispiel der Domäne Concurrent-Engineering

96-05 Gerhard Schellhorn, Wolfgang Ahrendt Verification of a Prolog Compiler - First Steps with KIV

96-06 Manindra Agrawal, Thomas Thierauf Satisfiability Problems

96-07 Vikraman Arvind, Jacobo Torán A nonadaptive NC Checker for Permutation Group Intersection

96-08 David Cyrluk, Oliver Möller, Harald Rueß An Efficient Decision Procedure for a Theory of Fix-Sized Bitvectors with Composition and Extraction

96-09 Bernd Biechele, Dietmar Ernst, Frank Houdek, Joachim Schmid, Wolfram Schulte Erfahrungen bei der Modellierung eingebetteter Systeme mit verschiedenen SA/RT–Ansätzen

96-10 Falk Bartels, Axel Dold, Friedrich W. von Henke, Holger Pfeifer, Harald Rueß Formalizing Fixed-Point Theory in PVS

96-11 Axel Dold, Friedrich W. von Henke, Holger Pfeifer, Harald Rueß Mechanized Semantics of Simple Imperative Programming Constructs

96-12 Axel Dold, Friedrich W. von Henke, Holger Pfeifer, Harald Rueß Generic Compilation Schemes for Simple Programming Constructs

96-13 Klaus Achatz, Helmuth Partsch From Descriptive Specifications to Operational ones: A Powerful Transformation Rule, its Applications and Variants

97-01 Jochen Messner Pattern Matching in Trace Monoids

97-02 Wolfgang Lindner, Rainer Schuler A Small Span Theorem within P

97-03 Thomas Bauer, Peter Dadam A Distributed Execution Environment for Large-Scale Workflow Management Systems with Subnets and Server Migration

97-04 Christian Heinlein, Peter Dadam Interaction Expressions - A Powerful Formalism for Describing Inter-Workflow Dependencies

97-05 Vikraman Arvind, Johannes Köbler On Pseudorandomness and Resource-Bounded Measure

97-06 Gerhard Partsch Punkt-zu-Punkt- und Mehrpunkt-basierende LAN-Integrationsstrategien für den digitalen Mobilfunkstandard DECT

97-07 Manfred Reichert, Peter Dadam ADEPTflex - Supporting Dynamic Changes of Workflows Without Loosing Control

97-08 Hans Braxmeier, Dietmar Ernst, Andrea Mößle, Heiko Vogler The Project NoName - A functional programming language with its development environment

97-09 Christian Heinlein Grundlagen von Interaktionsausdrücken

97-10 Christian Heinlein Graphische Repräsentation von Interaktionsausdrücken

97-11 Christian Heinlein Sprachtheoretische Semantik von Interaktionsausdrücken

97-12 Gerhard Schellhorn, Wolfgang Reif Proving Properties of Finite Enumerations: A Problem Set for Automated Theorem Provers

97-13 Dietmar Ernst, Frank Houdek, Wolfram Schulte, Thilo Schwinn Experimenteller Vergleich statischer und dynamischer Softwareprüfung für eingebettete Systeme

97-14 Wolfgang Reif, Gerhard Schellhorn Theorem Proving in Large Theories

97-15 Thomas Wennekers Asymptotik rekurrenter neuronaler Netze mit zufälligen Kopplungen

97-16 Peter Dadam, Klaus Kuhn, Manfred Reichert Clinical Workflows - The Killer Application for Process-oriented Information Systems?

97-17 Mohammad Ali Livani, Jörg Kaiser EDF Consensus on CAN Bus Access in Dynamic Real-Time Applications

97-18 Johannes Köbler,Rainer Schuler Using Efficient Average-Case Algorithms to Collapse Worst-Case Complexity Classes

98-01 Daniela Damm, Lutz Claes, Friedrich W. von Henke, Alexander Seitz, Adelinde Uhrmacher, Steffen Wolf Ein fallbasiertes System für die Interpretation von Literatur zur Knochenheilung

98-02 Thomas Bauer, Peter Dadam Architekturen für skalierbare Workflow-Management-Systeme - Klassifikation und Analyse

98-03 Marko Luther, Martin Strecker A guided tour through Typelab

98-04 Heiko Neumann, Luiz Pessoa Visual Filling-in and Surface Property Reconstruction

98-05 Ercüment Canver Formal Verification of a Coordinated Atomic Action Based Design

98-06 Andreas Küchler On the Correspondence between Neural Folding Architectures and Tree Automata

98-07 Heiko Neumann, Thorsten Hansen, Luiz Pessoa Interaction of ON and OFF Pathways for Visual Contrast Measurement

98-08 Thomas Wennekers Synfire Graphs: From Spike Patterns to Automata of Spiking Neurons

98-09 Thomas Bauer, Peter Dadam Variable Migration von Workflows in ADEPT

98-10 Heiko Neumann, Wolfgang Sepp Recurrent V1 – V2 Interaction in Early Visual Boundary Processing

98-11 Frank Houdek, Dietmar Ernst, Thilo Schwinn Prüfen von C–Code und Statmate/Matlab–Spezifikationen: Ein Experiment

98-12 Gerhard Schellhorn Proving Properties of Directed Graphs: A Problem Set for Automated Theorem Provers

98-13 Gerhard Schellhorn, Wolfgang Reif Theorems from Compiler Verification: A Problem Set for Automated Theorem Provers

98-14 Mohammad Ali Livani SHARE: A Transparent Mechanism for Reliable Broadcast Delivery in CAN

98-15 Mohammad Ali Livani, Jörg Kaiser Predictable Atomic Multicast in the Controller Area Network (CAN)

99-01 Susanne Boll, Wolfgang Klas, Utz Westermann A Comparison of Multimedia Document Models Concerning Advanced Requirements

99-02 Thomas Bauer, Peter Dadam Verteilungsmodelle für Workflow-Management-Systeme - Klassifikation und Simulation

99-03 Uwe Schöning On the Complexity of Constraint Satisfaction

99-04 Ercument Canver Model-Checking zur Analyse von Message Sequence Charts über Statecharts

99-05 Johannes Köbler, Wolfgang Lindner, Rainer Schuler Derandomizing RP if Boolean Circuits are not Learnable

99-06 Utz Westermann, Wolfgang Klas Architecture of a DataBlade Module for the Integrated Management of Multimedia Assets

99-07 Peter Dadam, Manfred Reichert Enterprise-wide and Cross-enterprise Workflow Management: Concepts, Systems, Applications. Paderborn, Germany, October 6, 1999, GI–Workshop Proceedings, Informatik ’99

99-08 Vikraman Arvind, Johannes Köbler Graph Isomorphism is Low for ZPPNP and other Lowness results

99-09 Thomas Bauer, Peter Dadam Efficient Distributed Workflow Management Based on Variable Server Assignments

2000-02 Thomas Bauer, Peter Dadam Variable Serverzuordnungen und komplexe Bearbeiterzuordnungen im Workflow- Management-System ADEPT

2000-03 Gregory Baratoff, Christian Toepfer, Heiko Neumann Combined space-variant maps for optical flow based navigation

2000-04 Wolfgang Gehring Ein Rahmenwerk zur Einführung von Leistungspunktsystemen

2000-05 Susanne Boll, Christian Heinlein, Wolfgang Klas, Jochen Wandel Intelligent Prefetching and Buffering for Interactive Streaming of MPEG Videos

2000-06 Wolfgang Reif, Gerhard Schellhorn, Andreas Thums Fehlersuche in Formalen Spezifikationen

2000-07 Gerhard Schellhorn, Wolfgang Reif (eds.) FM-Tools 2000: The 4th Workshop on Tools for System Design and Verification

2000-08 Thomas Bauer, Manfred Reichert, Peter Dadam Effiziente Durchführung von Prozessmigrationen in verteilten Workflow- Management-Systemen

2000-09 Thomas Bauer, Peter Dadam Vermeidung von Überlastsituationen durch Replikation von Workflow-Servern in ADEPT

2000-10 Thomas Bauer, Manfred Reichert, Peter Dadam Adaptives und verteiltes Workflow-Management

2000-11 Christian Heinlein Workflow and Process Synchronization with Interaction Expressions and Graphs

2001-01 Hubert Hug, Rainer Schuler DNA-based parallel computation of simple arithmetic

2001-02 Friedhelm Schwenker, Hans A. Kestler, Günther Palm 3-D Visual Object Classification with Hierarchical Radial Basis Function Networks

2001-03 Hans A. Kestler, Friedhelm Schwenker, Günther Palm RBF network classification of ECGs as a potential marker for sudden cardiac death

2001-04 Christian Dietrich, Friedhelm Schwenker, Klaus Riede, Günther Palm Classification of Bioacoustic Time Series Utilizing Pulse Detection, Time and Frequency Features and Data Fusion

2002-01 Stefanie Rinderle, Manfred Reichert, Peter Dadam Effiziente Verträglichkeitsprüfung und automatische Migration von Workflow- Instanzen bei der Evolution von Workflow-Schemata

2002-02 Walter Guttmann Deriving an Applicative Heapsort Algorithm

2002-03 Axel Dold, Friedrich W. von Henke, Vincent Vialard, Wolfgang Goerigk A Mechanically Verified Compiling Specification for a Realistic Compiler

2003-01 Manfred Reichert, Stefanie Rinderle, Peter Dadam A Formal Framework for Workflow Type and Instance Changes Under Correctness Checks

2003-02 Stefanie Rinderle, Manfred Reichert, Peter Dadam Supporting Workflow Schema Evolution By Efficient Compliance Checks

2003-03 Christian Heinlein Safely Extending Procedure Types to Allow Nested Procedures as Values

2003-04 Stefanie Rinderle, Manfred Reichert, Peter Dadam On Dealing With Semantically Conflicting Business Process Changes.

2003-05 Christian Heinlein

Dynamic Class Methods in Java

2003-06 Christian Heinlein Vertical, Horizontal, and Behavioural Extensibility of Software Systems

2003-07 Christian Heinlein Safely Extending Procedure Types to Allow Nested Procedures as Values (Corrected Version)

2003-08 Changling Liu, Jörg Kaiser Survey of Mobile Ad Hoc Network Routing Protocols)

2004-01 Thom Frühwirth, Marc Meister (eds.) First Workshop on Constraint Handling Rules

2004-02 Christian Heinlein Concept and Implementation of C+++, an Extension of C++ to Support User-Defined Operator Symbols and Control Structures

2004-03 Susanne Biundo, Thom Frühwirth, Günther Palm(eds.) Poster Proceedings of the 27th Annual German Conference on Artificial Intelligence

2005-01 Armin Wolf, Thom Frühwirth, Marc Meister (eds.) 19th Workshop on (Constraint) Logic Programming

2005-02 Wolfgang Lindner (Hg.), Universität Ulm , Christopher Wolf (Hg.) KU Leuven 2. Krypto-Tag – Workshop über Kryptographie, Universität Ulm

2005-03 Walter Guttmann, Markus Maucher Constrained Ordering

2006-01 Stefan Sarstedt Model-Driven Development with ACTIVECHARTS, Tutorial

2006-02 Alexander Raschke, Ramin Tavakoli Kolagari Ein experimenteller Vergleich zwischen einer plan-getriebenen und einer leichtgewichtigen Entwicklungsmethode zur Spezifikation von eingebetteten Systemen

2006-03 Jens Kohlmeyer, Alexander Raschke, Ramin Tavakoli Kolagari Eine qualitative Untersuchung zur Produktlinien-Integration über Organisationsgrenzen hinweg

2006-04 Thorsten Liebig Reasoning with OWL - System Support and Insights –

2008-01 H.A. Kestler, J. Messner, A. Müller, R. Schuler On the complexity of intersecting multiple circles for graphical display

2008-02 Manfred Reichert, Peter Dadam, Martin Jurisch,l Ulrich Kreher, Kevin Göser, Markus Lauer

Architectural Design of Flexible Process Management Technology

2008-03 Frank Raiser Semi-Automatic Generation of CHR Solvers from Global Constraint Automata

2008-04 Ramin Tavakoli Kolagari, Alexander Raschke, Matthias Schneiderhan, Ian Alexander Entscheidungsdokumentation bei der Entwicklung innovativer Systeme für produktlinien-basierte Entwicklungsprozesse

2008-05 Markus Kalb, Claudia Dittrich, Peter Dadam

Support of Relationships Among Moving Objects on Networks

2008-06 Matthias Frank, Frank Kargl, Burkhard Stiller (Hg.) WMAN 2008 – KuVS Fachgespräch über Mobile Ad-hoc Netzwerke

2008-07 M. Maucher, U. Schöning, H.A. Kestler An empirical assessment of local and population based search methods with different degrees of pseudorandomness

2008-08 Henning Wunderlich Covers have structure

2008-09 Karl-Heinz Niggl, Henning Wunderlich Implicit characterization of FPTIME and NC revisited

2008-10 Henning Wunderlich On span-Pсс and related classes in structural communication complexity

2008-11 M. Maucher, U. Schöning, H.A. Kestler On the different notions of pseudorandomness

2008-12 Henning Wunderlich On Toda’s Theorem in structural communication complexity

2008-13 Manfred Reichert, Peter Dadam Realizing Adaptive Process-aware Information Systems with ADEPT2

2009-01 Peter Dadam, Manfred Reichert The ADEPT Project: A Decade of Research and Development for Robust and Fexible Process Support Challenges and Achievements

2009-02 Peter Dadam, Manfred Reichert, Stefanie Rinderle-Ma, Kevin Göser, Ulrich Kreher, Martin Jurisch Von ADEPT zur AristaFlow® BPM Suite – Eine Vision wird Realität “Correctness by Construction” und flexible, robuste Ausführung von Unternehmensprozessen

2009-03 Alena Hallerbach, Thomas Bauer, Manfred Reichert Correct Configuration of Process Variants in Provop

2009-04 Martin Bader

On Reversal and Transposition Medians

2009-05 Barbara Weber, Andreas Lanz, Manfred Reichert Time Patterns for Process-aware Information Systems: A Pattern-based Analysis

2009-06 Stefanie Rinderle-Ma, Manfred Reichert Adjustment Strategies for Non-Compliant Process Instances

2009-07 H.A. Kestler, B. Lausen, H. Binder H.-P. Klenk. F. Leisch, M. Schmid

Statistical Computing 2009 – Abstracts der 41. Arbeitstagung

2009-08 Ulrich Kreher, Manfred Reichert, Stefanie Rinderle-Ma, Peter Dadam Effiziente Repräsentation von Vorlagen- und Instanzdaten in Prozess-Management-Systemen

2009-09 Dammertz, Holger, Alexander Keller, Hendrik P.A. Lensch Progressive Point-Light-Based Global Illumination

2009-10 Dao Zhou, Christoph Müssel, Ludwig Lausser, Martin Hopfensitz, Michael Kühl, Hans A. Kestler Boolean networks for modeling and analysis of gene regulation

2009-11 J. Hanika, H.P.A. Lensch, A. Keller Two-Level Ray Tracing with Recordering for Highly Complex Scenes

2009-12 Stephan Buchwald, Thomas Bauer, Manfred Reichert Durchgängige Modellierung von Geschäftsprozessen durch Einführung eines

Abbildungsmodells: Ansätze, Konzepte, Notationen

2010-01 Hariolf Betz, Frank Raiser, Thom Frühwirth A Complete and Terminating Execution Model for Constraint Handling Rules

2010-02 Ulrich Kreher, Manfred Reichert

Speichereffiziente Repräsentation instanzspezifischer Änderungen in Prozess-Management-Systemen

2010-03 Patrick Frey

Case Study: Engine Control Application 2010-04 Matthias Lohrmann und Manfred Reichert

Basic Considerations on Business Process Quality 2010-05 HA Kestler, H Binder, B Lausen, H-P Klenk, M Schmid, F Leisch (eds):

Statistical Computing 2010 - Abstracts der 42. Arbeitstagung 2010-06 Vera Künzle, Barbara Weber, Manfred Reichert

Object-aware Business Processes: Properties, Requirements, Existing Approaches

2011-01 Stephan Buchwald, Thomas Bauer, Manfred Reichert Flexibilisierung Service-orientierter Architekturen

2011-02 Johannes Hanika, Holger Dammertz, Hendrik Lensch Edge-Optimized À-Trous Wavelets for Local Contrast Enhancement with Robust Denoising

2011-03 Stefanie Kaiser, Manfred Reichert

Datenflussvarianten in Prozessmodellen: Szenarien, Herausforderungen, Ansätze 2011-04 Hans A. Kestler, Harald Binder, Matthias Schmid, Friedrich Leisch, Johann M. Kraus

(eds): Statistical Computing 2011 - Abstracts der 43. Arbeitstagung

2011-05 Vera Künzle, Manfred Reichert

PHILharmonicFlows: Research and Design Methodology 2011-06 David Knuplesch, Manfred Reichert

Ensuring Business Process Compliance Along the Process Life Cycle 2011-07 Marcel Dausend

Towards a UML Profile on Formal Semantics for Modeling Multimodal Interactive Systems

2011-08 Dominik Gessenharter

Model-Driven Software Development with ACTIVECHARTS - A Case Study 2012-01 Andreas Steigmiller, Thorsten Liebig, Birte Glimm

Extended Caching, Backjumping and Merging for Expressive Description Logics 2012-02 Hans A. Kestler, Harald Binder, Matthias Schmid, Johann M. Kraus (eds):

Statistical Computing 2012 - Abstracts der 44. Arbeitstagung 2012-03 Felix Schüssel, Frank Honold, Michael Weber

Influencing Factors on Multimodal Interaction at Selection Tasks 2012-04 Jens Kolb, Paul Hübner, Manfred Reichert

Model-Driven User Interface Generation and Adaption in Process-Aware Information Systems

2012-05 Matthias Lohrmann, Manfred Reichert

Formalizing Concepts for Efficacy-aware Business Process Modeling 2012-06 David Knuplesch, Rüdiger Pryss, Manfred Reichert

A Formal Framework for Data-Aware Process Interaction Models 2012-07 Clara Ayora, Victoria Torres, Barbara Weber, Manfred Reichert, Vicente Pelechano

Dealing with Variability in Process-Aware Information Systems: Language Requirements, Features, and Existing Proposals

2013-01 Frank Kargl Abstract Proceedings of the 7th Workshop on Wireless and Mobile Ad- Hoc Networks (WMAN 2013)

2013-02 Andreas Lanz, Manfred Reichert, Barbara Weber

A Formal Semantics of Time Patterns for Process-aware Information Systems 2013-03 Matthias Lohrmann, Manfred Reichert

Demonstrating the Effectiveness of Process Improvement Patterns with Mining Results

2013-04 Semra Catalkaya, David Knuplesch, Manfred Reichert

Bringing More Semantics to XOR-Split Gateways in Business Process Models Based on Decision Rules

2013-05 David Knuplesch, Manfred Reichert, Linh Thao Ly, Akhil Kumar,

Stefanie Rinderle-Ma On the Formal Semantics of the Extended Compliance Rule Graph

2013-06 Andreas Steigmiller, Birte Glimm, Thorsten Liebig

Nominal Schema Absorption 2013-07 Hans A. Kestler, Matthias Schmid, Florian Schmid, Dr. Markus Maucher, Johann M. Kraus (eds)

Statistical Computing 2013 - Abstracts der 45. Arbeitstagung 2013-08 Daniel Ott, Dr. Alexander Raschke Evaluating Benefits of Requirement Categorization in Natural Language Specifications for Review Improvements 2013-09 Philip Geiger, Rüdiger Pryss, Marc Schickler, Manfred Reichert

Engineering an Advanced Location-Based Augmented Reality Engine for Smart Mobile Devices

2014-01 Andreas Lanz, Manfred Reichert

Analyzing the Impact of Process Change Operations on Time-Aware Processes 2014-02 Andreas Steigmiller, Birte Glimm, and Thorsten Liebig

Coupling Tableau Algorithms for the DL SROIQ with Completion-based Saturation Procedures

2014-03 Thomas Geier, Felix Richter, Susanne Biundo

Conditioned Belief Propagation Revisited: Extended Version 2014-04 Hans A. Kestler, Matthias Schmid, Ludwig Lausser, Johann M. Kraus (eds)

Statistical Computing 2014 - Abstracts der 46. Arbeitstagung 2014-05 Andreas Lanz, Roberto Posenato, Carlo Combi, Manfred Reichert

Simple Temporal Networks with Partially Shrinkable Uncertainty (Extended Version) 2014-06 David Knuplesch, Manfred Reichert

An Operational Semantics for the Extended Compliance Rule Graph Language

Ulmer Informatik-Berichte

ISSN 0939-5091

Herausgeber:

Universität Ulm

Fakultät für Ingenieurwissenschaften und Informatik

89069 Ulm

An Operational Semantics for the Extended Compliance Rule ... · An Operational Semantics for the...

Documents

Transcript of An Operational Semantics for the Extended Compliance Rule ... · An Operational Semantics for the...