Microsoft s Modeling Strategy

Microsoft's Modeling Strategy

As we stated at the outset, Microsoft's Visual Studio 2005 Team System Modeling Strategy is based on three key ideas: domain-specific languages (DSLs), model-driven development (MDD), and Software Factories.

We consider these three topics together as comprising Microsoft's new vision for how to add value to the software development process through visual modeling. It's this "adding value" that distinguishes the new vision from the old vision, which—to put a label on it—we'll call UML.

First to set the scene: The Object Management Group (OMG) has a licensed brand called Model-Driven Architecture (MDA). MDA is an approach to MDD based on constructing platform-independent UML models (PIMs) supplemented with one or more platform-specific models (PSMs). Microsoft also has an approach to model-driven development, based not on the generic UML but on a set of tightly focused domain-specific languages (DSLs). This approach to model-driven development is part of a Microsoft initiative called Software Factories, which in turn is part of a wider Dynamic Systems Initiative.

Note

If you would like a more in-depth exploration of software factories, we recommend that you pick up Software Factories: Assembling Applications with Patterns, Works, Models and Tools, written by Keith Short and Jack Greenfield (Wiley & Sons Publishing; ISBN: 0471202843).

Model-driven development

As a software designer, you may be familiar with the "code-generation" features provided by UML tools such as Rational Rose and IBM-Rational XDE. These tools typically do not generate "code" at all but merely "skeleton code" for the classes you devise, so all you get is one or more source files containing classes populated with the attributes and operation signatures that you specified in the model.

Note

The words "attribute" and "operation" are UML terminology. In the .NET world, we tend to refer to these as "field" and "method," respectively.

As stated in Microsoft's modeling strategy, this leads to a problem:

"If the models they supported were used to generate code, they typically got out of sync once the developers added other code around the generated code. Even products that did a good job of ‘round tripping’ the generated code eventually overwhelmed developers with the complexity of solving this problem. Often these problems were exacerbated because CASE tools tried to operate at too high a level of abstraction relative to the implementation platform beneath. This forced them to generate large amounts of code, making it even harder to solve the problems caused by mixing hand-written and generated code."

The methods that are generated for each class by UML code generation tools typically have complete signatures but empty bodies. This seems reasonable enough because, after all, the tool is not psychic. How would it know how you intend to implement those methods? Well, actually, it could know.

UML practitioners spend hours constructing dynamic models such as statecharts and sequence diagrams that show how objects react (to method invocations) and interact (invocate methods on other objects). Yet that information, which could be incorporated into the empty method bodies, is lost completely during code generation.

Note

We should point out that not all tools lose this kind of information during code generation, but most of the popular ones do. In addition, in some cases UML tools do generate code within method bodies—for example, when you apply patterns using IBM-Rational XDE—but in general our point is valid.

Why do UML tools generally not take account of the full set of models during code generation? In part it's because software designers do not provide information in the other models with sufficient precision to be useful as auto-generated method bodies. The main reason for that is because the notation (UML) and tools simply do not allow for the required level of precision.

What does this have to do with model-driven development? Well, MDD is all about getting maximum value out of the modeling effort, by taking as much information as possible from the various models right through to implementation. As Microsoft puts it:

"Our vision is to change the way developers perceive the value of modeling. To shift their perception that modeling is a marginally useful activity that precedes real development, to recognition that modeling is an important mainstream development task…"

Although our example of UML dynamic modeling information finding its way into implemented method bodies was useful in setting the scene, don't assume that model-driven development is only, or necessarily, about dynamic modeling. If you've ever constructed a UML deployment model and then tried to do something useful with it—such as generate a deployment script or evaluate your deployment against the proposed logical infrastructure—you will have seen how wasted that effort has been other than to generate some documentation.

The model-driven development ethos translates into Visual Studio 2005 functionality as follows:

• Automated validation of application settings against constraints of the hosting environment

• Generation of Web services wrappers to bridge different implementation technologies

• Automatic synchronization between source code and class models (therefore, no troublesome code generation and reverse engineering phases)

• Production of deployment reports in support of automated deployment via external scripting tools

The bottom line? Well, because models are regarded as first-class development artifacts, developers write less conventional code and development is therefore more productive and agile. In addition, it fosters a perception among all participants—developers, designers, analysts, architects, and operations staff—that modeling actually adds value to their efforts.

Domain-specific languages

UML fails to provide the kind of high-fidelity domain-specific modeling capabilities required by automated development. In other words, if you want to automate the mundane aspects of software development, then a one-size-fits-all generic visual modeling notation will not suffice. What you need is one or more domain-specific languages (or notations) highly tuned for the task at hand—whether that task is the definition of Web services, the modeling of a hosting environment, or traditional object design.

Important

A domain-specific language (DSL) is a modeling language that meets certain criteria. For example, a modeling language for developing Web services should contain concepts such as Web methods and protocols. The modeling language should also use meaningful names for concepts, such as fields and methods (for C#) rather than attributes and operations. The names should be drawn from the natural vocabulary of the domain.

The DSL idea is not new, and you may already be using a DSL for database manipulation (it's called SQL) or XML schema definition (it's called XSD).

Visual Studio 2005 embraces this idea by providing domain-specific languages for specific tasks. Domain-specific languages enable visual models to be used not only for creating design documentation, but also for capturing information in a precise form that can be processed easily, raising the prospect of compiling models into code.

In the section labeled "Visual Designers" later in this chapter, we'll introduce the initial set of DSLs that Microsoft has devised for service-based application modeling, logical infrastructure modeling, system modeling, and deployment modeling. But that's not an exhaustive set. We can expect additional visual designers to be incorporated into future versions of Visual Studio—perhaps to support business process modeling or Web-services contract design. In addition, Microsoft has a suite of tools that enables you to devise your own domain-specific languages for your own problem domain.

In that context, "your own problem domain" need not be technology focused, such as how to model Web services or deployment infrastructures, but may instead be business focused. You could devise a DSL that is highly tuned for describing banking systems or industrial processes. And here's an interesting idea: If you really can't live without UML, how about devising a set of DSLs that mirrors the UML?

We'll say more about that at the end of the chapter, and you can also find out more about DSLs in Chapter 7.

Software Factories

In their book Software Factories (Wiley, 2004) Greenfield, Short, and others introduce and discuss techniques and tools for adding significant value to the process of turning visual models into functional implementations.

In a nutshell, the Software Factories initiative is all about pulling together the ideas of model-driven development and domain-specific languages to support the following:

• Full or partial generation of artifacts (such as source code and configuration files) from other artifacts (particularly models)

• Synchronization of related artifacts (such as the model and the code) during development, and validation of artifacts constructed manually

• The application of patterns and industry best practices driven by guidance in context.

The key to all that is a Software Factory Schema, which relates work done at one level of abstraction, in one part of the system or in one phase of the life cycle to work done at other levels or in other parts and phases.

While some of the results of this initiative are already apparent in the Visual Studio 2005 Team System, some of the ideas have yet to be fully realized in tools, and this is not just about Microsoft tools. To quote from Microsoft's published modeling strategy:

"… we see factories as the basis of a broad ecosystem in which our customers and partners participate, building custom factories on top of foundations we supply, and supplying factory components to other members of the ecosystem."

A concrete example would be a software factory for banking. This would include DSL-based modeling tools, process guidance, and architectural frameworks that help to automate the tasks involved in building systems specifically for the banking industry; the point being that all banking systems comprise the same sorts of entities (accounts, interest rates, etc.), the same kinds of processes (bill payments, funds transfers, etc.), as well as being bound by the same regulatory requirements. It makes little sense to reinvent the wheel for each new process.

Important

For more information on this initiative, visit the Software Factories Workbench at http://www.lab.msdn.microsoft.com/teamsystem/workshop/sf/.