back-annotation of simulation traces with change-driven model transformations
Post on 27-Jun-2015
174 Views
Preview:
DESCRIPTION
TRANSCRIPT
Budapest University of Technology and Economics Software Engineering and Formal Methods 2010, Pisa, Italy
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
Motivation - BPEL
Requirement: Every received request must result in a reply! Will the business process assure this?
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Rollback changes
Throw Error
Event: Cancel
Yes No
Yes No
Outline of the talk
Motivation
Introduction – BPEL verification
Back-annotation problem
Transformation-driven Back-annotation
Summary
Future Work
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.
Business Process
Requirement
Verification of BPEL
Business Process
Requirement
Verification of BPEL
Receive request
Business Process
Requirement
Verification of BPEL Every received request must result in a reply!
Business Process
Requirement
Verification of BPEL
Model
Transform
Business Process
Requirement
Verification of BPEL
Model
Transform
Formal model (Petri Nets)
Business Process
Requirement
Verification of BPEL
Model
Transform
Formal model (Petri Nets)
Transition Place Token
Business Process
Requirement
Verification of BPEL
Model Theorem
Formalize Transform
Business Process
Requirement
Verification of BPEL
Model Theorem
Formalize Transform
Linear Temporal Logic formula
G [ Request => F (Reply) ]
Business Process
Requirement
Verification of BPEL
Model Theorem
Model checker
Formalize Transform
Check
Business Process
Requirement
Verification of BPEL
Model Theorem
Model checker
Formalize Transform
Result
Check
Business Process
Requirement
Verification of BPEL
Model Theorem
Model checker
Formalize Transform
Result
Proved / Counter-example
Check
Counter-example
Counter-example
Processing results
Counter-example = Execution Trace
o Sequence of steps representing changes of the model
Processing results
Counter-example = Execution Trace
o Sequence of steps representing changes of the model
Processing results
Counter-example = Execution Trace
o Sequence of steps representing changes of the model
Transition firing
Processing results
Counter-example = Execution Trace
o Sequence of steps representing changes of the model
Transition firing
Model change
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
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
Often several 100s of steps, multiple changes/step
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
Transition
PNFiring
trans
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
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
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
BPEL Activity • Not Startable • Startable • Running • Finished • Interrupted
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
BPEL Activity Runs
BPEL Activity Executed
BPEL Activity Startable
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
Static Metamodel
Trace Metamodel
Dynamic Metamodel
<<uses>>
<<uses>>
<<uses>>
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
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
Add Tokens
Delete Tokens
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
Fire Transition
Select Transition
Fire Transition
Select Transition
Add Tokens
Delete Tokens
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
Fire Transition
Select Transition
Fire Transition
Select Transition
Add Tokens
Delete Tokens
BPEL Activity Executed
BPEL Activity Runs
BPEL Activity Startable
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
Petri Net subnet
initial
final
stop
stopped
failed
BPEL Element
B2PN
Traceability link
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
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
PNF: PNFiring Tr: Transition
BA: BPEL Activity B2PN : Subnet
trans trans
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
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
initial
start stop
stopped
failed
final
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
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
BPEL Trace
BPEL step BPEL step
Activity Startable
Activity Runs
Activity Executed
next
next next
Change State
Change State
next
initial
inner trans
stop
stopped
failed
final
initial
inner trans
stop
stopped
failed
final
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
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
initial
inner trans
stop
failed
final
stopped
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
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 MBPEL
MPN’
CHMPN
MBPEL’
CHMBPEL
IF
map
TR
TR
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 MBPEL
MPN’
CHMPN
MBPEL’
CHMBPEL
IF
map
TR
TR
Record model changes
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 MBPEL
MPN’
CHMPN
MBPEL’
CHMBPEL
IF
map
TR
TR
Traceability model
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 MBPEL
MPN’
CHMPN
MBPEL’
CHMBPEL
IF
map
TR
TR
Execute back-annotation
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 MBPEL
MPN’
CHMPN
MBPEL’
CHMBPEL
IF
map
TR
TR
Apply changes
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
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 Step 1
PNF: PNFiring Tr: Transition trans
Appear
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 Step 1
PNF: PNFiring Tr: Transition trans
Appear Step 2 PNF: PNFiring Tr: Transition
BA: BPEL Activity
B2PN : Subnet trans
trans
Match
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 Step 1
PNF: PNFiring Tr: Transition trans
Appear Step 2 PNF: PNFiring Tr: Transition
BA: BPEL Activity
B2PN : Subnet trans
trans
Match
Step 3 PNF: PNFiring Tr: Transition
BA: BPEL Activity
B2PN : Subnet trans
BAR: BPELActivityRuns
trans
activity
Create
Back-annotation with CDT
Presentation of BPEL traces
Dynamic behavior requires dynamic presentation
Presentation of BPEL traces
Dynamic behavior requires dynamic presentation
BPEL Trace
BPEL step BPEL step
Activity Startable
Activity Runs
Activity Executed
next
next next
Change State
Change State
next
Presentation of BPEL traces
Dynamic behavior requires dynamic presentation
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
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
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
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
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
Presentation of BPEL traces
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
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
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
Presentation of BPEL traces
Hidden formal methods
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
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update? Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update? Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update? Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Event: Cancel
Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Rollback changes
Event: Cancel
Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Rollback changes
Throw Error
Event: Cancel
Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Rollback changes
Throw Error
Event: Cancel
Yes No
Yes No
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Rollback changes
Throw Error
Event: Cancel
Yes No
Yes No
Returns with a web-service error
Motivating scenario (cont.)
Requirement: Every received request must result in a reply!
Receive request
Calculate Rating
Send offer
Accept?
Receive answer
Send reply
Send rejection
Receive update request
Update?
Rollback changes
Throw Error
Event: Cancel
Yes No
Yes No
Returns with a web-service error
Not executed = No reply
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
Summary
Reusable dynamic back-annotation approach:
oWith 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)
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!
top related