Section 26.4. DEFINING THE WEAVING KNOWLEDGE: THE DESIGNER S VIEWPOINT


26.4. DEFINING THE WEAVING KNOWLEDGE: THE DESIGNER'S VIEWPOINT

The designer (or framework documenter) has to provide both a Smartbooks representation of a particular aspect technology and mapping rules from generic aspect functionality (refer to Figure 26-4) to enable generating a weaving plan.

26.4.1. Documentation Books of Support Technology

Let us consider how to express AMF-related knowledge in terms of instantiation schemes. Figure 26-8 shows an instantiation scheme described using the TOON notation and the associated textual representation. This scheme corresponds to a proxy definition for aspect behavior in the AMF framework. The head of this scheme states that in order to have a functional proxy for a component, the proxy class should implement the FunctionalProxyIF interface and wrap the component.

Figure 26-8. Example of an instantiation scheme for the AMF.


More precisely, the diagram prescribes that four tasks should be carried out by the user:

  1. An ImplementInterface task that has to produce a subclass of FunctionalProxyIF.

  2. A DefineVariable task, which must add a myComponent attribute for the proxy class.

  3. A DefineMethod task in charge of overriding a functional method of the component (to incorporate aspect behavior).

  4. An OptionalDefineMethod task if any update to the constructor is required.

The schema description can also provide explanations about the expected behavior of methods and can specify constraints that must be followed by a code skeleton. For example, the method [Method] of ComponentProxy in Figure 26-8 should call a similar method in the wrapped class. The kind of tasks presented by the example can be seen as basic tasks or programming tasks because they refer to programming activities associated with framework code. As we have seen before, these tasks are classified as pending or waiting tasks, according to their role in the planning process.

The purpose of the Smartbooks approach is to automate, to some extent, the activities dictated by framework documentation. However, the designer arbitrarily fixes the terms used to document the framework functionality. Framework documentation, either automated or not, is usually hard to extract from designers. The method gives little assistance for this process. Good documentation is ultimately a human activity.

26.4.2. Adding Weaving Information

This phase focuses on specifying the ways crosscutting relationships and aspect design tasks should be translated into aspect programming constructs. This depends, of course, on the aspect support available in the environment. As we mentioned before, aspect interaction diagrams include special tasks, with corresponding activities that developers must carry out in order to tune specific details of the aspect-based application. These tasks, so-called design tasks, indicate how abstract weaving specifications are mapped to a particular aspect implementation (an aspect framework in our example), which has been previously documented in terms of programming tasks during the previous phase.

The code template of Figure 26-9 illustrates (partially) how the AMF implements before/after advice and conditional activation of aspects according to the design tasks given in Figure 26-3. Boldface code distinguishes those parts defined by means of programming tasks. Note that not everything can be expressed in terms of programming tasks. Some framework constraints are just documented by means of warning messages.

Figure 26-9. Mapping aspect design tasks to programming tasks of the AMF.


According to the framework design, our aspect-based implementation should basically agree with the following prescriptions:

  1. Every method with aspectual advice should be implemented as a separate class, a child of the AspectIF interface. After/before behaviors for a given method can be added by means of the precondition()and postcondition() methods, defined also by the AspectIF interface.

  2. Regarding aspect composition, a proxy object controls the access to the functionality of its wrapped document. This proxy object uses the factory pattern to create aspect objects using the create() method defined by the AspectFactory class. Aspects are created for each method of the functional component that has to be associated with aspect behavior. On creation, these aspects should be registered within the aspect moderator by calling the register() method in AspectModerator.

  3. Within the proxy, each participating method is guarded by pre-activation and post-activation phases (methods preActivation() and postActivation()in class AspectModerator). These phases are also implemented in the aspect moderator. During the former phase, the proxy intercepts requests for access to the functional components and calls the moderator to evaluate the required aspects. If the pre-activation phase returns successfully, then the proxy calls the actual participating method. Once this execution is complete, the proxy initiates the post-activation phase and again calls the moderator to evaluate the associated aspects.

Similarly, the code template in Figure 26-10 (partially) illustrates how AspectJ [13] would implement before/after advice and conditional activation of aspects according to the design tasks given in Figure 26-3. Note that the aspect definitions are slightly different from their counterparts in the AMF.

Figure 26-10. Mapping aspect design tasks to programming tasks of AspectJ.


Developers can now define several types of advice associated with different methods in the same aspect (class), without needing to split this behavior in separate classes. Advice definitions are expressed in AspectJ by means of special designators for crosscutting and pointcuts. Aspects can be instantiated like regular classes, but developers neither explicitly create aspects at runtime nor specify how they are evaluated. If some aspects need finer control over their advice parts when they run, a special modifier called dominates can be used to specify that their advice parts should be more specific than another aspect's. Additionally, conditional aspect activation can take advantage of the introduction of parts in order to permit changes in the program by adding or extending classes with new members.

These templates facilitate the work of application developers because they don't require an extensive knowledge about particular implementation mechanisms of AspectJ or the AMF. The specific details are actually hidden by high-level operations documented in the form of design tasks. From the programming perspective, this raises the abstraction level of aspects by explicitly considering aspect programming at the design phase [4].

26.4.3. Internal Representation of Aspect Requirements

As we mentioned before, the developer defines several functional requirements (planning goals) to be met by his or her application. The rules of Figure 26-11 give an idea of the kind of information provided to the Smartweaver engine as internal representation of these goals.

Figure 26-11. Internal representation of planning goals for the AMF.


Rules 1 and 2 refer to the aspect-moderator definition as a singleton. Rules 3 to 5 describe a similar pattern for the aspect-factory. Rule 6 specifies a proxy that wraps a document in order to incorporate aspectual behavior. Rules 7 to 9 correspond partially to some aspect diagram. Rules 10 to 12, in turn, may come from some aspect interaction diagram. Note that in the case of rules 10 to 12, they say nothing about how aspects should be mapped to framework classes. This enables framework designers to decide which is the best strategy to implement aspects on top of the framework. In particular, the current implementation of the AMF framework prescribes that developers should create a different aspect class for each aspectual advice. For example, the WFSynchronization aspect, which conceptually affects several document operations, should be implemented within the framework as an abstract class WFSynchronization and three subclasses, ReadWFSynchronization, CheckWFSynchronization, and WriteWFSynchronization, one subclass for each document's operation. In general, the strategies and constraints to map aspectual specifications into framework implementations may vary according to the facilities of the target framework and the developers' experience.

The AMF framework is primarily composed of abstract classes and interfaces, so it can be thought of more as a programming model than a component-based framework. This feature makes the Smartbooks method particularly useful because we can express many model constraints not completely captured by code structures as instantiation rules.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net