MDA Explained

MDA is a model-based approach to software development defined by the Object Management Group (OMG), the same body responsible for administering the UML and CORBA. The aim of the paradigm is to enable a system to be fully specified using software models, independent of any supporting technology platform. This architectural separation of concerns between system and platform is an overarching principle for realizing the three primary goals of MDA:

• Portability

• Interoperability

• Reusability

To this list, we could also add the development concerns of agility and rapidity.

The MDA approach defines a process whereby a working application can be generated from a business domain model, known as a platform-independent model (PIM). This leap from conceptual model to working application is achieved by the refinement of a series of models, with each model being generated at ever-decreasing levels of abstraction. The final model in the process is tightly coupled to the target platform, and from this, a substantial percentage of the code for a working application can be generated.

Let's consider some of the core concepts that make up the MDA paradigm.

Platform

MDA uses the term platform to embody all the technical aspects of a system relating to its implementation. The MDA standard provides the following definition for the term:

Platform Definition

Technological and engineering details that are irrelevant to the fundamental functionality of a software component.

This definition covers such technical aspects as the choice of middleware, such as J2EE, or .NET, as well as such pressing technical design decisions as which design patterns to apply and what model-view-controller framework to adopt for the Web application.

As we shall see, MDA places great emphasis on platform neutrality and separates invariant business functionality from the design requirements of the target platform.

Models

The MDA paradigm uses models for all of the benefits associated with modeling. Models are an extremely good means of communication, both with the customer and among members of the development team. They also provide a means to validate the design against any requirement changes throughout the project lifecycle using UML interaction diagrams.

Models can assist in the development of quality software, even if not supported by sophisticated modeling tools. Models drawn on the whiteboard or scribbled down on notepaper all contribute toward clearly articulating aspects of the system to the members of the project team.

MDA maximizes the benefits of modeling by making the model central to the development process and incorporates the strengths of automated application generation.

Code Generation with Modeling Tools versus MDA

The forward-engineering approach of modeling tools is fundamentally different than that of MDA.

Modeling tools generate code at the class and method levels; MDA tools generate nearly complete applications.

With MDA, models are transformed at ever-decreasing levels of abstraction until a functioning application is arrived at. The relationship between models that provide a view of the same system at different levels of abstraction is often called a refinement. This concept is pivotal to MDA, which sees models refined throughout the development process.

Two types of model form the backbone of the MDA paradigm: the PIM mentioned earlier and the specialized platform-specific models (PSM).

To this list could also be added the code model, or implementation. The OMG defines an implementation as a specification capable of providing all the information necessary to put it into operation. The source code produced for a particular implementation is considered a model by MDA, as it is executable by a machine.

Figure 8-1 depicts the lifecycle of the MDA models.

Figure 8-1. MDA model lifecycle.

Let's look at these two model types and the purpose each serves in the MDA lifecycle.

Platform-Independent Model

The PIM results from an intensive analysis phase and focuses on the core business functionality required by the customer. As the name suggests, the PIM gives a view of the system that is not constrained to any particular platform. Instead, the PIM embodies pure business behavior.

Not surprisingly, given the involvement of the OMG, the MDA approach recommends the use of UML notation for constructing the PIM, with class diagrams commonly used to describe the business domain. The UML is ideally suited to this type of model due to its rich and expressive syntax. Moreover, because the PIM is constructed in collaboration with the customer, UML diagrams are an effective mechanism for communicating system intent and behavior.

What the PIM does not show is the use of platform-specific technologies required to realize a working application. The next MDA model type provides this view.

Platform-Specific Model

The PSM is a refinement of a PIM for a particular platform, where the platform represents an actual operating system, framework, middleware, database product, or any of a number of system-implementation technologies. The PSM is therefore closely aligned with application code and is at a level where code can be directly generated from the structure the model defines.

The PSM is equivalent to the type of model produced with a modeling tool such as Together ControlCenter. It is at a low level of abstraction that sits just above the final implementation. Using a suitable transformation process, the PSM is further refined into executable application code.

The process of transformation between model types is known as mapping and is another core MDA concept.

Mapping

The crux of the MDA paradigm is the method by which models are transformed on the journey from PIM to working application. Mapping is therefore one of the most fundamental MDA concepts, and the success of the paradigm hinges on how effectively this task can be automated.

Essentially, a mapping is a set of rules and techniques that enable one model type to be converted into another form, for example, mapping from a PIM to a PSM.

Note

Mappings can be defined between any of the MDA models. For example, it is valid to map directly from the PIM to the code model.

The task of generating code from a PSM is well-known technology and is already demonstrated by established modeling tools such as Together ControlCenter and IBM's Rational Rose. The greatest challenge for MDA-compliant tool vendors lies in the transformation of PIM to PSM.

In conventional development without MDA, the architect instructs the project team on how a PIM is to be rendered as an executable design. The architect may decide to implement the system's Web application component using the Apache Struts framework instead of Java Server-Faces. Likewise, the architect may make the call to construct the persistence layer using Hibernate rather than entity beans.

Hibernate and entity beans are discussed in Chapter 7.

The architect's decisions are not simply a list of frameworks and technologies. The architect may elect to access the persistence layer via the use of the Data Access Object pattern, with Values Objects returned to the client application through a Session Façade.

These architectural directions, and many more, must all be applied by the design team in order to take a PIM to the point where it can be built as a working solution. For the MDA tool to go from PIM to PSM, it too must follow the same directions. This is a highly complex task with which even the best architects and designers still struggle.

The MDA approach states the transformation process can be manual, but the true benefits of MDA are only realized if this process can be automated by the use of software tools. In this regard, an MDA tool could be regarded as a form of expert system, because the process is one of applying the knowledge and skill of the experienced architect to the mapping problem.

An overview of expert systems is provided in Chapter 10.

MDA tool vendors find themselves in the position of not only developing products capable of accurately performing this mapping, but also having to convince skeptical developers that such an approach is feasible. They must sell the concepts as well as the benefits of MDA against those of existing model-centric processes.