AspectJTamer: The Controlled Weaving of Independently Developed Aspects

Transcription

1 AspectJTamer: The Controlled Weaving of Independently Developed Aspects Constantin Serban Applied Research Telcordia Technologies One Telcordia Drive Piscataway, NJ USA Shmuel Tyszberowicz School of Computer Science The Academic College of Tel-Aviv Yaffo and Tel-Aviv University Tel-Aviv Israel Abstract 1. Introduction In recent years, Aspect Oriented Programming (AOP) has emerged as a promising model for modularizing large and complex programs, advancing towards wider acceptance for mainstream commercial development. The use of AOP techniques for developing commercial applications poses, however, a number of challenges especially when such applications are composed of large numbers of binary components containing independently developed aspects. The interaction of such independently developed aspects with each other and with the rest of the system can lead to unexpected problems. First, aspects in binary distributions can be mistakenly treated as ordinary classes, thus ignoring their complex interaction with the rest of the system. Second, independently developed aspects might inadvertently make inappropriate assumptions about their application environment, thus creating unintended effects. This paper presents AspectJTamer, a tool for addressing these issues. First, AspectJTamer provides support for identifying aspects that are present in binary distributions and for documenting their specific interaction points, thus making explicit both their assumptions about, and their weaving scope within, an application. Second, AspectJTamer provides a mechanism to control the weaving scope of binary aspects in a flexible manner, thus offering supplemental constraints overriding the assumptions made by independently developed aspects. This research was supported in part by a grant from the Israel Science Foundation (grant No. 1011/04). In recent years, Aspect Oriented Programming (AOP) has become an increasingly important software development method, whose goal is to improve the development and the maintenance of large applications through separation of concerns [6],[5], [3]. In AOP, a program is developed as a set of distinct, non-overlapping concerns, called aspects, Aspects are composed into a coherent application through a process called weaving, that takes place at various points of interest in the program called join points. Contributing to the success of AOP towards wide-spread commercial adoption is the popularity of the AspectJ language [2], an aspect-oriented extension of Java. Among the notable characteristics of AspectJ are its ability to produce Java-compatible classes, thus catering to a large base of Java users, and the ability of its AspectJ compiler (ajc) to weave into standard Java bytecode, thus integrating well with purely Java developed code. The ability of such aspects to be represented as Java bytecode called binary aspects, and the possibility to weave them directly into bytecode classes, represents, however, a double-edged sword in the context of large commercial applications. Commercial applications have long development lifecycles; they are composed of large number of components 1, developed over extended periods of time. These components are often developed by different teams: either within the same organization, or by different organizations as commercial-off-the-shelf (COTS) components. The system is often assembled at a later development stage, based on previously agreed (provide or use) interfaces, without explicit knowledge of the actual code or development process 1 A component, in our view, is a reusable software element, typically a collection of classes that are developed together in order to fulfill an identifiable function

2 adopted by each individual component. Components are often delivered in binary format (or bytecode), without the source code and rarely with documentation that supports little more than a description of the interfaces of interest. When AOP techniques are employed in the development of such applications, aspects can appear at multiple levels. Aspects can be used for programming individual components, reflecting component-wide concerns, or they can be used during the integration phase, in order to support application-wide concerns. The default model for constructing an application using AOP in general and AspectJ in particular is to weave all the components and their aspects together, assuming each aspect reflects an application-wide concern. Accordingly, aspects present in one component will be woven into different components throughout the system, producing new interactions at the weaving join points. The existence, the scope, and the effects of such interactions are not described by the functional API of a component; even more, they are obscured by the fact that binary aspects within a component appear to be ordinary Java classes from the point of view of the builder, or the integrator, of the application. The problem is not only the lack of information regarding the aspects that are present in an application. The presence of binary aspects in independently developed components poses additional challenges. In AOP models, and particularly in AspectJ, aspects are treated democratically and are assumed to apply equally to an entire application, regardless of the originating component. The actual classes affected by an aspect are specified at the time of writing the aspect, using a pointcut expression, describing the set of join points where the aspect should be woven into. This description, however, might reflect only partial knowledge related to the enclosing component, and might not contain information related to the rest of the system. Consequently, component-wide aspects are promoted incidentally to application-wide scope, without necessary reflecting the actual intent of the builder of the component or the intent of the application integrator. However, altering the scope of an aspect by changing its pointcut is not possible in the case of binary aspects. Alternatively, this scope can be restricted at compile, or weave-time. Nevertheless, aspect compilers or weavers offer little or no support for limiting what component, or class is woven into by a certain binary aspect. This paper addresses the above issues. For this purpose, we have developed AspectJTamer, a tool intended to aid the builders and integrators of applications based on AspectJ. First, AspectJTamer provides support for identifying aspects that are present in binary components and for documenting their specific interaction points, thus making explicit both their assumptions about, and their weaving scope within, an application. Second, AspectJTamer provides a mechanism to control the weaving scope of binary aspects on a per-class granularity, constraining what components can be woven into by an aspect especially when the pointcut of that aspect is not available for modification. The rest of the paper is structured as follows. First, in Section 2 we will present in more detail a number of specific problems that emerge when integrating components containing binary aspects. In Section 3 we will present AspectJTamer, and we will show how it can handle these situations. Section 4 will present related work, and we will conclude in Section Fault Scenarios Faults can occur whenever independently developed components containing binary aspects are integrated in a certain application. The main reasons leading to these faults are as follows: Lack of information about aspects: The presence of a binary aspect, or information about its intended pointcut is not known at integration time. This can lead to an aspect not interacting with other components as planned. Incidental expansion of scope: During the integration phase, the pointcut of a binary aspect might match unintended join points in other components. This can lead to unintentional interaction taking place. In the next section, we will introduce an example application that will serve as a basis of discussion for identifying these faults An Example: Growable Resource Repository Consider an application that contains two components: A and B. Component A is responsible for maintaining a number of resources in a growable repository that can be viewed as a resource pool. Component B requests these resources using the method getresource(description d) provided by Component A, where d represents the description of a resource. Once A provides a resource to B, the resource is no longer available in the repository. After B finishes using a resource, it returns it to the repository using the method dispose(resource r). In order to offer high availability, the method getresource(description d) is expected to always return a valid resource. Thus Component A is responsible for creating new resources when all the existing resources are in use. Figure 1 presents the implementation of this repository using Java and AspectJ. Class ResourceRepository in

3 Component A implements these methods as follows. A resources object of type HashMap is pre-populated with resources and their descriptions. Method getresource removes a resource from the HashMap and returns it to the requester. When the resource is no longer needed, it is replaced through method dispose: the resource is saved in the HashMap resources object to be served in subsequent requests. The ResourceRepository implementation does not satisfy the requirements of a growable repository: after ResourceRepository object runs out of its pre-populated resources, the method getresource returns null. The contract of the component, however, specifies that getresource always returns a valid resource. In order to overcome this situation, the aspect GrowableRepository augments the basic functionality by supplying additional resources when necessary. GrowableRepository defines a pointcut, resourceget, matching all the calls to the method getresource(description). An around advice proceeds as follows. When ResourceRepository runs out of resources and getresource returns null, the advice creates a new resource based on the given description. This resource is subsequently handed down to the requester. Figure 2 shows how Component B uses the resource repository. First, a ResourceRepository object is acquired, and a Description object is prepared. Then B calls getresource method, supplying the target description. After the resource is used, it is recycled through dispose method. Note that this implementation has been suggested by [7] and it also appears in a host of other materials. The reader is referred to the afore mentioned work for a detailed description of the reasons and the advantages of an aspect solution to the resource pooling problem; we will not discuss this further The lack of information regarding binary aspects For the application above to function properly, the GrowableRepository aspect has to be woven into Component B, such that the advice resourceget executes whenever method getresource is invoked. The weaving is performed by ajc (AspectJ compiler), provided that both components are present in the inpath argument 2. In order to have a proper integration, however, the builder of the application has to be aware that: a) Component A is developed using AspectJ technology, and b) GrowableRepository has to be woven into all the classes using the growable resource repository feature. 2 The inpath specifies the directories where both the aspects to be applied, and the classes that are to be woven into, reside. This is not self-explanatory. The binary distribution of Component A contains classes that, when examined, appear to be ordinary Java classes, i.e ResourceRepository.class and GrowableRepository.class. Moreover, if the application is integrated simply using a standard Java compiler, the application would appear to work properly, at least until the resources held in ResourceRepository are exhausted. One conclusion we draw is that, as a minimal requirement, the user of a component should be able to discern that aspects are present in binary form in that component. Knowing that GrowableRepository is an aspect is a necessary, but not a sufficient condition for correctly integrating the two components. Consider the following example. Assume that EnhancedResourceRepository is a new class in Component B. Also assume that EnhancedResourceRepository extends class ResourceRepository in order to provide additional functionality to the basic repository. The code of this class is shown in Figure 3. Method getresources is intended to obtain two different resources, atomically. It is implemented by calling twice the method getresource in its superclass (i.e. ResourceRepository). The rest of the code in Figure 3 shows how the enhanced repository is used. After weaving the GrowableRepository aspect into Component B, it is expected that the enhanced repository would return valid resources for every invocation of getresources method. But this is not the case. The pointcut resourceget defined in GrowableRepository does not capture the calls to the superclass, thus the advice is never executed (see [2] for more details). Consequently, the method getresources will return invalid resources (i.e. null) after exhausting the pre-populated set. The pitfall presented here is not limited to subclassing. The same fault would have occurred if the caller in Component B used the reflective capabilities of Java to invoke the getresource method on a ResourceRepository object. The underlying cause of this pitfall is that pointcuts in AspectJ are syntactically determined, thus, knowing informally that GrowableRepository captures calls to getresource is not sufficient. We conclude that the precise expression of the pointcut is necessary in order to determine the exact interaction between the two components. This is analogous to the practice in object-oriented programming, where it is necessary to know the exact syntax of the API provided, or required, by an ordinary Java component Incidental expansion of scope Explicitly declaring the pointcuts of an aspect helps eliminate some of the problems that appear when using a

4 public class ResourceRepository { HashMap<Description><Resource> resources =...//populate with resources public Resource getresource(description d){ return resources.remove(d); //if no resource in resources matches d then it returns null public void dispose(resource r){ resources.put(r.getdescription(), r); public aspect GrowableRepository { pointcut resourceget(description d): call(* *.getresource(description)) && args(d); Object around (Description d) : resourceget(d) { Resource r = proceed(d); if(r == null) return new Resource(d); return r; Figure 1. Component A: The Implementation of a Growable ResourceRepository ResourceRepository rep =...//obtain a reference to a ResourceRepository Description mydescription =...//provide a resource description Resource r = rep.getresource(mydescription);...//use resource rep.dispose(r); Figure 2. Component B: Typical Usage of a Growable ResourceRepository public class EnhancedResourceRepository extends ResourceRepository { public Resource[] getresources(description d1, Description d2){ Resource[] rs = {super.getresource(d1), super.getresource(d2); resources.remove(d1); resources.remove(d2); return rs; EnhancedResourceRepository rep =...//reference an EnhancedResourceRepository Description d1, d2 =...//provide resource descriptions Resource[] rs = rep.getresources(d1, d2); Figure 3. Component B: Alternate Usage of a Growable ResourceRepository

5 binary component. When integrating two binary components which are developed independently, however, additional problems might appear. Let us further assume that Component B contains a class, ResourceVerifier, that tracks all the resources that are in use at a certain moment of time. This class is used only by Component B internally, and it is not intended to interact with Component A. The code corresponding to this class is shown in Figure 4. The class saves resources that are known to be available in a HashMap object, and they are later accessed through a getresource method with the same signature as the method in the class ResourceRepository. Finally, the class provides another method, resourceinuse, that calls the local method getresource; if the resource is in the available list, then it returns true. Recall that in order for the application to work properly, it is necessary that the classes in Component B are woven into by GrowableRepository. However, due to the fact that the pointcut resourceget in GrowableRepository is unbound, i.e it has wildcard characters, it will match any method with the signature getresource(description d). Thus, the corresponding method in ResourceVerifier will be advised as well. Accordingly, this will render the method resourceinuse unusable, since it will always return true, whether the resource is present in the available list or not. The above example documents how the GrowableRepository aspect can affect other classes unintentionally, but in a harmful way. Since the pointcut of the GrowableRepository might be known in advance as part of the interaction API between the two components, one might argue that this situation could be avoided through a defensive programming style. But the problem can be shown to be even more general. Assuming that Component A contains an undocumented aspect A B, that is intendedly used for strictly internal functionality; and assuming that Component B provides joint points that incidentally match unbound pointcuts in A B ; then any integration between Component A and B using the AspectJ compiler will produce the same undesirable effects. Eliminating all the name clashes with respect to aspects present in other components, regardless of the intended public or private character of the aspect, or the methods, is not practical, especially when the two components are developed independently. Alternatively, one might propose the complete elimination of unbound pointcuts in the aspects as the source of this evil. But this again might not be possible, since such aspects rely on unbound pointcuts in order to deal with the internal complexities of components. Since modifying the pointcut of the aspect is not possible, nor practical for binary aspects, a desirable solution would be to restrict the weaving of aspects only to necessary classes. In our example, it would suffice to weave the GrowableRepository aspect into all the classes using ResourceRepository.getResource but not in ResourceVerifier class. Unfortunately, ajc, the AspectJ compiler, does not provide support for such functionality. Ajc assumes that all the aspects apply equally to an entire application, regardless of the originating component. Note that the existence of such conflicts when distributing components with woven concerns is a previously known problem. In particular, some of the above situations have been discussed in [4], and were also addressed in our own work on aspect enforcement [13]. 3. The AspectJTamer AspectJTamer is a command-line tool we have developed in order to aid the builders and integrators of applications based on AspectJ. AspectJTamer offers support for detecting aspects in binary components and documenting their specific interaction points, as well as for providing a mechanism to control the weaving scope of binary aspects on a per-class granularity. We will present below these features Detecting Aspects in Binary Components This function of AspectJTamer is nonintrusive. When starting AspectJTamer, all the components and their binary classes that are part of an application are supplied to the tool. We call this the codebase of the application. AspectJTamer inspects the codebase and presents a report to the user. The information thus presented can be subsequently used in order to avoid the pitfalls of building, and integrating the components with binary aspects. AspectJTamer provides the following specific operations. Detecting binary aspects: AspectJTamer parses all the class files in the system and uses the AspectJ introspective capabilities to determine which class encodes a binary aspect. The report is presented in the following form. Aspect GrowableRepository in file /res/users/.../compa/growablerepository.class Aspect CompBAsp in file /res/users/.../compa/compbasp.class Determining aspect details: Upon request, for every binary aspect in the system AspectJTamer analyzes its code

6 public class ResourceVerifier { HashMap<Description><Resource> available =...//hold available resources public Resource getresource(description d){ return available.get(d); public boolean resourceinuse(description d){ if(getresource(d) == null); return false; return true; Figure 4. Component B: Class using getresource method reflectively and determines the information of interest with respect to the interaction between that aspect and the rest of the system. The tool lists the pointcuts declared in the aspect; the type of advice associated with them; declared errors and warnings; intertype declarations; and declared precedence relationships. Note that the actual content or semantics of the aspect advices are not covered by this command. The report is presented as follows. Aspect GrowableRepository in file /res/users/.../compa/growablerepository.class pointcut resourceget(description d): call(* *.getresource(description)) && args(d); Object around (Description d) : resourceget(d) {; Detecting woven classes: This command detects what aspects are woven on a per-class basis, effectively determining what is the de facto scope of an aspect. This is possible because, in AspectJ, when an aspect is woven into a class, the bytecode of the class retains information related to the identity of that aspect, as a non-standard Java attribute. AspectJTamer uses the programatic interface of ajc, the AspectJ compiler, to determine what are the previously woven aspects present into the bytecode of a class. This information is necessary in order to prevent the expansion of scope within a component. Whenever a new aspect is woven into a component, the aspects already present in a limited scope in that component, might expand their scope to the entire component, similar to the case described in Section 2.3. AspectJTamer presents the following report. Class User in file /res/users/.../compb/user.class Woven with: Aspect GrowableRepository in file /res/users/.../compa/growablerepository.class Aspect CompBLogger in file /res/users/.../compb/compblogger.class Detecting Shared Join Points: Shared join points are join points in a program where multiple aspects are woven. Although not specifically addressed in this paper, shared join points can potentially cause an application to have unpredictable behavior, as pointed out in a host of recent research (see Section 4). For every class, AspectJTamer determines whether any two aspects in the codebase apply to the same join point, thus assessing the relative independence of the two aspects with respect to that class. AspectJTamer presents a report as follows. Class User in file /res/users/.../compb/user.class Shared Join Point detected: Aspect GrowableRepository in file /res/users/.../compa/growablerepository.class Aspect CompBLogger in file /res/users/.../compb/compblogger.class

7 3.2. Controlling the Weaving Scope of Aspects Given the dangers of accidental scope expansion posed by aspects with unbound pointcuts, and given that the pointcuts of binary aspects cannot be modified, a solution is to restrict the weaving of such aspects only to certain selected classes. Such weaving is designed to override the pointcut of an aspect by preventing it from expanding to unintended classes. AspectJTamer provides a mechanism to control the weaving scope of binary aspects on a per-class granularity Weaving with AspectJTamer Consider a set S of binary components with woven aspects, and consider an aspect A S. Let us assume that the desired scope of A is a subset SS of S. The function of AspectJTamer is to weave aspect A into SS without any expansion of scope. The weaving takes place according to the pointcut defined in A and it is guaranteed to satisfy the following properties: Classes in (S\SS) remain unchanged and A remains unchanged. Classes in SS are transformed as follows. Consider a class C SS, where C is either a Java class or an aspect class. Assume further that C has been previously woven into by a set of aspects W. After weaving with AspectJTamer, C will be woven into by 1) the same W, if the pointcut defined in A does not match a join point in C; or 2) by (W A), if the pointcut defined in A matches a join point in C. These properties ensure that only classes in SS are affected by the weaving, and the only transformation that takes place in SS is the weaving of A. Other aspects in S are not otherwise affected, and their scope is left unchanged. Ajc does not provide such functionality. AspectJTamer requires a configuration file, called directions file, that contains the definition of the desired scope for each aspect that is to be woven into the application. AspectJTamer requires two additional arguments: an inpath argument, representing a sequence of directories to the codebase of the application; and a destination directory where the woven classes are deposited at the end of the weaving process. AspectJTamer is launched as follows: > ajtamer -inpath <directories:> -directions <direction-file> -destination <dest-directory> We assume that this configuration file is created by the system architect, the builder, or the integrator of the application, based on the used components and based on their intended use. It is also assumed that the builder uses AspectJTamer to detect the potential conflicting aspects and their details, as described in Section 3.1. An example of configuration file containing the weaving directions is shown in Figure 5 (a). The first line specifies that aspect GrowableRepository from package compa is to be woven into the entire package compa, and into classes RepUser and ExtraAspect from package compb. The second line specifies that aspect ExtraAspect from package compb is to be woven into the entire package compb. Every entry in the directions file contains a weave declaration, followed by an aspect class and a list of target classes; wildcard characters can be used for specifying sets of target classes. The grammar used for a weave declaration is similar to the pointcut syntax of AspectJ. AspectJTamer interprets the entries in the directions file sequentially, starting with the first entry. A weave entry in the directions file will not automatically produce an actual weaving in a target class, because weaving is also subject to the AspectJ rules of the aspect pointcut. The weaving of aspect A into target C takes place if there is a corresponding entry for A and C in the directions file, and, if the entry exists, only if a pointcut defined in A matches a join point in C. Thus, it can be said that AspectJTamer overrides the scope defined by the pointcut of an aspect. Implementation-wise, AspectJTamer uses the programatic interface of ajc, the AspectJ compiler, in order to produce the woven code. Consequently, classes produced with AspectJTamer are entirely compatible with any AspectJ application. The weaving takes place iteratively: every iteration is responsible for weaving a particular aspect into a particular class. The following steps are performed during an iteration: Copy the aspect A and the target class C into a separate directory D. Identify other aspects W already woven in C and copy them into D. Using ajc, the AspectJ compiler, weave all the classes in D together. Select the modified target class and discard all other classes since they might be contaminated by aspect expansion.

8 (a) Weaving Instructions weave compa.growablerepository : compa.* & compb.repuser & compb.extraaspect; weave compb.extraaspect : compb.*; (b) Extraction Instructions unweave compa.growablerepository : compb.resourceverifier; unweave compa.compalogger : compa.*; Figure 5. AspectJTamer Directions File Extracting Aspects with AspectJTamer The inverse operation of weaving an aspect into a class is called extracting an aspect. The extraction of an aspect might be useful in certain situations. Consider the following example. Recall that Component A provides a growable resource repository functionality. In order to trace and debug its execution, Component A also contains a logging aspect, CompALogger, already woven in every class in Component A, and distributed along with the component. When the component is integrated in the application, however, a new logging scheme is decided for the entire application. Accordingly, CompALogger is not only unnecessary, but it can interfere with the new logging process by obscuring the logging output. If the source files for CompALogger are not available, as in the case of binary distributions, rebuilding the component without CompALogger aspect is not an option. In AspectJTamer, an aspect extraction is defined as follows. Consider a class C, and a set of aspects W already woven in C. After extracting aspect A W, C is left affected by W \A. That is, the extraction of an aspect from a class does not influence the scope of other aspects in the application, and only leaves class C free of A. Extractions are specified as entries in the AspectJ- Tamer directions file. Figure 5 (b) presents an example of such directions. The first line specifies that aspect GrowableRepository from package compa should be extracted from class ResourceVerifier in package compb. The second line directs AspectJTamer to extract CompALogger aspect from the entire package compa. Extraction directives use the same syntax as presented before in the case of weaving. Note that the directions file can contain any combination of weaving and extraction directives. Implementation-wise, AspectJTamer uses the standard AspectJ Compiler in order to extract the aspect. The extraction process is similar to the weaving, with the difference that an empty aspect, with no advice and accordingly no effect replaces the extracted aspect. 4. Related Work The problems caused by the integration of components with woven concerns have been previously discussed in a number of research papers. Our previous work on aspectbased enforcement [13] raises the issue of aspect interference, and points out its negative effects on security. Among the proposed solutions, we have presented a manual, separate-weaving procedure for building aspect-based applications, as well as an automated method for step-wise compilation representing the seed of our current work. This work differs from our previous work in many respects. The application domain considered in our current work is significantly different, as well as the technical solution. Novelties introduced by AspectJTamer are the generous support for identifying aspect information in a binary distribution, and support for precisely defining the scope of an aspect as well as for the extracting an aspect from a binary class. In a different work, the authors of [10] discuss in detail the problems generated by the introduction of programming aspects (also called foreign aspects ) into a system. They recognize that such introduction can change the behavior of the system in an unexpected and undesirable way, mostly by unanticipated composition. The authors, however, stop short of providing a solution. A similar problem is also addressed in [1], where the author recognizes that the separate development of code and the aspects controlling that code can lead to fragile systems, especially in the case of evolving systems. A different type of aspect interference is discussed in [11, 12], and separately in [14] and [4], respectively. The authors discuss the effects of multiple aspects weaving at shared join points. In [11, 12], the authors propose a declarative model for insuring a predictable ordering and for specifying controlling constraints. The authors in [4] propose an automatic tool for detecting interactions at shared join points and provide a conflict resolution mechanism based on a dedicated composition language. With respect to this issue, our work detects strong independence between aspects, but it does not address the actual issue of interference at shared join points.

9 Finally, in [8, 9] the authors propose an approach to AOP where aspects are viewed as program transformations. This view eliminates the composition problem allowing an incremental development using a component-based software engineering approach. Their solution, however, does not offer an implementation for AspectJ and Java. 5. Conclusions This paper addresses the pitfalls of integrating binary components with woven concerns a growing danger hindering the advance of AOP towards a wider commercial adoption. We have identified two main reasons that lead to such problems: i) a lack of information about aspects present in a component, which can take the form of either unknown aspects or unknown pointcuts in aspects; and ii) accidental expansion of scope for aspects with unbound pointcuts. Both situations can lead to unexpected and sometimes subtle errors, with possibly serious effects on the correctness of an application. In order to address these issues, we have developed a tool called AspectJTamer, intended to aid the builders and integrators of applications based on AspectJ. First, AspectJTamer provides support for identifying aspects that are present in binary components as well as for determining their declared pointcuts and the actual weaving scope. Second, AspectJTamer provides a mechanism to control the scope of binary aspects on a per-class granularity, using controlled weaving and extraction directives. Even though AspectJTamer has been developed specifically to handle binary distributions, the detection and controlled weaving method described in this paper might also prove necessary when dealing with non-binary aspects, i.e. aspect present in source form. This is the case in the context of large projects that contain multiple undocumented aspects, developed by heterogeneous teams, and where the interaction points for such aspects are not captured in a formal API description. 02: Proceedings of the 1st ACM SIGPLAN/SIGSOFT conference on Generative Programming and Component Engineering, pages , London, UK, Springer- Verlag. [5] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. Griswold. Getting started with AspectJ. Commun. ACM, 44(10):59 65, [6] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier, and J. Irwin. Aspect-Oriented Programming. In European Conference on Object-Oriented Programming vol.1241, pp , [7] R. Laddad. AspectJ in action: Practical Aspect-Oriented Programming. In ISBN , [8] R. Lopez-Herrejon and D. Batory. Improving incremental development in AspectJ by bounding quantification. In Software Engineering Properties of Languages and Aspect Technologies (SPLAT) Workshop at AOSD, Chicago, USA, March [9] R. Lopez-Herrejon, D. Batory, and C. Lengauer. A disciplined approach to aspect composition. In ACM SIGPLAN 2006 Workshop on Partial Evaluation and Program Manipulation, PEPM 06, Charleston, South Carolina, January [10] N. McEachen and R. T. Alexander. Distributing classes with woven concerns: an exploration of potential fault scenarios. In AOSD 05: Proceedings of the 4th international conference on Aspect-oriented software development, pages , New York, NY, USA, ACM Press. [11] I. Nagy, L. Bergmans, and M. Aksit. Declarative aspect composition. In Software-engineering Properties of Languages for Aspect Technologies, SPLAT 04, [12] I. Nagy, L. Bergmans, and M. Aksit. Composing aspects at shared join points. In Hirschfeld, Kowalczyk, Polze and Weske Editors, Proceedings of International Conference NetObjectDays, NODe2005, pages P 69, Erfurt, Germany, September [13] C. Serban and S. Tyszberowicz. Enforcing interaction properties in AOSD-enabled systems. ICSEA 06: Proceedings of International Conference of Software Engineering Advances, 0:8, [14] D. Stauch, K. Altisen, and F. Maraninchi. Interference of Larissa aspects. In Foundations of Aspect-Oriented Languages Workshop, FOAL 2006, References [1] J. Aldrich. Open Modules: A proposal for modular reasoning in Aspect-Oriented Programming, [2] AspectJ Team. AspectJ 1.5 Programming Guide. In index.html, [3] A. Colyer, A. Clement, R. Bodkin, and J. Hugunin. Using AspectJ for component integration in middleware. In OOP- SLA 03: Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages , New York, NY, USA, ACM Press. [4] R. Douence, P. Fradet, and M. Sudholt. A framework for the detection and resolution of aspect interactions. In GPCE