The Program is the Model: Enabling [email protected]

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

Jesús Sánchez describes today his approach for enabling [email protected] Enter Jesús.

The application of MDE to advanced scenarios is leading to a trend to use models at runtime as part of running systems. This requires interacting with functionality written in general-purpose languages (GPL), which is typically made available in the form of APIs.  In addition, certain programming tasks can be more naturally expressed using model transformations. In this way, it is important to look into ways to bridge the gap between modeling frameworks and general-purpose languages.

Two main approaches were available so far: building an ad-hoc processor to map an API and a model representing it, or using automated mapping tools such as Api2MoL, which was presented in this portal in a previous post. Diagram (a) in the following figure illustrates these approaches: a meta-model that represents the API is defined and the ad-hoc processor or the automated tool are in charge of synchronizing API objects and the model that mirrors them. This model could then be used as input or output of a regular model transformation.

However, we propose a more direct approach, shown in diagram (b), in which there is no need to maintain an intermediate model, but Java objects are treated as if they were part of a model, conforming to a meta-model. Given a Java API, a specification of a mapping between a Java API (e.g., Swing) and a meta-model describing it is defined with a DSL. Then, a model transformation definition is written against the API meta-model, and is compiled into Java bytecode according to the mapping. In this way, the integration of Java programs and model transformation technology is seamless.


As a motivating example, let’s assume that we need to build a visualization component for Petri net models, as part of a Java application. We could use an existing API like jGraph, which provides facilities to visualize graph-like structures.

Normally, we would create a Java program that traverses the model, instantiates jGraph classes (in particular mxCell, that represents a visualizable element), an invokes methods to set the properties of the created objects. However, another option is to see this program as a model transformation that establishes a mapping between the elements of the Petri net meta-model and the jGraph API. The following figure illustrates this scenario.



We have implemented our approach on top of the Eclectic model transformation tool
It features a compiler that generates Java bytecode, so that transformations are executed by the JVM as if they were normal Java programs. However, so far it only dealt with EMF models.

We have extended Eclectic to make it able to deal with APIs, using the approach introduced above. In short, we have created a DSL that allows specifying, at the same time, a meta-model that represents an API and the mapping between the API meta-model elements and the API elements (e.g., Java classes and methods). We allow three kinds of mappings:


  1. Basic mappings, which are based on the Java conventions. A metaclass is mapped to a Java class, and features are mapped to getter and setter methods.
  2. User-defined mappings, which is a very simple mechanism to specify API access logic that our DSL cannot directly support by using plain Java code.
  3. Mappings based on design patterns. For these, our DSL provides dedicated constructs to specify how a given API instantiates a design pattern, so that our compiler knows how to deal with this particular structure. Until now we have given support for the Iterator and Observer patterns.

Applicability scenarios

We are implementing several examples to assess the applicability of our approach, which are available at the Eclectic web site, and we have identified three scenarios in which we believe that it could useful.

  • Model to Java. The first scenario consists of transforming a regular model, conforming to some meta-model, to Java objects that will be integrated with a running system. The Petri net to jGraph example belongs to this scenario. Another example would be generating a Swing graphical user interface at runtime from a UML model.
  • Java to model. The second scenario is the reverse situation. A set of Java live objects are processed by the transformation engine to yield a given model.  This could be useful for reverse engineering at runtime, where the structure of a system at a given moment is analysed by means of a model transformation in order to discover certain information. This has the advantage that the source code of the application is not needed. Another possibility is taking advantage of existing APIs that perform some complex processing and generate an in-memory data structure that has to be further manipulated.  Some examples of APIs of this kind are iText to generate PDFs or Apache POI, which provides a Java bridge to read and write Microsoft Office documents.
  • Pure Java Transformations. This scenario is intended to take advantage of model transformation technology to deal with programming tasks that have a transformational nature.

Eclectic is still under development and we are working actively on improving it, but it already features several transformation languages plus editors packaged as an Eclipse plug-in, and includes the possibility of applying [email protected] Try it and do not hesitate in contacting us if you have any doubt or problem. Also, the full paper describing our approach is available here.

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone


Your email address will not be published. Required fields are marked *