Joe Börcsök


Senior Java Developer


Model Transformations and Validations

Multiple steps, multiple opportunities for intervention

Joe Börcsök

November 25, 2019

Why create a gigantic, complex metamodel that describes everything, when designing an application is feasible with small steps and the serial transformation of simpler, easy-to-use models?

The essence of model-based application development is that a commissioned project doesn’t involve separate modeling and developing, but rather the creation of the model is followed by a series of transformations and validations which allow single or multiple operators to shape and supplement it, and if necessary, use increasingly detailed data. This model will serve as the basis of the future application and can be used to integrate the entire process on a higher level.

In order to use the method, let’s first go over the basic concepts of “model” (an abstract simplification of something that describes something we’d like to deal with) and “metamodel” (the description that defines the model, the metamodel describes how the various elements can be combined when making the model. If the model were pieces of a model airplane then the metamodel would be the set of instructions to build it).

Metamodels must contain the following elements:

  • abstract syntax that defines the structural elements and correlations in the definition of the model
  • concrete syntax which describes language elements of the abstract syntax with textual or graphic representation
  • semantic information that describes the higher-level meaning of the elements and the conditions of their use

A state machine that accepts only even numbers is a good example of a model. It can be used to demonstrate the usage of a metamodel and how it differs from other definition options, such as grammar.

Some of the main differences between metamodeling and grammar:

  • While the metamodel also allows describing the graph structure (directed graph), grammar supports parse trees better (an exponent can take the environment into consideration, yet cannot span great distances).
  • Whilst the metamodel defines the structure that the model will contain, grammar fundamentally defines the concrete syntax.
  • While a metamodel can describe what the structure looks like, we can wait to decide which form this can be described in. However, with grammar, the rules of textual representation must be defined.
  • Whilst in the case of metamodels, the metamodel and its copy, the model follows similar rules (thus, even the metamodel has a metamodel, the meta-metamodel) and can be loaded in many devices in a similar manner, this isn’t present in the case of grammar. The grammar rules must be defined in a different structure than the sentences of the grammar itself.

The advantages of using metamodels include the following:

  • They display and allow the processing of large-size documentation (formal description), similar to grammars.
  • They allow production of valid, well-defined texts (models), similar to grammars.
  • The verification of rules is defined in a declarative, business language on a model copy; performing conversions based on declaratively described transformational rules.
  • One can generate text-based documentation from the model.

Validate as soon as possible!

Validation is also necessary when using metamodels in order to ensure the successful development of applications. During these validations, we can examine whether the model was properly prepared. Devices usually won’t even allow creating drawings that contain syntactic errors. Designs can be successfully saved even if the semantic rules aren’t observed, yet the warnings or error messages inform the modelers that further processing (including conveying to other team members) is not yet possible. This way, it’s easier for the user to identify the causes and correct them.

However, it’s worth keeping in mind that semantic rules can be grouped and some serve as the prerequisites of others. In these cases, the lower-level rule makes it unnecessary to run those that are based on them.

Let’s look at a Java example of this. If there is an error in a Java source that is used by many – sometimes even dozens – of other components, there’s no need to list all the errors, only those in the foundations. We cannot resolve any other errors until the basic error is corrected. For similar reasons, it’s worth running the validation and correcting the errors as soon as possible, as it will be harder to figure out at a later point exactly what it is that we must go back for.

Multiple steps, multiple opportunities for intervention

Once we’ve suitably validated our models, we can move on to transformations. This involves transforming the models into copies of the same or different metamodel, using the concepts of metamodels (transformation rules). Sometimes, a single transformation requires multiple source copies (input models).

The use of transformation is advantageous because it doesn’t require creating a minutely developed, yet overly complex metamodel that describes part or the entirety of an application. Naturally, this can also have its advantages especially when presenting very simple, Hello World applications. However, this results in accumulating business (high level) and technical (low level) concepts in the same group, which no one will really be able to use as it will be too detailed for people dealing with business concepts, whilst for those who deal with low-level parts, it will be too voluminous, as they only work on small units at the same time.

Nevertheless, transformations allow creating ever newer transformations from multiple original models. This allows reaching the goal of a working application through multiple stages. What’s more, after every stage, we have the option of adding appropriate self-made supplements, source codes, parameters and configurations in the right location. A great advantage is that this way, there’s no need to provide everything in a single, shared place that would make things complicated for everyone and instead splits them according to various roles.

All source models (those independently created by someone, not as a result of a transformation) must be validated individually, thus incorporating increasingly lower level technical elements in the application.

And how does all of this work, for example, in the JUDO system?

Modelers use appropriate tools to draw a model, which results in a JUDO PSM (platform specific model) model. The modeling device makes those elements accessible and connectible which are supported by the future operating environment (platform). Yet, what if there is a need for an element that the system cannot accommodate by default?

In such cases:

  • we can include supplementary source models (for example, type mappings in the case of a new relational database)
  • we can use annotations (key-value pairs) that are carried in the system throughout the transformation and at the end, the developers reach the unique behaviors described by them
  • or we can use dynamic operation, when the modeler enters previously non-defined type data, while the system remains flexibly adaptable.

Model transformation-based application development is an effective method for creating applications that have a structure (and to a certain extent, a behavior) that can be well described with models. At the 1st BlackBelt Open Meetup, I tried to update knowledge on the subject for those who were already involved in modeling (for example, with UML the discussion provided a developmental methodology) as well as for developers who are yet to use modeling (in their case, this provided them with an example of how to describe correlations on a higher level).

Some questions came up during the lecture. For example, what happens if I change the metamodel, what makes this so “painful”?

In such cases, one must tread carefully. If the metamodel in question is used by multiple projects, the modification will impact all of them. However, there can be significant differences between the life cycles. It’s worth considering how the changes impact all the individual layers and only refreshing to the new version if the undecided element is prepared for the other changes beyond the necessary supplement or fix (that necessitates refreshing).

Naturally, the question came up whether multiple metamodels, validations and transformations are capable of constituting a consistent whole.

The answer is yes, insofar as they all cover none-overlapping functionalities with clearly defined roles and boundaries. In such cases, the validations and transformations can be thoroughly covered with unit tests:

  • In the matter of validations, these ensure that the rules truly identify required errors and, in the case of a change in the metamodels, that they can continue to be applied for the models in question.
  • in the case of transformations, they ensure that the produced models remain valid (i.e. the semantic rules of the target model are coded in the transformational rules used to produce the models)

Give Judo a Try!

  • We have a  slack community as well, where you will find up-to-date information and you can also contribute with others.
  • A ton of documentation and video tutorials are available for our members.
  • You get scores for your activity and you can take home some JUDO goodies!