Aspect-oriented software development An introductory guide
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Tue, 06 Dec 2011 01:25:58 UTC Contents
Articles
Overview 1 Aspect-oriented software development 1 Aspect-oriented programming 12
Concepts 22 Aspect 22 Advice 23 Join point 25 Pointcut 25 Aspect weaver 26 Cross-cutting concern 31
Languages 33 AspectJ 33 AspectC++ 36 AspectWerkz 37 References Article Sources and Contributors 38 Image Sources, Licenses and Contributors 39 Article Licenses License 40 1
Overview
Aspect-oriented software development
In computing, Aspect-oriented software development (AOSD) is an emerging software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program's business logic. AOSD allows multiple concerns to be expressed separately and automatically unified into working systems. Traditional software development focuses on decomposing systems into units of primary functionality, while recognizing that there are other issues of concern that do not fit well into the primary decomposition. The traditional development process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keep in mind all the things that need to be done, how to deal with each issue, the problems associated with the possible interactions, and the execution of the right behavior at the right time. These concerns span multiple primary functional units within the application, and often result in serious problems faced during application development and maintenance. The distribution of the code for realizing a concern becomes especially critical as the requirements for that concern evolve — a system maintainer must find and correctly update a variety of situations. Aspect-Oriented Software Development focuses on the identification, specification and representation of cross-cutting concerns and their modularization into separate functional units as well as their automated composition into a working system.
History Aspect-Oriented Software Development describes a number of approaches to software modularization and composition including, in order of publication, reflection and metaobject protocols, Composition Filters,[1] developed at the University of Twente in the Netherlands, Subject-Oriented Programming[2] (later extended as Multidimensional Separation of Concerns)[3] at IBM, Feature Oriented Programming[4] at University of Texas at Austin, Adaptive Programming[5] at Northeastern University, USA, and Aspect-Oriented Programming (AOP)[6] at Palo Alto Research Center. The term aspect-oriented was introduced by Gregor Kiczales and his team at Palo Alto Research Center who also first developed the explicit concept of AOP and the AOP language called AspectJ which has gained considerable acceptance and popularity within the Java developer community. Currently, several aspect-oriented programming languages are available for a variety of languages and platforms. Just as object-oriented programming led to the development of a large class of object-oriented development methodologies, AOP has encouraged a nascent set of software engineering technologies, including methodologies for dealing with aspects, modeling techniques (often based on the ideas of the Unified Modeling Language, UML), and testing technology for assessing the effectiveness of aspect approaches. AOSD now refers to a wide range of software development techniques that support the modularization of crosscutting concerns in a software system, from requirement engineering to analysis and design, architecture, programming and implementation techniques, testing and software maintenance techniques. Aspect-oriented software development has constantly gained in popularity, and is the subject of an annual conference, the International Conference on Aspect-Oriented Software Development, held for the first time in 2002 in Enschede, The Netherlands. AOSD is a rapidly evolving area. It is a popular topic of Software Engineering research, especially in Europe, where research activities on AOSD are coordinated by the European Network of Excellence on Aspect-Oriented Software Development [7] (AOSD-Europe), funded by the European Commission. Aspect-oriented software development 2
Motivation
Crosscutting concerns
The motivation for aspect-oriented programming approaches stem from the problems caused by code scattering and tangling. The purpose of Aspect-Oriented Software Development is to provide systematic means to modularize crosscutting concerns.
The implementation of a concern is scattered if its code is spread out over multiple modules. The concern affects the implementation of multiple modules. Its implementation is not modular.
The implementation of a concern is tangled if its code is intermixed with Figure 3 — An UML architecture diagram for a telecom component code that implements other concerns. The module in which tangling occurs is not cohesive. Scattering and tangling often go together, even though they are different concepts. Aspect-oriented software development considers that code scattering and tangling are the symptoms of crosscutting concerns. Crosscutting concerns can not be modularized using the decomposition mechanisms of the language (object or procedures) because they inherently follow different decomposition rules. The implementation and integration of these concerns with the primary functional decomposition of the system causes code tangling and scattering.
Example 1: Logging in Apache Tomcat Figure 1 illustrates a decomposition into classes of the Apache Tomcat web container. The vertical bars in the diagram correspond to different packages in the Tomcat distribution. The length of these bars corresponds to the size of the code of these packages. In Figure 1, the code that corresponds to the classloading concern of the application have been highlighted in red. Classloading in Tomcat is a modular concern with respect to the system decomposition. Its implementation is contained in a small number of classes and is not intertwined with the implementation of other concerns. Figure 2 represents the implementation of the logging concern in Tomcat. Logging in Tomcat is a crosscutting concern. Its implementation spreads over many classes and packages and is intermixed with the implementation of many other concerns. Aspect-oriented software development 3
Example 2: Coordination of components Figure 3 represents the UML architecture diagram of a telecom component. Each box corresponds to a process that communicates with other processes through connectors. Figure 4 illustrates the impact of a coordination concern on the architecture of the system, such as When the system starts up, all parts must initialize successfully, otherwise the system must shut down. The highlighted box corresponds to a coordinator process. This concern has an impact on the implementation of each process in the diagram. Its implementation crosscuts the implementation of the other processes.
Examples of crosscutting concerns see Cross-cutting_concern#Examples
Problems caused by scattering and tangling Scattering and tangling of behavior are the symptoms that the implementation of a concern is not well modularized. A concern that is not modularized does not exhibit a well-defined interface. The interactions between the implementation of the concern and the modules of the system are not explicitly declared. They are encoded implicitly through the dependencies and interactions between fragments of code that implement the concern and the implementation of other modules. The lack of interfaces between the implementation of crosscutting concerns and the implementation of the modules of the system impedes the development, the evolution and the maintenance of the system.
System development A module is primarily a unit of independent development. It can be implemented to a large extent independently of other modules. Modularity is achieved through the definition of well-defined interfaces between segments of the system.[8] The lack of explicit interfaces between crosscutting concerns and the modules obtained through the functional decomposition of the system imply that the implementation of these concerns, as well as the responsibility with respect to the correct implementation of these concerns, cannot be assigned to independent development teams. This responsibility has to be shared among different developers that work on the implementation of different modules of the system and have to integrate the crosscutting concern with the module behavior. Furthermore, modules whose implementation is tangled with crosscutting concerns are hard to reuse in different contexts. Crosscutting impedes reuse of components. The lack of interfaces between crosscutting concerns and other modules makes it hard to represent and reason about the overall architecture of a system. As the concern is not modularized, the interactions between the concern and the top-level components of the system are hard to represent explicitly. Hence, these concerns become hard to reason about because the dependencies between crosscutting concerns and components are not specified. Finally, concerns that are not modularized are hard to test in isolation. The dependencies of the concern with respect to behavior of other modules are not declared explicitly. Hence, the implementation of unit test for such concerns requires knowledge about the implementation of many modules in the system.
System maintenance and evolution The lack of support for the modular implementation of crosscutting concerns is especially problematic when the implementation of this concern needs to be modified. The comprehension of the implementation of a crosscutting concern requires the inspection of the implementation of all the modules with which it interacts. Hence, modifications of the system that affect the implementation of crosscutting concern require a manual inspection of all the locations in the code that are relevant to the crosscutting concern. The system maintainer must find and correctly Aspect-oriented software development 4
update a variety of poorly identified situations.
Overview
Nature of aspect-orientation The focus of Aspect-Oriented Software Development (AOSD) is in the investigation and implementation of new structures for software modularity that provide support for explicit abstractions to modularize concerns. Aspect-Oriented Programming approaches provide explicit abstractions for the modular implementation of concerns in design, code, documentation, or other artifacts developed during the software life-cycle. These modularized concerns are called aspects, and aspect-oriented approaches provide methods to compose them. Some approaches denote a root concern as the base. Various approaches provide different flexibility with respect to composition of aspects
Quantification and obliviousness The best known definition of the nature of AOSD is due to Filman and Friedman, which characterized AOSD using the equation aspect orientation = quantification + obliviousness.[9] AOP can be understood as the desire to make quantified statements about the behavior of programs, and to have these quantifications hold over programs written by oblivious programmers.[9] AOP is the desire to make statements of the form: In program P, whenever condition C arises, perform action A over a conventionally coded program P.[9] Obliviousness implies that a program has no knowledge of which aspects modify it where or when, whereas quantification refers to the ability of aspects to affect multiple points in the program. The notion of non-invasiveness is often preferred to the term obliviousness. Non-invasiveness expresses that aspects can add behavior to a program without having to perform changes in that program, yet it does not assume that programs are not aware of the aspects. Filman's definition of aspect-orientation is often considered too restrictive.[10] Many aspect-oriented approaches use annotations to explicitly declare the locations in the system where aspects introduce behavior. These approaches require the manual inspection and modification of other modules in the system and are therefore invasive. Furthermore, aspect-orientation does not necessarily require quantification. Aspects can be used to isolate features whose implementation would otherwise be tangled with other features. Such aspects do not necessarily use quantification over multiple locations in the system. The essential features of Aspect-Oriented Software Development are therefore better characterized in terms of the modularity of the implementation of crosscutting concerns, the abstractions provided by aspect-oriented languages to enable modularization and the expressiveness of the aspect-oriented composition operators. Aspect-oriented software development 5
Concepts and terminology Aspect-oriented approaches provide explicit support for localizing concerns into separated modules, called aspects. An aspect is a module that encapsulates a concern. Most aspect-oriented languages support the non-invasive introduction of behavior into a code base and quantification over points in the program where this behavior should be introduced. These points are called join points.
Join point model Join points are points in the execution of the system, such as method calls, where behavior supplied by aspects is combined. A join point is a point in the execution of the program, which is used to define the dynamic structure of a crosscutting concern. The join point model of an aspect-oriented language defines the types of join points that are supported by the aspect-oriented language and the possible interaction points between aspects and base modules. The dynamic interpretation of join points makes it possible to expose runtime information such as the caller or callee of a method from a join point to a matching pointcut. Nowadays, there are various join point models around and still more under development. They heavily depend on the underlying programming language and AO language. Examples of join points are • method execution • method call • field read and write access • exception handler execution • static and dynamic initialization A method call join point covers the actions of an object receiving a method call. It includes all the actions that compose a method call, starting after all arguments are evaluated up to return. Many AOP approaches implement aspect behavior by weaving hooks into join point shadows, which is the static projection of a join point onto the program code. Figure 5 illustrates possible join points in the execution of a small object-oriented program. The highlighted join points include the execution of method moveBy(int, int) on a Line object, the calls to methods moveBy(int, int) on the Point objects in the context of the Line object, the execution of these methods in the context of the Point objects and the calls and execution of the setX(int) and setY(int) methods.
Pointcut designators The quantification over join points is expressed at the language level. This quantification may be implicit in the language structure or may be expressed using a query-like construct called a pointcut. Pointcuts are defined as a predicate over the syntax-tree of the program, and define an interface that constrains which elements of the base program are exposed by the pointcut. A pointcut picks out certain join points and values at those points. The syntactic formulation of a pointcut varies from approach to approach, but a pointcut can often be composed out of other pointcuts using the boolean operators AND, OR and NOT. Pointcut expressions can concisely capture a wide range of events of interests, using wildcards. For example, in AspectJ syntax, the move pointcut
pointcut move: call(public * Figure.* (..))
picks out each call to Figure's public methods. cflow poincuts identify join points based on whether they occur in the dynamic context of other join points. For example, in AspectJ syntax cflow(move()) picks out each join point that occurs in the dynamic context of the join points picked out by the move pointcut. Pointcuts can be classified in two categories: Aspect-oriented software development 6
• Kinded pointcuts, such as the call pointcut, match one kind of join point using a signature. • Non-kinded pointcuts, such as the cflow pointcut match all kinds of join points using a variety of properties.
Advice bodies An advice body is code that is executed when a join point is reached. Advice modularizes the functional details of a concern. The order in which the advice bodies contributed by aspects (and by the base) may be controlled in a variety of ways, including: • as a join point is reached, before the execution proceeds with the base • after the base semantics for the join point. When the join point corresponds to the execution of a method, an after advice can be executed after the method returned or after raising an exception • as the join point is reached, with explicit control over whether the base semantics is executed. Around advice can modify the control flow of the program. More general ways to describe the ordering of advice bodies in terms of partial-order graphs have also been provided.[11] When the execution of a join point satisfies a pointcut expression, the base and advice code associated with the join point are executed. The advice may interact with the rest system through a join point instance containing reflective information on the context of the event that triggered the advice, such as the arguments of a method call or the target instance of a call.
Inter-type declarations Inter-type declarations allow the programmer to modify a program's static structure, such as class members and classes hierarchy. New members can be inserted and classes can be pushed down the class hierarchy.
Aspects An aspect is a module that encapsulates a concern. An aspect is composed of pointcuts, advice bodies and inter-type declarations. In some approaches, and aspect may also contain classes and methods.
Aspect weaving Aspect weaving is a composition mechanism that coordinates aspects with the other modules of the system. It is performed by a specialized compiler, called an aspect weaver. Aspect-oriented software development 7
Example
Figure 6 illustrates a classic example of a crosscutting concern in a figure editor example taken from the AOSD literature. The example describes an abstract Shape class that can be moved in the editor. Whenever a shape is moved, the display needs to be refreshed. Figure 6 also depicts two Shape subclasses, Line and Point that implement the Shape functionality. The display refresh concern is scattered across the implementation of both subclasses. Figure 7 represents an aspect-oriented implementation of the same system, where an aspect encapsulates the display updating functionality. The move pointcut descriptor of Figure
7 captures all the executions of the Figure 6 — Figure Editor in UML moveBy methods of a subclass of Shape and invokes the display refresh functionality after the execution proceeds. The concern is modularized, which makes it easier to evolve and maintain.
Aspect-oriented requirement engineering
Aspect-oriented requirement Engineering (also referred to as "Early Aspects") focuses on the identification, specification and representation of crosscutting properties at the Figure 7 — Aspect-Oriented Figure Editor in UML requirement level. Examples of such properties include security, mobility, availability and real-time constraints. Crosscutting properties are requirements, use cases or features that have a broadly-scoped effect on other requirements or architecture components.
Aspect-oriented requirements engineering approaches are techniques that explicitly recognise the importance of clearly addressing both functional and non-functional crosscutting concerns in addition to non-crosscutting ones. Therefore, these approaches focus on systematically and modularly treating, reasoning about, composing and subsequently tracing crosscutting functional and non-functional concerns via suitable abstraction, representation and composition mechanisms tailored to the requirements engineering domain. Specific areas of excellence under the denominator of AO Requirements Analysis are: • the aspect-oriented requirements process itself, Aspect-oriented software development 8
• the aspect-oriented requirements notations, • aspect-oriented requirements tool support, • adoption and integration of aspect-oriented requirements engineering, and • assessment/evaluation of aspect-oriented requirements.
Aspect-oriented system architecture Aspect-oriented system architecture focuses on the localization and specification of crosscutting concerns in architectural designs. Crosscutting concerns that appear at the architectural level cannot be modularized by redefining the software architecture using conventional architectural abstractions. Aspect-oriented system architecture languages propose explicit mechanisms to identify, specify and evaluate aspects at the architecture design level. Aspect-oriented architecture starts from the observation that we need to identify, specify and evaluate aspects explicitly at the architecture design level. Aspectual architecture approaches describe steps for identifying architectural aspects. This information is used to redesign a given architecture in which the architectural aspects are made explicit. In this regard, specific areas of excellence are: • the aspect-oriented architecture process itself, • the aspect-oriented architecture notations, • aspect-oriented architecture tool support, • adoption and integration of aspect-oriented architecture, and • assessment/evaluation of aspect-oriented architecture.
Aspect-oriented modeling and design Aspect-oriented design has the same objectives as any software design activity, i.e. characterising and specifying the behavior and structure of the software system. Its unique contribution to software design lies in the fact that concerns that are necessarily scattered and tangled in more traditional approaches can be modularized. Typically, such an approach includes both a process and a language. The process takes as input requirements and produces a design model. The produced design model represents separate concerns and their relationships. The language provides constructs that can describe the elements to be represented in the design and the relationships that can exist between those elements. In particular, constructs are provided to support concern modularization and the specification of concern composition, with consideration for conflicts. Beyond that, the design of each individual modularized concern compares to standard software design. Here, specific areas of excellence areas are: • the aspect-oriented design process itself, • the aspect-oriented design notations, • aspect-oriented design tool support, • adoption and integration of aspect-oriented design, and • assessment/evaluation of aspect-oriented design. Aspect-oriented software development 9
Aspect-Oriented Programming (AOP) AOP includes programming techniques and tools that support the modularisation of concerns at the level of the source code. Just like any other programming language, an aspect-oriented language typically consists of two parts: a language specification and an implementation. Hence, there are two corresponding areas of excellence: support for language developers and support for application developers. Support for application developers An aspect-oriented approach supports the implementation of concerns and how to compose those independently implemented concerns. While the specification of such a language is the primary manual for application developers, it provides obviously no guarantee that the application developer will produce high-quality aspect-oriented programs. Specific areas of excellence: • the crucial concepts of aspect-oriented programming, • programming in aspect-oriented languages, • composing software components written in any language using aspect-oriented composition mechanisms, or • aspect-oriented programming environments. Support for language developers Excellence on support for constructing aspect languages includes the following areas: • constructing languages or teels for specific domains and/or platforms, and • transferring implementation principles of aspect-oriented execution environments, including • interpreters, • compilers, and • virtual machines.
Formal method support for aspect-orientation Formal methods can be used both to define aspects semantically and to analyze and verify aspect-oriented systems. Aspect-oriented programming extends programming notations with aspect modules that isolate the declaration of when the aspect should be applied (join points) and what actions should be taken when it is reached (advice). Expertise in formal semantic definitions of aspect constructs is useful for language designers to provide a deep understanding of the differences among constructs. Aspects potentially can harm the reliability of a system to which they are woven, and could invalidate essential properties that already were true of the system without the aspect. It is also necessary to show that they actually do add intended crosscutting properties to the system. Hence, numerous questions of correctness and verification are raised by aspect languages. Among the kinds of expertise are: • specially designed testing techniques to provide coverage for aspects, • program slicing and code analysis approaches to identify interactions among aspects and between aspects and underlying systems, • model checking techniques specialized for aspects, and • inductive techniques to verify aspect-oriented systems. Each of the above approaches can be used to • specify and analyze individual aspects relative to an existing system, • define conditions for composing multiple aspects correctly, and • detect and resolve potential interferences among aspects. Although some approaches are already used in aspect languages, others are still subject of research and are not ready for routine industrial application. Nevertheless, awareness of these issues is essential for language designers, and for effective use of aspects, especially in safety-critical contexts. Aspect-oriented software development 10
Aspect-oriented middleware Middleware and AOSD strongly complement each other. In general, areas of excellence consist of • support for the application developer, which includes • the crucial concepts of aspect supporting middleware, • aspect-oriented software development using a specific middleware, involving the aspect programming model, aspect deployment model, platform infrastructure, and services of the middleware, and • Product Family Engineering (methods, architectures, techniques) in distributed and ambient computing, and • support for the middleware developer with respect to • host-infrastructure middleware, • distribution middleware, • common middleware services, and • domain-specific middleware services.
Adoption • IBM Websphere Application Server (WAS) is a java application server that supports Java EE and Web Services. Websphere is distributed according to editions that support different features. Websphere uses AspectJ internally to isolate features of the different editions. • JBoss Application Server (JBoss AS) is a free, open-source java application server that supports Java EE. The core of JBoss AS is integrated with the JBoss AOP aspect-oriented programming language.[12] The application server uses JBoss AOP to deploy services such as security and transaction management. • Oracle TopLink is a Java object-to-relational persistence framework that is integrated with the Spring Application Server. TopLink achieves high levels of persistence transparency using Spring AOP. • SAP • Sun Microsystems uses AspectJ to streamline mobile application development for the Java ME platform. Aspects are used to simplify the development of mobile applications for deployment to different operator decks and different mobile gaming community interfaces. • Siemens Soarian is a health information management system that supports seamless access to patient medical records and the definition of workflows for health provider organizations. Soarian uses AspectJ to integrate crosscutting features such as tracing, auditing and performance monitoring in the context of an agile development process. • Motorola wi4 is a cellular infrastructure system that provides support for the WiMAX wireless broadband standard. The wi4 control software is developed using an aspect-oriented extension to the UML 2.0 standard called WEAVR. WEAVR is used during the development for debugging and testing purposes. • ASML is a provider of lithography systems for the semiconductor industry. ASML uses an aspect-oriented extension to C called Mirjam to modularize tracing and profiling concerns. • Glassbox is a troubleshooting agent for Java applications that automatically diagnoses common problems. The Glassbox inspector monitors the activity of the Java virtual machine using AspectJ. • .NET 3.5 supports Aspect Oriented concepts through the Unity container. Aspect-oriented software development 11
Footnotes [1] Bosch, J.; M. Aksit (1992). Composition-Filters Based Real-Time Programming. Vancouver: An Evaluation of Object-Oriented Technology in Real-Time Systems: Past, Present & Future (ACM OOPSLA'92 Workshop). [2] Harrison, William; Harold Ossher (September 1993). "Subject-Oriented Programming - A Critique of Pure Objects". Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications. [3] Ossher, Harold; Peri Tarr, William Harrison, Stanley Sutton (May 1999). "N-Degrees of Separation: Multi-Dimension Separation of Concerns". Proceedings of 1999 International Conference on Software Engineering. [4] Batory, Don S.; V. Singhal, J. Thomas, S. Dasari, B. Geraci, M. Sirkin (September 1994). "The GenVoca Model of Software-System Generators". IEEE Software. [5] Lieberherr, K. (1996). Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing Company. [6] Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, John Irwin (1997). "Aspect-Oriented Programming". Proceedings of the European Conference on Object-Oriented Programming 1241: 220–242.
[7] http:/ / www. aosd-europe. net/ [8] Parnas, D.L. (1972): On the Criteria To Be Used in Decomposing Systems into Modules, in: Communications of the ACM, December 1972, Vol. 15, No. 12, 1053-1058 [9] Filman, R. and D. Friedman. “Aspect-oriented programming is quantification and Obliviousness.” Proceedings of the Workshop on Advanced Separation of Concerns, in conjunction with OOPSLA’00 (2000) [10] Rashid, A and A. Moreira. “Domain Models are NOT Aspect Free.” Proceedings of the 9th Internation Conference on Model-Driven Engineering Languages and Systems (Models06). Genoa, Italy. LNCS 4199. Springer-Verlag (2006): 155-169. [11] William Harrison, Harold Ossher, Peri Tarr. General Composition of Software Artifacts, Proceedings of Software Composition Workshop 2006, March 2006, Springer-Verlag, LNCS 4089, pages 194-210
[12] "Chapter 8. JBoss AOP" (http:/ / docs. redhat. com/ docs/ en-US/ JBoss_Enterprise_Application_Platform/ 5/ html/
Administration_And_Configuration_Guide/ jboss_aop. html). Red Hat. 2010. .
References • Kiczales, G., J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J.-M. Loingtier, J. Irwin (1997): Aspect-Oriented Programming, in: Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP 1997), Jyväskylä, Finland, Lecture Notes in Computer Science 1241, Springer-Verlag, 220-242 • Murphy, G.C., R.J. Walker, E.L.A. Baniassad, M.P. Robillard, A. Lai, M.A. Kersten (2001): Does Aspect-Oriented Programming Work?, in: Communications of the ACM, October 2001, Vol. 44, No. 10, 75-77 • Tarr, P., H. Ossher, W. Harrison, S.M. Sutton Jr. (1999): N Degrees of Separation: Multi- Dimensional Separation of Concerns, in: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, California, USA, IEEE Computer Society Press, 107-119
External links
• Aspect-Oriented Software Development Community and Conference (http:/ / www. aosd. net/ )
• European Network of Excellence on Aspect-Oriented Software Development (http:/ / www. aosd-europe. net/ )
• Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design (http:/ / www. early-aspects.
net/ )
• The Aspect-Oriented Software Architecture Design Portal (http:/ / trese. cs. utwente. nl/ taosad/ )
• Aspect-Oriented Software Engineering at Lancaster (http:/ / www. comp. lancs. ac. uk/ computing/ aop/ )
• Early Aspects for Business Process Modeling (An Aspect-Oriented Language for BPMN) (http:/ / dssg. cs. umb.
edu/ wiki/ index. php/ Early_Aspects_for_Business_Process_Modeling)
• Composition Filters Model (http:/ / trese. cs. utwente. nl/ oldhtml/ composition_filters/ )
• Demeter and Adaptive Programming (http:/ / www. ccs. neu. edu/ research/ demeter/ )
• IBM subject-oriented programming (http:/ / www. research. ibm. com/ sop/ )
• Aspect-Oriented Software Development Course, Bedir Tekinerdogan, Bilkent University (http:/ / www. cs.
bilkent. edu. tr/ ~bedir/ CS586-AOSD/ ) Aspect-oriented programming 12 Aspect-oriented programming
In computing, aspect-oriented programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while "aspect-oriented software development" refers to a whole engineering discipline.
Overview Aspect-oriented programming entails breaking down program logic into distinct parts (so-called concerns, cohesive areas of functionality). Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program. Logging exemplifies a crosscutting concern because a logging strategy necessarily affects every logged part of the system. Logging thereby crosscuts all logged classes and methods. All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. The difference between implementations lies in the power, safety, and usability of the constructs provided. For example, interceptors that specify the methods to intercept express a limited form of crosscutting, without much support for type-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, an aspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structural changes to other classes, like adding members or parents.
History AOP has several direct antecedents:[1] reflection and metaobject protocols, subject-oriented programming, Composition Filters and Adaptive Programming.[2] Gregor Kiczales and colleagues at Xerox PARC developed the explicit concept of AOP, and followed this with the AspectJ AOP extension to Java. IBM's research team pursued a tool approach over a language design approach and in 2001 proposed Hyper/J and the Concern Manipulation Environment, which have not seen wide usage. EmacsLisp changelog added AOP related code in version 19.28 [3]. The examples in this article use AspectJ as it is the most widely known AOP language. The Microsoft Transaction Server is considered to be the first major application of AOP followed by Enterprise JavaBean.[4] [5]
Motivation and basic concepts Typically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered by virtue of the function (such as logging) being spread over a number of unrelated functions that might use its function, possibly in entirely unrelated systems, different source languages, etc. That means to change logging can require modifying all affected modules. Aspects become tangled not only with the mainline function of the systems in which they are expressed but also with each other. That means changing one concern entails understanding all the tangled concerns or having some means by which the effect of changes can be inferred. Aspect-oriented programming 13
For example, consider a banking application with a conceptually very simple method for transferring an amount from one account to another:[6]
void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {
if (fromAcc.getBalance() < amount) { throw new InsufficientFundsException(); }
fromAcc.withdraw(amount); toAcc.deposit(amount); }
However, this transfer method overlooks certain considerations that a deployed application would require. It lacks security checks to verify that the current user has the authorization to perform this operation. A database transaction should encapsulate the operation in order to prevent accidental data loss. For diagnostics, the operation should be logged to the system log. And so on. A simplified version with all those new concerns would look somewhat like this:
void transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) throws Exception { logger.info("transferring money..."); if (! checkUserPermission(user)){ logger.info("User has no permission."); throw new UnauthorizedUserException(); } if (fromAcc.getBalance() < amount) { logger.info("Insufficient Funds, sorry"); throw new InsufficientFundsException(); }
fromAcc.withdraw(amount); toAcc.deposit(amount);
//get database connection
//save transactions
logger.info("Successful transaction."); }
In the previous example other interests have become tangled with the basic functionality (sometimes called the business logic concern). Transactions, security, and logging all exemplify cross-cutting concerns. Now consider what happens if we suddenly need to change (for example) the security considerations for the application. In the program's current version, security-related operations appear scattered across numerous methods, and such a change would require a major effort. Aspect-oriented programming 14
AOP attempts to solve this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects. Aspects can contain advice (code joined to specified points in the program) and inter-type declarations (structural members added to other classes). For example, a security module can include advice that performs a security check before accessing a bank account. The pointcut defines the times (join points) when one can access a bank account, and the code in the advice body defines how the security check is implemented. That way, both the check and the places can be maintained in one place. Further, a good pointcut can anticipate later program changes, so if another developer creates a new method to access the bank account, the advice will apply to the new method when it executes. So for the above example implementing logging in an aspect:
aspect Logger {
void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger) { logger.info("transferring money..."); }
void Bank.getMoneyBack(User user, int transactionId, Logger logger) { logger.info("User requested money back"); }
// other crosscutting code... }
One can think of AOP as a debugging tool or as a user-level tool. Advice should be reserved for the cases where you cannot get the function changed (user level)[7] or do not want to change the function in production code (debugging).
Join point models The advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines three things: 1. When the advice can run. These are called join points because they are points in a running program where additional behavior can be usefully joined. A join point needs to be addressable and understandable by an ordinary programmer to be useful. It should also be stable across inconsequential program changes in order for an aspect to be stable across such changes. Many AOP implementations support method executions and field references as join points. 2. A way to specify (or quantify) join points, called pointcuts. Pointcuts determine whether a given join point matches. Most useful pointcut languages use a syntax like the base language (for example, AspectJ uses Java signatures) and allow reuse through naming and combination. 3. A means of specifying code to run at a join point. AspectJ calls this advice, and can run it before, after, and around join points. Some implementations also support things like defining a method in an aspect on another class. Join-point models can be compared based on the join points exposed, how join points are specified, the operations permitted at the join points, and the structural enhancements that can be expressed. Aspect-oriented programming 15
AspectJ's join-point model • The join points in AspectJ include method or constructor call or execution, the initialization of a class or object, field read and write access, exception handlers, etc. They do not include loops, super calls, throws clauses, multiple statements, etc. • Pointcuts are specified by combinations of primitive pointcut designators (PCDs). "Kinded" PCDs match a particular kind of join point (e.g., method execution) and tend to take as input a Java-like signature. One such pointcut looks like this:
execution(* set*(*))
This pointcut matches a method-execution join point, if the method name starts with "set" and there is exactly one argument of any type. "Dynamic" PCDs check runtime types and bind variables. For example
this(Point)
This pointcut matches when the currently-executing object is an instance of class Point. Note that the unqualified name of a class can be used via Java's normal type lookup. "Scope" PCDs limit the lexical scope of the join point. For example:
within(com.company.*)
This pointcut matches any join point in any type in the com.company package. The * is one form of the wildcards that can be used to match many things with one signature. Pointcuts can be composed and named for reuse. For example
pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*);
This pointcut matches a method-execution join point, if the method name starts with "set" and this is an instance of type Point in the com.company package. It can be referred to using the name "set()". • Advice specifies to run at (before, after, or around) a join point (specified with a pointcut) certain code (specified like code in a method). The AOP runtime invokes Advice automatically when the pointcut matches the join point. For example:
after() : set() { Display.update(); }
This effectively specifies: "if the set() pointcut matches the join point, run the code Display.update() after the join point completes." Aspect-oriented programming 16
Other potential join point models There are other kinds of JPMs. All advice languages can be defined in terms of their JPM. For example, a hypothetical aspect language for UML may have the following JPM: • Join points are all model elements. • Pointcuts are some boolean expression combining the model elements. • The means of affect at these points are a visualization of all the matched join points.
Inter-type declarations Inter-type declarations provide a way to express crosscutting concerns affecting the structure of modules. Also known as open classes, this enables programmers to declare in one place members or parents of another class, typically in order to combine all the code related to a concern in one aspect. For example, if a programmer implemented the crosscutting display-update concern using visitors instead, an inter-type declaration using the visitor pattern might look like this in AspectJ:
aspect DisplayUpdate { void Point.acceptVisitor(Visitor v) { v.visit(this); } // other crosscutting code... }
This code snippet adds the acceptVisitor method to the Point class. It is a requirement that any structural additions be compatible with the original class, so that clients of the existing class continue to operate, unless the AOP implementation can expect to control all clients at all times.
Implementation AOP programs can affect other programs in two different ways, depending on the underlying languages and environments: 1. a combined program is produced, valid in the original language and indistinguishable from an ordinary program to the ultimate interpreter 2. the ultimate interpreter or environment is updated to understand and implement AOP features. The difficulty of changing environments means most implementations produce compatible combination programs through a process known as weaving - a special case of program transformation. An aspect weaver reads the aspect-oriented code and generates appropriate object-oriented code with the aspects integrated. The same AOP language can be implemented through a variety of weaving methods, so the semantics of a language should never be understood in terms of the weaving implementation. Only the speed of an implementation and its ease of deployment are affected by which method of combination is used. Systems can implement source-level weaving using preprocessors (as C++ was implemented originally in CFront) that require access to program source files. However, Java's well-defined binary form enables bytecode weavers to work with any Java program in .class-file form. Bytecode weavers can be deployed during the build process or, if the weave model is per-class, during class loading. AspectJ started with source-level weaving in 2001, delivered a per-class bytecode weaver in 2002, and offered advanced load-time support after the integration of AspectWerkz in 2005. Any solution that combines programs at runtime has to provide views that segregate them properly to maintain the programmer's segregated model. Java's bytecode support for multiple source files enables any debugger to step through a properly woven .class file in a source editor. However, some third-party decompilers cannot process Aspect-oriented programming 17
woven code because they expect code produced by Javac rather than all supported bytecode forms (see also "Problems", below). Deploy-time weaving offers another approach.[8] This basically implies post-processing, but rather than patching the generated code, this weaving approach subclasses existing classes so that the modifications are introduced by method-overriding. The existing classes remain untouched, even at runtime, and all existing tools (debuggers, profilers, etc.) can be used during development. A similar approach has already proven itself in the implementation of many Java EE application servers, such as IBM's WebSphere.
Terminology Standard terminology used in Aspect-oriented programming may include: Cross-cutting concerns Even though most classes in an OO model will perform a single, specific function, they often share common, secondary requirements with other classes. For example, we may want to add logging to classes within the data-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even though each class has a very different primary functionality, the code needed to perform the secondary functionality is often identical. Advice This is the additional code that you want to apply to your existing model. In our example, this is the logging code that we want to apply whenever the thread enters or exits a method. Pointcut This is the term given to the point of execution in the application at which cross-cutting concern needs to be applied. In our example, a pointcut is reached when the thread enters a method, and another pointcut is reached when the thread exits the method. Aspect The combination of the pointcut and the advice is termed an aspect. In the example above, we add a logging aspect to our application by defining a pointcut and giving the correct advice.
Comparison to other programming paradigms Aspects emerged out of object-oriented programming and computational reflection. AOP languages have functionality similar to, but more restricted than metaobject protocols. Aspects relate closely to programming concepts like subjects, mixins, and delegation. Other ways to use aspect-oriented programming paradigms include Composition Filters and the hyperslices approach. Since at least the 1970s, developers have been using forms of interception and dispatch-patching that resemble some of the implementation methods for AOP, but these never had the semantics that the crosscutting specifications provide written in one place. Designers have considered alternative ways to achieve separation of code, such as C#'s partial types, but such approaches lack a quantification mechanism that allows reaching several join points of the code with one declarative statement. Aspect-oriented programming 18
Adoption issues Programmers need to be able to read code and understand what is happening in order to prevent errors.[9] Even with proper education, understanding crosscutting concerns can be difficult without proper support for visualizing both static structure and the dynamic flow of a program. Beginning in 2002, AspectJ began to provide IDE plug-ins to support the visualizing of crosscutting concerns. Those features, as well as aspect code assist and refactoring are now common. Given the power of AOP, if a programmer makes a logical mistake in expressing crosscutting, it can lead to widespread program failure. Conversely, another programmer may change the join points in a program – e.g., by renaming or moving methods – in ways that the aspect writer did not anticipate, with unintended consequences. One advantage of modularizing crosscutting concerns is enabling one programmer to affect the entire system easily; as a result, such problems present as a conflict over responsibility between two or more developers for a given failure. However, the solution for these problems can be much easier in the presence of AOP, since only the aspect need be changed, whereas the corresponding problems without AOP can be much more spread out.
Implementations The following programming languages have implemented AOP, within the language, or as an external library: • .NET Framework languages (C# / VB.NET)[10] • AutoHotkey[11] • C / C++[12] • COBOL[13] • The Cocoa Objective-C frameworks[14] • ColdFusion[15] • Common Lisp[16] • Delphi[17] [18] • Delphi Prism [19] • e (IEEE 1647) • Emacs Lisp[20] • Groovy • Haskell[21] • Java[22] • AspectJ • JavaScript[23] • Logtalk [24] • Lua[25] • make[26] • ML[27] • PHP[28] • Racket[29] • Perl[30] • Prolog[31] • Python[32] • Ruby[33] [34] [35] • Squeak Smalltalk[36] [37] • UML 2.0[38] • XML[39] Aspect-oriented programming 19
Notes and references [1] "Aspect-Oriented Programming" "Kiczales, G.; Lamping, J; Mehdhekar, A; Maeda, C; Lopes, C. V.; Loingtier, J; Irwin, J. Proceedings of the European Conference on Object-Oriented Programming (ECOOP), Springer-Verlag LNCS 1241. June 1997." [2] "Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" Karl Liebherr 1996 ISBN 0-534-94602-X presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).
[3] http:/ / web. mit. edu/ dosathena/ sandbox/ emacs-19. 28/ src/ ChangeLog
[4] Don Box; Chris Sells (4 November 2002). Essential.NET: The common language runtime (http:/ / books. google. com/
books?id=Kl1DVZ8wTqcC& pg=PA206). Addison-Wesley Professional. p. 206. ISBN 978-0-201-73411-9. . Retrieved 4 October 2011.
[5] Roman, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 January 2005). Mastering Enterprise JavaBeans (http:/ / books. google. com/
books?id=60oym_-uu3EC& pg=PA285). John Wiley and Sons. p. 285. ISBN 978-0-7645-8492-3. . Retrieved 4 October 2011. [6] Note: The examples in this article appear in a syntax that resembles that of the Java language.
[7] Emacs documentation (http:/ / www. gnu. org/ software/ emacs/ elisp/ html_node/ Advising-Functions. html)
[8] http:/ / www. forum2. org/ tal/ AspectJ2EE. pdf
[9] Edsger Dijkstra, Notes on Structured Programming (http:/ / www. cs. utexas. edu/ users/ EWD/ ewd02xx/ EWD249. PDF), pg. 1-2
[10] Numerous: Afterthought (https:/ / github. com/ vc3/ Afterthought), LOOM.NET (http:/ / www. rapier-loom. net/ ), Enterprise Library 3.0
Policy Injection Application Block (http:/ / www. codeplex. com/ entlib), AspectDNG (http:/ / sourceforge. net/ projects/ aspectdng/ ),
Aspect# (http:/ / www. castleproject. org/ aspectsharp/ ), Compose* (http:/ / composestar. sourceforge. net/ ), PostSharp (http:/ / www.
postsharp. org/ ), Seasar.NET (http:/ / www. seasar. org/ en/ dotnet/ ), DotSpect (.SPECT) (http:/ / dotspect. tigris. org/ ), Spring.NET (http:/ /
www. springframework. net/ ) (as part of its functionality), Wicca and Phx.Morph (http:/ / www. cs. columbia. edu/ ~eaddy/ wicca), SetPoint
(http:/ / setpoint. codehaus. org/ )
[11] Function Hooks (http:/ / www. autohotkey. com/ forum/ viewtopic. php?p=243426)
[12] Several: AspectC++, XWeaver project (http:/ / www. xweaver. org/ ), FeatureC++ (http:/ / wwwiti. cs. uni-magdeburg. de/ iti_db/
forschung/ fop/ featurec/ ), AspectC (http:/ / www. cs. ubc. ca/ labs/ spl/ projects/ aspectc. html), AspeCt-oriented C (http:/ / www. aspectc.
net/ ), Aspicere (http:/ / sailhome. cs. queensu. ca/ ~bram/ aspicere/ index. html)
[13] Cobble (http:/ / homepages. vub. ac. be/ ~kdeschut/ cobble/ )
[14] AspectCocoa (http:/ / www. ood. neu. edu/ aspectcocoa/ )
[15] ColdSpring (http:/ / www. coldspringframework. org/ )
[16] AspectL (http:/ / common-lisp. net/ project/ closer/ aspectl. html)
[17] InfraAspect (http:/ / code. google. com/ p/ infra/ )
[18] MeAOP in MeSDK (http:/ / code. google. com/ p/ meaop/ )
[19] RemObjects Cirrus (http:/ / prismwiki. codegear. com/ en/ Cirrus)
[20] Emacs Advice Functions (http:/ / www. gnu. org/ software/ emacs/ elisp/ html_node/ Advising-Functions. html)
[21] monad (functional programming), Monads As a theoretical basis for AOP (http:/ / citeseerx. ist. psu. edu/ viewdoc/ summary?doi=10. 1. 1.
25. 8262), and Aspect-oriented programming with type classes. (http:/ / portal. acm. org/ citation. cfm?id=1233842)
[22] Numerous others: CaesarJ (http:/ / www. caesarj. org/ ), Compose* (http:/ / composestar. sourceforge. net/ ), Dynaop (http:/ / dynaop. dev.
java. net/ ), JAC (http:/ / jac. objectweb. org/ ), Google Guice (as part of its functionality), Javassist (http:/ / www. csg. is. titech. ac. jp/
~chiba/ javassist/ ), JAsCo (and AWED) (http:/ / ssel. vub. ac. be/ jasco/ ), JAML (http:/ / www. ics. uci. edu/ ~trungcn/ jaml/ ), JBoss AOP
(http:/ / labs. jboss. com/ portal/ jbossaop), LogicAJ (http:/ / roots. iai. uni-bonn. de/ research/ logicaj), Object Teams (http:/ / www.
objectteams. org/ ), PROSE (http:/ / prose. ethz. ch/ ), The AspectBench Compiler for AspectJ (abc) (http:/ / www. aspectbench. org/ ), Spring
framework (as part of its functionality), Seasar, The JMangler Project (http:/ / roots. iai. uni-bonn. de/ research/ jmangler/ ), InjectJ (http:/ /
injectj. sourceforge. net/ ), GluonJ (http:/ / www. csg. is. titech. ac. jp/ projects/ gluonj/ ), Steamloom (http:/ / www. st. informatik.
tu-darmstadt. de/ static/ pages/ projects/ AORTA/ Steamloom. jsp)
[23] Many: Advisable (http:/ / i. gotfresh. info/ 2007/ 12/ 7/ advised-methods-for-javascript-with-prototype/ ), Ajaxpect (http:/ / code. google.
com/ p/ ajaxpect/ ), jQuery AOP Plugin (http:/ / plugins. jquery. com/ project/ AOP), Aspectes (http:/ / aspectes. tigris. org/ ), AspectJS (http:/
/ www. aspectjs. com/ ), Cerny.js (http:/ / www. cerny-online. com/ cerny. js/ ), Dojo Toolkit (http:/ / dojotoolkit. org/ ), Humax Web
Framework (http:/ / humax. sourceforge. net/ ), Joose (http:/ / code. google. com/ p/ joose-js/ ), Prototype - Prototype Function#wrap (http:/ /
www. prototypejs. org/ api/ function/ wrap), YUI 3 (Y.Do) (http:/ / developer. yahoo. com/ yui/ 3/ api/ Do. html) [24] Using built-in support for categories (which allows the encapsulation of aspect code) and event-driven programming (which allows the definition of before and after event handlers).
[25] AspectLua (http:/ / luaforge. net/ projects/ aspectlua/ )
[26] MAKAO (http:/ / sailhome. cs. queensu. ca/ ~bram/ makao/ )
[27] AspectML (http:/ / www. cs. princeton. edu/ sip/ projects/ aspectml/ )
[28] Several: PHPaspect (http:/ / code. google. com/ p/ phpaspect/ ), Aspect-Oriented PHP (http:/ / www. aophp. net/ ), Seasar.PHP (http:/ /
www. seasar. org/ en/ php5/ index. html), PHP-AOP (http:/ / php-aop. googlecode. com/ ), FLOW3 (http:/ / flow3. typo3. org/ )
[29] AspectScheme (http:/ / planet. racket-lang. org/ display. ss?package=aspectscheme. plt& owner=dutchyn)
[30] The Aspect Module (http:/ / search. cpan. org/ dist/ Aspect/ lib/ Aspect. pm)
[31] "Whirl" (http:/ / www. bigzaphod. org/ whirl/ dma/ docs/ aspects/ aspects-man. html) Aspect-oriented programming 20
[32] Several: PEAK (http:/ / peak. telecommunity. com/ ), Aspyct AOP (http:/ / old. aspyct. org), Lightweight Python AOP (http:/ / www. cs. tut.
fi/ ~ask/ aspects/ aspects. html), Logilab's aspect module (http:/ / www. logilab. org/ projects/ aspects), Pythius (http:/ / pythius. sourceforge.
net/ ), Spring Python's AOP module (http:/ / springpython. webfactional. com/ reference/ html/ aop. html), Pytilities' AOP module (http:/ /
pytilities. sourceforge. net/ doc/ 1. 1. 0/ guide/ aop/ )
[33] AspectR (http:/ / aspectr. sourceforge. net/ )
[34] AspectR-Fork (http:/ / aspectr-fork. sourceforge. net/ )
[35] Aquarium (http:/ / aquarium. rubyforge. org/ )
[36] AspectS (http:/ / www. prakinf. tu-ilmenau. de/ ~hirsch/ Projects/ Squeak/ AspectS/ )
[37] MetaclassTalk (http:/ / csl. ensm-douai. fr/ MetaclassTalk)
[38] WEAVR (http:/ / www. iit. edu/ ~concur/ weavr)
[39] AspectXML (http:/ / code. google. com/ p/ aspectxml/ )
Further reading • Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and
John Irwin (1997). "Aspect-Oriented Programming" (http:/ / citeseerx. ist. psu. edu/ viewdoc/ summary?doi=10.
1. 1. 115. 8660). Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242. The paper generally considered to be the authoritative reference for AOP. • Filman, Robert E.; Tzilla Elrad, Siobhán Clarke, and Mehmet Aksit (2004). Aspect-Oriented Software Development. ISBN 0-321-21976-7. • Pawlak, Renaud; Lionel Seinturier, and Jean-Philippe Retaillé (2005). Foundations of AOP for J2EE Development. ISBN 1-59059-507-6. • Laddad, Ramnivas (2003). AspectJ in Action: Practical Aspect-Oriented Programming. ISBN 1-930110-93-6. • Jacobson, Ivar; and Pan-Wei Ng (2005). Aspect-Oriented Software Development with Use Cases. ISBN 0-321-26888-1.
• Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006 (http:/ / www. cmsdevelopment. com/ en/
articles/ aosdinphp/ ) • Clarke, Siobhán; and Elisa Baniassad (2005). Aspect-Oriented Analysis and Design: The Theme Approach. ISBN 0-321-24674-8. • Yedduladoddi, Raghu (2009). Aspect Oriented Software Development: An Approach to Composing UML Design Models. ISBN 3639120841. • "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
External links
• Eric Bodden's list of AOP tools (http:/ / www. sable. mcgill. ca/ aop. net/ ) in .net framework
• Programming Styles: Procedural, OOP, and AOP (http:/ / www. dreamincode. net/ forums/ blog/ gabehabe/ index. php?showentry=1016)
• Programming Forum: Procedural, OOP, and AOP (http:/ / forum. codecall. net/ java-help/
26210-object-reading-writing. html)
• Aspect-Oriented Software Development (http:/ / aosd. net/ conference), annual conference on AOP
• AOSD Wiki (http:/ / aosd. net/ wiki), Wiki on aspect-oriented software development
• AspectJ Programming Guide (http:/ / www. eclipse. org/ aspectj/ doc/ released/ progguide/ index. html)
• The AspectBench Compiler for AspectJ (http:/ / www. aspectbench. org/ ), another Java implementation
• Series of IBM developerWorks articles on AOP (http:/ / www. ibm. com/ developerworks/ views/ java/
libraryview. jsp?search_by=AOP@work:)
• A detailed series of articles on basics of aspect-oriented programming and AspectJ (http:/ / www. javaworld. com/
javaworld/ jw-01-2002/ jw-0118-aspect. html) Aspect-oriented programming 21
• What is Aspect-Oriented Programming? (http:/ / codefez. com/ what-is-aspect-oriented-programming/ ), introduction with RemObjects Taco
• Constraint-Specification Aspect Weaver (http:/ / www. cis. uab. edu/ gray/ Research/ C-SAW/ )
• Aspect- vs. Object-Oriented Programming: Which Technique, When? (http:/ / www. devx. com/ Java/ Article/ 28422)
• Gregor Kiczales, Professor of Computer Science, explaining AOP (http:/ / video. google. com/
videoplay?docid=8566923311315412414& q=engEDU), video 57 min.
• Aspect Oriented Programming in COBOL (http:/ / database. ittoolbox. com/ documents/ academic-articles/ what-does-aspectoriented-programming-mean-to-cobol-4570)
• Aspect-Oriented Programming in Java with Spring Framework (http:/ / static. springframework. org/ spring/ docs/
2. 0. x/ reference/ aop. html)
• Wiki dedicated to AOP methods on.NET (http:/ / www. sharpcrafters. com/ aop. net)
• AOP considered harmful (Forrester) (http:/ / www. forrester. com/ Research/ Document/ Excerpt/
0,7211,36794,00. html)
• Early Aspects for Business Process Modeling (An Aspect Oriented Language for BPMN) (http:/ / dssg. cs. umb.
edu/ wiki/ index. php/ Early_Aspects_for_Business_Process_Modeling)
• AOSD Graduate Course at Bilkent University (http:/ / www. cs. bilkent. edu. tr/ ~bedir/ CS586-AOSD)
• Introduction to AOP - Software Engineering Radio Podcast Episode 106 (http:/ / www. se-radio. net/ podcast/
2008-08/ episode-106-introduction-aop)
• An Objective-C implementation of AOP by Szilveszter Molnar (http:/ / innoli. com/ en/ Innoli-EN/ OpenSource. html)
• Apect-Oriented programming for iOS and OS X by Manuel Gebele (https:/ / github. com/ mgebele/ MGAOP) 22
Concepts
Aspect
In computer science, an aspect of a program is a feature linked to many other parts of the program, but which is not related to the program's primary function. An aspect crosscuts the program's core concerns, therefore violating its separation of concerns that tries to encapsulate unrelated functions. For example, logging code can crosscut many modules, yet the aspect of logging should be separate from the functional concerns of the module it cross-cuts. Isolating such aspects as logging and persistence from business logic is the aim of aspect-oriented software development (AOSD), of which the aspect-oriented programming (AOP) paradigm is the most widely employed.[1] Aspect-orientation is not limited to programming since it is useful to identify, analyse, trace and modularise concerns (e.g., PREview) through requirements elicitation, specification and design. Aspects can be multi-dimensional by allowing both functional and non-functional behaviour to crosscut any other concerns, instead of just mapping non-functional concerns to functional requirements. One view of aspect-oriented software development is that every major feature of the program, core concern (business logic), or cross-cutting concern (additional features), is an aspect, and by weaving them together (a process also called composition), one finally produces a whole out of the separate aspects. This approach is known as pure aspect programming, but hybrid approaches are more commonly used, perhaps since there is less of a paradigm shift between object- and aspect-oriented programming. There is a similar situation with early aspect software development (e.g., requirements), with traditional methods being enhanced for aspect-orientation and new models proposed. Non-functional concerns (e.g., security) can crosscut functional concerns (e.g., door must be present). It is possible for functional concerns to crosscut non-functional or functional concerns (e.g., need for more features harms mobility). A uniform approach to representation and composition, similar to the pure approach in AOP, is termed multidimensional representation. The prism analogy describes aspects with terms from the domain of light. Like splitting light into its many aspects (different colours) with a prism, one splits a problem into its separate aspects. With another prism you can put the different colours back into a white ray of light, and by the process of weaving aspects one can put the solutions for the different aspects of a problem back into a solution for the whole problem.
References
[1] Awais Rashid (2004). Aspect-Oriented Database Systems. Springer. ISBN 3540009485. Advice 23 Advice
In aspect and functional programming, advice describes a class of functions which modify other functions when the latter are run; it is a certain function, method or procedure that is to be applied at a given join point of a program. The following is taken from a discussion at the mailing list aosd-discuss [1]. Pascal Costanza contributed the following: The term advice goes back to the term advising as introduced by Warren Teitelman in his PhD thesis in 1966. Here is a quote from Chapter 3 of his thesis: Advising is the basic innovation in the model, and in the PILOT system. Advising consists of inserting new procedures at any or all of the entry or exit points to a particular procedure (or class of procedures). The procedures inserted are called "advice procedures" or simply "advice". Since each piece of advice is itself a procedure, it has its own entries and exits. In particular, this means that the execution of advice can cause the procedure that it modifies to be bypassed completely, e.g., by specifying as an exit from the advice one of the exits from the original procedure; or the advice may change essential variables and continue with the computation so that the original procedure is executed, but with modified variables. Finally, the advice may not alter the execution or affect the original procedure at all, e.g., it may merely perform some additional computation such as printing a message or recording history. Since advice can be conditional, the decision as to what is to be done can depend on the results of the computation up to that point. The principal advantage of advising is that the user need not be concerned about the details of the actual changes in his program, nor the internal representation of advice. He can treat the procedure to be advised _as a unit_, a single block, and make changes to it without concern for the particulars of this block. This may be contrasted with editing in which the programmer must be cognizant of the internal structure of the procedure. "Advising" found its way into BBN Lisp and later into Xerox PARC's Interlisp. It also found its way to Flavors, the first object-oriented extension to Lisp developed at MIT. They were subsumed
under the notion of method combination. See, for example, AIM-602 at http:/ / www. ai. mit. edu/ research/ 1 publications/ browse/ 0600browse. shtml Since method combination and macros are closely related, it's also interesting to note that the first macro system was
described in 1963, three years before Warren Teitelman's PhD thesis. See AIM-57 at http:/ / www. ai. mit. edu/ 2 research/ publications/ browse/ 0000browse. shtml
Use The practical use of advice functions is generally to modify or otherwise extend the behavior of functions which cannot be easily modified or extended. The Emacspeak Emacs-addon makes extensive use of advice: it must modify thousands of existing Emacs modules and functions such that it can produce audio output for the blind corresponding to the visual presentation, but it would obviously be infeasible to copy all of them and redefine them to produce audio output in addition to their normal outputs; so, the Emacspeak programmers define advice functions which run before and after. Another Emacs example; suppose after one corrected a misspelled word through ispell, one wanted to re-spellcheck the entire buffer. ispell-word offers no such functionality, even if the spellchecked word is used a thousand times. One could track down the definition of ispell-word, copy it into one's .emacs, and write the additional functionality, but this is tedious, prone to broken-ness (the .emacs version will get out of sync with the actual Ispell Elisp module, if it even works out of its home). What one wants is fairly simple: just to run another command after Advice 24
ispell-word runs. Using advice functions, it can be done as simply as this:
(defadvice ispell (after advice) (flyspell-buffer))
(ad-activate 'ispell t)
Notes Gregor Kiczales comments the above as follows: 1. Advice appeared separately from Flavors in Maclisp and the Lisp Machine. You could advise any function, just like in Interlisp at the time. The before/after ontology appeared separately in Flavors methods. 2. Method combination and macros were only marginally related until much later, in New Flavors and CLOS, when a macro-like mechanism was provided to allow people to define their own rules for combining methods. Prior to that the rules governing combination of before/after methods and so-called whoppers methods (around) was fixed, and the compiler just generated the code for that. There were things called wrappers, which had macro-like behavior, but I forget when they came around. Traipsing through the various versions of MacLisp and Lispm manual to get this part of the history exactly right could interesting. Or it could be that Howard Cannon or David Moon or someone could actually remember it all exactly.
External links • Teitelman's PhD thesis [2] (AITR-221) • InterLisp reference manual [3] • "Origin of Advice" [4]
References
[1] http:/ / aosd. net/ pipermail/ discuss_aosd. net/ 2004-November/ 001173. html
[2] http:/ / www. ai. mit. edu/ research/ publications/ browse/ 0200browse. shtml
[3] http:/ / www. classiccmp. org/ bitsavers/ pdf/ xerox/ interlisp/ 1974_InterlispRefMan. pdf
[4] http:/ / p-cos. blogspot. com/ 2007/ 12/ origin-of-advice. html Join point 25 Join point
In computer science, a join point is a point in the control flow of a program. In aspect-oriented programming a set of join points is described as a pointcut. A join point is a specification of when, in the corresponding main program, the aspect code should be executed. The join point is a point of execution in the base code where the advice specified in a corresponding pointcut is applied. Conceptually, a join point exists where a precondition for a command in Hoare logic makes an assertion parametric upon the joint and several advice supplied by the different concerns at that point in a generalized abstract process, the unified thing composed from its concrete aspects being the pointcut.
Pointcut
In aspect-oriented computer programming, a pointcut is a set of join points. Whenever the program execution reaches one of the join points described in the pointcut, a piece of code associated with the pointcut (called advice) is executed. This allows a programmer to describe where and when additional code should be executed in addition to an already defined behavior. This permits the addition of aspects to existing software, or the design of software with a clear separation of concerns, wherein the programmer weaves (merges) different aspects into a complete application.
External links • Paper "A Classification of Pointcut Language Constructs [1]" by Maximilian Störzer and Stefan Hanenberg • Paper "Back to the Future: Pointcuts as Predicates over Traces [2]" by Karl Klose and Klaus Ostermann • Paper "Inductively Generated Pointcuts to Support Refactoring to Aspects [3]" by Tom Tourwé, Andy Kellens, Wim Vanderperren and Frederik Vannieuwenhuyse • Paper "Remote Pointcut - A Language Construct for Distributed AOP [4]" by Muga Nishizawa, Shigeru Chiba and Michiaki Tatsubori • Paper "Datalog as a Pointcut Language in Aspect-Oriented Programming [5]" • Paper "Expressiveness and Complexity of Crosscut Languages [6]" by Karl J. Lieberherr, Jeffrey Palm and Ravi Sundaram
References
[1] http:/ / www. infosun. fim. uni-passau. de/ st/ papers/ splat05/
[2] http:/ / en. scientificcommons. org/ 43200024
[3] http:/ / citeseer. ist. psu. edu/ 710677. html
[4] http:/ / citeseer. comp. nus. edu. sg/ 709927. html
[5] http:/ / progtools. comlab. ox. ac. uk/ publications/ oopsla06abc
[6] http:/ / www. ccs. neu. edu/ research/ demeter/ biblio/ unified. html Aspect weaver 26 Aspect weaver
Aspect weaver
An aspect weaver takes information from raw classes and aspects and creates new classes with the aspect code appropriately weaved into the classes. Usage
Paradigm Aspect-oriented programming
Language(s) AspectC++, AspectJ
An aspect weaver is a metaprogramming utility for aspect-oriented languages designed to take instructions specified by aspects (isolated representations of a significant concepts in a program) and generate the final implementation code. The weaver integrates aspects into the locations specified by the software as a pre-compilation step. By merging aspects and classes (representations of the structure of entities in the program), the weaver generates either a woven class (which can then be compiled into bytecode) or woven bytecode directly. Aspect weavers take instructions known as advice specified through the use of pointcuts and join points, special segments of code that indicate what methods should be handled by aspect code. The implementation of the aspect then specifies whether the related code should be added before, after, or throughout the related methods. By doing this, aspect weavers improve modularity, keeping code in one place that would otherwise have been interspersed throughout various, unrelated classes.
Motivation Many programming languages are already widely accepted and understood. However, the desire to create radically different programming languages to support the aspect-oriented programming paradigm is not significant due to business-related concerns; there are risks associated with adopting new technologies.[1] Use of an entirely new language relies on a business's ability to acquire new developers. Additionally, the existing code base of a business would need to be discarded. Finally, a business would need to acquire a new toolchain (suite of tools) for development, which is often both an expense in both money and time.[2] Primary concerns about roadmaps for the adoption of new technologies tend to be the need to train new developers and adapt existing processes to the new technology.[3] To address these business concerns, an aspect weaver enables the use of widely adopted languages like Java with aspect-oriented programming through minor adaptations such as AspectJ which work with existing tools.[4] Instead of developing an entirely new language, the aspect weaver interprets the extensions defined by AspectJ and builds "woven" Java code which can then be used by any existing Java compiler. This ensures that any existing object oriented code will still be valid aspect-oriented code and that development will feel like a natural extension of the object-oriented language.[5] The AspectC++ programming language extends C++ through the use of an aspect Aspect weaver 27
weaver, offering the additional efficiency over AspectJ that is necessary for embedded systems while still retaining the benefits of aspect-oriented programming.[6]
Implementation Aspect weavers operate by taking instructions specified by aspects, known as advice, and distributing it throughout the various classes in the program automatically. The result of the weaving process is a set of classes with the same names as the original classes but with additional code injected into the classes' functions automatically. The advice specifies the exact location and functionality of the injected code.[7] Through this weaving process, aspect weavers allow for code which would have otherwise been duplicated across classes. By eliminating this duplication, aspect weavers promote modularity of cross-cutting concerns.[8] Aspects define the implementation code which would have otherwise been duplicated and then use pointcuts and join points to define the advice. During weaving, the aspect weaver uses the pointcuts and join points, known as a pointcut designator, to identify the positions in candidate classes at which the implementation should be injected.[9] The implementation is then injected into the classes at the points identified, thus permitting the code to be executed at the appropriate times without relying on manual duplication by the programmer.[10]
aspect Logger { pointcut method() : execution(* *(..)); before() : method() { System.out.println("Entering " + thisJoinPoint.getSignature().toString()); } after() : method() { System.out.println("Leaving " + thisJoinPoint.getSignature().toString()); } } public class Foo { public void bar() { System.out.println("Executing Foo.bar()"); } public void baz() { System.out.println("Executing Foo.baz()"); } }
A sample aspect and class defined in the AspectJ programming language public class Foo { public void bar() { System.out.println("Entering Foo.bar()"); System.out.println("Executing Foo.bar()"); System.out.println("Leaving Foo.bar()"); } public void baz() { System.out.println("Entering Foo.baz()"); System.out.println("Executing Foo.baz()"); System.out.println("Leaving Foo.baz()"); } } The woven class that results from executing an aspect weaver on the above sample Aspect weaver 28
Weaving in AspectJ In the programming language AspectJ, pointcuts, join points, and the modularized code are defined in an aspect block similar to that of Java classes. Classes are defined using Java syntax. The weaving process consists of executing the aspect advice to produce only a set of generated classes that have the aspect implementation code woven into it.[11] The example at right shows a potential implementation of an aspect which logs the entry and exit of all methods. Without an aspect weaver, this feature would necessitate duplication of code in the class for every method. Instead, the entry and exit code is defined solely within the aspect.[12] The aspect weaver analyzes the advice specified by the pointcut in the aspect and uses that advice to distribute the implementation code into the defined class. The code differs slightly in each method due to slight variances in requirements for the method (as the method identifier has changed). The aspect weaver determines the appropriate code to generate in each situation as defined by the implementation advice and then injects it into methods matching the specified pointcut.[13]
Weaving to bytecode Instead of generating a set of woven source code, some AspectJ weavers instead weave the aspects and classes together directly into bytecode, acting both as the aspect weaver and compiler.[14] [15] While it is expected that the performance of aspect weavers which also perform the compilation process will require more computation time due to the weaving process involved, it is also expected that this performance can be improved as aspect weavers' compiler implementations are relatively new, while traditional compilers have been thoroughly tested and optimized.[16]
Run-time weaving Developments in AspectJ have revealed the potential to incorporate just-in-time compilation into the execution of aspect-oriented code to address performance demands.[17] At run-time, an aspect weaver could translate aspects in a more efficient manner than traditional, static weaving approaches. Using AspectJ on a Java Virtual Machine, dynamic weaving of aspects at run-time has been shown to improve code performance by 26%.[18] While some implementations of just-in-time virtual machines implement this capability through a new virtual machine, some implementations can be designed to use features that already exist in current virtual machines.[19] [20] The requirement of a new virtual machine is contrary to one of the original design goals of AspectJ.[5] To accomplish just-in-time weaving, a change to the virtual machine that executes the compiled bytecode is necessary. A proposed solution for AspectJ uses a layered approach which builds upon the existing Java Virtual Machine to add support for join point management and callbacks to a Dynamic Aspect-Oriented Programming Engine.[20] An alternative implementation uses a weaving engine that uses breakpoints to halt execution at the pointcut, select an appropriate method, embed it into the application, and continue.[21] The use of breakpoints in this manner has been shown to reduce performance due to a very large number of context switches.[18]
Performance Aspect weavers' performance, as well as the performance of the code that they produce, has been a subject of analysis. It is preferable that the improvement in modularity supplied by aspect weaving does not impact run-time performance. Aspect weavers are able to perform aspect-specific optimizations.[22] While traditional optimizations such as the elimination of unused special variables from aspect code can be done at compile-time, some optimizations can only be performed by the aspect weaver. For example, AspectJ contains two similar but distinct keywords, thisJoinPoint, which contains information about this particular instance of woven code, and thisJoinPointStaticPart, which contains information common to all instances of code relevant to that set Aspect weaver 29
of advice. The optimization of replacing thisJoinPoint with the more efficient and static keyword thisJoinPointStaticPart can only be done by the aspect weaver. By performing this replacement, the woven program avoids the creation of a join point object on every execution.[14] Studies have shown that the unnecessary creation of join point objects in AspectJ can lead to a performance overhead of 5% at run-time, while performance degradation is only approximately 1% when this object is not created.[23] Compile-time performance is generally worse in aspect weavers than their traditional compiler counterparts due to the additional work necessary for locating methods which match the specified pointcuts. A study done showed that the AspectJ compiler ajc is about 34% slower than the Sun Microsystems Java 1.3 compiler and about 62% slower than the Java 1.4 compiler.[16]
References [1] Kiczales (October 2001), p.2 [2] Kiczales (October 2001), p.7 [3] Colyer (2003), p.6 [4] Kiczales (October 2001), p.5 [5] Kiczales (June 2001), p.3 [6] Spinczyk (2002), p.1 [7] Wand (2004), p.1 [8] Wand (2004), p.7 [9] Viega (November 2000), p.2 [10] Spinczyk (October 2007), p.21 [11] Wang (July 2007), p.4 [12] Avgustinov (2007), p.2 [13] Hilsdale (2004), pp.5–6 [14] Hilsdale (2004), p.2 [15] McEachen (2005), p.1 [16] Hilsdale (2004), p.7 [17] Popovici (2003), p.1 [18] Sato (September 2003), p.17 [19] Sato (September 2003), p.2 [20] Papovici (2003), p.3 [21] Sato (September 2003), p.11 [22] Gal (2001), p.3 [23] Colyer (2003), p.2
Bibliography • Avgustinov, Pavel; Hajiyev, Elnar; Ongkingco, Neil; de More, Oege; Sereni, Damien; Tibble, Julian; Verbaere, Mathieu (2007). "Semantics of Static Pointcuts in AspectJ". Proceedings of the 34th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (ACM): 11–23. doi:10.1145/1190216.1190221. • Colyer, Adrian; Clement, Andy; Bodkin, Ron; Hugunin, Jim (2003). "Using AspectJ for Component Integration
in Middleware" (http:/ / wwwx. cs. unc. edu/ ~lee/ docs/ pra03-colyer. pdf) (PDF). Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications: 339–344. doi:10.1145/949344.949440. Retrieved 23 January 2009. • Gal, Andreas; Schröder-Preikschat, Wolfgang; Spinczyk, Olaf (2001). "On Minimal Overhead Operating Systems
andAspect-Oriented Programming" (http:/ / fusion. cs. uni-magdeburg. de/ pubs/ ecoop2001. pdf) (PDF). Proceedings of the 4th Workshop on Object-Orientation and Operating Systems at the 15th European Conference on Object-Oriented Programming (ECOOP-OOOSW). Retrieved 27 January 2010.
• Hilsdale, Erik; Hugunin, Jim (2004). "Advice Weaving in AspectJ" (http:/ / www. daimi. au. dk/ ~eernst/
aosdF06/ papers/ AJWeaving. pdf) (PDF). Proceedings of the 3rd international conference on Aspect-oriented software development (ACM): 24–35. doi:10.1145/976270.976276. Retrieved 23 January 2009. Aspect weaver 30
• Kiczales, Gregor; Hilsdale, Erik; Hugunin, Jim; Kersten, Mik; Palm, Jeffrey; Griswold, William (October 2001). "Getting Started with AspectJ". Communications of the ACM (ACM) 44 (10): 59–65. doi:10.1145/383845.383858. • Kiczales, Gregor; Hilsdale, Erik; Hugunin, Jim; Kersten, Mik; Palm, Jeffery; Griswold, William G. (June 2001).
"An Overview of AspectJ" (http:/ / kerstens. org/ mik/ publications/ aspectj-ecoop2002. pdf) (PDF). Proceedings of the European Conference on Object-Oriented Programming 2072: 327–354. doi:10.1007/3-540-45337-7_18. Retrieved 4 January 2010. • McEachen, Nathan; Alexander, Roger (2005). "Distributing Classes with Woven Concerns – An Exploration of Potential Fault Scenarios". Proceedings of the 4th International Conference on Aspect-Oriented Software Development (ACM): 192–200. doi:10.1145/1052898.1052915. • Popovici, Andrei; Alonso, Gustavo; Gross, Thomas (2003). "Just-In-Time Aspects: Efficient Dynamic Weaving for Java". Proceedings of the 2nd International Conference on Aspect-Oriented Software Development (ACM): 100 109. doi:10.1145/643603.643614. • Sato, Yoshiki; Chiba, Shigeru; Tatsubori, Michiaki (September 2003). "A Selective, Just-In-Time Aspect
Weaver" (http:/ / www. csg. is. titech. ac. jp/ paper/ yoshiki-gpce03. pdf) (PDF). Proceedings of the 2nd international conference on Generative programming and component engineering: 189–208. Retrieved 4 January 2010. • Spinczyk, Olaf; Gal, Andreas; Schröder-Preikschat, Wolfgang (2002). "AspectC++: An Aspect-Oriented
Extension to the C++ Programming Language" (http:/ / www. acs. org. au/ documents/ public/ crpit/
CRPITV10Spinczyk. pdf) (PDF). Proceedings of the Fortieth International Conference on Tools Pacific 21: 53–60. Retrieved 4 January 2010.
• Spinczyk, Olaf; Lohmann, Daniel (October 2007). "The design and implementation of AspectC++" (http:/ /
www4. informatik. uni-erlangen. de/ Publications/ 2007/ spinczyk_07_knosys. pdf) (PDF). Knowledge-Based Systems 20 (7): 636–651. doi:10.1016/j.knosys.2007.05.004. Retrieved 23 January 2010. • Viega, John; Voas, Jeffrey (November 2000). "Can Aspect-Oriented Programming lead to More Reliable Software?". IEEE Software 17 (6): 19–21. doi:10.1109/52.895163. • Wand, Michael; Kiczales, Gregor; Dutchyn, Christopher (2004). "A semantics for advice and dynamic join points
in aspect-oriented programming" (http:/ / reference. kfupm. edu. sa/ content/ s/ e/
a_semantics_for_advice_and_dynamic_join__97028. pdf) (PDF). ACM Transactions on Programming Languages and Systems (TOPLAS) (ACM): 890–910. Retrieved 23 January 2009.
• Wang, Yi; Zhao, Jianjun (July 2007). "Specifying Pointcuts in AspectJ" (http:/ / cse. sjtu. edu. cn/ ~zhao/ pub/
pdf/ aoasia07. pdf) (PDF). Proceedings of the 21st Annual International Computer Software and Applications Conference 2: 5–10. doi:10.1109/COMPSAC.2007.196. Retrieved 23 January 2010.
Further reading • Suzuki, Junichi; Yamamoto, Yoshikazu (June 1999). Moreira, A. M.; Demeyer, Moreira. eds. "Extending UML
with Aspects: Aspect Support in the Design Phase" (http:/ / www. imamu. edu. sa/ DContent/ IT_Topics/ Aspect
Support in the Design Phase. pdf) (PDF). Proceedings of the Workshop on Object-Oriented Technology 1743: 299–300. Retrieved 4 January 2010. Cross-cutting concern 31 Cross-cutting concern
In computer science, cross-cutting concerns are aspects of a program which affect other concerns. These concerns often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and can result in either scattering (code duplication), tangling (significant dependencies between systems), or both. For instance, if writing an application for handling medical records, the bookkeeping and indexing of such records is a core concern, while logging a history of changes to the record database or user database, or an authentication system, would be cross-cutting concerns since they touch more parts of the program.
Background Cross-cutting concerns are parts of a program which rely on or must affect many other parts of the system. They form the basis for the development of aspects.[1] Such cross-cutting concerns do not fit cleanly into object-oriented programming or procedural programming.[2] Cross-cutting concerns can be directly responsible for tangling, or system inter-dependencies, within a program. Because procedural and functional language constructs consist entirely of procedure calling, there is no semantic through which two goals (the capability to be implemented and the related cross-cutting concern) can be addressed simultaneously.[3] As a result, the code addressing the cross-cutting concern must be scattered, or duplicated, across the various related locations, resulting in a loss of modularity. [2] Aspect-oriented programming aims to encapsulate cross-cutting concerns into aspects to retain modularity. This allows for the clean isolation and reuse of code addressing the cross-cutting concern.[4] By basing designs on cross-cutting concerns, software engineering benefits are affected, including modularity and simplified maintenance.[5]
Examples Examples of concerns that tend to be crosscutting include: • Synchronization • Real-time constraints • Error detection and correction • Product features • Memory management • Data validation • Persistence • Transaction processing • Internationalization and localization which includes Language localisation • Information security • Caching • Logging • Monitoring • Business rules • Code mobility • Domain-specific optimizations Cross-cutting concern 32
References [1] U.S. Patent 6467086, p.4 [2] Kiczales, p.1 [3] Kiczales, p.6 [4] Kiczales, p.2 [5] Li, p.1
Bibliography • Kiczales, Gregor; Lamping, John; Mendhekar, Anurag; Maeda (1997). "Aspect-Oriented Programming". Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP 1997) (Jyväskylä, Finland): 220–242.
• US patent 6467086 (http:/ / worldwide. espacenet. com/ textdoc?DB=EPODOC& IDX=US6467086), Kiczales et. al, "Aspect-oriented programming", issued 2002-10-15 • Li, Harry; Krishnamurthi, Shriram; Fisler, Kathi (2002). "Verifying Cross-Cutting Features as Open Systems". ACM SIGSOFT Software Engineering Notes 27 (6): 89–98. doi:10.1145/605466.605481.
• Parnas, David L. (December 1972). "On the Criteria To Be Used in Decomposing Systems into Modules" (http:/ /
citeseerx. ist. psu. edu/ viewdoc/ download?doi=10. 1. 1. 90. 8963& rep=rep1& type=pdf) (PDF). Communications of the ACM 15 (12): 1053–1058. doi:10.1145/361598.361623. • Tarr, Peri; Ossher, Harold; Harrison, William; Sutton, Stanley M., Jr. (1999). "N Degrees of Separation: Multi-
Dimensional Separation of Concerns" (http:/ / citeseerx. ist. psu. edu/ viewdoc/ download?doi=10. 1. 1. 89.
1641& rep=rep1& type=pdf) (PDF). Proceedings of the 21st International Conference on Software Engineering (Los Angeles, California, USA: IEEE Computer Society Press): 107–119. doi:10.1109/ICSE.1999.841000.
Further reading • Laddad, R. (2003): AspectJ in Action, Practical Aspect-Oriented Programming, Manning Publications Co.
External links
• AOSD.net's (http:/ / www. aosd. net/ wiki/ index. php?title=Glossary) glossary of aspect oriented terms.
• AspectJ (http:/ / eclipse. org/ aspectj/ ), an Aspect-Oriented extension to the Java programming language
• Bergmans, L., M. Aksit (2001): Composing Multiple Concerns Using Composition Filters, http:/ / trese. cs.
utwente. nl/ (24 July 2004) • Berg, K. van den, Conejero, J. and Chitchyan, R. (2005). AOSD Ontology 1.0 ‐ Public Ontology of
Aspect‐Orientation. AOSD Europe Network of Excellence, retrieved May 2005, from http:/ / www. aosd-europe.
net/ deliverables/ d9. pdf
• Here is an example of handling a cross-cutting concern: http:/ / blogs. captechconsulting. com/ blog/
balaji-muthuvarathan/ persistence-pattern-using-threadlocal-and-ejb-interceptors 33
Languages
AspectJ
AspectJ
Paradigm(s) aspect-oriented
Appeared in 2001
Developer Eclipse Foundation
Stable release 1.6.11 (March 15, 2011)
Major implementations The AspectJ Development Tools for Eclipse
Implementation language Java
OS Cross-platform
License Eclipse Public License
Usual filename extensions aj
Website [1]
AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely-used de-facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.
Simple language description All valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define special constructs called aspects. Aspects can contain several entities unavailable to standard classes. These are: • inter-type declarations—allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. This example adds an acceptVisitor (see visitor pattern) method to the Point class: aspect VisitAspect { void Point.acceptVisitor(Visitor v) { v.visit(this); } }
• pointcuts — allow a programmer to specify join points (well-defined moments in the execution of a program, like method call, object instantiation, or variable access). All pointcuts are expressions (quantifications) that determine whether a given join point matches. For example, this point-cut matches the execution of any instance method in an object of type Point whose name begins with set: pointcut set() : execution(* set*(..) ) && this(Point);
• advice — allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. Here, the advice refreshes the display every time AspectJ 34
something on Point is set, using the pointcut declared above:
after () : set() { Display.update(); }
AspectJ also supports limited forms of pointcut-based static checking and aspect reuse (by inheritance). See the AspectJ Programming Guide [2] for a more detailed description of the language.
AspectJ compatibility and implementations AspectJ has been designed to be implemented in many ways, including source- or bytecode-weaving and directly in the VM (virtual machine). In all cases, the AspectJ program is transformed into a valid Java program run in a Java VM. Any classes affected by aspects are binary-compatible with the unaffected classes (in order to maintain compatibility with any classes that were compiled with the unaffected originals). Supporting multiple implementations allows the language to grow as technology changes, and being Java-compatible ensures platform availability. Key to its success has been engineering and language decisions designed to make the language usable and programs deployable. The original Xerox AspectJ implementation used source weaving, which required access to source code. When Xerox contributed the code to Eclipse, AspectJ was reimplemented using the Eclipse Java compiler and a bytecode weaver based on BCEL, so developers could write aspects for code in binary (.class) form. At this time the AspectJ language was restricted to support a per-class model essential for incremental compilation and load-time weaving. This made IDE integrations as responsive as their Java counterparts, and it enabled developers to deploy aspects without altering the build process. This led to increased adoption, as AspectJ became usable for impatient Java programmers and enterprise-level deployments. Since then, the Eclipse team has increased performance and correctness, upgraded the AspectJ language to support Java 5 language features like generics and annotations, and integrated annotation-style pure-java aspects from AspectWerkz. The Eclipse project supports both command-line and Ant interfaces. A related Eclipse project has steadily improved the Eclipse IDE support (AJDT) for AspectJ and other providers of crosscutting structure. IDE support for emacs, NetBeans, and JBuilder foundered when Xerox put them into open source, but support for Oracle's JDeveloper did appear. IDE support has been key to Java programmers using AspectJ and understanding crosscutting concerns. BEA has offered limited support in a VM for aspect-oriented extensions, but for extensions to be supported in all Java VM's would require agreement through Sun's Java Community Process (see also the java.lang.instrument package available since Java SE 5 which is some kind of common ground for JVM load-time instrumentation). Academic interest in both the semantics and implementation of aspect-oriented languages has surrounded AspectJ since its release. The leading research implementation of AspectJ is the AspectBench Compiler [3], or abc; it supports extensions for changing the syntax and semantics of the language and forms the basis for many AOP experiments that the AspectJ team can no longer support, given its broad user base. Many programmers discover AspectJ as an enabling technology for other projects they use, most notably Spring AOP. A sister Spring project, Spring Roo, automatically maintains AspectJ inter-type declarations as its principal code generation output. AspectJ 35
History and contributors Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT [4] project with Adrian Colyer (current lead of the AspectJ project [5]) and Andrew Clement (current compiler engineer). Jonas Boner and Alex Vasseur engineered the AspectWerkz project, and later contributed to the AspectJ project when it merged in the AspectWerkz annotation style and load-time weaving support. The AspectBench Compiler was developed and is being maintained as a joint effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).
Bibliography • Laddad, Ramnivas (September 28, 2009), AspectJ in Action: Enterprise AOP with Spring (2nd ed.), Manning Publications, pp. 550, ISBN 978-1933988054 • Miles, Russ (December 20, 2004), AspectJ Cookbook [6] (1st ed.), O'Reilly Media, pp. 354, ISBN 978-0596006549 • Colyer, Adrian; Clement, Andy; Harley, George; Webster, Matthew (December 24, 2004), Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools [7] (1st ed.), Addison-Wesley Professional, pp. 504, ISBN 978-0321245878 • Gradecki, Joseph D.; Lesiecki, Nicholas (March 7, 2003), Mastering AspectJ: Aspect-Oriented Programming in Java [8] (1st ed.), Wiley, pp. 456, ISBN 978-0471431046
External links • AspectJ Home Page [5] • Xerox has U.S. Patent 6467086 [9] for AOP/AspectJ, but published AspectJ source code under the Common Public License [10], which grants some patent rights.
• http:/ / www. eclipse. org/ aspectj/ doc/ released/ progguide/ index. html • AJDT [11]
• http:/ / aspectbench. org/
• http:/ / www. ibm. com/ developerworks/ java/ library/ j-aspectj
References
[1] http:/ / www. eclipse. org/ aspectj/
[2] http:/ / www. eclipse. org/ aspectj/ doc/ released/ progguide/ index. html
[3] http:/ / www. aspectbench. org/
[4] http:/ / eclipse. org/ ajdt
[5] http:/ / eclipse. org/ aspectj
[6] http:/ / oreilly. com/ catalog/ 9780596006549/
[7] http:/ / www. informit. com/ store/ product. aspx?isbn=0321245873
[8] http:/ / www. wiley. com/ WileyCDA/ WileyTitle/ productCd-0471431044. html
[9] http:/ / www. google. com/ patents?vid=6467086
[10] http:/ / www. eclipse. org/ legal/ cpl-v10. html
[11] http:/ / www. eclipse. org/ ajdt/ AspectC++ 36 AspectC++
AspectC++ is an aspect-oriented extension of C and C++ languages. It is based on source-to-source translation, translating AspectC++ source code to C++. It is available under the GNU GPL, though some extensions specific to Microsoft Windows are only available through pure-systems GmbH. Aspect-oriented programming allows modularizing cross-cutting concerns in a single module, an aspect. Aspects can modify existing classes, but most commonly they provide 'advice' that runs before, after, or around existing functionality. For example, all calls to a specific function can be traced using an aspect, rather than inserting 'cerr' or print statements in many places:
aspect Tracer { advice call("% %Iter::Reset(...)") : before() { cerr << "about to call Iter::Reset for " << JoinPoint::signature() << endl; } };
The Tracer aspect will print out a message before any call to %Iter::Reset. The %Iter syntax means that it will match all classes that end in Iter. Each 'matched' location in the source code is called a join point -- the advice is joined to (or advises) that code. AspectC++ provides a join point API to provide and access to information about the join point. For example, the function:
JoinPoint::signature()
returns the name of the function (that matched %Iter::Reset) that is about to be called. The join point API also provides compile-time type information that can be used within an aspect to access the type or the value of the arguments and the return type and return value of a method or function.
External links • AspectC++ [1] • Articles on aspect-oriented programming and AspectC++ at past AOSD conferences [2]
References
[1] http:/ / www. aspectc. org/
[2] http:/ / www. aosd. net AspectWerkz 37 AspectWerkz
AspectWerkz is a dynamic, lightweight and high-performance AOP/AOSD framework for Java. It has been merged with the AspectJ project, which supports AspectWerkz functionality since AspectJ 5. Unlike AspectJ prior to version 5, AspectWerkz did not add any new language constructs to Java, but instead supported declaration of aspects within Java annotations. It utilizes bytecode modification to weave classes at project build-time, class load time, as well as runtime. It uses standardized JVM level APIs. Aspects can be defined using either Java 5 annotations, Java 1.3/1.4 custom doclets or a simple XML definition file. AspectWerkz provides an API to use the very same aspects for proxies, hence providing a transparent experience, allowing a smooth transition for users familiar with proxies. AspectWerkz is Free Software. The LGPL-style license allows the use of AspectWerkz 2.0 in both commercial and open source projects.
External links • Project homepage [1]
http:/ / aspectwerkz. codehaus. org/ introduction. html
References
[1] http:/ / aspectwerkz. codehaus. org/ Article Sources and Contributors 38 Article Sources and Contributors
Aspect-oriented software development Source: http://en.wikipedia.org/w/index.php?oldid=443024978 Contributors: AlanUS, Andreas Kaufmann, Antonielly, Aolrnin, CSProfBill, Chris the speller, Cotttho, Cybercobra, David D Allen, Diego Moya, Epbr123, Eric-Wester, Ettrig, Garde, Gbs256, Gf uip, GregorKiczales, Iridescent, Kiv, LilHelpa, Lycurgus, Mark Renier, Materialscientist, Mdd, NuclearWarfare, Obankston, Random user 39849958, Salavat, Shepard, Shirik, Smyth, Stevage, Tekinerdogan, Thr4wn, Twelvethirteen, WikHead, X1011, 65 anonymous edits
Aspect-oriented programming Source: http://en.wikipedia.org/w/index.php?oldid=464070948 Contributors: 54gsze4ghz5, Accurizer, ActiveSelective, AlanUS, Alhoori, Andrew Eisenberg, Antonielly, Ap, AscendantOat, AstReseach, B4hand, BCube, Beland, BenFrantzDale, Bissinger, Bkil, Bkkbrad, Bluemoose, Bramadams, Burschik, Cbuckley, Ch'marr, Chris-gore, Christianjul, Coffee, Cool Blue, Cotttho, Cramforce, Cwolfsheep, Cybercobra, DVdm, Danakil, Darren Duncan, Davetron5000, Daya, Dcoetzee, Descender, Detabbed, Devnevyn, Dgies, Dgilperez, Diego Moya, Dkf11, Donio, DragonHawk, Dreftymac, Ejdzej, Eleusis, Elibarzilay, Elrad, Elwikipedista, Epbr123, Ericbodden, Euyyn, EvanProdromou, FatalError, Frecklefoot, Gaius Cornelius, Garde, GeoffWozniak, Georg-Johann, GeorgeBills, Gerbrant, Ghettoblaster, Gijs.peek, GimliDotNet, Gk5885, Graham87, Gregbard, GregorKiczales, Gregturn, Guy Harris, Gwalla, Habitue, Hailiang, Hairy Dude, Harryboyles, Headbomb, Hesby, Homerjay, Hozawa, Hu12, Hubba, Imz, Irishguy, Ivan Pozdeev, JNW, Jacosi, Jayger, Jerryobject, Jim McKeeth, Jldupont, JonSangster, Joriki, Juanmanuelfigueroa, KHenry, Karol Langner, Kazvorpal, Kbg, Keepbalance, KellyCoinGuy, KenFehling, Khalid hassani, Kiba, Korpo, Kyellan, Ligulem, Limited Atonement, Limyreth, LinguistAtLarge, Luís Felipe Braga, Lycurgus, M3tainfo, Macademe, Macarion, Mark T, MarkSweep, Mathrick, MauriceKA, MaxSem, Mazi, Mfb52, Micah hainline, Michael Hardy, Michaelpb, Milkfish, Minghong, Mjchonoles, Modify, Moszinet, Mountain, Mshonle, NickHodges, Nicolas1981, Nixdorf, Nnp, Nyttend, Oli Filth, Oliver Pereira, Open2universe, Orderud, Paul August, Pavel Vozenilek, Pgan002, Phil Boswell, Philman716, Pmerson, PowerWill500, Pratiproy, Prwg, Raztus, RedWolf, Regenspaziergang, RenniePet, Riceball.lee, Rich Farmbrough, Richard M Vaughan, Samsara, Sanmartin, Seinturier, Shadowjams, Sheiko, Sheltim, Shepard, Shirik, Silentfishwm, Sleske, Smallman12q, Smmousavi, Smyth, Spandrawn, Spyforthemoon, Srleffler, Stormie, Svick, Swati88, The Anome, Timo Honkasalo, Tinku99, Tokek, Tony Sidaway, Torchiest, Traroth, TreyHarris, Trusilver, Tuliopa, Tyafei, Udooz, Upquark, Wantok, Warnet, anonymous edits ערן, Wbrameld, West Brom 4ever, Wikiuser100, Wimt, Winterst, Wwwwolf, Xrm0, Yacht, Yadyn, Zeno Gantner, 461
Aspect Source: http://en.wikipedia.org/w/index.php?oldid=457194690 Contributors: Abdull, Andreas Kaufmann, CSProfBill, Cotttho, Dcamp314, Diego Moya, Dominus, Gene Thomas, GreatWhiteNortherner, Gwalla, Jdcooper, Magioladitis, Mild Bill Hiccup, Mithunc, Modster, OwenBlacker, Paul Mackay, Peashy, PhilKnight, Pnm, Rich Farmbrough, Ruud Koot, S.K., Shawn wiki, Shirik, Softtest123, Uncle G, Zencv, Zondor, 16 anonymous edits
Advice Source: http://en.wikipedia.org/w/index.php?oldid=462233199 Contributors: Cpl Syx, Ericbodden, Gurch, Gwern, Imz, JLaTondre, Joswig, Marudubshinki, Oyd11, Shirik, The Anome, Timo Honkasalo, 4 anonymous edits
Join point Source: http://en.wikipedia.org/w/index.php?oldid=410043125 Contributors: A Stop at Willoughby, B4hand, CUNT FUCKING CUNT, Cotttho, Evercat, Garde, Greenrd, Hans Adler, Imz, Korpo, Lycurgus, Marudubshinki, Michael Hardy, Pcap, Quux, Shirik, SimonP, Swirlix, 10 anonymous edits
Pointcut Source: http://en.wikipedia.org/w/index.php?oldid=442477684 Contributors: Azure Haights, Cotttho, Fubar Obfusco, Gwalla, Hans Adler, Hooperbloob, Jni, Korpo, Macademe, Magioladitis, Mellum, Michael Hardy, Peak, Phil Boswell, Quux, Shirik, TheParanoidOne, 6 anonymous edits
Aspect weaver Source: http://en.wikipedia.org/w/index.php?oldid=429855915 Contributors: Cybercobra, David Eppstein, Fetchcomms, Imz, Ironholds, JLaTondre, KrissManKrissMan, LilHelpa, Shirik, 2 anonymous edits
Cross-cutting concern Source: http://en.wikipedia.org/w/index.php?oldid=459973415 Contributors: ARC Gritt, Abatishchev, Abdull, Andreas Kaufmann, Andrew Eisenberg, Betacommand, Bluemoose, Cotttho, Crystallina, DavidBourguignon, Froehle, Gijs.peek, Ian Burnet, Jemiller226, Jni, JonHarder, Maria C Mosak, Mdd, Niteowlneils, Physis, Pierre gronau, Pion, Pogaz, Sceptre, Shawn wiki, Shirik, Strib, TheParanoidOne, Thr4wn, Wolfraem, Yworo, 35 anonymous edits
AspectJ Source: http://en.wikipedia.org/w/index.php?oldid=454516181 Contributors: Andrew Eisenberg, Anna Frodesiak, Ascánder, Ashmodai, BenFrantzDale, Bissinger, CRGreathouse, Clicketyclack, Cotttho, Danakil, Dispenser, Ejdzej, Ericbodden, Garde, Harperska, Hult041956, JLaTondre, James tyrrell, LittleDan, Macademe, Mshonle, Pavel Vozenilek, Q Chris, Rhino1977, Rich Farmbrough, Rumping, Rural 2, SF007, Salvan, Seliopou, Shirik, Stan Shebs, Stuartyeates, Udittmer, Van der Hoorn, 61 anonymous edits
AspectC++ Source: http://en.wikipedia.org/w/index.php?oldid=355003746 Contributors: Anthony Bradbury, Decltype, DimpleK, GregorB, Kathleen.wright5, MikeMortensen, Shirik, Wwwwolf, 6 anonymous edits
AspectWerkz Source: http://en.wikipedia.org/w/index.php?oldid=454516145 Contributors: Bxj, Hervegirod, JennyRad, John Vandenberg, MinorEdits, Nixeagle, Sedimin, Stuartyeates, The Great Corrector, 4 anonymous edits Image Sources, Licenses and Contributors 39 Image Sources, Licenses and Contributors
Image:UMLComponent blur.gif Source: http://en.wikipedia.org/w/index.php?title=File:UMLComponent_blur.gif License: Creative Commons Attribution 3.0 Contributors: Cotttho (talk) Image:FigureEditor.jpg Source: http://en.wikipedia.org/w/index.php?title=File:FigureEditor.jpg License: Creative Commons Attribution 3.0 Contributors: Cotttho (talk) (Transferred by Murav/Originally uploaded by Cotttho) Image:AOFigureEditor.jpg Source: http://en.wikipedia.org/w/index.php?title=File:AOFigureEditor.jpg License: Creative Commons Attribution 3.0 Contributors: Cotttho (talk) File:AspectWeaver.svg Source: http://en.wikipedia.org/w/index.php?title=File:AspectWeaver.svg License: Creative Commons Attribution-Sharealike 3.0 Contributors: Shirik License 40 License
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/