I had promised last week that I would post some screen shots of the Whitehorse Class Designer tool. Here is one.

Notice that this diagram would be familiar to anyone used to UML notation. However, it is not a UML Class Diagram, but a visualization of CLR classes which could be either from VB or from C# projects. Underlying code artifacts (source files) are kept in sync with changes made using the Class Designer. Changes made to source files which affect elements of the diagram are likewise immediately synchronized. Feedback from developers who have used this designer has so far been largely positive.  To a developer it is a useful code visualization tool, and a place where the structure of an emerging program can be designed before any method body coding starts. There are no concepts exposed that are based on a generic type structure, as would a corresponding UML Class Diagram, and no odd extensions that have been grafted on to the surface to cope with CLR unique characteristics.


True, in its raw form, it offers no higher-level abstractions, but to tool developers (like us), it is built in exactly the same way that a designer for higher-level, more abstract domain-specific modeling language would be built (like one of the other Whitehorse designers, for example). We defined:

  • a metamodel, or abstract syntax graph, for the DSL (which is a meta representation of the CLR type system)
  • the mapping of the abstract syntax graph to a concrete syntax (boxes and lines in this case)
  • well-formedness rules for the language  (CLR type system constraints)
  • mappings from this abstract syntax to artifacts (C# or VB source files, in this case)

 Hence the Class Designer is very much part of our broader strategy for using DSLs to improve the application development process.


To get away from somewhat contrived examples, here’s a piece of a Class Designer screen created when asked to visualize a piece of the System.XML assembly.