Generation process
author : | Florian Desbois, Jean Couteau |
---|---|
contact : | eugene-devel@list.nuiton.org or eugene-users@list.nuiton.org |
revision : | $Revision$ |
date : | $Date$ |
Generation principle is split into three points :
- Input files, representing a data model
- Generation process (templates, model transformers)
- Output files for a final application in the programming language wanted
EUGene uses UML modeling language (in XMI format) to read a data model, load it into memory to manipulate it using Java and finally generate output files adapted to a technology or a programming language.
Two generation option :
- Simple generation : generation template
- Complete generation : model reading + model transformer + simple generation template (usually unique for the output language)
We will also see the case of Java generation .
Simple generation
EUGene needs one or more XMI files as input of the generation process. Those files corresponds to the model to manipulate during generation. Those XMI files will be converted in .objectmodel files easier to read to fill the ObjectModel memory model. Since EUGene first versions, it is possible to write generation templates to interpret the obtained ObjectModel's specificity according to the desired output (whatever the language might be : java, xml, php, C++, ...)
In this generation case, the developer only needs to write one or more generators (Generator) using a simple syntax interpreted by Nuiton-processor .
By default EUgene manipulate ObjectModel resulting from known file formats such as zargo, zuml or xmi files (see Writer ).
Complete generation
It is possible to use another file format than xmi or objectmodel as EUGene input. In this case, it is necessary to convert this format to fill the memory Objectmodel. It is then possible to use an appropiate ModelReader. It is also possible to use another model than the ObjectModel, StateModel for exemple (the ModelReader used will then be StateModelReader). As seen previously, it is possible to write genertors to interpret ObjectModel and convert it into files. But it is also possible to use a model transformer that is behaving the same way than a generator ; except that it does not end on files writing but on a new model creation ready to be interpreted again by a generator. The transformer's content is not a template anymore but model transformation : the conversion from the input model interpreted by the ModelReader to an output model easier to manipulate in another generator. this allows essentially to concentrate model's interpretation by the transformers and use a basic generator specific to a language for example.
The ObjectModel can also be used as result model from the transformation without necessarily contains model's specificity (UML norm) but more language's one (Java for example).
Java generation
We come to the practical case of Java code generation. Here the input model used is ObjectModel with the default ObjectModelReader that will interpret the .objectmodel files to fill in the memory ObjectModel. The developer will have to create transformers inheriting from ObjectModelTransformerToJava to interpret the input model (UML) to a new model close to Java language (still an ObjectModel). The generator used is still the same, it is the JavaGenerator, that will simply write the content of the Java specific model.
Tools can help adapt easily ObjectModel to the language wanted, like extensions (for Java : ImportsManager, AnnotationManager, ...) and the builder (for Java : JavaBuilder).
Is is mainly advised to use Maven to execute generation using eugene-maven-plugin . Plugin configuration allows to precise the different generation elements (writer, reader, model, template, ...).