Enterprise Architect (EA) provides a light-weight language extension mechanism called UML Profiles. Especially this mechanism of EA is, in comparison to other tools, very flexible and powerful because such profiles can be used not only to extend UML, but this core UML mechanism can be reused for other languages such as SysML, BPMN, Web Modeling, or your own languages defined as profile. By this, elements of these languages can also by extended, annotated and their graphical notation can be customized.

In this blog entry, I do not want to recall the debates of the last decades on pros and cons of creating new modeling languages either by defining metamodels from scratch (with the additional burden of creating a specific modeling environment and handling their evolution) or by extending the UML metamodel with UML Profiles (which provide only a limited language adaptation mechanism) have been going on. In contrast, I’m going to point out several benefits of using profiles as extension mechanism for different languages (such as UML, SysML or BPMN) in general:

Lightweight language extension. One of the major advantages of UML Profiles is the ability to systematically introduce further language elements without having to re-create the whole modeling environment such as editors, transformations, and model APIs. This also facilitates to test new modeling languages (or new language constructs) easily. Instead of creating a full new modeling language and a dedicated modeling environment from the beginning on, one can start with a UML Profile to validate whether users find the modeling language useful.

Dynamic model extension. In contrast to direct metamodel extensions, also already existing models may be dynamically extended by additional profile information without recreating the extended model elements. One model element may be further annotated with several stereotypes (even contained in different profiles) at the same time which is equivalent to the model element having multiple types. Furthermore, the additional information introduced by the profile application is kept separated from the model and, therefore, does not pollute the actual model instances.

Preventing metamodel pollution. Information not coming from the modeling domain can be represented by additional profiles without polluting the actual domain languages (UML, SysML, etc.). Consider for instance annotating the results of a model review (as known from code reviewing) which shall be attached to the reviewed domain models. Stereotypes concerning model reviews do not particularly relate to the domain and, therefore, should not be introduced in the domain metamodels. Using specific profiles instead helps to separate such concerns from the domain metamodel and keeps the metamodel as it is defined by e.g. standardization organizations.

Model-based representation. Additional information, introduced to the models by profile applications, is accessible and processable like ordinary model information. Consequently, model engineers may reuse familiar model engineering technologies to process profile applications. Due to their model-based representation, profile applications may also be validated against the profile definition to ensure their consistency as it is known from metamodel/model conformance. For this, an EA AddIn would be necessary.