email article printer friendly

Introducing Model-Driven Development
Use model-driven development techniques to resolve common problems associated with building applications in SOA environments.
by Steve Andrews

May 2, 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.