HAL Id: hal-01231772
https://hal.archives-ouvertes.fr/hal-01231772
Submitted on 20 Nov 2015HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
A transformation-driven approach to automate feedback
verification results
Faiez Zalila, Xavier Crégut, Marc Pantel
To cite this version:
Faiez Zalila, Xavier Crégut, Marc Pantel. A transformation-driven approach to automate feedback verification results. 3rd International Conference On Model and Data Engineering (MEDI 2013), Sep 2013, Amantea, Calabria, Italy. pp. 266-277. �hal-01231772�
O
pen
A
rchive
T
OULOUSE
A
rchive
O
uverte (
OATAO
)
OATAO is an open access repository that collects the work of Toulouse researchers and makes it freely available over the web where possible.
This is an author-deposited version published in : http://oatao.univ-toulouse.fr/ Eprints ID : 12571
The contribution was presented at MEDI 2013 : http://si.deis.unical.it/~cuzzocrea/MEDI2013/
Official URL: http://dx.doi.org/10.1007/978-3-642-41366-7_23
To cite this version : Zalila, Faiez and Crégut, Xavier and Pantel, Marc A
transformation-driven approach to automate feedback verification results. (2013)
In: 3rd International Conference On Model and Data Engineering (MEDI 2013), 25 September 2013 - 27 September 2013 (Amantea, Calabria, Italy).
Any correspondance concerning this service should be sent to the repository administrator: staff-oatao@listes-diff.inp-toulouse.fr
A Transformation-Driven Approach
to Automate Feedback Verification Results
⋆Faiez Zalila, Xavier Cr´egut, and Marc Pantel
Universit´e de Toulouse, IRIT – France {firstname.lastname}@enseeiht.fr
Abstract. The integration of formal verification methods in modeling activities is a key issue to ensure the correctness of complex system design models. In this purpose, the most common approach consists in defining a translational semantics mapping the abstract syntax of the designer ded-icated Domain-Specific Modeling Language (DSML) to a formal verifica-tion dedicated semantic domain in order to reuse the available powerful verification technologies. Formal verification is thus usually achieved us-ing model transformations. However, the verification results are available in the formal domain which significantly impairs their use by the system designer which is usually not an expert of the formal technologies.
In this paper, we introduce a novel approach based on Higher-Order transformations that analyze and instrument the transformation that ex-presses the semantics in order to produce traceability data to automatize the back propagation of verification results to the DSML end-user. Keywords: Domain specific modeling language, Formal verification, Model checking, Translational semantics, Traceability, Verification feed-back, Fiacre.
1
Introduction
Model-Driven Engineering (MDE) provides powerful techniques and tools to define Domain-Specific Modeling Languages (DSMLs) adapted for given user dedicated domains. These techniques rely on the DSML metamodel that de-scribes the main concepts of the domain and their relations. MDE allows system designers (DSML end-users) working closer to the system domain as they will manipulate concepts from the real system.
Model validation and verification (V&V) activities are key features to assess the conformance of the future system to its behavioral requirements. In order to apply them, it is required to introduce an execution semantics for the DSMLs to verify whether built models behave as expected. This one is usually provided as a mapping from the abstract syntax (metamodel) of the DSML to an existing semantic domain, generally a formal verification dedicated language, in order to reuse powerful tools (simulator or model-checker) available for this language [1,2].
⋆ This works was funded by the french Ministry of Industry through the ITEA2 project OPEES and openETCS and the french ANR project GEMOC.
One key issue is that system designers are not supposed to have a strong knowledge on formal languages and associated tools. Thus, the challenge for the
DSML designer is to leverage formal tools so that the system designer does
not need to burden with formal aspects and then to integrate them in tradi-tional Computer Assisted Software Engineering (CASE) tools, like the Eclipse platform.
MDE already provides means to define metamodels (e.g. Ecore tools, Em-phatic) along with static properties (e.g. OCL) and to generate either tex-tual syntactic editors (e.g. xText, EMFText) or graphical editors (e.g. GMF, Spray, Sirius). Additionally, the DSML designer should extend the DSML frame-work with required elements to perform V&V tasks relying on translational se-mantics from the DSML to formal languages (e.g. Petri nets, automata, etc.).
Translational semantics for DSMLs into formal semantic domains allows the use of advanced analysis tools like model-checkers. It introduces the executabil-ity aspect for DSMLs and can provide execution paths in case of verification failures. However, this approach has a strong drawback: the verification results are generated in the formal technical space, whereas DSML end-users are not supposed to have a strong knowledge on formal languages and associated tools. Therefore, these results should be lifted to the user level (i.e. the DSML level) automatically.
The DSML designer does not only provide the translational semantics but must also implement a backward transformation that bring back the formal veri-fication results to the DSML level so that they are understandable by the system designer (DSML end-user). Bringing back formal results to the DSML level can be complex. It is thus mandatory to assist the DSML designer by providing methods and tools to ease the implementation of result back propagation.
In this work, we propose a generic approach to integrate hidden formal verifi-cation through model-checking for a DSML. We rely on the Executable DSML pattern [3] to define all concerns involved in the definition of DSML semantics while its translational semantics is defined using a model-to-model transforma-tion. Then, we define a higher-order transformation (HOT) to manipulate the translational semantics in order to generate the mandatory tools to ensure the back propagation of verification results. We rely on the Fiacre intermediate language [4] to help DSML designers to use formal methods by reducing the semantic gap between DSMLs and formal methods.
To illustrate our proposal, we consider as running example the xSPEM exe-cutable extension of the SPEM process modeling language [5]. It was designed in order to experiment V&V in the TopCased toolkit [6] using an MDE approach. The paper is structured as follows: section 2 presents the Executable DSML pattern illustrated with SPEM [5] and the Fiacre metamodel. Section 3 ex-plains our approach to generate the DSML verification framework. Section 4 presents the overview of the use of the generated DSML verification frame-work by the system designer. Section 5 gives some related frame-work in the domain of user level verification results. Finally, Section 6 concludes and gives some perspectives.
<<import>> <<merge>> DDMM EDMM Event WorkDefinitionEvent StartWD FinishWD TM3 Scenario Trace name : String date : Int Internal : Boolean RuntimeEvent minTime : Int maxTime : Int Process name : String minTime : Int maxTime : Int WorkDefinition linkType : WSType WorkSequence 0 .. * workDefinitions 1 successor 0 .. * workSequences 1 predecessor linkToSuccessor 0 .. * linkToPredecessor 0 .. * 0 .. * traces 0 .. * events 1 workDefinition SDMM notStarted running finished <<enumeration>> ExecutionState linkType : WSType Dynamic_WorkDefiniton 1 workDefinition 0 .. * dynamic_wd <<merge>> <<merge>> startToStart startToFinish finishToStart finishToFinish <<enumeration>> WSType
Fig. 1. Executable DSML pattern applied into the SPEM metamodel
2
The Executable DSML pattern for V&V
When dealing with an executable DSML, the usual metamodel generally does not model the notions manipulated at runtime such as dynamic information or stimuli that make the model evolve. To address this issue, Combemale et al. have proposed the Executable DSML pattern [3]. In the context of formal verification, the pattern is applied both on the source DSML and the formal target DSML to help in leveraging to the DSML side the results obtained on the formal side.
2.1 xSPEM as an Executable DSML
The Executable DSML pattern applied on SPEM metamodel is shown in Figure 1.
The classical DSML metamodel is shown as the Domain Definition Meta-Model (DDMM). It provides the key concepts of the language (representing the considered domain) and their relationships. It is the usual metamodel used to define the modeling language in standardization organisations. It is usually en-dowed with structural constraints. For instance, the SPEM metamodel defines the concepts of Process composed of (1) workDefinitions that model the ac-tivities performed during the process, (2) workSequences that define temporal dependency relations (causality constraints) between activities.
During the execution of a model, additional data are usually mandatory for expressing the execution itself. A first extension, named State Definition Meta-Model (SDMM), stores dynamic data in the form of metatype instances. For ex-ample, each workdefinition is in one of the states: notStarted, running or finished.
The state attribute should be defined in the Dynamic WorkDefinition metatype. The second extension, Event Definition MetaModel (EDMM), reifies the con-crete stimuli of the DSML as subtypes of the common abstract RuntimeEvent metatype. Concrete EDMM events add properties in relation to, and/or rede-fine properties of, events related to the formal semantics to be supported. As an illustration, runtime events for xSPEM include ”start a workdefinition” and ”finish a workdefinition”. Thus, two metatypes StartWD and FinishWD will be defined.
Finally, the Trace Management MetaModel (TM3) allows to define a scenario as a sequence of runtime events usually interleaved with the state of the model between triggered previous and next events. The TM3 is independent of any DSML.
2.2 The Fiacre Formal Language
Fiacre [4] is a french acronym for an Intermediate Format for Embedded
Dis-tributed Components Architectures. It was designed as the target language for model transformations from different DSMLs such as Architecture Analysis and Design Language (AADL), Ladder Diagram (LD), Business Process Execution Language (BEPL) and some UML diagrams (sub-languages).
The Fiacre formal language allows representing both the behavioral and timing aspects of systems, in particular embedded and distributed systems, for formal verification and simulation purposes. Fiacre is built around two notions:
– Processes describe the behavior of sequential components. A process is
de-fined by a set of control states, each associated with a piece of program built from deterministic constructs available in classical programming lan-guages (assignments, conditionals, repetitions, and sequential compositions), non deterministic constructs (non deterministic choice and non deterministic assignments), communication events on ports, and transitions to next state.
– Components describe the composition of processes, possibly in a
hierarchi-cal manner. A component is defined as a parallel composition of instantiated components and/or processes communicating through ports and shared vari-ables. The notion of component also allows restricting the access mode and visibility of shared variables and ports, associating timing constraints with communications, and defining priority between communication events. Verification results are obtained at the formal level and must be leveraged at the DSML level. This feedback is made easier thanks to the Executable DSML pattern [3] applied not only at the DSML level but also at the formal one.
In this work, our aim is to build DSML events out of the Fiacre ones pro-vided by verification failures. We are thus interested only in the Fiacre EDMM. It contains specific events [7]: instances of processes entering or leaving a state, variables changing values, communications through ports and tagged statements occurring in process instances.
3
Generation DSML Verification Framework
Our approach is based on two model-based concepts: 1) traceability and 2) higher-order transformation. It relies on the Atlas Transformation Language (ATL) [8].
3.1 Traceability Mechanism
The model transformation traceability consists in storing a set of relations (also named mappings) between corresponding source and target model elements in order to reuse them to verify and validate software life-cycle.
Several traceability approaches are proposed in the literature [9]. For exam-ple, in [10], authors introduce an approach named embedded traceability. In this latter, the traceability elements are embedded inside the target models. For [11], the traceability information are considered as a model, more precisely as an additional target model of a transformation program. We have chosen the last be-cause it avoids polluting source and target models with traceability information. Traceability information are generated while running the model transformation (Source2Target model transformation) as illustrated in Fig. 2.
<<conforms to>>
Source metamodel
Source model model transformationSource2Target
Target metamodel Target model
Source2Target metamodel
<<conforms to>> <<conforms to>>
Source2Target model
Fig. 2. The traceability mechanism
3.2 Higher-Order Transformation
A higher-order transformation is a model transformation that manipulates other model transformations. It means that the input and/or output models are them-selves model transformations. Fig. 3 gives a technical overview of the applica-tion of a higher-order transformaapplica-tion where both inputs and outputs are model transformations [12]. A first step parses the textual syntax and builds a model conforming to the ATL metamodel. Then, the higher-order transformation (ATL Higher-Order transformation) manipulates the input model and generates an-other transformation model (ATL output model ). It generally adds some in-formation. We use it to easily extend the translational semantics to support traceability data generation. Finally, the textual representation (ATL output transformation) was generated from the generated ATL model.
ATL input transformation ATL input model ATL output model ATL output transformation ATL Higher-order transformation ATL Metamodel TCS Injector source model target model TCS Extractor conforms to conforms to
Fig. 3.An overview of Higher-Order transformation
3.3 The Approach Architecture
The figure 4 shows the overall organization of our approach. It explains different steps performed by the DSML designer in order to prepare the verification framework used by the DSML end-user. It also introduces the capability of our approach to simplify the DSML designer task in order to facilitate the integration of a verification framework for a new DSML.
Extending the DSML with runtime information DSML Designer Define a translational semantics EDMM+SDMM+TM3 runtime extensions DSML semantics Domain Definition MetaModel DDMM DSML Designer DSML2Fiacre transformation Step 1
Step 2 Higher-OrderDSML2Fiacre
transformation DSML2Fiacre withTraces transformation FiacreScenario 2DSMLScenario Transformation DSML2Fiacre MetaModel Trace EDMM+SDMM+TM3 runtime extensions Fiacre semantics Domain Definition MetaModel DDMM source metamodel target metamodel Verification work-flow target metamodel target metamodel source metamodel source metamodel source metamodels target metamodel source metamodel
Step 3 DSLML verification framework generation
Fig. 4. Scheme of different steps to generate the DSML verification framework
Step 1. The DSML designer extends the DSML abstract syntax (DDMM) with
the runtime information conforming to the Executable DSML pattern. It consists in defining different events (EDMM) and snapshots (SDMM) to be captured.
Step 2. The DSML designer defines the translational semantics (DSML2Fiacre
transformation) from DSML DDMM into the formal Fiacre language. In our case, it is defined as a model-to-model transformation implemented with ATL.
In our example, the translational semantics consists in transforming a SPEM model into a Fiacre specification. Here are some rationale behind this trans-lational semantics. Each workdefinition is translated into one Fiacre process. Such a process contains three states (notStarted, running and finished ) and two transitions (from notStarted to running and then from running to finished ). The transitions are guarded (conditional statement) according to the dependencies
defined between workdefinitions (the previous activities must have reached the expected state). As a Fiacre process cannot inspect the current state of other processes, the process takes as argument an array containing the state of each workdefinition (derived from the xSPEM SDMM). Each transition includes an assignment to update variables which store the state of the activities.
In addition, the transformation must integrate the information to capture the DSML events. Fiacre allows to annotate the Fiacre model with tag state-ments ”#ident”. So, the DSML designer must extend the translational semantics with tag statements in order to capture the corresponding event in the DSML scenario.
The listing 1.1 shows an application of this extension for the StartWD event which is a workdefinition event. A tag declaration named ”StartWD” is de-fined (lines 12-13) in order to capture the StartWD event dede-fined in the SPEM
EDMM. A tag statement is initialized with the corresponding tag declaration
(lines 9-10). This statement is inserted in the first Fiacre transition (from not-Started ... to running) just before the assignment which updates the state vari-able of the activity (lines 6-7). These elements are also defined for the FinishWD event. 1 WorkDefinition2Fiacre { 2 from 3 workdefinition : SpemMetaModel!WorkDefinition 4 to 5 ...
6 sequence statement start: FiacreMetaModel!StatementSequence(
7 statements <− Sequence{start tag statement, assignment is started}
8 ),
9 start tag statement : FiacreMetaModel!TaggedStatement(
10 tag <− tag start wd
11 ),
12 tag start wd: FiacreMetaModel!TagDeclaration(
13 name <− ’StartWD’
14 )
15 ...
Listing 1.1. Extending the translational semantics with tagged statements
Step 3. The DSML2Fiacre transformation defined by the DSML designer
pro-vides the proposed translational semantics extended with bindings which al-low implementing DSML events. Based on this model-to-model transformation, a higher-order transformation (Higher-Order DSML2Fiacre transformation) al-lows to generate different elements to extend the DSML verification framework. Let’s detail the generated elements.
DSML2Fiacre Metamodel : It is the traceability metamodel. It defines a
meta-class for each traceable element.
Definition 1. A traceable element is a DSML element extended at least with
SPEM DDMM (subset) Fiacre DDMM (subset) SPEM2Fiacre metamodel InstanceDeclaration
TagDeclaration WorkDefinition2Fiacre WorkDefinition instance
tag
workdefinition SPEM2Fiacre
0..* traces
Fig. 5. SPEM2Fiacre trace metamodel
The generated meta-class contains references to record the traceable element (workdefinition), the tag declaration (tag) and its corresponding process instance (instance). In the case of xSPEM, only WorkDefinition is a traceable element. The generated trace metamodel, SPEM2Fiacre, is shown in Figure 5.
Therefore, a meta-class named WorkDefinition2Fiacre was generated to store the workdefinition and the corresponding tag event containing the tag declara-tion and its instance. The traceability metamodel is generated in order to be referenced by the translational semantics enriched with traceability rules.
DSML2FiacrePlusTraces Transformation : It adds traceability rules to the
translational semantics proposed in the DSML2Fiacre transformation. Traceabil-ity elements are created into the rule which translates the traceable element.
Typically, the traceability information consists in saving a tag event informa-tion (Fiacre side) and the traceable element (DSML side).
Listing 1.2 introduces elements into the WorkDefinition2Fiacre rule (line 1). According to the generated DSML2Fiacre metamodel, this rule produces a target pattern element (lines 6-9) to create WorkDefinition2Fiacre instance (line 6) with the tag declaration (line 7) and the generated Fiacre process instance (line 8). Saving traceability source information in ATL consists in adding a single-statement imperative block to initialize the source element, workdefinition, with the traceable element (lines 10-13).
1 rule WorkDefinition2Fiacre{
2 from
3 workdefinition : SpemMetaModel!WorkDefinition
4 to
5 ...
6 start trace : SpemMetaModel2FiacreMetaModel!WorkDefinition2Fiacre (
7 tag <− tag start wd,
8 instance <− process instance
9 )
10 do {
11 start trace .refSetValue (’ workdefinition ’, workdefinition );
12 ...
13 }
14 ...
FiacreTM32SpemTM3 Transformation : It defines the backward trans-formation which allows to back propagate the Fiacre formal scenario into the
DSML scenario. Listing 1.3 shows some elements in this ATL transformation.
It defines an ATL helper (lines 1-5) for each traceable element (WorkDefini-tion in this case) to request from a tag event the corresponding trace element (WorkDefinition2Fiacre). An ATL rule (lines 7-14) is defined for each DSML event to generate from a tag event (lines 8-10) using the trace element a corre-sponding DSML event (lines 11-13).
1 helper context FiacreSemanticsMetaModel!”fiacreSemantics::fiacreEDMM::TagEvent”
2 def: getTraceabilityElement() :
3 Spem2FiacreMetaModel!WorkDefinition2Fiacre =
4 Spem2FiacreMetaModel!WorkDefinition2Fiacre.allInstances()
5 −>select(trace|trace .tag=self.tag and trace.instance=self . instance)−>first ();
6 7 rule TagEvent2StartEvent{ 8 from fcr event : 9 FiacreSemanticsMetaModel!”fiacreSemantics::fiacreEDMM::TagEvent” 10 ( fcr event .tag.name=’StartWD’) 11 to spem event: 12 SpemSemanticsMetaModel!”spemSemantics::spemEDMM::StartWD”( 13 workdefinition <− fcr event.getTraceabilityElement().workdefinition) 14 }
Listing 1.3. A subset of the backward transformation
4
The Use of the DSML Verification Framework
Once the previous steps have been performed, the DSML verification framework is generated. Figure 6 shows an overview of the generated DSML verification framework connected to both modeling and formal levels.
This framework allows the DSML end-user to define models (xSPEM model ) conforming to the DSML abstract syntax (xSPEM DDMM) and to verify be-havioral properties while hiding formal methods and tools.
The defined model is translated with SPEM2FiacrewithTraces transforma-tion into a Fiacre program (fiacre model ). Additransforma-tionally, a traceability model (spem2fiacre model) is also generated which saves mappings between both models.
Next, the existing tools around the Fiacre language (Frac compiler1 and
Selt2, the Tina [13] model-checker) perform the formal verification and
gen-erate the formal results (counter-example in case of failure). In the same spirit defined in this paper, we have transformed these formal results at the Petri nets level to more abstract results at the Fiacre level (fiacre scenario) [14]. Finally, the backward transformation (FiacreScenario2SPEMScenario transformation) is performed in order to generate the expected scenario (xSPEM scenario).
1 http://projects.laas.fr/fiacre/manuals/frac.html
DSML end-user - build models - Verify properties - Obtain user-friendly results ---<<uses>> <<uses>> source model source model source model xSPEM model fiacre model target model target model spem2fiacre model target model fiacre scenario xSPEM scenario SPEM2Fiacre withTraces transformation del od FiacreScenario 2SPEMScenario Transformation Entité formal verification tools code generators and compilers formal counter-example formal scenario 2 fiacre scenario <<defines>> <<get>>
End-user level DSML verification
framework formal level
Fig. 6.The use of the generated DSML verification framework
5
Related Work
The problem of integrating formal verification into the design of DSMLs has been widely addressed by the MDE community. However, the analysis feedback at the DSML level problem is typically either ignored or resolved by defining ad-hoc or hard-coded solutions. For example, in [15], authors propose an approach, named Metaviz, based on the real-time systems specification and validation tool set IFx-OMEGA. It is designed to ease the visualization of simulation trace. The goal is to assist the user in the Interactive Simulation task by refining this step with a diagnosis process built around visualization concepts. It consists in feeding back verification results at OMEGA level. Thus, It can be considered as an ad-hoc approach.
On the other hand, a few number of works handling the feedback with general solutions exists in the literature.
Heged¨us et al. [16] propose a technique for the back propagation of
simula-tion traces based on change-driven model transformasimula-tions from traces generated by SAL model checking framework to the specific animator named BPEL Ani-mation Controller. So, they define a change-driven model transforAni-mation which consumes changes of the Petri nets simulation run and produces a BPEL pro-cess execution using traceability information generated while running the trans-lational semantics defined previously. In this case, after defining the runtime extension for both levels (BPEL and Petri nets) and the translational seman-tics, the DSML designer is invited to define 1) a change command metamodel for Petri nets and BPEL and also 2) the back-ward change-driven transformation. In our approach, we try to generate automatically the mandatory data required to feedback verification results without introducing additional information.
In [17], authors introduce an algorithm requiring the DSML’s semantics to be defined formally, and a relation R to be defined between states of the DSML and states of the target language. The DSML designer must provide as input a natural-number bound n, which estimates a difference of granularity between
the semantics of the DSML and the semantics of the target language. However, we don’t think that DSML designer, for who it is difficult to use formal methods and verification, can define this important information to feedback verification results.
The most advanced work about back propagation problem is defined in [18]. A Triple Graphical Pattern (TGP) is defined to introduce how a result generated in the formal domain can be shown in the DSML level. TGP is defined to resolve the problem of to-1 restriction on back propagation. It allows to handle the 1-to-n case which means that several events in the formal verification results may correspond to one event in the DSML level and m-to-n case which considers mappings as a set of events in the both levels. These cases occur due to the mismatch between trace granularity between the DSML and formal levels caused by the semantic gap between both levels. In our case, the use of the intermediate language Fiacre allows to reduce this semantic gap and therefore the 1-to-n and m-to-n mapping are usually not occurring. Also, the DSML designer does not need to extend the translational semantics with any additional information to ensure the back-annotation task. Finally, as a technical viewpoint, defining a Triple Graph Transformation Systems (TGTS) is typically more complicate task than an ATL transformation.
6
Conclusion
In this paper, we have presented an approach to integrate formal tools into the verification of DSMLs. It consists in generating a DSML verification framework containing the necessary elements to map the DSML abstract syntax into a semantic domain and also to feed verification results — generated in the formal level — back to the DSML level.
Our solution is a generic tool implementing a higher-order transformation that requires a translational semantics defined between the DSML and the
Fiacre intermediate language. The translational semantics is extended with
tagged statements which trigger DSML events. This additional information al-lows identifying which elements are concerned with the back propagation task. Therefore, all required elements are generated automatically. It has been illus-trated on xSPEM as DSML and Fiacre as the formal language.
This approach has been designed for domain specific languages. It is currently being experimented for several significantly different DSMLs like Architecture Analysis and Design Language (AADL), Business Process Engineering Language (BPEL) and Ladder Diagram (LD).
References
1. Merilinna, J., P¨arssinen, J.: Verification and validation in the context of domain-specific modelling. In: Proceedings of the 10th Workshop on Domain-Specific Mod-eling, DSM 2010, pp. 9:1–9:6 (2010)
2. Harel, D., Rumpe, B.: Meaningful Modeling: What’s the Semantics of “Semantics”? Computer 37(10), 64–72 (2004)
3. Combemale, B., Cr´egut, X., Pantel, M.: A Design Pattern to Build Executable DSMLs and associated V&V tools (short paper). In: Asia-Pacific Software Engi-neering Conference (APSEC), Hong Kong, China (2012)
4. Berthomieu, B., Bodeveix, J.-P., Filali, M., Farail, P., Gaufillet, P., Garavel, H., Lang, F.: FIACRE: an Intermediate Language for Model Verification in the top-cased Environment. In: ERTS 2008 (2008)
5. Software & Systems Process Engineering Metamodel (SPEM) 2.0, Object Manage-ment Group (October 2007)
6. Farail, P., Gaufillet, P., Canals, A., Camus, C.L., Sciamma, D., Michel, P., Cr´egut, X., Pantel, M.: The TOPCASED project: A Toolkit in OPen source for Critical Aeronautic SystEms Design. In: Embedded Real Time Software (ERTS 2006), Toulouse, January 25-27 (2006)
7. Abid, N., Dal Zilio, S.: Real-time Extensions for the Fiacre modeling language (2010), http://automata.rwth--aachen.de/movep2010/index.php?page=about 8. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Bruel, J.-M. (ed.)
MoDELS 2005. LNCS, vol. 3844, pp. 128–138. Springer, Heidelberg (2006)
9. Galvao, I., Goknil, A.: Survey of traceability approaches in model-driven engi-neering. In: 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC), p. 313 (October 2007)
10. Kolovos, D.S., Paige, R.F., Polack, F.A.C.: Merging models with the epsilon merging language (EML). In: Wang, J., Whittle, J., Harel, D., Reggio, G. (eds.) MoDELS 2006. LNCS, vol. 4199, pp. 215–229. Springer, Heidelberg (2006)
11. Jouault, F.: Loosely coupled traceability for ATL. In: Proceedings of the European Conference on Model Driven Architecture (ECMDA) Workshop on Traceability (2005)
12. Tisi, M., Jouault, F., Fraternali, P., Ceri, S., B´ezivin, J.: On the use of higher-order model transformations. In: Paige, R.F., Hartman, A., Rensink, A. (eds.) ECMDA-FA 2009. LNCS, vol. 5562, pp. 18–33. Springer, Heidelberg (2009) 13. Berthomieu, B., Ribet, P.-O., Vernadat, F.: The tool TINA – construction of
ab-stract state spaces for Petri nets and time Petri nets. Int. Journal of Production Research 42(14), 2741–2756 (2004)
14. Zalila, F., Cr´egut, X., Pantel, M.: Verification results feedback for FIACRE in-termediate language. In: Conf´erence en Ing´enierie du Logiciel, CIEL (June 2012), http://gpl2012.irisa.fr/?q=node/31
15. Aboussoror, E.A., Ober, I., Ober, I.: Seeing errors: model driven simulation trace visualization. In: France, R.B., Kazmeier, J., Breu, R., Atkinson, C. (eds.) MOD-ELS 2012. LNCS, vol. 7590, pp. 480–496. Springer, Heidelberg (2012)
16. Heged¨us, ´A., Bergmann, G., R´ath, I., Varr´o, D.: Back-annotation of simulation traces with change-driven model transformations. In: SEFM 2010, pp. 145–155 (2010)
17. Combemale, B., Gonnord, L., Rusu, V.: A generic tool for tracing executions back to a DSML’s operational semantics. In: France, R.B., Kuester, J.M., Bordbar, B., Paige, R.F. (eds.) ECMFA 2011. LNCS, vol. 6698, pp. 35–51. Springer, Heidelberg (2011)
18. Guerra, E., de Lara, J., Malizia, A., D´ıaz, P.: Supporting user-oriented analysis for multi-view domain-specific visual languages. Information and Software Tech-nology 51(4), 769–784 (2009)
