Validation of Models with Acceleo (Part 2)

The second one (Part 2) consists in creating Acceleo services.

This solution provides additionnal functionalities in relation to the first one. Indeed, as the rules are written in Java language, you can decide that a specific rule won't overload a generic one for example...

I've created a "ValidatorServices" class which implements a mechanism to validate a model and get the report from templates, thanks to the services that it provides. The end-user has just to extend this one and to implement the "checkRules" abstract protected method in order to define his own rules.
He can use "validate", "isErrorChecking" or "isWarningChecking" services to validate his model.

But the main new feature consists in giving the possibility to use the result of the validation report and to act on the generation or not. Let's interest by this feature:

The "isErrorChecking" and "isWarningChecking" are able to notify if an error/warning at least has been detected. So, "isErrorChecking" may be used for example to forbid the generation if it returns true.

The "ValidatorServices" class manages a "singleton" behaviour in order to have only one validation launch per generation and to optimize the process.
Moreover, it manages a workaround about Acceleo architecture limitation on the instanciating of custom services between templates...

Indeed, the services don't share the same context between each template. So, let's take an example with two templates where each of them generates a file. We knows that the generation depends on the "file" parameter. Consequently, it's in this place that you have to use "isExistingError" if you want to control the generation. Not to have as many validation launches as templates which generate files, it is required to keep report in memory. To do that, the "ValidatorServices" retrieve data from a temporary file, in the temporary directory of the OS (Java environment variable). You can use a custom action to delete this file (clean data context) at the end of the generation process.
IsXXXChecking use temporary file only if it is called in different templates which generate files.

See the demo:

The main benefit of this way is to be able to cancel the generation if the validation process has thrown errors or warnings... according to your rules.
Then, it provides a flexibility for the use of the validation mechanism (priority of rules, control generation...) thanks to the Java language. So, applying a rule on a "super" meta-class and an other one on a "child" meta-class, you can decide to display the both respective messages if these rules are not checked (and not only the "child" one).

The concern is the technical heaviness of the solution which might be managed, in a more transparent way, by the acceleo core.
Then, the use of Java language involves a loss of the Acceleo features (debugging, traceability...).

Validation of Models with Acceleo (Part 1)

With Acceleo, you can define your own functional validation rules on a model and log messages according to them, during code generation.

I suggest different ways to define the validation rules.

The first one (Part 1) consists in creating a simple Acceleo template where each script defines a set of rules to check on a particular meta-class of the meta-model.

I've created basic java services to log messages with different severities. These messages take as parameter the condition to check (a boolean) and the text to display if this one is false.

We knows that a script may be called if the « file » parameter is setted or if an other script calls it. We also knows that this parameter is used to decide to generate or not the code and to specify where it has to be generated.
In our specific case, we want to activate rules sets without generating code. So, each script owns a « file » parameter which is a call script returning nothing and which gets the particularity to call back the right script to run the rules to apply.

You can see a demo with an example of a template in order to validate a State Machine UML2 model:

The benefit of this way is really the easiness to define the rules thanks to Acceleo Language.
The generic rules (in this example, on the « Named Elements ») apply only on the objects not concerned by a specific rule (inheriting concept).

The only concern is about using the result of the validation to decide to generate or not, for example. Here, it's not simple to do that because, in a chain, every templates which are called are not able to directly communicate between them.