Sunday, March 21, 2010

Technology Review: Architecture Analysis in Visual Studio 2010

I recently had a chance to review Visual Studio 2010 RC. I was mostly interested in new architecture analysis capabilities that come in the form of Architecture Explorer and dependency graph support.

I started from downloading the Visual Studio 2010 RC virtual machine, available from Microsoft. Note that the size of the unrared archive is around 30GB and that when running it needs at least 1.5GB of memory to run smoothly, so keep that in mind before giving it a try.

The download also comes with a couple of hands-on labs. I was particularly interested in the ones that cover dependency graph generation and architecture explorer.

The starting point for using dependency graphs is the generator, available from the Architecture menu. You can generate graphs by assembly, namespace, type, method as well as specify visibility options. The graph that is generated is in DGML form (directed graph markup language). While I wasn’t too crazy about the graphics of the generated diagrams (they could use some polish), I was quite pleasantly surprised with the features of the DGML viewer. I found different diagram layouts (top-down, bottom-up, butterfly, clustering) particularly useful. Clustering will organize the nodes clustered around nodes with highest number of adjacent edges, which gives you a quick and easy way to identify “significant” or “critical” nodes. Butterfly will organize the nodes around a selected node into ones with incoming and ones with outgoing edges. Particularly useful to identify wrong direction dependencies on the architecture. I also liked the neighborhood mode where you can start from a node and only traverse up to a selected number of levels deep. On the other hand, I found the hovering over an edge until the two arrows and a plus show up a little clunky. I would have liked to have seen perhaps a mode where you can select two adjacent nodes and it would automatically select the edge that connects them and show some kind of icon to access the context menu. Still, it proved useful to create new diagrams by concentrating on the details of the connected nodes. I found the grouping feature in the graph viewer working well, although like I said graphics could use some polish. It allows you to show or hide the details by expanding and collapsing different groups such as assemblies, classes etc.

The architecture explorer feature complements the graph viewer well. It’s a tool that allows you to explore the solution and even external assemblies, traversing various relationships between objects, such as fetching classes, references, files, references to types, building call graphs etc. The end result of the traversal is a path that you can simply plot as a graph in the graph viewer. Again, my biggest complaint is the user interface. It seems they tried to stuff a gigantic piece of UI into a panel, completely unnecessary. Furthermore, it features auto-expanding and collapsing vertical areas that are only used for filtering the next node in the traversal. It resembles an accordion. Traversal goes from left to right, with each step pushing the UI further to the left making room for the next node and with that awkward vertical expand/collapse filter area between each step. In one word a disaster. Whatever happened to not cluttering the user interface? I would like to have seen a top-down, entire step collapsible like in MS Outlook, filter stays in one spot kind of UI that I could dock to the left side of the window and show/hide when needed. Left to right just doesn’t make any sense.

So, how useful are these features? If you’re doing a lot of static code analysis, somewhat. There have been other tools on the market for a long time, but still it’s nice to see a tool that comes with Visual Studio. It’s by no means any match for something like Resharper, but it can come in handy for quick architecture review. That said, that’s about the extent of its usefulness. I would love to have seen refactoring support built right into the graph viewer. Reversing the direction of dependencies is perhaps one of the most common and most important refactoring operations. It seems like the logical next step for Microsoft.

No comments:

Post a Comment

Post a Comment