What is Aspect Oriented Architecture (AOA/AOP)

[bri189a]

Is this just a buzz word for using attributes smartly? That's what I gather.

[Diesel]

Aspect-Oriented Software Development (AOSD) is an emerging technology that provides explicit abstractions and mechanisms to model concerns that tend to crosscut multiple system components. Existing aspect-oriented software development approaches have basically focused on identifying the aspects at the programming level and less attention has been taken on the impact of crosscutting concerns at the architecture design level. In a fashion similar to traditional software engineering (procedural, functional, logic, object-oriented), aspect-orientation is now starting to follow a cycle of natural progression from programming up to design and analysis phases. Despite the interest and the recognition of its importance, there is still a lack of appropriate techniques to identify concerns at the software architecture design level.

 

 

To solve the above problems is is worthwhile to integrate the ideas in software architecture design and aspect-oriented software development, and for this the term Aspect-Oriented Software Architecture Design is coined. From a software architecture design perspective this will improve and broaden the understanding of the identification and management of architecture design concerns. In this way, not only functional components will be addressed as architecture design components, but also crosscutting architectural concerns will be explicitly handled. From an aspect-orientation perspective this project will enhance the understanding of aspects at the earlier phases of the software development process, and likewise will improve the aspect-orientation approach through the overall software life cycle.

 

taken from: trese.cs.utwente.nl/taosad/

 

 

Sounds very abstract right now.

Edited September 17, 2005 by Diesel

[bri189a]

Yeah... if anyone can put that in plain english that would be great. You know the old robot anology for OOP? That's kind of the level I grasp on to better.

[Jaco]

Yeah... if anyone can put that in plain english that would be great. You know the old robot anology for OOP? That's kind of the level I grasp on to better.

 

An example you'll see often for AOP is exception handling. You might want to have all methods in a class implement the same kind of exception handling - AOP can allow you to not have to specify the exception handlers in each method. When you think about it, that's a lot of code you have to enter when you're often just saying the same thing. AOP allows you to say to the AOP compiler: "this class has this type of exception handling, so just assume it - don't force me to spell it out everywhere".

 

AOP complements OOP - it will get us further to the "an idea should be expressed in only one place" concept. Even if you max out OOP, you'll still have a lot of copied ideas, such as exception handling - AOP deals with a lot of duplicate code that can't be handled by OOP.

[Nerseus]

Take a look at the Wikipedia: http://en.wikipedia.org/wiki/Aspect_oriented

Here's a snippet:

 

For example, consider a banking application. The method for transferring an amount from one account to another is conceptually very simple:

 

void transfer(Account fromAccount, Account toAccount, int amount) {
 if (fromAccount.getBalance() < amount) {
   throw new InsufficientFundsException();
 }

 fromAccount.withdraw(amount);
 toAccount.deposit(amount);
}

 

(the examples are shown in a Java-like syntax, since at the time of writing, an overwhelming majority of AOP-related research and work is done in Java or Java-variants.)

 

However, in a real-world banking application, this transfer method is far from being sufficient. We must include security checks to verify that the current user is authorized to perform this operation. We must enclose the operation in a database transaction, to prevent accidental data loss. We must log the operation to the system log. And so on. A very simplified version with all those new concerns would look somewhat like this:

 

void transfer(Account fromAccount, Account toAccount, int amount) {
 if (!getCurrentUser().canPerform(OP_TRANSFER)) {
   throw new SecurityException();
 }

 Transaction tx = database.newTransaction();

 if (fromAccount.getBalance() < amount) {
   tx.rollback();
   throw new InsufficientFundsException();
 }

 fromAccount.withdraw(amount);
 toAcount.deposit(amount);

 systemLog.logOperation(OP_TRANSFER, fromAccount, toAccount, amount);

 tx.commit();
}

 

The code is no longer simple and elegant. This is because the various new concerns are tangled with the basic functionality (sometimes called the business logic concern). The transactions, security, logging, etc. are all examples of cross-cutting concerns.