This is the second of three articles in which I would like to discuss common issues (and our solutions) that occur when Enterprise Architect, EA for short, is used to create models that are processed further by other tools.
In my previous article, I presented an MDG Technology for EMF, which extends EA amongst others by (i) stereotypes for each element/connector part of EMF’s meta model, and (ii) a new diagram type with a related toolbar and quick linker. In this article, I would like to develop the example further and customize Enterprise Architect with an add-in to increase productivity of the user and to ensure consistent models.
A UML profile ensures that all needed concepts can be instantiated in the model. But the instantiation might be complicated and time intensive. The MDG Technology for EMF for instance reuses UML concepts if suitable and introduces tagged values only for additional properties. Consequently, a user needs to find the few relevant input fields in the depth of Enterprise Architect’s properties dialogs. Usability, especially for new users, could be improved with some input form containing only the relevant properties.
Add-ins allow one to extend Enterprise Architect with additional functionality such as
These examples have in common that they focus on one task and help the user to perform it in an efficient way, therefore, we call them model assistants. Model assistants might be invoked manually by the user via a menu item or automatically after specific changes in the model.
The screenshot below shows Enterprise Architect with an add-in for EMF. The add-in offers a model assistant to edit elements/connectors with an applied stereotype of the MDG Technology for EMF. This assistant comes in two flavors: first, the context menu item of a selected element allows the user to open a dialog in which EMF-specific properties can be edited; second, a main menu item which opens a custom window that shows the same relevant properties for EMF of the selected element. If no EMF stereotype is applied on the selected element, an info message is shown instead.
Model assistants help the user to perform one task in an efficient way, but they do not uphold one from doing something that violates the model. For instance,
Consequently, model validity should be checked frequently to find defects as early as possible to reduce the costs to fix them. It also ensures that the model can be processed further by other tools.
We use so called integrity checks to check the model’s consistency and validity. They ensure
Integrity checks can be executed automatically, e.g. when an EA model is opened, or on demand by the user. Often it is possible to solve found issues automatically or semi-automatically. Our add-ins typically show all found issues to the user so that she or he can review them and decide how to solve each of them. This can be seen in the screenshot below, where the integrity check reports that a mandatory tagged value is missing and suggests to re-add it as resolution.
Integrity check reporting that a mandatory tagged value is missing
Both, MDG technologies and add-ins must be available for all users working with the model. Whereas an MDG technology might be embedded into the Enterprise Architect model, this is not possible with add-ins. Therefore, a rollout of the add-in including all required resources such as an MDG technology is needed.
Instead of embedding MDG technologies in EA models, we prefer to distribute them as part of add-ins. This ensures that both, add-ins and MDG technology, are always compatible to each other. But it can happen that a model should be edited with a newer version of the add-in. If the newer MDG technology is incompatible to the old one, an integrity check can be implemented to migrate the model.
An installer is ideal for the rollout of the add-in, because it is convenient for users and administrators. Another benefit is that installers can typically update a previous installation. Installers are easy to implement with the WiX Toolset, for instance, because it nicely integrates into the .NET IDE which is typically used for add-in development.
In this article, I discussed several issues which often occur when using Enterprise Architect out of the box and which can be solved with an add-in, namely:
You can try out the add-in for EMF with just one click and also the source code of the add-in is available.
In my next article I will discuss how to process an EA model with the EA-Bridge to generate source code and to check it against the EMF standard.