Information Technology Reference
In-Depth Information
Ta b l e 2 .
Excerpt of the extracted traces
σ
1
:
start ∧ ei ∧ ri, edd ∧ ep ∧ ri, ra ∧ ep ∧ rh, bl ∧ ep ∧ rh, od ∧ ep ∧ rh, end ∧ ep ∧ rh
σ
2
:
start ∧ ei ∧ ri, edd ∧ ep ∧ ri, ra ∧ ep ∧ rh, od ∧ ep ∧ rh, end ∧ ep ∧ rh
···
σ
37
:
start ∧ ei ∧ ri, bl ∧ ei ∧ ri, edd ∧ ep ∧ ri, ra ∧ ep ∧ rh, od ∧ ep ∧ rh, end ∧ ep ∧ rh
···
σ
42
:
start ∧ ei ∧ ri, bl ∧ ei ∧ ri, ra ∧ rl ∧ ei, og ∧ rl ∧ ei, edd ∧ ep ∧ rl, end ∧ ep ∧ rl
Note that it is possible to extract traces that take repetition of activities into account
by omitting the
once
constraint in the domain knowledge. Still, for our purpose, this
does not seem to be appropriate. Compliance rules rarely forbid the repetition of activity
execution, so that modeling all potential loops blurs up the structure of a generated
process template. As this hinders discussions between business and compliance experts,
we neglect potential repetition for our synthesis approach.
Example.
Some of the traces extracted from the pseudomodel of our running example
are illustrated in Table 2. Here, the states of a trace are characterized by the conjunction
of propositions that hold true in the respective state.
3.4
Analysis of Extracted Traces
As stated earlier, the goal of synthesizing a process template out of compliance rules
is to support experts in getting a better understanding of the compliance aspects and to
discover missing or under-specified requirements. However, it is possible to detect such
under-specification by analysis of extracted traces before proceeding to synthesizing a
process template. Yet, not every semantical error in the specification can be detected,
so that a human expert has to validate the synthesized process template. We address
the issue of under-specified LTL specification by correctness criteria for the extracted
traces.
Let
be a set of traces derived from a pseudomodel, cf., Section 3.3. We leverage
the information whether an action
a
P
∈
A
is optional for completing the process.
Definition 1 (Optional Actions).
Given a set of actions
A
and a set of traces
P
,the
set
A
O
of optional actions is defined as
A
O
=
{
a
∈
A
:
∃
σ
∈P
.a
∈
σ
}
.
We argue that correctness of a specification where some activity is optional implies the
existence of a specific data condition under which the optional activity is executed. For
the traces in Table 2, for instance,
og
and
od
are optional activities. The condition under
which
og
executes is
, i.e., the risk object assumes
the state 'low'. Action
og
is executed independently from the state of the due diligence
evaluation object. For action
od
the condition is
(
rl
∧
ef
)
∨
(
rl
∧
ep
)
∨
(
rl
∧
ei
)
(
rh
∧
ef
)
∨
(
rh
∧
ep
)
∨
(
rh
∧
ei
)
, i.e., the
risk is 'high'. In contrast, action
bl
is executed under the condition
(
ei
∧
ri
)
∨
(
ei
∧
rh
)
∨
(
. Hence,
none of the objects influences the decision of executing
bl
,since
bl
appears with
all
combinations of data values. Yet,
bl
is optional. This indicates an under-specified LTL
specification as conditions for executing optional activities are not stated explicitly.
ei
∧
rl
)
∨
(
ef
∧
ri
)
∨
(
ef
∧
rh
)
∨
(
ef
∧
rl
)
∨
(
ep
∧
rh
)
∨
(
ep
∧
rl
)
∨
(
ep
∧
ri
)
