Modularity issues in aspect-oriented programming have been reported by different au- thors [94, 22, 91]. For instance, Clifton and Leavens argue that existing aspect-oriented programming languages do not contribute to comprehensibility, since they require sys- tems to be studied in their entirety. In order to improve comprehensibility of AOP systems, they propose a simple set of restrictions that minimizes this problem [22]. In their proposed approach, aspects are categorized as observers — aspects that do not change the effective specifications of the modules, or as assistants — aspects that might change the modules specifications. Observers preserve modular reasoning even in the cases that advised modules do not make explicit references to them. On the other hand, Clifton and Leavens argue that, in order to preserve modular reasoning, modules that are advised by assistants should make explicit references to them. A new construct (accept type) was proposed to indicate that a module (class or interface) accepts to be advised by an assistant aspect. This construct aim at indicating to the class developer that an
assistant aspect exists, and should be studied when some maintenance task needs to be
executed. In spite of that, it maintains the feature obliviousness with respect to the ob-
server aspects. LSD also indicates to class developer the aspects that should be studied,
through the Design Rules specification. These Design Rules contain information about aspects like inter-type declarations, pointcuts, advice and required/prohibited behavior. In doing so, LSD supports the information hiding principle, keeping the class developer away from the complete implementation of the aspect.
Other authors focus on discussing how to expose more stable aspect-oriented inter- faces and how to compute module interfaces in AO systems. Since these later works are more related to our proposal, we discuss them in more detail in the remaining of this section.
7.1.1
Open Modules
Open Modules is an approach for dealing with modularity issues in AOP [2]. Besides exposing data structures and functions, Open Modules interfaces can also expose point-
90
cuts denoting internal semantic of events. Clients of these modules are able to advise only exported pointcuts, introducing a form of encapsulating join points occurring inside a module and protecting them from external advising. Moreover, by exporting a point- cut, the module developer is compromised to maintain the semantics of that pointcut, which, in fact, mitigates the fragile pointcut problem. Although join point hiding is an important concern, it does not provide information to the aspect developer (beyond ex- ported join points and public methods), like required/prohibited inter-type declarations, method calls, attribute accesses and assignments, that are useful for decoupling classes and aspects, and consequently their developers. Differently from LSD, Open Modules does not offer any mechanisms for describing aspect developers responsibilities and the relationship between the types that participate of a collaboration. As a consequence, module developers are still able to unintentionally implement part of a concern assigned to a different team because they cannot assume the existence of any behavior expected to be modularized as an aspect.
7.1.2
Crosscuting Programming Interfaces (XPIs)
Sullivan et al. [94] presented a comparative analysis between an AO system developed following the widely cited oblivious approach and the same system developed with clear design rules that document interfaces between classes and aspects. This last approach promises benefits when relevant crosscutting behavior are anticipated and when new code, anticipated or not, can be written against existing interfaces (design rules). Its main problem is expressing the design rules in natural language, leading to sometimes verbose and ambiguous interpretation. With LSD, we can express most part of these design rules in an unambiguous language and also check if they are being respected, as discussed in Chapter 6.
In a subsequent work [43], they propose to express and check the design rules using AspectJ. They called this approach Crosscutting Programming Interfaces (XPI) (more details and examples in Chapter 6). XPIs authors argue that the main advantages of their approach is that: (a) it does not require any new construct in the AspectJ lan- guage; and (b) there is no restriction to the pointcut visibility. In fact, this characteristic encourage the use of XPIs in sites that are already using the AspectJ language. How- ever, most constraints required for defining the responsibilities of both class developers and aspect developers cannot be checked using the proposed XPI language (a deeper comparison of our approach against XPIs is presented in Chapter 6). Consequently, it is not possible to guarantee, at least automatically, if certain design rules are being obeyed, like LSD does. Although it is possible to check part of the design rules using XPIs, the use of a language not designed to this purpose leads frequently to complex specifications (contracts imposed by aspects).
7.1.3
Aspect-Aware Interfaces (AAI)
Kiczales and Mezini [53] defend that the complete interface of a module can only be determined once the complete configuration of the systems is known. They introduce the notion of aspect-aware interfaces, which describe the existing dependencies between classes and aspects, giving support to reasoning about the effect of aspects over classes
by pointing out where aspects are affecting a certain class. This interface must be automatically recomputed whenever classes or aspects change and, in fact, tools like AJDT already offer similar functionality through IDE resources that indicate which advice apply in a certain point. Also, these AAIs can be saved and compared with newer ones to detect changes to the set of join points intercepted by aspects. This approach helps to identify missing and accidental join points [88]. Although very useful for evolution, this kind of interface does not support earlier software development phases, when it is necessary to partition the system into classes and aspects, and distribute tasks among development teams. At that moment, it is necessary to establish design rules that will govern both class and aspects development. LSD serves exactly to this purpose and brings automatic checking of the developed code.