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:
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:
The advantages of using metamodels include the following:
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:
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 lifecycles. 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: