Now for the third post from the series of Visual Studio Tools I Can't Live Without on using UML diagrams to validate your intended architecture.
Part of what I do when I run a code review is to extend it with a report on design divergence. That is when I look at what the intended application design was and what has actually been implemented.
This takes several long and probing interviews with the application architect or technical lead, asking questions about what they think has been coded. Then I look at the code at a high level, with more attention paid to sections with more complexity.
Sometimes it is pretty spot on. Sometimes it is very very different when we get in to the code.
As mentioned in other posts, I will use tools like dependency graphs to get a quick high level understanding of a code base. Another tool that Visual Studio gives me that I didn't have in the past is UML diagram validation of code.
Visual Studio has a project type called a Modelling Project that allows you to create different kinds of UML diagrams that communicate what your intended application design is or are created from code and show the implemented application design.
Again, there is a lot of documentation on how to create these diagrams. The main thing to know is that there are many different types of diagrams and once you put them in place, they can be used to validate the actual code.
Using these tools, you can reverse engineer a code base quite quickly and take in the high level design visually, which is for me the fastest way to understand an application architecture.
It is also quite revealing in that it can show boundary violations between components that cause future extensibility pain. In one case, we identified calls being made from the view directly to the data access layer, bypassing business logic layers. The architect there didn't realise that some of the less experienced developers didn't know they shouldn't do things like that.
Layer and Class diagrams are my favourites. The ability to drag and drop a file from the Solution Explorer in to the diagram makes them a breeze to create.
Once I have diagrams in place, I communicate to the technical leads how to continue to use and create them for regular checks and even in gated check-ins.
A picture really is worth a thousand words.