Preservation and Traceability of References in Transformations

The development of software systems involve many different stakeholder and domains, each introducing their own requirements. Furthermore, these systems have to interact with other external services. This results in complex software projects. One method to address this complexity is the separation of concerns and the use of models for these concern. In recent years, domain-specific languages (DSL) have become the source to describe these models.

DSLs in modern software projects are used to describe the application domain and in addition other crosscutting concerns, such as persistence, monitoring, or security. While DSLs for specific application domains might be used only in a small set of projects, the additional mentioned concerns exist across different projects, and the languages are, therefore, used in different projects.

Beneath DSLs, code generators transform source models into target models or code. These generators must incorporate models based on different DSLs to realize the combination of the different aspects. This combination can either be realized by weaving the aspect into the base model or by a reference on the target model level. In my previous post, I discussed different reference types and their function in models including references between aspect models, describing a cross-cutting concern and base models. In this post, I describe five basic scenarios for mapping references to target model structures and motivate different solution strategies for them, which will be discussed in future posts.

Mapping Scenarios for Base and Aspect Model to Target Models

Roughly there are five preservation scenarios for join point references from aspect to base models (see Figure 1). First, a base and aspect model are compiled together in one target model.  Second, a separate target model is generated for the aspect and the base model, utilizing the same target meta-model. Third, like before, but the reference direction is inverted. Fourth, the target base and aspect models use different meta-models, for example Java and AspectJ. And fifth, like before, but the direction of the reference is inverted.

Five different code generation scenarios.
Figure 1: Five different code generation scenarios.

However, the second and third scenario are just special cases of scenario four and five, respectively. Therefore, only three scenarios are described in the remainder of this post.

Joined Target Model

In development domains, where aspect-oriented programming (AOP) is not available in the general purpose language environment or not applicable due to environment restrictions, the code of aspect models must be woven into the code for the base models resulting in joined target models. Typical languages for joined target models are languages, like C, Fortran, Perl, PHP or Cobol, and project which are based on these languages.

A minimalistic scenario for joined target models comprise one base model and one aspect model with different meta-models and transformations to generate target models. The base model transformation must be able to generate a complete self-contained target model, while the aspect model transformation must generate target model fragments. Complete self-contained target models generated from the aspect model would hinder the integration of the aspect and are not covered by this scenario. All target models and target model fragments are based on the same meta-model supporting a later weaving step.

Separate Target Models and Meta Models

Some languages and language environments provide aspect oriented programming (AOP) in different realizations (see Aspect-Oriented Software Development). Most of these AOP approaches, aspects advices are implemented in either an special aspect language or in the same target language used for the source base model. The pointcuts or join points are defined in an additional notation expressing the references from the aspect advice to a target base model node.

To generate such join point references the source and the destination of the references must resemble the source model references. The reference source can be handled by the aspect generator during the generation of the advice model. However, the destination is determined by the base model generator.

Inverted References on the Target Level

In some situations the references from the aspect model referencing the base model are inverted in direction on target level. For example, in an Java and AspectJ context, instead of using pointcuts collected in a separate file, Java classes are annotated with weaving information. In this context, the target base model must be modified by aspect references. Therefore, the aspect pointcut or join point information must be available to the base model transformation.

Summary

All three approaches require information from both models in a least one of the two involved generators. This additional information which must be provided by the other generator during code generation or at a second model iteration after the initial transformation. While the three scenarios have similarities, they have to be discussed in more detail in following posts.

Leave a Reply

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