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

Aspect-oriented softwaredevelopmentAn introductory guide

ContentsArticlesOverview 1

Aspect-oriented software development 1Aspect-oriented programming 12

Concepts 22

Aspect 22Advice 23Join point 25Pointcut 25Aspect weaver 26Cross-cutting concern 31

Languages 33

AspectJ 33AspectC++ 36AspectWerkz 37

ReferencesArticle Sources and Contributors 38Image Sources, Licenses and Contributors 39

Article LicensesLicense 40

1

Overview

Aspect-oriented software developmentIn computing, Aspect-oriented software development (AOSD) is an emerging software development technologythat seeks new modularizations of software systems in order to isolate secondary or supporting functions from themain program's business logic. AOSD allows multiple concerns to be expressed separately and automatically unifiedinto working systems.Traditional software development focuses on decomposing systems into units of primary functionality, whilerecognizing that there are other issues of concern that do not fit well into the primary decomposition. The traditionaldevelopment process leaves it to the programmers to code modules corresponding to the primary functionality and tomake sure that all other issues of concern are addressed in the code wherever appropriate. Programmers need to keepin mind all the things that need to be done, how to deal with each issue, the problems associated with the possibleinteractions, and the execution of the right behavior at the right time. These concerns span multiple primaryfunctional units within the application, and often result in serious problems faced during application developmentand maintenance. The distribution of the code for realizing a concern becomes especially critical as the requirementsfor 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 ofcross-cutting concerns and their modularization into separate functional units as well as their automated compositioninto a working system.

HistoryAspect-Oriented Software Development describes a number of approaches to software modularization andcomposition 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 asMultidimensional Separation of Concerns)[3] at IBM, Feature Oriented Programming[4] at University of Texas atAustin, Adaptive Programming[5] at Northeastern University, USA, and Aspect-Oriented Programming (AOP)[6] atPalo Alto Research Center. The term aspect-oriented was introduced by Gregor Kiczales and his team at Palo AltoResearch Center who also first developed the explicit concept of AOP and the AOP language called AspectJ whichhas 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 developmentmethodologies, AOP has encouraged a nascent set of software engineering technologies, including methodologiesfor 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 ofsoftware 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 annualconference, the International Conference on Aspect-Oriented Software Development, held for the first time in 2002in Enschede, The Netherlands. AOSD is a rapidly evolving area. It is a popular topic of Software Engineeringresearch, especially in Europe, where research activities on AOSD are coordinated by the European Network ofExcellence on Aspect-Oriented Software Development [7] (AOSD-Europe), funded by the European Commission.

Aspect-oriented software development 2

Motivation

Crosscutting concerns

Figure 3 — An UML architecture diagram for a telecom component

The motivation for aspect-orientedprogramming approaches stem fromthe problems caused by code scatteringand tangling. The purpose ofAspect-Oriented SoftwareDevelopment is to provide systematicmeans to modularize crosscuttingconcerns.

The implementation of a concern isscattered if its code is spread out overmultiple modules. The concern affectsthe implementation of multiplemodules. Its implementation is notmodular.

The implementation of a concern istangled if its code is intermixed withcode that implements other concerns.The module in which tangling occursis 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 crosscuttingconcerns. 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 andintegration of these concerns with the primary functional decomposition of the system causes code tangling andscattering.

Example 1: Logging in Apache Tomcat

Figure 1 illustrates a decomposition into classes of the Apache Tomcat web container. The vertical bars in thediagram correspond to different packages in the Tomcat distribution. The length of these bars corresponds to the sizeof the code of these packages. In Figure 1, the code that corresponds to the classloading concern of the applicationhave been highlighted in red. Classloading in Tomcat is a modular concern with respect to the systemdecomposition. Its implementation is contained in a small number of classes and is not intertwined with theimplementation of other concerns.Figure 2 represents the implementation of the logging concern in Tomcat. Logging in Tomcat is a crosscuttingconcern. Its implementation spreads over many classes and packages and is intermixed with the implementation ofmany 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 thatcommunicates with other processes through connectors.Figure 4 illustrates the impact of a coordination concern on the architecture of the system, such as When the systemstarts 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 eachprocess in the diagram. Its implementation crosscuts the implementation of the other processes.

Examples of crosscutting concernssee Cross-cutting_concern#Examples

Problems caused by scattering and tanglingScattering 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 theimplementation of the concern and the modules of the system are not explicitly declared. They are encodedimplicitly through the dependencies and interactions between fragments of code that implement the concern and theimplementation of other modules.The lack of interfaces between the implementation of crosscutting concerns and the implementation of the modulesof 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 ofother modules. Modularity is achieved through the definition of well-defined interfaces between segments of thesystem.[8]

The lack of explicit interfaces between crosscutting concerns and the modules obtained through the functionaldecomposition of the system imply that the implementation of these concerns, as well as the responsibility withrespect to the correct implementation of these concerns, cannot be assigned to independent development teams. Thisresponsibility has to be shared among different developers that work on the implementation of different modules ofthe 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 differentcontexts. Crosscutting impedes reuse of components. The lack of interfaces between crosscutting concerns and othermodules makes it hard to represent and reason about the overall architecture of a system. As the concern is notmodularized, the interactions between the concern and the top-level components of the system are hard to representexplicitly. Hence, these concerns become hard to reason about because the dependencies between crosscuttingconcerns and components are not specified.Finally, concerns that are not modularized are hard to test in isolation. The dependencies of the concern with respectto behavior of other modules are not declared explicitly. Hence, the implementation of unit test for such concernsrequires 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 theimplementation of this concern needs to be modified. The comprehension of the implementation of a crosscuttingconcern 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 allthe 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-orientationThe focus of Aspect-Oriented Software Development (AOSD) is in the investigation and implementation of newstructures for software modularity that provide support for explicit abstractions to modularize concerns.Aspect-Oriented Programming approaches provide explicit abstractions for the modular implementation of concernsin design, code, documentation, or other artifacts developed during the software life-cycle. These modularizedconcerns are called aspects, and aspect-oriented approaches provide methods to compose them. Some approachesdenote a root concern as the base. Various approaches provide different flexibility with respect to composition ofaspects

Quantification and obliviousness

The best known definition of the nature of AOSD is due to Filman and Friedman, which characterized AOSD usingthe equation aspect orientation = quantification + obliviousness.[9]

AOP can be understood as the desire to make quantified statements about the behavior of programs, andto 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, performaction A over a conventionally coded program P.[9]

Obliviousness implies that a program has no knowledge of which aspects modify it where or when, whereasquantification 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 aspectscan add behavior to a program without having to perform changes in that program, yet it does not assume thatprograms are not aware of the aspects.Filman's definition of aspect-orientation is often considered too restrictive.[10] Many aspect-oriented approaches useannotations to explicitly declare the locations in the system where aspects introduce behavior. These approachesrequire 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 featureswhose implementation would otherwise be tangled with other features. Such aspects do not necessarily usequantification over multiple locations in the system.The essential features of Aspect-Oriented Software Development are therefore better characterized in terms of themodularity of the implementation of crosscutting concerns, the abstractions provided by aspect-oriented languages toenable modularization and the expressiveness of the aspect-oriented composition operators.

Aspect-oriented software development 5

Concepts and terminologyAspect-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-invasiveintroduction of behavior into a code base and quantification over points in the program where this behavior shouldbe 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 iscombined. A join point is a point in the execution of the program, which is used to define the dynamic structure of acrosscutting concern.The join point model of an aspect-oriented language defines the types of join points that are supported by theaspect-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 calleeof a method from a join point to a matching pointcut. Nowadays, there are various join point models around and stillmore 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 initializationA method call join point covers the actions of an object receiving a method call. It includes all the actions thatcompose 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 staticprojection 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 joinpoints include the execution of method moveBy(int, int) on a Line object, the calls to methods moveBy(int, int) on thePoint objects in the context of the Line object, the execution of these methods in the context of the Point objects andthe 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 thelanguage structure or may be expressed using a query-like construct called a pointcut. Pointcuts are defined as apredicate over the syntax-tree of the program, and define an interface that constrains which elements of the baseprogram are exposed by the pointcut. A pointcut picks out certain join points and values at those points. Thesyntactic formulation of a pointcut varies from approach to approach, but a pointcut can often be composed out ofother pointcuts using the boolean operators AND, OR and NOT. Pointcut expressions can concisely capture a widerange 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. Forexample, in AspectJ syntax cflow(move()) picks out each join point that occurs in the dynamic context of the joinpoints 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 aconcern. The order in which the advice bodies contributed by aspects (and by the base) may be controlled in avariety 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 beenprovided.[11]

When the execution of a join point satisfies a pointcut expression, the base and advice code associated with the joinpoint are executed. The advice may interact with the rest system through a join point instance containing reflectiveinformation on the context of the event that triggered the advice, such as the arguments of a method call or the targetinstance of a call.

Inter-type declarations

Inter-type declarations allow the programmer to modify a program's static structure, such as class members andclasses 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-typedeclarations. 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 isperformed by a specialized compiler, called an aspect weaver.

Aspect-oriented software development 7

Example

Figure 6 — Figure Editor in UML

Figure 7 — Aspect-Oriented Figure Editor in UML

Figure 6 illustrates a classic exampleof a crosscutting concern in a figureeditor example taken from the AOSDliterature. The example describes anabstract Shape class that can be movedin the editor. Whenever a shape ismoved, the display needs to berefreshed. Figure 6 also depicts twoShape subclasses, Line and Point thatimplement the Shape functionality.The display refresh concern isscattered across the implementation ofboth subclasses. Figure 7 represents anaspect-oriented implementation of thesame system, where an aspectencapsulates the display updatingfunctionality.The move pointcut descriptor of Figure7 captures all the executions of themoveBy methods of a subclass ofShape and invokes the display refreshfunctionality after the executionproceeds. The concern is modularized,which makes it easier to evolve andmaintain.

Aspect-oriented requirementengineering

Aspect-oriented requirementEngineering (also referred to as "EarlyAspects") focuses on the identification,specification and representation ofcrosscutting properties at therequirement level. Examples of suchproperties include security, mobility,availability and real-time constraints. Crosscutting properties are requirements, use cases or features that have abroadly-scoped effect on other requirements or architecture components.

Aspect-oriented requirements engineering approaches are techniques that explicitly recognise the importance ofclearly 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 andsubsequently tracing crosscutting functional and non-functional concerns via suitable abstraction, representation andcomposition 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 architectureAspect-oriented system architecture focuses on the localization and specification of crosscutting concerns inarchitectural designs. Crosscutting concerns that appear at the architectural level cannot be modularized byredefining the software architecture using conventional architectural abstractions. Aspect-oriented systemarchitecture languages propose explicit mechanisms to identify, specify and evaluate aspects at the architecturedesign level.Aspect-oriented architecture starts from the observation that we need to identify, specify and evaluate aspectsexplicitly at the architecture design level. Aspectual architecture approaches describe steps for identifyingarchitectural aspects. This information is used to redesign a given architecture in which the architectural aspects aremade 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 designAspect-oriented design has the same objectives as any software design activity, i.e. characterising and specifying thebehavior and structure of the software system. Its unique contribution to software design lies in the fact that concernsthat are necessarily scattered and tangled in more traditional approaches can be modularized. Typically, such anapproach includes both a process and a language. The process takes as input requirements and produces a designmodel. The produced design model represents separate concerns and their relationships. The language providesconstructs that can describe the elements to be represented in the design and the relationships that can exist betweenthose elements. In particular, constructs are provided to support concern modularization and the specification ofconcern composition, with consideration for conflicts. Beyond that, the design of each individual modularizedconcern 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 thesource code.Just like any other programming language, an aspect-oriented language typically consists of two parts: a languagespecification and an implementation. Hence, there are two corresponding areas of excellence: support for languagedevelopers and support for application developers.Support for application developers

An aspect-oriented approach supports the implementation of concerns and how to compose those independentlyimplemented 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-orientedprograms. 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-orientationFormal 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 ofwhen 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 deepunderstanding of the differences among constructs. Aspects potentially can harm the reliability of a system to whichthey are woven, and could invalidate essential properties that already were true of the system without the aspect. It isalso necessary to show that they actually do add intended crosscutting properties to the system. Hence, numerousquestions 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 readyfor routine industrial application. Nevertheless, awareness of these issues is essential for language designers, and foreffective use of aspects, especially in safety-critical contexts.

Aspect-oriented software development 10

Aspect-oriented middlewareMiddleware 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 internallyto isolate features of the different editions.

• JBoss Application Server (JBoss AS) is a free, open-source java application server that supports Java EE. Thecore of JBoss AS is integrated with the JBoss AOP aspect-oriented programming language.[12] The applicationserver 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 ApplicationServer. 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 anddifferent mobile gaming community interfaces.

• Siemens Soarian is a health information management system that supports seamless access to patient medicalrecords and the definition of workflows for health provider organizations. Soarian uses AspectJ to integratecrosscutting features such as tracing, auditing and performance monitoring in the context of an agile developmentprocess.

• Motorola wi4 is a cellular infrastructure system that provides support for the WiMAX wireless broadbandstandard. The wi4 control software is developed using an aspect-oriented extension to the UML 2.0 standardcalled 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-orientedextension to C called Mirjam to modularize tracing and profiling concerns.

• Glassbox is a troubleshooting agent for Java applications that automatically diagnoses common problems. TheGlassbox 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-OrientedProgramming (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): DoesAspect-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 Separationof Concerns, in: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), LosAngeles, 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 programmingIn computing, aspect-oriented programming (AOP) is a programming paradigm which aims to increasemodularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented softwaredevelopment.AOP includes programming methods and tools that support the modularization of concerns at the level of the sourcecode, while "aspect-oriented software development" refers to a whole engineering discipline.

OverviewAspect-oriented programming entails breaking down program logic into distinct parts (so-called concerns, cohesiveareas of functionality). Nearly all programming paradigms support some level of grouping and encapsulation ofconcerns 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 formsof 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 thesystem. Logging thereby crosscuts all logged classes and methods.All AOP implementations have some crosscutting expressions that encapsulate each concern in one place. Thedifference 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 fortype-safety or debugging. AspectJ has a number of such expressions and encapsulates them in a special class, anaspect. For example, an aspect can alter the behavior of the base code (the non-aspect part of a program) by applyingadvice (additional behavior) at various join points (points in a program) specified in a quantification or query calleda pointcut (that detects whether a given join point matches). An aspect can also make binary-compatible structuralchanges to other classes, like adding members or parents.

HistoryAOP 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 theAspectJ AOP extension to Java. IBM's research team pursued a tool approach over a language design approach andin 2001 proposed Hyper/J and the Concern Manipulation Environment, which have not seen wide usage. EmacsLispchangelog added AOP related code in version 19.28 [3]. The examples in this article use AspectJ as it is the mostwidely known AOP language.The Microsoft Transaction Server is considered to be the first major application of AOP followed by EnterpriseJavaBean.[4] [5]

Motivation and basic conceptsTypically, an aspect is scattered or tangled as code, making it harder to understand and maintain. It is scattered byvirtue 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 requiremodifying all affected modules. Aspects become tangled not only with the mainline function of the systems in whichthey are expressed but also with each other. That means changing one concern entails understanding all the tangledconcerns 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 amountfrom 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 lackssecurity checks to verify that the current user has the authorization to perform this operation. A database transactionshould encapsulate the operation in order to prevent accidental data loss. For diagnostics, the operation should belogged to the system log. And so on. A simplified version with all those new concerns would look somewhat likethis:

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 thebusiness 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 theapplication. 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-alonemodules called aspects. Aspects can contain advice (code joined to specified points in the program) and inter-typedeclarations (structural members added to other classes). For example, a security module can include advice thatperforms a security check before accessing a bank account. The pointcut defines the times (join points) when one canaccess 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 programchanges, so if another developer creates a new method to access the bank account, the advice will apply to the newmethod 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 youcannot get the function changed (user level)[7] or do not want to change the function in production code (debugging).

Join point modelsThe advice-related component of an aspect-oriented language defines a join point model (JPM). A JPM defines threethings: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 anordinary programmer to be useful. It should also be stable across inconsequential program changes in order for anaspect to be stable across such changes. Many AOP implementations support method executions and fieldreferences as join points.

2. A way to specify (or quantify) join points, called pointcuts. Pointcuts determine whether a given join pointmatches. Most useful pointcut languages use a syntax like the base language (for example, AspectJ uses Javasignatures) 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, andaround join points. Some implementations also support things like defining a method in an aspect on anotherclass.

Join-point models can be compared based on the join points exposed, how join points are specified, the operationspermitted 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 aJava-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 isexactly 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 theunqualified 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 thewildcards 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 aninstance 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 (specifiedlike 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 codeDisplay.update() after the join point completes."

Aspect-oriented programming 16

Other potential join point modelsThere are other kinds of JPMs. All advice languages can be defined in terms of their JPM. For example, ahypothetical 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 declarationsInter-type declarations provide a way to express crosscutting concerns affecting the structure of modules. Alsoknown 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 programmerimplemented the crosscutting display-update concern using visitors instead, an inter-type declaration using thevisitor 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 existingclass continue to operate, unless the AOP implementation can expect to control all clients at all times.

ImplementationAOP programs can affect other programs in two different ways, depending on the underlying languages andenvironments:1. a combined program is produced, valid in the original language and indistinguishable from an ordinary program

to the ultimate interpreter2. the ultimate interpreter or environment is updated to understand and implement AOP features.The difficulty of changing environments means most implementations produce compatible combination programsthrough a process known as weaving - a special case of program transformation. An aspect weaver reads theaspect-oriented code and generates appropriate object-oriented code with the aspects integrated. The same AOPlanguage can be implemented through a variety of weaving methods, so the semantics of a language should never beunderstood in terms of the weaving implementation. Only the speed of an implementation and its ease of deploymentare 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 towork with any Java program in .class-file form. Bytecode weavers can be deployed during the build process or, if theweave model is per-class, during class loading. AspectJ started with source-level weaving in 2001, delivered aper-class bytecode weaver in 2002, and offered advanced load-time support after the integration of AspectWerkz in2005.Any solution that combines programs at runtime has to provide views that segregate them properly to maintain theprogrammer's segregated model. Java's bytecode support for multiple source files enables any debugger to stepthrough 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 thegenerated code, this weaving approach subclasses existing classes so that the modifications are introduced bymethod-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 implementationof many Java EE application servers, such as IBM's WebSphere.

TerminologyStandard 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 thedata-access layer and also to classes in the UI layer whenever a thread enters or exits a method. Even thougheach class has a very different primary functionality, the code needed to perform the secondary functionality isoften identical.

AdviceThis is the additional code that you want to apply to your existing model. In our example, this is the loggingcode that we want to apply whenever the thread enters or exits a method.

PointcutThis is the term given to the point of execution in the application at which cross-cutting concern needs to beapplied. In our example, a pointcut is reached when the thread enters a method, and another pointcut is reachedwhen the thread exits the method.

AspectThe combination of the pointcut and the advice is termed an aspect. In the example above, we add a loggingaspect to our application by defining a pointcut and giving the correct advice.

Comparison to other programming paradigmsAspects emerged out of object-oriented programming and computational reflection. AOP languages havefunctionality similar to, but more restricted than metaobject protocols. Aspects relate closely to programmingconcepts like subjects, mixins, and delegation. Other ways to use aspect-oriented programming paradigms includeComposition Filters and the hyperslices approach. Since at least the 1970s, developers have been using forms ofinterception and dispatch-patching that resemble some of the implementation methods for AOP, but these never hadthe 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 suchapproaches lack a quantification mechanism that allows reaching several join points of the code with one declarativestatement.

Aspect-oriented programming 18

Adoption issuesProgrammers need to be able to read code and understand what is happening in order to prevent errors.[9] Even withproper education, understanding crosscutting concerns can be difficult without proper support for visualizing bothstatic structure and the dynamic flow of a program. Beginning in 2002, AspectJ began to provide IDE plug-ins tosupport the visualizing of crosscutting concerns. Those features, as well as aspect code assist and refactoring are nowcommon.Given the power of AOP, if a programmer makes a logical mistake in expressing crosscutting, it can lead towidespread program failure. Conversely, another programmer may change the join points in a program – e.g., byrenaming or moving methods – in ways that the aspect writer did not anticipate, with unintended consequences. Oneadvantage of modularizing crosscutting concerns is enabling one programmer to affect the entire system easily; as aresult, 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 bechanged, whereas the corresponding problems without AOP can be much more spread out.

ImplementationsThe 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/ ), Springframework (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 WebFramework (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 thedefinition 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 SoftwareDevelopment. ISBN 0-321-21976-7.

• Pawlak, Renaud; Lionel Seinturier, and Jean-Philippe Retaillé (2005). Foundations of AOP for J2EEDevelopment. 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

AspectIn computer science, an aspect of a program is a feature linked to many other parts of the program, but which is notrelated to the program's primary function. An aspect crosscuts the program's core concerns, therefore violating itsseparation of concerns that tries to encapsulate unrelated functions. For example, logging code can crosscut manymodules, 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 softwaredevelopment (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 byallowing both functional and non-functional behaviour to crosscut any other concerns, instead of just mappingnon-functional concerns to functional requirements.One view of aspect-oriented software development is that every major feature of the program, core concern (businesslogic), or cross-cutting concern (additional features), is an aspect, and by weaving them together (a process alsocalled composition), one finally produces a whole out of the separate aspects. This approach is known as pure aspectprogramming, but hybrid approaches are more commonly used, perhaps since there is less of a paradigm shiftbetween object- and aspect-oriented programming. There is a similar situation with early aspect softwaredevelopment (e.g., requirements), with traditional methods being enhanced for aspect-orientation and new modelsproposed. Non-functional concerns (e.g., security) can crosscut functional concerns (e.g., door must be present). It ispossible for functional concerns to crosscut non-functional or functional concerns (e.g., need for more features harmsmobility). A uniform approach to representation and composition, similar to the pure approach in AOP, is termedmultidimensional 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 thedifferent colours back into a white ray of light, and by the process of weaving aspects one can put the solutions forthe 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

AdviceIn aspect and functional programming, advice describes a class of functions which modify other functions when thelatter 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 thefollowing:The term advice goes back to the term advising as introduced by Warren Teitelman in his PhD thesis in 1966. Hereis 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 newprocedures at any or all of the entry or exit points to a particular procedure (or class of procedures). Theprocedures 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 thatthe execution of advice can cause the procedure that it modifies to be bypassed completely, e.g., by specifyingas an exit from the advice one of the exits from the original procedure; or the advice may change essentialvariables and continue with the computation so that the original procedure is executed, but with modifiedvariables. Finally, the advice may not alter the execution or affect the original procedure at all, e.g., it maymerely perform some additional computation such as printing a message or recording history. Since advicecan be conditional, the decision as to what is to be done can depend on the results of the computation up tothat point.

The principal advantage of advising is that the user need not be concerned about the details of the actualchanges 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 maybe contrasted with editing in which the programmer must be cognizant of the internal structure of theprocedure.

"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 subsumedunder the notion of method combination. See, for example, AIM-602 at http:/ / www. ai. mit. edu/ research/publications/ browse/ 0600browse. shtml 1

Since method combination and macros are closely related, it's also interesting to note that the first macro system wasdescribed in 1963, three years before Warren Teitelman's PhD thesis. See AIM-57 at http:/ / www. ai. mit. edu/research/ publications/ browse/ 0000browse. shtml 2

UseThe practical use of advice functions is generally to modify or otherwise extend the behavior of functions whichcannot be easily modified or extended. The Emacspeak Emacs-addon makes extensive use of advice: it must modifythousands of existing Emacs modules and functions such that it can produce audio output for the blind correspondingto the visual presentation, but it would obviously be infeasible to copy all of them and redefine them to produceaudio output in addition to their normal outputs; so, the Emacspeak programmers define advice functions which runbefore 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)

NotesGregor 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 tothat the rules governing combination of before/after methods and so-called whoppers methods (around) wasfixed, and the compiler just generated the code for that. There were things called wrappers, which had macro-likebehavior, but I forget when they came around. Traipsing through the various versions of MacLisp and Lispmmanual to get this part of the history exactly right could interesting. Or it could be that Howard Cannon or DavidMoon 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 pointIn computer science, a join point is a point in the control flow of a program. In aspect-oriented programming a set ofjoin points is described as a pointcut. A join point is a specification of when, in the corresponding main program, theaspect code should be executed.The join point is a point of execution in the base code where the advice specified in a corresponding pointcut isapplied.Conceptually, a join point exists where a precondition for a command in Hoare logic makes an assertion parametricupon 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.

PointcutIn aspect-oriented computer programming, a pointcut is a set of join points. Whenever the program executionreaches one of the join points described in the pointcut, a piece of code associated with the pointcut (called advice) isexecuted. This allows a programmer to describe where and when additional code should be executed in addition toan already defined behavior. This permits the addition of aspects to existing software, or the design of software witha clear separation of concerns, wherein the programmer weaves (merges) different aspects into a completeapplication.

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 theclasses.Usage

Paradigm Aspect-oriented programming

Language(s) AspectC++, AspectJ

An aspect weaver is a metaprogramming utility for aspect-oriented languages designed to take instructions specifiedby aspects (isolated representations of a significant concepts in a program) and generate the final implementationcode. The weaver integrates aspects into the locations specified by the software as a pre-compilation step. Bymerging aspects and classes (representations of the structure of entities in the program), the weaver generates either awoven 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, specialsegments of code that indicate what methods should be handled by aspect code. The implementation of the aspectthen specifies whether the related code should be added before, after, or throughout the related methods. By doingthis, aspect weavers improve modularity, keeping code in one place that would otherwise have been interspersedthroughout various, unrelated classes.

MotivationMany programming languages are already widely accepted and understood. However, the desire to create radicallydifferent programming languages to support the aspect-oriented programming paradigm is not significant due tobusiness-related concerns; there are risks associated with adopting new technologies.[1] Use of an entirely newlanguage relies on a business's ability to acquire new developers. Additionally, the existing code base of a businesswould need to be discarded. Finally, a business would need to acquire a new toolchain (suite of tools) fordevelopment, which is often both an expense in both money and time.[2] Primary concerns about roadmaps for theadoption of new technologies tend to be the need to train new developers and adapt existing processes to the newtechnology.[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 retainingthe benefits of aspect-oriented programming.[6]

ImplementationAspect weavers operate by taking instructions specified by aspects, known as advice, and distributing it throughoutthe various classes in the program automatically. The result of the weaving process is a set of classes with the samenames as the original classes but with additional code injected into the classes' functions automatically. The advicespecifies 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 acrossclasses. By eliminating this duplication, aspect weavers promote modularity of cross-cutting concerns.[8] Aspectsdefine the implementation code which would have otherwise been duplicated and then use pointcuts and join pointsto define the advice. During weaving, the aspect weaver uses the pointcuts and join points, known as a pointcutdesignator, to identify the positions in candidate classes at which the implementation should be injected.[9] Theimplementation is then injected into the classes at the points identified, thus permitting the code to be executed at theappropriate 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 AspectJIn the programming language AspectJ, pointcuts, join points, and the modularized code are defined in an aspectblock similar to that of Java classes. Classes are defined using Java syntax. The weaving process consists ofexecuting the aspect advice to produce only a set of generated classes that have the aspect implementation codewoven 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 theimplementation code into the defined class. The code differs slightly in each method due to slight variances inrequirements for the method (as the method identifier has changed). The aspect weaver determines the appropriatecode to generate in each situation as defined by the implementation advice and then injects it into methods matchingthe specified pointcut.[13]

Weaving to bytecodeInstead of generating a set of woven source code, some AspectJ weavers instead weave the aspects and classestogether directly into bytecode, acting both as the aspect weaver and compiler.[14] [15] While it is expected that theperformance of aspect weavers which also perform the compilation process will require more computation time dueto 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 andoptimized.[16]

Run-time weavingDevelopments in AspectJ have revealed the potential to incorporate just-in-time compilation into the execution ofaspect-oriented code to address performance demands.[17] At run-time, an aspect weaver could translate aspects in amore 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 someimplementations of just-in-time virtual machines implement this capability through a new virtual machine, someimplementations can be designed to use features that already exist in current virtual machines.[19] [20] Therequirement 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 isnecessary. A proposed solution for AspectJ uses a layered approach which builds upon the existing Java VirtualMachine to add support for join point management and callbacks to a Dynamic Aspect-Oriented ProgrammingEngine.[20] An alternative implementation uses a weaving engine that uses breakpoints to halt execution at thepointcut, select an appropriate method, embed it into the application, and continue.[21] The use of breakpoints in thismanner has been shown to reduce performance due to a very large number of context switches.[18]

PerformanceAspect 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 keywordthisJoinPointStaticPart can only be done by the aspect weaver. By performing this replacement, thewoven program avoids the creation of a join point object on every execution.[14] Studies have shown that theunnecessary creation of join point objects in AspectJ can lead to a performance overhead of 5% at run-time, whileperformance 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 tothe additional work necessary for locating methods which match the specified pointcuts. A study done showed thatthe AspectJ compiler ajc is about 34% slower than the Sun Microsystems Java 1.3 compiler and about 62% slowerthan 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 ACMSIGPLAN-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 Integrationin Middleware" (http:/ / wwwx. cs. unc. edu/ ~lee/ docs/ pra03-colyer. pdf) (PDF). Companion of the 18th annualACM 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 SystemsandAspect-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 Conferenceon 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-orientedsoftware 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). Proceedingsof 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 ofPotential Fault Scenarios". Proceedings of the 4th International Conference on Aspect-Oriented SoftwareDevelopment (ACM): 192–200. doi:10.1145/1052898.1052915.

• Popovici, Andrei; Alonso, Gustavo; Gross, Thomas (2003). "Just-In-Time Aspects: Efficient Dynamic Weavingfor 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 AspectWeaver" (http:/ / www. csg. is. titech. ac. jp/ paper/ yoshiki-gpce03. pdf) (PDF). Proceedings of the 2ndinternational conference on Generative programming and component engineering: 189–208. Retrieved 4 January2010.

• Spinczyk, Olaf; Gal, Andreas; Schröder-Preikschat, Wolfgang (2002). "AspectC++: An Aspect-OrientedExtension 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-BasedSystems 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 ReliableSoftware?". 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 pointsin aspect-oriented programming" (http:/ / reference. kfupm. edu. sa/ content/ s/ e/a_semantics_for_advice_and_dynamic_join__97028. pdf) (PDF). ACM Transactions on ProgrammingLanguages 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 ApplicationsConference 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/ AspectSupport 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 concernIn computer science, cross-cutting concerns are aspects of a program which affect other concerns. These concernsoften cannot be cleanly decomposed from the rest of the system in both the design and implementation, and canresult 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 isa core concern, while logging a history of changes to the record database or user database, or an authenticationsystem, would be cross-cutting concerns since they touch more parts of the program.

BackgroundCross-cutting concerns are parts of a program which rely on or must affect many other parts of the system. Theyform the basis for the development of aspects.[1] Such cross-cutting concerns do not fit cleanly into object-orientedprogramming 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 semanticthrough which two goals (the capability to be implemented and the related cross-cutting concern) can be addressedsimultaneously.[3] As a result, the code addressing the cross-cutting concern must be scattered, or duplicated, acrossthe various related locations, resulting in a loss of modularity. [2]

Aspect-oriented programming aims to encapsulate cross-cutting concerns into aspects to retain modularity. Thisallows for the clean isolation and reuse of code addressing the cross-cutting concern.[4] By basing designs oncross-cutting concerns, software engineering benefits are affected, including modularity and simplifiedmaintenance.[5]

ExamplesExamples 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 inEclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become thewidely-used de-facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-likesyntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001.

Simple language descriptionAll valid Java programs are also valid AspectJ programs, but AspectJ also allows programmers to define specialconstructs 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, likemethod call, object instantiation, or variable access). All pointcuts are expressions (quantifications) that determinewhether a given join point matches. For example, this point-cut matches the execution of any instance method inan 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 theAspectJ Programming Guide [2] for a more detailed description of the language.

AspectJ compatibility and implementationsAspectJ has been designed to be implemented in many ways, including source- or bytecode-weaving and directly inthe VM (virtual machine). In all cases, the AspectJ program is transformed into a valid Java program run in a JavaVM. Any classes affected by aspects are binary-compatible with the unaffected classes (in order to maintaincompatibility with any classes that were compiled with the unaffected originals). Supporting multipleimplementations allows the language to grow as technology changes, and being Java-compatible ensures platformavailability.Key to its success has been engineering and language decisions designed to make the language usable and programsdeployable. 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 abytecode weaver based on BCEL, so developers could write aspects for code in binary (.class) form. At this time theAspectJ language was restricted to support a per-class model essential for incremental compilation and load-timeweaving. This made IDE integrations as responsive as their Java counterparts, and it enabled developers to deployaspects without altering the build process. This led to increased adoption, as AspectJ became usable for impatientJava programmers and enterprise-level deployments. Since then, the Eclipse team has increased performance andcorrectness, upgraded the AspectJ language to support Java 5 language features like generics and annotations, andintegrated annotation-style pure-java aspects from AspectWerkz.The Eclipse project supports both command-line and Ant interfaces. A related Eclipse project has steadily improvedthe 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 didappear. 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 allJava VM's would require agreement through Sun's Java Community Process (see also the java.lang.instrumentpackage 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 AspectJsince its release. The leading research implementation of AspectJ is the AspectBench Compiler [3], or abc; itsupports extensions for changing the syntax and semantics of the language and forms the basis for many AOPexperiments 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 SpringAOP. A sister Spring project, Spring Roo, automatically maintains AspectJ inter-type declarations as its principalcode generation output.

AspectJ 35

History and contributorsGregor 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 andErik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, MikKersten implemented the IDE integration and started the Eclipse AJDT [4] project with Adrian Colyer (current leadof 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 projectwhen 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 ToolsGroup at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and theInstitute 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 inJava [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 CommonPublic 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 toMicrosoft Windows are only available through pure-systems GmbH.Aspect-oriented programming allows modularizing cross-cutting concerns in a single module, an aspect. Aspects canmodify existing classes, but most commonly they provide 'advice' that runs before, after, or around existingfunctionality.For example, all calls to a specific function can be traced using an aspect, rather than inserting 'cerr' or printstatements 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 itwill 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, thefunction:

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 typeor 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

AspectWerkzAspectWerkz is a dynamic, lightweight and high-performance AOP/AOSD framework for Java. It has been mergedwith 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 insteadsupported declaration of aspects within Java annotations. It utilizes bytecode modification to weave classes at projectbuild-time, class load time, as well as runtime. It uses standardized JVM level APIs. Aspects can be defined usingeither 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 andopen 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 ContributorsAspect-oriented software development  Source: http://en.wikipedia.org/w/index.php?oldid=443024978  Contributors: AlanUS, Andreas Kaufmann, Antonielly, Aolrnin, CSProfBill, Chris thespeller, 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 anonymousedits

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, DiegoMoya, 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, PaulAugust, 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,Wbrameld, West Brom 4ever, Wikiuser100, Wimt, Winterst, Wwwwolf, Xrm0, Yacht, Yadyn, Zeno Gantner, 461 ,ערן anonymous edits

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., Shawnwiki, 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, HansAdler, 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, TheGreat Corrector, 4 anonymous edits

Image Sources, Licenses and Contributors 39

Image Sources, Licenses and ContributorsImage: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 byMurav/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

LicenseCreative Commons Attribution-Share Alike 3.0 Unported//creativecommons.org/licenses/by-sa/3.0/