Section 26.3. APPLYING SMARTWEAVER: THE DEVELOPER S VIEWPOINT

26.3. APPLYING SMARTWEAVER: THE DEVELOPER'S VIEWPOINT

Getting smart guidance for a given application requires two primary activities. First, the developer (or final user) has to specify the design of the target application in terms of UML diagrams extended with some aspect characteristics. After that, the developers interact with the functionality wizard providing additional requirement details. The tool can then suggest a series of programming tasks produce the desired aspect-incorporating functionality.

26.3.1. Design of the Target Application

Developers should use the documentation tool to define the design of the core workflow components, as well as the crosscutting properties affecting components' functionality. In the line of [5, 19], we have extended conventional UML models to support AOSD features by including additional stereotypes and relationships. Aspects can be seen as special classes defining attributes and operations and incorporating advice operations. Figure 26-3 shows a class diagram with some of the classes involved in the workflow application and its associated aspects.

Figure 26-3. Aspect diagram for the workflow application.

For example, Figure 26-3 defines concurrency advice for the WFDocument class and also exposes the conditional activation of the WFLogging aspect as a result of evaluating the WFAuthorization aspect. These descriptions may be complemented with more detailed views documenting aspect behavior. Note that in order to specify which aspects crosscut the workflow application, the developers have to previously sketch out the main workflow classes. In the general case, developers can incrementally specify portions of aspect diagrams and define particular properties regarding before/after crosscutting, aspect priorities, or conditional activation, among others. These specifications are based on a new kind of task, more abstract than a programming task, called a design task.

26.3.2. Interaction with the Task Manager

Once aspect models have been defined using the Documentation Tool, it is possible to translate them to schemes expressing a portion of the functionality required by the final application. For example, when running the Hint's Functionality Collector, the Functionality Collector begins by presenting the user with the initially available functionality, based on the instantiation knowledge previously provided by the designer (in this case, knowledge of the AMF framework). At first, only high-level functionality is presented to the user. As some items are selected, other options including further information may be displayed so the designer can refine previous selections. Figure 26-4 shows a sample of general functionality items relevant to any aspect-oriented development.

Figure 26-4. Functionality items suggested by the Hint's Functionality Collector.

On the basis of the functionality requirements collected by Hint, the tool internally generates a set of goals to express these requirements. The engine responds with an implementation plan in accord with these requirements. This plan is presented to the user by the Task Manager, and it includes a set of waiting tasks (representing the developer's design decisions) and a set of pending tasks (representing instantiation actions).

To exemplify this guidance, let us consider some of the activities derived from the definition of a new aspect. In the AMF framework, this functionality requires the definition of an AspectFactory class. The planner asks the user for a name for this class. If the class already exists, the planner may initially check for a subclassing relationship. It then presents a task for selecting which methods are to be overwritten. In addition, a task for creating the target subclass may be generated during the checking process. Figures 26-5 and 26-6 depict a possible list of tasks (shown from the Task Manager) for the instantiation of our workflow application.

Figure 26-5. A class-refinement task proposed by the Task Manager.

Figure 26-6. A class-creation task and a method-creation task proposed by the Task Manager.

Finally, the application is shaped through several interactions with the user, either with the diagram editor or the Task Manager. The execution of the tasks suggested by the Smartweaver engine can optionally generate code skeletons, which the user can later fill in with more specific implementation details.

To validate the feasibility of this approach, we compared our (assisted) design for the workflow application against the one presented in [7]. Although results are still preliminary, we found a reasonable match between them. The final instantiation of the AMF framework for our workflow application is shown in Figure 26-7.

Figure 26-7. Sketch of the workflow application (gray boxes correspond to AMF classes).