This document discusses using model transformations to back-annotate simulation traces onto business process models. It presents the challenges of mapping low-level simulation traces to higher-level process models due to information loss and granularity mismatches during modeling abstraction. The authors propose a change-driven transformation approach where the transformation is executed incrementally based on notifications of changes to the simulation model, rather than requiring manual initialization. This approach aims to better handle complex mapping issues that can arise, such as many-to-one and one-to-many mappings between model changes.

1. Back-annotation of Simulation Traces
with Change-driven Model Transformations
Ábel Hegedüs, Gábor Bergmann, István Ráth, Dániel Varró
(hegedusa@mit.bme.hu)
Budapest University of Technology and Economics
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics
Software Engineering and Formal Methods 2010, Pisa, Italy

2. Motivation - BPEL
Receive request
Event: Cancel
Calculate Rating
Rollback changes
Accept?
Yes No Throw Error
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Will the business
process assure this?
Send reply

3. Outline of the talk
 Motivation
 Introduction – BPEL verification
 Back-annotation problem
 Transformation-driven Back-annotation
 Summary
 Future Work

4. Introduction
 Quality of processes checked design-time to avoid
malfunctioning due to design errors
o using formal methods
 Processes can not be checked directly
o formal semantics not defined
o model checking support missing
 Transformation to some formal model is required
o Petri Nets, Process algebra, Transition systems, etc.

5. Verification of BPEL
Business
Requirement
Process

6. Verification of BPEL
Receive request
Business
Requirement
Process

7. Verification of BPEL
Every received
request must result
in a reply!
Business
Requirement
Process

8. Verification of BPEL
Business
Requirement
Process
Transform
Model

9. Verification of BPEL
Business
Requirement
Process
Transform
Model
Formal model
(Petri Nets)

10. Verification of BPEL
Business
Requirement
Process
Transform
Model
Formal model Token Transition Place
(Petri Nets)

11. Verification of BPEL
Business
Requirement
Process
Transform Formalize
Model Theorem

12. Verification of BPEL
Business
Requirement
Process
G [ Request =>
Transform Formalize F (Reply) ]
Model Theorem
Linear Temporal
Logic formula

13. Verification of BPEL
Business
Requirement
Process
Transform Formalize
Model Theorem
Check
Model checker

14. Verification of BPEL
Business
Requirement
Process
Transform Formalize
Model Theorem
Check
Model checker
Result

15. Verification of BPEL
Business
Requirement
Process
Transform Formalize
Model Theorem
Check
Model checker
Result
Proved /
Counter-example

16. Counter-example

17. Counter-example

18. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model

19. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model

20. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model
Transition firing

21. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model
Transition firing
Model change

22. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model
 How can we use these textual results?
o Model changes of dynamic properties – state change
 Convert textual trace automatically into model
o Integration of analysis and modeling tools

23. Processing results
 Counter-example = Execution Trace 100s of steps,
Often several
multiple changes/step
o Sequence of steps representing changes of the model
 How can we use these textual results?
o Model changes of dynamic properties – state change
 Convert textual trace automatically into model
o Integration of analysis and modeling tools

24. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model
 How can we use these textual results?
o Model changes of dynamic properties – state change
 Convert textual trace automatically into model
o Integration of analysis and modeling tools
PNFiring
trans
Transition

25. Processing results
 Counter-example = Execution Trace
o Sequence of steps representing changes of the model
 How can we use these textual results?
o Model changes of dynamic properties – state change
 Convert textual trace automatically into model
o Integration of analysis and modeling tools
Bind output of simulator/model
checker to the modeling
framework using importers

26. Business Process Execution Traces
 Missing dynamic semantics
 Describe dynamic state of a process
o Activity / Variable states
o Events, triggers, variable manipulations
 Semantics definition driven by structural modeling
approach
 Dynamic and trace metamodels for BPEL

27. Business Process Execution Traces
 Missing dynamic semantics BPEL Activity
• Not Startable
 Describe dynamic state of a process • Startable
• Running
o Activity / Variable states • Finished
• Interrupted
o Events, triggers, variable manipulations
 Semantics definition driven by structural modeling
approach
 Dynamic and trace metamodels for BPEL

28. Business Process Execution Traces
 Missing dynamic semantics BPEL Activity Startable
BPEL Activity Runs
 Describe dynamic state of a process Activity Executed
BPEL
o Activity / Variable states
o Events, triggers, variable manipulations
 Semantics definition driven by structural modeling
approach
 Dynamic and trace metamodels for BPEL

29. Business Process Execution Traces
 Missing dynamic semantics
Static
Metamodel
 Describe dynamic state of a process
o Activity / Variable states
<<uses>> <<uses>>
o Events, triggers, variable manipulations
Trace Dynamic
Metamodel Metamodel
 Semantics definition driven by structural modeling
<<uses>>
approach
 Dynamic and trace metamodels for BPEL

30. Abstraction gap
 Lost information
o Decision conditions
o Variable values, parts
o Timing (event ordering)
 Granularity mismatch
o NOT 1-to-1 mapping
o Non-trivial mapping problems (interleaving)
 Traceability requirements
o PN elements grouped into subnets for simplifying the
traceability model

31. Abstraction gap
 Lost information
Delete Tokens
o Decision conditions
Add Tokens
o Variable values, parts
o Timing (event ordering)
 Granularity mismatch
o NOT 1-to-1 mapping
o Non-trivial mapping problems (interleaving)
 Traceability requirements
o PN elements grouped into subnets for simplifying the
traceability model

32. Abstraction gap
 Lost information Select Transition
Delete Tokens
o Decision conditions Fire Transition
Add Tokens
o Variable values, parts Select Transition
o Timing (event ordering) Fire Transition
 Granularity mismatch
o NOT 1-to-1 mapping
o Non-trivial mapping problems (interleaving)
 Traceability requirements
o PN elements grouped into subnets for simplifying the
traceability model

33. Abstraction gap
 Lost information Select Transition BPEL Activity
Startable
Delete Tokens
o Decision conditions Fire Transition
BPEL Activity
Add Tokens
Runs
o Variable values, parts Select Transition
BPEL Activity
o Timing (event ordering) Fire Transition Executed
 Granularity mismatch
o NOT 1-to-1 mapping
o Non-trivial mapping problems (interleaving)
 Traceability requirements
o PN elements grouped into subnets for simplifying the
traceability model

34. Abstraction gap
 Lost information
o Decision conditions
initial
o Variable values, parts
stop
o Timing (event ordering)stopped
Petri Net
B2PN
BPEL
subnet Element
 Granularity mismatch failed Traceability link
o NOT 1-to-1 mapping final
o Non-trivial mapping problems (interleaving)
 Traceability requirements
o PN elements grouped into subnets for simplifying the
traceability model

35. Trace mapping – simple changes
1. Identification of BPEL process elements which
are affected by the PN change
o Static traceability model generated during the
structural transformation
2. Decide BPEL change type represented by the PN
change
o Inspect the structure of the static model
• Graph patterns defined for matching to structure parts
3. Persist BPEL change into the hierarchy of the
trace model
o Use dynamic traceability model to record BPEL-PN
trace correspondence

36. Trace mapping – simple changes
1. Identification of BPEL process elements which
are affected by the PN change
o Static traceability model generated during the
structural transformation
2. Decide BPEL change type represented by the PN
Tr: Transition
change trans trans
PNF: PNFiring
o Inspect the structure of the static model
: Subnet B2PN
• Graph patterns defined forBA: BPEL Activity
matching to structure parts
3. Persist BPEL change into the hierarchy of the
trace model
o Use dynamic traceability model to record BPEL-PN
trace correspondence

37. Trace mapping – simple changes
1. Identification of BPEL process elements which
are affected by the PN change
o Static traceability model generated during the
structural transformation
2. Decide BPEL change type represented by the PN
change
o Inspect the structure of the static model
• Graph patterns defined for matching to structure parts
3. Persist BPEL change into the hierarchy of the
trace model
o Use dynamic traceability model to record BPEL-PN
trace correspondence

38. Trace mapping – simple changes
initial
1. Identification of BPEL process elements which
are affected by the PNstart
stop change
o Staticstopped
traceability model generated during the
structural transformation
failed
2. Decide BPEL change type represented by the PN
change final
o Inspect the structure of the static model
• Graph patterns defined for matching to structure parts
3. Persist BPEL change into the hierarchy of the
trace model
o Use dynamic traceability model to record BPEL-PN
trace correspondence

39. Trace mapping – simple changes
1. Identification of BPEL process elements which
are affected by the PN change
o Static traceability model generated during the
structural transformation
2. Decide BPEL change type represented by the PN
change
o Inspect the structure of the static model
• Graph patterns defined for matching to structure parts
3. Persist BPEL change into the hierarchy of the
trace model
o Use dynamic traceability model to record BPEL-PN
trace correspondence

40. Trace mapping – simple changes
1. Identification of BPEL process elements which
BPEL Trace
are affected by the PN change
next
o BPEL steptraceability model generated during the
Static BPEL step
structural transformation
Activity Activity Activity
2. Decide BPEL change type represented by the PN
Startable
next
Runs Executed
next
change
Change Change
o Inspect the structure of the static model
State State
next
• Graph patterns defined for matching to structure parts
3. Persist BPEL change into the hierarchy of the
trace model
o Use dynamic traceability model to record BPEL-PN
trace correspondence

41. initial initial
stop stop
stopped inner stopped inner
trans trans
failed failed
final final

42. Trace mapping – complex changes
 Many-to-one:
o Multiple PN changes one BPEL change
o Transition firing represents internal behavior of a BPEL
activity
o Identify whether a PN change should be mapped
 One-to-many
o One PN change multiple BPEL changes
o Persisted as substeps of a macro step in the trace
 Interleaving
o Parallel execution, relevant changes have to be selected
o Petri Net subnets separate transitions

43. Trace mapping – complex changes
 Many-to-one:
o Multiple PN changes one BPEL change
o Transition firing represents internal behavior of a BPEL
activity
o Identify whether a PN change should be mapped
initial
 One-to-many
o One PN change multiple BPEL changes
stop
o Persisted as substeps of a macro step in the trace
stopped inner
 Interleaving trans
failed
o Parallel execution, relevant changes have to be selected
o Petri Net subnets separate transitions
final

44. Trace mapping – complex changes
 Many-to-one:
o Multiple PN changes one BPEL change
o Transition firing represents internal behavior of a BPEL
activity
o Identify whether a PN change should be mapped
 One-to-many
o One PN change multiple BPEL changes
o Persisted as substeps of a macro step in the trace
 Interleaving
o Parallel execution, relevant changes have to be selected
o Petri Net subnets separate transitions

45. Change-Driven Model Transformations
 Transformation design pattern
o Execution driven by changes in the model
• Simulation trace – Sequence of model changes
o Handles external models
• Simulator / model checker with only notification of changes
• Process editor with only manipulation interface
MPN TR MBPEL
map
CHMPN CHMBPEL
IF
MPN’ TR MBPEL’

46. Change-Driven Model Transformations
 Transformation design pattern
o Execution driven by changes in the model
• Simulation trace – Sequence of model changes
o Handles external models
• Simulator / model checker with only notification of changes
Record model
• Process editor with only manipulation interface
changes
MPN TR MBPEL
map
CHMPN CHMBPEL
IF
MPN’ TR MBPEL’

47. Change-Driven Model Transformations
 Transformation design pattern
o Execution driven by changes in the model
• Simulation trace – Sequence of model changes
o Handles external models
• Simulator / model checker with only notification of changes
Traceability model
• Process editor with only manipulation interface
MPN TR MBPEL
map
CHMPN CHMBPEL
IF
MPN’ TR MBPEL’

48. Change-Driven Model Transformations
 Transformation design pattern
o Execution driven by changes in the model
• Simulation trace – Sequence of model changes
o Handles external models
• Simulator / model checker with only notification of changes
Execute back-
• Process editor with only manipulation interface
annotation
MPN TR MBPEL
map
CHMPN CHMBPEL
IF
MPN’ TR MBPEL’

49. Change-Driven Model Transformations
 Transformation design pattern
o Execution driven by changes in the model
• Simulation trace – Sequence of model changes
o Handles external models
• Simulator / model checker with only notification of changes
• Process editor with only manipulation interface
Apply
MPN TR MBPEL changes
map
CHMPN CHMBPEL
IF
MPN’ TR MBPEL’

50. Back-annotation with CDT
 Change history and trace metamodels
o Low-level model manipulations are grouped to form
micro and macro steps
 Mapping issues easier to handle
o Rules trigger only when appropriate changes occur in
the model
o Transformation is executed when changes happen,
instead of manual initialization

51. Back-annotation with CDT
 Change history and trace metamodels
o Low-level model manipulations are grouped to form
micro and macro steps
 Mapping issues easier to handle
o Rules trigger only when appropriate changes occur in
the model
o Transformation is executed when changes happen,
Step 1 Appear
instead of manual initialization PNF: PNFiring
Tr: Transition trans

52. Back-annotation with CDT
 Change history and trace metamodels
o Low-level model manipulations are grouped to form
micro and macro steps
 Mapping issues easier to handle
o Rules trigger only when appropriate changes occur in
the model
o Transformation is executed when changes happen,
Step 1
2 Appear
instead of manual initialization PNF: PNFiring
Tr: Transition trans
trans
trans
B2PN : Subnet
Match
BA: BPEL Activity

53. Back-annotation with CDT
 Change history and trace metamodels
o Low-level model manipulations are grouped to form
micro and macro steps
 Mapping issues easier to handle
o Rules trigger only when appropriate changes occur in
the model
o Transformation is executed when changes happen,
3
Step 1
2 Appear PNF: PNFiring
instead of manual initialization PNF: PNFiring
Tr: Transition
Tr: Transition trans
trans
trans
trans
trans Create
B2PN
B2PN ::Subnet
Subnet
Match
activity
BA: BPEL Activity
BA: BPEL Activity BAR: BPELActivityRuns

54. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation

55. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
BPEL Trace
next
BPEL step BPEL step
Activity Activity Activity
Startable Runs Executed
next next
Change Change
State State
next

56. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation

57. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

58. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

59. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

60. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

61. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

62. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

63. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

64. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality

65. Presentation of BPEL traces
 Dynamic behavior requires dynamic presentation
 Overlay dynamic information on static view
o Graphical BPEL editor
o Use colors/labels to display current state
o Provide intuitive navigation in the trace
 Integrate with analysis functionality
Hidden formal methods

66. Motivating scenario (cont.)
Accept?
Yes No
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

67. Motivating scenario (cont.)
Receive request
Accept?
Yes No
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

68. Motivating scenario (cont.)
Receive request
Calculate Rating
Accept?
Yes No
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

69. Motivating scenario (cont.)
Receive request
Event: Cancel
Calculate Rating
Accept?
Yes No
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

70. Motivating scenario (cont.)
Receive request
Event: Cancel
Calculate Rating
Rollback changes
Accept?
Yes No
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

71. Motivating scenario (cont.)
Receive request
Event: Cancel
Calculate Rating
Rollback changes
Accept?
Yes No Throw Error
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

72. Motivating scenario (cont.)
Receive request
Event: Cancel
Calculate Rating
Rollback changes
Accept?
Yes No Throw Error
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

73. Motivating scenario (cont.)
Receive request
Returns with a web-
service error
Event: Cancel
Calculate Rating
Rollback changes
Accept?
Yes No Throw Error
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Send reply

74. Motivating scenario (cont.)
Receive request
Returns with a web-
service error
Event: Cancel
Calculate Rating
Rollback changes
Accept?
Yes No Throw Error
Send offer Send rejection
Requirement:
Receive answer
Receive Every received request
update request must result in a reply!
No Yes
Update?
Not executed =
Send reply No reply

75. Outlook: Scaling to large traces
 Great part of the trace is irrelevant to the error
 Process too complex for reasonable model
checking resources (time, memory)
o Decompose the process into smaller, interacting
processes
o Analysis of cooperating BPEL processes through
abstraction of behavior

76. Summary
 Reusable dynamic back-annotation approach:
o With generic modeling framework for dynamic traces
o Joint dynamic traceability metamodels
o Transformation library
• using the CDT design pattern
 Motivating scenarios:
o End-to-end verification approaches
o BPEL to PN and Back
o BPEL to SAL and Back (Tool demo)

77. Future work
 Automatic generation of trace persistence rules
from simulation rules
 On-the-fly back-annotation
 Derive mapping rules from forward
transformation
 ...
 Thank you! Questions?
 Come see our Tool Demo in Room 28!