Tailoring Enterprise Architect with MDG Technologies

Enterprise Architect, EA for short, is a widely used integrated modeling platform with an impressive amount of supported languages including UML, SysML or BPMN. But even with this large collection of languages, you may have found yourself in a situation where none of them fulfilled your particular use case in an appropriate manner. Such situations occur often when the EA model is processed further by other tools and is not only used for documentation purposes. The challenge is then to come up with a model that is accepted by the tools processing it.

This is the first of three articles in which I would like to discuss common issues and solutions we developed together with our customers where EA needs to be integrated into existing tool chains.

Problem: Unsuitable Modeling Language

The main reason why Enterprise Architect should be integrated into existing tool chains is from my point of view to generate artifacts such as source code or reports from the model. Obviously, generating artifacts saves time and reduces failures.

The customers I support use UML or SysML as modeling languages. Both offer a large variety of elements, connectors, and diagrams that can be created. But this variety is not needed in practice, because the organization has a strict development process in which the artifacts to be created are specified. Indeed, the variety is counterproductive, because the user is not guided by EA to come up with a model which fulfills the standard of the organization and which can be processed further.

Another problem by using standard languages such as UML or SysML is that some aspects to be modeled cannot be expressed in an appropriate way. In a simple case, this might be a value which should be attached to an element to describe for instance the maximal allowed memory consumption. In a complex case, this might be a missing concept such as the ECU configuration in Autosar.

Solution: Define an MDG Technology

In UML, profiles are used to declare stereotypes which can be applied to elements and connectors to refine their semantics and to describe them more precisely. A stereotype might have additional properties, whose runtime values are called tagged values. Enterprise Architect allows one to define UML profiles and related customizations of EA by so called MDG Technologies. Please observe that EA allows the user to assign tagged values which do not belong to any stereotype. I prefer to avoid them, because the potential for failures (e.g. spelling mistakes or the absence) is high and because they are not part of the UML standard which might be an issue when the model should be processed by other tools.

Let me introduce an ongoing example as basis for the discussion of the customization of EA. The goal is to use UML class diagrams to describe domain models and to generate EMF compatible source code from them fully automatically. A domain model in EMF is an instance of the Ecore meta model, which is similar to an UML class diagram, but (i) with a limited set of elements and connectors and (ii) with some additional properties per element/connector. Indeed, I could have chosen any other standard as basis for the discussion such as Autosar, Franca or BPMN. But I think EMF is quite simple and it does not make this article unnecessarily complicated without losing the capability to discuss the solutions for our customers.

The screenshot below shows the domain model of a fictive application for unit testing. Several UML class diagrams are used to visualize one aspect of the domain model. On top level, the Test Application consists of packages Source and Test. The source code under test is represented by packages and modules and a test for a source module can have multiple test runs where each run has a specific test result.

Fictive example application model for unit testing authored in EA

The first draft of the model in the screenshot above uses only elements and connectors of UML. But as you might imagine, this does not fulfill the needs to generate an EMF model. Having an appropriate example model is a good foundation to start the customization process, because it allows the domain experts to see the effects of the customization on a model they are familiar with. This makes all discussions in the iterative customization process less theoretical.

To make the model EMF compatible, I have to specify some additional properties and to use only data types supported by EMF. To attach the missing properties, I define an UML profile for EMF. This profile contains a stereotype with tagged values for each concept supported by EMF. If desired, the stereotype could also define how an element or connector is rendered and whether or not a composite diagram is available. Properties already available in UML are reused, thus only new properties are defined by tagged values. For a reference to a data type, I could simply enter the name of a data type supported by EMF as free text, because EA does not validate referenced types. The absence of a validation seems to make modeling comfortable, but it causes more problems as it helps. Instead, I define a so-called code engineering language listing all data types supported by EMF as part of the MDG technology. In Enterprise Architect, such a language is set on each element and the combo-box to select a type is filled with the data types of the set language.

Finally, a new diagram type with a related toolbox is defined as part of the MDG technology. The diagram type ensures that the correct language is set on newly created elements and that tagged values are shown by default in diagrams. The new toolbox contains only a subset of UML elements and connectors which are related to EMF and which already have the EMF-specific stereotypes applied.

The screenshot below shows again the test application example, but this time modeled in EA using the MDG Technology for EMF. What cannot be seen in the screenshot is, that the quick linker is extended to suggest connectors and elements related to EMF.

Revised model of the application for unit testing with an MDG Technology for EMF

Problem: Common Patterns are Difficult to Instantiate

It is cumbersome for users to instantiate recurring model patterns in which multiple elements and connectors are involved. In the EMF example, a helpful pattern is to model a map data structure, because it involves several classes with an unintuitive configuration as shown in the diagram below.  Please observe that a map is represented in EMF as a list of map entries with instance type name java.util.Map$Entry and explicit types for the key and the value. EMF’s code generator will recognize the pattern and use an EMF specific map implementation as type of the composition entries.

Template of a map data structure in EMF

Another example are templates, which contain entire model fragments to start with. If an organization specifies the artifacts to be created, templates could be defined as the minimal set of required elements, connectors, and diagrams.

Solution: Define Templates

Enterprise Architect allows one to define templates as part of an MDG technology. Templates are supported by EA in two flavors. The Model Wizard adds a new package with predefined content to an existing model whereas a template (called pattern in EA) instantiated via the toolbox adds content to the model and also to the current diagram.

The MDG technology of the running example, offers a template which adds the minimal content expected by EMF. In addition, the pattern Map can be instantiated via the toolbox (see diagram above).

Problem: Finding Elements of Interest

An EA model often consists of several diagrams where each diagram visualizes one aspect of the model. This brings the need to find existing elements in order to reuse them in a diagram. In large models, finding an element by navigating in the Project Browser window gets really time intensive. The alternative is to search for a model element. Beside predefined searches, user defined SQL queries can be executed. But this requires knowledge of the underlying database schema which many users may not have.

Solution: Define Searches and Configure ‘Model Views’ Window

An MDG technology allows one also to deliver predefined searches. The results of these searches can be shown in the Model Views window. This eliminates the need to instantiate searches manually. Furthermore, a Workspace Layout can be defined to ensure that all windows relevant for the modeling task at hand are visible.

The Model Views window in the running example lists all EClass and EEnum instances, because they are likely to be reused in other diagrams.

Screenshot of the Model Views window showing the content of the revised model of the application for unit testing with an MDG Technology for EMF

Summary

In this blog article, I discussed several issues which often occur when using Enterprise Architect out of the box and which can be solved with an MDG Technology, namely:

• The user is overwhelmed by the opportunities of the UML as a general purpose modeling language and does not know which elements and connectors should be used to create a consistent model that can be processed further. This can be solved with custom diagram types and custom related toolboxes offering only the needed elements and connectors. The perspectives introduced by EA 14 looks promising in order to focus better on the task at hand.
• Content not supported by the UML must be entered as free text which is cumbersome and error-prone. The solution is a UML profile to define stereotypes (and its properties) and an EA code engineering language to provide a list of predefined data types. For convenience, the quick linker can be extended to support the new stereotypes.
• Common patterns are cumbersome to instantiate. The solution are templates which can be instantiated and then adjusted by the user.
• Elements are hard to find in large models. The solution are custom searches where the results are optionally shown in the Model Views window.

If you want to try out the MDG Technology for EMF, you can download it with just one click. The source code of the MDG Technology is available as well.

Outlook: Further Ways to Tailor Enterprise Architect

In my next article I will (i) discuss how add-ins can be used to make the user more productive and to ensure consistent models, and (ii) how to integrate EA in existing tool chains with the EA-Bridge to validate the model and to generate source code.