lthough AOP and MDA were developed from very different viewpoints: programming vs. modeling; weaving many inputs into one output vs. creating many outputs from one input, there is a great deal of common ground between them and both techniques are used for identical purposes. There is no need to choose between them. They complement each other and can be used together successfully.

One very positive aspect of both AOP and MDA is that they have brought our attention back to issues like modularization and abstraction; issues that were considered to be very important in the 1980s, but slipped away in the 1990s. You should not forget that the attention to these issues was very fruitful?it was the driving force behind the advent of object-oriented programming and object-oriented modeling, and as such, has brought us the UML. It will be very interesting to see what it will bring us in the 21st century. It may be called MDA, AOP, or it may have a completely different name, but it will no doubt be an important step forward for the industry.

Aspect-oriented Programming
The key to AOP is modularization. Each program contains aspects that are not specific for that application domain. For instance, the way error handling, logging, or tracing is handled is often identical over multiple domains. AOP tells us that these aspects should be contained in different modules, and indeed aspect is the name used for such a module. The modules that contain the application-specific code and the non-specific aspect module, or modules, are then woven together to create the application. (See Figure 1.)

Figure 1. Aspect Weaving: Application code and aspects are woven together to get the finished product in AOP.

The application-specific code and the aspects can be developed independently. The application-specific code need not know what aspects will be added, leaving the developer to concentrate on implementing the required functionality?the business logic. Likewise, the author of the aspects does not need to know the application-specific code. The only knowledge necessary for writing aspects would be the join points. Join points are identifiable events in the execution of a program. The developer of a logging aspect, for instance, would have to know about method calls and the aspect would specify that whenever a method is called, a message would be added to the log.

Join points can be identified by the aspect using pointcut expressions. Pointcut expressions specify join points, much as classes specify object instances. In the example below, the pointcut publicMethods is defined to include all methods of any class in the package org.apache.cactus or any of its subpackages. Before execution of such a method the Logger.entry() method is called, and after execution a call to the Logger.exit() method is placed.

 public aspect AutoLog{    pointcut publicMethods() :            execution(public * org.apache.cactus..*(..));    before() : publicMethods(){        Logger.entry(thisJoinPoint.getSignature().toString());    }    after() : publicMethods(){        Logger.exit(thisJoinPoint.getSignature().toString());    }} 

Another term you need is advice, this is the set of statements that should be executed whenever a join point occurs. In the AutoLog example above, there are two advices: the before and after advice. The last term that you should be familiar with is crosscutting concerns. This is behavior that cuts across the typical divisions of responsibility, such as logging. Aspects are most-often used to define such crosscutting concerns.

There are different forms of AOP. The Java-based AspectJ is probably the best-known aspect-oriented language. Other well-known examples are Spring AOP and AspectC++. See AOSD.net for more tools and aspect-oriented languages.

In short, AOP takes two or more disjointed parts of an application and weaves them together to produce the final result. The link between the parts is formed by join points, which are specified by pointcuts. Aspects are commonly used for logging, tracing, debugging, and profiling, or performance monitoring or testing of diagnostic systems, and to display updated notifications, mainly security, context passing, and error handling.

Model Driven Architecture
The key to MDA is that most applications are built using a number of different languages and environments. To be able to deal with this, the Platform Independent Model (PIM) was introduced. A PIM specifies the business functionality of the application completely, but does not include anything that is specific for a certain technology or language. For instance, a PIM may specify that the application is split into a number of components, but it does not specify whether the application uses .NET or J2EE. The PIM is often written in UML and is completely independent from any details that may be different across the two platforms.

MDA tools will take a PIM and use a transformation definition to transform the PIM into one or more Platform Specific Models (PSMs). A PSM contains all the detail that is needed for the chosen platform. It is crucial that the PSM is generated automatically?that is, there is no (or little) user effort needed to produce a PSM from a PIM. Usually the PSM is an almost direct reflection of the program code. (See Figure 2.)

Figure 2. Transformation Example: A PIM written in UML is transformed into three PSMs: one based on SQL, one based on EJB, and one based on JSP.

You should understand that a transformation is really the execution of a transformation definition. It is the transformation definition that is of interest?the transformation (execution) automatically follows. Developers of transformation definitions are not particularly interested in one specific input model. They write their transformation definitions so that they can be applied to any input model written in a certain language. Transformation definitions use the definition of the language, the metamodel, to decide what to do with the input model.

Transformations come in many different flavors. There are transformations in which the input and output model are the same, called in-model transformations. There are transformations of which the input and output model, although being different models, are written in the same language. There are also transformations that have one input model, and one output model?or even multiple input models, and/or multiple output models. In short, MDA takes one or more models, the PIMs, and generates one or more models that are more detailed and specific, the PSMs, from which the program code is generated.

Differences and Similarities
Now that you know about the most important elements of both AOP and MDA, the time has come dig deeper. When do you call an approach AOP and when do you call it MDA? As you will see, the answer to this question is tricky.

Separation of Concerns
First, the goal of both MDA and AOP is similar. They both try to attack the complexity of building IT systems through the concept of separation of concerns. In AOP the focus lies on separating crosscutting concerns from the basic application logic. In MDA, the focus lies on separating technological concerns from the application logic. Interestingly enough, some of the concerns factored out by AOP and MDA are identical.

For example, most MDA tools are able to transform a PIM class model at the business level into a set of PSM models that include all of the persistence code. The PIM modeler does not need to concern himself with persistency anymore. Examples of MDA tools performing this transformation are AndroMDA and OptimalJ.

Likewise, an advanced AOP application is used to separate out the persistency concern. Persistence is defined as an aspect and is considered a crosscutting concern by the AOP community and a technological concern by the MDA community. Both views are equally valid, it is a matter of taste to decide which one is the obvious choice to employ.See “Java Persistency Aspect” and the paper “Persistence as an Aspect” for more information.

Compile-time vs. Run-time
Another difference is that the MDA approach is static, whereas the AOP approach can be dynamic. The PSMs, and finally the executables, are created through transformations at compile-time (or generation-time). When the PIM is changed, you need to regenerate the PSMs and the program code, then compile everything and run the system. Early AOP systems also wove the aspects at compile time, but with current AOP systems it is possible to include certain actions at run-time. Based on the behavior of the system, that is, on the events that occur during execution, actions defined in an aspect, may or may not be executed. That is a difference, but as you will see later on, it is a very subtle one.

Programming vs. Modeling
An obvious difference between AOP and MDA is that AOP is about programming and MDA is about modeling. So, when you are dealing with program code, the label to use is AOP, and when you are dealing with models you should label your activities MDA. Still, both program code and a model may describe the same application. They do so in a different manner and on a different level of detail, but they are very similar. Many modern IDEs allow program code to be viewed as a UML model. Alternatively, with things like executable UML and model compilers available, a model can also be seen as a program. The difference between models and code is becoming less important as they grow closer to each other and the distinction between model and code is not large enough to clearly differentiate between AOP and MDA.

Metalevel Access
Both AOP and MDA allow the aspect/transformation to access the input program/model at the metalevel. In the MDA world, the transformation has access to every element of the input model through the metamodel of the input language. The best-known example of a metamodel is the UML metamodel, which is accessed by transformation authors to define transformations on UML models. The author also has access to every part of the output model through the output language (by accessing its metamodel), and can use any language construct available to define the output of a transformation.

In the AOP world, the aspect also has access to the metalevel. However, AOP systems give very limited access to the language’s metalevel through a set of predefined types of join points. Remember that aspects intervene in the normal run of the application, based on events such as calling or execution a method and setting or getting the value of a field. Only these types of events can be accessed, other parts of the metalevel are not available.

It would appear that because of the full metalevel access, MDA is more powerful than AOP. The downside, as usual, is that MDA transformations are harder to write. AOP is considerably easier to use.

Restructuring
Restructuring is a bit of a sore spot. There is indeed a crucial difference in power between AOP and MDA. In AOP, there is one main program and one or more aspects that are woven together. The aspects are all woven into the main application. The basic structure of the main application cannot be changed, therefore the structure of the result of aspect weaving is the same as the original application structure. The aspect is able to change the dynamics of the application, for instance by defining that a certain advice must be executed for any call to any operation in the application, but it cannot change the structure.

In MDA, a transformation may completely change the structure of the application model. Because a transformation has full access to the input and output models, you can do anything you like. As a consequence, MDA can be used to restructure models, while AOP cannot. For instance, you may split a class in the input model into two or three classes in the output model, or into an interface and a class, or even completely discard the class from the output.

An example of using this restructuring capability is the use of MDA transformations to apply patterns on models. Many design patterns, e.g. the Observer/Listener pattern, require a restructuring of the model. For the Observer/Listener pattern, two superclasses or interfaces must be added and a change to the implementation of certain operations must be performed. This results in a completely restructured output model. On the other hand, there are many examples of how AOP can be used to apply patterns. Again, this difference between MDA and AOP is too small to be a discriminating factor.

Which Language?
The last major difference between MDA and AOP is the ability to use multiple languages vs. a single language. AOP is targeted towards one programming language. For instance, AspectJ is specific for Java, it even changes the byte code of the Java application. For each AOP system, the input and output of the weaving process is one and the same language.

MDA is by definition targeted towards multiple platforms and languages. Both the source languages and the target languages in MDA can be any language you like. The only prerequisite is that there needs to be a metamodel of the language. In the example in our book, MDA Explained the PIM to PSM transformations all work with UML as the input language, but they generate output models in different languages (EJB model, SQL model, and JSP model).

Finally, you have found a significant difference. But it wouldn’t be right to only label transformations from one language to another as MDA. Even transformations that change the input model?where the same model is both input and output, can be rightly named MDA transformations. One thing is certain though, when multiple languages are involved, what you are doing cannot be called AOP.

Bringing AOP and MDA Together
Current developments make it even harder to distinguish between MDA and AOP. Both trends influence each other in such a way that they come closer and closer.

Aspects as Models, or Modeling Aspects
Transformations are defined in transformation definitions, which in turn are executed by a transformation engine. Because writing transformation is a lot of work, developers have started to parameterize transformation definitions so that they can be tuned and more widely used. Going further, many developers are now using complete models to parameterize transformation definitions. Models of persistence architecture and models of security architecture have been developed this way. MDA is used to combine such models with the application model, resulting in a combined model of the application plus persistence or security. In effect, the MDA transformation takes two input models and, in AOP terms, weaves those models together. (See Figure 3). Although this happens at the model level, it is conceptually very close to aspect weaving within the AOP approach.

Figure 3. Model Weaving: A representation of how MDA weaves the various models together.

Aspect-orientation has also been taken up directly by the modeling community. There is even an aspect-oriented modeling language, Theme/UML, which is defined as an extension to UML. Using this approach, aspects may be modeled directly using UML diagrams. The weaving of the aspects now becomes the weaving of models, which is what MDA is all about.

There is an ongoing discussion in the AOP community regarding whether there is even a need for a dominant “base” program. If all parts of the application can be defined by aspects, the base program can no longer be identified. Once this is the case, AOP looks more and more like MDA.

Choice of Concerns
The choice of concerns that should be put in an aspect or a different input model of an MDA transformation is, in many cases, the same for AOP and MDA. From the point of view of AOP, aspects can be used to add technological details to a model. This is exactly what the PIM to PSM transformations are supposed to do. The case of defining persistence is a very good example of this. A specific persistence technology (e.g. direct JDBC access to a database, XML file storage, etc.) is defined using either an aspect or a different input model, while the main application code/model is completely independent from the persistence technology being used.

Generation of Aspect Code
Some MDA approaches not only generate ordinary code, but also generate aspect code. The MDA generation becomes simpler and AOP techniques are then getting used to weave the aspects with the main application. This combines the two techniques directly.

Models as Programs
Another interesting development is the advance of model compilers and UML virtual machines. Using a UML virtual machine, it’s possible for an MDA approach to be more dynamic, just as AOP systems already are.

In AOP systems, access to the metalevel is limited. However, nothing in the AOP philosophy stops us from defining more types of pointcuts, thus opening up the metalevel of the source language to allow more expression.