Validation of User Intentions in Process Models

Web Science & Technologies
University of Koblenz ▪ Landau, Germany

Validation of User Intentions in
Process Models

Gerd Gröner, Mohsen Asadi, Bardia Mohabatti, Dragan Gasevic,
Fernando Silva Parreiras and Marko Boskovic

What is the goal of a particular process?

Goal that should be achieved
 several goals
 subgoals
 dependencies between
goals
?

Process Model:
➔
Operational representation
of activities to achieve a
certain goal

WeST Gerd Gröner CAiSE 2012
groener@uni-koblenz.de 2

Example: Traveling to Gdansk for CAiSE

quick
journey

✔

comfortable
journey

↯ ✔

cheap
late arrival
journey

goals and dependencies activities and dependencies
among goals between them

➔
Dependencies / relationships might be contradicting!


Problems and Questions

How are goals represented?
Which kinds of
quick
dependencies
journey
are covered in a
process model?
comfortable
journey

late arrival
cheap
journey

How is the influence of a
mapped goal on an activity? How to map / align between goals and
activities?
(What is the meaning?)


Idea

1. Extract and represent relationships of both models

logical view:
quick ➔
similar
journey
relationships
between
elements in both
comfortable
journey
models

late arrival
cheap
journey

2. Explicitly represent mappings between goals and activities

3. Classify inconsistencies between mapped goals and activities

4. Formalization for validation and recognition of inconsistencies


Outline

1. Modeling dimensions
i. Goal models
ii. Process models
2. Realization inconsistencies
3. Modeling principles
4. Validation
5. Discussion and conclusion


Requirements representation
Requirements: goals, functions and constraints of a system

→ Representation: means for understanding user intentions and
how they are related to each other

G5 G
OR OR
Goal models: +
•

Graph with G1 G4
AND
 intentional elements (hard AND

goals, soft goals, tasks) G2 G3
 links (contributions)
 decompositions (AND, IOR,
XOR)
➔
requirements of a
system-to-be


Intentions in Process Models

Requirement perspective: Process model:
• Goals (user intentions) • Control flow perspective
• Relationships (constraints, - activities
dependencies) - ordering through different constructors

preferred
payment
AND AND

no additional 30 days term
fee of credit

mapping

≈
realization of a goal


… Problem

Requirement perspective: Control flow perspective:

preferred
payment

AND AND

no additional 30 days term
fee of credit

mapping

relations not necessarily coincide,
they might even be contradicting


Outline

i. Goal models
ii. Process models
4. Validation


Realization Inconsistencies

Intentional relations (IR) Control flow relations /
over intentional elements workflow relations WF over
G1, …,Gm ∈ G activities
A1, …,An ∈ A

 WF over A1, …,An ∈ A and IR over G1, …,Gm ∈ G, with target
goal G ∈ G and activities A1, …,An are realizations of G1, …,Gm
 A strong inconsistency between WF and IR occurs if there
is no execution combination of activities that leads to the
fulfillment of the target goal G.
 A potential inconsistency between WF and IR occurs if
some execution combinations of activities lead to the
fulfillment of G and some do not lead to the fulfillment of G.


Realization Inconsistencies – Example
Strong inconsistency:
preferred
payment

AND AND

no additional
30 days term fee
of credit

Potential inconsistency:

preferred
payment

AND AND

30 days term
little of credit
payment
effort


Correspondences

Intentional relations
Control flow relations AND IOR XOR ● -
●
+
AND-AND parallel split - synchronization ✔ ✔ ↯ ✔ ↯
AND-OR parallel split – multi merge ✔ ✔ ↯ ✔ ↯
AND-Disc parallel split – discriminator ✔ ✔ ↯ ✔ ↯
AND-XOR parallel split – simple merge ✔ ✔ ↯ ✔ ↯
IOR-IOR multi choice - multi merge ± ✔ ± ± ±
IOR-Disc multi choice - discriminator ± ✔ ± ± ±
IOR-XOR multi choice – simple merge ± ✔ ± ± ±
XOR-XOR exclusive – simple merge ↯ ✔ ✔ ± ✔
Sequence ✔ ✔ ↯ ✔ ↯

↯ strong inconsistency, ± potential inconsistency,
✔ no inconsistency

Outline

i. Goal models
ii. User intentions for process models
4. Validation


Description Logics (DLs)
(1) DL Knowledge base (KB)

Concepts C C(x)
Property (role) R R(x,y)
Subclass C⊑D ∀ x (C(x) → D(x))
Negation ¬C ¬ C(x)

Union C⊔D C(x) ∨ D(x)
Intersection C⊓D C(x) ∧ D(x)
Existential
Quantification ∃ P.C ∃ y (P(x,y)∧C(y))

(2) Inference service:

Subsumption: C⊑D?
if KB ⊨ C ⊑ D


Towards a common knowledge base

(atomic) concepts:
- goals
- activities A1
G1
A2
G2
A3
G3
complex concept expressions
- intentional relations of Gi
- control flow relations of Aj

connect concepts (atomic concepts)
of mapped entities


Complex concept expressions – for IR
Preferred
payment (PP) RelCT ≡ ∃ relates . NF ⊓
AND
AND
∃ relates. CT
no add. 30 credit
fee (NF) term (CT)

DTC

XOR XOR RelCRC ≡ ( ∃ relates . CRC ⊔
∃ relates . CCR ) ⊓
CCR CRC
¬ (∃ relates . CTC ⊓
∃ relates . CCT)
Minimize
Risk (MR)

+ RelAP ≡ ( ∃ relates . MR )
•
Apply
Process (AP)


Complex concept expressions – for WF

RelFD ≡ ∃ relates . FD ⊓
∃ relates. AD

RelCP ≡ ( ∃ relates . CP ⊔
∃ relates . CCP ) ⊓
¬ (∃ relates . CP ⊓
∃ relates . CCP)


Outline

i. Goal models
ii. User intentions for process models
4. Validation


How to detect inconsistencies?

G1 A1

G2 A2
A3
G4
G3
atomic WF by
IR by concept complex
complex equivalence concept
concept

➔
complex concept expressions: logical formulas

➔
comparison of concept expressions


Validation – slightly abstracted
Logical point of view:

G1 M A1

RelG RelA
Mi

Validation principle:
• compare RelG and RelA if there is a mapping between G and A

RelG RelA
?
- coincide / equivalent ?
- contradicting?
- no influence?
• both models are correct on their own
• only mapped elements need to be considered

Relation comparison

 Strong inconsistency
 ''...no execution combination fulfills the target goal …''
➔ KB: no common instance: RelG ⊓ RelA ⊑ ⊥
 Potential inconsistency
 ''… there are some execution combinations that do not lead to the
fulfillment of G...''
➔
an execution combination not necessarily fulfills G
➔ KB: entailment RelA ⊑ RelG does not hold: ¬(RelA ⊑ RelG)

Otherwise

Relations coincide


Relation comparison – concept level

RelG RelA
?
compare RelG and RelA

✔ RelA ⊑ RelG ± ¬(RelA ⊑ RelG) ↯ RelG ⊓ RelA ⊑ ⊥
✔ relations ± depends on ↯ relations contradict
coincide particular execution

➔
detect inconsistency between both models
➔
identify the source (i.e., activity and goal) of an inconsistency


Resolve inconsistency

RelG RelA

inconsistency detected

 change intentional relations
 change control flow relations
 change mapping
➔
individual assessment


Conclusion
2 views /
perspectives
goals / intentions
activities and
their execution
DTC
XOR mapping
XOR

CCR CRC (realization
of goals)

intentional control flow
relationships relationships
➔
Problem: goals and activities depend on other goals and activities
➔
Mapping imposes to an activity also relationship from its corresponding goal


Conclusion (2)
Approach
1) Specifying realization inconsistencies
2) Formalizing relationships of both models
3) Detection of inconsistencies of mapped goals and activities

Contribution of DLs
 Detection of inconsistencies
 Potential inconsistency
 Strong inconsistency
 Pinpointing of sources for inconsistencies

Future Work:
 focus on behavioral constraints
 (semi-) automatic derivation of process models

Thank you!


Validation of User Intentions in Process Models

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (19)

Similar to Validation of User Intentions in Process Models

Similar to Validation of User Intentions in Process Models (20)

Recently uploaded

Recently uploaded (20)

Validation of User Intentions in Process Models