Keywords

1 Introduction

Model transformation technology is the enabler of automation in Model-Driven Engineering (MDE), allowing model refactorings, optimizations, simulations and language conversions. However, developing a transformation from scratch is complex and error prone, even when specialized languages are used [6]. Thus, the reuse of existing high-quality transformations should be fostered, to amortize the effort invested in their development. One way to achieve this goal is to develop reusable transformation libraries, as it is common with general-purpose languages (e.g., ready to use Java libraries packaged as a .jar).

There are different reuse approaches for model transformations, ranging from reusing single rules (e.g., rule inheritance [12]) to reusing complete transformations (e.g.,superimposition [11] or phasing [7]). However, most are type-centric, in the sense that a transformation cannot be reused for meta-models different from the ones used by the original transformation, thus limiting the reuse possibilities. There are some exceptions though, like [8] and [10], which use model subtyping and genericity respectively to define more reusable transformations. Other approaches [1] rely on transformation repositories and meta-model match and comparison techniques. However, they do not provide mechanisms to make transformations more reusable. Altogether, reuse of transformations is scarce in practice, as concluded in [3].

Fig. 1.
figure 1

Component instantiation

In the last few years, we have developed a transformation reuse approach inspired by generic programming [9] (e.g., templates in the C++ style) that we have implemented in a tool called bentō. The tool allows the definition of transformation components consisting of a transformation template, one or more concepts/meta-models, and a description of the component using a dedicated domain-specific language (DSL). Concepts are used as a means to describe the structural requirements that a meta-model needs to fulfil to allow the instantiation of the component with the meta-model. In particular, to instantiate the component for a meta-model, a binding mapping the concept elements to concrete meta-model elements (i.e., classes and features) should be written using another DSL. This binding adapts the transformation template to yield a new transformation ready to use with the concrete meta-model. Figure 1 shows this process. In addition, composite components permit combining simpler components using transformation chaining.

Our approach has advantages w.r.t. existing proposals: (i) it is more flexible, since it permits applying components for meta-models that are structurally very dissimilar to the concept; (ii) it does not require adapting the bound meta-models and their instance models, but our template rewriting approach generates a new transformation that can be readily applied to them, improving performance; (iii) no special traceability handling is needed; and (iv) our component model allows the precise description of components and provides a systematic way of reuse.

The aim of this tool-demo paper is to describe the architecture of bentō and its features from the perspective of the tool user. A summary of the concrete demo presented at the conference is available onlineFootnote 1. The concepts behind the component model underlying bentō have been reported elsewhere [4, 5]. Nevertheless, the tool has been improved since its first versions with new features such as support for in-place transformations, validation, integration with a static analyser [6]Footnote 2, and a REST-based repository to store and retrieve components.

Paper Organization. Section 2 overviews bentō’s architecture, and the following ones show its main use cases: developing reusable components (Sect. 3), reusing components (Sect. 4), making a reusable component out of an existing transformation (Sect. 5), and selecting components (Sect. 6). Section 7 finishes with the conclusions and future work.

2 Tool Architecture

Bentō is an Eclipse-plugin. Its architecture, depicted in Fig. 2, consists of a component model, a reverse engineering wizard, and a remote repository facility. Implementation-wise, the two main elements of the component model are anATLyzer to statically analyse ATL transformations, and the Template Adapter which is able to solve non-trivial heterogeneities between concepts and meta-models (see Sects. 3 and 4). The DSLs to specify components and bindings has been defined using EMFText. In addition, bentō includes a reverse engineering wizard to convert an existing transformation into a reusable component (see Sect. 5), and a REST-based repository to share components (see Sect. 6).

Fig. 2.
figure 2

bentō architecture

As stated by Krueger [2], the practical use of components should consider four dimensions: abstraction, specialization, selection and integration. Table 1 summarizes the features of bentō according to these dimensions.

Table 1. Features of bentō

3 Developing Components

As a running example, let us consider the visualization of object-oriented models by means of a transformation to the DOT format. This transformation will be similar for a range of object-oriented languages such as Ecore, KM3, UML or even Java. Hence, we create a reusable transformation component called oo2dot that can be specialized for such languages.

A transformation component is made of a transformation template, one or more concepts or meta-models over which the template is defined, and a description of the component. This is shown in Fig. 3. These artefacts are organized according to the structure shown in (1). In this case, the transformation has a source concept (OO.ecore) and a target meta-model (DOT.ecore). A concept is just a regular Ecore meta-model (2), but it only contains the elements required by the transformation, thus removing “accidental elements” for this particular scenario like configuration attributes (e.g., transient in Ecore) or features that we do not intend to visualize (e.g., annotations in Ecore). The transformation template is a regular ATL transformation. Moreover, bentō uses anATLyzer to statically analyse the transformation templates in order to provide some guarantee of their correctness, as illustrated by the error markers in (3). The component specification, shown in (4), describes the inputs and outputs of the transformation, since it is a single component.

Fig. 3.
figure 3

Definition of component in bentō

Components can be exported to a remote component repository using the Eclipse export menu (see more details in Sect. 6).

4 Reusing Components

In order to instantiate a component for a concrete meta-model, the component must be specialized by defining a binding from the elements in the concept to elements of the meta-model. Figure 4(1) shows part of the binding from the OO concept to the Ecore meta-model. The binding is used to automatically rewrite the original template, so that it becomes able to transform models conforming to the bound meta-model. A distinguishing feature of our tool is that it allows sophisticated adaptations that bridge many heterogeneities between the concept and the meta-model. This is possible due to the precise typing information gathered by anATLyzer. A detailed account of the binding features and solvable heterogeneities is given in [4].

Figure 4(2) shows how to instantiate and execute a component. We need to define a composite component which imports the component to instantiate (oo2dot) and the binding, and uses the apply command to adapt the component according to the binding and execute it on the given source/target models. Composite components also support sequencing components to create transformation chains.

Fig. 4.
figure 4

Binding and composite component definition in bentō

5 Reverse Engineering Existing Transformations

To enable the reuse of existing ATL transformations, bentō provides a reverse engineering facility that converts a transformation whose meta-models are “hard-coded” into a concept-based transformation component. This facility uses anATLyzer to statically determine the elements of the original meta-models that the transformation does not use, and then, it extracts a concept where such elements are pruned. In the process, a set of automated or manual refactorings can be applied to improve the quality of the extracted concept, which may imply the automatic co-evolution of the transformation.

From the user perspective, there is a wizard to configure the process, apply refactorings and automatically generate the component specification.

In the running example, instead of developing the oo2dot transformation from scratch, we could convert the KM32DOT transformation available in the ATL transformation zoo into a reusable component. This transformation has 418 LOC, 18 helpers and 7 rules; thus, its reuse saves a lot of effort. Figure 5 shows the wizard to configure the conversion, which includes links to guide the steps to perform.

Fig. 5.
figure 5

Reverse engineering of KM32DOT

6 Selecting Components

The ability to search and select components is important in any reuse approach, being typically enhanced by concise abstractions that can be easily understood and compared [2]. In our case, given a transformation component, it is easy to examine its concepts (i.e., its interface) to decide whether they match the meta-models at hand.

In addition, to facilitate the publication and retrieval of components, we have implemented a simple REST service to publish and search components. Components may have tags attached, which can be used in the search. Once a component is selected, it is automatically installed in a local project (bento.local.repo) and can be referenced by other projects using the URI bento:/componentName. When a component uses a URI of this kind, if the corresponding component has not already been installed, it is automatically sought in the remote repository by name. This feature is akin to Maven dependency resolution, and is intended to facilitate the maintenance of composite components. Figure 6 shows the Eclipse import wizard to search and install components.

Fig. 6.
figure 6

Searching the repository by name and tags

7 Conclusions

In this paper, we have presented bentō, a tool supporting model transformation components. It includes features like flexible template adaptations, reverse engineering of existing transformations into reusable components, a REST-based repository and component validations. To the best of our knowledge, this is the first component model for model transformations.

Bentō is available as free software (http://github.com/jesusc/bento) and as a ready to install Eclipse-plugin (http://www.miso.es/tools/bento.html).

Currently, Java programs can be packaged as bentō components, but these cannot be adapted. We are working on the possibility to package and adapt other MDE artefacts as bentō components, like Acceleo generators.