Generating code
Your team can respond very quickly and reliably to changes in user requirements by generating code from your models. If your team develops a line of similar products or relies on frequently used patterns, generating code is especially effective.
Your team can generate program code, schemas, documents, resources, and other artifacts of any kind. Your team can write text templates that interrogate the model using the Unified Modeling Language (UML) API. For more information, see How to: Generate Files from a UML Model.
In most cases, your team will not generate all of its code from models. By using techniques such as partial classes, your team can keep the generated code separate from hand-written code. Never edit generated code. Instead, update the model, which will, in turn, update the code.
Code generation is helpful in the following situations:
Product Lines. Fabrikam, Inc. builds and installs baggage handling systems for airports. Much of the software is very similar between one installation and the next, but the software configuration depends on what bag-handling machinery is installed and how these parts are interconnected by conveyor belts. At the start of a contract, Fabrikam's team discusses the requirements with the airport management and capture the conveyor-belt plan by using a UML activity diagram. From this model, the team generates configuration files, program code, and user guides. They complete the work by making manual additions and adjustments to the code. As they gain experience from one job to the next, they extend the scope of the generated material.
Patterns. The developers in Contoso, Ltd often build Web sites. They design the navigation scheme with UML class diagrams, using classes and associations to represent Web pages and navigation links. Much of the Web site code can be generated. Each Web page corresponds to several classes and resource file entries that conform to a uniform pattern. The result is more reliable and flexible than hand-written code.
Schemas. Humongous Insurance has thousands of systems worldwide. These systems use different databases, languages, and interfaces. The central architecture team publishes internal models of business concepts and processes. The diagrams make it easy to discuss the designs. From these models, local teams can generate parts of their database and XML schemas, C# declarations, and other elements.
Custom modeling languages
In the previous examples, each company has a very specialized use for its models. Although you can represent a baggage track by using an activity diagram, a formal baggage-track notation would be much better. Visual Studio supports the following approaches:
Customize a UML diagram with stereotypes. Stereotypes allow you to differentiate different types of elements (for example, to distinguish passenger check-in desks from X-ray stations) and record additional attribute values in each element. For more information, see How to: Define a Profile to Extend UML.
Design your own domain-specific language (DSL). If you do lots of work in the target domain, the additional effort might well be worth the more specific adaptation to your needs. For more information, see Modeling SDK for Visual Studio - Domain-Specific Languages.
Your team can create menu commands, validation tests, and toolbox items for both of these types of models by using the Visual Studio SDK. You can also build Visual Studio extensions that can integrate diagrams and couple them to external resources such as databases.