Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Back-annotation of Simulation Traces with Change-Driven Model Transformations

448 views

Published on

Back-annotation of simulation traces using the VIATRA model transformation framework (http://viatra.inf.mit.bme.hu) presented at the SEFM 2010 conference (http://www.sefm2010.isti.cnr.it/)

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

Back-annotation of Simulation Traces with Change-Driven Model Transformations

  1. 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 GroupBudapest University of Technology and EconomicsSoftware Engineering and Formal Methods 2010, Pisa, Italy
  2. 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. 3. Outline of the talk Motivation Introduction – BPEL verification Back-annotation problem Transformation-driven Back-annotation Summary Future Work
  4. 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. 5. Verification of BPELBusiness RequirementProcess
  6. 6. Verification of BPEL Receive requestBusiness RequirementProcess
  7. 7. Verification of BPEL Every received request must result in a reply!Business RequirementProcess
  8. 8. Verification of BPELBusiness RequirementProcess Transform Model
  9. 9. Verification of BPEL Business Requirement Process Transform ModelFormal model (Petri Nets)
  10. 10. Verification of BPEL Business Requirement Process Transform ModelFormal model Token Transition Place (Petri Nets)
  11. 11. Verification of BPELBusiness RequirementProcess Transform Formalize Model Theorem
  12. 12. Verification of BPELBusiness RequirementProcess G [ Request => Transform Formalize F (Reply) ] Model Theorem Linear Temporal Logic formula
  13. 13. Verification of BPELBusiness RequirementProcess Transform Formalize Model Theorem Check Model checker
  14. 14. Verification of BPELBusiness RequirementProcess Transform Formalize Model Theorem Check Model checker Result
  15. 15. Verification of BPELBusiness RequirementProcess Transform Formalize Model Theorem Check Model checker Result Proved / Counter-example
  16. 16. Counter-example
  17. 17. Counter-example
  18. 18. Processing results Counter-example = Execution Trace o Sequence of steps representing changes of the model
  19. 19. Processing results Counter-example = Execution Trace o Sequence of steps representing changes of the model
  20. 20. Processing results Counter-example = Execution Trace o Sequence of steps representing changes of the modelTransition firing
  21. 21. Processing results Counter-example = Execution Trace o Sequence of steps representing changes of the modelTransition firingModel change
  22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 35. Trace mapping – simple changes1. Identification of BPEL process elements which are affected by the PN change o Static traceability model generated during the structural transformation2. Decide BPEL change type represented by the PN change o Inspect the structure of the static model • Graph patterns defined for matching to structure parts3. Persist BPEL change into the hierarchy of the trace model o Use dynamic traceability model to record BPEL-PN trace correspondence
  36. 36. Trace mapping – simple changes1. Identification of BPEL process elements which are affected by the PN change o Static traceability model generated during the structural transformation2. 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 parts3. Persist BPEL change into the hierarchy of the trace model o Use dynamic traceability model to record BPEL-PN trace correspondence
  37. 37. Trace mapping – simple changes1. Identification of BPEL process elements which are affected by the PN change o Static traceability model generated during the structural transformation2. Decide BPEL change type represented by the PN change o Inspect the structure of the static model • Graph patterns defined for matching to structure parts3. Persist BPEL change into the hierarchy of the trace model o Use dynamic traceability model to record BPEL-PN trace correspondence
  38. 38. Trace mapping – simple changes initial1. Identification of BPEL process elements which are affected by the PNstart stop change o Staticstopped traceability model generated during the structural transformation failed2. 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 parts3. Persist BPEL change into the hierarchy of the trace model o Use dynamic traceability model to record BPEL-PN trace correspondence
  39. 39. Trace mapping – simple changes1. Identification of BPEL process elements which are affected by the PN change o Static traceability model generated during the structural transformation2. Decide BPEL change type represented by the PN change o Inspect the structure of the static model • Graph patterns defined for matching to structure parts3. Persist BPEL change into the hierarchy of the trace model o Use dynamic traceability model to record BPEL-PN trace correspondence
  40. 40. Trace mapping – simple changes1. 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 Activity2. 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 parts3. Persist BPEL change into the hierarchy of the trace model o Use dynamic traceability model to record BPEL-PN trace correspondence
  41. 41. initial initial stop stopstopped inner stopped inner trans trans failed failed final final
  42. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 54. Presentation of BPEL traces Dynamic behavior requires dynamic presentation
  55. 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. 56. Presentation of BPEL traces Dynamic behavior requires dynamic presentation
  57. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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!

×