MDA is dead, long live AADA

With recent additions of powerful language structures to the Java platform, the time is ripe for a fresh development methodology. The promise of design techniques - like Waterfall, Spiral, RUP and MDA - for an agile and efficient Object-Oriented development process is within reach.

Features like Annotations, AOP, Generics and IoC bring upon an opportunity to reevaluate our architecture design strategy. In this article I will introduce AADA (Annotations and Aspects Driven Architecture) a compelling alternative to MDA. AADA is a refactoring-oriented design methodology that effectively eliminates the need for massive code generation.

Present Shortcomings

I've been a software developer since 1992. Since then I’ve had my chances of using almost all methodologies, techniques and consequent buzzwords often mentioned in Information Technologies. Methodologies like Waterfall, Spiral, RUP, MDA, OOP techniques, UML, and other J2EE tools revolved around resolving common design problems.

I really liked MDA and used it in some projects. It proves to work only when doing a bottom-up approach. I mean that once some “kind of” framework or infrastructure was in place, you can build MDA Components that will deliver software for this infrastructure. It enables a high-level OO view of the running system. This view is not a write-only document generated in the early stages of the waterfall cycle, but a view of what is really running. With MDA you can remove the “boilerplate” code a-posteriori by defining MDA components. The problem is that defining MDA components elements (tagged value, stereotype, operations) is a difficult and non-trivial work that is hardly or never maintained, so MDA components proved to have a short usage time.

XP is another great improvement for developers. It focuses development teams on the needed missions, and on the needed missions only. It forces by means of refactoring to analyze and rethink all the “manual code generation” (or monkey programming) that’s been built up underway. XP avoids the trap of overshooting the design and the planned technical features. I find XP refactoring to be the best software design mechanism. What I mean is that refactoring code is actually designing software out of real raw material, like sculpting clay.

The job, simply put, is to find the best way to preserve the running system’s abilities with less amount of code. This is ultimate software productivity. It’s funny, as I was being paid to find the best way to eliminate the maximum amount of developers’ code. Without the code of a previous XP iteration though, it’s impossible to do the refactoring correctly. The argument: “Why didn’t you tell me that before I wrote all this code?” doesn’t hold. Guessing what is needed in a piece of software before writing it (sometimes referred to as Detailed Design) doesn’t make sense – it’s a waste of time. XP methodologies gave a big productivity boost to a lot of teams around the world.

So what’s new?

It seems as if very few exciting or new innovations came about since I started J2EE consulting in 1999. But today software development and consulting is becoming fun again. Nowadays, concepts like eXtreme Programming (XP), Inversion of Control (IoC) and Aspect Oriented Design (AOP) combined with features like annotations and generics (introduced with Java 5) are becoming common to current development environments.

During the last year, I realized that MDA or UML design is no longer needed. The level of expression obtained in an annotated Java class is actually better than it's PIM UML class counterpart. The mentioned advancements present the following advantages:

1. Expressiveness and Extensibility – Java annotations are more powerful than UML extensions defined in MDA (stereotypes and tagged values). Annotations are strongly typed and thus have the advantage of compile-time checks. Modern IDE’s can easily and quickly enumerate all instances of an annotation usage throughout the code, without the need for reverse engineering.
2. Strongly typed class associations – By use of generics, it’s possible to define class associations such as aggregation in a strongly typed manner.
3. Cross cutting concerns – Aspects successfully replace both MDA transformations and UML definitions of pre-conditions and post-conditions.
4. Elimination of boilerplate code – declared aspects remove the need for code generation. Although this is achieved mainly by employing aspects, strongly typed annotations greatly enhance readability.
5. Decoupling technical details from business logic – Strongly typed annotations combined with dependency injection contribute to a clean and efficient configuration setting. Str ongly typed annotations decorate strongly typed elements.
6. Traceability – One of MDA’s strong features is traceability. A good source code auditing is achieved by employing a good Source Configuration Management, as is the custom in an XP environment. Since a class is usually involved in more than one feature, associating a Version Control System commit action (of both implementation and tests classes) with an XP user story provides real traceability.

The MDA dream was to have one model generating software for multiple platforms, for example, the same PIM can generate a J2EE or .NET application. In practice achieving this goal demands building conforming infrastructures that are compliant with the same model. AADA enables to achieve real platform flexibility - in terms of multiple databases, multiple O/R mappings, multiple UIs, choice of a container (EJB or Servlets) and so on – with a main prerequisite, which is also the driving force: Java 5.

These compelling concepts are well demonstrated in specifications such as EJB 3.0 and the upcoming JEE version. These standards are likely to boost this new development technique.

AADA: The Code IS The Model
So I propose a new development technique: AADA (Annotations and Aspect Driven Architecture). This technique is to actually have full decoupling between the business classes (what used to be PIM classes in MDA) and all kind of technical considerations using Java 5 annotations and AOP. A ADA’s core is to annotate the business classes with project specific annotations that are created following the XP process of refactoring. These domain-specific annotations may potentially use EJB 3.0, Seam and AOP specific annotations.

To demonstrate the process, consider the following sequence:

Analyze the code to find patterns of annotations and aspects usage to obtain a higher level of meta-annotations. For example: “@Stateful @Name("hotelBooking") @Interceptor(SeamInterceptor.class) @Conversational(ifNotBegunOutcome="main") @LoggedIn” found in a Seam example can be replaced with “@MyCompanyConve rsation” which expresses the project’s naming convention, default values and Seam as the conversation state manager.
The basic component of AADA is the Annotation Factory Manager. In MDA a transformation has the ability to add more tagged values, stereotypes and classes based on an original PIM UML model element. This can be more clearly and easily done with a Java based annotation generator, which will contain the architectural logic and can be applied via AOP.

AADA and MDA compared
To illustrate the points made I’ll use one of the most non-trivial common examples, using the following data model:

a person has a list of addresses indexed per type and each address has a state and a country:

The first requirement for managing the above data model is that AddressType, State and Country would be “static/read only” data. This information would be used by whatever underlying framework you use (like persistence manager, data entry UI, marshaller/de-marshaller, etc.). Changing an address from Texas to California, for example, should not change the actual database entry of Texas to California (Although this might be a good idea after all).

In MDA you start by stereotyping or tagging the “static/read only” classes as “My Reference Classes”, and Person and Address as “My Business Classes”. From this simple declaration the architect can begin handling the model:

In Hibernate:

• All classes declared as “My Reference Classes” are cached read only;
• All associations to “My Reference Classes” should have outer-join=”false”;

In Data Entry UI:

• Associations to “My Reference Classes” should be combo box based;
• Changing association to “My Reference Classes” means finding the static entity California and associating it with my address;

In Marshalling:

• When serializing a Person all references to “My Reference Classes” should be passed by ID.
• De-serialization of a Person should link the Reference ID with a matching static reference data.

In an MDA environment, all these issues are managed through different MDA transformations that would generate extra classes, XML files, and so on. When these new elements are generated, reverse engineering becomes a headache.

The next XP iteration might pose a requirement to be able to reload on demand the list of Address Types available. As a developer to do that you just change the Hibernate XML mapping files (and possibly the cache definition also). By now, your MDA transformations are destroyed. From experience, MDA and XP practices don’t go very well together.

How does AADA handle this? Define 2 business annotations “@MyReferenceClasses” and “@MyBusinessClasses” and apply them to your model. Write pure clean Java classes that completely define the above model, using generics. These Annotated Java classes contain the same information (even more in fact) than the previous UML model.

For each annotation write an annotation factory that will inject by using AOP:

1. All EJB 3.0 annotations needed for the classes and their relationships
2. All Seam annotations needed for the State conversation and JSF UI definitions
3. Your specific aspects that manage these 2 annotations

The immediate benefits are evident:

• Everything is Java – No UML modeling tools are required.
• Readability - The code is properly decorated to add readability. For XP refactoring needs, being able to find all usages of annotations is very powerful and effective.
• Extensibility – Adding new features means to add specific annotations in the right places (for example @Remove or @IdleTime). If used often, these combinations of annotations can be transformed into “@MyNotSoReadOnlyReferenceClass”.
• No reverse engineering – The Code IS the Model.

All this AADA concepts are well demonstrated in the EJB 3.0 specifications and the Seam framework. To gain more flexibility, avoid using framework specific annotations (like EJB 3.0’s or Seam’s) directly in your business classes, as this could limit changes to the architecture after having developed code. For example, choosing a JNDI name by naming convention (not the default one of the Fully Qualified Name) or choosing a Conversation type from a project specific enumeration is something that a standard framework shouldn’t and doesn’t do. This means that in a generic framework like EJB 3.0 or Seam, a lot of annotation associations need to be string based. In a project specific, strings can be replaced by enumerations or a naming convention. This is not strictly an academic point, it really gives the benefit of being able to trace names and design decisions. The framework’s string based annotations may still be used, but they are easily identified for refactoring purposes of the next XP iteration.

MDA enables extending standard components (Corba, EJB etc.) with your own MDA component definitions. Using AADA you should stay clear of importing specific annotations (e.g. avoid importing javax.ejb in your business classes), but still have type safe compliance check, based on your own annotations and the injected ones. Today EJB 3.0 and Seam are the first AADA components that you can extend for the specific project needs. In fact, Seam already uses this concept of meta-annotations.

Adding new technical features or changing the architecture in AADA is XP compliant. Let's take for example an addition of a Web Service interface layer to your Seam conversation, or POJO services that use Inversion of Control in Seam. In an MDA environment the only approach that works, from my experience, is bottom-up. That means integrating a web service framework (like XFire) and at first developing all the Java code inside your actual business classes to be able to test that things work correctly. Once you’re happy with the results (which rarely happens in real life) you create an MDA transformation that represents your final goal. This takes a lot of time and energy, and the resulting transformation is very difficult to refactor.

In AADA such a change would mean adding the web service annotations to the business classes, testing the change and then adding these annotations to the Annotation Factory.
A fully XP process is ensured by allowing permanent testing and refactoring capabilities that don’t block developer decisions.

Summery
MDA focuses the architecture design efforts on an abstract model from which it’s possible to derive an implementation, but with the concurring cost of relying heavily on code generation. XP methodology advocates frequent changes and goes against excessive design. An attempt to adopt both strategies eventually exposes their mutual incompatibility. With recent additions to the development environment, these shortcomings may be efficiently resolved.

AADA introduces a fresh and convincing methodology that is compatible with principles of MDA but is not as cumbersome. AADA is refactoring-oriented and flexible enough to enable agile development cycles a-la XP.

Resources

Java

• Java Tiger, version 5 introduced very powerful constructs to the Java language including annotations and generics.
• Java 5 home: http://java.sun.com/j2se/1.5.0/index.jsp
• New features introduces in Java: http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
• Annotations are the new strongly typed declarative coding facility introduced with Java 5.
• Annotations (JSR-175) Community Process page: http://www.jcp.org/en/jsr/detail?id=175
• Generics (JSR-14) Community Process page: http://www.jcp.org/en/jsr/detail?id=14
• EJB3 is the new standard specification that would greatly simplify developing EJB’s.
• EJB3 (JSR-220) Community Process page: http://www.jcp.org/en/jsr/detail?id=220
• JBoss EJB 3.0 implementation: http://www.jboss.org/products/ejb3/overview

Methodologies

• Introduction to Model Driven Architecture (MDA): http://www-128.ibm.com/developerworks/rational/library/3100.html
• XP is a set of methodologies for an agile development process: http://www.xprogramming.com/xpmag/whatisxp.htm

Frameworks

• The Seam framework ties up the JSF framework for UI with EJB 3.0 standard as the backing model: http://www.jboss.com/products/seam
• XFire is a Java SOAP framework for an easy integration of Web Services: http://xfire.codehaus.org/