Cameron Skinner first introduced DGML about 9 months ago and now that VS 2010 Beta 2 has shipped it’s time for an update.
This video (WMV or MP4) takes you through some great demos to give you an idea of what it can do. This is just a 10 minute teaser, in subsequent posts I’ll drill into all the various software visualization features in more detail.
I think you’ll agree that this is pretty exciting stuff and I can’t wait to see all the amazing things that people will do with this new capability.
The following download contains the DGML demos used in this video: Demos.zip (542.37 kb)
Someone asked me recently how I built all those demos:
Demos.dgml – built by hand, manually adding the “Reference” attribute that point to each sample.
Assemblies.dgml: I just drag/dropped the .NET assemblies onto a new empty graph document. The green colorization was a custom category added by hand.
Grouped.dgml: was taking the above and manually grouping things then styling the group & link colors by hand.
Baseball.dgml – by hand by copying this graph from Slate magazine
Coverage.dgml – the dependency graph is just a class to class dependency graph which I think I just used the architecture menu generate with a “Custom” settings, namely show only Types and no methods (this way the classes are leaf nodes but their links are a rollup of their inner dependencies), then I wrote a tool that mapped the Coverage report (which is in an XML format) to add coverage properties to my nodes. The hard part here is the “name mapping” because metrics analyzer uses a different “identifier” scheme.
LinesOfCode.dgml – the class dependency graph came from the Architecture menu, then wrote a tool that took a log file from the Metrics Analyzer in VS and mapped it back to the DGML graph. The hard part here is the “name mapping” because metrics analyzer uses a different “identifier” scheme.
Set.dgml – the class dependencies from VS, but the categorization by hand (using the VS Property Window you can type in your own category names), then hooking up the icons by hand.
Tagging.dgml –by hand
TeamData.dgml – was a class level dependency graph , the green was a hand categorization of interfaces, the link color styles added via the Legend.
Most of these started as class or assembly level dependency graphs, with manual coloring and grouping added.
Overview.dgml – entirely by hand
ProgressionTypes – You can get a Type Hierarchy graph using the Architecture Explorer tool window which I explain in my view on the Architecture Explorer.
CallSequence.dgml: by hand
UmlMetaModel.dgml – I built a tool that understands the MOF XML format and exported it from an internal MOF description of UML that we had, but I think the grouping was by hand.
Devdiv-grouped.dgml A friend of mine JP Duplessis wrote a tool that cracks all the binaries in a Visual Studio build (native and managed) which he then stored in a database, he then dumped that out to DGML. The grouping was then done using some regular expression matching. We knew a few central nodes that lived in each group, then based on their dependencies the tool would suck things into those groups. We call this “group by patterns”.
devdiv-just-group.dgml – collapse all, but then I have a tool that does a “shallow copy” of this graph keeping the computed group to group dependencies intact. This could be a handy power tool – sort of a “roll up and throw away the detail” kind of tool.
Wpf-by-namespace – was a straight architecture dependency graph, limited to public types only I believe.