A Generative Approach to Define Rich Domain-Specific Trace Metamodels

Abstract

Executable Domain-Specific Modeling Languages (xDSMLs) open many possibilities for performing early verification and validation (V&V) of systems. Dynamic V&V approaches rely on execution traces, which represent the evolution of models during their execution. In order to construct traces, generic trace metamodels can be used. Yet, regarding trace manipulations, they lack both efficiency because of their sequential structure, and usability because of their gap to the xDSML. Our contribution is a generative approach that defines a rich and domain-specific trace metamodel enabling the construction of execution traces for models conforming to a given xDSML. Efficiency is increased by providing a variety of navigation paths within traces, while usability is improved by narrowing the concepts of the trace metamodel to fit the considered xDSML. We evaluated our approach by generating a trace metamodel for fUML and using it for semantic differencing, which is an important V&V activity in the realm of model evolution. Results show a significant performance improvement and simplification of the semantic differencing rules as compared to the usage of a generic trace metamodel.

Omniscient debugging for executable DSLs

“…We considered two sets of fUML models. First, as in our previous work [18], we used models taken from the case study of Maoz et al [36] 5 . This choice was made to help establish a benchmark, facilitate comparison with future work, and because the models were drawn from industrial sources.…”

“…The results show that our approach is on average six times more efficient in memory when compared to the second debugger, and at least respectively 60 and two times faster when exploring past states compared to the first and second debuggers, while only slowing down the execution 1.6 times on average. This paper is a significant extension of our previous work [17,18,19]. The extension comprises (i) a pattern to interrupt model executions and to decouple runtime services from metaprogramming approaches, (ii) a fully generic set of trace management facilities, (iii) a revised generic omniscient debugger, (iv) an up-to-date description of the current tool-support, (v) a more thorough review of related work.…”

Interconnected Linguistic Architecture

“…The generator is modeled by the EMFGenerator function which takes a designated genModel to produce the javaFiles which in turn defines an object-graph language CustomObjects for Custom and the functions CustomSerialize and CustomDeserialize for de-/serialization. For instance, deserialization would result in a 'transient' (in-memory) object graph to [3][4][5][6][7][8][9] be treated in a special manner during verification (megamodel versus system); see the interconnection aspect 'Transient artifacts'.…”

“…Solution Model elements are semantically annotated by linking them to appropriate knowledge resources, e.g., pages on Wikipedia, DBpedia, or resources on schema.org. How exactly model elements exactly should be annotated and what sources to use, [3][4][5][6][7][8][9][10][11] depends, of course, on the specific megamodeling vocabulary. For instance, one could link languages or technologies to resources.…”

“…We assume XML document and schema to be readily bound in the XML module. The entity for the XML document needs to be duplicated and rebound in each of [3][4][5][6][7][8][9][10][11][12][13][14][15] the two instances so that we distinguish input and output documents of the XML transformation. Realization MegaL's import mechanism has essentially copy-and-paste semantics modulo the following refinements: bindings in the importing module override bindings of the imported module; entities of the imported module can be renamed; if a module is imported more than once into a module (directly or indirectly), then non-renamed declarations are only imported once.…”