On the automation-supported derivation of domain-specific UML profiles considering static semantics

In the light of standardization, the model-driven engineering (MDE) is becoming increasingly important for the development of DSLs, in addition to traditional approaches based on grammar formalisms. Metamodels define the abstract syntax and static semantics of a DSL and can be created by using the language concepts of the Meta Object Facility (MOF) or by defining a UML profile. Both metamodels and UML profiles are often provided for standardized DSLs, and the mappings of metamodels to UML profiles are usually specified informally in natural language, which also applies for the static semantics of metamodels and/or UML profiles, which has the disadvantage that ambiguities can occur, and that the static semantics must be manually translated into a machine-processable language. To address these weaknesses, we propose a new automated approach for deriving a UML profile from the metamodel of a DSL. One novelty is that subsetting or redefining metaclass attributes are mapped to stereotype attributes whose values are computed at runtime via automatically created OCL expressions. The automatic transfer of the static semantics of a DSL to a UML profile is a further contribution of our approach. Our DSL Metamodeling and Derivation Toolchain (DSL-MeDeTo) implements all aspects of our proposed approach in Eclipse. This enabled us to successfully apply our approach to the two DSLs Test Description Language (TDL) and Specification and Description Language (SDL).


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 Communicated by Sebastien Gerard.
This article is an extended version of our contribution [28] to the 15th European Conference on Modelling Foundations and Applications (ECMFA) in 2017.

B Alexander Kraas
Alexander.Kraas@swt-bamberg.de 1 Software Technologies Research Group, University of Bamberg, Bamberg, Germany 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 CMOFbased 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.

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.

Our overall approach
Our overall derivation approach shown in Fig. 1 consists of Steps (A)-(E), some of which are optional. The DSLspecific metamodel MM Domain is the central artefact for almost all derivations. If production rules of a grammarbased 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 (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 MM AC .
If we derive MM Domain from production rules in Step (A) 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 MM Domain are required from a semantic point of view, and if not, the affected ones must be removed. Otherwise, we create MM Domain from scratch. To do so, we copy the 'Abstract Concepts' from MM AC to 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 MM Domain . Finally, we capture the DSL's static semantics via OCL constraints and enrich MM Domain with toolchain-specific meta-information. For this purpose, we apply the UML profile 'MM2Profile' to 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 MM Domain via our toolchain.
After creating MM Domain , we can automatically derive a DSL-specific UML profile UP Domain in Step (B). If required, additional metaclasses (contained in MM Add ) that extend the MM U M L 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 T DM−to−U M L and T U M L−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.

The 'Abstract Concepts'
The metamodel MM AC holds a key role for our entire derivation approach, because metaclasses of the metamodel MM Domain inherit from 'Abstract Concepts' defined by MM AC . An important prerequisite for MM AC is that it must match a subset of MM U M L . Otherwise, a straightforward mapping of MM Domain to UP Domain , as implemented by our approach, is impossible.
We consider a metamodel MM AC to be matching with MM U M L , if the following constraints are fulfilled: 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 removed 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 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 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 MM U M L . We capture this condition by the following constraint: Different approaches can be applied to obtain a metamodel 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 MM AC shall match with MM U M L , we consider a creation of MM AC from scratch to be too errorprone 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 MM AC that only supports structural language concepts (e.g. Classifier). Finally, also the reuse of parts of MM U M L 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 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 MM AC is created manually as a copy, or automatically using the Package Merge feature provided by the CMOF.

The DSL metamodelling and derivation toolchain
We have implemented all aspects of our approach in the novel DSL Metamodelling and Derivation Toolchain (DSL-MeDeTo) [ Fig. 2). Hence, one of these tools also has to be utilized for applying the UML profile 'MM2Profile' to a metamodel.

Running example
The 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].

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  , specified in TDL's graphical notation a metamodel with information that is required for the derivation. Thereafter, we discuss the details of our approach.

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 MM Domain have to be processed in different ways. In addition, we have to consider that MM Domain also contains metaclasses that represent 'Abstract Concepts'. Hence, we presume that the metaclasses in MM Domain can be divided into three different sets. The first set represents 'Abstract Concepts'; a metaclass of this set is denoted as MC AC . The second set includes those metaclasses that shall be mapped to Stereotypes of the derived UML profile UP Domain . We use the term MC St to refer to a metaclass of this set. The third set contains metaclasses that map to 'additional' metaclasses in the metamodel MM Add . A metaclass of this set is denoted by MC AMC .

Design Decision 1 A metamodel MM Domain consists of a set of MC AC metaclasses, a set of MC St metaclasses, and an optional set of MC AMC metaclasses.
Each 'Abstract Concept' metaclass has a 'matching' UML metaclass in MM U M L , 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 MC AC metaclasses contained in MM Domain . In addition, we employ the name prefix to identify that a metaclass of MM Domain is an MC AC metaclass.

Design Decision 2 An 'Abstract Concept' metaclass MC AC has a name prefix 'AC_' and is not mapped to any kind of element.
Hence, all metaclasses without a name prefix are MC St or 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 MC AMC metaclasses. For this reason, we define metaclasses that have no special qualifier or name prefix as MC St metaclasses. By default, we use this type of metaclasses of MM Domain to derive Stereotypes for a UML profile, as shown in Fig. 4.  Fig. 4.

Design Decision 4 An Extension shall be introduced for each Stereotype, which is derived from an MC St metaclass that directly inherits from an 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 MC St metaclasses that are in a Generalization relationship (e.g. metaclasses MC St E and MC St D in Fig. 4).

Design Decision 5 A Generalization is introduced for each Stereotype that is derived from an MC St metaclass that inherits directly from another 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 OCLdefined static semantics of a metamodel to a UML profile. Therefore, we map each Property that is an ownedAttribute of an MC St to a corresponding Property of a Stereotype. However, we have to obey the following rule of the UML specification: Therefore, we map an 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 MC St attribute is mapped to a corresponding Stereotype attribute. If the type property of an MC St attribute refers to a metaclass, the aggregation property of the mapped Stereotype attribute shall have value 'none'.
If an ownedAttribute of an MC AC is redefined or subsetted by an ownedAttribute of an 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 MC St attribute that redefines or subsets an 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 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 MM Add . 58 A. Kraas Assume that an MC St A that inherits from at least two MC AC metaclasses is used as the type of a metaclass attribute att_A, and the 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 MC St of MM Domain inherits from at most one MC AC , so that only one Extension would be derived for a Stereotype. However, this approach would require a modification of 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 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 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 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 MC St can also inherit from an MC AC and one or more 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.
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 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 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 'readonly' and that is mapped from an MC St attribute with a type property that refers to an 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 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.

Enriching the source metamodel
Provided that 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 MC AC metaclasses and a set of 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 MC St in MM Domain .
However, the direct use of 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 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. The <<MM2Profile>> stereotype Because this stereotype has an Extension that is specified as required, it is automatically applied to the Package that represents 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 MM Add .
While attributes prefixed with 'profile' are passed to the derived UML profile UP Domain , all attributes with the 'add' prefix are passed to the metamodel 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 MC St metaclass.
The <<ToMetaclass>> stereotype According to Design Decision 3, an additional qualification for an MC AMC metaclass in MM Domain is required. Hence, we employ the stereotype <<ToMetaclass>> to define that a metaclass of MM Domain represents an MC AMC metaclass. The <<ToMetaclass>> stereotype provides the following attributes: alternativeName defines an alternative name for an 'additional' metaclass contained in 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.
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 MM Domain . For example, assume an MC St A is given that inherits from an MC AC at a high level of abstraction (e.g. AC_ Namespace) and another 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.

TDL Example: Input Metamodel
TDL's standardized metamodel 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 Package-ableElement. These metaclasses are comparable to those contained in the UML 'Kernel' package. Thus, one can assume that these metaclasses of MM std already correspond to the 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 MM std as input to derive a UML profile. Therefore, we have aligned MM std to meet the requirements of our derivation approach. Below, we refer to the revised metamodel of TDL using the term MM T DL .
To obtain MM T DL , 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 MM T DL with the meta-information that we require to derive a UML profile.
An excerpt of our modified MM T DL 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 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 MM T DL metamodel. Applying the <<ToStereotype>> stereotype on an 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 MC St attribute being mapped according to the default rules of our derivation approach. An 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 MC St attributes dataType and memberAssignment in Fig. 7a have the <<ToTaggedValue>> stereotype applied.

Our derivation approach
In the following, we discuss the details of our approach for deriving a UML profile UP Domain from a metamodel MM Domain that is enriched with the UML profile MM2Profile. To illustrate certain aspects of our approach, we use the MM T DL metaclasses and their corresponding Stereotypes in the UML profile UP T DL 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].

Mapping to 'Stereotypes'
The first step of our approach to derive a UML profile UP Domain from a metamodel 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 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 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 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.  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 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 MC AC and MC ST metaclasses in 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 MC St SM in 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 MC AC metaclasses that are super-types of the MC St SM. Then, we resolve the 'matching' UML metaclasses for that 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 MC St metaclasses in Fig. 7 inherit from 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 MC St metaclasses.

Mapping of DataTypes
Apart from Stereotypes, a UML profile can also introduce different kinds of data types, which can be DataTypes, Prim-itiveTypes, or Enumerations. For the derivation of a UML profile, we determine those data types of MM Domain that do not represent 'Abstract Concepts' and that are not mapped to data types of 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 Fig. 9 Mapping to derived attributes map to a metamodel MM Add . Thus, they are copied one-toone to UP T DL as shown in Fig. 8.

Mapping to stereotype attributes
According to Design Decision 6, we map an 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.
In Case (A) of our example, an MC St A with an attribute a and an 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 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 MC St metaclass ComponentInstance in Fig. 7b. As it redefines the type attribute of the 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 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 MC St attribute in 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 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 MC St attributes are mapped one-to-one to corresponding stereotype attributes, including those MC St attributes that are redefining/subsetting other 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 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 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.

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 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.
Let A be an MC St in MM Domain and A' its corresponding Stereotype in UP Domain . In addition, assume that 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 MC AC (Case A), an MC St (Case B), or an MC AMC (Case C) metaclass, as shown in Fig. 11. We determine the type property of att' as follows: 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 MM Domain may contain data types, which we copy one-to-one to the UML profile UP Domain or the metamodel MM Add . Because such data types can also be used as attribute type in 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 UP Domain , MM Add or MM U M L ; then, we use it as the new type of a mapped attribute.
The unassignedMember attribute of the <<StructureDataInstance>> stereotype and the Fig. 11 Variants for recomputing the attribute type 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.

Mapping to stereotype operations
In addition to attributes, a metaclass MC St can also have Operations specified, which we map to corresponding items of a created Stereotype in UP Domain . To do so, we map most of the properties of an 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 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.

OCL expressions for stereotype attributes
By Design Decision 7, we map a redefining or subsetting 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.
Assume we have given an MC St A that inherits from an 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 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:

Additional OCL constraints
Because the type properties of stereotype attributes are recomputed, we introduce additional OCL constraints to preserve the static semantics defined by 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 wellformedness of UML metaclass attributes that are relevant for computing the defaultValues of 'derived' and 'read-only' stereotype attributes.

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 MC St attribute att, where its type property refers to an 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 multivalued attributes: (1) self.<att_st> <> null implies self.<att_st>.isStereotypedBy(<ST>) (2) self.<att_st>−>forAll(isStereotypedBy(<ST>)) For instance, the type property of the component attribute of the MC St GateReference in Fig. 7b  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.

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 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 default-Value. 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 MC St attributes in the source model MM Domain are subsetting or redefining the same 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.

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 MM Domain to a derived UML profile 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.

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   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 Type-Exp 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 Feature-CallExp 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 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.

Design decisions for updating OCL expressions
Based on our design decisions for deriving UML profiles specified in Sec. 4

Design Decision 13 A PropertyCallExp that accesses the 'base_<metaclass>' attribute shall be introduced for OCL expressions that access an MC AC attribute or MC AC Operation via a 'self' variable that refers to an MC St .
The type properties of attributes are recomputed during the mapping, so that only Classifiers (Classes or DataTypes) of the MM U M L or 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 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 MC St feature to another 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 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 MC St metaclass as argument. During this update, we introduce a new OperationCallExp that invokes the operation isStrictStereotypedBy() or isStereo typedBy(). Exp 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 MM Add or MM U M L . The Stereotypes of 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 MM U M L or MM Add .

The OCL update in detail
We now detail our approach for updating OCL expressions contained in the metamodel 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 Feature-CallExp 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: 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 referred-Property: input: source.referredProperty result: source.extension_<stereotype>.referredProperty For example, the update defined by Design Decision 13 is applied to the constraint of the MC St StructuredData Type in Fig. 7a. The membersAreDistinguishable() operation that is invoked by this constraint is inherited from MC AC AC_Namespace. In UP T DL , 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: input: self.membersAreDistinguishable() result: self.base_DataType.membersAreDistinguishable() 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 PropertyCall-Exp 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:

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 MC St metaclass; 2. The referredProperty of a PropertyCallExp is an MC AC attribute, or in case of an OperationCallExp, the referre-dOperation is an 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: input: self.referredProperty result: self.base_<metaclass>.referredProperty For example, the 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 PropertyCall-Exp for both attributes extension_StaticDataUse and extension_Parameter. 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 MC St shown in the input expressions: Below, for example, we apply the OCL update according to Design Decision 15 to a constraint of the 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 MC St SimpleDataType specified as argument is substituted with the qualified name of the corresponding Stereotype: input: self.dataType.oclIsKindOf(SimpleDataType) result: self.dataType.isStereotypedBy('UP4TDL::SimpleDataType') TypeExp. According to Design Decision 16, we have to update all occurrences of TypeExp that refer to an MC AC or an MC St metaclass. A TypeExp that refers to an MC AC metaclass is updated so that the 'matching' UML counterpart of the MC AC is referenced. Furthermore, a TypeExp that refers to an 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 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 MC St TestDescription. After conducting our update, the UML metaclass BehavioredClassifier is passed as argument, as required by Design Decision 16.

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 UP T DL are created as expected. Then, we compare our UP T DL 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.

Evaluation of the generated UML profile UP TDL
In Table 2, we compare the metaclasses of MM T DL with the stereotypes that we have derived for the UML profile UP T DL . Because of Design Decision 1, we do not map MC AC metaclasses to model elements of UP T DL . Accordingly, the 13 MC AC metaclasses have no counterparts in UP T DL .
The <<ToStereotype>> stereotype is applied to 59 of the 80 MC St metaclasses in MM T DL , mainly to define the UML metaclasses to be extended by generated Stereotypes (Design Decision 9). Based on the number of MC St metaclasses in MM T DL , one could assume that UP T DL contains a total of 80 Stereotypes. As shown in Table 2, only 79 Stereotypes are created for UP T DL . This corresponds to the desired result, because we have defined the MC St MappableDataElement in MM T DL (see Fig. 7a) as not to be mapped. Stereotype extensions and generalizations. To explain more clearly for which kinds of MC St metaclasses Stereotypes are introduced either with Extensions or Generalizations, we distinguish two MC St groups in Table 2: For MC St metaclasses that inherit directly from MC AC metaclasses, we introduce Extensions between generated Stereotypes and UML metaclasses identified based on the MC AC metaclasses (Design Decision 4). Because one of the 33 MC St metaclasses that inherit directly from MC AC metaclasses is specified as not mappable, we derive only 32 Stereotypes with an Extension to a UML metaclass. 29 of these 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 MC AC metaclasses.
The  As shown in Table 3, MM T DL contains a total of 126 metaclass attributes, of which 99 are considered as MC St attributes that map to 52 'non-derived' and 47 'derived' stereotype attributes. The remaining 27 attributes are owned by MC AC metaclasses and, therefore, are not considered when deriving UP T DL .
To discuss the mapping of 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 MC St attributes of a group have the <<ToTaggedValue>> stereotype applied. This is because the application of this stereotype overrides the default mapping for MC St attributes, so that these attributes are mapped to 'derived' stereotype attributes.
The   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 UP T DL 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 MC St attributes whose type property refers to an 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 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 UP T DL are derived from redefining

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 UP T DL with the one standardized for TDL [6]. We refer to the latter UML profile via the acronym UP std . First, we analyse the number of model elements contained in UP std and UP T DL , 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 UP T DL . Quantitative comparison. To compare the various elements in UP std and UP T DL , we summarize their quantities in UP std embraces a lower number of Stereotypes than UP T DL , which is due to the above reason. In contrast and except of the MappableDataElement metaclass, UP T DL provides a specific Stereotype for each MC St metaclass of MM T DL . In addition, the Stereotypes of UP T DL have a larger number of attributes. One might assume that this is due to the larger number of Stereotypes in UP T DL . However, the question arises whether the different numbers of Stereotypes is the only reason, because UP T DL contains with 99 stereotype attributes almost twice as many as UP std . Another reason might be that not each metaclass attribute has a corresponding Stereotype attribute in UP T DL . 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 UP std has only two OCL Constraints, this statement also applies to those TDL language concepts for which corresponding Stereotypes are present. In contrast, UP T DL provides 113 Constraints and 10 Operations that are defined via OCL. These include not only the Constraints transferred from MM T DL , but also those introduced during the derivation of UP T DL . Therefore, we conclude that UP std cannot be used to ensure TDL's static semantics, whereas this drawback does not exist for UP T DL . Comparison of the syntactic structure. After we determined that UP std has some limitations over UP T DL , 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 UP std are shown in Fig. 15a, and those defined for UP T DL can be found in Fig. 15b.
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 UP std extends the UML metaclasses EncapsulatedClassifier and Property, whereas the one in UP T DL extends only the latter. Both UML metaclasses extended by the stereotype of 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 con-sider an extension of this UML metaclass by the <<ComponentInstance>> stereotype in UP std as semantically incorrect, and therefore, this Stereotype should only extend the UML metaclass Property, as is the case in UP T DL .
Comparing Figs. 15a and 15b, we find that the stereotypes of UP T DL have six and those of UP std have only three attributes defined by Association ends. Because stereotypes of UP T DL are derived from MC St metaclasses in MM T DL , they have the same number of attributes as the corresponding metaclasses. In contrast, stereotypes in 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 UP std . This is a viable way, but due to the absence of OCL Constraints in UP std , the values permitted for UML metaclass attributes are not constrained. Therefore, UP std allows the specification of models that are invalid in relation to the static semantics of TDL. Because UP std does not specify a corresponding stereotype attribute for each metaclass attribute, this also explains the difference in the number of attributes between UP std and UP T DL .
All stereotype attributes introduced by Association ends in UP T DL refer to UML metaclasses extended by Stereotypes. In contrast, the stereotype attributes in 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 UP T DL and 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 MM T DL . Thus, a syntactical difference between 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 UP std . We therefore assume that these are issues that result from the manual creation of UP std .

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 UP T DL was derived from MM T DL according to our Design Decisions 1-12. The comparison of UP T DL with MM T DL showed that exactly the number of model elements we expected, such as stereotypes, was generated for UP T DL . 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 UP std with our automatically derived UML profile UP T DL quantitatively and qualitatively. This comparison showed that some of TDL's language concepts in 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 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 UP std , our automatically derived UP T DL 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 UP std are not present in the automatically derived UP T DL . Furthermore and because of our automatic OCL update, UP T DL enables an evaluation of the static semantics of TDL, which is infeasible with 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 UP S DL 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 UP S DL 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 UP S DL 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 UP S DL . 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.

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.

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.