In-Depth

Introducing Model-Driven Development

Use model-driven development techniques to resolve common problems associated with building applications in SOA environments.

• By Steve Andrews
• May 1, 2007

Organizations increasingly rely on software solutions to automate their business activities. This automation helps them more efficiently and effectively reach their business objectives by delivering customer value. The extent to which high-quality software can be developed and leveraged quickly and cost-effectively determines how competitive an organization can be in its market.

Despite businesses' dependence on software to enable their activities, a huge chasm still exists between companies with problems and those that supply software solutions to those problems. Increased rigor and focus on the discipline of eliciting requirements can begin to address this problem, but even then the intent often strays once coding begins. Developers continue to spend the majority of their effort on developing application infrastructure ("plumbing" code) at the expense of what the users really care about - the business logic.

The recent surge in popularity of strategies such as service-oriented architecture (SOA) can be attributed, in large part, to a desire to raise the level of abstraction for technical solutions to that of the business. SOA largely deals with integration and with assembling composite applications and executable business processes from existing application services. In raising the level of abstraction, SOA vendors bring modeling tools to the forefront; they have increased productivity in the integration tier by enabling business-domain experts to model the business and generate executable representations of those models.

If you acknowledge that individual applications exist to expose services at the business level of abstraction, why do you not place the same emphasis on modeling for individual applications? Despite the advances in SOA technologies and techniques, a composite application is only as good as its underlying individual application services. In this article you'll explore how raising the level of abstraction and using model-driven techniques can address the most common issues associated with building applications.

Understanding the Importance of Models
Models are abstractions of reality that can be used to express knowledge about the problem and solution spaces of a domain. Models for building complex structures have been around for hundreds of years. When was the last time you heard of a construction crew starting to build a building without a blueprint?

A model's primary purpose is to reduce the risk of a product-creating project by clearly articulating how a series of sub-components are to be assembled to satisfy the objectives of the end product's users. The model must also meet a set of environmental constraints (such as building codes or other regulatory requirements) for which a violation will result in costly rework.

Models encapsulate the modeler's knowledge about assembling solutions that address specific user needs within certain environments. Most very large software projects are at least as costly as building physical structures, so at least the same amount of rigor should be applied to modeling how these systems will be constructed to drive down financial risk.

In software, you have an added incentive: you can automate the construction of software run-time components from models of sufficient fidelity. By contrast, building construction remains a labor-intensive discipline that relies on a high degree of manual transformation of a blueprint (model) into a physical structure.

Different Types of Models
In software, there are several kinds of models that can describe the problem and solution spaces with varying degrees of abstraction. These models build on each other and encapsulate many kinds of knowledge.

A computational-independent model (CIM) describes what an application needs to accomplish. It may be represented as a business model. This business model describes organizational structures and the associated business processes that specify the activities necessary for achieving business objectives.

A CIM may also be represented as one or more use cases. These use cases specify the required behavior of individual systems that automate activities within the context of the over-arching business model. The CIM is rooted in the requirements space and specifies what needs to happen.

A platform-independent model (PIM) describes what key business abstractions need to exist and how they interact to meet the behavior specified in the CIM. A PIM encapsulates knowledge about the business domain (such as, finance and health care) and will hold true regardless of the technology used. In fact, a single PIM may be implemented in any number of ways.

The PIM bridges the gap between the problem and solution spaces. Business analysts should be able to review a PIM and verify coverage of the business problem the CIM defines. Developers should be able to review the PIM and glean how the solution may best be implemented.

A platform-specific model (PSM) specifies how the elements in the PIM will be implemented using a specific technology (such as, Java, .NET, and Ruby). The PSM encapsulates knowledge about architectural mechanisms (such as persistency, remote-ability, and security) that provide common technical functions and how they are leveraged by the business-specific components of an application.

A platform-specific implementation (PSI) is the actual set of executable software components, which are described technically by the PSM and functionally by the CIM and PIM.

Finally, a transformation model (TM) encapsulates the knowledge about how to transform elements from the above-mentioned models. A TM specifies how to transform PIM and PSM elements into a PSI that addresses business problems using a specific set of implementation technologies. There are a variety of strategies for performing transformations, but the general premise is to move from a description of the solution at the business level of abstraction to an executable system.

The MDD Approach
Model-driven development (MDD) enables a more rapid, complete and direct path from a business problem to an executable business solution. MDD transforms the business knowledge in a PIM into a PSM based on knowledge about a technical platform, and then transforms the PSM into a PSI that can be deployed to a run-time environment. The fidelity of the transformation model determines how rapidly and completely this process can be completed. A PSI can be developed manually based on a PIM and PSM, but it will take longer and may introduce human error (see Figure 1).

You can employ several MDD strategies. For example, architected model-driven development (AMDD) combines application frameworks (which handle common application infrastructure concerns) with MDD generative techniques. AMDD further decreases the amount of manual development that must be done by raising the level of technical abstraction. Ultimately, all MDD variants are focused on delivering business results without letting the technology get in the way.

MDD is not a silver bullet that obviates the need for solid software engineering fundamentals. Good requirements that unambiguously define the problem are still important, as their fidelity in the CIM determines the potential fidelity of the PIM. Luckily, since MDD compresses the actual coding time, it frees up more time to devote to understanding user needs.

Over time, as transformation- and platform-specific models evolve, the need for higher-priced development resources will decline. Since the application architecture is "baked into" the generated PSM, you can focus on writing business logic almost exclusively. For example, if part of the application architecture exposes behavior using Web services, you can encapsulate the rules for generating Web service interfaces in the transformation model one time and apply it many times. Your alternative is manually re-implementing the Web service technical details for each service, which takes away from time spent focusing on the services' business logic.