Since many tools for model-driven engineering (MDE) can only process consistent models, the consistency must be guaranteed by all tools which modify models, such as model editors, transformers, merge tools, etc. This is a recurring challenge for tool developers. An obvious solution of this challenge is to use a common library of consistency-preserving edit operations for modifying models. Typical meta-models lead to several 1000 edit operations, i.e. it is hardly possible to manually specify and implement so many edit operations. This problem is aggravated by UML pro les: Stereotyped model elements are implemented as complex data structures. This paper discusses several approaches to implementing edit operations on pro led models. Furthermore, it canvasses how to generate complete sets of speci cations and implementations of edit operations.
In model-driven engineering (MDE) models are the primary development
artifacts. Models are modi ed by many di erent tools, including model editors,
transformers, patch and merge tools [
A general solution to the challenge described above is to use a library of edit operations, but many of the existing libraries do not guarantee the consistency of the models. In this paper we present a novel approach to specify and implement a library of consistency-preserving edit operations (Section 2).
Consistency-preserving edit operations (CPEOs) depend on the meta-model, i.e. they are not generic. The set of CPEOs available for a given meta-model must be complete in the following sense: It must be possible to construct any consistent model and to edit each consistent model to become another consistent model. Complete sets of CPEOs are quite large; their creation should therefore be supported by (meta-) tools. Section 2 introduces SERGE, our own tool to generate CPEOs, and discusses the limitations of automatically generating sets of CPEOs.
The challenge of de ning CPEOs is aggravated in case of domain-speci c
modeling languages (DSMLs) which are de ned using the UML pro le
mechanism, e.g. SysML [
The main contribution of this paper is an analysis of how pro les a ect (sets of) CPEOs of the underlying non-extended meta-model. This is discussed in Section 5.
Several approaches are available for implementing CPEOs for pro led metamodels and for semi-automatically generating complete sets of CPEOs. Section 6 presents these approaches and discusses their respective advantages and disadvantages.
Section 7 summarizes the contributions of this paper. 2
Meta-Models. A model is conceptually considered as a typed, attributed graph which is known as the abstract syntax graph (ASG). Meta-models, e.g. the UML meta-model, de ne the types of nodes and edges allowed in an ASG. Following the common practice in MDE, we assume that there is an object-oriented implementation of meta-models. Thus, nodes and edges of an ASG are represented by (runtime) objects and references between them.
Consistency of Models. An ASG is considered consistent if it complies to the de nitions and constraints speci ed by its meta-model, notably constraints concerning hierarchies, relationships and multiplicities.
Standards such as the UML typically de ne strict, \ideal" consistency constraints; ASGs complying with them represent models which can be translated to source code and other platform-speci c documents. Many model editors (e.g. the Eclipse UML Model Editor) use de facto less strict meta-models. For example, they enforce only multiplicity constraints which are required to produce a graphical representation of a model.
Edit Operations vs. Basic Graph Operations. Meta-models are just data models of models, they do not directly specify editing behavior. One obvious approach to modify models is to use 'basic graph operations' on the ASG including deleting, creating, moving and changing elements, attributes or references.
Executing a single basic graph operation on an ASG can lead to a new state which violates the syntactic consistency. For example, a basic operation which creates a single UML StateMachine object leads to an inconsistent ASG: A StateMachine must always contain at least one Region. In contrast to this, a CPEO will create a StateMachine and create a contained Region at the same time. Thus, the model is transformed from one consistent state into another. This CPEO is minimal in the sense that it cannot be splitted into smaller parts which preserve the consistency of the model.
In general, an edit operation has an interface specifying input and output parameters. For example, the edit operation createStateMachine must be supplied with a container element in which the StateMachine is to be created, along with local attribute values for the new StateMachine. Objects created by an edit operation are handled as output arguments. Additionally, pre- and postconditions may precisely specify application conditions of an edit operation.
Basically, minimal CPEOs can be categorized into the same kinds of operations as basic graph operations, namely creation, deletion, move and change operations. However, minimal CPEOs usually comprise a set of basic ASG operations. An example for such an 'atomic compositions' of ASG elements is the creation of a StateMachine with at least one nested Region in a single transaction. 3
Comprehensive languages, such as the UML require large sets of edit operations. The manual speci cation of such sets of CPEOs for a given modeling language is very tedious and prone to errors.
This problem is addressed by our SiDi Edit Rules Generator (SERGe) [
According to our knowledge, there are no other approaches for constructing
CPEOs. There are approaches to create certain kinds of edit operations or
grammars which can construct or modify models [
SERGe uses the Eclipse Modeling Framework (EMF) [
Figure 1 shows the edit rule createStateMachine. This edit rule is generated by SERGe when processing the implementation of the UML2 meta-model in EMF Ecore. For the sake of readability, the rule shown in Figure 1 is a simpli ed version of the rule.
This example illustrates that a Henshin rule can de ne variables serving as input or output parameters. The input parameter Selected determines the context object to which an edit rule shall be applied. In our example, the context object will be the Model in which the StateMachine shall be created. The StateMachine object and its mandatory Region will be returned as output parameters New and Child when the rule is applied. Additionally, the name and the property isReentrant of the StateMachine to be created must be provided by the input value parameters Name and IsReentrant, respectively. Manual Adaptions of Generated Operations. SERGe is not capable of interpreting arbitrary well-formedness constraints (OCL ?? Constraints) attached to a meta-model element. Hence, some of the generated edit rules have to be complemented by additional application conditions.
For example, the UML meta-model speci es that all the members of a Namespace (which includes the packaged elements of a Model) are distinguishable by their names. Thus, a StateMachine can only be created in a Model if there is no NamedElement with the same name. This precondition can be implemented in Henshin by a negative application condition (NAC) as shown in Figure 2. Conclusion. We can conclude that the most important innovation of SERGe is that the generated edit operations comply to multiplicity constraints and preserve the consistency of a model in this respect. If required, the generated edit operations can be extended manually additional well-formedness constraints; this usually requires only a limited e ort.
However, SERGe currently does not address the generation of edit operations for UML pro les. Several design variants to extend a generator such as SERGe to pro le de nitions will be discussed in the remainder of this paper.
UML pro les provide a light-weight approach to implement domain-speci c languages by reusing existing meta-models.
Pro le De nition. Pro les are basically de ned as follows: A pro le must
import the base meta-model which contains the reused element types. Principally,
any MOF-based meta-model can be extended by a pro le de nition. In practice,
the UML meta-model serves as the base meta-model. Figure 3 shows an excerpt
of the SysML [
The UML pro le mechanism is designed in a way that all data related to a pro le are separated from the extended model; i.e. one or more pro les can be applied to a UML model without destroying its previous structure. Thus, the extended UML model always remains processable by UML tools.
An example of a pro le application is shown in Figure 4; a very simple SysML model is shown in concrete syntax (left) and abstract syntax (right). It illustrates how stereotype objects of type Block and FlowPort (colored in light gray) are attached to instances of the meta-classes Class and Port, respectively.
In this section we analyze how UML pro le de nitions in uence the set of CPEOs. The complete set of edit operations can be divided into four disjoint subsets which are described below.
A. Edit Operations modifying UML Model Elements. The rst set of edit operations operates on model elements that are instances of meta-classes of the base meta-model, i.e. the UML meta-model. For the sake of readability, we refer to them as (pure) UML model element operations. In principle, no knowledge about applicable pro les is required to generate these operations.
Nevertheless, these model elements can have stereotypes. Although the e ect of a UML model element operation does not depend on whether or not there is a stereotype, it can be necessary to omit or rename some of the generated edit operations, notably in case of required stereotypes. Thus, we further divide the set of UML model element operations into two main subsets: 1. Edit operations which create or delete UML model elements and their containment references.
These edit operations must be omitted if the type of the involved model element has a required stereotype in the pro le de nition. In this case, the base model element and the stereotype object have to be handled consistently by hybrid edit operations (s. Section 5.D). Other edit operations which modify the containment hierarchy, notably relocations of model elements caused by move operations, are not omitted. 2. Edit operations which change attributes or non-containment references of model elements. They are independent on whether or not a pro le is applied. It can be helpful to rename these operations for the sake of understandability, e.g. from setClassIsAbstract to setBlockIsAbstract.
In both cases, edit operations are omitted if they operate on instances of metamodel elements which are excluded by the pro le de nition. For example, SysML does not support interaction diagrams as de ned in UML2. Thus, edit operations modifying elements of type Interaction, InteractionFragment or Lifeline are omitted.
B. Edit Operations modifying Tagged Values. This subset comprises edit operations which change attributes or references of stereotypes. For the sake of simplicity, we refer to this subset as tagged value modi cations. These edit operations modify only parts of a model, speci cally the stereotype instances of the pro le. They can have arguments whose type is de ned by the base metamodel; these arguments remain unchanged.
Tagged value modi cations are easy to de ne and implement if their domain is a primitive data type. For example, the edit operation setBlockIsEncapsulated simply sets the tagged value isEncapsulated of a SysML Block. Tagged value modi cations are more complicated if they change references of stereotype objects. Here, multiplicity constraints which de ne mandatory neighbours or children must be taken into account. These cases can be handled in the same way as modi cations of references on UML model elements (see Section 2). C. Edit Operations for Stereotype Application. Stereotypes are applied to or removed from an UML model element by Stereotype Applications. From a users' point of view, this can appear as a conversion of a model element to another type. On the ASG level, a stereotype application is an edit operation that creates or deletes a stereotype object together with the reference to an instance of its base meta-class.
These edit operations are not permitted for stereotypes that are declared as required for their base meta-class. In such cases they are omitted from this set of edit operations. For example, the stereotype application operations applyStereotypeBlock and unapplyStereotypeBlock are not applicable to SysML models. The stereotype Block must always be created or deleted together with an instance of its base meta-class Class, but not without. This kind of modi cation is achieved by a hybrid edit operation.
D. Hybrid Edit Operations for Required Stereotypes. Hybrid edit operations concurrently modify instances of base meta-classes and stereotype instances. Typically, they create or delete model elements that have required stereotypes. An example is given in Section 5.C; creating a SysML Block requires the creation of a UML Class to which it must be attached as stereotype. 6
The previous section introduced 4 di erent kinds of edit operations. The complete set of operations which is necessary to consistently edit pro led UML models, is the union of these 4 sets and represented by the dotted rectangle in Figure 5.
The edit operations speci ed in subsections 5.A can be generated by SERGe. The same is true for edit operations speci ed in subsections 5.B and 5.C because pro le de nitions are handled as usual MOF-based meta-models.
However, some extensions are necessary for the generation of hybrid edit operations (Section 5.D). Generally, hybrid edit operations can be implemented using two di erent approaches: A higher-order transformation approach and a meta-model driven approach. A. Higher-order Transformation Approach. This approach uses a set of existing UML edit operations as primary input (see arrow 1 in Figure 5). It does not matter whether the edit operations have been generated and/or constructed manually. The basic idea is to modify them by adding appropriate stereotypes.
We assume that edit operations are de ned as executable speci cations in the form of Henshin transformation rules as explained in Section 2. Henshin rules are technically represented as models and can be transformed automatically, i.e. their modi cation can be considered as a higher-order transformation (HOT).
We have implemented this HOT in Henshin as follows: Basically, stereotypes
as de ned by the pro le are applied to all instances of a UML base meta-class
which occur in the given set of UML edit rules. A parametrized HOT rule is
provided in order to attach an instance of a stereotype. The necessary parameters
are the stereotype and the UML meta-class. We have implemented three variants
of this HOT rule: They attach stereotype objects to UML model elements which
are (1) to be created, (2) to be deleted and (3) to be preserved by an edit rule.
A working example of a HOT rule can be found at [
Since a UML meta-class can be extended by several stereotypes, di erent variants for every stereotype will be created. Such variants can also consist of combinations of multiple stereotypes, if more than one meta-class is contained in the given UML edit rule. Thus, the scheduling algorithm which applies the HOT rules with appropriate invocation arguments is responsible for generating all possible combinations of stereotype attachments.
A big advantage of this approach is that e orts of manual adjustments on UML edit operations are not lost. A disadvantage is that it supports only simple pro les: It cannot handle stereotypes which have mandatory references to other stereotypes or UML model elements. However, important pro le-based standards such as SysML and MARTE rarely contain such scenarios.
B. Metamodel-driven Approach. This approach does not require any previously generated sets of edit operations, all operations are generated from scratch; the pro le and the base meta-model are the only input data here (see arrow 2 in Figure 5).
This approach can consider multiplicity constraints of (non-) containment references which emanate from stereotypes. However, in contrast to the HOT approach, all manual adjustments on an existing set of UML edit operations (modi cations, creations and deletions) are lost. Manually created edit operations for the base language are not automatically adapted.
Two alternative patterns are available for implementing a hybrid operation; Figures 6 and 7 illustrate them using the creation of a SysML Block as an example: 1. Sequentially boxed operations (Figure 6): Here, the UML edit operation and the pro le application operation are applied in sequential order; initially, a class instance is created. In a next step the required stereotype is added. 2. Concurrent operation (Figure 7): Basically, all edit operations used separately in the rst approach are 'merged' into one. For Henshin transformation rules, such a merge can be implemented by concurrent rule construction.
This paper has presented our approach to construct complete sets of consistencypreserving edit operations on models. In contrast, existing approaches for generating edit operations do not support consistency preservation and DSMLs using UML Pro les such as SysML or MARTE.
We addressed an important practical requirement: How to consistently maintain operation sets for the base language without pro les and for the pro led language. Our solution is based on a clear separation of all edit operations in 4 categories. The most complex type of edit operations are hybrid ones; we showed that they can be implemented in such a way that manual optimizations of the base edit operations can be preserved.
Acknowledgement. This work was partially supported by the DFG (German Research Foundation) under the Priority Programme SPP1593: Design For Future - Managed Software Evolution.