Model-Driven Development


Joseph Hofstader

November 2006

Applies to:
   Microsoft Visual Studio 2005
   Guidance Automation Toolkit

Summary: Over the last few years, as tools and technologies have evolved, another option has evolved to define a software-solution's architecture: Model-Driven Development (MDD). MDD gives architects the ability to define and communicate a solution while creating artifacts that become part of the overall solution. (6 printed pages)


Why MDD?
A Process for Model-Driven Development
Structuring the Solution
Designing the Domain Model


Often, the inception of a new software solution is an overwhelming task. Typically, after a number of approvals from management, some high-level requirements are handed over to a development organization to define and create the solution. At this point in the product life cycle, companies often take one of two approaches:

  • Take time to draw pictures defining the solution, without creating any artifacts that will become part of the actual solution.
  • Begin coding on the functional requirements, without formally defining how the solution will be structured.

Each approach contains its own risks and benefits, and experienced software professionals can argue intelligently for either approach in good company.

Taking too much time to analyze the solution initially can result in lost profits and possibly the cancellation of the effort. There is also a risk that issues with implementing the defined architecture might require that the solution take a different path, rendering the exercise a waste of time.

There are also many risks involved with giving too little thought to the overall structure of the solution—in particular, how the product can be extended and maintained in the future. Any solution of a reasonable size or complexity usually requires some initial analysis and design on how the solution should be implemented. Without some upfront guidelines, a solution might require extensive rework in subsequent releases. Also, a technically complex solution might result in an unmanageable code base, which will be hard to maintain as the project evolves.

Over the last few years, as tools and technologies have evolved, yet a third option has evolved to define a software-solution's architecture: Model-Driven Development (MDD). MDD gives architects the ability to define and communicate a solution while creating artifacts that become part of the overall solution.

Why MDD?

Since the declaration of the Agile Manifesto, there has been a movement away from requiring comprehensive documentation as a work product of a software solution. While few can argue that the only true measure of success in software development is the creation of a product that fulfills the business requirements, a lack of documentation can pose some risks in itself. As declared in the Agile Manifesto, there is value in comprehensive documentation (comprehensive documentation being an item "on the right" in the manifesto). The value includes the ability to perform the following tasks: communicate the solution to stakeholders who are not involved with the development of the product, create a contract with the team that is developing the solution, and track the history of the decisions behind the solution's design. A quality MDD tool facilitates each of the aforementioned tasks.

An effective architect plays multiple roles on any given project. Beyond defining a solution for a business problem, an architect's responsibilities often include communicating the solution to multiple stakeholders: business sponsors, potential end users, and development organizations. Architects usually create a number of diagrams to communicate the solution to each of the different audiences. Using a tool for design and development that supports the generation of code and facilitates 360-degree synchronization between the diagrams and code gives stakeholders a true representation of the solution. Synchronizing the diagrams and code manually is often time-consuming and fruitless, as software solutions rarely sit idle long enough to capture the correct images.

Having a design tool that creates code from models can be used to define a contract between the product sponsors and the development team. A model for software development that is becoming common in many organizations is having an internal architect define and design a product, and then outsource the development of the product. Having a clear understanding of the solution's design handed off to the development team eliminates much ambiguity as to the expectations of the development team. Combining MDD with a test-driven development methodology by defining unit tests for the software up front gives the acceptance criteria to the development organization prior to the commencement of development, creating even less doubt of what is expected.

Having the ability to generate pictures from the MDD environment allows the history of the product to be documented accurately with a minimal amount of effort. Without any design documentation, there is no historic trail of the solution's evolution. If this history only exists in the heads of the current development team, there is less likelihood of historic accuracy, and lessons learned might be forgotten.

A Process for Model-Driven Development

Along with a number of nonfunctional requirements like security and event management, there are three main architectural aspects that must be defined for the functional requirements, prior to development. These are the solutions:

  1. Boundaries
  2. Structure
  3. Domain model

As an example of this process, we will specify a solution that allows a user to order a pay-per-view (PPV) program from a television service provider.

Defining Boundaries

Prior to creating any artifacts (code or otherwise), the architect must understand the intent of the solution, and where that solution fits in the context of the business problem that it is solving. In particular, the architect should have an idea of which objects act as inputs to a solution, and which objects are required for the solution to fulfill the business requirements. The architect should also understand the basic flow of the business transactions, as if the transactions were being performed manually.

Understanding the boundaries of the solution gives the architect a target to which they can design. It also allows the architect to communicate the scope of the solution, and ensure that the architect envisions the solution as the stakeholders have defined it. It is a critical first step to defining the structure of the solution.


In the PPV example, we will assume that the order is placed externally to this solution, and that we only need to support the following requirements:

  • The solution must interface with the order-entry system.
  • The solution must check the accounting system to verify the subscriber's credit.
  • If the subscriber has the credit, the solution must activate the set-top box to access the event.

From this transaction, we know that there are three external actors: the company's order-entry system, the company's accounting system, and the set-top box. After spending some time assessing the manual processes, we learn that there are a number of different set-top boxes, with different programmatic interfaces.

Structuring the Solution

How the solution will be structured is the first decision—and one of the most critical decisions—that an architect must make. Without defining a solution's structure and the policies that enforce that structure, a solution can grow unwieldy. The solution can fulfill the business requirements without the necessary consistency that will allow for easy extension or maintenance.

One of the first artifacts to be created is a diagram of the conceptual architecture. The conceptual architecture defines how the functional requirements will be fulfilled within the structure that is defined for the solution. The definition of the conceptual architecture should include: how the solution is exposed to external processes, how users will interact with the solution, how transactions will be maintained throughout the solution, how the solution's domain will be accessed and manipulated, and how the solution will handle events internally and externally.

By defining the structure of a solution early in the process, the architect can begin to communicate the solution with varying stakeholders. Business sponsors often use a conceptual diagram to begin creating the marketing for a solution. Development managers tend to be appreciative of any early communications to forecast their staffing requirements. In most instances, the development team will want to do a steel thread of a functional requirement through the solution. A steel thread is a technical proof of concept that touches all of the technologies in a solution. The steel thread allows the development team to ferret out any technical issues prior to committing to a development schedule. Many times, development can begin on parts of the solution after the structure is defined.

Using a modeling tool that allows the architect to define the conceptual architecture while building a working thread through the solution can minimize any ambiguity as to the intent of the architecture, and can expose any technical issues that might arise.


After getting validation that the solution boundaries are correct, we can now proceed to structuring the solution. From the initial analysis, we know the following requirements of the solution:

  • The solution shall expose a programmatic interface to process PPV requests.
  • The solution shall orchestrate this process, so that if users have good credit, their PPV is activated; if not, they receive a notification that they cannot access the program.
  • The solution shall activate the service on devices with disparate interfaces.

There are a few structural architectural patterns that can be followed from here. Knowing the nature of the process, a layered architecture can fulfill the requirements with a public Web service layer, a process layer, and a domain service layer.

Using Microsoft Visual Studio 2005, the structure of the application and the services required to fulfill the business requirements can be defined. It should be noted that the services are created by Visual Studio by, literally, pushing a button.


Figure 1. A distributed-system diagram in Visual Studio 2005

Designing the Domain Model

The conceptual architecture is a critical first artifact in the architecture of a solution, but it is only a first step. Taking the conceptual architecture to the point where the solution can be developed with an extendible and maintainable result requires the solution's domain to be defined in detail.

The domain model contains objects that are essential to the fulfillment of the solution's functional requirements. The model also defines relationships between objects. This part of the solution definition also requires the architect to consider how to control access to the domain objects, and how to coordinate transactions across the domain. The result of the domain modeling can include any or all of the following: frameworks, object models, and service definitions.


Within our solution, we know that there are two main parts to the domain model: an accounting service and a set-top box. This example will focus on a major design element of the PPVActivationService: how to design a service that authorizes access to the set-top boxes with disparate interfaces.

This example shows an implementation of the Strategy design pattern, as defined in Visual Studio 2005. The ConcreteSetTopBoxStrategies will contain the actual code that connects to the set-top box and sends the commands that authorize access to the PPV event. This model is backed by code that compiles.

Click here for larger image

Figure 2. A class diagram of the Strategy pattern from Visual Studio 2005 (Click on the picture for a larger image)


The productivity gains from MDD are undisputable. By creating this example, the solution's architecture was defined, and tangible artifacts were created that can be added to the code base of the solution. If the time had been taken to create a unit test (and a lab set up with a set-top box to activate), a steel thread could have been done to prove the architecture sound. Developers would then have a concrete example of how the solution is expected to behave. Prior to development, the architect can put the solution framework into the Guidance Automation Toolkit (GAT) extension to Visual Studio 2005, to communicate the design to the development team with strict guidance on how to implement the solution correctly. The pictures can then be exported and inserted into a document to communicate the solution's architecture to the nondevelopment stakeholders, eliminating a redundant effort of creating the diagrams in another tool.


About the author

Joseph Hofstader is a Systems Architect at Avaya, with the title of Distinguished Member of the Technical Staff. Joe has spent the last 12 years in the architecture, design, and development of solutions in the telecommunications industry. Joe holds a master's degree from George Mason University in Fairfax, VA.