Class diagrams drawn using the Visual Studio 2005 Class Designer are basically the same as their UML equivalents, save for a few minor issues. Class Designer is limited in the following respects:
Bi-directional associations are not supported.
Association names and end roles are not distinguished, and indeed associations are not distinguished from compositions and aggregations.
Inheritance relationships between classes and interfaces are not visualized.
There is no notion of a simple dependency between classes.
.NET namespaces (similar to UML packages) cannot be visualized on class diagrams.
That's not an exhaustive list, but it gives you an idea. Many of those apparent limitations arise from the fact that Class Designer provides a direct representation of the underlying code, rather than an abstract representation as provided by UML. Aggregations, compositions, and regular associations cannot be distinguished in code so cannot be distinguished on diagrams. Simple dependencies cannot be represented in code, so cannot be represented on diagrams.
Actually, in a sense, dependencies are represented in source code, as Imports statements (VB) or using statements (C#). The problem is that generally these statements are used to refer to packages (namespaces), rather than individual classes. The current version of Class Designer does not support the rendering of namespaces on class diagrams, so these dependencies between packages cannot be visualized.
Aside from those issues, if you redrew any of the preceding figures using Visio, you would be conveying pretty much the same information in the same way. In fact, of all the Visual Studio 2005 designers, this one is the closest match with UML.
Figure 5-14 shows a UML class diagram reverse-engineered into Visio for Enterprise Architects from the Visual Studio solution on which Figures 5-3 and 5-4 were based.
Remember in Chapter 1 that we indicated the importance of domain-specific languages (DSLs). Class Designer provides a DSL for class modeling. In keeping with Microsoft's focus on deployment, and with the developer in mind, Class Designer handles Common Language Runtime (CLR) types directly, whereas UML notation typically uses more abstract types that must translate (map) to CLR types during code generation and reverse engineering.
This makes Class Designer code synchronization much more effective than the round-trip engineering features of the previous generation of UML tools, and with an added benefit for the developer. Traditionally, UML tools generated large amounts of superfluous source code simply to support the round-trip engineering process, which overwhelmed developers and encouraged them to write code manually, rather than generate code from models. Class Designer adds little or no additional meta-data to your code.
As good as Class Designer is, we're not suggesting that you throw out your UML tool straightaway. As we indicated in Chapter 1, we do see a retained role for Visio Enterprise Architect for devising entities at the analysis stage that will ultimately become classes at the design stage. The idea is that business and systems analysts, who have no need for the Visual Studio suite and in any case have no requirement for code synchronization, can whiteboard various usage scenarios using analysis entities (key abstractions) in Visio. The Visio code-generation facility can then be used to provide a starting set of classes in Visual Studio, for refinement using Class Designer.