Reference Representation in Joined Target Models

The previous post discussed three different scenarios for reference representation in target models generated out of one base and one aspect model. The first scenario addresses the weaving of target aspect model fragments into an target base model, calling that a joined target model.

In this article, the prerequisites for creation of a joined target model and the weaving process are explained. The goal is to define APIs and artifact classes required to implement this approach, which can then be tested subsequently.

The article provides first a scenario description with the involved models and transformation. Second, target meta-model characteristics are discussed. Third, the weaving approach is introduced. The weaving process induces some requirements, especially the determination of the insertion point, which are explained in the fourth section. Finally, a summary comprises all relevant information to be able to develop this weaving approach.

Scenario

The scenario involves one source base model (SBM) and one source aspect model (SAM) with different meta-models, called source base meta-model (SBMM) and source aspect meta-model (SAMM). The SBM and SAM are transformed in target base models (TBM) and target aspect models (TAM), respectively, by two code generators TBM: SBMM -> TMM* and TAM: SAMM -> TMMfragments*. The target models are then combined by a weaving process. To be able to weave the aspect model, the TAM must return weavable TM fragments forming subgraphs of a valid target model. The TBM must produce self-contained target models.

Target Meta-Model Characteristics

Target meta-models can be quite diverse in the way they represent language features, and the different languages features required by the languages. First, languages may model behavior with imperative statement sequences, such as C or Java, or use functions, like Lisp or Clojure. Second, sequences can be represented by arrays, lists, or trees.

Statement sequences form together with control structures directed graphs with one entry and many exit points. To add code to such a statement structure, the begin and end of the sequence or graph must be determined. Sometimes the end of a sequence or a branch of the graph is marked by a return statement, which then must be rewritten to add code after the value of the return statement is computed. The detection of entry and exit points highly depend on the way these graphs are realized. Figure 1, shows three typical representations of statement sequences, as they occur in Xtext-based languages.

data-structures-to-represent-statement-sequences

Figure 1: Different realizations of statement sequences in meta-models, especially in the context of Xtext, which often results in list or tree structures.

In functional programming languages, the abstract syntax tree (AST) is much simpler. The insertion is done by adding an aspect function which takes the annotated function as its parameter resulting in one additional node in the AST for the aspect function having one child, the annotated function. In total functional languages form trees similar to the tree in Figure 1.

In order to preserve the behavior of the base model, the aspect function must be able to handle the return value of the annotated function and return the value unchanged to the outer function.

Weaving of Target Models

The weaving process incorporates target aspect model fragments in the target base model. Model weaving has been addressed in different publications and requires a way to identify subgraphs in the target base model which reflect the insertion point and alter or move nodes to integrate the aspect model fragment. After the identification, the alteration and movement must be controlled by a composition specification. The inserted model fragments must structural compatible to the insertion point, otherwise the resulting target model would no longer conform to its meta-model.

The specification to drive the aspect weaving is called a weaving template, which comprises a target base model pattern to identify insertion points, a composition specification, and the relation to a source base model reference.

The target base model pattern solely depend on the target meta-model. In imperative languages or languages with imperative features it might be designed to identify procedures or methods, and subsequently find the begin and end of the statement graphs in the methods’ bodies.

The composition specification describes an insertion mechanism for target aspect model fragments. It specifies the type and configuration of the root node of such fragments. Furthermore, it rewrites the target base model graph and inserts the aspect into the base model.

In imperative languages, statement graphs may end with a return statement, which itself my contain a complex expression. To ensure the execution of the aspect after these expressions, the composition specification must rewrite the return statement, by introducing a variable carrying the result of the return statement, followed by a call of the aspect model, and finally a return statement with the previous variable.

When inserting model fragments, it is important, that the identifier names differ between the base and the aspect models. Under the assumption that the aspect code generator is written independent of the base code generator, the guarantee that names are different cannot be implemented in the different code generator without some considerations. In languages providing package support, aspects can be encapsulated in packages which differ from base model packages, similar to Java frameworks which have their own namespace. While this is suffice for aspect model fragments, it is not for the rewriting of the return statement. The variable can always clash with generated or user defined variables in the target base model.

A solution to this issue can be a special method in Java, which has one parameter for the return statement expression and is inserted as outer function in the return statement. For example, return value*4; is transformed to return Aspect.specialFunctionName(value*4);

Other languages, like C, might not provide namespaces or packages, which hinders the realization of the weaving in the proposed way. However, developers require such distinction mechanism, which they then emulate with rules how names must be specified. Based on these rules code models can be created with the above approach.

Determination of the Insertion Point

The insertion point of the target aspect model fragment into the target base model must be determined prior to the weaving. The insertion point is determined by the reference’s destination of the join point specified in the source aspect model, either by a direct reference or a pointcut, or in a separate aspect join point model.

The references on the source model level between aspect and base model must be represented on the target model level. For the reference source, this is a trivial issue, as the code generator for the aspect model realizes the creation of the target model nodes representing the source model node owning the reference source. The reference destination, however, cannot be computed by the aspect code generator, as the representation of the source base model node in the target model is determined by the base code generator. Therefore, it is unknown to the aspect code generator and might only be determinable after the base code generator completed its work.

A solution to this problem must therefore resolve the references destination in the target model and subsequently create of fix the realization of the reference. This can be realized through collected node creation traces during the base model code generation. The traces express which target model node was created by interpreting a source model node.

As result traces from one target model node to different source model nodes and from multiple target model nodes to one source model node can occur. However, in code generation contexts for DSLs, the source model is more concise than the target model, therefore, it can be assumed that one target model node has only one source model node. But one source model node might have multiple target model nodes (see Fig. 2).

trace-references

Figure 2: References expressing the creation relationship between source and target model node.

Therefore, a selection of the correct target model node based only on the source model node is not possible without additional information. The information can be derived from two sources the target model structure and specialized selection pattern, which are similar to the pattern used to find join points in other AOM approaches [Kienzle 2009, Whittle 2009].

First, all target model nodes having a common source model node form a collection of nodes belonging to a self-contained model, which is in fact a directed graph according to the containment graph. Especially, models based on DSLs resemble a tree like structure similar to an AST. The goal is to identify the root nodes of the subgraphs created from the the source model node. This can be done by calculating the distance between each node and the global root node. While tracing node distances, the algorithm can come across another node of the collection, which is then considered a parent node and the child node is then not relevant to define the top node for the weaving template.

The weaving template comprises of a subgraph pattern which matches the found target base model and which describes the transformation of the base model and the insertion of the aspect model. For example, in an imperative language, the referenced root node is a method definition and the insertion point is in the enclosed statement sequence.

Second, the root node might no be the right insertion point and the deviation cannot be described in the weaving template. Then a specialized selection pattern, including model queries can be used. This is also required to limit the number of found root nodes, if for instance a large set of methods is found in the target model. However, most of them are not relevant in context of the creation. The selection pattern, therefore, depends not only on the target meta-model, but also on the base model code generator.

Summary

In this article, I have shown how in general the weaving process of an target aspect model into a target base model originating in different source models can be achieved and what the obstacles are when joined target models are generated.

The important building blocks of the approach are traces representing information of the origin of target model nodes, insertion point detection pattern, and composition specification governing the weaving process.

The next step for this weaving scenario is the evaluation in a simple example requiring an aspect and a base language, suitable generators and example models for the involved languages. The use case for the evaluation is a smartphone app development project where the app code must include monitoring probes. As languages a simple language for smartphone apps (LAD) and an instrumentation language from the Kieker project will be used. The target language will be Java. Java already has an aspect language called AspectJ and therefore weaving Java code in my own method looks like a pointless endeavor, it has two advantages to use Java.

First, a meta-model for Java is already available reducing the effort to build the evaluation scenario. Second, the other two model reference representation methods mentioned in the previous article can then be evaluated with the same source models increasing comparability of the different approaches.