In [2] we discussed both the theoretical and practical foundations with the goal to support domain-specific model patterns in metamodeling environments. In order to support the treatment of early model parts, we weakened the instantiation relationship. We worked out various constructs that help relaxing the instantiation rules, and showed that the utilization of these constructs allows to express domain-specific patterns.
Metamodeling is a successful technique to define the rules of graphical modeling languages. The method allows to define the metamodel itself and also provides an instantiation relationship. We say that a model is valid if it can be obtained from the metamodel via the agreed instantiation relationships.
Since metamodels allow model descriptions, various language-related operations could be handled in a more general way, if the metamodel is also present with the model. This leads us to the concept of reuse, i.e. an operation assumes a metamodel description language, the instantiation method is the only fixed element, the model and its metamodel become variable parameters, and in this way the features of a modeling tool can be reused across any model in a metamodeling environment.
Domain-specific design patterns are design patterns inserted into domain-specific languages. They are addressing a specific domain-related challenges [11]. In domain-specific languages, not only design patterns can be developed, but model patterns for many other purposes. The modeling language patterns in this broader sense are referred to as domain-specific model patterns. We have developed the method and also the tool support for domain-specific model patterns. The features for pattern specification are general, i.e. they exploit the benefits of metamodeling described above: the metamodels can be taken as parameters in metamodeling environments. However, we need to weaken the instantiation rules to be able to store premature model parts in a metamodeling environment.
In software modeling and graph rewriting-based model transformation, there are several recurring problems that should be solved repeatedly in the context of different environments or different transformations. A pattern is a reusable entity, which describes a frequent design or implementation problem, and gives a general, but customizable solution for it.
Model transformations are formed using transformation rules. Within a model transformation, it is required that each rule be defined over an attributed type graph. This type graph is obtained by regarding the metamodels of both the source and the target languages. As a consequence, one requirement for rules is that both LHS and RHS are instances of their corresponding metamodels.
Often, this instance relationship is loosely applied: we require that a model or a transformation rule must be an instance of the metamodel, but should not necessarily conform to additional constraints (e.g.
attribute value constraints). This does not affect cardinality constraints. The reasons of this method are that we do not want to define unnecessary restrictions when designing a model transformation and we aim to reduce the number of rules by allowing abstract classes.
Figure 5-1 illustrates that metamodel-based transformation rules are on the same level as metamodels, furthermore, introduces the instantiation hierarchy applied in a metamodeling tool. The left-hand side of the transformation rules is built based on the types and associations of the input metamodel. Similarly, right-hand side of the transformation rules is built based on the types and associations of the output metamodel. The figure summarizes the instantiation relationships between the meta-metamodel, metamodels, instance models and transformation rules. Domain-specific design patterns are also valid or relaxed instances of the metamodels. We apply and reuse these model patterns with the help of transformation rules, i.e. transformation rules insert the model patterns into the appropriate parts of the instance models.
Figure 5-1 Supporting domain-specific design patterns
In [2], the concepts of partial instantiation, relaxed multiplicity, and relaxed instantiation relationship are introduced. In order to support the treatment of premature model parts, such as transformation rules or model patterns, this approach also weakened the instantiation relationship.
In requiring valid intermediate models after each rule execution, the following question arises: Can we use the same metamodel both for intermediate models and for the final output model? To support the model transformation process with the same metamodel, certain relaxations should be allowed on the instantiation relationship, i.e., special instantiation rules are necessary. In order to describe these special instantiation rules, we need to introduce the concept of partial instantiation.
Definition (Partial instantiation). If a model can be extended to a valid instance model, it is a partial instance of a metamodel. During the extension, it is not allowed to delete or modify any element or attribute value of the partial instance model, but only extension functions, i.e., adding new elements and initializing (uninitialized) attribute values is permitted.
In the majority of the practical cases, partial instantiation means relaxing the multiplicities on the edges and the cardinalities of the nodes in the metamodel.
Assuming that a multiplicity interval is m1..m2, where m2 can be infinity. The relaxed version of this multiplicity interval is 0..m2. Similarly, assuming that a cardinality interval c1..c2, where c2 can be infinity. The relaxed version of this cardinality interval is 0..c2.
instantiate instantiate
With relaxing the multiplicities and cardinalities, we facilitate the omissions of certain nodes and edges.
However, the patterns in certain cases do not conform to the relaxed model. Assume the following containment chain: Queue-Task-Subtask. When we define patterns, it would be desirable to model a subchain of these chains. In general, this means that we allow transitive containment in the model.
Definition (Transitive containment). Assume a directed containment path between two nodes N1 and N2
in a metamodel. Transitive containment means that objects of N1 can contain objects of N2.
Assume that the modeler has constructed a pattern with the containment chain Queue-Subtask. In the editor (at the concrete syntax level), it seems that the modeler must insert a Task between the Queue and the Subtask to extend the pattern to a valid instance. However, it is not true on the abstract syntax level.
First, it must be allowed that a Subtask can be dropped onto a Queue. Second, on insertion, the tool must disconnect the containment between the Subtask and a Queue. Finally, the tool must connect the inserted Task to the existing Queue and Subtask. In general, it is not true that a model with transitive containment can be extended to a valid instance by adding elements only.
We can state that a model allowing transitive containment with respect to its metamodel is not necessarily a partial instance. An example preceded the statement that proves that there exists a case where the transitive containment violates the rules of partial instantiation. If a model uses transitive containment where the metamodel allows it, then the model is obviously still a partial instantiation.
Also, the multiplicities along the containment path are not considered in Definition of Transitive containment, which can lead to another type of violation.
Definition (Dangling edge relaxation). Dangling edges are edges that are not connected to a node at either end. Assuming two nodes with an edge between them, and this construct conforms to the metamodel. Dangling edge relaxation means that either of the nodes is allowed to be omitted.
Definition (Incomplete attributes). Incomplete attributes are uninitialized attributes in a model element with no default value.
In Figure 5-2, two invalid partial instances of our DomainServers metamodel (Figure 3-2) are presented.
In Figure 5-2a, the Queue is associated with two Server nodes. In Figure 5-2b, there is only one DB Task. Without the deletion and modification of certain elements, these model patterns cannot be extended to a complete instance model.
Figure 5-2 Example of (a-b) invalid partial instances, (c) valid partial instance
Figure 5-2c depicts a valid partial instance of the DomainServers metamodel. A server node contains a tier. The server has a ThreadPool containing two threads, but the required Queue is missing. This partial instance can be extended to a complete instance model by only adding new elements and providing uninitialized attribute values.
The following statement shows further connections between the partial instantiation and the pattern constructs presented above. If a model is created violating the instantiation rules in the following respects only: dangling edge relaxation, and incomplete attributes, then the model is a partial instantiation of its metamodel.
Relaxed instantiation relationship and relaxed multiplicity rules based on the above definitions support the definition and utilization of domain-specific design patterns and model patterns.
The practical relevance of domain-specific model patterns, and the theoretical foundations for the issue, i.e. that patterns are not always regular instances of the metamodel motivated us to provide tool support for model patterns.
Defining domain-specific model patterns and reusing them in different domain-specific models offer great perspectives for rapid application development and keep reliability at a high-level as well. VMTS has been prepared to provide tool support to create general but customizable model patterns. The support of domain-specific patterns also highlights the benefit of metamodeling.
An important rule is that patterns can be applied for models having the same metamodel as the patterns.
It is not enough to create patterns on their own; there is a natural need for the capability of organizing them into pattern repositories and attaching some meta-information to the patterns as well. In this way, a large number of patterns can be handled effectively. For this purpose, we have built a DSL with metamodeling techniques. We have created pattern models that are independent from their target model into which the patterns are inserted. For the catalog, a pattern metamodel is created. As a result, a pattern repository domain-specific modeling language is created. Its nodes contain references to pattern models.
Thus, the models of this language behave as pattern repositories as they can contain numerous references to real design pattern models.
Note that pattern models use the same metamodel as the target model. When inserting a pattern into a model, we offer only those patterns that have the same meta-model as the model itself.