Semantics of References in Meta-Models

Meta-Models define structural properties of models conforming to them. In this article the focus is on EMF-based meta-models, as a large tool landscape supports EMF and Ecore. In Ecore, meta-models comprise of classes with attributes and references between these classes. See the EMF documentation for more details. While the syntax of Ecore meta-models is well defined, the semantics of model elements depend on the domain where the meta-model is designed for. However, there are similarities in the semantics of structures defined in Ecore.

This article addresses the semantics of references in models in the context of aspect-oriented (AO) domain-specific languages (DSL). References play an important role in AO-DSLs, as they are especially used to express the join points. Furthermore, references are also used in DSLs for other purposes, like referencing definitions and declarations. Due to my goal of automatically integrating AO-DSL generator fragments into working generators, it is important to distinguish references for aspect-orientation and for other uses.

In the first Section, I briefly define the terminology used in the article. Section two gives an introduction to different realizations or references. And the third Section, discusses the different uses for references and where they occur in DSL development.

Foundations

Before I discuss the technical and semantical properties of references, some terminology has to be introduced. Many terms are well known in the modeling community, which allows me to be brief, others are only used in a few papers and might not be common knowledge.

A model is an abstract representation of a system (which can be also a model). In this publication, a model comprises of objects and references between these objects. Objects and references must conform to a meta-model, which defines classes with attribute and reference declarations. In ecore, reference declarations can express containments or associations, they can be optional and they can have a multiplicity. A containment expresses that the referenced object belongs to the referrer, while a association expresses other types of relationships.

Software systems comprise different concerns, like monitoring or access control, which influence the main structure and behavior of a system. Concerns, which affect different location in a system’s code are called cross-cutting concerns. The modeling of cross-cutting concerns have first led to aspect-oriented programming (AOP) and then to aspect-oriented modeling (AOM).

In recent years, domain-specific languages (DSL) became a popular method to define models and express different aspects of software systems. These aspects include structure and behavior of the software system, the system’s deployment and configuration, and also the previously mentioned cross-cutting concerns. In the composition of the software system, aspects and the models representing theses aspects play different “roles”. The main path of execution, which determines the behavior of the software system and implements the functionality of the software, is called base model, while those aspects, which are woven in the base model or its execution representation are called aspect models. These models must conform to their respective meta-models, called base meta-model and aspect meta-model.

Transformations are then used to interpret the base and aspect models, called source models and generate appropriate target models. The meta-models for the source and target model are called source meta-model and target meta-model respectively. In conjunction with the previous definitions of base and aspect model this leads to four different names for models and meta-models, which are used in this article.

Different Techniques to Realize References

References in models encode the location of a foreign model node in a way that an interpreter of the model containing the reference can find the node in the destination model. If the destination node cannot be reached, the reference is a dangling reference.

In EMF references are represented by EReference classes. These references can refer to nodes in the same (local nodes) and other models (foreign nodes). Local and foreign model can either have the same meta-model, like in Java one class declaration can inherit form another class declaration, or can have different meta-models.

To model references between models with different meta-models, a reference must have knowledge of the referenced node and the meta-model of the foreign model. this can be achieved in ecore in different ways. Here, I sketch two possible approaches. First, the meta-model of the local model can include a reference to the meta-model of the foreign model making meta-model declaration visible for the local meta-model. In the AOM context, that requires the aspect meta-model to know the base meta-model hindering the reuse of the aspect meta-model without modifications. Second, the local meta-model (e.g., an aspect meta-model) can contain in its root node or other central place a reference declaration allowing to represent a reference to another model or even a meta-model, like in MDL or Xtext. Based on that import, local nodes can refer via the import to foreign nodes without the necessity to incorporate them in the local meta-model. Third, references can be stored in strings or special classes representing references to model nodes of foreign models. These implementations are normally accompanied by a description on how to interpret the string value.

Semantics of References

More interesting than implementation details are the different applications of references between model nodes. References express either containment or associative relationships. They can be optional or required, and they can reference a single instance or reference to multiple instances. In meta-models these attributes accompany the reference declaration.

Containments can be used in different situation to express what belongs together, for example, to formulate statement sequences, an expression tree, or parameter declarations. Associations are used all other relationships. For example in programming languages, a reference from a class to a parent class expresses inheritance, and a reference from a variable to its declaration expresses read or write access to the variable. Associations are also used to express references in aspect modeling. The semantic of such references are the modification or manipulation of the referenced node or the nodes interpretation. In detail associations can have the following meaning:

Table 1: Different use-cases of associative references and their semantics.
Associative Reference Semantics
parent structure inheritance
method call, control flow
function call, control flow
variable/fields read access
variable/field assignment write access
parameter read access
parameter assignment write access or passing
rule invocation
jump label control flow
jumps control flow
aspect modification/manipulation on interpretation

Depending on the capabilities of the target meta-model, references are mapped to target meta-model structures utilizing different strategies. For example, inheritance in the source meta-model can be mapped to their target meta-model counterparts, if the target meta-model supports a similar or richer object-oriented paradigm. In other cases the semantics of the source meta-model must be realized through corresponding structural elements accompanied by runtime functions, like in GObject or the Objective-C runtime.

Method, function and rule references are supported by most general purpose languages, and are therefore, easy to map. Each reference in the source meta-model can be mapped to an equivalent target meta-model reference declaration. Variables and fields of records or other structural data types are either accessed to read a value from or write a value to them. In many target languages the write operation is expressed by an assignment, while the read operation is expressed just by a reference. Functional languages use different methods to store data, but this is of no consequence to for this article.

Parameter of functions, methods, or rules have a variable-like semantic in call by value paradigm. However, source languages can also implement a call by reference semantic. If the target language does not support call by reference, the behavior must be realized with reference or pointer operations provided by the target language.

Jump labels or ids mark a node in a source model to be the destination of a jump directive. In a DSL they are often realized with ids, which are realized with references to a model node. Depending on the target language, these references destination markers are either replaced by the unique name of a structure in a target language, e.g., a class or variable name, or they are mapped to a jump label in the target language. If jump labels are used to express loops, they can be eradicated by mapping them to a loop construct of the target language.

The remaining kind of references are references used in aspects oriented modeling (AOM). Kramer and Kienzle [2010], and Bennett et. al. [2009] discuss UML-based aspect-oriented source models and their transformation to AspectJ-based target models. The first approach describes aspects as structural and behavioral models based on class and respectively sequence or state diagrams. References are expressed as pointcuts, utilizing meta-model structures from the same meta-model as the base and advice model. A pointcut, in this context, is a generic subgraph of the base model, which can be used to match subgraphs in the base model. Each match represents a join point. The second approach extends UML class diagrams to support aspects and generate AspectJ code from these aspects. As it does not address behavior models, only stubs can be generated.

In general, aspects in AOM comprise references to base model nodes and an advice. The references are called join points and can either be explicit references in the aspect model referencing directly or indirectly nodes in the base model or they are subgraphs patterns which can be used to query the base model for matches. Then these matches can be used to determine the references. The subgraph pattern matching is used and explained in different articles [Pierre-Alain Muller et. al. 2005; Kramer and Kienzle, 2010] and tools, like Kermeta, support this identification. Therefore, the key problem is the preservation of the reference information in the target model.

Preservation of Reference Information in Target Models

As the previous section explained, aspect models can be seen as a set of advices with references (implying join points) to base model nodes. The semantics of the references are that the behavior expressed by the advice have to be executed before, after or before and after the referenced node is executed. In source models these semantics can easily be described. They are normally part of the advice. But it is complicated to ensure this in target models, as it depends on the way how the source models are mapped to the target models, and how behavior is expressed in the target meta-model. Furthermore, the it is a non-trivial task to preserve and trace the reference through the transformation.

There are different scenarios for source and target models which require different solution strategies on how the preservation and the traceability of references through transformations can be guaranteed. However, the scenarios and the solution strategies will be discussed in another article.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">