ACCIDENTES DE TRABAJO CON BAJA. PARTE DEL CUERPO LESIONADA

Refactory1 _{[RSA10, Rei10] is a tool for generic model refactoring developed at Technische Uni-}

versit¨at Dresden. It provides genericity for modifications by first specifying the abstract steps required to perform a refactoring independet of a concrete type of model and then mapping this specification to individual elements of a particular metamodel.

For example, Extract Super Class for UML models is specified as a mapping to UML of a generic refactoring ExtractX. ExtractX specifies that there are a number of “extractees”, an original container, a new container and a so called “container container”, which is the parent of both the original and the new container. The abstract steps for ExtractX are to create a new element of the type “new container” in “container container”, remove the “extractees” from the original container, place them in the new container and finally create the link between the original and new container. In the concrete case of Extract Super Class, the “extractees” are attributes, the original container is the class that contains them, the new container is the newly created super class and the “container container” is the package both classes reside in. However, this general procedure might just as well be used in a documentation format to extract a particular paragraph from a chapter to a newly created superordinate chapter. All that is needed to make the refactoring available to the documentation format is a mapping to its metamodel elements. In more detail, Refactory uses role modeling [RWL96] to create genericity. A role can be “played” by a particular object for a certain period of time before it is dismissed again. Through this, a role provides a particular view on that object for a limited time. This characteristic makes role modeling a very suitable approach for looking at objects and their connections for the duration of a refactoring.

Despite its name, Refactory is not limited to semantic preserving changes but in fact allows arbitrary modifications of Ecore-based models. The following explanations will use the term “refactoring” for an individual modification to stay consistent with Refactory’s terminology. However, the more general phrase “evolution” could be used as well. This makes Refactory a useful tool for implementing evolutions for model-based software product lines. However, the development branches of Refactory and FeatureMapper should remain independent so that no custom version of Refactory is required to execute the evolutions in this thesis. As a consequence, modifications to Refactory are only possible if they pursue the goal of generic model refactoring but not the specifics of evolving software product lines. On occasion, this results in minor inconveniences. For example, the menu entry for all currently applicable modifications is named “Refactor” even though it really contains the more general evolutions. However, these problems do not hinder the functionality of evolving software product lines, which makes them acceptable. Refactory uses up to four different types of files to specify a new refactoring. Out of these four files, two specify the abstract refactoring and one creates a binding to a concrete meta model. The optional fourth file allows to use regular Java source code to perform changes that can not sufficiently be expressed in the abstract refactoring. After they were specified, all files have to be registered with Refactory by use of individual extension points. The names of the respective extension points will be mentioned but an explanation of creating extensions for them is omitted at this point. Details on binding the extension points can be found in Section 4.3.1. All four types of files will be explained thoroughly in the following paragraphs.

4.1.1.1 Role Model (*.rolestext)

Refactory requires a role model to be specified in a *.rolestext file and registered to the extension point org.emftext.refactoring.rolemodel. The main intent of the role model is to define the roles participating in a particular refactoring by giving them a name. Additionally, roles may have a modifier applied to them. There are three possible options for role modifiers. First, “input” marks a role as being the input to the refactoring, which means that the user has to select an element of the type that is mapped to this role for the refactoring to be applicable. Second, “super” states that it suffices if a class of a selected element is derived from the type mapped to this role. Hence, the mapped class is a super class of the actual type of the selected element and the object is not required to be exactly of the specified type. Third, a role may be marked as “optional”, which means that it does not necessarily have to be mapped to a concrete metamodel class.

Furthermore, the role model specifies how roles reference each other through role collabora- tions. Among these are the role composition and the role association, which are conceptually equivalent to the UML class composition and association respectively. Both collaborations have a role as source and target element, which each have a minimum and maximum cardinality ap- plied to it. With collaborations, it is possible to express relations of roles like the one mentioned in the above example where a role “container” possesses many elements of role “extractee”. In this case, a role composition from role “container” with minimum and maximum cardinality of one to the target role “extractee” with a cardinality from one to unlimited has to be specified. Additionally, the “transitive” modifier may be used on a role collaboration. It states that a relation between two roles does not necessarily have to be present directly on the mapped model elements but may be established through other intermediate elements as well. The entire role model of ExtractX is presented in Listing 4.1 in the form of a *.rolestext file to illustrate some of the concepts described in this section. A complete definition of the syntax and semantic of role models can be found in [Rei10].

Listing 4.1: Complete role model for ExtractX.

RoleModel ExtractX {

input super ROLE Extractee;

ROLE OrigContainer;

ROLE NewContainer(input newName);

ROLE ContainerContainer;

transitive : OrigContainer [1..1] <>− Extractee extracts [0..∗];

transitive : NewContainer [1..1] <>− Extractee moved [0..∗];

transitive : ContainerContainer [1..1] <>− NewContainer target [1..1];

transitive : ContainerContainer [1..1] <>− OrigContainer source [1..1];

transitive : OrigContainer [1..∗] −− NewContainer reference [1..∗]; }

4.1.1.2 Refactoring Specification (*.refspec)

While the role model defines which roles exist and how they relate to one another, it does not specify the steps needed to perform a particular refactoring. This is done by the second type of file required by Refactory, the so called refactoring specification. It is defined in a *.refspec file, which supports a domain specific language to formulate instructions on how to carry out a specific refactoring. It has to be registered using the extension point org.emftext. refactoring.refspec.

The first conceptual part of the refactoring specification is dedicated to retrieving concrete objects from the roles defined in the role model. For this purpose, Refactory offers object as- signment commands (out of which three will be presented) that can resolve roles to the objects bound during runtime. The instruction “filter” selects all concrete objects matching the re- quested role, whereas “trace” selects parent elements of the specified input that fit. As third assignment command, “uptree” selects the most special element in the containment hierachy that plays the requested role and is common to all input elements. This is used to determine common container elements.

The second conceptual part of the *.refspec file specifies the steps needed to perform the refactoring. For this purpose, Refactory has instructions to create, move and remove elements as well as to set values. For the sake of brevity, the details of these operations ore omitted at this point. Details on the refactoring specification can be found in [Rei10]. Furthermore, an examplary glance at the capabilites and syntax of a *.refspec file for the generic ExtractX refactoring is provided in Listing 4.2.

Listing 4.2: Complete refactoring specification for ExtractX.

REFACTORING FOR <ExtractX>

STEPS {

object containerContainerObject := ContainerContainer from uptree(INPUT);

object origContainerObjects := OrigContainer as trace(INPUT);

create new nc:NewContainer in containerContainerObject;

assign nc.newName;

move OrigContainer.extracts to nc distinct;

set use of nc in origContainerObjects; }

4.1.1.3 Role Mapping (*.rolemapping)

Having the role model and the refactoring specification in place concludes the generic part of a refactoring. What remains to be done in order for the refactoring to be applicable, is to bind the generic part to a concrete type of model. This is done in the third type of file called a role mapping, which is specified in a *.rolemapping file and then has to be registered using the extension point org.emftext.refactoring.rolemapping. As first step of binding a generic refactoring, a particular type of target model, such as UML, has to be selected by specifying

its namespace URI. In the second step, entities of the selected target model type have to be assigned to the roles defined in the role model. It is possible to map concrete as well as abstract entities. In the latter case, all specializing sub-types are permissible for the bound role. To finalize the mapping, a name has to be assigned to the newly created concrete refactoring. In Listing 4.3, it is shown how the generic refactoring ExtractX is mapped to the UML metamodel to create the concrete refactoring Extract Super Class. A detailed explanation of role mappings can be found in [Rei10].

Listing 4.3: Complete role mapping of ExtractX as Extract Super Class for the UML metamodel.

ROLEMODELMAPPING FOR <http://www.eclipse.org/uml2/3.0.0/UML>

ExtractSuperClass maps <ExtractX> { Extractee := Property;

OrigContainer := Class { extracts := ownedAttribute; reference := superClass; };

NewContainer := Class(newName −> name) { moved := ownedAttribute; }; ContainerContainer := Package { source := packagedElement; target := packagedElement; }; }

Naturally, a generic refactoring consisting of role model and refactoring specification can be mapped multiple times to create a number of different concrete refactorings. The mappings may use the same or different metamodels for each concrete refactoring. As an example of the first case, the generic refactoring ExtractX can be mapped to the UML metamodel again to create another concrete refactoring Extract Interface, which creates a new interface and makes the selected class implement all of its methods. An example of the second case might be to reuse the refactoring in a different context such as in the aforementioned extraction of paragraphs to sections in a documentation format. Through this mechanism, a refactoring can easily be reused in an entirely different language with only minimal effort.

4.1.1.4 Post Processor

Refactory allows an optional fourth type of file to complement a concrete refactoring. It is called “post processor” and it is a regular Java source class. A post processor has to be registered using the extension point org.emftext.refactoring.postprocessor. The only requirement

is that the provided class implements the interface IRefactoringPostProcessor. For the sake of convenience, an abstract base class called AbstractRefactoringPostProcessor is provided, which implements all methods of the interface so that only individual pieces of functionality have to be customized. The purpose of a post processor is to perform modifications that can not sufficiently be expressed in the refactoring specification using the domain specific language of Refactory. For example, one shortcoming of the refactoring specification is that it can not copy elements. If this type of modification is required, a post processor has to be employed.

In the control flow of Refactory, the modifications of the refactoring specification are per- formed first and then the post processor is executed. This makes the post processor an ideal mechanism for performing a remapping after an interspatial evolution. Hence, the implemen- tation of evolutions for software product lines uses post processors to perform the remapping in both problem and solution space. However, both implementations vary significantly due to the specific requirements of evolutions in each of the spaces. Details on this can be found in Section 4.2.