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.
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 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.
Auteur d'origine: Cedric Notot