1 Introduction

The use and development of domain-specific languages (DSL) is becoming increasingly important. In recent years, various approaches for developing DSLs have been proposed, which can be divided into two categories. The first category comprises approaches based on formalisms already used for general purpose languages, such as context-free grammars. The advantage is that existing language development tools such as parser generators can be employed for DSLs. The second category encompasses approaches that apply model-driven engineering (MDE) [51], where the most important activity [3, 17, 53] is the design and creation of a metamodel. Typically, a metamodel defines the abstract syntax and static semantics of the DSL to be implemented; it can also capture the semantics of a DSL [3, 49]. Metamodels can be defined using the language concepts of the Meta Object Facility (MOF) [47], either the Essential MOF (EMOF) or the Complete MOF (CMOF). The latter variant is based on EMOF but provides additional language concepts. A higher degree of abstraction and reuse of existing metamodels is achieved by employing the CMOF, which can be advantageous for the creation of more complex DSLs.

Apart from metamodelling, a DSL can also be implemented by customizing the Unified Modeling Language (UML) [40]. Either the UML metamodel can be modified or extended to meet the requirements of a DSL, or so-called UML profiles [11] can be used. Because UML profiles do not alter the UML metamodel, they are considered to be a lightweight extension to the UML [4, 23]. When a UML profile is created, a set of UML stereotypes is introduced. A stereotype is a specific type of UML element that adds additional attributes, operations, and constraints to a metaclass. Different manual or generative approaches for implementing a DSL based on UML profiles can be found in the literature, e.g. in [15, 30, 50].

While working on a new version of the UML profile [20] for the Specification and Description Language (SDL) [21], we found several shortcomings [24, 25] in the old edition [18], which resulted from the manual creation of the profile. The well-formedness rules of this profile are captured in natural language, not in a machine-processable language such as the Object Constraint Language (OCL) [45] that is used in the metamodelling domain. To create a toolchain [26] for the UML profile for SDL, we manually translated the well-formedness rules into OCL constraints. During this process, we noticed that these rules are often ambiguous. Likewise, the well-formedness rules of other standardised DSLs (e.g. [37, 42, 43]) are frequently provided only in natural language.

To remedy the shortcomings of hand-crafted UML profiles, we propose an approach for the fully automated derivation of UML profiles from CMOF-based metamodels. This is especially relevant for DSLs, for which a metamodel and a corresponding UML profile shall be created, which is often the case for standardized DSLs such as [6, 43, 44, 46]. In contrast to a manual derivation of UML profiles from metamodels as proposed in [30, 50, 54], our approach performs this task fully automatically. In addition to generating model elements for a UML profile, our approach also enables the transfer of the OCL-defined static semantics of a metamodel to such a profile. While the work presented in [13, 14] also supports this, the OCL constraints of a metamodel must be revised manually before they can be copied to a UML profile, whereas this is not required by our approach. Furthermore, we enable the mapping of subsetting or redefining metaclass attributes to OCL-defined stereotype attributes, which is a novel feature compared to [13, 14, 48]. Moreover, our approach supports the semi-automatic generation of CMOF-based metamodels from grammar production rules and of model transformations for model interoperability from DSL models to UML models with applied profile, and vice versa.

The remainder of this article is structured as follows. The next section provides an overview of our approach, while we detail the derivation of UML profiles from metamodels in Sec. 4. Then, we discuss our automatic transfer of the OCL-defined static semantics in Sec. 5. Based on a case study for the Test Description Language (TDL) [6], which is an international standard maintained by the European Telecommunications Standards Institute (ETSI), we evaluate the results of our approach described in Sec. 6. Finally, we discuss the related work in Sec. 7, while Sec. 8 presents our summary and conclusions.

The concepts of our derivation approach have already been sketched as extended abstract in [28], and its applicability to automatically derive a UML profile for SDL has been demonstrated in another extended abstract [27]. In the present article, we give a fully comprehensive insight into our derivation of UML profiles and our automatic transfer of the OCL-defined static semantics. In particular, we detail our considerations that inspired this derivation approach. Furthermore, we analyse the applicability of our derivation approach based on a further case study involving TDL. To evaluate all aspects of our approach and to conduct case studies on SDL and TDL, we implemented the DSL Metamodeling and Derivation Toolchain (DSL-MeDeTo) [58] in Eclipse.

2 Overview

This section provides an overview of our overall approach to derive a metamodel, a UML profile, and model transformations for model interoperability. In addition, we give a short introduction to our DSL-MeDeTo toolchain that implements our approach.

2.1 Our overall approach

Our overall derivation approach shown in Fig. 1 consists of Steps (A)–(E), some of which are optional. The DSL-specific metamodel \(\textit{MM}_{Domain}\) is the central artefact for almost all derivations. If production rules of a grammar-based DSL are available, the metamodel can be generated semi-automatically in Step (A); otherwise, it has to be created manually.

To obtain a metamodel that does not require too much effort for further refinement (e.g. adding additional metaclasses), we reuse ‘Abstract Concepts’ that are defined by an existing metamodel (\(\textit{MM}_{AC}\)), as proposed in [10, 49]. Apart from these works, the reuse of artefacts of existing languages is recommended in other works, e.g. in [3, 22]). In contrast to the approach proposed in [10, 49], we use particular annotations for a given DSL’s production rules so that relationships between generated metaclasses and the ‘Abstract Concepts’ must not be created manually.

We define ‘Abstract Concepts’ as a set of generic language concepts that are commonly shared across several DSLs and not only applicable to a specific language. For example, language concepts such as generalization or redefinition can be regarded as ‘Abstract Concepts’. Furthermore, we assume that each ‘Abstract Concept’ is represented by a particular metaclass contained in \(\textit{MM}_{AC}\).

Fig. 1
figure 1

Transformation steps and their derived artefacts

If we derive \(\textit{MM}_{Domain}\) from production rules in Step (A)Footnote 1, we have to review and, if necessary, refine it before it can be used as input for Steps (B)–(E). In particular, it must be assessed whether all metaclasses derived for \(\textit{MM}_{Domain}\) are required from a semantic point of view, and if not, the affected ones must be removed. Otherwise, we create \(\textit{MM}_{Domain}\) from scratch. To do so, we copy the ‘Abstract Concepts’ from \(\textit{MM}_{AC}\) to \(\textit{MM}_{Domain}\). Then, we capture the abstract semantics of the DSL of interest by creating appropriate metaclasses. Thereafter, we use inheritance relationships to associate these metaclasses with the ‘Abstract Concepts’ copied to \(\textit{MM}_{Domain}\). Finally, we capture the DSL’s static semantics via OCL constraints and enrich \(\textit{MM}_{Domain}\) with toolchain-specific meta-information. For this purpose, we apply the UML profile ‘MM2Profile’ to \(\textit{MM}_{Domain}\) as shown in Fig. 1. This UML profile contains five stereotypes and a set of constraints (see Sec. 4.2) that ensure a proper processing of \(\textit{MM}_{Domain}\) via our toolchain.

After creating \(\textit{MM}_{Domain}\), we can automatically derive a DSL-specific UML profile \(\textit{UP}_{Domain}\) in Step (B). If required, additional metaclasses (contained in \(\textit{MM}_{Add}\)) that extend the \(\textit{MM}_{UML}\) are derived in Step (C). The derivation of additional metaclasses may be an option if stereotypes cannot be employed due to their restrictions as defined by the UML [41]. For instance, such an approach is applied for the value and expression languages of the SDL-UML profile [20] and of the MARTE profile [42]. Because the input and output artefacts of Steps (B) and (C) are models, we realize both derivations by two dedicated Model-to-Model (M2M) transformations.

In Steps (D) and (E), we derive two M2M transformations that can be used to obtain model interoperability between DSL-specific models and UML models with an applied UML profile. For this purpose, we develop two Model-to-Text (M2T) transformations that generate the source code of the M2M transformations \(\textit{T}_{DM-to-UML}\) and \(\textit{T}_{UML-to-DM}\), resp.

Even though our automatic derivation approach eliminates the need for manual creation of UML profiles, the quality of these artefacts depends significantly on the experience of the language engineer who manually created the metamodels used as input. As with other hand-crafted software artefacts, metamodels can contain errors due to manual creation. Therefore, metamodels used as input for our derivation approach should be subject to quality assurance.

2.2 The ‘Abstract Concepts’

The metamodel \(\textit{MM}_{AC}\) holds a key role for our entire derivation approach, because metaclasses of the metamodel \(\textit{MM}_{Domain}\) inherit from ‘Abstract Concepts’ defined by \(\textit{MM}_{AC}\). An important prerequisite for \(\textit{MM}_{AC}\) is that it must match a subset of \(\textit{MM}_{UML}\). Otherwise, a straightforward mapping of \(\textit{MM}_{Domain}\) to \(\textit{UP}_{Domain}\), as implemented by our approach, is impossible.

We consider a metamodel \(\textit{MM}_{AC}\) to be matching with \(\textit{MM}_{UML}\), if the following constraints are fulfilled:

Constraint 1

For each metaclass MC of \(\textit{MM}_{AC}\), a corresponding metaclass MC’ with an equal name shall be present in \(\textit{MM}_{UML}\). In addition, MC shall have an equal or lesser number of attributes than MC’.

This constraint is essential for the derivation of UML profiles according to our approach, because the UML metaclasses to be extended by Stereotypes are identified based on the correlation between ‘Abstract Concepts’ and UML metaclasses. To determine such a correlation, we employ the name property of the metaclasses. Even though an ‘Abstract Concept’ may have fewer attributes than the corresponding UML metaclass, we consider a correlation as given. For instance, such a situation may occur if some attributes of an ‘Abstract Concept’ are removedFootnote 2 because they are not required to define the syntax of a DSL.

Constraint 2

For each attribute att of a metaclass MC, a corresponding attribute att’ with an equal name shall be present in metaclass MC’. In addition, att and att’ shall have the same properties, especially the same type and multiplicity.

The condition imposed by Constraint 2 is important because OCL constraints in \(\textit{MM}_{Domain}\) may capture attributes of ‘Abstract Concepts’. When deriving a UML profile, such an attribute access must be translated into an access to a UML metaclass attribute. In addition, attributes of metaclasses in \(\textit{MM}_{Domain}\) may redefine or subset ‘Abstract Concept’ attributes. During the UML profile derivation, we have to translate such attribute relationships into appropriate constructs that access UML metaclass attributes.

In addition to metaclasses, the ‘Abstract Concepts’ may contain DataTypes. Therefore, each of these DataTypes must have a corresponding type in \(\textit{MM}_{UML}\). We capture this condition by the following constraint:

Constraint 3

A data type in \(\textit{MM}_{AC}\) shall have a corresponding data type in \(\textit{MM}_{UML}\).

Different approaches can be applied to obtain a metamodel \(\textit{MM}_{AC}\). Apart from creating such a metamodel from scratch, Clark et al. [3] argue that also a reuse of metaclasses of an existing metamodel, by copying or importing them, can be considered. Because \(\textit{MM}_{AC}\) shall match with \(\textit{MM}_{UML}\), we consider a creation of \(\textit{MM}_{AC}\) from scratch to be too error-prone and expensive. Another option is to use the MOF or the UML Infrastructure Library [39]. Because the metaclasses of these metamodels are primarily employed to define UML’s ‘Kernel’ package, they may be reused to create an \(\textit{MM}_{AC}\) that only supports structural language concepts (e.g. Classifier). Finally, also the reuse of parts of \(\textit{MM}_{UML}\) may be considered if language concepts for behavioural specifications (e.g. StateMachines) are required.

Our approach does not support the import of metaclasses; otherwise, there would be a dependency between \(\textit{MM}_{Domain}\) and the metamodel from which the metaclasses are imported. In addition, imported metaclasses cannot be modified. For example, it is impossible to remove non-required features from them. Therefore, we assume that \(\textit{MM}_{AC}\) is created manually as a copy, or automatically using the Package Merge feature provided by the CMOF.

2.3 The DSL metamodelling and derivation toolchain

We have implemented all aspects of our approach in the novel DSL Metamodelling and Derivation Toolchain (DSL-MeDeTo) [58] using well-established standards and open source components. We choose the Model Development Tools (MDT)Footnote 3 edition of Eclipse to realize our toolchain, which consists of a set of particular plug-ins as shown in Fig. 2. To create a metamodel or to derive other artefacts such as UML profiles, the components of our toolchain have access to a common model repository. Because our derivation approach is designed for CMOF-based metamodels, we have to employ UML models instead of Ecore models [52]. The code generators of Eclipse-MDT can handle both formats. The most important plug-ins of our toolchain are:

Fig. 2
figure 2

The Eclipse-based toolchain and its components

Textual editor. The textual editor enables the specification of production rules for the DSL or computer language of interest. In addition, the production rules can be associated with different types of annotation, e.g. to define a relationship to the ‘Abstract Concepts’. The parsed production rules are stored by the textual editor in an intermediate model-based format; thus, they can be transformed to a metamodel by employing an M2M transformation. As we have made good experiences with Spoofax for creating our SU-MoVal framework [26], we also employed this DSL workbench to create the textual editor for DSL-MeDeTo.

UML profile ‘MM2Profile’. The UML profile ‘MM2Profile’ is used to enrich a metamodel \(\textit{MM}_{Domain}\) with additional information, which is processed by different components of DSL-MeDeTo. The application of this UML profile to a metamodel \(\textit{MM}_{Domain}\) is a prerequisite for the derivation of a UML profile \(\textit{UP}_{Domain}\) and of the additional metaclasses \(\textit{MM}_{Add}\). In addition, ‘MM2Profile’ defines a set of OCL constraints that must be met by \(\textit{MM}_{Domain}\) so that its processing by our toolchain is sound. More details of ‘MM2Profile’ are discussed in Sec. 4.2.

OCL Updater. Before the metamodel \(\textit{MM}_{Domain}\) with applied ‘MM2Profile’ can be used for the derivation of other artefacts, all its OCL-defined Operations, Properties and Constraints have to be adapted in such a way that they can be utilized for a derived UML profile. This adaptation is implemented by the ‘OCL Updater’ component, which consists of an OCL parser and a pretty printer. The update is based on the abstract syntax tree (AST) of a parsed OCL expression, as argued in Sec. 5.

M2M transformations. We employ the operational language of the Query/View/Transformation specification (QVT) [38] for implementing three M2M transformations that are used by DSL-MeDeTo to derive different kinds of artefacts. The first transformation implements Step (A) of our approach; its output is the CMOF-based metamodel \(\textit{MM}_{Domain}\). A second transformation derives the UML profile \(\textit{UP}_{Domain}\) from \(\textit{MM}_{Domain}\) (Step (B)). Optionally, the ‘additional’ metaclasses for \(\textit{MM}_{Add}\) can be created with a third transformation (Step (C)).

M2T transformations. We use the MOF M2T Language (MTL) [36] for realizing two M2T transformations: the M2T transformation \(\textit{T}_{GenDM-to-UML}\) is employed to generate the M2M transformation \(\textit{T}_{DM-to-UML}\) in Step (D), while \(\textit{T}_{GenUML-to-DM}\) generates \(\textit{T}_{DM-to-UML}\) in Step (E). The source code of both M2M transformations is generated in terms of the operational language of QVT. We utilize the AcceleoFootnote 4 component of Eclipse to execute both M2T transformations.

Model editors. Apart from the discussed components, either Eclipse’s UML tree editor or the UML modelling tool PapyrusFootnote 5 can be used for creating or modifying the metamodels that are processed by our toolchain (see Fig. 2). Hence, one of these tools also has to be utilized for applying the UML profile ‘MM2Profile’ to a metamodel.

3 Running example

The Test Description Language (TDL) [6] is a new DSL [32, 55] for the design and specification of test descriptions. Its development and standardization is driven by the European Telecommunications Standards Institute (ETSI). Because a metamodel [6] and a corresponding UML profile are available, we employ TDL as an exemplary DSL for our case study in Sec. 6 in order to investigate the applicability of our derivation approach. Furthermore, TDL serves us as running example to illustrate the various steps in deriving a UML profile from a CMOF-based metamodel.

Fig. 3
figure 3

Data and test configuration definition example ([7]—Annex A.1), specified in TDL’s graphical notation

Background. Ulricht et al. [55] point out that TDL bridges the gap between high-level test requirement specifications and executable test cases. Thus, TDL test descriptions can serve as the basis to create executable test cases in any kind of target language, such as the Testing and Test Control Notation-Version 3 (TTCN-3) [8]. Because TDL is a new language, the literature concerning the application of TDL is rather limited. Marroquin et al. [34] report on a successful application of TDL in the telecommunications domain. The automatic derivation of TDL test descriptions from Use Case Maps (UCM) is discussed by Boulet et. al [2]. A TDL test description consists of the following parts:

Test configuration::

A test configuration defines the tester components and the components of a system under test (SUT) involved in a particular test scenario. All components communicate among each other via defined gates and associated connections.

Test descriptions::

A particular test scenario is described in terms of a test description that defines the set of interactions between the test and SUT components of its associated test configuration. Various types of behavioural elements are available for specifying the control flow of a test description, e.g. sequential or parallel behaviour.

Data definitions::

Data types can be specified as simple or structured data types, and their instances are used in interactions or can be passed as arguments for the invocation of parameterized test descriptions.

Behavioural elements::

The various behavioural element types can be used to define the control flow, send messages, start and stop timers, or set the test result.

A TDL test description example is given in Fig. 3. The shown diagram contains the definitions of data types and associated data instances. In addition, the ‘DataResourceMapping’ elements are used to specify a resource that contains an external representation for data types or their instances. Such an external representation is identified by a ‘DataElementMapping’. For instance, the structured data type MSG is associated with the ‘DataResourceMapping’.

Apart from data type definitions, the shown diagram also contains a TestConfiguration consisting of a tester and an SUT component. Because both components are instances of the ComponentType DefaultCTwithVariable, each of them owns a gate, which is of type defaultGT. The gates of the component instances are interconnected via a Connection.

Based on the type definitions and their instances, we can specify the behaviour of an TDL test description. The notation employed for TDL’s test behaviour is similar to Message Sequence Charts (MSC) [19].

4 The derivation of UML profiles

As claimed in Introduction, we can automatically derive a UML profile based on a metamodel for a DSL in Step (B) of our approach. In this section, we first discuss the design decisions of our derivation approach. Then, we treat the prerequisites for the suitability of a metamodel as input for our UML profile derivation, and also consider the enrichment of a metamodel with information that is required for the derivation. Thereafter, we discuss the details of our approach.

4.1 Design decisions for the profile derivation

As our objective is to derive a UML profile and optionally ‘additional’ metaclasses, the metaclasses contained in the metamodel \(\textit{MM}_{Domain}\) have to be processed in different ways. In addition, we have to consider that \(\textit{MM}_{Domain}\) also contains metaclasses that represent ‘Abstract Concepts’. Hence, we presume that the metaclasses in \(\textit{MM}_{Domain}\) can be divided into three different sets. The first set represents ‘Abstract Concepts’; a metaclass of this set is denoted as \(\textit{MC}_{AC}\). The second set includes those metaclasses that shall be mapped to Stereotypes of the derived UML profile \(\textit{UP}_{Domain}\). We use the term \(\textit{MC}_{St}\) to refer to a metaclass of this set. The third set contains metaclasses that map to ‘additional’ metaclasses in the metamodel \(\textit{MM}_{Add}\). A metaclass of this set is denoted by \(\textit{MC}_{AMC}\).

Design Decision 1

A metamodel \(\textit{MM}_{Domain}\) consists of a set of \(\textit{MC}_{AC}\) metaclasses, a set of \(\textit{MC}_{St}\) metaclasses, and an optional set of \(\textit{MC}_{AMC}\) metaclasses.

Each ‘Abstract Concept’ metaclass has a ‘matching’ UML metaclass in \(\textit{MM}_{UML}\), and their names are prefixed with ‘AC_’ to avoid name clashes with those metaclasses that are generated based on production rules. Hence, we do not map \(\textit{MC}_{AC}\) metaclasses contained in \(\textit{MM}_{Domain}\). In addition, we employ the name prefix to identify that a metaclass of \(\textit{MM}_{Domain}\) is an \(\textit{MC}_{AC}\) metaclass.

Design Decision 2

An ‘Abstract Concept’ metaclass \(\textit{MC}_{AC}\) has a name prefix ‘AC_’ and is not mapped to any kind of element.

Hence, all metaclasses without a name prefix are \(\textit{MC}_{St}\) or \(\textit{MC}_{AMC}\) metaclasses. To make a clear distinction between these two metaclass types, an additional qualifier is required. As the derivation of ‘additional’ metaclasses is optional, it is sufficient to use such a qualifier only for \(\textit{MC}_{AMC}\) metaclasses. For this reason, we define metaclasses that have no special qualifier or name prefix as \(\textit{MC}_{St}\) metaclasses. By default, we use this type of metaclasses of \(\textit{MM}_{Domain}\) to derive Stereotypes for a UML profile, as shown in Fig. 4.

Fig. 4
figure 4

Mapping of metaclasses to Stereotypes

Design Decision 3

A metaclass of \(\textit{MM}_{Domain}\) without a qualifier is assumed to be an \(\textit{MC}_{St}\) metaclass, whereas a metaclass with existing qualifier represents an \(\textit{MC}_{AMC}\) metaclass.

“An element imported as a metaclassReference is not specialized or generalized in a Profile” [41, Sec. 12.4.7.5].

“A Stereotype may only generalize or specialize another Stereotype” [41, Sec. 12.4.9.6].

Hence, a Stereotype is not permitted to generalize a UML metaclass. Instead, an Extension association has to be used. Consequently, we introduce an Extension for each Stereotype, which is derived from an \(\textit{MC}_{St}\) that inherits directly from an \(\textit{MC}_{AC}\) in \(\textit{MM}_{Domain}\). For example, an Extension is introduced only for Stereotypes derived from metaclasses \(\textit{MC}_{St}\) A and \(\textit{MC}_{St}\) D in Fig. 4.

Design Decision 4

An Extension shall be introduced for each Stereotype, which is derived from an \(\textit{MC}_{St}\) metaclass that directly inherits from an \(\textit{MC}_{AC}\) metaclass.

In contrast to the previous case, a Stereotype can inherit from another Stereotype without restrictions. Therefore, we can introduce a Generalization between two Stereotypes that are derived from two \(\textit{MC}_{St}\) metaclasses that are in a Generalization relationship (e.g. metaclasses \(\textit{MC}_{St}\) E and \(\textit{MC}_{St}\) D in Fig. 4).

Design Decision 5

A Generalization is introduced for each Stereotype that is derived from an \(\textit{MC}_{St}\) metaclass that inherits directly from another \(\textit{MC}_{St}\) metaclass.

One of our key objectives for the derivation of a UML profile is the preservation of the syntactic structure defined by a metamodel. This is a prerequisite for transferring the OCL-defined static semantics of a metamodel to a UML profile. Therefore, we map each Property that is an ownedAttribute of an \(\textit{MC}_{St}\) to a corresponding Property of a Stereotype. However, we have to obey the following rule of the UML specification:

“The type of a composite aggregation Stereotype Property cannot be a Stereotype (since Stereotypes are owned by their Extensions) or a metaclass (since instances of metaclasses are owned by other instances of metaclasses)” [41, Sec. 12.3.3.4].

Therefore, we map an \(\textit{MC}_{St}\) attribute whose type property refers to a metaclass, to a stereotype attribute whose aggregation property has value ‘none’. Thus, this stereotype attribute represents a reference to a metaclass instance.

Design Decision 6

An \(\textit{MC}_{St}\) attribute is mapped to a corresponding Stereotype attribute. If the type property of an \(\textit{MC}_{St}\) attribute refers to a metaclass, the aggregation property of the mapped Stereotype attribute shall have value ‘none’.

If an ownedAttribute of an \(\textit{MC}_{AC}\) is redefined or subsetted by an ownedAttribute of an \(\textit{MC}_{St}\), this kind of relationship cannot be preserved for a derived UML profile. This is caused by the two UML constraints above and the fact that redefinition and subsetting can only be used for Classes that are in a direct or indirect inheritance relationship.

In general, such metaclass attributes may be mapped to stereotype attributes in two different ways. The first possibility is a one-to-one mapping to a stereotype attribute, where existing redefinition/subsetting relationships are removed. However, the drawback of this approach is that values for stereotype attributes have to be assigned manually. The second option is to map a metaclass attribute to a ‘derived’ stereotype attribute whose value is computed automatically via an OCL expression at runtime. Because of this advantage, we choose the latter option.

Design Decision 7

An \(\textit{MC}_{St}\) attribute that redefines or subsets an \(\textit{MC}_{AC}\) attribute is mapped to a derived and read-only stereotype attribute, and an OCL expression is introduced as its defaultValue.

When specifying a UML model, a model element must be created before a stereotype can be applied to it. While the model element is always located at a certain position in the UML model, the instance of its applied stereotype is not directly contained in the model. However, the UML model and associated stereotype instances are contained in the same resource or container. This fact could become an issue when the type of an ownedAttribute of a Stereotype refers to another Stereotype. In this case, the designer of a UML model has to identify a valid Stereotype instance that shall be assigned as value for a Stereotype attribute, which is non-trivial because Stereotype instances have no unique identification feature.

Consequently, we do not use a Stereotype as the type of a stereotype attribute; instead, we refer to a UML metaclass that is extended by a Stereotype, or to an ‘additional’ metaclass contained in the \(\textit{MM}_{Add}\) metamodel.

Design Decision 8

The type property of an stereotype attribute either refers to a UML metaclass that is extended by a Stereotype, or to an ‘additional’ metaclass in \(\textit{MM}_{Add}\).

Fig. 5
figure 5

Inheritance and the type of a stereotype attribute

The discussed recomputation of the type of a stereotype attribute also affects the modelling of inheritance relationships between \(\textit{MC}_{St}\) and \(\textit{MC}_{AC}\) metaclasses in \(\textit{MM}_{Domain}\). As long as an \(\textit{MC}_{St}\) only inherits from a single \(\textit{MC}_{AC}\), there are no restrictions on the modelling of \(\textit{MM}_{Domain}\). But this is not the case for multiple inheritance.

Assume that an \(\textit{MC}_{St}\) A that inherits from at least two \(\textit{MC}_{AC}\) metaclasses is used as the type of a metaclass attribute att_A, and the \(\textit{MC}_{St}\) is mapped to a Stereotype A, as shown in Fig. 5a. According to Design Decision 4, this stereotype would have two Extension associations with different UML metaclasses. Due to Design Decision 8, two possibilities would exist as type of the mapped attribute att_A.

To avoid this ambiguity, we must ensure that a derived Stereotype has only an Extension to a single UML metaclass. One possible solution would be that an \(\textit{MC}_{St}\) of \(\textit{MM}_{Domain}\) inherits from at most one \(\textit{MC}_{AC}\), so that only one Extension would be derived for a Stereotype. However, this approach would require a modification of \(\textit{MM}_{Domain}\), or its modelling would become too restrictive. Hence, we consider this approach to be inappropriate.

Another solution would be to introduce a specific kind of metadata that can be attached to an \(\textit{MC}_{St}\), so that the UML metaclass to be extended by a Stereotype can be defined explicitly. Because this approach does not require a modification of \(\textit{MM}_{Domain}\), we prefer this solution.

Design Decision 9

A particular kind of meta-information (e.g. provided by an applied stereotype) shall be applicable to an \(\textit{MC}_{St}\) so that the UML metaclass to be extended by a Stereotype can be defined explicitly.

For the sake of completeness, it is mentioned that an \(\textit{MC}_{St}\) can also inherit from an \(\textit{MC}_{AC}\) and one or more \(\textit{MC}_{St}\) metaclasses, as shown in Fig. 5b. In contrast to the previous scenario, no ambiguities for the determination of the type property of a stereotype attribute exist, because a derived Stereotype has only a single Extension to a UML metaclass. Due to Design Decision 8, Generalizations to other Stereotypes do not affect type determination.

A metaclass attribute can redefine and subset other attributes at the same time. In addition, a metaclass attribute cannot only redefine or subset a single attribute, but also several attributes. We have to consider this when introducing OCL expressions as substitute for redefining or subsetting attributes (see Design Decision 7).

Because subsetting or redefinition of several attributes usually occurs only in the case of multiple inheritance, we must pay particular attention to Design Decision 9, which requires that a derived stereotype extends only a single UML metaclass. Thus, only attributes of this UML metaclass can be invoked in generated OCL expressions for stereotype attributes. Hence, in the case of multiple inheritance, we must either be able to specify which UML metaclass attributes should be invoked in OCL expressions, or there must be a possibility to provide OCL expressions manually.

Table 1 Properties that redefine and/or subsets other properties of UML metaclasses (analysis based on the UML metamodel [40])

To decide which solution shall be implemented by our derivation approach, we have analysed the UML metamodel concerning the utilization of ‘subsetting’ and ‘derivation’. The results are summarized in Table 1. Based on these, we suppose that the ‘subsetting’ of a single attribute (75.7%) is much more common than that of multiple attributes (13.7%). A similar situation exists for ‘redefinition’, whereas a combined use of ‘redefinition’ and ‘subsetting’ (1%) can be considered as a rarely used special case. Hence, we automatically introduce OCL expressions only for such stereotype attributes derived from \(\textit{MC}_{St}\) attributes, which ‘redefine’ or ‘subset’ a single attribute. In all other cases, we prefer a manual specification of OCL expressions.

Design Decision 10

An ownedAttribute of an \(\textit{MC}_{St}\) can have an alternative OCL expression, which is used as defaultValue of a corresponding stereotype attribute.

Due to Design Decision 8, we recompute the type property of a stereotype attribute so that it refers to a UML metaclass. A disadvantage is that syntactically invalid values can be assigned to such kind of attribute. For example, a value assigned to a stereotype attribute may have the correct UML type, but it may have applied an invalid stereotype. Therefore, we introduce OCL constraints to ensure that only those UML elements having applied a particular stereotype can be assigned to such stereotype attributes. However, we do not generate OCL constraints for ‘derived’ and ‘read-only’ stereotype attributes, because no values can be assigned to them manually (Design Decision 7).

Design Decision 11

An OCL Constraint is created for each Stereotype attribute that is not defined as ‘derived’ and ‘read-only’ and that is mapped from an \(\textit{MC}_{St}\) attribute with a type property that refers to an \(\textit{MC}_{St}\).

Even though we do not introduce OCL constraints for ‘derived’ and ‘read-only’ stereotype attributes, this does not apply for those UML metaclass attributes that are employed as computational basis for the defaultValue of stereotype attributes (Design Decision 7). Because of the same reason as above, only UML elements having applied a particular stereotype shall be assignable to such UML metaclass attributes. Hence, we introduce appropriate OCL constraints. We identify the UML metaclass attributes that shall be constrained based on the redefinition and subsetting relationships of \(\textit{MC}_{St}\) attributes.

Design Decision 12

An OCL Constraint is created for each UML metaclass attribute that is the computation base for the value of a ‘derived’ and ‘read-only’ stereotype attribute.

4.2 Enriching the source metamodel

Provided that \(\textit{MM}_{Domain}\) is generated from production rules in Step (A) of our approach, we can use it directly as input for the UML profile derivation. By definition, we consider that such a metamodel contains a set of \(\textit{MC}_{AC}\) metaclasses and a set of \(\textit{MC}_{St}\) metaclasses (Design Decisions 2 and 3). In this case, we determine the UML metaclass to be extended by a derived Stereotype based on the inheritance relationships of the source \(\textit{MC}_{St}\) in \(\textit{MM}_{Domain}\).

However, the direct use of \(\textit{MM}_{Domain}\) to derive a UML profile is not always possible. For example, we cannot define that, instead of a ‘matching’ UML metaclass, one of its subtypes shall be extended by a Stereotype. Therefore, the stereotypes of our UML profile ‘MM2Profile’ presented below must be applied to metaclasses of \(\textit{MM}_{Domain}\).

As shown in Fig. 6, the UML profile ‘MM2Profile’ consists of five stereotypes that extend four different UML metaclasses. Except for stereotype \(<<\) MM2Profile \(>>\) that is automatically applied to a Package element, the application of all other stereotypes is optional. We thus enable the application of these stereotypes only in cases when additional information is required for the derivation.

Fig. 6
figure 6

Stereotypes of the UML profile ‘MM2Profile’

The \(<<\)MM2Profile\(>>\) stereotype Because this stereotype has an Extension that is specified as required, it is automatically applied to the Package that represents \(\textit{MM}_{Domain}\). Most of the stereotype attributes define input parameters for the code generator of Eclipse and, therefore, are passed directly to the derived UML profile and to the metamodel \(\textit{MM}_{Add}\).

While attributes prefixed with ‘profile’ are passed to the derived UML profile \(\textit{UP}_{Domain}\), all attributes with the ‘add’ prefix are passed to the metamodel \(\textit{MM}_{Add}\) that contains the ‘additional’ metaclasses.

The \(<<\)ToStereotype\(>>\) stereotype If the default creation of a Stereotype according to our approach is infeasible, the attributes of the \(<<\) ToStereotype \(>>\) can be used as follows:

extendedMetaclass:

overrides the automatically determined UML metaclass to be extended by a Stereotype.

alternativeName:

defines an alternative name for a derived Stereotype.

noMapping:

determines whether a Stereotype is generated for the current \(\textit{MC}_{St}\) metaclass.

The \(<<\)ToMetaclass\(>>\) stereotype According to Design Decision 3, an additional qualification for an \(\textit{MC}_{AMC}\) metaclass in \(\textit{MM}_{Domain}\) is required. Hence, we employ the stereotype \(<<\) ToMetaclass \(>>\) to define that a metaclass of \(\textit{MM}_{Domain}\) represents an \(\textit{MC}_{AMC}\) metaclass. The \(<<\) ToMetaclass \(>>\) stereotype provides the following attributes:

alternativeName:

defines an alternative name for an ‘additional’ metaclass contained in \(\textit{MM}_{Add}\).

superClass:

overrides the automatically determined UML metaclass from which an ‘additional’ metaclass inherits.

The \(<<\)ToTaggedValue\(>>\) stereotype We employ this stereotype to explicitly define a name or to specify an alternative OCL expression (used as defaultValue) for an attribute of a derived Stereotype. To support these, the \(<<\) ToTaggedValue \(>>\) stereotype provides the following attributes:

alternativeName:

defines an alternative name for an ownedAttribute of a derived Stereotype.

oclSpecification:

defines an OCL expression that is used as defaultValue for an ownedAttribute of a Stereotype.

derivationSource:

specifies the computation source for the oclSpecification.

Fig. 7
figure 7

An excerpt of the metamodel \(\textit{MM}_{TDL}\)

The \(<<\)OmitGeneralization\(>>\) stereotype A metaclass can have more than one Generalization relation to other metaclasses. However, for the derivation of a UML profile, it may be required that a Generalization to a particular metaclass is not taken into account. This can be specified by applying the \(<<\) OmitGeneralization \(>>\) stereotype to a Generalization contained in \(\textit{MM}_{Domain}\).

For example, assume an \(\textit{MC}_{St}\) A is given that inherits from an \(\textit{MC}_{AC}\) at a high level of abstraction (e.g. AC_ Namespace) and another \(\textit{MC}_{AC}\) (e.g. AC_DataType). In this case, we want to prevent that the stereotype derived from A extends the UML metaclass Namespace. To achieve this, we apply the \(<<\) OmitGeneralization \(>>\) stereotype to the Generalization from A to AC_Namespace.

4.3 TDL Example: Input Metamodel

TDL’s standardized metamodel \(\textit{MM}_{std}\) is divided into several Packages, one of which is the Foundation package. The metaclasses contained in this package define generic language concepts, such as NamedElement and PackageableElement. These metaclasses are comparable to those contained in the UML ‘Kernel’ package. Thus, one can assume that these metaclasses of \(\textit{MM}_{std}\) already correspond to the \(\textit{MC}_{AC}\) metaclasses required by our approach. However, differences in syntax and semantics exist. For instance, metaclass attributes contained in TDL’s Foundation package do not match those of UML metaclasses. Because identically named attributes of ‘Abstract Concepts’ and UML metaclasses are a prerequisite (see Sec. 2.2) of our derivation approach, we cannot use \(\textit{MM}_{std}\) as input to derive a UML profile. Therefore, we have aligned \(\textit{MM}_{std}\) to meet the requirements of our derivation approach. Below, we refer to the revised metamodel of TDL using the term \(\textit{MM}_{TDL}\).

To obtain \(\textit{MM}_{TDL}\), we replace the metaclasses contained in TDL’s Foundation package with equally named metaclasses of the UML Kernal package. Then, we put the copied metaclasses in inheritance relationships to TDL’s metaclasses by introducing Generalization relationship. Furthermore, we redefine or subset the attributes inherited from the copied metaclasses where required. Finally, we apply our UML profile MM2Profile to enrich \(\textit{MM}_{TDL}\) with the meta-information that we require to derive a UML profile.

Fig. 8
figure 8

Introduced Extensions and Generalizations in \(\textit{UP}_{TDL}\)

An excerpt of our modified \(\textit{MM}_{TDL}\) is shown in Figs. 7a and 7b, where the contained metaclasses define the syntax of TDL’s data types and test configurations. Some of the metaclasses (e.g. MappableDataElement) and attributes contained in the figures have stereotypes of our UML profile MM2Profile applied. We assume that metaclasses whose names start without the prefix ‘AC_’ represent \(\textit{MC}_{St}\) metaclasses that are mapped to Stereotypes.

Without additional meta-information, a Stereotype derived from the DataType metaclass shown in Fig. 7a would extend the UML metaclass Type or Namespace. Consequently, this Stereotype could then be applied to all UML elements that are instances of subclasses of these UML metaclasses. This would not correspond to the syntax specified by the \(\textit{MM}_{TDL}\) metamodel. Applying the \(<<\) ToStereotype \(>>\) stereotype on an \(\textit{MC}_{St}\) metaclass remedies this issue, because its extendedMetaclass attribute can be employed to explicitly specify the UML metaclass to be extended by a Stereotype.

As the abstract metaclass MappableDataElement has neither constraints, nor attributes, or operations, we do not intend to derive a Stereotype for it. For this reason, we apply the \(<<\) ToStereotype \(>>\) stereotype to this metaclass and assign the value ‘true’ to its noMapping attribute.

We use the \(<<\) ToTaggedValue \(>>\) stereotype to prevent an \(\textit{MC}_{St}\) attribute being mapped according to the default rules of our derivation approach. An \(\textit{MC}_{St}\) attribute marked in this way is mapped to a stereotype attribute that is defined as ‘read-only’ and ‘derived’, and the oclSpecification of the applied \(<<\) ToTaggedValue \(>>\) stereotype is employed to define the defaultValue. For instance, the \(\textit{MC}_{St}\) attributes dataType and memberAssignment in Fig. 7a have the \(<<\) ToTaggedValue \(>>\) stereotype applied.

4.4 Our derivation approach

In the following, we discuss the details of our approach for deriving a UML profile \(\textit{UP}_{Domain}\) from a metamodel \(\textit{MM}_{Domain}\) that is enriched with the UML profile MM2Profile. To illustrate certain aspects of our approach, we use the \(\textit{MM}_{TDL}\) metaclasses and their corresponding Stereotypes in the UML profile \(\textit{UP}_{TDL}\) shown in Fig. 7. In addition to explaining our derivation approach by examples in this paper, we detail the various derivation steps using pseudocode in [29].

4.4.1 Mapping to ‘Stereotypes’

The first step of our approach to derive a UML profile \(\textit{UP}_{Domain}\) from a metamodel \(\textit{MM}_{Domain}\) consists in the creation of Stereotypes. Therefore and as argued for Design Decision 3, we create a Stereotype and map various properties (e.g. name and isAbstract) of the source \(\textit{MC}_{St}\) one-to-one to its corresponding properties, while a few properties must be processed in a particular manner. Further details concerning this topic are discussed below.

If an \(\textit{MC}_{St}\) has applied the \(<<\) ToStereotype \(>>\) stereotype, the mapping to a Stereotype can be omitted due to the noMapping attribute. For example, when comparing Figs. 7a and 8a, we find that the latter does not contain a stereotype for the \(\textit{MC}_{St}\) MappableDataElement. This is because we have applied the \(<<\) ToStereotype \(>>\) stereotype to this metaclass and assigned value ‘true’ to the noMapping attribute.

Relationships to super-types. After the stereotypes are created, we introduce inheritance relationships (i.e. a Generalization) between them and their super-types. However, according to Design Decision 5, a Generalization must be introduced only for those Stereotypes created from \(\textit{MC}_{St}\) metaclasses that inherit from other \(\textit{MC}_{St}\) metaclasses.

For the reason above, we identify the set of super-types for a Stereotype ST based on the generalization property of its source \(\textit{MC}_{St}\) metaclass, where we regard only \(\textit{MC}_{St}\) metaclasses that have not applied the \(<<\) OmitGernalization \(>>\) stereotype. Based on the resulting set of \(\textit{MC}_{St}\) metaclasses, we identify the corresponding Stereotypes in \(\textit{UP}_{Domain}\) and assign them to the superClass property of Stereotype ST. This also causes an implicit creation of Generalization relationships between Stereotype ST and the super-types.

An example is shown in Fig. 8a, where the \(<<\) SimpleDataInstance \(>>\) stereotype inherits from the \(<<\) DataInstance \(>>\) stereotype. This is because the two source metaclasses in Fig. 7a are \(\textit{MC}_{St}\) metaclasses that are in an inheritance relationship.

Extension relationships to UML metaclasses. Apart from Generalizations, we create an Extension association between a mapped Stereotype ST and the UML metaclasses to extend, which can be determined in two ways. Implicitly, we can identify them based on generalization relationships between \(\textit{MC}_{AC}\) and \(\textit{MC}_{ST}\) metaclasses in \(\textit{MM}_{Domain}\) (Design Decision 4). However, this can be overridden by explicitly specifying the UML metaclasses of interest (Design Decision 9) using the \(<<\) ToStereotype \(>>\) stereotype.

To obtain the set of UML metaclasses for a Stereotype ST, we employ its source metaclass \(\textit{MC}_{St}\) SM in \(\textit{MM}_{Domain}\). First, we check whether UML metaclasses are explicitly defined via the \(<<\) ToStereotype \(>>\) stereotype, and if so, we use these UML metaclasses as extension target for stereotype ST. Otherwise, we determine the \(\textit{MC}_{AC}\) metaclasses that are super-types of the \(\textit{MC}_{St}\) SM. Then, we resolve the ‘matching’ UML metaclasses for that \(\textit{MC}_{AC}\) metaclasses. Afterwards, we introduce an Extension between stereotype ST and each identified UML metaclass.

For example, the Extensions of the stereotypes \(<<\) DataUse \(>>\) and \(<<\) Parameter \(>>\) shown in Fig. 8 are create because the source \(\textit{MC}_{St}\) metaclasses in Fig. 7 inherit from \(\textit{MC}_{AC}\) metaclasses. In contrast, the Extensions of all remaining stereotypes in Fig. 8 are created based on an explicit specification using the \(<<\) ToStereotype \(>>\), which is applied to the source \(\textit{MC}_{St}\) metaclasses.

4.4.2 Mapping of DataTypes

Apart from Stereotypes, a UML profile can also introduce different kinds of data types, which can be DataTypes, PrimitiveTypes, or Enumerations. For the derivation of a UML profile, we determine those data types of \(\textit{MM}_{Domain}\) that do not represent ‘Abstract Concepts’ and that are not mapped to data types of \(\textit{MM}_{Add}\). Then, we copy these data types one-to-one into the UML profile.

For instance, the Enumerations UnassignedMember Treatment and ComponentInstanceRole in Fig. 7 do neither represent ‘Abstract Concepts’ nor data types that map to a metamodel \(\textit{MM}_{Add}\). Thus, they are copied one-to-one to \(\textit{UP}_{TDL}\) as shown in Fig. 8.

4.4.3 Mapping to stereotype attributes

According to Design Decision 6, we map an \(\textit{MC}_{St}\) metaclass attribute to a corresponding attribute of a Stereotype. However, we must also respect UML’s extension mechanism for Stereotypes. Therefore, we cannot simply map every kind of metaclass attribute to a corresponding stereotype attribute. The most important rule in this context is that subsetting and redefinition are only applicable to stereotype attributes as long as no attribute of a UML metaclass is involved.

Subsetting and redefining metaclass attributes. Due to the reason above and according to Design Decision 7, we map a redefining or subsetting metaclass attribute to a ‘derived’ and ‘read-only’ stereotype attribute, and we introduce an OCL expression so that the attribute’s value is automatically computed at runtime. To explain this mapping in more detail, we employ the example given in Fig. 9, where we distinguish two cases.

Fig. 9
figure 9

Mapping to derived attributes

Fig. 10
figure 10

Introduced Properties and Associations in \(\textit{UP}_{TDL}\)

In Case (A) of our example, an \(\textit{MC}_{St}\) A with an attribute a and an \(\textit{MC}_{AC}\) T_AC are given. Furthermore, attribute a redefines attribute t_ac, and its type property also refers to T_AC. We obtain a ‘read-only’ and ‘derived’ attribute a of stereotype A’ as mapping result, and the type property of a now refers to the ‘matching’ UML metaclass T_AC’. In addition, an OCL expression is introduced to define the defaultValue of a. Case (B) differs from (A) only in the detail that attribute a of \(\textit{MC}_{St}\) A is subsetting attribute t_ac, instead of redefining it.

In both cases, we also create an OCL expression and assign it to the defaultValue property of a mapped stereotype attribute, as described in Sec. 4.5.

For example, see the type attribute of the \(\textit{MC}_{St}\) metaclass ComponentInstance in Fig. 7b. As it redefines the type attribute of the \(\textit{MC}_{AC}\) AC_TypedElement, it is mapped to a ‘derived’ and ‘read-only’ attribute of the stereotype \(<<\) ComponentInstance \(>>\) in Fig. 10b.

In addition to the scenario above, we also create ‘derived’ and ‘read-only’ stereotype attributes for all \(\textit{MC}_{St}\) attributes that have an ‘alternative’ OCL specification (Design Decision 10). This can be defined via the oclSpecification attribute of the \(<<\) ToTaggedValue \(>>\) stereotype applied to an \(\textit{MC}_{St}\) attribute in \(\textit{MM}_{Domain}\). During the mapping, we first create the stereotype attribute, and then we assign the given OCL specification to the attribute’s defaultValue property.

For instance, see the various \(\textit{MC}_{St}\) attributes with applied \(<<\) ToTaggedValue \(>>\) stereotype in Fig. 7b. According to Design Decision 10, these attributes are mapped to ‘derived’ and ‘read-only’ stereotype attributes shown in Fig. 10b.

Other metaclass attributes. All remaining kinds of \(\textit{MC}_{St}\) attributes are mapped one-to-one to corresponding stereotype attributes, including those \(\textit{MC}_{St}\) attributes that are redefining/subsetting other \(\textit{MC}_{St}\) attributes, or that are specified to be a superset. Because only stereotype attributes are involved, no UML restrictions apply and we can preserve such relationships. To do so, we usually map all properties of an \(\textit{MC}_{St}\) attribute to corresponding properties of the stereotype attribute to be created.

However, an exception are the properties type and aggregation. The mapping of the former property depends on whether the type property of the \(\textit{MC}_{St}\) attribute in question refers to a metaclass. If this is the case, the aggregation property of a created stereotype attribute must be set to the value ‘none’, as we argued for Design Decision 6. Because the mapping rules for the type property are more complex, we discuss this separately in the next section.

4.4.4 Recomputing the type property

As we argued for Design Decision 8, a stereotype attribute shall not have a stereotype as its type. Therefore, we recompute the type property of a created stereotype attribute during the mapping; but for this, we must consider that a metamodel \(\textit{MM}_{Domain}\) can contain three types of metaclasses (Design Decision 1) that are mapped in different ways. In the following, we analyse the different cases.

Fig. 11
figure 11

Variants for recomputing the attribute type

Let A be an \(\textit{MC}_{St}\) in \(\textit{MM}_{Domain}\) and A’ its corresponding Stereotype in \(\textit{UP}_{Domain}\). In addition, assume that \(\textit{MC}_{St}\) A has an attribute att that maps to a corresponding attribute att’ of A’, and the type property of att can refer to an \(\textit{MC}_{AC}\) (Case A), an \(\textit{MC}_{St}\) (Case B), or an \(\textit{MC}_{AMC}\) (Case C) metaclass, as shown in Fig. 11. We determine the type property of att’ as follows:

Case A::

By Design Decision 2, we assume that a ‘matching’ UML metaclass exists for each \(\textit{MC}_{AC}\) metaclass in \(\textit{MM}_{Domain}\). Hence, when we recompute a type property that refers to an \(\textit{MC}_{AC}\), we determine the ‘matching’ UML metaclass and use it as the new type.

For example, consider attribute att of \(\textit{MC}_{St}\) A in Fig. 11a as input, and assume that the type property of att refers to an \(\textit{MC}_{AC}\) T_AC in \(\textit{MM}_{Domain}\). Then, the recomputed type of att’ refers to metaclass T_AC’ in \(\textit{MM}_{UML}\).

Case B::

If the type of an attribute refers to an \(\textit{MC}_{St}\), the type of the mapped attribute must refer to a UML metaclasses, as we argued for Design Decision 8. Thus, when we recompute a type property that refers to an \(\textit{MC}_{St}\) metaclass, we determine a UML metaclass rather than the Stereotype that extends it.

For instance, consider attribute att of \(\textit{MC}_{St}\) A in Fig. 11b as input, and assume the type property of att refers to \(\textit{MC}_{St}\) T_ST in \(\textit{MM}_{Domain}\). Then, the recomputed type of att’ refers T_AC’ in \(\textit{MM}_{UML}\).

Case C::

An \(\textit{MC}_{AMC}\) in \(\textit{MM}_{Domain}\) maps to an ‘additional’ metaclass in \(\textit{MM}_{Add}\) (Design Decision 1). If such an \(\textit{MC}_{AMC}\) is referenced as type of a metaclass attribute in \(\textit{MM}_{Domain}\), then only the corresponding metaclass in \(\textit{MM}_{Add}\) has to be determined and used as type of the mapped attribute.

For example, let attribute att of \(\textit{MC}_{St}\) A in Fig. 11c be the input for the recomputation, and assume that the type of att refers to the \(\textit{MC}_{AMC}\) T_AMC in \(\textit{MM}_{Domain}\). Then, the recomputed type of att’ refers to T_AMC’ of \(\textit{MM}_{Add}\).

All metaclass attributes that are implicitly defined via association ends in Fig. 10 are an example of Case B because their type properties refer to UML metaclasses extended by Stereotypes.

In addition to metaclasses, a metamodel \(\textit{MM}_{Domain}\) may contain data types, which we copy one-to-one to the UML profile \(\textit{UP}_{Domain}\) or the metamodel \(\textit{MM}_{Add}\). Because such data types can also be used as attribute type in \(\textit{MM}_{Domain}\), we must recompute the type of a mapped attribute in this case, too. But unlike metaclasses, we only determine whether a data type is contained in \(\textit{UP}_{Domain}\), \(\textit{MM}_{Add}\) or \(\textit{MM}_{UML}\); then, we use it as the new type of a mapped attribute.

The unassignedMember attribute of the \(<<\) StructureDataInstance \(>>\) stereotype and the role attribute of the \(<<\) ComponentInstance \(>>\) stereotype in Fig. 10 are examples for the described recomputation of an attribute type that refers to a data type.

4.4.5 Mapping to stereotype operations

In addition to attributes, a metaclass \(\textit{MC}_{St}\) can also have Operations specified, which we map to corresponding items of a created Stereotype in \(\textit{UP}_{Domain}\). To do so, we map most of the properties of an \(\textit{MC}_{St}\) operation one-to-one, excluding the redefinedOperation property and the operation’s parameters.

Similar to attributes and because of the restrictions specified for UML profiles, an operation of a Stereotype is not permitted to redefine an operation of a UML metaclass. In contrast, no restrictions exist for a redefinition between stereotype operations. For these reasons, when mapping an \(\textit{MC}_{St}\) operation to a corresponding stereotype operation, we only process those items of the redefinedOperation property, which refer to other \(\textit{MC}_{St}\) operations. Consequently, a created stereotype operation in \(\textit{UP}_{Domain}\) only redefines operations of other stereotypes, but not of UML metaclasses.

As discussed earlier, the type property must be recomputed while creating a stereotype attribute. Because a Parameter of an Operation also has a type, we recompute this property in the same way.

4.5 OCL expressions for stereotype attributes

By Design Decision 7, we map a redefining or subsetting \(\textit{MC}_{St}\) attribute to a ‘derived’ and ‘read-only’ stereotype attribute. Consequently, the value of this attribute is computed at runtime based on its defaultValue property. To enable this computation, we introduce an OCL expression for each of these attributes. However, as argued for Design Decision 10, the automatic creation of OCL expressions is restricted to the subsetting or redefinition of a single attribute only. In all other cases, an OCL expression must be provided using the \(<<\) ToTaggedValue \(>>\) stereotype.

Fig. 12
figure 12

Subsetting \(\textit{MC}_{St}\) attribute and the corresponding ‘derived’ and ‘read-only’ stereotype attribute

Assume we have given an \(\textit{MC}_{St}\) A that inherits from an \(\textit{MC}_{AC}\) AC_MCB, and A has an attribute att_a that is subsetting an attribute att_mcb of AC_MCB, as shown in Fig. 12. According to our mapping rules, A is mapped to a Stereotype A’, and att_a maps to a ‘derived’ and ‘read-only’ stereotype attribute att_a’. Because AC_MCB has a ‘matching’ UML counterpart MCB, AC_MCB is not mapped. In addition, we introduce an Extension between Stereotype A’ and UML metaclass MCB, which implies the creation of the attributes extension_A and base_MCB. However, the subsetting relationship of att_a is not preserved for att_a’; instead, we create an OCL expression so that the attribute’s value is computed at runtime.

In the created OCL expression, we first navigate from the instance of A’ to the instance of MCB by employing attribute base_MCB. Then, we access attribute att_MCB to collect all items required to compute the value of attribute att_a’. We select these items either based on their applied stereotypes or according to their type. The latter option is applied if the type property of att_a’ refers to an ‘additional’ metaclass. Finally, we typecast the set of all determined values so that they match the type and cardinality of att_a’.

A generated OCL expression as a substitution for redefining or subsetting \(\textit{MC}_{St}\) attributes always consists of the following parts:

  • Navigation to UML metaclass MCB that is extended by a Stereotype ST;

  • Navigation to attribute att_src of MCB, so this attribute serves as the source for the value computation;

  • Selection of all relevant items of att_src based on their applied stereotype or element type;

  • Type-cast of the selected items to match the type and cardinality of the stereotype attribute att_st.

We generate all OCL expressions according to two patterns. The first pattern is used for stereotype attributes that have an upper cardinality one, while the second pattern is employed in all other cases:

figure a

For example, when we employ Pattern (1) for the type attribute of the \(\textit{MC}_{St}\) ComponentInstance in Fig. 7b, we obtain the following OCL expression for the corresponding attribute of \(<<\) ComponentInstance \(>>\) in Fig. 10b:

figure b

As the type attribute of the \(<<\) ComponentInstance \(>>\) stereotype is only single-valued, we evaluate in the first two lines of the generated OCL expression whether an element with applied \(<<\) ComponentType \(>>\) stereotype is assigned to the type attribute of the UML metaclass Property. If so, we type-cast and return the determined element.

4.6 Additional OCL constraints

Because the type properties of stereotype attributes are recomputed, we introduce additional OCL constraints to preserve the static semantics defined by \(\textit{MM}_{Domain}\). Due to Design Decisions 11 and 12, we distinguish between two categories of OCL constraints. The first is introduced to ensure the well-formedness of stereotype attributes that are not ‘derived’ and ‘read-only’. The second ensures the well-formedness of UML metaclass attributes that are relevant for computing the defaultValues of ‘derived’ and ‘read-only’ stereotype attributes.

4.6.1 OCL constraints for stereotype attributes

As argued for Design Decision 11, a syntactically invalid value can be assigned to a stereotype attribute that is not defined as ‘derived’ and ’read-only’. Therefore, we introduce OCL constraints to ensure that only UML elements having applied particular stereotypes can be assigned to such stereotype attributes.

Assume an \(\textit{MC}_{St}\) attribute att, where its type property refers to an \(\textit{MC}_{St}\) A. This attribute is mapped to a corresponding attribute att’, and a Stereotype A’ is derived from A. In addition, this stereotype has an Extension to a UML metaclass MCB. Furthermore, the type property of att’ is recomputed so that it refers to MCB. Thus, any kind of MCB instance can be assigned to att’. However, att’ is only well formed if all elements assigned to it have A’ applied. To ensure this, we create an OCL constraint that consists of the following parts:

  • Navigation to stereotype attribute att_st;

  • Verification that all items of att_st have stereotype ST applied.

Apart from the components above, the cardinality of the stereotype attribute must also be respected because different constraint kinds have to be used for single-valued and multi-valued attributes:

figure c

For instance, the type property of the component attribute of the \(\textit{MC}_{St}\) GateReference in Fig. 7b refers to the \(\textit{MC}_{St}\) ComponentInstance. As we recompute the type property of stereotype attributes, that of the component attribute of \(<<\) GateReference \(>>\) refers to the UML metaclass Property. For this attribute, we introduce the following OCL Constraint by applying Pattern (1) above:

figure d

In Line 1, we evaluate whether a value is assigned to the stereotype attribute. If so, we employ the isStereotyped By() operation in Line 2 to test whether the element assigned to the component attribute has applied the \(<<\) ComponentInstance \(>>\) stereotype. Consequently, only elements with applied \(<<\) ComponentInstance \(>>\) stereotype can be assigned to the component attribute.

4.6.2 OCL constraints for UML metaclass attributes

We introduce a second category of OCL constraints for ensuring the well-formedness of UML metaclass attributes that serve as value computation source for the defaultValue of ‘derived’ and ‘read-only’ stereotype attributes (Design Decision 12).

Suppose that the same excerpt of a metamodel \(\textit{MM}_{Domain}\) (see Fig. 12) is given as we have employed to explain the generation of OCL expressions. After applying our derivation approach, we obtain a ‘derived’ and ‘read-only’ stereotype attribute att_a’ that has an OCL expression as defaultValue. Moreover, an attribute att_mcb of a UML metaclass MCB serves as basis for computing this OCL expression. To preserve well-formedness, we have to ensure that only permitted elements can be assigned to metaclass attribute att_mcb. For the given example, only the assignment of elements with an applied stereotype A’ is permitted. Hence, we introduce an appropriate OCL Constraint that constrains attribute att_mcb.

Apart from the given example, a UML metaclass attribute can also be used to compute several stereotype attributes. This is always the case if several \(\textit{MC}_{St}\) attributes in the source model \(\textit{MM}_{Domain}\) are subsetting or redefining the same \(\textit{MC}_{AC}\) attribute. In such a scenario, we obtain a set of valid stereotypes that can be applied to items of the attribute att_mcb, and therefore, these also must be verified via a generated OCL constraint, which consists of the following parts:

  • Navigation to attribute att_mcb of UML metaclass MCB, which is extended by Stereotype ST;

  • Verification that each item of att_mcb has one of the permitted stereotypes applied.

We employ the following two patterns to generate an OCL Constraint. As in the case of the previous constraint category, we must obey the attribute cardinality here:

figure e

For example, the type attribute of the \(\textit{MC}_{St}\) Component Instance in Fig. 7b redefines an attribute of the \(\textit{MC}_{AC}\) AC_TypedElement. As only one attribute of the \(\textit{MC}_{St}\) ComponentInstance redefines the type attribute of the \(\textit{MC}_{AC}\) AC_TypedElement, only one attribute of the \(<<\) ComponentInstance \(>>\) stereotype has an OCL expression for a value computation based on the type attribute of UML metaclass TypedElement. Consequently, according to Design Decision 12, only elements with applied \(<<\) ComponentType \(>>\) stereotype shall be assignable to this UML metaclass attribute. To ensure this, we create the following OCL constraint by employing Pattern (1):

figure f

Line 1 tests whether a value exists at all. If this is the case, starting from an instance of \(<<\) ComponentInstance \(>>\), we navigate in Line 2 to the type attribute and invoke the isStereotypedBy() operation to evaluate whether the element assigned to this attribute has the \(<<\) ComponentType \(>>\) stereotype applied.

Fig. 13
figure 13

Basic structure of OCL’s abstract syntax

5 Update of existing OCL expressions

A metamodel includes OCL expressions for different purposes. OCL expressions can be used to define Constraints on metaclasses, so that the static semantics of a computer language or DSL is captured. They can also serve as the basis for computing values of metaclass attributes and operations at runtime.

The automatic transfer of the static semantics of a metamodel \(\textit{MM}_{Domain}\) to a derived UML profile \(\textit{UP}_{Domain}\) is a key feature of our approach. Because Stereotypes and their extended UML metaclasses exist as separate instances in a model, an automatic transfer of OCL expressions from a metamodel to a UML profile is impossible without updating them at the same time. As argued in the Sec. 2.3, we do not consider the OCL update as a separate process but as an action of our UML profile derivation process.

First, we give an overview of the OCL metamodel as a basis for specifying our design decisions for the OCL update. Then, we discuss the details for updating OCL expressions, and finally, we elaborate on the most important aspects of our implementation.

5.1 The OCL metamodel

We briefly introduce the relevant parts of OCL’s abstract syntax, which is defined by a MOF-compliant metamodel [45]. The OCL metamodel is divided into several packages, and the most important of them are:

  • The ‘Expressions’ package, which specifies the different OCL expression types;

  • The ‘Types’ package defines OCL’s type system, which includes concepts for using predefined types as well as user-defined types introduced by a metamodel.

Because only the OCL metaclasses that define the abstract syntax of OCL expressions are of interest for our OCL update, we just treat some metaclasses of the ‘Expressions’ package. The basic structure of the abstract syntax of OCL expressions is shown in Fig. 13. OCL is a ‘typed language’. Therefore, the most general metaclass OCLExpression inherits from the TypedElement, so that all OCL expressions own the type property. Typically, an abstract syntax tree (AST) of an analysed OCL expression consists of any number of nested OCL expression instances. Each of these instances has a static type specified, which is determined by a recursive analysis of all nested expressions. The result value of an expression is determined by performing an evaluation, and the obtained value must conform to the static type of the expression.

The objectives of the metaclasses shown in Fig. 13 are explained below. Only the metaclasses MsgExp and StateExp are excluded, because they cannot be used for OCL expressions contained in metamodels.

CallExp:

is used to obtain the evaluation result of an operation or attribute of a classifier or the result of a collection type iterator. The purpose of a CallExp is defined by its concrete subtypes.

FeatureCallExp:

is employed to determine the evaluation result of an attribute or operation of a classifier. This abstract OCL metaclass is more precisely defined by further subtypes, see below.

LiteralExp:

represents a literal of a primitive type such as Integer or String.

TypeExp:

refers to a classifier in a model or a predefined type. Typically, a TypeExp is passed as argument to invoke one of the predefined OCL operations oclAsType(), oclIsTypeOf(), or oclIsKindOf().

VariableDeclaration:

is a super-type of Variable and Parameter. Variable represents user-defined variables, and Parameter specifies operation parameters.

VariableExp:

is a reference to an explicitly declared variable, an operation parameter, or the implicitly introduced variables ‘self’ and ‘result’.

LoopExp:

iterates over all items of a collection type. The invocation of a predefined collection iterator is represented by IteratorExp, which is a concrete subtype of LoopExp.

IfExp:

always consists of two mandatory alternative expressions and a Boolean condition. Depending on the condition’s result, one of the alternative expressions is evaluated and the obtained result is returned.

The subtypes of the abstract OCL metaclass FeatureCallExp are shown in Fig. 14. Depending on the subtype, a NavigationCallExp represents a reference to a classifier attribute or an association class. Because the latter element type is not applicable to OCL expressions of metamodels, we do not consider the metaclass AssociationClassCallExp further. The PropertyCallExp is used to evaluate the value of a classifier attribute, and the referredProperty property is the reference to this attribute.

Another subtype of the FeatureCallExp metaclass is the OperationCallExp that is employed to evaluate the result of an operation invocation. The referredOperation property of this metaclass identifies the operation to be invoked, and the items of the ownedArguments property define the values that are passed to the operation’s parameters.

5.2 Design decisions for updating OCL expressions

Based on our design decisions for deriving UML profiles specified in Sec. 4.1, we map \(\textit{MC}_{St}\) metaclasses of the metamodel \(\textit{MM}_{Domain}\) to corresponding Stereotypes of the UML profile \(\textit{UP}_{Domain}\), and \(\textit{MC}_{St}\) attributes to stereotype attributes. Furthermore, we map Operations and Constraints of \(\textit{MC}_{St}\) metaclasses to corresponding counterparts in Stereotypes. As the result of the mappings, all elements of an \(\textit{MC}_{St}\) are owned by Stereotypes. The ‘self’ variable of an OCL expression contained in a Stereotype always refer to this Stereotype instead of a metaclass. If a feature of the extended UML metaclass is accessed based on the ‘self’ variable, the ‘base_<metaclass>’ attribute must be accessed first when navigating to that metaclass feature.

Fig. 14
figure 14

Abstract syntax of OCL’s FeatureCallExp

Hence, we must update all OCL expressions that access an \(\textit{MC}_{AC}\) attribute or \(\textit{MC}_{AC}\) Operation based on a ‘self’ variable that refers to an \(\textit{MC}_{St}\). During this update, we introduce a PropertyCallExp that accesses the attribute ‘base_<metaclass>’.

Design Decision 13

A PropertyCallExp that accesses the ‘base_<metaclass>’ attribute shall be introduced for OCL expressions that access an \(\textit{MC}_{AC}\) attribute or \(\textit{MC}_{AC}\) Operation via a ‘self’ variable that refers to an \(\textit{MC}_{St}\).

The type properties of attributes are recomputed during the mapping, so that only Classifiers (Classes or DataTypes) of the \(\textit{MM}_{UML}\) or \(\textit{MM}_{Add}\) metamodel are referenced (Design Decision 9). Moreover, the same recomputation is applied to the type property of an operation Parameter. Thus, neither the type properties of stereotype attributes nor those of operation parameters refer to Stereotypes. This situation also applies to attributes and operation parameters of ‘additional’ metaclasses of \(\textit{MM}_{Add}\). Thus, accessing mapped stereotype attributes or operation parameters always returns a metaclass instance.

If a Property or Operation of a Stereotype shall be accessed based on the result returned by an OCL expression, then the ‘extension_<stereotype>’ attribute has to be employed for navigating to the stereotype feature. For this reason, we update all OCL expressions that contain a navigation from one \(\textit{MC}_{St}\) feature to another \(\textit{MC}_{St}\) feature, and during this update we introduce a PropertyCallExp that accesses the ‘extension_<stereotype>’ attribute.

Design Decision 14

A PropertyCallExp that accesses the ‘extension_<stereotype>’ attribute shall be introduced for OCL expressions that contain a navigation from one \(\textit{MC}_{St}\) feature to another.

The predefined OCL operations oclIsTypeOf() and oclIsKindOf() are used to verify whether the evaluation result of an OCL expression is an instance of the Classifier defined as argument. The oclIsTypeOf() operation returns only value ‘true’, if the evaluation result exactly matches the type specified as argument, while the oclIsKindOf() operation returns ‘true’ also for subtypes.

Because the type property of stereotype attributes and operation parameters is recomputed during the mapping, OCL expressions that access these elements can never return a stereotype instance as result. Thus, we cannot utilize the aforementioned operations to verify whether a particular stereotype is applied. Instead, we employ the operations isStrictStereotypedBy() and isStereotyped By(). We update an OperationCallExp that invokes the oclIsTypeOf() or oclIsKindOf() operation, passing an \(\textit{MC}_{St}\) metaclass as argument. During this update, we introduce a new OperationCallExp that invokes the operation isStrictStereotypedBy() or isStereo typedBy().

Design Decision 15

An OperationCallExp that invokes the oclIsTypeOf() or oclIsKindOf() operation, passing an \(\textit{MC}_{St}\) as argument, shall be replaced by an OperationCallExp that invokes the operation isStrictStereo typedBy() or isStereotypedBy().

The elements of \(\textit{MM}_{Domain}\) are located in \(\textit{UP}_{Domain}\), \(\textit{MM}_{Add}\), and \(\textit{MM}_{UML}\) after the mapping. Because a TypeExp refers to a particular Classifier of a metamodel, we have to update all OCL expressions of that type, so that they refer to elements in \(\textit{MM}_{Add}\) or \(\textit{MM}_{UML}\). The Stereotypes of \(\textit{UP}_{Domain}\) are not considered for this update, because the type properties of stereotype attributes and parameters are recomputed during the mapping so that Stereotypes are not referenced.

Design Decision 16

All TypeExp shall be updated so that they refer to Classifiers of \(\textit{MM}_{UML}\) or \(\textit{MM}_{Add}\).

5.3 The OCL update in detail

We now detail our approach for updating OCL expressions contained in the metamodel \(\textit{MM}_{Domain}\). We assume that a textually specified OCL expression is parsed and the resulting abstract syntax tree (AST) is present. This AST is an instantiation of OCL’s metamodel.

FeatureCallExp. By Design Decisions 13 and 14, an additional PropertyCallExp that refers to the ‘base_<metaclass>’ or ‘extension_<stereotype>’ attribute must be introduced for an existing FeatureCallExp in certain situations. However, this applies only to instances of PropertyCallExp and OperationCallExp, because only these subtypes of FeatureCallExp are applicable in the context of metamodels.

Following Design Decision 13, we create an additional PropertyCallExp to access an ‘extension_<stereotype>’ attribute if all criteria below are met:

  1. 1.

    The type of the ownendSource expression of a FeatureCallExp refers to an \(\textit{MC}_{St}\) metaclass;

  2. 2.

    The referredProperty of a PropertyCallExp is an \(\textit{MC}_{St}\) attribute, or in case of an OperationCallExp, the referredOperation is an \(\textit{MC}_{St}\) operation.

Assume that the PropertyCallExp shown below is used as input for the OCL update, and that the above criteria are met. After applying the update, we obtain the result shown in the second line, where the <stereotype> placeholder represents the name of the Stereotype that owns the referredProperty:

figure g

For example, the update defined by Design Decision 13 is applied to the constraint of the \(\textit{MC}_{St}\) StructuredData Type in Fig. 7a. The membersAreDistinguishable() operation that is invoked by this constraint is inherited from \(\textit{MC}_{AC}\) AC_Namespace. In \(\textit{UP}_{TDL}\), this operation is not inherited by the derived StructuredDataType stereotype, but we can invoke it via the extended UML metaclass. For this purpose, we introduce an PropertyCallExp for the attribute base_DataType based on Design Decision 13:

figure h

Due to Design Decision 14, another kind of update of an existing FeatureCallExp is required in order to access a UML metaclass feature based on a ‘self’ variable that refers to a Stereotype instance. We create an additional PropertyCallExp that refers to the ‘base_<metaclass>’ attribute, so we can access the UML metaclass feature. We only conduct this update if all following criteria are met:

  1. 1.

    The ownendSource expression of a FeatureCallExp is a VariableExp that refers to the ‘self’ variable, and the type of this VariableExp expression refers to an \(\textit{MC}_{St}\) metaclass;

  2. 2.

    The referredProperty of a PropertyCallExp is an \(\textit{MC}_{AC}\) attribute, or in case of an OperationCallExp, the referredOperation is an \(\textit{MC}_{AC}\) operation.

Assume that the PropertyCallExp shown below is used as input for the OCL update, and the above criteria are met. The result of this update is shown in the second line. The <metaclass> placeholder corresponds to the name of the UML metaclass that owns the referredProperty:

figure i

For example, the \(\textit{MC}_{St}\) StructuredDataInstance in Fig. 7a has defined the constraint below, which includes two sub-expressions that meet the discussed criteria of Design Decision 14. Hence, we introduce a PropertyCallExp for both attributes extension_StaticDataUse and extension_Parameter.

figure j

OperationCallExp. The predefined OCL operations ocl IsTypeOf() and oclIsKindOf() can be employed to determine whether the result type of an expression matches the expected type. By Design Decision 15, an update of an OperationCallExp is required if one of the operations is applied to an \(\textit{MC}_{St}\) metaclass. We conduct this update as follows:

  • The referred operation oclIsTypeOf() of an OperationCallExp is replaced by the isStrictStereo typedBy() operation, if the passed argument is an \(\textit{MC}_{St}\) metaclass.

  • The operation oclIsKindOf() that is referred by an OperationCallExp is replaced by the isStereotyped By() operation, if the passed argument is an \(\textit{MC}_{St}\) metaclass.

For instance, suppose the two OCL expressions below are used as input for the update, and both expressions meet the above criteria. In Case (A), we introduce the operation isStrictStereotypedBy(), whereas the operation isStereotypedBy() is employed in Case (B). The placeholder <stereotype> represents the stereotype name that is derived from the \(\textit{MC}_{St}\) shown in the input expressions:

figure k

Below, for example, we apply the OCL update according to Design Decision 15 to a constraint of the \(\textit{MC}_{St}\) SimpleDataInstance in Fig. 7a. As shown, the call of the operation oclIsKindOf() is replaced by an invocation of the operation oclIsStereotypedBy(). In addition, the \(\textit{MC}_{St}\) SimpleDataType specified as argument is substituted with the qualified name of the corresponding Stereotype:

figure l

TypeExp. According to Design Decision 16, we have to update all occurrences of TypeExp that refer to an \(\textit{MC}_{AC}\) or an \(\textit{MC}_{St}\) metaclass. A TypeExp that refers to an \(\textit{MC}_{AC}\) metaclass is updated so that the ‘matching’ UML counterpart of the \(\textit{MC}_{AC}\) is referenced. Furthermore, a TypeExp that refers to an \(\textit{MC}_{AMC}\) metaclass is updated so that it refers to an ‘additional’ metaclass.

We explain the application of the update based on the getTestDescription() operation of the \(\textit{MC}_{St}\) AtomicBehaviour. Line 3 of this operation invokes the operation oclAsType(T), where a TypeExp is passed as argument T that refers to the \(\textit{MC}_{St}\) TestDescription. After conducting our update, the UML metaclass BehavioredClassifier is passed as argument, as required by Design Decision 16.

figure m

6 Case study-based evaluation

We employ the Test Description Language (TDL) as a running example to explain the details of deriving a UML profile from a metamodel. Below, we detail our case study on TDL, where we fully automatically derive a UML profile from TDL’s metamodel using our derivation approach. First, we investigate whether all elements of the UML profile \(\textit{UP}_{TDL}\) are created as expected. Then, we compare our \(\textit{UP}_{TDL}\) with the UML profile [6] standardized for TDL. In this way, we assess the quality of UML profiles generated via our approach against manually created ones.

6.1 Evaluation of the generated UML profile \(\textit{UP}_{TDL}\)

In Table 2, we compare the metaclasses of \(\textit{MM}_{TDL}\) with the stereotypes that we have derived for the UML profile \(\textit{UP}_{TDL}\). Because of Design Decision 1, we do not map \(\textit{MC}_{AC}\) metaclasses to model elements of \(\textit{UP}_{TDL}\). Accordingly, the 13 \(\textit{MC}_{AC}\) metaclasses have no counterparts in \(\textit{UP}_{TDL}\).

The \(<<\) ToStereotype \(>>\) stereotype is applied to 59 of the 80 \(\textit{MC}_{St}\) metaclasses in \(\textit{MM}_{TDL}\), mainly to define the UML metaclasses to be extended by generated Stereotypes (Design Decision 9). Based on the number of \(\textit{MC}_{St}\) metaclasses in \(\textit{MM}_{TDL}\), one could assume that \(\textit{UP}_{TDL}\) contains a total of 80 Stereotypes. As shown in Table 2, only 79 Stereotypes are created for \(\textit{UP}_{TDL}\). This corresponds to the desired result, because we have defined the \(\textit{MC}_{St}\) MappableDataElement in \(\textit{MM}_{TDL}\) (see Fig. 7a) as not to be mapped.

Table 2 Metaclasses in \(\textit{MM}_{TDL}\) vs. stereotypes in \(\textit{UP}_{TDL}\)

Stereotype extensions and generalizations. To explain more clearly for which kinds of \(\textit{MC}_{St}\) metaclasses Stereotypes are introduced either with Extensions or Generalizations, we distinguish two \(\textit{MC}_{St}\) groups in Table 2:

For \(\textit{MC}_{St}\) metaclasses that inherit directly from \(\textit{MC}_{AC}\) metaclasses, we introduce Extensions between generated Stereotypes and UML metaclasses identified based on the \(\textit{MC}_{AC}\) metaclasses (Design Decision 4). Because one of the 33 \(\textit{MC}_{St}\) metaclasses that inherit directly from \(\textit{MC}_{AC}\) metaclasses is specified as not mappable, we derive only 32 Stereotypes with an Extension to a UML metaclass. 29 of these \(\textit{MC}_{St}\) metaclasses have the \(<<\) ToStereotype \(>>\) stereotype applied, so that the UML metaclasses to be extended are explicitly specified (Design Decision 9) and not determined based on \(\textit{MC}_{AC}\) metaclasses.

The second \(\textit{MC}_{St}\) group summarizes all \(\textit{MC}_{St}\) metaclasses that inherit from other \(\textit{MC}_{St}\) metaclasses by means of Generalization. This group comprises 47 \(\textit{MC}_{St}\) metaclasses of which 30 have the \(<<\) ToStereotype \(>>\) stereotype applied. For all Stereotypes that are created from these 47 \(\textit{MC}_{St}\) metaclasses, we introduce Generalizations to other Stereotypes (Design Decision 5). In addition, we create 30 Extension relationships from Stereotypes to UML metaclasses, because the source \(\textit{MC}_{St}\) metaclasses have applied the \(<<\) ToStereotype \(>>\) stereotype (Design Decision 9).

Stereotype attributes. Due to the higher number of relevant design decisions, the mapping of attributes is more complex than the one of Stereotypes. Accordingly, several types of attribute mappings are considered in Table 3:

‘Derived’ stereotype attributes::

This group summarizes all mapped stereotype attributes that are defined as ‘derived’ and ‘read-only’.

‘Non-derived’ stereotype attributes::

This group captures all stereotype attributes that do not belong to the first group.

As shown in Table 3, \(\textit{MM}_{TDL}\) contains a total of 126 metaclass attributes, of which 99 are considered as \(\textit{MC}_{St}\) attributes that map to 52 ‘non-derived’ and 47 ‘derived’ stereotype attributes. The remaining 27 attributes are owned by \(\textit{MC}_{AC}\) metaclasses and, therefore, are not considered when deriving \(\textit{UP}_{TDL}\).

Table 3 Metaclass attributes in \(\textit{MM}_{TDL}\) vs. stereotype attributes in \(\textit{UP}_{TDL}\)

To discuss the mapping of \(\textit{MC}_{St}\) attributes to ‘derived’ or ‘non-derived’ stereotype attributes, we group them according to their type in Table 3. In addition, we specify how many of the \(\textit{MC}_{St}\) attributes of a group have the \(<<\) ToTaggedValue \(>>\) stereotype applied. This is because the application of this stereotype overrides the default mapping for \(\textit{MC}_{St}\) attributes, so that these attributes are mapped to ‘derived’ stereotype attributes.

The first group of \(\textit{MC}_{St}\) attributes subsumes all \(\textit{MC}_{St}\) attributes that are already defined as ‘derived’ and ‘read-only’ in \(\textit{MM}_{TDL}\). By default, these \(\textit{MC}_{St}\) attributes are mapped to stereotype attributes also defined as ‘derived’ and ‘read-only’. During the mapping, we copy an OCL expression available as defaultValue and subject it to our OCL update. However, if an \(\textit{MC}_{St}\) attribute has the \(<<\) ToTaggedValue \(>>\) stereotype applied, we use the OCL expression defined by this Stereotype instead of the existing one in \(\textit{MM}_{TDL}\).

Overall, \(\textit{MM}_{TDL}\) contains three \(\textit{MC}_{St}\) attributes defined as ‘derived’ and ‘read-only’, of which one has applied the \(<<\) ToTaggedValue \(>>\) stereotype. Accordingly, existing OCL expressions are transferred to \(\textit{UP}_{TDL}\) for only two \(\textit{MC}_{St}\) attributes. In the case of the \(\textit{MC}_{St}\) attribute with applied \(<<\) ToTaggedValue \(>>\) stereotype, the OCL expression defined by this Stereotype was copied to \(\textit{UP}_{TDL}\).

The second \(\textit{MC}_{St}\) attribute group contains nine \(\textit{MC}_{St}\) attributes that redefine other metaclass attributes. Eight of these \(\textit{MC}_{St}\) attributes are mapped to ‘derived’ and ‘read-only’ stereotype attributes, where six attributes are mapped based on Design Decision 7 and two others based on the applied \(<<\) ToTaggedValue \(>>\) stereotype, as required by Design Decision 10. One further \(\textit{MC}_{St}\) attribute is mapped to a ‘non-derived’ stereotype because it redefines an \(\textit{MC}_{St}\) attribute and is thus not captured by Design Decision 7.

All attributes that subset other metaclass attributes are captured by the third \(\textit{MC}_{St}\) attribute group. In total, this group comprises 43 \(\textit{MC}_{St}\) attributes, of which 29 have the \(<<\) ToTaggedValue \(>>\) stereotype applied. Based on Design Decision 7, these 29 attributes are mapped to ‘derived’ and ‘read-only’ stereotype attributes. In addition, we introduce OCL expressions as defaultValues, which are used to compute the values of stereotype attributes at runtime.

One could now expect that all 14 remaining \(\textit{MC}_{St}\) attributes would also be mapped to ‘derived’ and ‘read-only’ stereotype attributes according to the rules defined by Design Decision 7. However, this is not the case as we have supplemented these rules during the implementation of our derivation approach, as argued in Sec. 4.4. Therefore, only those \(\textit{MC}_{St}\) attributes that redefine or subset \(\textit{MC}_{AC}\) attributes not declared as ‘derivedUnion’ or ‘read-only’, are mapped according to Design Decision 7. Because the 14 remaining \(\textit{MC}_{St}\) attributes do not meet this condition, they are mapped to ‘non-derived’ stereotype attributes.

The last \(\textit{MC}_{St}\) attribute group comprises all attributes that are not captured by one of the three other groups. This applies to 44 \(\textit{MC}_{St}\) attributes, of which seven have applied the \(<<\) ToTaggedValue \(>>\) stereotype, so they are mapped to seven stereotype attributes that are defined as ‘derived’ and ‘read-only’ (Design Decision 10). The 37 remaining metaclass attributes of this group are mapped one-to-one to ‘non-derived’ stereotype attributes (Design Decision 6).

OCL-defined elements. The metamodel \(\textit{MM}_{TDL}\) contains 67 Constraints and ten Operations defined via OCL, which we map to corresponding elements in \(\textit{UP}_{TDL}\). When comparing \(\textit{MM}_{TDL}\) and \(\textit{UP}_{TDL}\), we find that \(\textit{UP}_{TDL}\) comprises 113 OCL Constraints instead of 67. This is because we introduce additional OCL Constraints for Stereotypes of \(\textit{UP}_{TDL}\) (Design Decisions 11 and 12).

Table 4 OCL artefacts of \(\textit{MM}_{TDL}\) vs. the ones of \(\textit{UP}_{TDL}\)

To ensure that only UML elements with certain Stereotypes can be assigned to ‘non-derived’ stereotype attributes, we create appropriate OCL Constraints. Table 4 shows that \(\textit{UP}_{TDL}\) contains 52 ‘non-derived’ stereotype attributes, but only 40 OCL Constraints are created for these. This is because only 40 of the 52 ‘non-derived’ stereotype attributes are derived from \(\textit{MC}_{St}\) attributes whose type property refers to an \(\textit{MC}_{St}\) (Design Decision 11).

In addition, further OCL Constraints are provided according to Design Decision 12 for ‘derived’ and ‘read-only’ stereotype attributes derived from subsetting or redefining \(\textit{MC}_{St}\) attributes. These OCL Constraints ensure that only UML elements with matching Stereotypes can be assigned to UML metaclass attributes that serve as computation source for the values of the stereotype attributes in question. As six stereotype attributes in \(\textit{UP}_{TDL}\) are derived from redefining \(\textit{MC}_{St}\) attributes, an equal number of OCL constraints is introduced based on Design Decision 12.

6.2 The standardized versus the derived UML profile

In the following, we investigate whether an automatic generated UML profile is comparable to a manually created one. Therefore, we compare our derived UML profile \(\textit{UP}_{TDL}\) with the one standardized for TDL [6]. We refer to the latter UML profile via the acronym \(\textit{UP}_{std}\). First, we analyse the number of model elements contained in \(\textit{UP}_{std}\) and \(\textit{UP}_{TDL}\), so that we can draw initial conclusions. Afterwards, we review some Stereotypes of both UML profiles to obtain a detailed view on the quality of the UML profile \(\textit{UP}_{TDL}\).

Quantitative comparison. To compare the various elements in \(\textit{UP}_{std}\) and \(\textit{UP}_{TDL}\), we summarize their quantities in Table 5. A particularity of \(\textit{UP}_{std}\) is shown in the first table row. \(\textit{UP}_{std}\) defines a mapping to TDL metaclasses for 23 UML element types without defining Stereotypes, i.e. the relevant UML model elements are mapped without TDL-specific Stereotypes applied to them. The disadvantage of this approach is that no OCL Constraints are defined for the affected UML element types due to the missing Stereotypes; thus, the static semantics of the relevant language concepts of TDL is not captured.

Table 5 Comparison of the UML profiles \(\textit{UP}_{std}\) and \(\textit{UP}_{TDL}\)

\(\textit{UP}_{std}\) embraces a lower number of Stereotypes than \(\textit{UP}_{TDL}\), which is due to the above reason. In contrast and except of the MappableDataElement metaclass, \(\textit{UP}_{TDL}\) provides a specific Stereotype for each \(\textit{MC}_{St}\) metaclass of \(\textit{MM}_{TDL}\). In addition, the Stereotypes of \(\textit{UP}_{TDL}\) have a larger number of attributes. One might assume that this is due to the larger number of Stereotypes in \(\textit{UP}_{TDL}\). However, the question arises whether the different numbers of Stereotypes is the only reason, because \(\textit{UP}_{TDL}\) contains with 99 stereotype attributes almost twice as many as \(\textit{UP}_{std}\). Another reason might be that not each metaclass attribute has a corresponding Stereotype attribute in \(\textit{UP}_{TDL}\). This aspect is analysed in more detail below.

The compliance of UML elements with TDL’s static semantics can only be evaluated if Stereotypes with appropriate OCL Constraints exist. Because \(\textit{UP}_{std}\) has only two OCL Constraints, this statement also applies to those TDL language concepts for which corresponding Stereotypes are present. In contrast, \(\textit{UP}_{TDL}\) provides 113 Constraints and 10 Operations that are defined via OCL. These include not only the Constraints transferred from \(\textit{MM}_{TDL}\), but also those introduced during the derivation of \(\textit{UP}_{TDL}\). Therefore, we conclude that \(\textit{UP}_{std}\) cannot be used to ensure TDL’s static semantics, whereas this drawback does not exist for \(\textit{UP}_{TDL}\).

Comparison of the syntactic structure. After we determined that \(\textit{UP}_{std}\) has some limitations over \(\textit{UP}_{TDL}\), we now compare the structure of the Stereotypes in both UML profiles. For this purpose, we examine the Stereotypes that define the abstract syntax for TDL test descriptions. The relevant Stereotypes of \(\textit{UP}_{std}\) are shown in Fig. 15a, and those defined for \(\textit{UP}_{TDL}\) can be found in Fig. 15b.

Fig. 15
figure 15

Stereotypes in \(\textit{UP}_{std}\) and \(\textit{UP}_{TDL}\) used to define the syntax of TDL test descriptions

Considering the Stereotypes and the UML metaclasses extended by them in Figs. 15a and 15b, we can identify two significant differences. The \(<<\) ComponentInstance \(>>\) stereotype in \(\textit{UP}_{std}\) extends the UML metaclasses EncapsulatedClassifier and Property, whereas the one in \(\textit{UP}_{TDL}\) extends only the latter. Both UML metaclasses extended by the stereotype of \(\textit{UP}_{std}\) are fundamentally different language concepts. The UML metaclass Property represents a specialization of Structural Feature, whereas EncapsulatedClassifier is a specialization of Classifier that can provide various Features, such as StructuralFeature.

If we consider the TDL metaclasses shown in Fig. 7b, we see that the componentInstance attribute of the TestConfiguration metaclass is a composition. Hence, instances of ComponentInstance are parts of Test Configuration instances. In addition, Component Instance provides a type attribute that is employed to refer to a ComponentType. Thus, from a semantic point of view, a TDL ComponentInstance can be compared with a UML Property rather than a UML EncapsulatedClassifier. For this reason, we consider an extension of this UML metaclass by the \(<<\) ComponentInstance \(>>\) stereotype in \(\textit{UP}_{std}\) as semantically incorrect, and therefore, this Stereotype should only extend the UML metaclass Property, as is the case in \(\textit{UP}_{TDL}\).

Comparing Figs. 15a and 15b, we find that the stereotypes of \(\textit{UP}_{TDL}\) have six and those of \(\textit{UP}_{std}\) have only three attributes defined by Association ends. Because stereotypes of \(\textit{UP}_{TDL}\) are derived from \(\textit{MC}_{St}\) metaclasses in \(\textit{MM}_{TDL}\), they have the same number of attributes as the corresponding metaclasses. In contrast, stereotypes in \(\textit{UP}_{std}\) have a lower number of attributes than TDL metaclasses.

Instead of the non-existent stereotype attributes, a mapping of UML metaclass attributes to certain TDL metaclass attributes is defined in \(\textit{UP}_{std}\). This is a viable way, but due to the absence of OCL Constraints in \(\textit{UP}_{std}\), the values permitted for UML metaclass attributes are not constrained. Therefore, \(\textit{UP}_{std}\) allows the specification of models that are invalid in relation to the static semantics of TDL. Because \(\textit{UP}_{std}\) does not specify a corresponding stereotype attribute for each metaclass attribute, this also explains the difference in the number of attributes between \(\textit{UP}_{std}\) and \(\textit{UP}_{TDL}\).

All stereotype attributes introduced by Association ends in \(\textit{UP}_{TDL}\) refer to UML metaclasses extended by Stereotypes. In contrast, the stereotype attributes in \(\textit{UP}_{std}\) (e.g. see Fig. 15a) always refer to Stereotypes. Because navigation from a Stereotype instance to the extended UML element or vice versa is possible, referencing Stereotypes or extended UML metaclasses is comparable from a syntactical point of view. However, the latter option requires the use of appropriate OCL Constraints to ensure that only UML elements with a specific applied Stereotype can be assigned to a stereotype attribute. As discussed above, exactly such OCL Constraints are automatically introduced by our derivation approach.

Another difference between the stereotype attributes of \(\textit{UP}_{TDL}\) and \(\textit{UP}_{std}\) shown in Fig. 15 is their cardinality. If we compare the stereotype attributes in Fig. 15b with the corresponding metaclass attributes in Fig. 7b, we find that their cardinalities match. In contrast, the stereotype attributes shown in Fig. 15a have different cardinalities than their corresponding metaclass attributes of \(\textit{MM}_{TDL}\). Thus, a syntactical difference between \(\textit{UP}_{std}\) and the TDL metamodel exists. The TDL standard [6] does not indicate that the deviating attribute cardinalities are an explicit design decision for the creation of \(\textit{UP}_{std}\). We therefore assume that these are issues that result from the manual creation of \(\textit{UP}_{std}\).

6.3 Discussion of the evaluation results

We investigated the applicability of our approach to derive a UML profile and used the Test Description Language (TDL) [6] to evaluate the applicability of our derivation approach to new DSLs. In contrast, the Specification and Description Language (SDL) [21] was subject of another case study [27, 28] to evaluate the applicability of our approach for existing DSLs with available production rules.

In Sects. 4 and 5, we already employed TDL as running example to detail our approach for deriving a UML profile and updating the associated OCL-defined static semantics; therefore, here we only quantitatively investigated whether \(\textit{UP}_{TDL}\) was derived from \(\textit{MM}_{TDL}\) according to our Design Decisions 112. The comparison of \(\textit{UP}_{TDL}\) with \(\textit{MM}_{TDL}\) showed that exactly the number of model elements we expected, such as stereotypes, was generated for \(\textit{UP}_{TDL}\). Hence, we conclude that our derivation approach conforms to our Design Decisions. However, this does not answer whether a UML profile automatically derived by our approach is comparable to a manually created one.

Thus, we compared TDL’s standardized UML profile \(\textit{UP}_{std}\) with our automatically derived UML profile \(\textit{UP}_{TDL}\) quantitatively and qualitatively. This comparison showed that some of TDL’s language concepts in \(\textit{UP}_{std}\) are not represented as Stereotypes but as UML elements, for which mapping rules but no OCL constraints exist. Furthermore, we also noticed that the Stereotypes in \(\textit{UP}_{std}\) have fewer attributes than the respective TDL metaclasses. Moreover, the cardinalities of some stereotype attributes did not match those of the corresponding metaclass attributes.

When compared to \(\textit{UP}_{std}\), our automatically derived \(\textit{UP}_{TDL}\) showed a certain correlation regarding the Stereotypes and extended UML metaclasses. Due to the one-to-one derivation of Stereotypes from TDL metaclasses, the highlighted syntactic drawbacks of \(\textit{UP}_{std}\) are not present in the automatically derived \(\textit{UP}_{TDL}\). Furthermore and because of our automatic OCL update, \(\textit{UP}_{TDL}\) enables an evaluation of the static semantics of TDL, which is infeasible with \(\textit{UP}_{std}\) due to the absence of OCL Constraints.

As mentioned before, we conducted another case study [27, 29] where the Specification and Description Language (SDL) [21] served us to evaluate our derivation approach for grammar-based DSLs. The focus of our investigation was on the semi-automatic creation of an SDL metamodel based on production rules and on the automatic derivation of a UML profile and ‘additional’ metaclasses. In the following, we briefly summarize the results of our SDL case study.

By comparing our generated UML profile \(\textit{UP}_{SDL}\) with the one standardized for SDL [20], we observed that the Stereotypes in the latter have a much smaller number of attributes. Furthermore, we noticed that many Stereotypes of the standardized UML profile represent not just one but several SDL language concepts. Both identified differences result in more complex mapping rules and OCL constraints in the standardized variant. In contrast, the Stereotypes of our \(\textit{UP}_{SDL}\) have a one-to-one relationship to SDL’s language concepts they represent. Consequently, we could decrease the complexity of mapping rules and OCL constraints.

Furthermore, we found that some of SDL’s well-formed rules were not captured by OCL constraints in the standardized UML profile, while in our \(\textit{UP}_{SDL}\) all rules are considered. Furthermore, we identified differences regarding OCL constraints that ensure the syntactic structure: OCL constraints of the standardized UML profile capture less syntactic aspects than those of our \(\textit{UP}_{SDL}\). This is because our derivation approach automatically introduces OCL constraints in order to ensure syntactic aspects, e.g. the application of specific Stereotypes to attribute items. In contrast, this kind of OCL constraints may be ignored when manually creating a UML profile, because they are often the result of implicit requirements imposed by structural aspects. Hence, we consider the automated derivation of UML profiles to be less error-prone when compared to manual creation.

The above comparison clearly shows that a UML profile generated with our derivation approach captures all language concepts of a DSL as dedicated Stereotypes. This is the essential prerequisite for an automatic transfer of the OCL-defined static semantics from a metamodel to a UML profile and enables the evaluation of the static semantics for UML models with applied UML profile. For manually created UML profiles, an OCL-defined static semantics is either not available or not all well-formedness rules are captured. Furthermore, our automatic derivation prevents manual modelling errors such as false multiplicities of stereotype attributes.

7 Related work

Apart from manual approaches (e.g. [30, 50]) for creating UML profiles, the most closely related works to ours are [13, 14, 48, 56], which also automatically derive UML profiles from existing DSL metamodels. Their commonality is that, in addition to the metamodel, mapping rules must be provided as input for the profile derivation. Depending on the approach, this is realized in terms of so called ‘Integration Metamodels’ or ‘Mapping Models’. In contrast, our approach expects CMOF-based metamodels as input for the derivation of UML profiles, which reuse ‘Abstract Concepts’ as proposed in [10, 49].

Giachetti et al. propose an approach [13, 14] that can be applied to generate UML profiles and mapping rules for model transformations. To derive these artefacts, they employ a certain type of EMOF-based metamodel called ‘Integration Metamodels’ [15]. Such a metamodel is initially created as a copy of a metamodel for the DSL of interest. In the next step, the copy must be altered manually by adding additional metaclasses, until all rules defined for ‘Integration Metamodels’ are met. In addition, the structure and semantics of the UML metaclasses that are defined as a mapping target and the ones of the DSL metamodel have to be considered during the rework. Because of the creation of new metaclasses, a revision of the OCL constraints contained in the ‘Integration Metamodel’ is required. Furthermore, the mappings to UML metaclasses also have to be specified in the ‘Integration Metamodel’. Finally, a UML profile and the mapping rules can be generated based on the revised ‘Integration Metamodel’. Giachetti et al. state in [12, 13] that the OCL constraints contained in an ‘Integration Metamodel’ must be included in a derived UML profile. Therefore, all references in OCL constraints to elements of the ’Integration Metamodel’ are modified so that corresponding UML metaclasses or stereotypes are referenced after UML profile generation.

In contrast, our approach for deriving UML profiles can be applied to CMOF-based metamodels that are created by reusing ‘Abstract Concepts’. Due to the correlation between ‘Abstract Concepts’ and UML metaclasses, we do not have to modify a metamodel so that its structure matches that of the UML metamodel, as is required for an ‘Integration Metamodel’. In most cases, we can use these correlations to automatically determine the information required for deriving the different elements of a UML profile. The explicit definition of mapping information is only necessary if ‘additional’ metaclasses shall be derived, or if a derived Stereotype shall extend a UML metaclass that does not have a matching ‘Abstract Concept’ counterpart.

Another advantage of our approach is the possibility to define ‘alternative’ OCL expressions so that the values of stereotype attributes are computed at runtime without manual assignment. This is also useful if the value of an attribute can only be determined based on UML model elements that do not have stereotypes applied, or if several model elements must be accessed to obtain the required values.

Equally important and in contrast to our work, the approach of Giachetti et al. [13, 14] does not consider the generation of OCL expressions and constraints for subsetting and redefining stereotype attributes. While they discuss a transfer of OCL constraints of an ‘Integration Metamodel’ towards generated stereotypes by adapting the referenced element types, this is insufficient to obtain valid OCL constraints for generated UML profiles. Because stereotypes and UML metaclasses are instantiated separately, additional attribute navigations must be inserted in OCL expressions, as supported by our approach.

Another category of related works covers the derivation of metamodels based on existing UML profiles, as proposed in [33, 35], which is exactly the inverse of our approach. The creation of a UML profile from scratch may be an option for a new DSL with low complexity, but for an existing DSL with higher complexity this can be difficult. This is because not only the static semantics of the DSL but also UML’s static semantics must be taken into account. Therefore, the manual creation of a metamodel followed by an automatic derivation of a UML profile should be preferred for more complex DSLs such as SDL [21]. This variant should also be chosen if the production rules for a DSL are given, because then existing tools [16] (e.g. EMFText [17] or xText [1, 5]) can be employed for automatically deriving metamodels.

8 Summary and Conclusions

In addition to our overview on all aspects of our derivation approach given in [28] and our SDL case study [27], which evaluates the applicability of our approach to grammar-based DSLs, the present article details the fully automated derivation of UML profiles and the transfer of static semantics from metamodels to these profiles. In addition, we present another case study on TDL, where we evaluate the applicability of our approach for DSLs to be created from scratch. Our DSL-MeDeTo tool chain, which implements our approach, and the case studies on TDL and SDL are available via our homepage [58].

While only syntactic constructs for UML profiles can be automatically derived from EMOF-based metamodels using existing works [13, 14, 48, 56], our approach also supports CMOF-based metamodels. Particularly noteworthy is the mapping of redefining or subsetting metaclass attributes to ‘derived’ and ‘read-only’ stereotype attributes, whose values are computed at runtime via automatically generated OCL expressions. The advantage of such stereotype attributes is that a manual value assignment at runtime is not required, which also reduces the modelling effort.

The automated update and transfer of OCL-defined attributes, Operations and Constraints to a UML profile is a further contribution of our approach when compared to existing works. This enables us to automatically transfer the static semantics of a DSL metamodel to a derived UML profile. Consequently, we make it possible to automatically evaluate the static semantics for UML models that have applied a UML profile for a particular DSL.

As highlighted in Introduction to this article, a manual creation of UML profiles is often error-prone and, if present, well-formedness rules of UML profiles are usually specified in natural language, which can lead to ambiguities. We confirmed these statements with our TDL case study, where we identified several shortcomings regarding the syntax and static semantics of TDL’s standardized UML profile [6]. On the one hand, we found that no corresponding stereotypes exist for some TDL metaclasses, not all metaclass attributes are captured by stereotype attributes, and the cardinalities of metaclass and stereotype attributes do not match. On the other hand, the standardized UML profile for TDL has only two OCL constraints, while the metamodel has 62. Consequently, TDL’s static semantics is not captured by the UML profile. In contrast, the aforementioned shortcomings are fixed in the UML profile for TDL that we derived via our DSL-MeDeTo toolchain. In particular, a stereotype is present for each TDL metaclass, and all metaclass attributes are captured by stereotype attributes. Furthermore, all OCL constraints of TDL’s metamodel are updated and transferred to the derived UML profile. Therefore, TDL’s static semantics can be automatically validated for UML models that have the profile applied.

Because our work has overcome essential shortcomings of existing approaches for the derivation of UML profiles, especially the support of CMOF language concepts and the automatic transfer of static semantics, we anticipate that there is no demand for substantial future work in this area. However, some limitations regarding the derivation of CMOF-based metamodels and transformations for model interoperability exist, because we only create these artefact types semi-automatically based on a single metamodel. As the main goal of our work is the derivation of UML profiles, a semi-automatic generation of the other artefact types is sufficient for us. The consideration of certain approaches presented in the literature, e.g. in [9, 31, 56]), could be of interest for the fully automatic generation of model transformations.