Transformations play a key role in software engineering. Although there exist satisable solutions of automated transformations of models to text, the same cannot be said about transformations of models to models. This area is still in phase of research and exploring of possibilities [1].

According to the approaches of present implemented in several CASE tools, every model transformation requires application of the corresponding transformation rule with suitable parameters [3,4,6,13] Unfortunately, as mentioned in [4], this approach has one big disadvantage, which is a low reusability. For every transformation that has no rule dened, it is necessary to either apply a composition of other rules, or dene a new transformation rule. In this paper, we introduce transformation engine named SBAT (STRIPS Based Transformation Engine) that does not require such steps.

There are several ways how to dene model transformation. In this paper, we introduce the denition presented in [5] and cited by [8]:

A transformation is the automatic generation of a target model from a source model, according to a transformation denition. A transformation denition is a set of transformation rules that together describe how a model in the source language can be transformed into a model in the target language. A transformation rule is a description of how one or more constructs in the source language can be transformed into one or more constructs in the target language.

Publication [8] describes two criteria of classication of model transformations.

The rst one is a dierence of abstraction level of source and target models: In this paper, we focus more closely on refactoring.

There exist several ways how to dene refactoring. The denition presented in [7] says that refactoring is an improvement of software system without changing its behavior. In other words, for the same input, the refactored software must return the same output as the original software. Detail information on refactoring is available in [2].

The idea of complex refactoring as composition of nite primitive (atomic) refactorings was rst published in [10], where formal denition of C++ code refactoring was discussed, and later in [12], where it was demonstrated on refactoring of UML models. We have used the same idea to construct the SBAT transformation engine.

Technical report [9] denes STRIPS as following: STRIPS (STanford Research Institute Problem Solver) belongs to the class of problem solvers that search a space of world models to nd one in which a given goal is achieved. For any world model, we assume there exists a set of applicable operators each of which transforms the world model to some other world model. The task of the problem solver is to nd some composition of operators that transforms a given initial world model into one that satises some particular goal condition.

The STRIPS language is based on the calculus of rst-order predicate logic.

Formally, the STRIPS problem can be expressed by the following denitions: Denition 1. STRIPS problem is an ordered triple (I, O, G), where I is an initial state, O is a set of operators, and G is a goal state condition. Denition 2. Operator o (x) is dened as an ordered triple(P, A, D), whereP = (x) is an application condition, A = [A 1 (x) , . . . , A l (x)] is a set of formulas which become true after operator application, D = [D 1 (x) , . . . D m (x)] is a set of formulas which become false after operator application, x = (x 1 , . . . x n ) are free variables contained in formulas

A goal is to nd such list of operators applications, which cause transition for initial state to the state satisfying the goal state condition. More formally: Denition 4. State s m is a solution of problem (I, O, G), if there exists a list of operators applications o 1 h 1 , . . . , o m h m , where h i are vectors of constants, m ∈ N, and:

Resulting from the facts on present state model transformation discussed in the introduction of this paper, we have decided to design a new transformation engine fullling the following requirements:

1. The engine will support model transformations such as refactoring.

2. The input of transformation process will be the source model and conditions of a target model.

3. The output of transformation process will be a target model, or information that the source model cannot be transformed to any model fullling the input conditions.

4. The source model and the target model will be consistent in light of behavior of modeled system. 5. The transformation process will be fully automatized, without need to specify transformation rules on input.

6. The engine will be universal and suciently reusable for wide scale of object models.

In this paper, formal denition of object model is based on simplied metamodel of UML 2.0 class diagrams, in detail described in [11]. Because of intended generality, we do not focus on implementation details, such as method parameters and bodies, access mode of class members, etc.

where Attr (y) and M eth (y) are sets of attributes and methods respectively of class y,

where super (y) means a superclass of y,

where type (y) means a type of y,

where lambda-expression Λ contains message sending o u, where o is an instance of class w.

The following conditions must be fullled: in the class hierarchy, each attribute appears at most once, so (6) each attribute is of some type, so

each attribute is of at most one type and each method has at most one return value type, so

Each model transformation requires answers to the following questions [8]:

1. What needs to be transformed?

To nd answers, we have to formulate the transformation problem and set the principle of its solution. This can be done by several ways, we have decided to apply the STRIPS planning.

Let's assume any nite subset B of object universal, containing elements of all possible model states. To formulate STRIPS problem (I, O, G) for model transformation, we must describe the model states and transformation rules using rst-order predicate logic calculus. For this purpose, we dene predicates shown in table 1

attribute a is of type

A goal state condition G is dened by the formula that is true in any goal state.

The set of operators O is dened identically for each particular problem, because it represents a set of primitive refactorings. The complete denition of the operator set is described in table 3 in appendix.

The goal state condition is the following: G =inM odel (Element) ∧ attrInClass (name, Element) ∧ attrInClass (owner, Element) ∧ superClass (Element, F ile) ∧ superClass (Element, F odler) (10) The STRIPS planner reaches the goal state by application of satisable operators (see table 2).

A class model in UML notation corresponding to the goal state is shown in g. 2.

In this paper we have introduced SBAT transformation engine based on STRIPS planning system. This engine automates refactoring of the given source model to a target model fullling the input condition.

The main asset of SBAT engine for practice is a contribution to an improvement of automation of object model transformations, which consequently would implicate saved human resources for software projects. Then, these resources could be allocated for example on software debugging or testing tasks, rather than on model transformation ones. Another asset should be a theoretical background for research activities in the area of model transformations.