Modelling the Operational Semantics ofDomain-Specific Modelling Languages

Guido Wachsmuth

Humboldt-Universitat zu BerlinUnter den Linden 6

D-10099 Berlin, Germanyguwac@gk-metrik.de

Abstract. Domain-specific modelling languages provide modelling meanstailored to a particular domain. In Model-driven Engineering, it is com-mon practice to specify such languages by modelling means as well. Inthis paper, we investigate structural operational semantics for domain-specific modelling languages. Thereby, we rely completely on standardmodelling means as provided by the Object Management Group. As ex-amples, we specify structural operational semantics for Petri nets as wellas for a stream-oriented language from the domain of earthquake de-tection. The approach is useful to provide prototypical tool support fordomain-specific modelling languages. It can be instrumented to specifyinterpreters and debuggers in a generic way.

1 Introduction

Domain-specific modelling languages. In Model Driven Engineering (MDE),models are the primary engineering artefacts. Models are expressed by meansof modelling languages. This includes general-purpose languages like the Uni-fied Modeling Language (UML) [?] as well as domain-specific modelling lan-guages (DSMLs). In contrast to general-purpose languages, DSMLs provide mod-elling means tailored to a particular domain [?,?]. They include concepts andnotations to which experts from this domain are used. This enables domainexperts to participate in software engineering by capturing their knowledge inprecise and comprehensible models. Requirements for a DSML are often sketchyand evolve over time. Thus, prototypical tool support is needed. Since the ap-plication range of a DSML and thus its reuse will usually be limited, generativeor generic solutions are preferable. In this paper, we instrument standardisedmodelling means to specify interpreters and debuggers for DSMLs in a genericway.

Model-driven language engineering. In MDE, it is common practice tospecify modelling languages by modelling means. Metamodels capture the ab-stract syntax of these languages. Language semantics are usually expressed bymodel transformations. Thereby, language instances are transformed into in-stances of another language. Often, this language is somehow executable, for

example a standard programming language like Java. This process of code gen-eration corresponds to traditional compilation. In this paper, we address modelinterpretation. Therefore, we adopt the idea of structural operational seman-tics from grammar-based language engineering [?]. The semantics of a modellinglanguage is not given by a translation but by a transition system. A transitionsystem consists of a set of valid configurations and a transition relation betweenconfigurations. For the modelling of transition systems, we rely completely onmodelling means standardised by the Object Management Group (OMG). Weinstrument metamodels to model configuration sets, and use model transforma-tions to specify transition relations.

Structure of the paper. In the next section, we give a brief introduction tometamodels, model transformations, and operational semantics. In Section 3,we define the operational semantics of Petri nets by syntactic manipulation. InSection 4, we discuss the semantics of a stream-oriented language from the do-main of earthquake detection as a more sophisticated example. Here, we specifythe operational semantics by a transition relation between configurations. InSection 5, we discuss the benefits of our approach in the context of languageprototyping and generic tool support for DSMLs. Related work is discussed inSection 6. The paper is concluded in Section 7.

2 Preliminaries

Metamodels. Metamodels model the structure of models. From a languageperspective, they define an abstract syntax for a modelling language. With itsMetaObject Facility (MOF) [?], the OMG provides standard description meansfor metamodels. The MOF is rooted in the UML and reuses its basic conceptslike packages, classes, properties, and associations. Constraints expressed in theObject Constraint Language (OCL) [?] can be used to restrict the instance set ofa MOF compliant metamodel. Additionally, MOF offers sophisticated featureslike property redefinition, union sets, and package merge. The semantics of thesefeatures was formally defined in [?].

Example 1 (Petri net metamodel). Fig. 1 provides a MOF compliant metamodelfor Petri nets. A Petri net consists of places and transitions. Each transitionhas input and output places. Places are marked with a number of tokens. Thisnumber is constrained to be non-negative.

Model transformations. Model transformations take a central place in MDE.They are used to translate models to other models, e.g. platform-independentmodels into platform-specific ones. Furthermore, model transformations can beinstrumented to translate models into an exutable language, e.g. Java. The OMGstandard for model transformations is Query/View/Transformation (QVT) [?].QVT defines three model transformation languages: QVT Relations and QVT

Transition

Net

Place

token : Integer token >= 0

src0..*

snk0..*

snk0..*

src0..*

transitions 0..*

1

places0..*

1

Fig. 1. A metamodel for Petri nets.

Core are declarative languages at two different levels of abstraction. The QVTOperational Mappings language is an imperative language. In this paper, wefocus on QVT Relations, the high-level declarative language. It extends OCLand its semantics is given in a self-descriptive way by a mapping to QVT Core.

In QVT Relations, a transformation needs to declare parameters for holdingthe models involved in the transformation. These parameters are typed overappropriate metamodels. Upon invocation, the user needs to specify the directionfor the execution of a transformation. A transformation can be executed in thedirection of one parameter. The model held by this parameter is the targetmodel of the transformation. All models held by other parameters are sourcemodels. In special cases, the target model is one of the source models. Then, thetransformation is executed as an in-place transformation, i.e. the target modelresults from changing the source model.

A transformation consists of queries and relations. A query returns the resultof an OCL expression. A relation declares several domains. A domain is boundto a model held by a parameter. Furthermore, it declares a pattern which willbe bound to elements from this model. A pattern consists of a variable anda type declaration which may specify some of the properties of this type bysubpatterns. All relations of a transformation which are declared as top needto hold. If a relation does not hold, the transformation tries to satisfy it bychanging elements in domains which are bound to the target model and declaredas enforce. Relations can have two kinds of clauses: A when clause specifies acondition under which a relation applies. A where clause specifies additionalconstraints among the involved model elements, which may need to be enforced.These concepts are illustrated in the example that follows.

Example 2 (Queries and relations in QVT Relations). Figure 2 shows a trans-formation in QVT Relations. The transformation has two parameters input andoutput both typed with the Petri net metamodel given in Ex. 1. As parame-ter names suggest, we assume the execution of the tranformation in directionoutput. Thus, input and output will hold the source and target model, re-spectively. The transformation is designed for in-place execution. Thus, bothparameters must be bound to the same model. Otherwise, the execution will notyield correct results. The transformation declares the queries isActivated andgetActivated. The first query returns whether a given transition in a Petri net

transformation petri_sos(input:petri, output:petri) {top relation run {

trans: Transition;checkonly domain input net:Net{};enforce domain output net:Net{};where { trans = getActivated(net); fire(trans); }

}

relation fire {checkonly domain input trans:Transition{};

}

query isActivated(trans: Transition): Boolean {trans.src -> forAll(place | place.token > 0)

}

query getActivated(net: Net): Transition {net.transitions -> any(trans | isActivated(trans))

}

top relation produce {checkonly domain input p:Place{ src = t:Transition{}, token = n:Integer{} };enforce domain output p:Place{ token = n+1 };when { fire(t); t.src -> excludes(p); }

}

top relation consume {checkonly domain input p:Place{ snk = t:Transition{}, token = n:Integer{} };enforce domain output p:Place{ token = n-1 };when { fire(t); t.snk -> excludes(p); }

}

top relation preserve {checkonly domain input p:Place{ token = n:Integer{} };enforce domain output p:Place{ token = n };when { not produce(p, p); not consume(p, p); }

}}

Fig. 2. Operational semantics for Petri nets.

is activated or not. It inspects all input places of the transition. If they are allmarked with tokens, the transition is activated and the query returns true. Thesecond query returns an activated transition of a given Petri net. Therein, theOCL predicate any ensures a non-deterministic choice. Furthermore, the trans-formation contains several relations. The relation run declares two domains. Thefirst domain pattern binds the variable net to a Petri net in the source model(held by input). The second domain pattern specifies the same Petri net to occurin the target model (held by output). The second domain is declared enforced.Thus, the net will be created in the target model if it does not already exist.A net in the target model, for which no corresponding net in the source modelcan be found, will be deleted. In its where clause, the relation run obtains anactivated transition of the net by calling the query getActivated. Additionally,the unary relation fire needs to hold for this transition. fire simply checks ifthe transition can be found in the source model. The first relation run is declaredas top. Therefore, it has to hold to process the transformation successfully. Sincethe relation fire is not declared as top, it only has to hold to fulfill other rela-

tions calling it from their where clauses. We will discuss the remaining relationslater on.

Operational semantics. The operational semantics of a language describesthe meaning of a language instance as a sequence of computational steps. Gen-erally, a transition system 〈Γ,→〉 forms the mathematical foundation, where Γ isa set of configurations and→⊆ Γ ×Γ is a transition relation. Inference rules area common way to define the valid transitions in the system inductively. Plotkinpioneered these ideas. In his work on structural operational semantics [?], he pro-posed to describe transitions according to the abstract syntax of the language.This allows for reasoning about programs by structural induction and correctnessproofs of compilers and debuggers [?]. The structural operational semantics of alanguage defines an interpreter for this language working on its abstract syntax.This can be instrumented as a reference to test implementations of compilersand interpreters. Starting from Plotkin’s ideas, structural operational semanticsbecame very popular in traditional grammar-based language engineering [?,?]. Inthis paper, we apply the idea of structural operational semantics to model-drivenlanguage engineering. Thereby, we rely only on standard modelling techniques:Configuration sets are captured in MOF compliant metamodels. Transition re-lations are specified in QVT Relations.

3 Syntactic manipulation: Petri nets

For some simple languages, computational steps can be expressed as purely syn-tactic manipulation. A well-known example for this is the lambda calculus [?].Petri nets provide another example. In this section, we give an operational se-mantics for Petri nets based on the metamodel given in Fig. 1. A computationstep in a Petri net chooses an activated transition non-deterministically and firesit. The marking of a place is

(i) increased by one token iff it is only an output place,(ii) decreased by one token iff it is only an input place,

(iii) preserved otherwise.

The transformation given in Fig. 2, specifies these semantics in QVT Rela-tions. We discussed its relations run and fire as well as the queries getActivatedand isActivated already in Ex. 2. The relations produce, consume, and preservecover the different cases for places:

(i) The relation produce matches a place p in the input, an incoming transitiont of this place, and its number of tokens n. It enforces an increase of thenumber of tokens in the output by one. The relation needs to hold onlyif the matched transition is fired and if the matched place is not an inputplace of this transition.

DetectionTimeFilter

threshold : Integer

StaLtaFilter

staTime : IntegerltaTime : Integerthreshold : Integer

DetectionWarning

processWarning()

SimulationSensor

readAcceleration()

TextWarning

processWarning()

AccelerationSensor

readAcceleration()

DatabaseSensor

readAcceleration()

SimulationWarning

processWarning()

Source Sink

Filter

sink

1

source

1

Fig. 3. A metamodel for a stream-oriented language.

(ii) The relation consume works similarly. It matches a place in the input, anoutgoing transition of this place, and its number of tokens. The number oftokens in the output is decreased by one. The relation only has to hold if thetransition is fired and if the place is not an output place of the transition.

(iii) Otherwise, preserve keeps places unchanged.

4 Configuration transitions: A stream-oriented language

Describing operational semantics by syntactic manipulation works only for sim-ple languages. In this section, we provide operational semantics for a stream-oriented language by transitions between configurations. We rely on MOF todefine a metamodel for configurations and on QVT Relations to capture thetransition relation between configurations.

The language. Our group develops technologies for earthquake early warningsystems. Earthquake detection algorithms form an integral part of such systems.Developing such algorithms requires knowledge from the domain of seismology.To involve domain experts in the system engineering process, we provide themwith domain-specific modelling means [?].

Seismologists might think of earthquake detection in terms of streams: Sen-sors produce streams of measured data, filters process these streams, and sinksconsume the provided data. Fig. 3 shows a MOF compliant metamodel for astream-oriented language. In this paper, we mention only one kind of source,

StaLtaFilter

staTime : IntegerltaTime : Integerthreshold : Integer

AccelerationSensor

readAcceleration()

DetectionTimeFilter

threshold : Integer

StaLtaCfg

buffer : Integer [0..*]

DetectionTimeCfg

counter : Integer

SensorCfg

SourceSourceCfg

data : Integer [0..1]

Configuration source

11

{redefines source}filter

11

{redefines source}sensor

11

{redefines source}filter

11

configs

0..*

config

1

Fig. 4. A metamodel for configurations.

that is acceleration sensors, and only one kind of sink, that is detection warn-ings.

For acceleration sensors, various implementations of readAcceleration()can be used to provide sensor readings. For example, the method can connect toa database of sensor readings stored during former earthquake events. Alterna-tively, simulation of a wave propagation model might calculate the data needed.In the same way, processWarning() can be customised to write detection warn-ings to a file or to provide it to other simulations, e.g. for evacuation.

Filters process data. Therefore, a filter acts as a source and as a sink. Weconsider two kind of filters: The Short Term Averaging/Long Term Averag-ing (STA/LTA) detection algorithm [?] is realised by STA/LTA filters. The ideaof this algorithm is to determine the acceleration average in the short and thelong term. If the ratio between both averages exceeds a threshold, an earthquakeis detected. The filters can be configured with values for the STA time, the LTAtime, and the threshold. Detection time filters refrain from forwarding data fora certain amount of time. Once a filter forwards data from its source, it stopsconsidering data from its source for the specified amount of time.

Configurations. Configurations form the central concept for the structuraloperational semantics of the stream-oriented language. As a first step, we needto define the set of valid configurations by a metamodel as shown in Fig. 4. Themetamodel defines a configuration for each kind of sources in the stream-orientedlanguage. Generally, the configuration for a source contains the current dataprovided by the source. Additionally, configurations for STA/LTA filters keep abuffer of input data. Detection time filter configurations store a time counter.Figure 5 shows an abstract representation of an initial configuration model for anexample stream-oriented model. Here, model elements from the stream-oriented

: DetectionTimeFilter

threshold = 5000

: DetectionTimeCfg

counter = 0

: DatabaseSensor

: SensorCfg

: Configuration

: StaLtaCfg

: StaLtaFilter

staTime = 1000ltaTime = 10000threshold = 4

: TextWarning

Fig. 5. Initial configuration of a stream-oriented model.

model are filled white while model elements from the configuration model arefilled grey.

Transition relation. The operational semantics of the stream-oriented lan-guage is now expressed as a transition relation between configurations in time.For simplicity, we assume equidistant time steps. We define the transition rela-tion in QVT Relations. As in the Petri net example, the transformation changesa configuration in-place. Its relations and queries are given in Fig. 6. We willnow discuss the details.

In each step, sensors need to provide new acceleration data. The configurationof a sensor is updated by the new value. The relation readSensor defines thisbehaviour. It matches a sensor configuration in the input and in the outputmodel. The output configuration is enforced to contain new data read from thesensor.

If a source provides data to a warning sink, a detection warning has to be pro-cessed. The behaviour is specified by the relation processWarning. It matchessource configurations in the input which provide data and for which the sinkof the configured source is a warning sink. The configuration is preserved inthe output model. As specified in the where clause, the warning is processed bycalling the corresponding method on the sink.

The relation processStaLta matches the configuration for a STA/LTA filterin the input and the output model. Furthermore, the corresponding filter, itssource, and the configuration of the source are matched in the input model.For the output configuration, new values for the buffer and the filter data areenforced. The new buffer is empty if the source does not provide any data.Otherwise, the new buffer consists of the data provided from the source andthe values from the old buffer. If the new buffer overflows, older elements willbe removed from the buffer. The ratio between short and long term average iscalculated in terms of the new buffer. If it exceeds the specified threshold of the

top relation readSensor {checkonly domain input cfg:SensorCfg{ sensor = sensor:AccelerationSensor{} };enforce domain output cfg:SensorCfg{ data = sensor.readAcceleration() };

}

top relation processWarning {checkonly domain input cfg:SourceCfg{

source = src:Source{ sink = warn:DetectionWarning{} }, data = d:Integer{}};enforce domain output cfg:SourceCfg{};where { warn.processWarning(); }

}

top relation processStaLta {checkonly domain input fcfg1:StaLtaCfg{

filter = filter:StaLtaFilter{source = src:Source{}, staTime = sta:Integer{},ltaTime = lta:Integer{}, threshold = threshold:Integer{}

},config = cfg:Configuration{ configs = scfg:SourceCfg{ source = src } }

};enforce domain output fcfg2:StaLtaCfg{

buffer = fillBuffer(fcfg1.buffer, lta, scfg.data),data = provideRatio(calculateRatio(fcfg2.buffer, sta, lta), threshold)

};when { fcfg1 = fcfg2; }

}

query fillBuffer(buffer: Sequence(Integer), size: Integer, value: Integer): Sequence(Integer) {if value -> oclIsUndefined() then Sequence{} else

trimBuffer(buffer -> prepend(value), size)endif

}

query trimBuffer(buffer: Sequence(Integer), size: Integer): Sequence(Integer) {if buffer -> size() <= size then buffer else buffer -> subSequence(1, size) endif

}

query calculateRatio(buffer: Sequence(Integer), sta: Integer, lta: Integer): Integer {if buffer -> size() >= lta then

trimBuffer(buffer, sta) -> sum() div trimBuffer(buffer, lta) -> sum()else

undefinedendif

}

query provideRatio(ratio: Integer, threshold: Integer): Integer {if ratio >= threshold then ratio else undefined endif

}

top relation processDetectionTime {checkonly domain input tcfg:DetectionTimeCfg{

filter = filter:DetectionTimeFilter{ source = src:Source{}, waitTime = wait:Integer{} },counter = 0,config = cfg:Configuration{

configs = scfg:SourceCfg{ source = src, data = data:Integer{} }}

};enforce domain output tcfg:DetectionTimeCfg{ data = data, counter = wait };

}

top relation updateDetectionTime {checkonly domain input tcfg:DetectionTimeCfg{ counter = cnt:Integer{} };enforce domain output tcfg:DetectionTimeCfg{ data = undefined, counter = (cnt - 1).max(0) };when { not processDetectionTime(tcfg, tcfg); }

}

Fig. 6. Operational semantics for the stream-oriented language.

filter, it will be used as the new filter data. Otherwise, the filter does not provideany data.

The relations processDetectionTime and updateDetectionTime specifythe desired behaviour of detection time filters. The former relation matches aconfiguration for a detection time filter with a reset counter, its source, the con-figuration of this source in the input model, and the provided data. In the newconfiguration, this data is provided by the filter and the counter is started. Thelatter relation updates the internal counter and ensures that no data is providedby the filter. It only has to hold if the first relation fails. The counter is decreasedby one until it equals zero.

5 Applications

Interpreters. Modelling the structural operational semantics of a languagewith MOF and QVT Relations provides a generic way for interpretation. For acompliant metamodel, the MOF standard defines how to serialise the abstractrepresentation of models. This ensures tool interoperability. Thus, we can loadany model compliant to a metamodel together with the QVT transformationdescribing the language’s semantics into a QVT engine. Then, execution of thetransformation interprets the model.

Example 3 (Interpreting stream-oriented models). We want to interpret the modelfrom Fig. 5. Therefor, we load the transformation specifying the operational se-mantics of the stream-oriented language into a QVT engine. We discussed thistransformation in the preceeding section. Then, we apply the transformationto the initial configuration of the stream-oriented model. This results in a newconfiguration. We can instruct the QVT engine to apply the transformationuntil the configuration is not affected anymore. During the execution, the trans-formation will call the method readAcceleration to read sensor data from adatabase. If an earthquake is detected, the transformation will call the methodprocessWarning to present a textual warning to the user.

We can benefit from the direct executability for language prototyping. Struc-tural operational semantics descriptions provide a generic way to specify inter-preters. The specification depends on the structure of the language and canbe expressed in the particular modelling domain which the language addresses.Thereby, execution takes place in the expert domain. In contrast to translationalsemantics, error and debug information remain in the modelling domain. Thus,domain experts can be involved into a prototyping cycle for language semantics.

Once the semantics meet the expectations of domain experts, equivalent se-mantics can be implemented in another style. Usually, translational semanticswill be preferred to include platform-dependent information or for performanceissues. We can test these semantics as well as generated or handwritten lan-guage processors against the generic interpreter. Thereby, the interpreter actsas a reference. Then, generated code and handwritten processors should lead tothe same result as specified in the operational semantics.

Transition

/isActivated : BooleanisSelected : Boolean

TransitionBP

onActivated : Boolean

Breakpoint

isEnabled : Boolean

PlaceBP

onToken : Boolean

Place

token : Integer

Net

isActivated = src -> forAll(token > 0) token >= 0

breakpoints

0..*

1

transition

1

place1

0..*snk

0..*src

0..*src

0..*snk

transitions 0..*

1

places0..*

1

Fig. 7. Petri nets metamodel extended for debugging purposes.

Debuggers. Debugging differs from interpretation in two ways: The user isinterested in the internal state of the execution, and the user wants to controlthe execution. With our approach, we can extend operational semantics to offergeneric support for debugging. The internal state of the execution is representedby configurations. In order to provide debugging information, the metamodelfor configurations has to include this information. The introduction of derivedattributes can provide such extra information not needed for interpretation.

Example 4 (Debugging Petri nets). When we debug Petri nets, we want to knowif a transition is currently activated or not. Furthermore, we want to triggerwhich transition fires in the execution step. We can easily extend the meta-model from Fig. 1 to include these features. The new metamodel is shown inFig. 7. For transitions, we introduce a derived attribute isActivated which in-dicates the activation of the transition. Additionally, we introduce an attributeisSelected. Only selected transitions will be fired. Furthermore, we specifybreakpoints. There are two kinds of breakpoints: Transition breakpoints inter-rupt the execution if the refered transition becomes activated or inactivated.Place breakpoints interrupt the execution if the refered place is marked with thespecified number of tokens.

We need to modify the transition relation in two ways: First, the queryisActivated must be expressed in terms of the new attributes. Second, addi-tional relations that interrupt the execution at breakpoints are required. Weomit the result due to space limitations.

In general, the configuration metamodel needs only a few extensions for de-bugging purposes. Usually, the runtime state already provides many of the in-formation needed for debugging. Only a few additions are needed particular

for debugging, e.g. breakpoints or watch epressions. Since debugging affects thecontrol flow of the execution, more changes are needed for the transition rela-tion. Though, parts concerned with basic language constructs will usually stayunchanged.

Implementation. We implemented our approach in the Eclipse Modeling Frame-work [?]. Furthermore, we rely on a QVT Relations engine provided by ikv [?],an industrial partner of our research group. We developed abstract interpretersand debuggers for various kinds of Petri nets, an extended version of the stream-oriented language, and for a scripting language for metamodel adaptation [?].The latter language provides over 50 language concepts. Its operational seman-tics is defined by over 200 relations.

Efficiency of the developed interpreters and debuggers depends basically onthe efficiency of the QVT engine. The engine we use is designed for industrialprojects. Amongst others, it was applied in a project between ikv and the biggestconsumer electronics vendor in Korea in the area of embedded systems. Theengine provides an efficiency which is adequate for prototyping purposes. Forthe metamodel adaptation language, an adaptation script of over 40 adaptationsteps is interpreted in less than a second.

6 Related Work

Translational approaches. Model-to-model transformations are a commonway to define the semantics of a language model by translation into a targetlanguage. Usually, this ends in an executable model, e.g. a program in a gen-eral purpose programming language. For example, the Model Driven Architec-ture [?], the OMG’s standard for MDE, suggests the transformation of platformindependent models into platform specific models. By providing standard meansfor these transformations, QVT forms the center of this approach.

Translational semantics are harmful in a domain-specific context. The cor-responding transformations are specified in terms of the source and the targetlanguage model. While we can expect domain experts to understand the sourcelanguage model, we cannot do so with respect to the target language. Further-more, complicated translations hide the underlying language semantics in thedetails of the target language. Executing the target program, another problemarises. To assist domain experts, error messages and debugging information needto be mapped into the source domain which is a sophisticated task. Thus, transla-tional semantics do not provide an appropriate level of abstraction for prototyingpurposes.

In our approach, we stay in the expert domain to describe the operational se-mantics of the language in terms of its structure. The domain experts understandthese structures and should be able to explain the effects of execution. Further-more, the structural operational semantics description is instantly executable inthe expert domain. This enables us to test the specified behaviour together withthe domain experts. Thus, our approach is well suited for prototyping.

Nevertheless, translational semantics are needed in addition. They allow forthe integration of platform dependent details, can match a particular targetplatform, and provide a higher efficiency.

Semantics description languages. Several approaches address a metamodelbased formalisation of language semantics. All these provide their own descrip-tion means, sometimes a variation or extension of existing modelling languages.Hausmann et al. describe the operational semantics of UML behaviour diagramsin terms of collaboration diagrams and graph transformations [?,?]. Sunye et al.recommend UML action semantics for executable UML models [?]. Furthermore,they suggest activities with action semantics for language modelling. Scheidgenand Fischer follow this suggestion and provide description means for the opera-tional semantics of MOF compliant language models [?].

Other approaches originate in language development frameworks. The AMMAframework integrates Abstract State Machines for the specification of executionsemantics [?]. Muller et al. integrate OCL into an imperative action language [?]to provide semantics description means for the Kermeta framework [?]. In a sim-ilar way, OCL is extended with actions to provide semantics description meansin the Mosaic framework [?].

All these approaches have in common the fact that they use languages par-ticulary designed for semantics description. Users have to learn these languagesin order to use a certain tool. Then, they are restricted to a certain tool, its lan-guage modelling formalism, and a particular way to describe the semantics of theintended language. In contrast, our approach relies only on standard modellingtechniques. Both, MOF and QVT are OMG standards. One goal of the OMGstandards is to provide interoperability between various tools. In a MDE setting,users are accustomed to apply these techniques. With our approach, they canbenefit from language engineering knowledge without switching to a differenttechnology space.

7 Conclusion

Contribution. In this paper, we demonstrated how to define operational se-mantics of a language in a model-driven way. Thereby, only standard modellingtechniques were applied. The abstract syntax of a language as well as runtimeconfigurations were captured in MOF compliant models. The operational seman-tics were defined inductively in a declarative way by means of QVT Relations.Furthermore, we discussed the applications of our approach in the areas of lan-guage prototyping.

Future work. We plan to integrate the work presented in the paper withour existing work on metamodel adaptation and model co-adaptation [?]. Thatwork is concerned with well-defined adaptation steps for metamodels similaryto object-oriented refactoring. Adaptation steps are performed by transforma-tion. Language instances are automatically co-adapted. It provides a first step

Fig. 8. Visual debugger for Petri nets.

to agile model-driven language engineering. Generic support for execution asmentioned in this paper is a second step. To integrate both steps, we need toconsider co-adaptation of semantics. So far, co-adaptation of language instancesonly concerns the syntax. When adapting a metamodel, language instances areco-adapted to comply to the new metamodel. Considering semantics, languageinstances and semantics descriptions need to be co-adapted in a way that pre-serves the meaning of those instances. Furthermore, adaptation of semantics isa topic on its own. Here, we can think of transformations that extend, preserve,or restrict semantics descriptions.

Furthermore, we are working on a combination of operational semanticsand model-based visualisation techniques. This work is joined work with DanielSadilek. The approach allows for the prototyping of graphical interpreters and de-buggers for visual DSMLs. As a technological foundation, we rely on the EclipseModeling Framework and the Graphical Modeling Framework for the Eclipseplatform. As a first result, Fig. 8 shows the screenshot of a prototypical visualdebugger for Petri nets.

Acknowledgement. This work is supported by grants from the DFG (GermanResearch Foundation, Graduiertenkolleg METRIK). The author is grateful toEckhardt Holz, Daniel Sadilek, and Markus Scheidgen for encouraging discussionand helpful suggestions. Daniel Sadilek invented the first versions of the stream-oriented language used as the second example in this paper. Furthermore, theauthor is thankful to Hajo Eichler, Omar Ekine, and Jorg Kiegeland from ikvfor help with the QVT engine.