aspect in computing aspectoriented software development aosd is a software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main programs business logic aosd allows multiple concerns to be expressed separately and automatically unified into working systems traditional software development focuses on decomposing systems into units of primary functionality while recognizing that there are other issues of concern that do not fit well into the primary decomposition the traditional development process leaves it to the programmers to code modules corresponding to the primary functionality and to make sure that all other issues of concern are addressed in the code wherever appropriate programmers need to keep in mind all the things that need to be done how to deal with each issue the problems associated with the possible interactions and the execution of the right behavior at the right time these concerns span multiple primary functional units within the application and often result in serious problems faced during application development and maintenance the distribution of the code for realizing a concern becomes especially critical as the requirements for that concern evolve a system maintainer must find and correctly update a variety of situations aspectoriented software development focuses on the identification specification and representation of crosscutting concerns and their modularization into separate functional units as well as their automated composition into a working system history aspectoriented software development describes a number of approaches to software modularization and composition including in order of publication reflection and metaobject protocols composition filters at palo alto research center the term aspectoriented was introduced by gregor kiczales and his team at palo alto research center who also first developed the explicit concept of aop and the aop language called aspectj which has gained considerable acceptance and popularity within the java developer community currently several aspectoriented programming languages are available for a variety of languages and platforms just as objectoriented programming led to the development of a large class of objectoriented development methodologies aop has encouraged a nascent set of software engineering technologies including methodologies for dealing with aspects modeling techniques often based on the ideas of the unified modeling language uml and testing technology for assessing the effectiveness of aspect approaches aosd now refers to a wide range of software development techniques that support the modularization of crosscutting concerns in a software system from requirement engineering to business process management analysis and design architecture programming and implementation techniques testing and software maintenance techniques aspectoriented software development has constantly gained in popularity and is the subject of an annual conference the international conference on aspectoriented software development held for the first time in 2002 in enschede the netherlands aosd is a rapidly evolving area it is a popular topic of software engineering research especially in europe where research activities on aosd are coordinated by the european network of excellence on aspectoriented software development aosdeurope funded by the european commission motivation crosscutting concerns figure 3 an uml architecture diagram for a telecom component the motivation for aspectoriented programming approaches stem from the problems caused by code scattering and tangling the purpose of aspectoriented software development is to provide systematic means to modularize crosscutting concerns the implementation of a concern is scattered if its code is spread out over multiple modules the concern affects the implementation of multiple modules its implementation is not modular the implementation of a concern is tangled if its code is intermixed with code that implements other concerns the module in which tangling occurs is not cohesive scattering and tangling often go together even though they are different concepts aspectoriented software development considers that code scattering and tangling are the symptoms of crosscutting concerns crosscutting concerns cannot be modularized using the decomposition mechanisms of the language object or procedures because they inherently follow different decomposition rules the implementation and integration of these concerns with the primary functional decomposition of the system causes code tangling and scattering example 1 logging in apache tomcat classloading in tomcat is a modular concern with respect to the system decomposition its implementation is contained in a small number of classes and is not intertwined with the implementation of other concerns logging in tomcat is a crosscutting concern its implementation spreads over many classes and packages and is intermixed with the implementation of many other concerns example 2 coordination of components figure 3 represents the uml architecture diagram of a telecom component each box corresponds to a process that communicates with other processes through connectors examples of crosscutting concerns see crosscutting concernexamples problems caused by scattering and tangling scattering and tangling of behavior are the symptoms that the implementation of a concern is not well modularized a concern that is not modularized does not exhibit a welldefined interface the interactions between the implementation of the concern and the modules of the system are not explicitly declared they are encoded implicitly through the dependencies and interactions between fragments of code that implement the concern and the implementation of other modules the lack of interfaces between the implementation of crosscutting concerns and the implementation of the modules of the system impedes the development the evolution and the maintenance of the system system development a module is primarily a unit of independent development it can be implemented to a large extent independently of other modules modularity is achieved through the definition of welldefined interfaces between segments of the system the lack of explicit interfaces between crosscutting concerns and the modules obtained through the functional decomposition of the system imply that the implementation of these concerns as well as the responsibility with respect to the correct implementation of these concerns cannot be assigned to independent development teams this responsibility has to be shared among different developers that work on the implementation of different modules of the system and have to integrate the crosscutting concern with the module behavior furthermore modules whose implementation is tangled with crosscutting concerns are hard to reuse in different contexts crosscutting impedes reuse of components the lack of interfaces between crosscutting concerns and other modules makes it hard to represent and reason about the overall architecture of a system as the concern is not modularized the interactions between the concern and the toplevel components of the system are hard to represent explicitly hence these concerns become hard to reason about because the dependencies between crosscutting concerns and components are not specified finally concerns that are not modularized are hard to test in isolation the dependencies of the concern with respect to behavior of other modules are not declared explicitly hence the implementation of unit test for such concerns requires knowledge about the implementation of many modules in the system system maintenance and evolution the lack of support for the modular implementation of crosscutting concerns is especially problematic when the implementation of this concern needs to be modified the comprehension of the implementation of a crosscutting concern requires the inspection of the implementation of all the modules with which it interacts hence modifications of the system that affect the implementation of crosscutting concern require a manual inspection of all the locations in the code that are relevant to the crosscutting concern the system maintainer must find and correctly update a variety of poorly identified situations overview nature of aspectorientation the focus of aspectoriented software development is in the investigation and implementation of new structures for software modularity that provide support for explicit abstractions to modularize concerns aspectoriented programming approaches provide explicit abstractions for the modular implementation of concerns in design code documentation or other artifacts developed during the software lifecycle these modularized concerns are called aspects and aspectoriented approaches provide methods to compose them some approaches denote a root concern as the base various approaches provide different flexibility with respect to composition of aspects quantification and obliviousness the best known definition of the nature of aosd is due to filman and friedman which characterized aosd using the equation aspect orientation quantification obliviousness aop can be understood as the desire to make quantified statements about the behavior of programs and to have these quantifications hold over programs written by oblivious programmers aop is the desire to make statements of the form in program p whenever condition c arises perform action a over a conventionally coded program p obliviousness implies that a program has no knowledge of which aspects modify it where or when whereas quantification refers to the ability of aspects to affect multiple points in the program the notion of noninvasiveness is often preferred to the term obliviousness noninvasiveness expresses that aspects can add behavior to a program without having to perform changes in that program yet it does not assume that programs are not aware of the aspects filmans definition of aspectorientation is often considered too restrictive many aspectoriented approaches use annotations to explicitly declare the locations in the system where aspects introduce behavior these approaches require the manual inspection and modification of other modules in the system and are therefore invasive furthermore aspectorientation does not necessarily require quantification aspects can be used to isolate features whose implementation would otherwise be tangled with other features such aspects do not necessarily use quantification over multiple locations in the system the essential features of aspectoriented software development are therefore better characterized in terms of the modularity of the implementation of crosscutting concerns the abstractions provided by aspectoriented languages to enable modularization and the expressiveness of the aspectoriented composition operators concepts and terminology aspectoriented approaches provide explicit support for localizing concerns into separated modules called aspects an aspect is a module that encapsulates a concern most aspectoriented languages support the noninvasive introduction of behavior into a code base and quantification over points in the program where this behavior should be introduced these points are called join points join point model join points are points in the execution of the system such as method calls where behavior supplied by aspects is combined a join point is a point in the execution of the program which is used to define the dynamic structure of a crosscutting concern the join point model of an aspectoriented language defines the types of join points that are supported by the aspectoriented language and the possible interaction points between aspects and base modules the dynamic interpretation of join points makes it possible to expose runtime information such as the caller or callee of a method from a join point to a matching pointcut nowadays there are various join point models around and still more under development they heavily depend on the underlying programming language and ao language examples of join points are method execution method call field read and write access exception handler execution static and dynamic initialization a method call join point covers the actions of an object receiving a method call it includes all the actions that compose a method call starting after all arguments are evaluated up to return many aop approaches implement aspect behavior by weaving hooks into join point shadows which is the static projection of a join point onto the program code figure 6 illustrates possible join points in the execution of a small objectoriented program the highlighted join points include the execution of method movebyint int on a line object the calls to methods movebyint int on the point objects in the context of the line object the execution of these methods in the context of the point objects and the calls and execution of the setxint and setyint methods pointcut designators the quantification over join points is expressed at the language level this quantification may be implicit in the language structure or may be expressed using a querylike construct called a pointcut pointcuts are defined as a predicate over the syntaxtree of the program and define an interface that constrains which elements of the base program are exposed by the pointcut a pointcut picks out certain join points and values at those points the syntactic formulation of a pointcut varies from approach to approach but a pointcut can often be composed out of other pointcuts using the boolean operators and or and not pointcut expressions can concisely capture a wide range of events of interests using wildcards for example in aspectj syntax the move pointcut pointcut move callpublic figure picks out each call to figures public methods cflow poincuts identify join points based on whether they occur in the dynamic context of other join points for example in aspectj syntax cflowmove picks out each join point that occurs in the dynamic context of the join points picked out by the move pointcut pointcuts can be classified in two categories kinded pointcuts such as the call pointcut match one kind of join point using a signature nonkinded pointcuts such as the cflow pointcut match all kinds of join points using a variety of properties advice bodies an advice body is code that is executed when a join point is reached advice modularizes the functional details of a concern the order in which the advice bodies contributed by aspects and by the base may be controlled in a variety of ways including as a join point is reached before the execution proceeds with the base after the base semantics for the join point when the join point corresponds to the execution of a method an after advice can be executed after the method returned or after raising an exception as the join point is reached with explicit control over whether the base semantics is executed around advice can modify the control flow of the program more general ways to describe the ordering of advice bodies in terms of partialorder graphs have also been provided when the execution of a join point satisfies a pointcut expression the base and advice code associated with the join point are executed the advice may interact with the rest system through a join point instance containing reflective information on the context of the event that triggered the advice such as the arguments of a method call or the target instance of a call intertype declarations intertype declarations allow the programmer to modify a programs static structure such as class members and classes hierarchy new members can be inserted and classes can be pushed down the class hierarchy aspects an aspect is a module that encapsulates a concern an aspect is composed of pointcuts advice bodies and intertype declarations in some approaches an aspect may also contain classes and methods aspect weaving aspect weaver aspect weaving is a composition mechanism that coordinates aspects with the other modules of the system it is performed by a specialized compiler called an aspect weaver example figure 6 figure editor in uml figure 7 aspectoriented figure editor in uml figure 6 illustrates a classic example of a crosscutting concern in a figure editor example taken from the aosd literature the example describes an abstract shape class that can be moved in the editor whenever a shape is moved the display needs to be refreshed figure 6 also depicts two shape subclasses line and point that implement the shape functionality the display refresh concern is scattered across the implementation of both subclasses figure 7 represents an aspectoriented implementation of the same system where an aspect encapsulates the display updating functionality the move pointcut descriptor of figure 7 captures all the executions of the moveby methods of a subclass of shape and invokes the display refresh functionality after the execution proceeds the concern is modularized which makes it easier to evolve and maintain aspectoriented requirement engineering aspectoriented requirement engineering also referred to as early aspects focuses on the identification specification and representation of crosscutting properties at the requirement level examples of such properties include security mobility availability and realtime constraints crosscutting properties are requirements use cases or features that have a broadly scoped effect on other requirements or architecture components aspectoriented requirements engineering approaches are techniques that explicitly recognise the importance of clearly addressing both functional and nonfunctional crosscutting concerns in addition to noncrosscutting ones therefore these approaches focus on systematically and modularly treating reasoning about composing and subsequently tracing crosscutting functional and nonfunctional concerns via suitable abstraction representation and composition mechanisms tailored to the requirements engineering domain specific areas of excellence under the denominator of ao requirements analysis are the aspectoriented requirements process itself the aspectoriented requirements notations aspectoriented requirements tool support adoption and integration of aspectoriented requirements engineering and assessmentevaluation of aspectoriented requirements aspect oriented business process management aobpm reducing complexity is an important issue in business process management bpm area one source of complexity is rooted in the variety of concerns that a business process addresses such as security and privacy ideally these concerns should be defined separately from the business processes as they typically span several processes and they can be subject for change on a general organisational level instead of specific process level however current business process management systems do not support this kind of modelling aspect oriented business process management aobpm tries to support separation of crosscutting concerns from the core business concerns it defines a set of requirements and a formal model this model is designed using coloured petri nets cpn the approach is implemented as a service in yawl based on service oriented architecture the assessment result of current aspect oriented business process management approaches are defined based on five dimensions such as signature exposure rule composition advice relations transformation patterns and phases support the result can be seen in the following figure aspectoriented system architecture aspectoriented system architecture focuses on the localization and specification of crosscutting concerns in architectural designs crosscutting concerns that appear at the architectural level cannot be modularized by redefining the software architecture using conventional architectural abstractions aspectoriented system architecture languages propose explicit mechanisms to identify specify and evaluate aspects at the architecture design level aspectoriented architecture starts from the observation that we need to identify specify and evaluate aspects explicitly at the architecture design level aspectual architecture approaches describe steps for identifying architectural aspects this information is used to redesign a given architecture in which the architectural aspects are made explicit in this regard specific areas of excellence are the aspectoriented architecture process itself the aspectoriented architecture notations aspectoriented architecture tool support adoption and integration of aspectoriented architecture and assessmentevaluation of aspectoriented architecture aspectoriented modeling and design aspectoriented design has the same objectives as any software design activity ie characterising and specifying the behavior and structure of the software system its unique contribution to software design lies in the fact that concerns that are necessarily scattered and tangled in more traditional approaches can be modularized typically such an approach includes both a process and a language the process takes as input requirements and produces a design model the produced design model represents separate concerns and their relationships the language provides constructs that can describe the elements to be represented in the design and the relationships that can exist between those elements in particular constructs are provided to support concern modularization and the specification of concern composition with consideration for conflicts beyond that the design of each individual modularized concern compares to standard software design here specific areas of excellence areas are the aspectoriented design process itself the aspectoriented design notations aspectoriented design tool support adoption and integration of aspectoriented design and assessmentevaluation of aspectoriented design aspectoriented programming aop aspectoriented programming aop includes programming techniques and tools that support the modularization of concerns at the level of the source code just like any other programming language an aspectoriented language typically consists of two parts a language specification and an implementation hence there are two corresponding areas of concern support for language developers and support for application developers support for application developers an aspectoriented approach supports the implementation of concerns and how to compose those independently implemented concerns while the specification of such a language is the primary manual for application developers it provides obviously no guarantee that the application developer will produce highquality aspectoriented programs specific areas of excellence the crucial concepts of aspectoriented programming programming in aspectoriented languages composing software components written in any language using aspectoriented composition mechanisms or aspectoriented programming environments support for language developers excellence in constructing aspectoriented languages includes the following areas constructing languages or dsls for specific domains andor platforms and transferring implementation principles from other aspectoriented execution environments including interpreters compilers and virtual machines formal method support for aspectorientation formal methods can be used both to define aspects semantically and to analyze and verify aspectoriented systems aspectoriented programming extends programming notations with aspect modules that isolate the declaration of when the aspect should be applied join points and what actions should be taken when it is reached advice expertise in formal semantic definitions of aspect constructs is useful for language designers to provide a deep understanding of the differences among constructs aspects potentially can harm the reliability of a system to which they are woven and could invalidate essential properties that already were true of the system without the aspect it is also necessary to show that they actually do add intended crosscutting properties to the system hence numerous questions of correctness and verification are raised by aspect languages among the kinds of expertise are specially designed testing techniques to provide coverage for aspects program slicing and code analysis approaches to identify interactions among aspects and between aspects and underlying systems model checking techniques specialized for aspects and inductive techniques to verify aspectoriented systems each of the above approaches can be used to specify and analyze individual aspects relative to an existing system define conditions for composing multiple aspects correctly and detect and resolve potential interferences among aspects although some approaches are already used in aspect languages others are still subject of research and are not ready for routine industrial application nevertheless awareness of these issues is essential for language designers and for effective use of aspects especially in safetycritical contexts aspectoriented middleware middleware and aosd strongly complement each other in general areas of excellence consist of support for the application developer which includes the crucial concepts of aspect supporting middleware aspectoriented 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 hostinfrastructure middleware distribution middleware common middleware services and domainspecific middleware services adoption ibm websphere application server was is a java application server that supports java ee and web services websphere is distributed according to editions that support different features websphere uses aspectj internally to isolate features of the different editions jboss application server jboss as is a free opensource java application server that supports java ee the core of jboss as is integrated with the jboss aop aspectoriented programming language the application server uses jboss aop to deploy services such as security and transaction management oracle toplink is a java objecttorelational persistence framework that is integrated with the spring application server toplink achieves high levels of persistence transparency using spring aop sap sun microsystems uses aspectj to streamline mobile application development for the java me platform aspects are used to simplify the development of mobile applications for deployment to different operator decks and different mobile gaming community interfaces siemens soarian is a health information management system that supports seamless access to patient medical records and the definition of workflows for health provider organizations soarian uses aspectj to integrate crosscutting features such as tracing auditing and performance monitoring in the context of an agile development process motorola wi4 is a cellular infrastructure system that provides support for the wimax wireless broadband standard the wi4 control software is developed using an aspectoriented extension to the uml 20 standard called weavr weavr is used during the development for debugging and testing purposes asml is a provider of lithography systems for the semiconductor industry asml uses an aspectoriented extension to c called mirjam to modularize tracing and profiling concerns glassbox is a troubleshooting agent for java applications that automatically diagnoses common problems the glassbox inspector monitors the activity of the java virtual machine using aspectj net 35 supports aspect oriented concepts through the unity container footnotes kiczales g lamping j mendhekar a maeda c lopes c loingtier j m irwin j 1997 aspectoriented programming pdf ecoop97 proceedings of the 11th european conference on objectoriented programming lncs 1241 pp220242 citeseerx10111158660 doi101007bfb0053381 isbn3540630899 murphy gc rj walker ela baniassad mp robillard a lai ma kersten 2001 does aspectoriented programming work in communications of the acm october 2001 vol 44 no 10 7577 tarr p h ossher w harrison sm sutton jr 1999 n degrees of separation multi dimensional separation of concerns in proceedings of the 21st international conference on software engineering icse 1999 los angeles california usa ieee computer society press 107119 aspectoriented software development community and conference european network of excellence on aspectoriented software development early aspects aspectoriented requirements engineering and architecture design the aspectoriented software architecture design portal aspectoriented software engineering at lancaster early aspects for business process modeling an aspectoriented language for bpmn composition filters model demeter and adaptive programming ibm subjectoriented programming aspectoriented software development course bedir tekinerdogan bilkent university aspect oriented business process management vteaspectoriented software developmentconcepts advice aspect aspectoriented programming aspect weaver crosscutting concerns join point pointcut languages aspectc aspectj aspectwerkz vtesoftware engineeringfields computer programming requirements engineering software deployment software design software maintenance software testing systems analysis formal methods concepts data modeling enterprise architecture functional specification modeling language orthogonality programming paradigm software software archaeology software architecture software configuration management software development methodology software development process software quality software quality assurance software verification and validation structured analysis orientations agile aspectoriented object orientation ontology service orientation sdlc modelsdevelopmental agile eup executable uml incremental model iterative model prototype model rad up scrum spiral model vmodel waterfall model xp other spice cmmi data model er model function model information model metamodeling object model systems model view model languages idef uml usl sysml softwareengineers victor basili kent beck grady booch fred brooks barry boehm peter chen danese cooper ward cunningham tom demarco edsger w dijkstra delores m etter martin fowler adele goldstine margaret hamilton c a r hoare lois haibt mary jean harrold grace hopper watts humphrey michael a jackson ivar jacobson alan kay nancy leveson stephen j mellor bertrand meyer david parnas trygve reenskaug winston w royce james rumbaugh mary shaw peri tarr elaine weyuker niklaus wirth edward yourdon related fields computer science computer engineering project management risk management systems engineering category commons 