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 automaticallythat 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 interestthe 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 modelor 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.
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 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.
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 modelwhere 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.