This position paper, investigates a way to improve the reusability of legacy tools in speci c contexts (de ned by speci c metamodels). The approach is based on a dedicated language for co-evolution, called Modif. Its associated process involves two model migrations. The rst one (Migration), allows to put data under the scope of a legacy tool. The second one (Reverse Migration), allows to put the legacy tool's output back into the original speci c context. The approach is generalized by introducing the notion of dependency graph. It speci es the relations between the legacy tool's input and the legacy tool's output. The dependency graph is then used to address some complexities of the Reverse Migration. The improvement is illustrated by the reuse of a attener tool de ned on a speci c metamodel of FSM ( nite state machines).
Reuse is the act of using an asset in di erent systems [
The reuse brings up some di culties with it; for example, when a designer is de ning speci c functions for the DSML, he frequently notices that the functions are already provided by a legacy tool. Nevertheless, they were developed for a variant of his metamodel.
In this regard, the aim of reusing, raises two questions: how the DSML model can be adapted to be conform to the legacy tool's metamodel? And how the output of the legacy tool can be adapted in return to the DSML context?
Modif [
M1 has to be adapted to be M2, with the purpose of match the legacy tool
context. The adaptation is achieved by the Modif's Adaptation step. In
accordance with the principles of co-evolution between metamodels and models,
Adaptation performs Refactoring operations at the metamodel level and Migration at
the model level [
The process compound of Adaptation (M1 to M2), Tool and Contextualization (M3 to M4) correspond to the Tool reuse.
It is important to notice that a common operation performed during
Migration is the deletion of unnecessary information (slicing operation [
Adaptation
DSML context
Legacy tool context
MM conforms to
M1 conforms to
Refactoring Migration conforms to
MM ’ conforms to M2 input output Tool Contextualization
M4
Reverse Migration
M3
In this paper, we aim at improving the Modif's keys mechanism [
This paper is organized as follows. The next section presents the background of this work and some motivations to improve the keys mechanism, in order to make a correct contextualization. It takes into account the links between Migration and Reverse Migration. Then, we present the proposition to assist the user in the process of putting back the legacy tool's output into his DSML context. We nally conclude the paper and give some perspectives.
In a simple example we show the tool reuse process and why Reverse Migration is a key problem.
Adaptation Modif's Adaptation is based on co-evolution operators (e.g.
update, delete) like classically proposed by [
Contextualization Modif [
This is possible by applying the concept of relational natural join of relational databases. The relationships between instances are also built reusing the keys information. Thus, instances of the legacy tool's output are reconnected to the instances that have been recovered. New instances cannot be reconnected to other instances, and an instance of M3 can be reconnected to only one existing instance of M1.
To illustrate the approach and its limits, a case study of simple FSM is presented: { MM de nes the concepts of State, Transition, Action (associated to states) and Event (associated to transition). A state can contain other states inside it (hierarchical nite state machine); { MM' is the metamodel of input data expected by a attener legacy tool, it is similar to MM, except that it does not contain actions; { M1 (Figure 2) is a state-machine model conforms to MM. It is composed of a super-state with two actions, a substate with one action, a substate without actions, and two transitions; { M2 (Figure 2) is an adaptation of M1, in which actions are deleted; { Tool is a attener legacy tool that removes hierarchy by producing atomic states (aggregation of super-states and states). For each super-state, all substates are renamed and itself is removed. The renaming is done by concatenating the super-state's name and the substate's name; { M3 (Figure 2) depicts the legacy tool's output. Actions have to be reintegrated to it; { M4 (Figure 2) illustrates the result of the Reverse Migration by using the keys mechanism. The action run1 is recovered and reconnected to running nominal. The actions start and stop are lost because they are associated to the super-state running that does not exist after tool application. We present a proposition to enhance Modif and its keys mechanism, by introducing the notion of dependency graph. A dependency graph is considered a speci cation of the legacy tool. It speci es the dependencies between each instance of the legacy tool's output and a set of instances of the legacy tool's input. The set is compound of the instances that are involved in the creation or modi cation of the legacy tool's input instance. All types of instances can participate in the creation or update of other instances.
In this paper, the dependency graph is obtained by instrumenting the legacy tool. We log each concept of the legacy tool's output and the set of concepts of the legacy tool's input that participates in its creation or modi cation.
For the case study of FSM, Reverse Migration is applied to M3 using the keys mechanism, in order to recover deleted actions. Moreover, we also use the information given by the dependency graph to reconnect more actions. For this example, the relations between input and output of the legacy tool are shown in Figure 3. Now, the challenge is how to use this information to keep the recovered instances and to reconnect them.
state transition event
output running nominal running degraged running nominal running degraded running degraded running nominal nok ok
input nominal
Reverse Migration is parameterized by Adaptation (initial model and keys), dependency graph (tool behavior) and legacy tool's output. From those parameters, the generated code can be executed to get a contextualized nal model.
The process performed by the generated code to produce the nal model is: { to make an identical copy of each instance of the tool's output, taking into account its attributes and its references; { to use the keys to identify the deleted instances; { to recover the links to deleted instances and lter them by type, using the information provided by the dependency graph. The lter allows to recover instances of the appropriate type. We consider that an instance may be created from only instances of the same type (e.g. states are created from states); { to o er an extension point in which the user can specialize the by default behavior by de ning its customized behavior. If there is not customized behavior, only by default behavior is executed. 3.2
Experimentation The approach is experimented with the case study of attening nite state machines.
The following is the by default behavior proposed to reconnect each recovered action: R1 If its related state in M1 still exists in M3; the action is automatically connected to it; R2 If the state no longer exists in M3, but another states of M1 are related to it and they still exist; then, the action is connected to all of them; R3 If the state no longer exists in M3 neither the state related to it; then, the action is not connected to any state.
An excerpt of the code generated by Modif is shown in Listing 1.1. function is the main function, it takes as parameters the legacy tool output M3model, the dependency graph dicoKeys (it contains also the keys) and the initial model M1model).
Listing 1.1. Generated main class for the state machine example public c l a s s R e v e r s e M i g r a t i o n f m i g r a t i o n (new D e f a u l t B e h a v i o r ( ) ) ; m i g r a t i o n (new CustomizedBehavior ( ) ) ; // Reverse Migration f i n a l void f u n c t i o n (M3 M3model , Key dicoKeys , M1 M1model ) f for (M3. S t a t e s t a t e : M 3 S t a t e s L i s t ) f // r e l a t e d e n t r y a c t i o n s o f an s t a t e r e l a t e d E n t r y A c t i o n s=g e t R e l a t e d E n t r y A c t i o n s ( s t a t e , dicoKeys , M1model ) ; // r e l a t e d e x i t a c t i o n s o f an s t a t e r e l a t e d E x i t A c t i o n s=g e t R e l a t e d E n t r y A c t i o n s ( s t a t e , dicoKeys , M1model ) ; for (M1. S t a t e r e l a t e d : r e l a t e d S t a t e s ) f // by d e f a u l t b e h a v i o r b yD e fa ul t . connectEntryAction ( s t a t e , r e l a t e d E n t r y A c t i o n s ) ; b yD e fa ul t . c o n n e c t E x i t A c t i o n ( s t a t e , r e l a t e d E x i t A c t i o n s ) ; // customized b e h a v i o r customized . connectEntryAction ( s t a t e , r e l a t e d E n t r y A c t i o n s ) ;
Listing 1.2 shows the functions connectEntryAction and connectExitAction. They are responsible for reconnect entry and exit actions to the states, taking into account the information gathered from the dependency graph. These functions execute the behavior de ned in R1, R2 and R3.
If the designer does not agree the by default behavior, he can specialize the code by integrating his requirements. An example of the customized behavior de ned by an user is (Listing 1.3): D1 If the recovered action is an entry one, it is reconnected to only initial states (the attribute initial is set to true): it is an adaptation of R1; g g D2 If the action is an exit one, it is reconnected to all states: it was already de ned by R2.
Listing 1.2. By default behavior for the state machine example public c l a s s D e f a u l t B e h a v i o r implements M i g r a t i o n f // Function t o reconnect e n t r y a c t i o n s public void co nnec tEnt ryA ctio n
(M3. S t a t e s t a t e , E l i s t <M1. Action> r e l a t e d E n t r y A c t i o n s )f // Function t o reconnect e x i t a c t i o n s public void c o n n e c t E x i t A c t i o n
(M3. S t a t e s t a t e , E l i s t <M1. Action> r e l a t e d E n t r y A c t i o n s )f
Listing 1.3. Customized behavior for the state machine example public c l a s s CustomizedBehavior extends D e f a u l t B e h a v i o r f . . . public void co nnec tEnt ryA ctio n
( S t a t e s t a t e , ArrayList <Action> r e l a t e d E n t r y A c t i o n s )f i f ( s t a t e . i s I n i ( ) ) f for ( Action a c t i o n : r e l a t e d E n t r y A c t i o n s ) f
s t a t e . s e t E n t r y ( a c t i o n ) ;
The nal model obtained by following the by default behavior and then the customized behavior is presented in Figure 6. All actions are recovered and reconnected. run1 still related to running nominal. start is deleted from running degraded because it is not an initial state. stop still is connected to all states.
This approach allows to keep at Reverse Migration, the DSML instances deleted during Migration. Contrary to the result obtained by using only the keys mechanism, the dependency graph allows to reconnect all actions without lost. Even if the legacy tool performs creation. 4
In this paper, we present an approach to facilitate the legacy tool's reuse process. In particular, it improves the Reverse Migration for legacy tool's reuse by means of a dependency graph. The dependency graph provides a speci cation of the legacy tool to be reused. It enables to recover DSML instances deleted before using the legacy tool and to reintegrate them to its original DSML context.
Migration is metamodel dependent only; Reverse Migration is metamodel dependent, tool's behavior dependent, Migration dependent and original model dependent.
We are now working on the formalization of Migration and Reverese Migration. The approach will be experimented by reusing some legacy tools in the context of video transmission and coding in MPSoC.