Odysseas Papapetrou and George A. Papadopoulos

Transcription

1 From Components to Services: Evolutions and Trends in CBSE World Scientific, 2005 CHAPTER X ENHANCING COMPONENT-BASED SOFTWARE DEVELOPMENT WITH ASPECT ORIENTED PROGRAMMING Odysseas Papapetrou and George A. Papadopoulos Department of Computer Science, University of Cyprus {cspapap,george@cs.ucy.ac.cy The purpose of this paper is to assess the advantages and disadvantages of a state of the art programming paradigm, called Aspect Oriented Programming (AOP for short) for building component-based systems. For the purposes of this comparison, several other approaches based on the AOP methodology will be examined, in matters of efficiency, ease of programming, robustness, and other important metrics. We also develop two case studies and report on our experiences. KEYWORDS: Component-Based Software Development, Aspect-Oriented Programming, Aspect-Oriented Software Development. 1. Introduction Over the past thirty years the field of Computer Science has evolved considerably. However, although this evolution has covered both hardware and software, major problems with the latter still remain unsolved or unsatisfactorily solved. After all, the computer crisis of the late decade was not on hardware, but on software. The demand for software quality continues to rise to levels higher than what the market can provide. Therefore, several methodologies were developed for faster software development, including Computer Aided Software Engineering (CASE) tools to help modelling the system and code generators that can create a big percentage of the code fast, and at the same time allow the developer to modify and enhance the generated code. Components were also introduced as an answer to the software crisis. Component-based software was developed by adopting and combining a number of different components (sometimes third party components). Components were combined with various techniques and in different granularities, ranging from limited component use through standard software (e.g. Microsoft ActiveX), to completely component-based software running over middleware platforms (such as CORBA). Having the same motivation for faster software development, Aspect Oriented Programming (AOP) was recently proposed. Kiczales and others 23 suggested a programming paradigm that would not only enable faster development, but also help in preserving some quality aspects of the implementation. More specifically, AOP attempts to promote some of the crosscutting concerns (that is, concerns that were all over the software e.g. the logging requirement) as first-class citizens, targeting at better software modularity and more code reusability. These concerns were called aspects, and they were autonomous entities that, theoretically at least, could get plugged into different systems with different business logic, 1

2 Enhancing Component-Based Software Development with Aspect Oriented Programming and fulfil some of those systems requirements. Initially, AOP aimed to capture only nonbusiness-logic, non-functional concerns i.e. execution speed or logging. Quoting Kiczales in his initial proposal: Aspects tend not to be units of the system s functional decomposition, but rather to be properties that affect the performance or semantics of the components in a systemic way. However, the notion of aspects is nowadays extended to cover any functionality that crosscuts the whole system, even for the implementation of functional, system-specific requirements. This short introduction is followed by a more detailed description on AOP, including work on AOP modelling (Aspect Oriented Software Design) and code generation. In section 3 we describe some of the initiatives in using AOP for component-based systems, and the main motivations behind these attempts. We continue with a comparison of AOP with other programming paradigms (namely the OOP and the coordination paradigm) in order to demonstrate the advantages of AOP compared to other models with which AOP shares some common aims. We then present some interesting related work on Aspect Oriented Programming and report on the limitations and problems identified in our survey. Finally, we present our conclusions and expectations for the near future. 2. Description of Aspect Oriented Programming Aspect Oriented Programming suggests the distinction of the crosscutting concerns from a system, and the promotion of them to autonomous entities, called aspects. Aspect Oriented Programming can occur in two levels of the software engineering process: (a) in the implementation level, enabling easier implementation of the crosscutting concerns, and (b) in the design level, enabling not only better documentation of the crosscutting concerns, but also code generation and CASE-tools support. We will now introduce the basic principles of the Aspect Oriented Programming paradigm and see the reasoning and advantages of the new approach. We will also look how the paradigm can enhance the complete software-engineering cycle, in the design phase and with code generation. 2.1 Principles of Aspect Oriented Programming Aspect Oriented Programming, as proposed by Kiczales, is based on the concept of aspectual decomposition. Functional decomposition, introduced from earliest programming models such as the procedure oriented and the object-oriented model, try to break the system into smaller constructs, called functions, procedures, or objects. The constructs experience high cohesion and have a special well defined functionality. Aspectual decomposition is somewhat complementary to functional decomposition, and tries to overcome the limitation of functional decomposition in capturing and representing crosscutting functionality. After separating the system to functional constructs, aspectual decomposition is applied to the design in order to catch the crosscutting concerns. Crosscutting functionality usually includes extra-functional requirements (e.g. timing constraints or logging facility to all the system components). This functionality is usually replicated a number of times, spread over the whole system. There is no single point of reference where the developer could claim that the aspectual functionality belongs to and where it should be implemented. 2

3 Odysseas Papapetrou and George A. Papadopoulos Up to now, aspectual functionality was implemented in a not so elegant and not so efficient manner in traditional programming paradigms. Either implemented as procedure, or as method of an object, even through inheritance in OOP, the user should manually invoke the code every time the functionality was required. Furthermore, changes in the code were not trivial. There was a high risk of regression faults, since the methods were invoked from many places in the code. Moreover, since the crosscutting code was not a single autonomous construct, there was no way of representing it in modelling (through either ADL or the more powerful UML), thus prohibiting efficient code generation. Aspect Oriented Programming, by distinguishing the crosscutting code, and promoting it to a first-class citizen as a stand-alone entity in the software design and implementation, solves the pre-mentioned problems. First of all, it easily represents crosscutting code in modelling, thus, allowing a more complete model and a more powerful code generation. Furthermore, from modelling to implementation, the crosscutting concerns can be easily reused in various points as necessary (in the most extreme approach, the concerns can be reused even through different projects). Changes in the crosscutting code are trivial and not error-prone. And finally, the most important part of the AOP model is that it allows automatic invocation of the aspect code according to some rules, e.g. the logging aspect can be called each time any method of an object is called. Most of the aspect languages share the same primitives: the join-points (well defined points in program s execution, the pointcuts (a collection of join-points), and finally, the advice (the code to be executed). A less common construct, but also important, is inter-type declaration (formerly called Introduction), which introduces variables and/or code in the actual program. To make things clearer, we now present a short example of a logging aspect (logging every invocation of every method in objects myobject and myobject2). While for illustration purposes we use AspectJ (from Xerox) with Java, most of the other AOP implementations share the same principles and very similar primitives. // the complete aspect definition public aspect logging_aspect { // the joinpoints define the distinct places where the aspect // functionality should be invoked joinpoint myobjectmethodcalled: call(void myobject.*( )); joinpoint myobject2methodcalled: call(void myobject2.*( )); // the pointcut defines a collection of joinpoints pointcut log(): myobjectmethodcalled myobject2methodcalled; // alternatively, we could avoid defining the joinpoints, and define the // pointcut here as follows: // pointcut log(): call(void myobject.*( )) call(void myobject2.*( )); // this is the before advice (what to do before the joinpoint is executed) before():log() { System.err.println( Entering : + thisjoinpoint); // this is the after advice (what to do after the joinpoint is executed) after():log() { 3

4 Enhancing Component-Based Software Development with Aspect Oriented Programming System.err.println( Exiting : + thisjoinpoint); // this is introducing a variable in the actual myobject and MyObject2 // code this variable is actually never used in our example, just added public boolean (myobjectmethodcalled myobject2methodcalled).tmpvar = false; High-level goals of AOP: As already demonstrated, the purpose of Aspect Oriented Programming was to capture the crosscutting concerns throughout the system, and promote them as first-class citizens, in order to enable modelling and reusing them. The high level goals of such an approach, as reported in various publications, are listed below: (i) AOP makes programming easier and faster, closer to the human perception 23,26,36. Developers understand the concept of crosscutting concerns and crosscutting functionality, and they use it in understanding the whole system. Most of the time, they describe this functionality with non-formal expressions similar to the following one: every time a method from this object is called or every time the user tries to change the value of this variable. However, up to now there was no easy way to implement such a crosscutting concern. Nowadays, aspects are closer to the human perception for crosscutting concerns and simplify the design and implementation of systems with such requirements. Aspects can even allow code reuse for the extra-functional requirements they implement. Thus, they can make system implementation easier and faster. (ii) AOP makes programming less error-prone and easier to debug and maintain 23, 26, 36. As shown by previous researchers 35, successful software solutions spend an average of 67% of the complete cost for maintenance. Furthermore, rapid software design and development enforces important changes in software requirements, sometimes even before the final deployment. Thus, it is really important to keep programming as modular and as easy for reuse and maintenance as possible. Furthermore, special attention should be paid for easy debugging of newly introduced code and regression fault avoidance. These targets are fully met from Aspect Oriented Programming. Not only the code becomes more modular, thus easier to maintain and enhance, but also the goal for debugging is more easily gained (offered from the AOP ability of automatic aspect invocation). (iii) AOP can be used for more modular software and less tangling code 1, 23, 26, 36. Well constructed software not only allows easy code reuse but also assists during the development phase. The developer constructs small, independent parts of the application each time, and later combines them to a full running system, thus making the development of the complete system easier. Parallel developing is also feasible. However, this is not the case in modern systems, where several parts of code implementing crosscutting requirements must be reused in the system, e.g. the authorization code must be reused in the system a number of times. Modern programming paradigms do not offer an elegant solution to that, since the crosscutting code cannot be seen as a first-class citizen, an autonomous entity. AOP not only suggests a solution to easily develop and invoke this code, but also, to some extend, offers modelling abilities (with Aspect Oriented Modelling) so that the design is more complete. (iv) AOP can be used to make software quality-aware 34. One of the most difficult problems in software development is quality-aware software. Software that has functions that conform to some quality requirements is hard to develop. Even harder is the case of real time software, or a quality-aware distributed system. While AOP does not claim to have the 4

5 Odysseas Papapetrou and George A. Papadopoulos ability to speed up programming at runtime (the AOP model rather slows down the execution), it is the perfect solution for the quality monitoring problem. AOP can be used for easy monitoring in every quality-related function, e.g. to monitor the execution time of a function. 2.2 Aspect Oriented Modelling While the initial proposal for AOP existed only at the programming level, soon AOP was integrated into the software engineering process, producing its own software engineering techniques. The process of Aspect Oriented Software Development now includes a number of CASE tools, several modelling techniques and other aids. More specifically, the current approaches in Aspect Oriented Programming are the following ones: (i) AOP can exist only in implementation (pure AOP). Modelling is done in the traditional way, without AOP awareness, either in standard UML or in another ADL. AOP related functionality (e.g. the extra-functional requirements) is either not represented in the UML model or is represented as a traditional construct (class) or as note in the UML. The developer then decides, during the implementation phase, which of the functionality can be considered aspectual and is to be passed in aspects. This approach is generally useful for debugging functionality or trivial, small applications. Using AOP in large projects without Aspect Oriented Design is non-trivial, and generally not recommended. However, up to now, this is the most dominant approach in the field, since there is little work published in Aspect Oriented Modelling. (ii) In a complete and more powerful solution, AOP is applied to both modelling and implementation. Proper extensions to UML (or other Architecture Description Languages) are introduced in order to capture the meaning of aspects. The system is designed in an aspect-aware approach, and all the aspectual functionality is introduced in the model as aspects. Aspects are somewhat plugged in the model usually with simple aspect-like rules. Aspect Oriented Modelling can even be introduced in a CASE tool for a more powerful solution. Various aspects can easily be stored in libraries, recalled and introduced into the system during the modelling stage. The aspect code can also be stored so that it can be retrieved in the future. Moreover, following the trends from the.net environment where multiple languages can collaborate with each other, aspects can be implemented to work in a number of languages and stored in libraries, ready for reuse. In important aspects, such as security, this would also mean the ability to buy and use aspect code from experts. Much work is published regarding the need and advantages of software modelling with an architecture description language in the early stages of the software life cycle. The target is usually better, more modular, and easier to construct and maintain software. Hohmann 19 considers a number of advantages in modelling software architectures, including longevity and stability of the software, favour for future changes and maintenance and profitability. Bass et al. 6 also stress the need for software modelling as a common language for unambiguous representation of the system details. Several others also stress the importance of software modelling as a means of dealing with complexity and a basis for decision making. Efficient software modelling however generates the need for powerful modelling languages. The need for unambiguous and complete modelling languages emerged from the early years of computer evolution, and several steps were made toward that. Especially in the mid 90 s, there were several achievements in the field, with the introduction of UML 1.0 (replacing the prior version of 0.9) and several ADLs (Architecture Description Languages). Common in all 5

6 Enhancing Component-Based Software Development with Aspect Oriented Programming the approaches were the goals of unambiguity, completeness in representation, and, finally, ease of use. Several ADL proposals satisfied these needs with a basic well defined core of constructs and ability to extend the language using these constructs. Other ADL designers preferred the method of a strict, yet easy to extend language, which was trying to predict and adjust in most of the programming paradigms, in as much detail as possible, combining various types of diagrams. Since the aspect oriented paradigm initially started as a programming paradigm without modelling support, there is currently a lack of common practices for representing aspects at the design level. However, modelling of aspects would have many advantages for software development, such as: (i) Help to create more complete system architecture. Since aspects are represented in code as autonomous entities, a representation of aspects at the modelling level would mean a more complete software model. Efficient modelling of aspects will enhance the original model with the information about the aspect separation (which are the aspects) and the aspect invocation (which processes or methods of which components can invoke the aspects). This information is currently missing from the standard UML modelling, thus, cannot be processed for code generation or for any other reason. (ii) Pure separation of concerns at the design level. In the absence of aspects at the design level, the aspect functionality could be encapsulated in the component s code, and perhaps documented as note in the UML diagrams. However, such an approach would not be efficient enough to represent the separation of concerns, which is how the aspect code can be detached from the component code and reused in different components. (iii) Code generation. Learning and applying the AOP paradigm in the object-oriented model does not demand much learning time. However, even the limited increased complexity of the new model could be overcome with code generation. Furthermore, as expected, code generation based in a more complete, aspect-aware model will create a more complete code, easier to extend and complete. Code generation based on an aspect-aware UML set would not only create the basic constructs of classes and components, but also of aspects, and perhaps, even succeed in binding the aspects with the components (joinpoints and pointcuts). Following best practices from the traditional software engineering field, there were several attempts to model Aspect Oriented software with different versions and extensions of traditional UML languages. Some of the most promising innovations were 8, 9, 20, 21, 31. However, before studying some of them, we should stress that none of them is standardized yet at the software engineering community, and that there are many others, some being more accepted than others Aspect Oriented Design with UML There exist several accepted approaches of enhancing UML with aspect notations. We will now report briefly on some of them and comment on the advantages of this approach against standard UML. Theme/UML 8, 10 was originally developed to support new decomposition capabilities in UML models. Quoted from the creator s description in 13, the new decomposition capabilities support a way of directly aligning design models with individual requirements. Each model contains its own theme, or design of an individual requirement, with concepts from the 6

7 Odysseas Papapetrou and George A. Papadopoulos domain (which may appear in multiple requirements) designed from the perspective of that requirement. Standard UML is used to design the models decomposed in this way. Realizing the inefficiency of the current modelling languages (even UML at its full extent) to represent crosscutting requirements, the creators suggested the promotion of concerns to firstclass citizens. Such a convention would not only enable representation of these concerns as separate entities, thus making implementation and maintenance easier, but would also favour the reusability aspect of the concerns, enabling reusing the code with minor changes to different solutions. Respecting standard UML, Theme/UML supports the crosscutting concerns as separated, encapsulated design models. These models are then composed based on the composition relationship, to complete the design. The composition pattern used for the composition of these sub-models to the complete system model is based on an extension of the UML s templates 17, with the main difference that it allows multiple bindings (UML templates allow only a single class to be bound to a parameter). More formally, all the basic aspect oriented constructs (based on AspectJ) can be easily represented in Theme/UML under the following guidelines 8 : Aspects: Aspects can be formally represented as composition pattern subjects, which are very similar to the standard UML templates. Joinpoints: Joinpoints are represented as operation template parameters in the design level. Pointcuts: Pointcuts in AspectJ are a set of joinpoints. Joinpoints can be represented as operation template parameters. Then, since templates can be replaced by actual operations multiple times (due to the extension in Theme/UML), they can actually include a set of joinpoints, which is equivalent to AspectJ s pointcuts. Advice: Advices can be represented at the standard interaction diagrams from the UML. The designer can easily represent the before, after and around AspectJ constructs with a UML interaction diagram. Introduction: It is trivial to represent introductions (in the latest AspectJ version replaced from inter-type declarations) to Theme/UML. Design elements (e.g. classes and attributes) that are not template elements may be defined within the composition patterns. This is equivalent to AspectJ s inter-type declarations. An important aspect of Theme/UML is that due to the clean representation of AspectJ s constructs, it is very promising for code generation. Mapping from UML interaction diagrams and class diagrams to code seems feasible to a great extent. The complete methodology for mapping Theme/UML to AspectJ is presented in more detail in a later work of Clarke and Walker 9. Other researchers have also realized the need to design support for AOP programs. For example, Pawlak and others 31, while admitting that AOP has been in favour for more modular code and has helped a lot for faster software development, they do stress the need for support from the design level. This is why in the same work the writers describe another approach for modelling AOP constructs with UML. More specifically, the following constructs are added in UML to represent the AOP constructs: Groups: Groups try to encapsulate the meaning of the aspect invocation in AOP. As in AOP each aspect is bound to several objects (or even better, a group of objects), the same concept must exist in the design level. However, since the object may not share a common class or even inherit from the same class, the objects need to be grouped in a 7

8 Enhancing Component-Based Software Development with Aspect Oriented Programming different manner at the design level. For this reason, the writers introduce the Group construct, which can be used to represent the otherwise unclear relations between objects, yet necessary, for the required abstraction in the modelling of AOP-based systems. Groups can be used to capture two kinds of relations: (a) groups of objects that are not necessarily instances of the same class but need to be considered as groups, e.g. in the case of a system with a subset of real time components, these components may be grouped in order to be distinguished from the components that do not need real time functionality; and (b) groups of members that are localized on different hosts or containers in a distributed application. Aspect classes: Aspect classes are a special kind of regular classes that can contain methods that have particular semantics. These semantics include the AspectJ ones, <<before>>, <<after>> (only <<after>>, not AspectJ s <<after returning>> and <<after throwing>>), and <<around>>, and also the <<replace>> and <<role>> semantics. Pointcut relations: Pointcut relations are used to link some aspect methods to some points of the base class, and thus, model the exact place of invocation of the aspect methods. The Group construct may be used here instead of the normal class in order to capture the aspect s real behaviour in the usual cases where the aspect can be invoked from more than one class. 31 The following example taken from can be used to clarify the methodology: Fig. 1: Authentication aspect: an example taken from 31 In the figure, we can see the clear representation of the basic AOP concepts to the extended UML. The group stereotype in the diagram is used to declare that the location and the type of the clients are something abstract (they can be different classes that belong to the same group, not only one). The pointcut stereotype is used to represent when will the aspect be invoked (in the example, in the client side the authentication aspect will be invoked each time a method from the server is invoked, while in the server side the aspect will be invoked each time any of the server s methods is executed). Finally, the aspect stereotype includes the necessary definitions for the aspect invocation. 8

9 Odysseas Papapetrou and George A. Papadopoulos Another interesting work in AOP modelling is described in 21. The writers start from the initial modelling without aspects, by using an interceptor to handle invocations of different aspects (that is, the developer does not call the method itself but the interceptor, which then calls the aspect code prior calling the method). Then, they introduce the concept of aspect and pointcuts to UML. Pointcut constructs include all the necessary knowledge for the aspect s invocation, and they are connected with a binding relationship with the base classes that need to be monitored. Aspect constructs on the other hand contain the functionality of the aspects. The relationship between AOP and UML is also explored in 44 ; here, however, the authors are extending UML with a new diagram type to support aspect architectures. This framework assists the developer in designing aspects in an incremental way and provides a way to reason about the influence of one aspect on another one within the same system. Ending this section, we would like to stress that while many other approaches are documented for modelling AOP with UML, there is currently no standardization in the field yet. Efforts from conferences and workshops like the International Conference on Aspect Oriented Software Development and the Workshop on Aspect oriented modelling with UML for standardization are valuable and important for success of the AOP approach, and we hope that soon this would be enabled Aspect Oriented Design with other Architecture Description Languages While several other ADL languages 27 managed to establish themselves in the area of software modelling, less effort was reported (compared to the UML-based achievements) in the integration of them with Aspect Oriented Programming. According to Navasa 1, in order to manage the separation of concerns at architectural design of software systems, the current ADLs must be extended to provide functionality in specifying: (i) join points in the model, that is, the points in the functional components where the aspect specification has been extracted from, and thus needs to be added during aspect weaving; (ii) aspects modelled as a special kind of components, but new primitives for aspects should also be introduced; (iii) connectors between join points and aspects, which are different from the connectors between components. A possibility to use ready solutions from the coordination languages and models is suggested. In an ongoing work 2, Navasa et al. report some first attempts and some guidelines for using LEDA, a state of the art ADL, for modelling AOP systems. The main reason for selecting LEDA over other ADLs in that work is the fact that it handles connectors (the communication links between the components) as first class citizens. Several other characteristics of the language also favour AOP design. Other extensible ADL languages such as ACME may also prove themselves suitable for the task. However, there appears to exist no formal work published yet in the integration of AOP with Architecture Description Languages, other than the work reported here Code Generation While the advantages of AOP are widely accepted over the community, there is a consensus for the need of a complete methodology to support the AOP logic. Such a methodology should enclose the design phase and guide the user to the final code, perhaps with a code 9

10 Enhancing Component-Based Software Development with Aspect Oriented Programming generation facility. The case of AOP in the component oriented environment with the standard of high modularity and low coupling between components is of no difference. Currently, there are some proposals for such methodologies, motivated mostly from the ability to produce executable code from well defined software designs. These approaches use AOP-aware UML (e.g. Theme/UML) to map to code constructs, or even produce executable code (e.g. QCCS) that encapsulates the designs. UML has for long been used for code generation, due to its unambiguity and relevant completeness. Some widely spread tools, e.g. Rational Rose from IBM 39 and Together from Borland 38, offer solutions for the complete software development lifecycle, from requirements, to modelling and coding. More to the point, they can produce the code skeleton from the UML models (they mainly work on the class and component diagrams). Thus, the developer has a good, modular, well structured base to start with and fill in his code. In more advanced cases, the programmer may even apply the proprietary code in the UML models (e.g. as UML note, or a non-uml standard field) and compile and run from inside the CASE tool, without ever seeing the code files per se. There are several recent methodologies trying to implement code generation in aspect-aware UML models, one of them being QCCS. While QCCS s main purpose is not to generate code from aspect-aware UML, QCCS uses the AOP-aware design model to produce code for quality-controlled components. QCCS allows the user to model contracts that represent guarantees for QoS. The contracts are selected from an extensible predefined library of contracts during the design-modelling phase. These contracts are then realized and implemented as aspects. The whole transformation and code generation procedures are mostly transparent from the user, since a powerful case tool (Kase) is used from the beginning of the software life cycle and can facilitate the processes of modelling with UML, project creation in C#.NET, and finally, code generation for the contracts (based on the AOP model). In order to enhance the software with QoS, the application developer has to do nothing complicated (supposing that he is using ready-made contracts), just model the system with the contracts, and then catch and evaluate the events fired from the contracts. Such an approach eases QoS in component systems, a very important aspect in today s component-based software development. Finally, Clarke 8 presents an attempt to map the UML designs (interaction and class diagrams mostly) to AspectJ s constructs. While (to the authors knowledge) the methodology is not supported from a code generation tool, the generation of such a tool seems straightforward and will result in better exploitation of the method. 3. Using AOP in Component-Based Software Development The combination of AOP with component-based software development is already considered in various academic research publications. However, no standardization effort has currently been successful, thus restraining the two technologies from being combined in commercial solutions. Some of the initiatives for using AOP at component-based software development are QCCS 34 and Aspectual Components. Suvee et al. 41 also try to adopt AOP in componentbased software development. 10

11 Odysseas Papapetrou and George A. Papadopoulos Blank and Vayngrib 7, observing that Enterprise Java Beans and AOP can act complementary to each other, investigate the case of combining them for solving some of the EJB s problems. Duclos et al. 12 also propose a way for enhancement of components with aspects. Having as a goal to keep the advantages of both component-based software and aspect oriented software, they try to combine AOP with components based on the CCM (Corba Component Model) approach. According to the CCM model, each component has an abstract definition and one or more implementation descriptions. Each component also has a number of ports to communicate with its environment. In this work, combining AOP with the CCM model, not only enables the user to bind-relate aspects with all these constructs (e.g. one case would require only one component implementation to be checked, while another one would require all the component implementations to be bound with the aspect), but also does not require source code for the components. The proposed work was also implemented and tested with a number of aspects and with encouraging results. Aspectual components is another state of the art approach. Lieberherr et al. 24 present an interesting approach for combining components with AOP, without sacrificing the components or the aspects reusability. More to the point, they recognize the problems with original aspect oriented approaches (making direct references to AspectJ) that disallow aspect reusability since they make direct references to class-depended variables. Not so problematic for standard object-oriented programming, these direct references result in high coupling which is completely unacceptable in component-based software engineering. Thus, two new constructs are defined, aspectual components and connectors. Aspectual components try to include all the knowledge for the context of execution (the class and method that invoked them) in abstract references inside them which however are resolved with real classes at runtime only. Aspectual components describe what features-method patterns they expect from the class to be bounded, and how will these methods be executed or replaced. The most important fact in the aspectual components definition however, is that they actually include none of the application-depended information, e.g. the exact class name. Aspectual components are then connected (bound) with actual classes and methods with connectors. Connectors are the second basic construct of the methodology, and have a purpose to connect the methods of the classes with the aspects that should be invoked. Connectors however allow something more than a pure one-to-one mapping of methods with aspectual components (e.g. invoke an aspect each time a particular method from a class of some type is called). They can also capture a collection of methods and classes with wild cards and typical pattern matching, thus representing a more dynamic model than the traditional AOP. A combination of connectors can also be used to map different class types and methods with the same aspect without any problem. Probably the most important characteristic is that connectors, which are the only non-reusable part of the methodology, can very easily be constructed or modified for different programs. Aspectual components on the other hand need not be changed in order to be reused in other applications. The programmer just needs to write the proper connectors in order to invoke them. JasCo 41 is also concerned with the same subject. Extending the AspectJ s model 37 and Aspectual components 24, Suvee et al. present a methodology for integrating AOP in component-based systems, but without sacrificing either the components portability, or the aspects reusability. JAsCo suggests two basic constructs: (a) aspect beans, and (b) connectors. Aspect beans are nothing more than Java Beans, containing one or more logically related hooks as inner classes. Hooks try to capture the meaning of AspectJ s pointcuts and 11

12 Enhancing Component-Based Software Development with Aspect Oriented Programming advices. More formally, hooks include the when and what; when will something be executed, and what is the extra behaviour (code) that will be executed. Connectors on the other hand, like in the Aspectual Components approach, are used for deploying the aspects in the application. However, unlike aspectual components and other approaches, since working with Java Beans implies that events are used for inter-component communication, the model provides the ability for connectors that monitor events (instead of methods). Thus, the ability to bind events with aspects is also provided. Furthermore, another important difference of JAsCo, compared to some other AOP approaches, is that the former keeps the aspects (hooks) as first-class entities, even after compilation. It does not weave the aspect code in the actual functional code. This way, JAsCo provides for enabling and disabling of aspects at runtime, without recompilation or reloading. Another state-of-the-art initiative, QCCS 34, also investigates the case of combining component-based development with AOP. More specifically, QCCS developed a methodology and supporting tools for creation of quality-aware components with contracts based on aspect oriented programming. Based on the divide-and-conquer strategy for complex problems, QCCS suggests that the quality-related requirements of the components are best represented with aspect-oriented programming. More specifically, QCCS allows quality contracts for each component that are implemented with AOP. QCCS comes with a powerful CASE tool (Kase) which allows UML modelling, enhanced with the ability to model contracts. The tool not only enables modelling of the system s architecture, but supports also code generation, not only for the structure component code, but mainly for the quality-related code of the system. The issue of QoS and its relationship with AOP is also studied in 51. The work describes an adaptive environment, where QoS management is modelled as an aspect. The code of the latter can then access application-specific middleware and system information and controls, without the need to modify the actual application code. The associated aspect model includes join points specific to distribution and adaptation. Finally, yet another approach 52 on dealing with QoS-related non-functional aspects, is introducing the notion of a component container. The different aspects are woven into the running system by means of such a container which provides concepts for negotiation and monitoring of non-functional contracts between different components and operating system resources, as well as other platform services. This work focuses in particular on the streaming interfaces of multimedia-based applications. At this stage, it is worth mentioning two further approaches based on the use of AOP in Javabased enterprise systems, namely JBoss 47 and AspectWerkz 48. These environments allow developers to write Java objects separately from applications and later apply the former as enterprise-type services to the latter, without the need to change the applications code. JBoss features dynamic AOP where new interceptors (the mechanism used by JBoss to implement advices) can be added or removed at run time. AspectWerkz also supports dynamic AOP by means of dynamic weaving realised in the form of run time pointcut definitions. Specific uses of AOP in CBSD: The inherent capability of AOP to capture crosscutting concerns can offer elegant solutions in problems faced from CBSD. The bibliography on the subject mainly focuses in the following reasons for enhancing CBSD with AOP: (a) Performance, (b) Fault-tolerance, (c) Load-balancing (d) Enhancing reusability, (e) Implementing functional requirements, and (f) Building or enhancing the middleware. 12

13 Odysseas Papapetrou and George A. Papadopoulos Following, we will present how AOP can help in implementing these requirements. The advantages of the AOP approach, compared with the non-aop approach will also become clear to the reader. We argue that the integration of components with the AOP paradigm can be useful for several reasons. We will now demonstrate some of these reasons. 3.1 AOP for Performance and Quality of Service Performance has for long been one of the most important aspects in software, from simple timeouts to complex load-balancing formulas. Since most of the times it is difficult to model and implement, performance is usually applied to the project only after its completion. However, making a software component performance-aware, or, with performance guarantees, introduces several problems: (i) The code that monitors performance is embedded into the application code. As a result, the application code not only becomes less readable, but also more error-prone. Code maintenance (either the application or the performance-related code itself) in such scenarios is very difficult. (ii) Code that monitors performance parameters is usually hard to write. While this would not be a problem if there was a way to reuse the code, this is not the case in traditional performance-aware code. Since performance aspects are not modelled as autonomous parts, but rather embedded into the application code, the reusability of these aspects is impossible. This will result in the unacceptable situation of having to copy parts of code to different parts of the application. Furthermore, implementing the performance aspects as traditional classes is rarely a solution, since this will usually result in high-coupling between components (or classes) which would make things worse. Instead, a more structural way is required. (iii) There is no way of modelling performance properties as separate entities in the software models. More specifically, while modelling the application is standardized in the application s lifecycle, there is no simple way to include the performance-related properties and code of the application in the model. Up to now, the UML note field was used for keeping such information. However, this approach restricts the user from reusing the performance-related knowledge. Furthermore, code generation for the performance aspects (e.g. contracts) cannot be produced from the note field. Several studies prove that the traditional object-oriented paradigm is not suited well for implementing performance-aware software. For example, Mendhekar et al. 28, note that while detecting and anticipating performance problems with traditional OOP was sometimes easy, the outcome was not satisfactory since the code produced was tangled and confusing. Furthermore, they stress that some of the optimizations could not be done at all without completely breaking the modular structure of the program. For these reasons we consider the traditional ways of designing and implementing applications inefficient and difficult for performance-aware systems. AOP however can provide answers to these questions. Moving in the larger domain of quality-aware software, Plouzeau et al. 34 were able to introduce performance contracts in the UML design in order to later generate their code. More importantly, their approach was powered by simple aspect oriented programming and standard UML. By representing the performance-oriented functionality as aspects, not only the designer manages to represent the extra-functional requirements as autonomous entities, but at the 13

14 Enhancing Component-Based Software Development with Aspect Oriented Programming same time the resulted implementation is made more modular. The approach succeeds in completely decoupling the functional from the monitoring (performance-related) code, thus decoupling the functional from the extra-functional requirements. The new code can be removed any time from the compilation or reused in similar cases, without the need to introduce changes in the software. Furthermore, since the performance properties are now fully represented as aspects, they can be clearly modelled in a UML extension framework at the design level. For the sake of clarity, a trivial example code (the non-aop and the AOP version) is presented below. Our task is to add network QoS monitoring code in existing code. More specifically, the code is used for performance monitoring of a client-server network connection, and could be part of any client-server multimedia application which can also work offline (abandon the client-server model). The two machines exchange proprietary size and proprietary content messages over the network (the case could also be a streaming connection). The code is executed in the client host, each time the client tries to send a message to the server. The code tries to capture the case where the network latency between the server and the client gets more than a threshold, and in such a case interrupt the communication (and operate offline). The problems discussed above should be obvious in the non-aop code, since the performance-aware code is tangled with the code implementing the functional requirements. To make code tangling more visible, the code that we needed to add for the implementation of the latency monitor is presented in italic underline. The code is written in Java, although the code in any other language should be very similar. TCPConnection conn1 = new TCPConnection(server_ip, server_port); //... // sendtcpmessage is called only when the client is not // working disconnected // for every time the sendtcpmessage method is called, first // check the connection delay int conn_delay = conn1.checkconnectiondelay(); // get connection delay if ((conn_delay > MAXTHRESHOLD) // propagation delay too long (conn_delay == -1)) // -1 means network fault { System.err.println("Switching to disconnected mode"); System.err.println("All messages will be cached"); System.err.println("and sendtcpmessage will not be called again"); // go disconnected... conn1.setdisconnected(true); else { if (!connection.sendtcpmessage(data)) // returns true if // message is sent { // error handling //... ; 14

15 Odysseas Papapetrou and George A. Papadopoulos //... Also, we would have to modify the TCPConnection class, in order to implement the method checkconnectiondelay(). This code is omitted from here for the sake of clarity. The AOP (AspectJ) code for the same task follows. As we can see below, the code remains completely intact, without any additions from the introduction of the aspect into the system: // the file which includes the original code remains intact TCPConnection conn1 = new TCPConnection(server_ip, server_port); //... // and whenever we need, we use conn1.sendtcpmessage as before if (!connection.sendtcpmessage(data)) // returns true if // message is sent { // error handling //... ; We only create an aspect file to implement the concern, which includes the monitoring code: public aspect MonitorTCPConnection { pointcut messagesend():call(boolean TCPConnection.sendTCPMessage(String)); // add code to the TCPConnection class, // but without modifying the original file! int TCPConnection.checkConnectionDelay() { //... // the code here is omitted boolean around(tcpconnection conn1, String data) : messagesend() && target(conn)&& args(data) { int conn_delay = conn1.checkconnectiondelay(); if ((conn_delay > MAXTHRESHOLD) // propagation delay too long (conn_delay == -1)) { // -1 means network fault System.err.println("Switching to disconnected mode"); System.err.println("All messages will be cached"); System.err.println("and sendtcpmessage won t be called again"); // go disconnected... conn1.setdisconnected(true); else return (conn1.sendtcpmessage(data)); // pass the result out 15

16 Enhancing Component-Based Software Development with Aspect Oriented Programming Making a new method to include the quality-related code and replacing all the calls of the original method sendtcpmessage(string) can improve the situation, but will still require changes in the original code and make reusability difficult, if not impossible. Performance and Quality of Service was also in the focus of the QCCS project 34. By using a tailor-made aspect weaver, the users were able to easily enable or disable quality-control over components. For instance, by using an independently developed aspect for monitoring the connection between a (third-party) media player component and a (third-party) media server, the developer was able to monitor the available connection s bandwidth, and dynamically decrease or increase the video resolution so that the media can transparently appear to the user in maximum available quality for the variable status of the connection. A special case of performance-aware systems is real-time software. Real-time software tries to guarantee a minimum latency in program execution. However, in today s web and distributed applications, the case usually includes a non-static software architecture, with an arbitrary number of clients and servers and a weak or unstable underlying network infrastructure. For this reason, real-time components and real-time software in general, are both very difficult to construct. Furthermore, injecting the real-time monitoring code manually in the components is an exhausting and error-prone procedure, that renders tangled code very difficult to maintain. Limniotes et al. 25 suggest that the Manifold coordination language is fairly suited for implementing real-time systems, due to the language s exceptional distributed event handling system. However, Manifold, as other coordination languages, do fail in simplicity of programming and execution. This is why aspect orientation, following more or less the same principles (coordination paradigm also works with separation of concerns, but at a different level), can be considered for real-time applications. Gal et al. 15 investigate the use of AOP for constructing applications with real-time concerns. In their work, they demonstrate an example of aspect-oriented real-time monitoring, which not only is more modular and easy to construct than the traditional solution (with the tangling code) but is also more reusable. The code is demonstrated in AspectC++ with CORBA constructs for a distributed system. 3.2 AOP for Fault-Tolerance From the first days of Java, an important software revolution was noticed. Trying to catch the various possible architectures and configurations, Java aimed at prohibiting possible errors, or better, force the designer to construct fault-tolerant software. To do that, the Java compiler was marking all the possible thread-raising places in the code, and forcing the programmer to construct an error-handling code in order to heal the program execution. However, the trycatch solution was not enough, especially for third-party components that were developed without error-recovery provision. Here, the AOP model can be used to alleviate the problem. As demonstrated in 15, AOP can easily be used to predict and avoid error conditions or force immediate recovery. More important however is the fact that this is done in an efficient, easy, and elegant way that allows reusability and better maintenance. Fradet and Sudholt 14 also deal with the fault-tolerance problem with an aspect-oriented approach. More specifically, they focus on numerical calculations to suggest semantics to declare join-points and pointcuts for robustness. For example, a pointcut for an aspect to handle the very common divide-by-zero exception could be defined with a semantic like this: 16