Processing Enterprise Architect Models with the EA-Bridge

Previously, I presented how to tailor Enterprise Architect (EA) with MDG Technologies to define UML profiles and with add-ins to increase productivity. In this final article, I would like to develop the running example further to generate source code from the EA model. This means to transform the EA model into an Ecore model, the meta model of EMF.

Problem: Writing Maintainable Artifact Generators

EA offers a code generation facility and a documentation engine allowing one to generate source code and reports. Both can be tailored to produce the desired source code and documents, respectively. However, there are some points against the usage:

• Maintainability: The infrastructure of EA is rudimentary (e.g. complicated templates, no debugger) and not comparable to modern IDEs. This makes it almost impossible to implement complicated artifact generators (e.g. a code generator which preserves user changes or a model to model transformation where the outcome is not source code or text) that should be maintained for many years.
• Data Model: EA operates on a proprietary data model which consists basically of elements, connectors, attributes and methods. But it is often desired to operate on an instance of the standard UML metamodel which allows the generator to directly access UML conform instances including applied stereotypes. The usage of the UML metamodel increases also the interoperability of the code generator, because the UML model could be created by EA or any other tool.
• Integrability: The artifact generation is triggered within EA, but it might be desired to generate the artifacts in the tool in which they should be processed further (e.g. Eclipse in the running example). In addition, It might be required to trigger the artifact generation automatically, e.g. on a continuous integration server without a user interface.

Additional arguments are given in the article “Eclipse-based Code Generation for Enterprise Architect Models”.

Solution: Generator Implemented in Any Language Targeting the JVM

The EA-Bridge provides access to the content of an Enterprise Architect model stored as eap-file or within a remote database. It transforms the EA model into a standardized UML 2 model on the fly. Thus, all existing tools which operate on such UML 2 models should be compatible and can be used. This includes, for instance, the tree-based UML editor (see left editor in the screenshot “Eclipse extension to generate an ecore-file from a given eap-file”) and validation capabilities which are, compared to EA’s UML validation, complete and much faster.

Artifact generators operating on UML 2 models (and generally on all EMF-based models) are easy to implement with Xtend or Acceleo, but also any other programming language targeting the JVM can be used.

All involved artifacts and components are shown in the figure below. Please observe that only the artifact generator must be implemented. An artifact generator usually checks the model before the actual generation takes place. This ensures that only valid models are processed and that thus no defective artifacts are generated. Once the artifact generator is available, arbitrary EA models can be created by the user and be processed by the tooling. The generated artifacts can finally be processed by the (existing) tools.

(Involved artifacts and components when the EA-Bridge is used for artifact generation)

The screenshot below shows Eclipse with a custom extension that allows the user to generate an ecore Model from an EA model. The transformation is triggered via a context menu item. Once the ecore-file was generated, it might be modified by the user before Java source code is generated with the usual EMF tooling of Eclipse. In addition, validity of the EA model can be checked by calling EMF’s validator directly on the eap file.

(Eclipse extension to generate an ecore-file from a given eap-file)

Problem: Redundant Implementation of Model Checks

Conformance of the model to the targeted standard must be checked by the artifact generator to ensure that only valid artifacts are generated. But it is desired to check the model already during creation time, see last article. This brings the need to implement checks twice, once in EA and once in the artifact generator.

Solution: Use Headless Mode To Check a Model by the Artifact Generator

As the checks must be available in the artifact generator, a re-implementation in the add-in for EA should be avoided. We achieve this with a headless mode without any user interface offered by the artifact generator for checking purposes. The add-in can then call the existing functionality, prepare the results, and show them to the user.

The screenshot below shows how the EMF validation can be triggered within EA. The results are shown in window System Output. A double click on an issue selects the related element in the Project Browser window.

Checking model validity in EA by calling the artifact generator in a headless mode

Summary

In this article, I discussed how the EA-Bridge can be used to process an EA model in order to implement maintainable artifact generators. Offering a headless mode in addition avoids the need to implement model checks multiple times.

If you want to try out the tooling, you can download it with just one click!