Andreas Graf
by Andreas Graf Nov 22, 2017
5 min. reading time

The Unified Modeling Language (UML) is well established as a modeling language in many domains. One strong argument for the use of UML is the fact, that it has been standardized by the Object Management Group (OMG). Since a model-driven approach with UML mainly adds value if the model is used to generate additional artifacts such as code or custom reports, one might expect that writing such as transformation would be straightforward with some knowledge of the UML specification. However, the standard is often not well reflected by the APIs of UML tools.

Practical Example: UML Operations

Let's have a look at an exemplary UML meta-model element and see how it is reflected in tool API's. The example is going to be the UML element Operation, which reflects operations within an interface or class (amongst others). The UML diagram for that element is:

2017-11-02_10h40_47.png

(Image source: UML specification)


The following comparison was based on available information in the online help of the tools. It might differ for newer or other versions of the tools. The list of differences is not exhaustive, but serves to give an impression of the (non-)conformity to the UML meta-model.

Comparison with Enterprise Architect

A few examples on how the API differs from what you might expect from the UML specification:

  • There is no API for "Operation" in EA, the API element is called "Method".
  • UML Operation inherits from a number of other elements (BehavioralFeature, ParameterableElement). EA does not support inheritance in its API elements. That also means that there is no common super-class for elements such as UML Element (EA Element is significantly different from that). Model traversal in EA needs to do a lot of special handling which would not be required when traversing over an UML conformant API.
  • According to UML Specification, UML Operation has a derived attribute "type". This is derived from the first parameter of the list of owned parameters with direction "return". There is no such API in EA Method. The return type is stored separately in a non-standard string attribute called "ReturnType" and there might be arbitrary additional parameters with direction "return".
  • UML specifies an operation "returnResult()" on Operations, which is not reflected in the EA API.
  • Operations are sometimes overriding super class operations or implementing operations defined in Interfaces. UML Operation inherits from RedefinableElement and such can make use of the redefinedOperation/redefinedElement attributes. EA does not have such an API. Instead, it makes use of non-standard definitions of tagged values to internally store the GUID of the redefined element.

Comparison with Rhapsody

  • The API for UML Operation is found in IRPOperation.
  • IRPOperation inherits from IRPInterfaceItem. There is no meta-class "InterfaceItem" in UML.
  • UML Operation specifies parameters in a relation called ownedParameters and uses the meta-model element "Parameter". There is no API named IRPParameter in the Rhapsody API. Instead, there are arguments and the API is called IRPArgument.
  • UML Operation has an operation called "isQuery()" to determine if the element is considered "read-only". There is no such API in IRPOperation.

UML standard and APIs

The few examples above show that the APIs of tools can differ significantly from what one might expect when reading the UML standard. The same holds true when examining more meta-model elements and their APIs. This has a few implications:

  • Knowing the UML standard is not enough for accessing tool APIs. It is necessary to understand the tool API and figure out its mapping to UML, which is sometimes not easily available (e.g. the tagged values approach of EA).
  • Although UML is a standard, tool APIs differ significantly so that any code generators, report generators or custom validations written for those APIs are tied to a specific tool, although they are working on models that are supposed to represent a standard.

The Poster Boys

There are various reasons why tools implement APIs that don't reflect the UML (e.g. flexible data model for supporting additional model types (BPMN,...) and historic reasons). It is a trade-off decision, which will make life for developers more difficult. However, there are also other tools that implement an API which is very conforming to UML specification. These tools could be considered:

  • The free Papyrus tool available at Eclipse, based on the UML EMF implementation that is available at Eclipse. The free Eclipse UML meta-model implementation can be used for own projects to create UML model.
  • MagicDraw by NoMagic. Also has a good export to the UML EMF model implementation.

Easing the Pain with YAKINDU EA Bridge

When working with Enterprise Architect, you can benefit from implementing against an API based on the standard UML specification. The itemis solution YAKINDU EA Bridge leverages the power of the Eclipse UML EMF implementation and provides a powerful facade to the UML model stored in Enterprise Architect. Just implement your generators and validations against the correct UML API, and the YAKINDU EA Bridge will transparently access your EA models. This reduces the effort for implementation significantly and would also allow to reuse the code for other tools that are conforming.

Learn more about EA-Bridge  

Comments