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.
Problem: Modeling Tasks are Inadequately Supported
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.
Solution: Model Assistants
Add-ins allow one to extend Enterprise Architect with additional functionality such as
- input forms to create or edit elements and connectors,
- synchronization of changes between two views of an element on different abstraction layers, or
- refactorings which apply a change consistently on the overall model.
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 assistant to edit the properties of an EMF-stereotyped element/connector)
Problem: Model Validity
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,
- a mandatory tagged value could accidentally be deleted without any warning inside EA violating the UML profile. A tool processing the model might refuse to load the model or might use a default value for the missing tagged value. As the default value is not part of the model, resulting defects are hard to find.
- Concepts could be used wrongly violating their semantics, e.g. by introducing a cyclic inheritance relationship. A tool processing the model should report such defects. But if not, invalid artifacts are generated which must be inspected in order to find a defect introduced in the original model. This is a non-trivial task especially when the model and the artifacts are developed by different persons.
- Modeling conventions of the organization or the current project could be violated, e.g. by using names with characters that are forbidden in tools processing the model. Such a tool might not detect the violation and either fail or generate artifacts repeating the defect. If the violation is found later, e.g. in a review, the fix requires also to adjust artifacts based on the generated ones.
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.
Solution: Integrity Checks
We use so called integrity checks to check the model’s consistency and validity. They ensure
- that the database containing the EA model is consistent.
- EA’s Project Data Integrity Check ensures a mandatory consistency including for instance a valid containment hierarchy.
- Additional checks are desired for aspects not covered by EA’s integrity check such as conformance to the used MDG technology, e.g. missing mandatory tagged values are not automatically added.
- that the model is conform to the UML standard and the used UML profiles.
- Such a check is offered by EA and the YAKINDU EA-Bridge. The first one is based on Enterprise Architect’s API whereas the second one is based on the Eclipse UML2 implementation. The differences are discussed in the article “UML as a Standard: Where the Promise fails”.
- that the model is conform to the targeted standard and modeling conventions.
- This includes both, a syntactical and a semantical check. Syntactical validity means that each element and connector complies with the constraints of the used modeling language. Semantical validity is stricter and allows only elements and connectors according to the targeted domain. E.g. a connector between a provided and required port of the same component might be applicable, but not desired in the domain.
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
Problem: Rollout of MDG technology and Add-ins
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.
Solution: Offer an Installer
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:
- Modeling tasks are inadequately supported by the standard UI of EA. This includes that the user spends too much time with navigating through the UI of EA, the lag of custom input forms, or refactorings. We solve this with so called model assistants which help the user to perform specific tasks efficiently.
- Enterprise Architect ensures only basic consistency and validity of the model. We strongly recommend additional integrity checks to ensure consistent and valid models which can be processed further.
- Add-in and MDG technology must be compatible and available in all EA instances. We solve this by distributing the MDG technology as part of an add-in and with an installer to rollout the add-in.
Outlook: Processing EA Models in Eclipse
In my next article I will discuss how to process an EA model with the YAKINDU EA-Bridge to generate source code and to check it against the EMF standard.