Architecture Analysis Practices with VS2010 Direct Graphs and Layer Diagrams
Been using the direct graph [DGML] and layer diagram capabilities from VS2010 for a while now. Used them on many different projects with a wide spread of architectures, different quality levels and with many questions to answer about it. And I recognized a common way of working when using the tools…
It looks something like this:
Zoom Out – Recognize - Zoom In – Analyze - Zoom Out or Zoom In – Group – Zoom Out
and can been done in a different order…
Some examples will explain the analysis process better.
Chaos Example. First the question, the question what to analyze is the starting point and actually the key driver of the success factor of your analysis. The funny thing most project teams don’t know what to ask, they mostly cry for help. The same counts for a project like this. The project team was targeting a very basic architecture with a UI, business, data and infrastructure layer. To bad the team didn’t managed to stay in control and when you do an high level analysis, “Zoom Out”. [ Architecture –> Generate Dependency Graph –> By Assembly or Namespace, most of the time they are the same]
You get a direct graph, which probably makes everybody starts to cry or run a way “Recognize”… many connections, many dependencies which don’t belong there.
Although the funny thing is, when you us the default analyzers on this diagram, you won’t get any warnings….
“Analyze” There are no circular references, a trigger for tight coupling. There is one unreferenced node, for sure the outside pointing assembly [the UI] not strange. And, two assemblies are hubs, the data specific assemblies. This could be a trigger that these assemblies have too much responsibility.
Now at this stage of our analysis it’s interesting to take a look at the question… where are we looking for? it seems chaos, with the analyzers it looks like a kind of ok…. but it smells very bad.
The patterns and practices architecture guidance has a nice collection of:
It helps a lot when having these in our mind when executing an architectural analysis of a system… just to mention several:
- Separation of concerns.
- Single Responsibility principle
- Principle of Least Knowledge
- Don’t repeat yourself (DRY)
- Minimize upfront design
- Keep design patterns consistent within each layer.
- Do not duplicate functionality within an application.
- Prefer composition to inheritance
- Establish a coding style and naming convention for development
- Use abstraction to implement loose coupling between layers.
- Be explicit about how layers communicate with each other
- Do not mix different types of components in the same logical layer
- Keep crosscutting code abstracted from the application business logic as far as possible
- …
- …
Not all principles can be analyzed with Direct Graphs or Layer diagrams, but you can use some… the most important thing is that you know where you are looking for.
Now, lets zoom out… this direct graph we got gave us too much information to start our analysis with. It smells bad but what is wrong? sure, too much dependencies. Probably no good “Separation of concerns” and not been “explicit about how layers communicate with each other”… Start grouping assemblies [or namespace based on their parent namespace ] together.
Select the nodes which belong to each other and group them…
The Direct Graph we get now gives us much more information…
The UI talks with every single layer [assembly] in the system, but the thickness of the line tells us… the UI talks heavy to the business piece, sounds good… a lot to the framework and security assemblies, don’t know yet what their responsibilities are but the names are a kind of descriptive…
This is actually a funny part of the whole analysis thing, you really lean on the names used. A developer could call the UI layer data access, that would mess up my complete analysis.
Anyway, the problem is between the data access part and the business part. They are really tight coupled… the Web UI uses a bit of the data access, maybe some databound listbox “Recognize”. Not that important… Zooming in on this one “Zoom In” and selecting the dependency line between the data access and web component tells us…
.. that it is indeed a method… [only interested in methods]
… which does a data binding with a grid. [we will mark it needs some investigation]. Context menu item “Show Context” will jump to the code…
The tight coupling between data and business is a bigger challenge, when looking at the very very thick lines… they are really tight connected. Diving in these nodes “Zoom In” and looking at the different nodes, tells us… everyone from the data group points to “company.business.datasets”. that one isn’t a business component it contains real dataset [don’t know why its has “business” in the name..?]. Diving in the code shows something what we expect… generated datasets.
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30128.1
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
Moving the “company.business.datasets” to the data access group makes the dependency graph more clear… “Group”
The thing we still got in this system, is the connection between UI/ Web and the Data pieces… when zooming in on the Company.Web.Application you will see that about 50% of the types use the Business.DataSets… [context menu item on the DataSets node and select “all incoming”].
Probably all data binding stuff… now we have to make a decision. Refactoring the name of the Business.Datasets to DataAccess.DataSets would be useful. We can recommend that all UI binding should go through the business layer, than we need to start a big refactoring effort. We also could decide to binding of the UI with the datasets is fine [kind of Table Adapter Pattern]. It’s up to the architect. The thing dependencies which definitely have to remove are the ones with the dataacces assembly, there are just two calls. Create a dataset a bind it to those or create business entities.
So finally we come to some very specific recommendations how to improve this architecture… now it’s time to create a Layer Diagram. What I always do, is just drag and drop the different projects on the Layer diagram design surface and let it generate the dependencies…. again you get the scary one ;-)
Start group components together in layers and draw the dependencies as decided with the project lead and architect… till you get to the result you wanted, for your architecture….
And now, we can run the validation... the errors which show up are the code pieces you need to fix. When your ready fixing those, maybe you want to clean/ refractor the architecture even more, maybe remove the datasets and talk only through the businesslayer… change the dependency rules and validate again… in this way the errors which show up are more in control and you can do the refactoring step by step.
It was a fun journey ;-)
Zoom Out – Recognize - Zoom In – Analyze - Zoom Out or Zoom In – Group – Zoom Out and finally VALIDATE
TMap for VS2010 Process Template Explained…
Recorded a LiveMeeting yesterday about the TMap for VS2010 Testing Process Template.
Click to watch it [ 53:08 ]
patterns & practices Application Architecture Guide Layer Diagrams (Pre Release)
Patterns and practices has put on the Visual Studio Gallery a set of layer diagrams which correspond with the Application Architecture Guidance…
http://visualstudiogallery.msdn.microsoft.com/en-us/237f823c-45b4-4f1f-b9e2-607fe66eaae7
Install the VSIX in VS2010 Ultimate and you get diagrams like these, with all the validation capabilities the layer diagram has.
And the corresponding guidance…
Very Nice work…
VS2010 TMap Testing Template | Initial Work Items #1
During the unfolding of the TMap for VS2010 process template, several pre-defined work items are created for the test organization. These work items helps the test organization to start structured test process with a Master Test Plan.
When starting a testing effort first several things needs to be in place… we need to understand the assignment, determine what we are going to test what are the risks, etc… the first four steps in the image below.
Beside these steps also decisions needs to be taken about what to test where, you don’t want to loose money by testing things twice. As described in the TMap Next book:
The type of system and/or development approach and/or test policy determine which forms of which test levels are best used. For iterative system development, for instance, a thorough acceptance test is less obvious. This is because the quality from the user perspective has already been tested in previous test levels. However, for package implementations there is a far greater emphasis on a thorough acceptance test. The risks here are focused on the implementation of the package in the organization, a typical acceptance test aspect.
So, topics covered by the master test plan can be:
All these activities are described in detail in the TMap Next book, and you also get these steps when using the TMap for VS2010 process template, as initial work items.
These Master Test Plan activities got descriptive guidance attached to it. Accessible by using Microsoft Test Manager 2010, Visual Studio 2010 or the TFS 2010 Web Access tool, helping every role, to understand the assignment, the activities and test goals.
[Microsoft Test Manager 2010 | Initial Master Test Plan Work Items with guidance]
[Visual Studio 2010 | Initial Master Test Plan Work Items with guidance]
[ TFS 2010 Web Access | Initial Master Test Plan Work Items with guidance]
So, when the project starts the guy / girl with the Test Manager role has to assign the different tasks to the right team members to complete the Master Test Plan.
In a following post [probably not the next one] some Word and Excel templates which support these tasks and can be found at the project portal. First a planned post about initial work items for planning the infrastructure.
If you want to keep up to date about TMap testing and the VS2010 process template, send me an email with your name and organization
. Beside this blog and our the TMap codeplex site we have a community of users, to exchange ideas, usages stories and additional updates of the template en testing practices.
TMap for VS2010 Testing Process Template RC published on Codeplex.
A bit later as planned, due to my broken leg.
Just checked in the RC version of the TMap for VS2010 process template…
Downloaded it from TMap.Codeplex.com.
Still a lot of work to do, specially on the documentation and reporting part [lucky me, my colleagues from Sogeti US, Sweden and other Sogeti countries are helping me]. But still, the documentation section is a very good starting point when you want to discover the TMap processes for VS2010.
Later this week I will post some more content.
Speaking at Dutch DevDays and Danish ALM Day
Will be speaking at the Dutch DevDays [about VS2010 general/practical usages] and Danish ALM Day [about TMap for VS2010] in March/April.
The Hague, The Netherlands
March 30-31, 2010
DevDays 2010
[update]
Will give the interactive session "ALM Best Practices: Modeling the Showcase Application" with @Edwb (www.edwardbakker.nl) and the session "ALM Best Practices: Testing the Showcase Application" with www.RobKuijt.nl. Rob is a real tester, who will give an interesting look in the world of the tester.
Copenhagen, Denmark
April 9, 2010
ALM Day 2010
Not as much as Brian Keller [4 weeks, 7 countries, 25+ sessions, 1 suitcase…]… looking forward to it, specially because I can travel again and almost can walk without crutches. So, I can do my talks standing with my hands on the keyboard without falling.
VS2010 Architecture Explorer Analyzers
DGML, the new VS2010 visualization technology has capabilities to render graphs. Graphs like dependencies between classes, inheritance graphs, custom graph, you actually can visualize any relation you want. Cameron Skinner has posts about DGML and Chris Lovett has some great video’s.
[class dependencies uml2doc.codeplex.com]
Now the interesting thing is that you can analyze these graphs. In the image below you see the analyzers; Circular References – Hub – Unreferenced.
The purple classes are unreferenced which probably means dead code or entry point of the application. The kind of blue-green nodes are hub, classes which are important and heavy used, and no strongly connected classes in this solution.
Make your own analyzer.
You also can make your own analyzer. For example code coverage or naming conventions or … whatever you can imaging. In the example below I created an analyzer which marks the nodes green with the string ‘Clemens’… (code you know is great:)
Ok, maybe not that interesting analyzer, more interesting is the creation… in the /PrivateAssemblies/Providers folder there are already several analyzers available, actually the ones mentioned above.
A small analyze of this assembly tells us that all the analyzers are using the IProvider interface and the ProviderAttribute [see below]. After some more exploration you will find that the prgroesion.common assembly has a method ‘ProviderDiscovery’ which looks for classes in the provider directory.
so, making a assembly with the code below is a good start:
[Provider(Name = "ClemensAnalyzer")]
public class TestAnalyzer : IProvider
In the void Initialize(IServiceProvider serviceProvider); you have to initialize your provider, register the actions and action handler [action.ActionHandlers.Add(new ActionHandler(this.OnAnalyzeTests));]… which calls your analysis…
foreach (Node node in this._graph.VisibleNodes)
{
if (node.Label.Contains("Clemens"))
{
node[HasClemens] = true;
outputObjects.Add(node);
this.ThrowIfCancelled();
}
}
the node[HasClemens] = true; is some additional meta data you add to your diagram: private static GraphProperty HasClemens = GraphProperty.Register("HasClemens", typeof(bool), new GraphMetadata("Clemens","This one contains Clemens",null,GraphMetadataFlags.Default), typeof(TestAnalyzer));
All this and a bit more [didn’t finished the analysis completely, there is a lot more possible] result in your own analyzer…
Now, let’s start making a useful one :-)
Visual Studio 2010 Team Foundation Server Requirements Management Guidance
Another delivery from the VS ALM Rangers is public available… the Requirements Management Guidance.
Very useful guidance, with a small contribution from me with the Enrich VSTA 2010 Use case diagram with SketchFlow Screens post. [see the Requirements Elicitation part].
