8 min. reading time

Every once in a while our clients ask us whether it is possible to generate code for UML models designed with the Enterprise Architect (EA). Short answer: yes, but we don’t recommend it. In general, we encourage our clients to follow the model-driven engineering (MDE) paradigm to automatically derive source code from software models.

Considering the client's needs

Depending on the client’s use case, it might help them more to use a dedicated domain-specific language (e.g. with Xtext) with a client-specific code generator that perfectly suits the client's needs, though. However, in some cases UML is also well-suited, e.g. when working with Autosar models. In such scenarios, it seems to be reasonable to start with the general code generation facilities provided by EA and tailor them to specific needs. I would like to give an example of such a trial and motivate why a third party code generator might be the better choice.

Gentlemen, start your libraries...

Starting with a simple UML model describing a library with media, the default code generation templates produce some rudimentary Java code. Unfortunately, the templates did not consider multiplicities: a library should hold an arbitrary number of media, not only one! So I checked the templates and I was quite surprised about their weird syntax and the generation mechanism. It is nice that the templates are modularized and individual templates can be reused (e.g. for generating an attribute), even predefined macros can be used, e.g. to generate language-dependant visibilities. But I thought it would be easy to modify the templates to generate a ‘List<Media>’ for my library…

Code template editor in EA: no syntax validation, bad documentation – I did not manage to generate a multi-valued field for the ‘media’ aggragation.Code template editor in EA: no syntax validation, bad documentation – the proposed way to generate a multi-valued field for the ‘media’ aggregation does not work.

Searching for a solution 

But this is not as easy as it sounds, even for me as an experienced Java programmer. I tried modifying the template ‘Attribute Declaration’ (which is referenced by ‘Class Body’), until I realized that ‘Linked Attribute Declaration’ is magically used instead. Having found the right place, I could not determine how a type like ‘List’ is supposed to be generated because the predefined variable ‘linkAttCollectionClass’ is never set. Toolip says ‘The collection appropriate for the linked attribute in scope.’, the user guide is a bit more concrete, but until today we could not figure out how to set it. I ended up ignoring that variable and only keeping the ugly check of the aggregations cardinality (which fails e.g. for cardinality ‘1..1’). Our conclusion:

  • The proprietary template language in EA has an incomplete and incredibly bad documentation (or I simply couldn’t find the real reference documentation?).
  • The relation between sub-templates (e.g. inclusion of ‘Link Attribute’ in a class) is magic for me.
  • Code completion is impractical because it does not scope properly depending on the current context.
  • There is no syntax validation.
  • The actually generated code is hard to spot in the templates; invalid instructions are directly generated!
  • Macros cannot be modified / added.

Eclipse to the rescue

Because of the above listed disadvantages of the EA integrated code generation facilities, we recommend our clients who need code generation for UML models, to use Eclipse and its tools for code generation. This will also provide enough flexibility to format the generated code according to specific coding styles and guidelines, which would be a hard task in EA code templates.

We use the YAKINDU EA-Bridge to access to EA models inside Eclipse. It loads them as Eclipse UML models and, as a by-product, performs a syntactical model validation. Now we can use all Eclipse-based modeling tools to process EA models, e.g. for model validation, code generation (e.g. Xtend or plain Java), or automated test execution in continuous integration builds.

Our choice for code generation is typically Xtend with its template expressions, because it seamlessly integrates with Java, has excellent documentation, code completion, syntax validation, debugging support, etc. The snippet below shows a very simple example how to generate code for the Library class as desired.

A first code generation template in Xtend to generate java classes for all UML classes of an EA model; this template can easily be extended as needed.A first code generation template in Xtend to generate java classes for all UML classes of an EA model; this template can easily be extended as needed.

Our solution

In contrast to the EA code generation facilities, Xtend code templates are validated, the IDE provides properly scoped code completion, and changes are immediately reflected in the generated code (if the Xtend code generator is configured as an Eclipse builder, as is the case for the demo generator available below), which makes code template development an easy and comfortable task. You can even work on the EA model and as soon as it changes, the code generator will update (overwrite) the generated code. If you want to add custom code to your generated sources, we strongly suggest to apply the generation gap pattern to clearly separate generated and manual code. Mixing generated and manual code is also possible – we did that for some of our clients – but that requires a much more complicated code generator.

The YAKINDU EA-Bridge is available as a Trial Download which also contains the example code generation templates discussed in this text.

Please keep in mind, however, that the "YAKINDU EA-Bridge Live Codegen Example" project is just an example with only rudimentary error handling. It is useful to quickly getting started with some code generating prototype without starting a runtime instance. If you want to seriously create a code generator, you should do that inside a separate Eclipse plugin, register a builder or a context menu action, and launch that inside an Eclipse runtime instance.

Comments