Section 30.3. GENERATING ASPECT CODE FROM DOMAIN-SPECIFIC MODELS

30.3. GENERATING ASPECT CODE FROM DOMAIN-SPECIFIC MODELS

The traditional approach for generating artifacts from a domain-specific model involves the construction of an interpreter, or generator, which is then used to traverse a tree-like representation of the model. The actions performed at each visited node result in the synthesis of a new representation of the model. The GME provides a rich API for extracting model information.

Often, the generated artifact is represented as source code in a programming language, such as Java, C++, or C. In such cases, the interpreter has built-in knowledge of the semantics of the domain and the programming language to which it is mapped. The interpreter may also be aware of a library, or set of components, from which the synthesized implementation instantiates. When an interpreter produces a source code artifact that relies on pre-existing libraries of components (i.e., the libraries are static and not a part of the generated artifact), it can be hard to map crosscutting properties of the model into the component. This is typically true even if the component library is available in source form (unless there is provision within the interpreter to parse and transform the component library itself during the model synthesis). The reason is that the component, during generation-time, is often treated as being closed to modificationthe granularity of the component representation is typically at the interface level, not the individual statements within the component implementation.

An aspect-oriented approach can assist in the generation of component customizations that extend the component with properties declared in the model. The focus of this section is to introduce a generation technique that relies on an aspect-oriented language to encode the extended features that are added to a component.

30.3.1. Synthesizing Aspects

It is possible to generate the configuration of Bold Stroke components from domain-specific models in such a way that specific parts of each component are weaved together as an aspect. This goal fits well with the OMG's Model Driven Architecture (MDA) [4, 12] and also the concept of "fluid" AOP, which "involves the ability to temporarily shift a program (or other software model) to a different structure to do some piece of work with it, and then shift it back" [27].

A technique for realizing this objective is the generation of AspectJ [28] code from models, as shown in Figure 30-10. In this figure, the model (top-left of figure) and modeling pointcuts (top-right of figure) are sent through a C-SAW weaver that constrains the model. Here, modeling pointcuts represent the description of crosscutting concerns that are to be woven in the model [16]. The constrained model (bottom left of figure) can then be sent to a GME interpreter/generator that generates the aspect code. This figure illustrates that two stages of weaving are performed. A higher level of weaving is done on the model itself, as illustrated by the Bold Stroke example in Section 30.2. This weaving instruments a base model with specific concerns (often represented as model constraints) that typically crosscut the model. The second type of weaving occurs from the aspect code that is synthesized and later processed by the AspectJ compiler. Thus, we achieve weaving at both the modeling level and the implementation level.

Figure 30-10. An MDA view of aspect code generation.

The amount of generated code produced from the aspect generator would actually be quite small. The assumption is that the core of the available components would already exist. Another assumption would be the existence of several different aspects of concern. These assumptions are in line with the work that other researchers are doing toward the goal of making a library of components and aspects available for a subset of the CORBA Event Service, such as the FACET work [24] at Washington University written using AspectJ. As an alternative, the AspectC++ weaver [32] could be used on the original C++ Bold Stroke components. For other languages, adaptations to a program transformation system, such as the Design Maintenance System (DMS) [3], could be integrated within the model interpreter. We have shown on a separate project how such a transformation engine can be used to perform aspect weaving at the code level [19].

An example of a core library of components can be found in the Java code in Listing 30-3. This listing represents an abstract Component (a) and a LocDisplay component (b). The abstract component defines the required methods for the domainthe same methods that can be found in models like Figure 30-6. The LocDisplay subclass, for clarity, simply provides stubs for each method implementation.

Listing 30-3 (a). Component.java (from component library)

 public abstract class Component {   public abstract void call_back();   public abstract int  get_data();   public abstract void init();   public abstract void data_retrieve();   public abstract void compute();   public abstract void notify_availability();   protected int _data; } 

Listing 30-3 b. LocDisplay.java (from component library)

 public class LocDisplay extends Component {   public void call_back() {     System.out.println("This was LocDisplay.call_back"); };   public int get_data() { return _data; };   public void init() { };   public void data_retrieve() {     System.out.println("This is LocDisplay.data_retrieve!");     UpdateMap map = new UpdateMap();     map.get_data();   };   public void compute() {     System.out.println("This is LocDisplay.compute!"); };   public void notify_availability() {    System.out.println        ("This is LocDisplay.notify_availability!"); }; 

Example aspects are coded in Listing 30-4. The Lazy aspect contains abstract pointcuts. Other aspects (e.g., various other forms of Eager/Lazy, etc.) refine the definition of the pointcuts through extension. The Lazy aspect exists in a library of reusable aspectual components. This abstract aspect captures the notion of lazy evaluation, as described earlier in Section 30.2.1.1. The callback "after" advice simply forwards all notifications to client components without making any effort to retrieve data and compute the intention of the component.

Listing 30-4 a. Lazy Aspect (from aspect library)

 abstract aspect Lazy {   abstract pointcut call_back(Component c);   abstract pointcut get_data(Component c);   after(Component c): call_back(c)   {     System.out.println("after:call_back (Lazy)!");     c.notify_availability();   }     before(Component c): get_data(c)   {     System.out.println("before:get_data (Lazy)!");     c.data_retrieve();     c.compute();   } } 

Listing 30-4 b. Concretization of Lazy Aspect with LocDisplay

 aspect LocDisplayLazy extends Lazy {   pointcut call_back(Component c) : this(c) &&                   execution(void LocDisplay.call_back(..));   pointcut get_data(Component c) : this(c) &&                   execution(int LocDisplay.get_data(..)); } 

The LocDisplayLazy aspect, shown in Listing 30-4, illustrates the type of code that is expected to be generated by the GME model interpreter. This code is straightforward to generate. In fact, to synthesize the LocDisplayLazy aspect, all that is needed is the name of the class and the type of eager/lazy evaluation to weave. These properties are readily available to the model interpreter responsible for generating the aspect code. The code generator produces the concrete pointcuts that are needed to accomplish the weaving of the lazy evaluation concern with the LocDisplay component.

To summarize the idea, it is assumed that the code shown in Listing 30-4 (a) exists in a library of reusable aspects. The model synthesis step produces code, such as that shown in Listing 30-4 (b), which represents the weaving of a particular concern as a result of model properties.