Upload
others
View
16
Download
0
Embed Size (px)
Citation preview
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
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.
4 David Knuplesch and Manfred Reichert
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].
An Operational Semantics for the eCRG Language 5
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
6 David Knuplesch and Manfred Reichert
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
An Operational Semantics for the eCRG Language 7
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.
8 David Knuplesch and Manfred Reichert
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
An Operational Semantics for the eCRG Language 9
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
10 David Knuplesch and Manfred Reichert
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.
An Operational Semantics for the eCRG Language 11
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
12 David Knuplesch and Manfred Reichert
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
An Operational Semantics for the eCRG Language 13
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
14 David Knuplesch and Manfred Reichert
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
An Operational Semantics for the eCRG Language 15
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.
16 David Knuplesch and Manfred Reichert
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
77 2/7/2013 15:43 start 234 SolvencyCheck (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 ().
An Operational Semantics for the eCRG Language 17
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
propagation of effects
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.
18 David Knuplesch and Manfred Reichert
Agent
rating
≠
Request
Approval
-
- – -
Approval
-
- – -
Solvency C.
-
- – -
1/7/2013 15:27
a3
customer
amount
propagation of effects
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
77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)
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
An Operational Semantics for the eCRG Language 19
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,
20 David Knuplesch and Manfred Reichert
.
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
An Operational Semantics for the eCRG Language 21
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
propagation of effects
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
77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)
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.
22 David Knuplesch and Manfred Reichert
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
propagation of effects
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 ε
An Operational Semantics for the eCRG Language 23
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
24 David Knuplesch and Manfred Reichert
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))
An Operational Semantics for the eCRG Language 25
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).
26 David Knuplesch and Manfred Reichert
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
An Operational Semantics for the eCRG Language 27
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(φ(α)) =)
28 David Knuplesch and Manfred Reichert
.
– 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.
An Operational Semantics for the eCRG Language 29
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].
30 David Knuplesch and Manfred Reichert
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
An Operational Semantics for the eCRG Language 31
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