It's doubtful whether anyone would attempt to design an application these days without the aid of a modeling tool, using nothing but pencil and paper. That would be like writing this chapter using a typewriter, rather than Microsoft Word! Not so bad if you get it all right the first time, but almost impossible to rework in the light of new ideas or mistakes.
But all you need for visual design is a good drawing package, right? One that will let you redraw as many times as you like? No, because a good modeling tool is more than just a drawing package—it actually understands the design you're creating. For example, if you draw a line between a shape representing a web application and a shape representing a Web service, the tool will be able to deduce the following:
These shapes represent a web application and a Web service, respectively.
The web application references the web service, and communicates with it in some way.
This understanding of your design enables a modeling tool to add value to the Software Development Lifecycle (SDLC) by automating the validation of your design, the generation of code, the deployment of applications, and the production of documentation. To put it another way, the modeling tool must understand your design in order to make model-driven development and Software Factories a reality.
What distinguishes a good visual design (or modeling) tool from a simple drawing package? What is it that makes the tool understand your design? The meta-model.
Rational Rose has a true UML meta-model, accessible programmatically through the Rose Extensibility Interface (REI). Visio for Enterprise Architects ostensibly represents UML elements generically as pictorial shapes with no true meta-model, but it is possible to dig a little deeper to discover a meta-model of sorts encoded within those shapes.
Tony Loton's article "Build a Better Design Tool with Visio Automation" at http://www.asptoday.com/Content.aspx?id=2051 demonstrates how to extract information from the Visio UML meta-model using VBA macros and .NET programs.
IBM-Rational XDE has a meta-model partially represented in the code itself, as this is continually synchronized with the model, and also in an internal form accessible programmatically in a limited way through exposed COM interfaces.
Externally, modeling tools represent their meta-models using a proprietary file format or an industry standard format such as XML Metadata Interchange (XMI).
Because Class Designer synchronizes perfectly with classes in source code, on a one-for-one basis, the meta-model for this designer is in effect the programming language itself: Visual C#, Visual Basic, and Visual J# class diagram files carry very little additional metadata, a side-effect of which is that concepts which cannot be represented in code cannot be represented on diagrams. Therefore, whereas in Rational Rose class diagrams there is a diagrammatic distinction between associations and compositions, in Class Designer there is not.
With the Distributed System Designers, the situation is slightly different. They encode design information in XML conforming to the System Definition Model (SDM) schema. Try opening any of the application, logical datacenter, system, or deployment diagram files—with extensions .ad, .ldd, or .sd—using Windows NotePad, and you will see the following tag:
<SystemDefinitionModel xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Name="LogicalDataCenter2" Version="184.108.40.206" Culture="en-US" xmlns="http://schemas.microsoft.com/SystemDefinitionModel/2003/10">
As you progress through the software development life cycle, you will see that some of this information finds its way into separate files with an.sdm extension, again conforming to the same schema.
The good news is that you don't need to understand the SDM schema in order to use the modeling tools. For now, you just need to be aware that such a meta-model is important, and be mindful of the fact that everything you draw is described under-the-covers in the SDM format.
You can refer to Chapter 7 for more detailed information about the SDM.