Today I hacked on the Class Diagram functionality in Whidbey to allow rule-based generation of diagrams. Rather than manually dragging and dropping classes, I can now write a statement to build a diagram containing classes matching certain conditions. This is useful because it cuts down the work involved in creating a diagram, and allows the contents of the Class Diagram to be recalculated so any new classes or changes are picked up dynamically. Ever wanted to see a top-level view of your system that selectively includes things like:

• Classes in a particular namespace
• Classes that implement/extend a particular interface or type
• Classes that call a certain method
• Pretty much any arbitrary condition based on code structure
• Or some combination of the above?

If so, then read on...

The background

Since late 2004 I have been working on a project to build diagrams within Visual Studio which are linked to development artefacts using queries. The project is called Concern Maps, and provides a simple box and arrow visual language for modelling arbitrary "stuff" (e.g. patterns, architectures, source and related documents, cross-cutting concerns, etc...). The example below is a Concern Map representing a data access concern, with three "concepts": Data access classes, Order entity CRUD methods and Customer entity CRUD methods.

The large orange boxes within this visual language can be annotated with query expressions, which are contained within the small paler boxes. These query expressions could be one of several languages, and at the moment I have implemented regular expressions (for selecting sections of text), file names (for selecting entire files), XPath and XQuery (for selecting program elements from an XML representation of source code), and several shortcut queries (to hide some common XPath or XQueries like "types named X" or "type implementing interface Y", see this post for a full list). The data access example above uses XPath and XQuery expressions to select individual methods and classes based on their properties.

Query expressions are executed when a user double-clicks the associated box on the Concern Map. The matching artefacts (e.g. classes, documents etc) are displayed to the user in a tree view, and can be opened at the correct position within their file by double clicking the relevant node in the tree view. The example below shows the tree view that is displayed when double clicking the Data access classes shape within the diagram.

What does this have to do with the Class Diagram?

Until now I had been content to allow users to skip straight from the Concern Map diagram to the source code by clicking on the tree view. But while jogging this morning, I had a eureka moment - why not select classes into a Class Diagram?

This improves the Concern Map experience by allowing users to hook into the Class Diagram editing capabilities. It is also a nice tweak on the Class Diagram, since the user can populate the diagram based on the properties of the code rather than manually enumerating types. This might not be a big deal when working with tens of classes, but once the number of classes gets into three of four figures it becomes a much more interesting proposition.

I've roughed up a solution containing three projects to try to illustrate the capability. The solution looks like this:

• Acme.ConcernMaps, which holds the Concern Maps associated with the solution
• Acme.WidgetManager, which holds a single Manager class
• Acme.Widgets, which holds three different widget classes

I've also added a Concern Map the Acme.ConcernMaps project to represent the Manager / Widget relationship:

The Widgets query uses the Class Diagram language I put together today, and selects classes into a Class Diagram when it is evaluated. The expression 'InNamespace Acme.Widgets' is used within the query to select all classes in the Acme.Widgets namespace. Double clicking the Widgets node causes the Concern Map system to run this query and present one result to the user - a new Class Diagram file called temp.cd.

Double clicking this new file in the treeview loads it in the main frame, as shown in the screenshot above. It has also been added to the Acme.ConcernMaps project behind the scenes, so it can be loaded from there if the user doesn't have the Concern Map open.

I'll put together a screencast tomorrow that shows this running within the IDE.