What about UML?

As a professional software designer, chances are good that you have at least a passing acquaintance with UML. If so, you might want to know the following: How can you capitalize on your investment in UML skills when adopting the new tools? How can you capitalize on your investment in UML artifacts? What if you really want a fully integrated UML capability?

We'll attempt to answer those questions, but first a few words about Microsoft's position regarding UML.

According to the published modeling strategy, Microsoft is not against UML as such. They see UML as a valuable notation for sketching out ideas early in the software life cycle, a task for which you can continue to use Visio in the retained role that we discuss shortly. They also support third-party vendors, some of whom are building UML 2.0 tools for Visual Studio 2005. In addition, where it makes sense to do so, the new set of visual designers will use UML-like notations to ease the transition.

However, Microsoft believes that it can better bridge the gap between design and development (modeling and coding) by providing a set of visual designers—underpinned by DSLs—that enable you to work at a high level of abstraction while providing sufficiently high fidelity for the specific domain being modeled. In this respect, using stereotypes and other mechanisms to extend UML 2.0 would have been overly complex and still too generic.

Capitalizing on your investment in UML skills

A direct comparison between UML and the new visual designers is not valid, not to mention unfair. Microsoft has deliberately eschewed UML in favor of domain-specific languages that are highly tuned for specific tasks, and it's early days for this new vision, so we cannot expect a full end-to-end visual modeling capability in Visual Studio 2005.

However, just because a blow-by-blow comparison is not possible, you can still find similarities that offer opportunities to take advantage of your UML skills.

First, Application Designer enables you to model applications that communicate through endpoints in much the same way as you would use the UML component diagram to model components that communicate through interfaces. Therefore, if you're used to component diagrams, you'll take to application diagrams. In fact, we translated a UML component diagram into an equivalent VSTS application diagram early in this chapter.

Second, Logical Datacenter Design, in conjunction with Deployment Designer, enables you to model a logical infrastructure, and to show which applications will deploy to which servers, in much the same way as you would with a UML deployment diagram. If you're used to deployment diagrams, you'll take to logical datacenter diagrams.

When it comes to Class Designer, the similarities with UML class diagrams are apparent even from the first glance. The rendering of classes (as boxes with compartments) and interfaces (as lollipops) is much the same, as is some of the notation, such as the idea of "associations." In both cases, the purpose is exactly the same: to provide a one-for-one graphical representation of the underlying types in code. You just need to be aware of some terminology differences, such as "operations" and "attributes" in UML ("methods" and "fields" in Class Designer) and "generalization" in UML ("inheritance" in Class Designer).

We hope that those brief points have convinced you that all that UML training has not been a waste of time. You can take at least some of what you know and apply that knowledge when using the new tools.

You might have spotted that Visual Studio 2005 does not offer dynamic modeling capabilities that approximate UML's sequence and statechart diagrams. That situation might change over time as new visual designers are produced to support DSLs specifically for dynamic modeling. In the meantime, you can continue to use Visio (see the following section) or use strategically placed comments on diagrams to convey limited dynamic information.

Capitalizing on your investment in UML artifacts

If you've already designed .NET applications, chances are good that you have some existing models in Visio for Enterprise Architects or IBM-Rational XDE that you'd like to migrate into the Team Architect.

Any attempt to migrate your models as a whole will prove fruitless. Not only because of the lack of XMI exchange features, but also because a significant proportion of the model's contents simply cannot be represented in Visual Studio 2005—specifically, the use cases and the dynamic diagrams. That need not be a problem if Visio is used in the retained role indicated below, as the best tool for recording analysis-level dynamic information that does not directly affect the generated code.

You can certainly import into Visual Studio 2005 the static information from your existing models' class diagrams, either by generating code from Visio into Visual Studio or by reverse engineering existing deployed applications—including Web services—into Team Architect representations. Thanks to code synchronization, you should be able to quickly build a class diagram and/or application diagram that reflects the Visio-generated or reverse-engineered code base.

Achieving a fully integrated UML capability

This chapter has offered some good reasons why you should not want this at all, and Microsoft can offer many more. However, you may still find yourself wanting to adopt Visual Studio 2005 Team System but unable to live without a UML capability.

One option is to wait for a third-party vendor to provide a UML add-in. Borland has announced an intention to develop UML 2.0 capabilities for the Visual Studio Team System.

The other option is to use Microsoft's DSL tools to grow your own UML designers. We don't recommend that unless you work for an organization that can absorb the development costs of such an initiative, or unless you think you can sell the end product! Having said that, growing your own design notations is considerably easier with the DSL tools than it ever used to be by other means. To prove it, we had a stab at devising a DSL to mirror the UML's activity diagram notation. The result is the Activity Designer shown in Figure 1-9.

Figure 1-9

It turned out not to be production quality and it supported only a very limited subset of the notation, but when we tell you that it took only days—not weeks or months—to achieve something approaching the diagram we presented in Figure 1-8, you'll appreciate the potential offered by the DSL tools, even for UML stalwarts.

We could have just as easily used the DSL tools to build simulations of the other UML diagram types, such as use case diagrams and collaboration diagrams. And if all that sounds like too much hard work, you'll be pleased to hear that Microsoft's DSL Tools team has provided you with a starting point by bundling sample DSLs for UML use case diagrams, activity diagrams, and class diagrams with the DSL toolkit available at http://www.lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx.

A retained role for Visio for Enterprise Architects

Previously, Microsoft bundled Visio for Enterprise Architects with Visual Studio .NET, as the preferred tool for modeling .NET applications. Microsoft will continue to bundle Visio for Enterprise Architects as a complementary tool providing a broad modeling capability, most useful in the early analysis stages, and compliant with UML 1.3.

Here's our advice on how you should continue to use Visio:

What we're not advocating is using Visio in combination with the new visual designers for detailed design, implementation, and deployment activities within Visual Studio. The Team Edition for Software Architects is clearly stronger here with its IDE integration, code synchronization, and bias toward creating deployable designs.

What we are advocating is using Visio for the up-front analysis and design activities that may well be undertaken by a business or systems analyst already familiar with working with Visio, rather than a designer/developer familiar with working with Visual Studio. In a nutshell, we propose using the right tool for each job, with little or no overlap, as follows:

• Use Visio for the initial analysis activities, which in any case may be performed by people—business analysts or solution designers—more used to working in Visio than in Visual Studio. We're talking about use cases and scenario realizations (e.g., as sequence diagrams) that are in any case not supported by the Team Architect.

• Use Visio to generate a one-time-only domain model as code. Because the Team Architect keeps code and model in perfect sync, any Visio-generated classes will be available immediately to your Visual Studio model.

• Use the Visual Studio 2005 Application Designer to sketch out the overall shape of the system in terms of interconnected applications and services, analogous to a UML component diagram.

• Use the Visual Studio 2005 Class Designer to evolve the Visio-generated domain model (if you have one) into a proper technical design model incorporating the .NET framework classes that are not supported well in Visio.

• Develop the code itself, with Visual Studio 2005 automatically ensuring synchronization between the code and the model, analogous to UML round-trip engineering.

• Use the Visual Studio Logical Datacenter Designer and Deployment Designer to specify the mappings and constraints for the deployed system, analogous to a UML deployment diagram.

Finally, if you need to do any limited dynamic modeling in support of the detailed designs, do this using strategically placed comments to convey the necessary information without reverting back to Visio.

Important

The UML capabilities of Visio are fully documented in Professional UML with Visual Studio .NET: Unmasking Visio for Enterprise Architects (Wrox, 2003). This book is based on Visio for Enterprise Architects 2003, but for the retained role we suggest it should be equally applicable to the newer Visio for Enterprise Architects 2005.