Section: New Results
Methods and technology
The Gaspard2 environment consists of several conception flows composed of models corresponding to various system viewpoints and defined at different levels of abstraction. Transformations are used to go from one model to an other, i.e. from one level of abstraction to another. Developing and maintaining such transformations is a complex task requiring, like other engineering process, tools to document and to ease the development. Actually, transformation world lakes of such tools, and also of a "standard" to document and represent the intent of a transformation.
In the same way that UML help to develop and to document software by representing them graphically, we propose a graphical representation of transformations. We propose to focus on the “what” (what should be transformed) rather than the “how” (how implement the transformation). In other terms, we suggest to extract the intention of the transformation from the implementation details. Since years, modeling activities have been mainly supported by UML-like modeler tools and then, visual notation has become more familiar.
Our proposition relies on a graphical representation of transformation model that seems to be the best abstraction to focus on the purpose of the transformation independently from the implementation details.
We have developed the Transformation Modeling Language TrML. In this modeling language, we gather the core features that we consider mandatory to represent transformations. We provide the corresponding UML profile that makes it portable on any UML tool. TrML is not associated to a transformation engine but is defined in a metamodel, making possible to transform a TrML transformation to a particular engine representation.
Transformations aim to be automatically executed. We thus provide a transformation engine for TrML transformation by building TrML on top of an existing transformation engine, ATL. For this purpose, we adopt the bootstrap mechanism allowing to write a transformation from TrML to the model associated to the ATL engine.
We are currently thinking on building TrML on top of MoMoTE. Two ways can be explored either a code generation to Java or an abstraction of the MoMoTE concepts in a metamodel.
Writing transformation rules is a complex task due to navigation constraints. Relaxing these constraints for the transformation time eases the rules conception. It may also be necessary to add features into domain metamodels in order to ease development of tools build around this metamodel, or to ease the transformation rule development. However, these features additions as well as the relaxation of the navigation constraints must be contained in a well defined context in order to authorize exchange of models between tools manipulating several variants of the same domain metamodel. This implies two objectives: modifying a domain metamodel in order to ease the manipulation of the corresponding models and allowing the exchange of models between tools using or constructed upon these adapted metamodels and thus without model transformation.
The exchange of models remains possible as long as the metamodels adaptation is constrained in order not to change the nature of this model but to ease its manipulation. In this context, we have introduced the concept of morph that corresponds to a variant of the original domain metamodel and the concept of gene that specifies these variations. These two notions allow variation without altering the way instances are defined and saved. Each morph provides functionalities that are adapted to the use of this morph. A model, compliant to one morph can be imported by any tools based on morphs of the original domain metamodel. Thus, tools based on morph of a same domain metamodel become interoperable.
The objective of the synchronous modeling of data-intensive computations is to propose, on the one hand, a link between analysis and compilation techniques of data-parallel applications, and on the other hand, analysis and verification techniques of synchronous data-flow and automata-based languages.
With the code generated automatically via the transformation rules implemented in Gaspard2, first examples of validation have been carried out, which include safe array assignment check, deadlock analysis, and functional simulation. The first one helps to find some array assignment problems in the original design, for instance array multiple writing, array partial initialization. The second one involves a compiler-level deadlock analysis, which is not always obvious to detect in the original graphical design. The last one allows the observation the system behavior at the execution period. These validation methods provide Gaspard2 users with a first software verification phase before implementation.
This work is done in collaboration with Eric Rutten from the Pop-Art team-project at INRIA Rhône-Alpes in Grenoble.
The European Railway Traffic Management System (ERTMS) is a complex railway signaling system featuring hundreds of functional requirements, many of them being safety-critical. To ensure an efficient functional verification of the system, a powerful test specification methodology is needed. We proposed then, a model-based methodology for the test of the ERTMS system.
This methodology consists in capturing the textual requirements by a more formal model and in the automatic generation of test scenarios. As modeling languages, we have used SysML extended with MARTE annotations. Several SysML diagrams were used and adapted to achieve the goal of the test process. The requirement diagram captures the textual specifications and we have chosen the activity diagram as the test model. Test scenarios are specified by sequence diagrams which result from the transformation of activity diagrams [Oops!] [Oops!] . The automation of the test generation process has several benefits especially for the testers in term of time saving and cost decreasing.
Our future work aims at improving the technique and its tool support. We plan to improve the transformation rules to generate several test scenarios. We intend to further investigate the execution of test cases, especially finding a format for the scenarios supported by the ERTMS railway simulator. Indeed the cover of the scenarios can be measured only after their execution, it is thus necessary to be able to simulate the scenarios.