Semantic Model Differencing Utilizing Behavioral Semantics Specifications

Langer, Philip; Mayerhofer, Tanja; Kappel, Gerti

doi:10.1007/978-3-319-11653-2_8

Cited by 25 publications

(33 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Model breeding essentially requires identifying the common and different parts of two models so that the common parts can be retained in the new solution and the different parts can be mixed suitably. This is very similar to what has been developed in the context of work on model differencing and model merging [22,23,24,25]. It should be possible to reuse ideas from this field to develop generic model breeders.…”

Section: Model Evolutionmentioning

confidence: 54%

Towards Model-Based Optimisation: Using Domain Knowledge Explicitly

Zschaler

Mandow

2016

Software Technologies: Applications and Foundations

View full text Add to dashboard Cite

Abstract. Search-based software engineering (SBSE) treats softwaredesign problems as search and optimisation problems addressing them by applying automated search and optimisation algorithms. A key concern is the adequate capture and representation of the structure of design problems. Model-driven engineering (MDE) has a strong focus on domainspecific languages (DSLs) which are defined through meta-models, capturing the structure and constraints of a particular domain. There is, thus, a clear argument for combining both techniques to obtain the best of both worlds. Some authors have proposed a number of approaches in recent years, but these have mainly focused on the optimisation of transformations or on the identification of good generic encodings of models for search. In this paper, we first provide a structured overview of the current state of the art before identifying limitations of the key proposals (transformation optimisation and generic genetic encodings of models). We then present a first prototype for running search algorithms directly on models themselves (rather than a separate representation) and derive key research challenges for this approach to model optimisation.

show abstract

Section: Model Evolutionmentioning

confidence: 54%

Towards Model-Based Optimisation: Using Domain Knowledge Explicitly

Zschaler

Mandow

2016

Software Technologies: Applications and Foundations

View full text Add to dashboard Cite

show abstract

“…[1] begin [2] foreach value ∈ state.values do [3] dimension ← value.dimension [4] tracedObject ← dimension.tracedObject [5] tracedProp ← tracedObject.tracedProperty [6] dynObject ← tracedObject.dynamicObject [7] if value is IntegerAttributeValue then [8] dynObject.set(tracedProp, value.intValue) [9] else if value is <other attribute types> then [10] . .…”

Section: Inputmentioning

confidence: 99%

“…We begin by updating the current model state and the current starting Step that is starting. [1] begin [2] dstate .exeState.modelState ← sstart .startingState [3] dstate .exeState.stepping.starting ← sstart [4] pauseIfBreakpoints() [5] dstate .exeState.stepping.starting ← null [6] dstate .exeState.stepping.ending ← null [7] dstate .exeState.stepping.inProgress.push(sstart ) [8] dstate .lastNotification ← Starting Algorithm 5: stepEnding (omniscient debugger) [1] begin [2] if dstate .lastNotification = Ending then [3] pauseIfBreakpoints() [4] dstate .exeState.stepping.starting ← null [5] s end ← dstate .exeState.stepping.inProgress.pop() [6] dstate .exeState.stepping.ending ← s end [7] dstate .exeState.modelState ← s end .endingState [8] dstate .lastNotification ← Ending step of the observable ExecutionState element (lines 2-3). Next, we check the breakpoints and pause if one is enabled (line 4).…”

Section: Integration As An Execution Listenermentioning

confidence: 99%

“…Definition jumpToStartingStep(sstart : Step) [1] manager.restoreModelToState(sstart .startingState) [2] dstate .exeState.modelState ← sstart .startingState [3] restoreInProgressSteps(sstart ) [4] dstate .exeState.stepping.starting ← sstart [5] if sstart .container is Step then [6] dstate .exeState.stepping.ending ← sstart .container.nestedSteps.getBefore(sstart ) [7] else [8] dstate .exeState.stepping.ending ← null jumpToEndingStep(s end :…”

Section: Trace Exploration Servicementioning

confidence: 99%

“…In that context, early dynamic verification and validation (V&V) techniques, such as testing [6], semantic differencing [7] or runtime verification [8], are necessary to ensure that such executable models (or programs 1 ) are correct. These techniques require models to be executable, which can be achieved by defining the * Corresponding author Email addresses: erwan.bousse@tuwien.ac.at (Erwan Bousse), dorian.leroy@jku.at (Dorian Leroy), benoit.combemale@irit.fr (Benoit Combemale), wimmer@big.tuwien.ac.at (Manuel Wimmer), baudry@kth.se (Benoit Baudry)…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Omniscient debugging for executable DSLs

Bousse

LeRoy²,

Combemale

et al. 2018

Journal of Systems and Software

View full text Add to dashboard Cite

Omniscient debugging is a promising technique that relies on execution traces to enable free traversal of the states reached by a model (or program) during an execution. While a few General-Purpose Languages (GPLs) already have support for omniscient debugging, developing such a complex tool for any executable Domain Specific Language (DSL) remains a challenging and error prone task. A generic solution must: support a wide range of executable DSLs independently of the metaprogramming approaches used for implementing their semantics; be efficient for good responsiveness. Our contribution relies on a generic omniscient debugger supported by efficient generic trace management facilities. To support a wide range of executable DSLs, the debugger provides a common set of debugging facilities, and is based on a pattern to define runtime services independently of metaprogramming approaches. Results show that our debugger can be used with various executable DSLs implemented with different metaprogramming approaches. As compared to a solution that copies the model at each step, it is on average six times more efficient in memory, and at least 2.2 faster when exploring past execution states, while only slowing down the execution 1.6 times on average.Keywords: Software Language Engineering; Domain-Specific Languages; Executable DSL; Omniscient debugging; Execution trace IntroductionA large amount of Domain-Specific Languages (DSLs) have been proposed and used to describe the dynamic aspects of systems [1,2,3,4,5]. In that context, early dynamic verification and validation (V&V) techniques, such as testing [6], semantic differencing [7] or runtime verification [8], are necessary to ensure that such executable models (or programs 1 ) are correct. These techniques require models to be executable, which can be achieved by defining the * Corresponding author Email addresses: erwan.bousse@tuwien.ac.at (Erwan Bousse), dorian.leroy@jku.at (Dorian Leroy), benoit.combemale@irit.fr (Benoit Combemale), wimmer@big.tuwien.ac.at (Manuel Wimmer), baudry@kth.se (Benoit Baudry)1 We arbitrarily use the term executable model since this work focuses on metamodel-based DSLs, but the term program can be used interchangeably.

show abstract

Dependability of Model-Driven Executable DSLs

Idani

2020

Communications in Computer and Information Science

View full text Add to dashboard Cite

Semantic Model Differencing Utilizing Behavioral Semantics Specifications

Cited by 25 publications

References 25 publications

Towards Model-Based Optimisation: Using Domain Knowledge Explicitly

Towards Model-Based Optimisation: Using Domain Knowledge Explicitly

Omniscient debugging for executable DSLs

Dependability of Model-Driven Executable DSLs

Contact Info

Product

Resources

About