Object technology has difficulty localizing concerns involving global constraints and pandemic behaviors, appropriately segregating concerns, and applying domain-specific knowledge.¹

What Is Aspect Oriented Programming?

Aspect Oriented Programming (AOP) provides the ability to intercept code execution with the purpose of inserting a process before, in place of, or after the code that would normally execute. When you consider that everything, calling a method, returning from a method, retrieving or assigning a value, handling exceptions, switching context, etc., consists of code execution, you can begin to think about how such a capability would be used. If that satisfies your curiosity, then read no further. However, this definition is so simple that the reasons behind why one would use AOP are completely lost. Be warned also that this definition speaks only to a particular implementation which, in the opinion of this author, has actually nothing to do with Aspect Oriented Software Design (or Development, the terms seem to be interchangeable even if the acronym is the same) - AOSD. Furthermore, AOSD is itself a subset of post-object programming (POP) technologies. Unfortunately, pursuing AOP and AOSD gets us quickly lost in a quagmire of bizarre terminology and custom languages and extensions. This article is intended to provide a concise understanding of not only AOP but the more general issues of AOSD. Like many of the recent paradigms intended to solve some of the problems arising with complex software development, AOSD contains gems of wisdom within the effluence of actual implementations.

Success at developing simpler systems leads to aspirations for greater complexity¹

Why Aspect Oriented Software Design?

The predominant reason for AOSD is to help solve the issue of messy object architectures. The proponents of AOSD claim that object oriented programming has difficulty dealing with global information. Also, functionality that requires the involvement of several different objects (possibly collected into a component) results in interdependency between those objects/components. This makes the application susceptible to the implementation changes of a dependent object/component. Maintenance and enhancement are also problems, as the interaction between these objects/components (regardless of whether the rules of interaction are coded formally or informally) are typically hard coded within the containing object. If this is confusing in itself, consider that in these statements, the terminology of AOSD to explain the reason for AOSD is specifically avoided. This is intentional so as to avoid putting the cart before the horse. Attempting to understand AOSD can be very confusing when immediately immersed in the terminology of AOSD, with no glossary in sight.

Messy object architectures occur when something that the application needs to do requires the involvement of many different objects. Given a requirement specification, Object Oriented Design (OOD) often proceeds by determining the objects that are necessary to support the requirements. The goal is to compartmentalize functionality as determined by an analysis of the requirements until sufficient abstraction occurs (among other goals of OOD). Throughout this process, the designer often loses sight of the fact that ultimately these objects are going to need to interact with each other in order to meet the requirements with actual functionality. This happens easily and subconsciously because the way requirements interact is often fundamentally different from the way objects interact. The concepts described in Design Patterns are an attempt to formally understand the issues of object interaction and to provide the designer with some well understood and supported means for solving this object interdependency problem. In fact, the primary implementation of an AOP language, that being AspectJ, relies heavily on the Observer design pattern. However, one of the criticisms made by AOSD proponents is that, beside there being too many design patterns (and ever growing), these patterns are often "designed in" too early in the design process. As a result, designs must be redone, or even worse, implementation must be reworked when a different design pattern is required. Another criticism is the interaction between design patterns and system structure. A design pattern not only influences system architecture, but is itself influenced by system architecture. As a result, the design pattern loses its modularity as it disappears in the implementation. This often affects re-usability, as the design pattern (a reusable component) and the object model (another reusable component) become integrated into a more rigid, less re-usable, component.

Personally, while I agree with the reality of this observation, I disagree that this indicates some flaw with the concept of design patterns. Rather, I feel it is indicative of incomplete requirements and analysis, a lack of education and training on the part of the designer/developer, and a poor project leadership (someone should be smarter than everyone else!). If you accept this counter argument, then it also deflates the premise that AOSD is the cure to bad object architectures. Another consideration is that none of these paradigms give any indication as to when they should be used. Many useful applications, including web-based applications (where complex object interdependencies are difficult to maintain between page refreshes), do not encounter the problems that AOSD attempts to address. AOSD (and similar paradigms) begin to be useful only when an application crosses the boundary between automating simple tasks (like a simple text editor with cut and paste and print capability) and automating complex processes made of up multiple tasks (like a word processor that provides embedded graphics, line drawing, spell checking, layout and formatting tools, collaboration, security, and integration with other applications). Where this boundary is, and when to make the shift in the design paradigm, is still an art. My experiences have taught me that the vague requirements, ill-defined use cases, and potentially limitless enhancement are indicators that I should consider these issues at the very beginning of the project and design accordingly.

Aspectual requirements are concerns that introduce crosscutting in the implementation¹

Terminology

So far, I have avoided using any of the terminology that comes along with AOSD/AOP, trying to stick with well known object oriented terms instead. Having at least a rudimentary knowledge of the terminology is necessary, if for no other reason than to throw out a bunch of buzzwords at your next interview. Good definitions of the terminology are rather elusive, in part because these terms are not used very precisely (and therefore no one wants to define them), the concepts of AOSD continue to evolve (and therefore the terms take on new meanings), and because academia continues to exhibit a tendency towards terminology that convey little meaning without the surrounding context.

Concerns

A concern in the AOSD world has several definitions, but the one I like best is the IEEE definition: “... those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders.” Still, this isn't very helpful in bringing the definition into a real world context, but it does encapsulate the stages of application development, enumerated loosely as:

Requirements Gathering
Design
Prototyping
Implementation
Testing
Delivery
Maintenance

Each of these phases is of interest to one or more parties, or stakeholders (to name a few):

The customer
Management
The development team
The database group
The library/component developers
The QA team
Marketing
Production
Documentation/Help authoring
Tech support
The application itself

Note the last entry, "the application itself". It is important to realize that the application itself is a stakeholder, having concerns over issues such as:

security
performance
optimization
accuracy
data representation
data flow
portability
traceability
profiling

While this last list of concerns are "held" by different people, the application itself has a stake in these issues as it directly affects implementation and rework issues. Regardless of the front-end design work, many of the problems in this last category are not revealed until most of the components have been glued together and the product is nearly complete. Hence the expression, 90% of the work is done in the last 10% of the development. If AOSD has anything of value to contribute to software development, it is in the fact that it brings these concerns to consciousness and lets the whole entity involved in the software production consider these concerns from different points of view.

Viewpoint

This term is not commonly seen in AOSD/AOP circles, but it is worthy of mentioning. A viewpoint is a way of looking at the entire system from different positions and determining the concerns based on those positions. Software suppliers and customers have different viewpoints regarding the process of software construction. Within these two groups (and this is not to imply that there are only two groups), the suppliers have different viewpoints (management, engineer, technical support, etc) as does the customer (management, accountant, data entry person, for example). One of the concerns that I frequently deal with from the viewpoint of the "office girls" is twofold--"is this going to be hard to learn?" and "who's going to provide training?". Ironically, managers seem to forget to ask this question themselves and simultaneously seem to consider themselves immune from both needing training and actually using the end product.

Separation Of Concerns

This is an analysis of the concerns that exist in the development of the application. Each stakeholder has a different set of concerns regarding his/her/its involvement in the application. The separation of concerns is an important analysis in that it identifies the areas in which the physical implementation (see artifacts) ends up involving multiple stakeholders, be they departmental/organizational interests or objects. Looking at concerns from different viewpoints aids in the process of separation of concerns. Requirements often do not explicitly state when a concern involves multiple stakeholders. Instead, a requirement document often states concerns in terms of the specific department's needs. The same is true for object design (hence the "it" above), in which an object design specifies its concern from the point of view of expected inputs, resulting outputs, and manipulating methods, without regard to the system as a whole. Separating the different concerns (which implies identifying them correctly) is therefore a vital step in later on determining the actual flow of information in the application (see crosscutting).

The purpose of separation of concerns is to identify areas that can be designed and implemented in a decentralized way. This allows separate teams to work in parallel and to have independent and autonomous decision making processes. Even simple applications take advantage of this concept. Consider for example a simple network messaging application. The application relies on the fact that network protocols have been developed completely independently and reliably, thus the programmer need not "concern" him/herself with that issue. From a different point of view, large applications (consider the software needed to run the space shuttle) must separate its concerns into manageable "chunks" if work is to be accomplished in a reasonable timeframe. However, this leads to the issue that AOSD tries to address, namely the re-integration of these separate concerns. At the end of the day (metaphorically speaking) all the different pieces have to be put back together in a meaningful and consistent manner. AOSD is a tool for detecting problem areas in this process.

Artifacts

From the point of view of AOSD, concerns are usually conceptual, whereas "artifacts" are concrete constructions motivated by the concern. This introduces some confusion as to when something is a concern and when it is an artifact. The rule of thumb is that if it is a concept (for example, a requirements property), then it is a concern. If it is a concrete construction (the object's implementation, for example), then it is an artifact. The term "artifact" is not commonly used in the AOSD world. Be that as it may, it is useful to view concerns and artifacts as separate entities so that both can be considered independently of each other. This helps the designer to think of concerns independent of their effect on the implementation (artifacts). As a consultant, I have found this technique to be invaluable, as it helps me identify problems in communication between departments, problems in existing manual processes, conflicts in departmental/personnel goals, etc. As a result, I often spend more than half of my time documenting and fixing processes completely unrelated to programming, all without writing a single line of code. Alternatively, if I immerse myself too quickly in the design of objects (artifacts), I never notice that there are conflicts and disconnects in the different concerns until I am too far involved in the project design/implementation. I then have to either fix the design/implementation, forcibly change the existing processes, or both. The end result is that I am seen as the cause for the late software delivery or much angst amongst the workerbees. By viewing concerns and artifacts separately, I can resolve design/implementation issues before a single line of code is even written. A side effect of this approach is that by getting the kinks out of its processes, a company starts saving money immediately. And they thought they needed a program to do this!

One of the purposes of separating a concern from and artifact is to help create programming languages (see "formalism" below) that can represent the concern without dealing with the implementation (artifact) details. To date, this is very limited. Interested readers should refer to AspectJ, (a Java extension), Cosmos (a tool for modeling concerns), and CoCompose (a design approach).

Crosscutting

Crosscutting is a term used to describe implementations in which the application interfaces with multiple artifacts. (See, we can begin to use the terminology now). Since artifacts are physical implementations of different concerns, crosscutting therefore typically involves an operation (or workflow) that is trying to address several concerns. Since the artifacts representing these concerns are typically implemented as autonomous objects (because we're all trying to promote re-use), we end up with messy code. Often objects are passed into other objects (void ObjectD::DoSomething(ObjectA* a, ObjectB* b, ObjectC* c)) or are acquired through global mechanisms (AfxGetMainWnd()). This is the crux of AOSD - the criticism that complex object oriented implementations contain interdependencies that make it difficult to debug, test, maintain, and extend functionality. By explicitly identifying when and where crosscutting occurs, AOSD provides a mechanism for identifying global interdependencies so that the tenets of OOD, namely modularity and re-use, are realized. (Eek, I'm beginning to sound like the articles I've been reading).

Aspect

Finally we can explain the meaning of the very first word in the acronym AOSD. An aspect is nothing more than something that forces crosscutting in the implementation. While crosscutting is the implementation of a process that uses multiple artifacts to perform its task, an aspect is the situation in which this occurs. AOSD is the technique of identifying the aspects, or situations, in which implementation results in the crosscutting of artifacts. What this really means is that a requirements document rarely specifies things holistically. Instead, a requirements document is a collection of needs put together by different groups, each without regard to one another. This omission often doesn't get discovered until the object design has been completed and the issue of coupling the objects together to perform specific processes (or workflows) arises. I've seen many designs where this step is omitted. If it is not omitted, then everyone pulls out their Design Patterns book, identifies the applicable design patterns to help tie disparate objects together, draws a few more objects on the object diagram, and everyone goes happily off to start coding. If I were Mr. Aosd sitting in on these design meetings, I would cry "halt!" and explain patiently that a meta-level of design is still necessary to keep the design patterns and objects from getting entangled. This would also involve pointing out that probably only 10% (if that) of the aspects that are forcing crosscutting have been properly identified. And, since most languages do not implement AOSD directly, it is necessary to implement a framework that deals properly with these aspects so that our design pattern and object modularity/re-use is maintained. (What a wonderful segue to the Application Automation Layer!)

Unfortunately, in at least one article on separation of concerns, the authors defined "aspect" as properties of a component. This is in conflict with the AOSD/AOP definition more frequently encountered.

Weaving

Weaving is then the strange term used to describe whatever solution is used to resolve aspectual problems. (Hah, and you thought I couldn't use that word). Because this involves physical implementations (artifacts), weaving solutions are pretty much arbitrary, just as long as the resulting efforts create a coherent system. The term "weaving" probably came about as a result of the mental picture formed by using AOP language extensions such as AspectJ. Recall my simple definition of AOP - the ability to intercept code execution with the purpose of inserting a process before, in place of, or after the code that would normally execute. AOSD implementations "weave" solutions to aspectual problems (!) into existing code by injecting pre, post, and "around" processes. (In other words, this author feels that the term "weaving" is ridiculous and by itself justifies all his other rants about academia and buzzwords).

Component

The definition for this term is included here, not so much because it is used in AOSD (which it often isn't) but because this article uses it. The term component has become fuzzy within the Microsoft development universe, as it now relates to non-trivial GUI controls. For the purposes of this article, the term component is defined as "...an encapsulated, autonomous service provider that delivers useful services through well-specified interfaces to the wider context inside which it exists and collaborates with other components towards a common goal."⁵ Consider the of this definition, namely "...and collaborates with other components..." which implies crosscutting in its implementation. Hmmm.

Formalism

A programming language. (No, I'm not kidding).

Without proper attention to concerns during the design of the system, it will be hard to manage complexity, readability, the evolution and composition of the system²

A Case Study

Let's see how this works, taking boatyard operations management as an example (one of my clients).

Concerns

First, a general statement concerning the handling of a part. Keep in mind that when I started to look at automating their operations, none of this was written down in any coherent manner. This was the result of 20 years of verbal "know-how", and was conveyed to me verbally over several weeks. Formal processes, diagrams, etc. were completely lacking. As a result job training was expensive and lots of mistakes were made. I find it ironic that someone can demand perfection from a computer system when the system that it is replacing is so imperfect.

Being a full service boatyard, customers are basically not allowed to work on their own boats, except for minor internal work. This is partly due to environmental regulations and partly because it increases profit. Any parts that a customer needs for their boat are handled through the store front and are typically sold at retail, unless otherwise specified by the yard manager. Customers pay for their parts by cash, credit card, check, or on account through the marine store. Typically, however, parts are used for all repair and maintenance performed on the customer's boat. The mechanic is informed that work needs to be done on a boat when the yard manager writes up a work order, authorized by the customer in some fashion (usually verbal). With work order in hand, the mechanic begins work, which may require parts. Parts are either in stock, out of stock, or are special order. Assuming that the part is in stock, the mechanic goes to the parts desk and asks for the necessary part. At billing time, all the parts used on the various work orders are tallied, taxed, and billed to the customer. Occasionally, the yard manager will negotiate a special price that is to be given to the customer. This happens often when the customer knows the competition is selling the part for less. This almost always happens on special order parts, which the yard manager knows about when issuing the work order. The yard manager will also fill out a material request form, specifying the part and the price. The purchasing person is responsible for ordering the part and making sure it's in inventory in time for when the mechanic needs it. Finally, the yard manager often specifies that all work for the customer is to be billed out at a discount, or that only certain work orders have discounts applied. Otherwise, the part is billed out at retail. The purchasing department is interested in knowing what parts are used on which work orders so that inventory purchases can be better estimated in the future, and the yard manager wants to know in case there are any cost cutting measures that can be employed. The boatyard also has an accountant that is very interested in getting a grip on how parts are bought and sold, as the boatyard is currently taking a $15,000 inventory write-off every month - parts are being purchased but appear to be disappearing down a black hole. Of course, the owner thinks it's employee theft. As this is a completely manual process, any software that attempts to automate these processes must ensure that inventory is accurately debited and that parts are correctly billed to the customer. Oh, one more thing. Keep in mind that the boatyard also owns and operates several boats itself--launches to get people to and from their boats, charter boats, etc. These boats also need repair and maintenance, and parts need to be correctly billed to the boatyard's own accounts for tax purposes. All parts associated with boatyard work are sold to the boatyard "at cost".

Within the scope of this case study, let's look at how we could rewrite this statement in terms of "concerns".

The Yard Manager

The yard manager is concerned with:

Discounts associated with a work order
Discounts associated with the customer
Special pricing for special orders
Parts used on the work order
Efficiency

The Purchasing Department

The purchasing department is concerned with:

Debiting inventory when a part is sold, either through the marine store or over the parts counter
Purchasing special order parts
Restocking inventory

The Accountant

The accountant is concerned with:

Inventory levels and values
The $15,000 a month write-off
The correct billing of parts to either the customer or the boatyard
Taxes

The Billing Department

The billing department (or accounts receivable) is concerned with:

Billing the customer for all the parts used for a specified time period

The Owner

The owner is concerned about:

Employee theft

Boatyard Concerns

Before confusing the issue by considering artifacts (components, objects, and other structural implementations), let's look just at the concerns themselves and see what we can learn. The concern of the accountant (the $15,000 write-off) and the owner (who's stealing my stuff?) are actually issues involving a common theme that can be applied to any process or concern: validation, error correction, and exception handling. This reveals some systemic problems:

How does the yard manager verify that the customer is correctly billed as per the material request?
Who verifies that stock is properly debited from inventory?
Who verifies that parts, special order or not, are being correctly added to the work order?
Who is responsible for determining the retail price and taking the discount?
What happens when the yard manager forgets to inform this "magic person" that a discount should be applied to the customer's parts?
What happens when the cost of the part is more than the price the yard manager quoted to the customer?
Who verifies that parts are being correctly billed to boatyard owned boats?
Are work orders always created before work begins on a boat, or are there exceptions?

These are just some of the questions arise from looking at the various concerns. It cannot be overstated, and therefore I will state it again: all concerns need to be viewed from the point of view of validation, error correction, and exception handling. These are not programming issues. These are process issues: how does the existing business process handle these situations? However, they will always reveal major problems in the existing process, affect decisions on implementation, and result in time and cost overruns from your original estimation of the project. By using AOSD to identify concerns and then applying this basic rule of them, you can discover a great deal about the system without designing a single component or writing a line of code.

For the fun of it, I'm going to answer these questions based on how the boatyard was operating when I arrived on the scene.

How does the yard manager verify that the customer is correctly billed as per the material request?
By reviewing each bill. If the yard manager remembers the special order, then there's a chance of catching a mistake.
Who verifies that stock is properly debited from inventory?
Nobody. Standard inventory accuracy mechanisms such as cycle counts are not being performed.
Who verifies that parts, special order or not, are being correctly added to the work order?
The yard manager has a "feel" for what parts a job requires.
Who is responsible for determining the retail price and taking the discount?
Basically, no one. Essentially, the purchasing department sets the price based on the manufacturer's suggested retail price (MSRP), but parts often do not have an MSRP, so it's rather arbitrary.
What happens when the yard manager forgets to inform this "magic person" that a discount should be applied to the customer's parts?
The accounting department must make manual changes to the bill. If the bill isn't caught in time, then a credit memo is issued, which shows up next time on the customer's bill.
What happens when the cost of the part is more than the price the yard manager quoted to the customer?
Nothing. The company eats the loss. Furthermore, the loss is not conveyed to the accountant, so it never shows up as a loss.
Who verifies that parts are being correctly billed to boatyard owned boats?
No one. There is no accounting for parts billed against boatyard owned boat. The accountant estimates monthly billing.
Are work orders always created before work begins on a boat, or are there exceptions.
No. Often, during busy times, a verbal work order is issued.

Looks can be deceptive but distinctions are clear⁴

Lessons Learned

Not applying AOSD techniques when I started looking at yard processes and automation, I ended up spending about three to four months going in completely wrong directions because I didn't understand the depth of the problem. The ironic thing is that I've been doing process automation for several years and I should have known better. However, outward appearances can be deceiving. This particular boatyard looks extremely well run from the outside (which is exactly how they want the customer to see them), but internally, things are running amok. The customer that called because he never got billed for a $6,000 dinghy that he bought six months earlier (this actually happened) perhaps got a better understanding of the internal problems.

Artifacts (Objects And Components)

Now I'm going to take the daring step of determining a rudimentary set of components from the concerns themselves as opposed to any formal requirements document. This takes us away from the abstract issues of concerns and returns us to the more concrete issues of design and implementation. The following components can be identified through the semantics of the general statement and the concerns:

Work orders
Material requests
Customer Account
Inventory
Invoice (the bill)
Part
Discounts

These appear to be reasonable components regardless of implementation details and locale (for example, in memory objects, XML data, database tables, etc). Depending on requirements, these components may exist in all of these forms and others.

Boilerplate Concerns

An interesting step to perform at this point is to consider the concerns of these artifacts. Boilerplate concerns for artifacts include issues such as:

object/information creation date/time
closure date/time
active, inactive, or deleted
update/change history
error checking
exception handling
integrity of information
logging

Notice that these concerns can and are handled internally in the component--for the most part they do not require interaction with other components. The exceptions to this are the last three items, exception handling, integrity of information (generating problem alerts) and logging, which may involve other "helper" components. These are just a few of the common concerns a component may have, regardless of requirements. Designing components with these concerns in mind can be very helpful later on when the application's complexity increases and new features are added. Besides these boilerplate concerns, application specific concerns can also be determined from the requirements document and during product development.

In the actual system provided to the customer, only some of these concerns were addressed. I regret at this point that concerns such as change history were not part of the original implementation. However, because the implementation deals well with the issues of crosscutting (having used the Application Automation Layer framework!) the implementation of additional concerns is straightforward and will not break the existing system.

Crosscutting

Taking a single process, the determination of the price of the part, illustrates the crosscutting of implementation (in this case, the components described above). Even at this early design stage, without getting into the implementation details of each component, it can be demonstrated that determining the price of a part as it should appear on the customer's bill is something that involves many different components of the system. The following diagram illustrates this using the concept of a "back box" to determine the price.

Unfortunately, AOSD does not really provide any guidelines as to how to handle this crosscutting, other than helping to identify its existence. The concept of "weaving", which will be discussed below in the AspectJ section, is an attempt to provide a formalism (language implementation) to solve the problems introduced with crosscutting.

Aspects

In the above example, the price calculation is an aspect because it forces the crosscutting of component implementation. I suppose the proper usage would be "the price calculation aspect".

Like many of the recent paradigms intended to solve some of the problems arising with complex software development, AOSD contains gems of wisdom within the effluence of actual implementations³

AspectJ

Let the reader beware that I am not a Java programmer, and if I have any say in it, I hopefully never will be. Therefore, this section will be fairly brief. You can consult the references section below if you wish to explore the full syntax of this language extension. That said, there are some interesting (perhaps the more appropriate term should be "bizarre") capabilities in this language extension that are worth reading about. To demonstrate the implementation, some additional terminology needs to be defined, and within those definitions you will find example usage and further discussion.

Join Point

A join point is any point in the program execution that is "well defined". From the point of view of a high level language, this would be places where methods are called, data is accessed, values are stored, object creation and destruction (except for garbage collecting languages), exception handlers, etc. This basically excludes arithmetic and boolean operations (unless overloaded or dealing with setter/getter fields), and from the low level assembly language perspective, the intermediate machine instructions that are necessary to carry out a high level instruction.

Discussion

You may think that C#'s "set" and "get" language constructs abstract the concept of a join point for attributes, or C#'s and C++'s inheritance and overloading features abstract the concept of a join point for methods and operators. This is not the case. The issues involved in join points really require that the language supports the concept directly as "first class citizens" as opposed to using existing object oriented techniques. This is mainly due to the richness in how join points can be intercepted and the manual labor that would be required to simulate this concept in existing language constructs (see "pointcut" below).

Pointcut

A pointcut (or pointcut designator) is the specification for selecting a join point in the program. Given a join point (a place in the program execution in which you are interested), the pointcut is the syntax and mechanism that you use to convey your interest in the join point to the compiler or interpreter using a formal syntax. Unfortunately, you will see sentences like "code that is run when a pointcut is reached" which is confusing, to say the least. The pointcut vectors program execution to the "advice" (see below) when program execution reaches the join point. This obfuscation in terminology makes it very difficult to not only understand but also to buy in to the language extensions proposed in AspectJ.

Usage

Given an object Point, a pointcut that specifies the interception of changes to the object Point would look like this [6]:

pointcut fieldChanged(Point changed) : 
call( * Point.set*(..)) && target(changed);

Discussion

One of the interesting (bizarre) features of this language extension is the use of wildcards. You can create a pointcut on all function calls by specifying "call (*.*(..))" as a pointcut. You can specify pointcuts for all methods in a class by specifying "call (Point.*(..))" as the pointcut. Another area of control is the ability to specify the source of the call. If you have two classes, Line and Rectangle, this feature allows you to distinguish and specify different pointcuts in the cases when Line manipulates Point vs. when Rectangle manipulates Point. These can be nested to any level. There are also additional constructs that provide further complexity, such "within", "withincode", "cflow" and "cflowbelow", which I will not describe here.

Advice

Advice is the code that is executed when the join point specified by the pointcut is reached. Within the advice, you can specify code that is to run before, after, and/or instead of ("around") the code that is intercepted (or cut). Advice, or enhancements, are "woven" into the existing implementation through this mechanism.

Usage [6]:

after(Point changed ) : fieldChanged(changed)
         {
         changed.makeDirty();
         }

Discussion

Harking from the days of assembly language programming, this sounds like nothing more than a glorified "patch". Moreover, the pointcut specification is closely tied with architectural implementation, program flow, and class implementation. This results in more side effects, not less, when the implementation changes. Also, this kind of implementation complicates testing as it expands the number of pathways that code can be reached and the decision made that determine code execution. While this language extension provides some interesting food for thought, I simply cannot believe that it can be considered a solution to the crosscutting problems determined with by AOSD. Proponents of AspectJ will argue that it allows for the easy addition of such capabilities as logging and security checking. These are simplistic examples that are handled better by existing mechanisms such as refactoring, and frankly, by better up front design. Using this language extension, an application will quickly evolve into a patchwork of pointcut specifications that reduce the readability of the code to nil as the coherent fabric of the code has a patchwork of intercepts woven into it. Also, this language extensions appears inappropriate for complex (dare I say "real world") examples such as the case study discussed above.

At its essence, AOP is a programming technique¹

Conclusions

Obviously, AOSD is not the perfect solution to the issues involved in software production, but it is a good starting point if you haven't formulated your own yet. With experience, you should be able to fine tune the concepts of AOSD to better fit your own work environment, customer base, team members, etc. There is little language support in the mainstream language set for AOSD solutions. Personally, I believe that language extensions are completely the wrong direction to take. If anything, they defeat the purpose of AOSD because, at least with AspectJ, it seems that even tighter coupling between components results. Furthermore, a separate specification of program flow merely adds to the programmer's confusion and need to keep track of separate but related implementation details. Instead, the issues that AOSD raises can be better addressed within the existing tools (such as design patterns) and languages (such as C#, C++) by designing appropriate frameworks to manage crosscutting. One such proposed solution by this author (yet another plug for the AAL) achieves this by eliminating unnecessary object constructs, viewing data as a separate an event capable entity, and providing a workflow mechanism via a scripting language to glue together the autonomous components to achieve the desired process.

References

As this is not a formal paper (and because I'm too lazy), I haven't put any footnotes in the article itself as to what other authors I am referencing when I make certain statements. I can hear the university police banging down my door now. Regardless, the following references, all of which are locatable on the Internet (some through the ACM, an excellent online source of programming techniques), are for the most part excellent sources of information on AOP, AOSD, and AspectJ. If you read them yourself, you'll be able to figure out whom I'm paraphrasing and where. For those authors that might be offended, please note that nowhere in this article have I directly quoted you, unless specifically noted. I much prefer to paraphrase and rewrite so that the general programming community has some chance of understanding what you're all actually talking about.

¹Elrad, Filman, and Bader, October 2001/Vol. 44, No. 10 COMMUNICATIONS OF THE ACM
²AOSD, AOSD 2002--1st International Conference Aspect-Oriented Software Development, http://trese.cs.utwente.nl/aosd2002/
³Marc Clifton
⁴Peter Gabriel
⁵Stojanovic and Dahanayake. Components and Viewpoints as Integrated Separations of Concerns in System Designing
⁶SDSU, Aspect Oriented Programming, CS683: http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/progguide/index.html
Batenin and O'Neill. Towards Unanticipated Composition of Concerns in Hyperspaces
Chitchyan, Sommerville, and Rashid. An Analysis of Design Approaches for Crosscutting Concerns
Graversen and Beyer. Conceptual programming using roles
Sutton and Tarr. Aspect-Oriented Design Needs Concern Modeling
Wagelaar and Bergmans. Using A Concept-Based Approach To Aspect-Oriented Software Design
Akkawi, Bader, and Elrad. Dynamic Weaving for Building Reconfigurable Software Systems
Tucker and Krishamurthi. Pointcuts and Advice in HigherOrder Languages
Hannemann and Kiczales. Design Pattern Implementation in Java and AspectJ
Clarke and Walker. Towards a Standard Design Language for AOSD

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Aspect Oriented Programming / Aspect Oriented Software Design

Table Of Contents

Section I

Section II

The Yard Manager

The Purchasing Department

The Accountant

The Billing Department

The Owner

Boatyard Concerns

Lessons Learned

Boilerplate Concerns

Aspects

Discussion

Usage

Discussion

Usage [6]:

Discussion

License