Understanding 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 create “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.

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 state charts and sequence diagrams that show how objects react (to method invocations) and interact (invoke methods on other objects). Yet, that information, which could be incorporated into the empty method bodies, is lost completely during code generation.

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 on the other models with sufficient precision to be as 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 MDD? 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.

Although the example of UML dynamic modeling information finding its way into implemented method bodies was useful in setting the scene, don't assume that MDD 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.

So, what's the bottom line? 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 shows all the participants—developers, designers, analysts, architects, and operations staff—that modeling actually adds value to their efforts.

Understanding 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, a one-size-fits-all generic visual modeling notation will not suffice. What you need is one or more Domain-Specific Languages (DSLs) (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.

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 Ultimate 2013 embraces this idea by providing the capability to create DSLs for specific tasks. DSLs 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 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.

The “Code Understanding” Experience

Modeling is not just about building diagrams that help you understand requirements, architecture, and high-level design. It can also be about helping you gather a better understanding of the details of your code base. In Visual Studio Ultimate 2013, a majority of the work done on the architecture tools has been to enhance what is called the “code understanding” experience.

Think of the code understanding experience as the ability to understand both the new code you need to write, as well as the existing code you need to support. As a developer, you may need a better understanding of your code, how it fits into the wider system, and the frameworks that it is using, so that your team can more easily create tests, debug code, and add new features. The UML diagrams within Visual Studio Ultimate 2013 can provide that information. Layer diagrams can show you the different layers of your application and help you to enforce code rules.

You may run into the situation where you need to understand why a certain module has a dependency on another module. Dependency graphs are a great way to see how the different assemblies and modules in your solution interact and depend on each other. Understanding these dependencies can make it easier to refactor code to remove dependencies on deprecated features. Code maps are a new feature; they allow you to easily understand a specific section of your code while you are working on it. They also allow you to visualize your debugging process.

So, when thinking about modeling and visualization, don't just assume those tools are for making pretty pictures of your requirements. You can also use these tools to drill down into your code base to help you solve problems.

Use Case Diagrams

A use case diagram is a summary of who uses your application and what they can do with it. It describes the relationships among requirements, users, and the major components of the system, and provides an overall view of how the system is used.

Figure 14.1 shows an example of a use case diagram.

Activity Diagrams

Use case diagrams can be broken down into activity diagrams. An activity diagram shows the software process as the flow of work through a series of actions. It can be a useful exercise to draw an activity diagram showing the major tasks that a user will perform with the software application. Figure 14.2 shows an example of an activity diagram.

Sequence Diagrams

Sequence diagrams display interactions between different objects. This interaction usually takes place as a series of messages between the different objects. Sequence diagrams can be considered an alternate view to the activity diagram. A sequence diagram can show a clear view of the steps in a use case. Figure 14.3 shows an example of a sequence diagram.

Component Diagrams

Component diagrams help visualize the high-level structure of the software system. They show the major parts of a system and how those parts interact and depend on each other. One nice feature of component diagrams is that they show how the different parts of the design interact with each other, regardless of how those individual parts are actually implemented. Figure 14.4 shows an example of a component diagram.

Class Diagrams

Class diagrams describe the objects in the application system. They do this without referencing any particular implementation of the system itself. This type of UML modeling diagram is also referred to as a conceptual class diagram. Figure 14.5 shows an example of a class diagram.

Layer Diagrams

Layer diagrams are used to describe the logical architecture of your system. A layer diagram organizes the objects in your code into different groups (or layers) that describe the different tasks those objects perform. Layers can also be composed of sub-layers, which you can use to describe smaller, discrete tasks in the parent layer. In addition, you can use layer diagrams to show dependencies between different aspects of your code. Figure 14.6 shows an example of a layer diagram.

Architecture Explorer

The Architecture Explorer tool provided by Visual Studio Ultimate 2013 helps in understanding the existing architecture of a code base. This tool enables you to drill down into an existing code base, or even into compiled managed code, to help you understand how the application works, without having to open a single code file.

The Architecture Explorer can also lead into the world of dependency graphs, which are a type of view in Visual Studio Ultimate 2013 that makes it easy to understand code that is new or unfamiliar. Dependency graphs make use of the Directed Graph Markup Language (DGML) to show the relationships between different areas of code in an easy-to-understand, graphical fashion.

Code Maps

Code maps are a new feature in Visual Studio Ultimate 2013, and at first glance, they appear very similar to dependency graphs. They make use of the same visualization options as dependency graphs, allowing you to visualize your code relationships. However, the first major difference you will notice is that the code map appears alongside your code, in a separate tab, which allows you to quickly and easily visualize just a specific section of your code.

The second major difference is that code maps can be used to visualize the call stack while you are debugging your application, adding one more tool to your bug-fixing arsenal. You can graphically see the call stack, and this view will be dynamically updated as you step through your code. You can even save your code maps from your debugging session for later review. Figure 14.7 shows an example of a code map generated as part of the debugging process.

Visual Studio Visualization and Modeling SDK

You can use the Visual Studio Visualization and Modeling SDK (VMSDK) to create model-based development tools that can integrate into Visual Studio. You can use this toolset to create domain-specific languages as well as to extend the UML models and diagrams within Visual Studio 2013. One of the new features available in the toolset is a code index SDK, which enables you to create a tool that can bulk index assemblies into the code index, thereby speeding up dependency graph generation. The SDK also contains Team Build tasks that can index assemblies during the build process. More information on the SDK can be found at http://aka.ms/VS13VMSDK.