MDA Versus Traditional Modeling

Modeling tools such as Together ControlCenter and Gentleware's Poseidon enable the software engineer to use UML models to develop software applications. A question that commonly arises is how development processes centered on the use of tools such as these differ from an MDA development approach.

The similarities between the two approaches are not immediately apparent. Both look to leverage the power of modeling techniques to drive the development process, and the toolsets of each approach take time to learn. Moreover, neither claims to be an ease-of-use layer on top of J2EE. For each approach, strong technical knowledge and design skills are still a prerequisite as they are with traditional approaches.

Nevertheless, differences between MDA and other model-driven development methods do exist. The next sections highlight these differences by looking at the strengths and weaknesses of MDA for software development.

Strengths

The defining difference between the two approaches comes down to the level of abstraction employed. MDA leverages the power of high-level PIMs to drive the development process. This higher level of working gives MDA fundamental advantages over conventional, technology-specific modeling processes.

Business Focused

The construction of a platform-independent domain model is not exclusive to the MDA paradigm. Domain models are commonly constructed at the outset of any model-centric approach.

Traditional modeling methods rely on the business model to establish an understanding of the problem domain with the customer. The architect uses the requirements captured in this early model to build a PSM, which can be readily converted into code by most modeling tools.

The construction of the PSM is a skilled and time-consuming task. Before the modeling tool can generate a functioning system, the design team must have defined a detailed PSM.

The modeling tool generates a system from the PSM, but it does not assist in the transformation of business requirements into a functioning system. Consequently, the architect finds his or her attention diverted away from the critical business needs of the customer, and instead becomes focused on the technical challenges of implementing a solution for a specific platform.

The need for the architect to design a PSM is a distraction that can result in the initial business model being neglected. Using conventional modeling tools, the PSM becomes the main focal point of the development effort.

MDA forces the architect to concentrate on the domain model, or PIM, first and regards the PSM as a stepping-stone on the way to a working application. The use of the PIM to drive the development process keeps the focus on the customer requirements and not on the implementation platform.

Supports an Incremental Development Process

An MDA-compliant tool can convert a business model into a functioning application at the click of a button, with mapping rules filling in the gaps for the missing infrastructure required by the target platform. Admittedly, the generated system will be very raw and most likely lacking in critical business functionality. However, the generated application provides a solid foundation on which to build further functionality.

This ability to jump from business model to demonstrable application is perfectly suited to development processes founded upon short, incremental, iterative cycles. In this way, a working prototype can be constructed from a minimal model in an incredibly short timeframe. This type of development process has proven benefits, not just for rapidity but also for building systems that accurately meet the needs of the customer.

Leveraging Change

Traditional modeling tools provide a one-to-one mapping with the application code. Change a property on a class in a UML class diagram, and a single Java class is affected. Some model changes have no effect on the generated code. Switching an association between composition and aggregation, for example, is unlikely to result in any change to Java source.

With an MDA-compliant tool, a change in the PIM results in widespread change in the generated application. An update to a business entity in a PIM ripples through all layers of the architecture. The DDL generated for creating database tables changes; objects in the persistence layer change; business components change; and any corresponding Web application components change.

This ability to make sweeping and consistent application changes with a small modification to a conceptual model is a powerful feature of MDA tools, enabling customer requirement changes to be effected extremely rapidly.

Fewer Application Defects

A high percentage of defects found in application code are a result of code errors as opposed to incorrectly specified requirements. By using best-practice software generation methods in the mapping from PIM to PSM, the overall risk of code errors being introduced is significantly reduced.

Technology portability

Java is a crossplatform development language, which raises the question, Why would a paradigm whose focus is on platform independence be of relevance to anyone building J2EE solutions? The answer lies in the interpretation of the term platform.

J2EE is a constantly evolving platform. A search of the Java Community Process site at http://jcp.org is testament to the rapid rate of change Java technologies continually undergo.

A high-profile example is the EJB 3.0 specification, as defined by JSR-220, which has switched the focus of Enterprise JavaBeans from heavyweight components to lightweight POJOs, requiring minimal boilerplate code for deployment into the EJB container. Keeping pace with this change, and thereby keeping a system current, is an ongoing battle.

MDA, with its use of models to describe systems using platform-neutral semantics, can help extend the life of a system by ensuring the long-lived business functionality endures beyond the shorter-lived platform technology.

The MDA paradigm can make us more adaptive in relation to these fast-paced technology changes. For software engineers, MDA reduces the cost of change, making it possible to adopt emerging Java-based technologies without requiring prohibitively expensive application upgrades.

This is a good thing for any system, as it helps ward off the unwanted label legacy application.

Weaknesses

Powerful as the MDA paradigm appears to be, it is not without an Achilles' heel. Some of the weaknesses in the paradigm are as follows.

Working with Legacy Systems

One area where MDA tools fall behind their conventional modeling counterparts is in working with existing applications and data structures. Modeling tools can reverse-engineer applications into model form. However, as code is a representation of the system implemented on a specific platform, the models these tools build are all platform-specific. They do not reverse-engineer to the level of the PIM.

Mapping from PSM to PIM is complex and hard to automate. Most MDA tools focus their efforts on mapping from PIM to PSM. Consequently, anyone looking to reverse-engineer to a PIM in order to use an MDA approach has a hard task. The MDA standard specifies a mapping from PSM to PIM; currently, however, few tools can satisfactorily demonstrate this particular mapping.

Even if a PIM is produced for an existing system, problems still face the MDA practitioner. The power of an MDA tool to effect sweeping changes in the application code by a small change to the PIM is likely to prove too intrusive on the underlying application. It is akin to using a chainsaw where a scalpel is required.

Due to the technical challenges involved in mapping back to a PIM, traditional modeling methods are likely to prove more effective when extending or working with existing applications and data structures. Although an MDA approach should not be ruled out, a modeling tool is likely to prove the more effective software tool in this scenario, because it enables the architect to make small, strategic changes to what might be a fragile architecture.

Viability

In theory, MDA is the ultimate solution for rapid development. Produce an accurate, high-level model of the system requirements, press a button, and generate the system. In practice, though, the million-dollar question is, does it work?

The approach sounds both simple and obvious, but then, you could also state that the obvious method to reduce the traveling time between New York and London is to use technology that supports instantaneous teleportation. While the idea may sound good on paper, and it is possible to produce a long list of benefits for using teleportation technology over a commercial airline, making the concept a reality is another matter entirely.

Mapping from PIM to PSM is a difficult task. Ordinarily, this is a challenging task for a skilled design team; successfully automating the process has to be harder still.

It is in this critical area that opponents of MDA claim the paradigm falls down. MDA opponents argue the current state of the technology is not yet at a stage where a quality application can be produced without intervention from a skilled software engineer.

Despite this claim, tools are available that claim to be MDA-compliant. Moreover, the OMG proudly lists a growing number of MDA success stories on its Web site at http://www.omg.org/mda/products_success.htm.

The best way to establish the truth is to judge for ourselves by looking at a current MDA tool and analyzing how it addresses the problems inherent in mapping between models.