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

Abstract

Abstract-Model-driven analysis aims at detecting design flaws early in high-level design models by automatically deriving mathematical models. These analysis models are subsequently investigated by formal verification and validation (V&V) tools, which may retrieve traces violating a certain requirement. Back-annotation aims at mapping back the results of V&V tools to the design model in order to highlight the real source of the fault, to ease making necessary amendments.Here we propose a technique for the back-annotation of simulation traces based on change-driven model transformations. Simulation traces of analysis models will be persisted as a change model with high-level change commands representing macro steps of a trace. This trace is back-annotated to the design model using change-driven transformation rules, which bridge the conceptual differences between macro steps in the analysis and design traces. Our concepts will be demonstrated on the back-annotation problem for analyzing BPEL processes using a Petri net simulator.

Omniscient debugging for executable DSLs

“…. [11] else if value is ReferenceValue then [12] dynObject.set(tracedProp, value.referenceValue) [13] else if value is ManyReferenceValue then [14] . .…”

“…To that effect, efforts have been made to provide facilities to design so-called executable DSLs. [9,10,11,12,13,14,15]. More precisely, two different approaches are commonly used to define the execution semantics of an executable DSL: operational semantics (i.e., interpretation) and translational semantics (i.e., compilation).…”

A Transformation-Driven Approach to Automate Feedback Verification Results

“…Hegedüs et al [16] propose a technique for the back propagation of simulation traces based on change-driven model transformations from traces generated by SAL model checking framework to the specific animator named BPEL Animation Controller. So, they define a change-driven model transformation which consumes changes of the Petri nets simulation run and produces a BPEL process execution using traceability information generated while running the translational semantics defined previously.…”

A Generic Tool for Tracing Executions Back to a DSML’s Operational Semantics

“…(notStarted, undef ined, 0) (notStarted, undef ined, 0) 0 (inP rogress, tooEarly, 0) (notStarted, 8) Note that indeed both processes finish in due time: pA starts at 0 and finishes at 3 (its tmin = 3); and pB starts at 3 and finishes at 8 (its tmin = 5 = 8 − 3).…”

“…Most of the proposed methods are either dedicated to only one pair metamodel/verification tool ( [7], [10]) or they compute an "explanation" of the execution in a more abstract way. In [8], the authors propose a general method based on a traceability mechanism of model transformations. It relies on a relation between elements of the source and the target metamodel, implemented by means of annotations in the transformation's source codes.essentially By contrast, our approach does not require instrumenting the model transformation code, and is formally grounded on operational semantics, a feature that allows us to prove its correctness.…”