Section 18.2. ASPECTS AT IMPLEMENTATION LEVEL


18.2. ASPECTS AT IMPLEMENTATION LEVEL

The aim of this section is twofold: to describe both the benefits provided by AOP at the implementation level and the drawbacks of using AOP at the implementation level without an aspect-oriented design. For this purpose, we use a simple case study based on the behavior of a broker and its interaction with stock markets and clients. At the end of the section, the reader should conclude that, although aspect-oriented programming help programmers to avoid code tangling at the programming level, aspect-orientation should also be taken into account at the design level.

18.2.1. Motivating Example

The case study we have chosen is a simplified version of an online broker interacting with stock markets and clients. The client orders the broker to carry out operations, and the broker interacts with the stock market to buy or sell shares, depending on the client request. In this scenario, three different entities are considered: Client, Broker, and StockMarket. Figure 18-1 illustrates a simplified version of the UML class diagram for this example. Only Broker and StockMarket classes are shown.

Figure 18-1. UML class diagram for the Broker example.


The Client is only interested in buying and selling shares. For this purpose, the Broker provides the operation registerOrder with parameters (not shown in the diagram) to specify the type of the operation (buy or sell), the identification of the company, the number of shares, and an activation condition. The last parameter represents a condition under which the shares have to be bought or sold. The user chooses this condition, normally based on the situation of the market at a given time. A typical example could be "buy X shares of company Y when its value is less than Z." This is the reason why the StockMarket class provides an operation to set an alarm and the Broker class provides an operation to be informed when this alarm has been triggered so it can perform the required order. Whenever the user invokes registerOrder, the broker replicates its state for fault tolerance reasons. When the operation is completed, the state is replicated again. An ack() method is provided at the Broker side so that it can be kept informed about the details of the operation performed by the StockMarket. Distribution-related issues and others are left out for simplicity.

Figure 18-2 shows a sequence diagram for the case in which the client wants to give an order constrained by a condition.

Figure 18-2. Sequence diagram for buying shares.


From Figure 18-1 and Figure 18-2, it is easy to see the crosscutting among classes. For example, the methods setAlarm() and alarmTriggered() are only for coordination purposes. In addition, the replicate() method is only for replication issues.

The coordination property cuts across the Broker and StockMarket classes, while the replication property cuts across different instances of the Broker class. Dealing with these properties using conventional languages like Java results in spreading code through many components. In this situation, the source code becomes a tangled mess of instructions for different purposes. A direct implementation in Java or other languages would lead to a set of entities (objects, components, or others) that have the same interface shown in Figure 18-1. This solution would not only hinder reasoning about individual concerns but would also affect features such as reusability, adaptability, and the other -ilities mentioned in Section 18.1.

An AOP approach suggests separating coordination and replication issues to different entities. At the programming level, software developers may choose among different aspect-oriented programming languages and models, such as Hyper/J, AspectJ, or Composition Filters, just to cite a few.

No matter which model is chosen, the appearance of the final application is outlined in Figure 18-3. Although the figure would be the same for many AOP models, AspectJ is used here as a reference for its explanation. The figure shows an overview of the AspectJ code for the case study, merging different elements such as the interfaces of the classes, the placement of join points, and AspectJ pseudocode for those join points.

Figure 18-3. An overview of an AspectJ solution for the case study.


This code is quite different from that obtained when using traditional development techniques. First of all, the interface of the two classes involved has changed. At the top of the figure, you can see how only those methods related to the functional behavior now belong to the interface. Those methods related to coordination and replication have disappeared. That code is now encapsulated in two different entities called aspects (Replica and Alarm) (rectangles in the figure). Pseudocode of these aspects using AspectJ can be seen at the bottom of the figure. Different pointcuts are defined in each aspect. Each pointcut defines a set of places in which aspect code has to be injected. The point of execution in which the aspect code should be executed is specified by advice (before and after in this case). Circles in the figure represent the join points between the functional code and the aspect code. For example, the Apply_Replica pointcut specifies that after the execution of methods registerOrder() and ack(), the replicate() method must be executed.

Summarizing, code related to crosscutting concerns is separated from functional code. Using the mechanisms provided by AO languages, we can implement the behavior of such concerns in a single modular unit. In the case of AspectJ, the aspect programming construction is the modular unit in charge of encapsulating crosscutting concerns, and it consists of a combination of join points (grouped by the pointcut construction) and advices, besides conventional Java primitives.

This AOP implementation simplifies reasoning about the different concerns involved in the behavior of the system. It also improves reusability and adaptability of the different aspects. In summary, the evolution of the implementation is made easier. In the example, changes to the coordination or replication aspects are well localized. Moreover, and depending on the chosen AOP model, it may also be possible to make the changes without stopping the application and re-running it. In this way, things are 'easier' for the programmer.

18.2.2. AOP: Fact and Fiction

The previous example shows the benefits provided by AOP in the software development process: The different aspects intervening in the application have been separated, and therefore productivity is increased while development time and cost are decreased. As such, AOP is coping with the initial requirements of short time-to-market and software evolvability. These are the AOP facts.

Unfortunately, our experience tells us that there is another part of the story: AOP fictions. The wonderful world described previously is only an illusion. In fact, the reality is quite different. One begins to realize this when observing what has happened in the example from the point of view of software design: the designer gave a specification to the programmer, and then the programmer was forced to change the design of the application to introduce separation of crosscutting concerns. This has the following negative consequences:

  1. As the programmer has changed (part of) the design, coherence with the original overall design cannot be guaranteed. The programmer only has a partial view of the whole system. He doesn't know whether the changes he is introducing are compatible with other parts of the system or not. The problem could be even worse if other programmers are introducing changes as well. For example, the methods setAlarm() and alarmTriggered() have disappeared from the class interfaces established in Figure 18-1. Other programmers cannot rely on that design to develop their tasks simply because those methods are not available anymore.

  2. Owing to the changes introduced by the programmer, the implementation of the system does not correspond with the original design. There is a lack of coherence between implementation and design. Maintenance and evolution of the system becomes difficult. How are the aspect-related changes introduced by the programmer at the implementation level reflected in the design? Thus, the benefit of easier software evolution, one of the main claims of AOP, is reduced.

  3. Using AOP, the task of the programmer has been harder than using conventional techniques. In fact, in addition to his normal task, he has been forced to implicitly redesign the system. Thus, the benefit of improved programmer's productivity, one of the claims features of AOP, is reduced.[1]

    [1] In our experience, when programmers begin to use aspect-oriented tools, their productivity decreases significantly. This is due not only to the learning curve associated with using a new tool, but also to the cost of having to implicitly redesign the system in the adequate way. At the programming level, a programmer has to discover what different concerns he has to deal with and what concerns cut across groups of functional components in order for them to be encapsulated in the aspect entity.

  4. Using AOP, the programmer assumes responsibilities that clearly belong to the designer. This could lead to problems when things go wrong. Who is then responsible for this? The programmer or the designer? We experienced this problem when implementing a real AOP version of the case study.

All these problems are a consequence of not having appropriate design techniques. Since the designer has no design tools to specify whether crosscutting concerns must be separated, which crosscutting concerns must be separated, or how crosscutting concerns must be separated, all these responsibilities fall upon the programmer. The lesson learned must not be that AOP should be avoided. AOP complements current programming techniques such as OOP by offering a new concept/entity, the aspect, which captures crosscutting concerns in a modular way. If we want to use AOP in real software projects where several programmers are involved, aspect-oriented design techniques must be provided.

The next section outlines the two different but complementary approaches we have followed for aspect-oriented design.



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