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
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 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 :-)
Traceability in VS2010
Always an interesting question, how does traceability work in VS2010?
To often asked without any context, or only asked from a requirements perspective. Still way too open to answer in a tweet. So, a post to canalize those questions a little bit more…
[see the image below for the numbers]
you can take two directions when talking about traceability. The first is focused on “work”, the work items repository part of TFS [on the left side of the green dotted line]. with work related traceability we can answer questions like “did we completed all tasks for that requirement?” [for more see the red list]. Information which is very important for every roll in the Application Lifecycle. A tester want to know if he can start testing, so he want to see if the developer is ready. A project manager wants to plan the work. Developers want to know if designers are ready to start with a stabile set of needs… and many more. All work related information, and information which can be tracked/ traced by using work item and its repository.
VS2010 main capability for work related traceability are the TFS work item repository [see image below from MSDN] and linking of work items, setting up a hierarchy.
We can breakdown requirements, or user stories, in tasks. 
tasks that needs to be executed to get the requirement done. These tasks can have a parent-child relation [and other see Working with Link Types on MSDN]. Giving us the information we need in any kind of way, for example reports.
So far the work related traceability. The other kind of traceability is based on artifacts, things we make during the application lifecycle, I will call them ALM artifacts. ALM artifacts are used to create the solution/ application. For example the source, XAML and configuration files which make the solution. But, also the diagrams which we created to make a correct, consistent and good communicated application architecture, we use them to drill down from the needs to code. And also test cases belong to the things we make during the application lifecycle [I can imaging when you get confused now, test cases are within VS2010 work item types, but they definitely belong to the artifacts section].
Use case – user story what is the difference… I often use both [see this piece of MSDN documentation for modeling requirements]. User stories are work item types and use cases are ALM artifacts. So, they are a great bridge between the ‘work-world’ and ‘artifact-world’. The good thing is the capability of VS2010 to link diagrams, and other model elements to work items. [How to: Link Work Items to Model Elements], this give us the capability to create a trace.
From the description and diagrams of the requirements, the often called problem domain, we have to make a big jump into the solution domain.
Diagrams are created like the component diagram and layer diagrams visualizing the high level pieces of the solution with the dependency and interfaces between these components and layers. [used this image in this post; the modeling world].
It is also a big gap for traceability, to get this a little bit better a solution can be the replaying of scenarios written down in the user stories and drawn in activities as described in this post; VS2010 Modeling; Create Lifeline from Component.
A trace back from component/layer to requirement can be a link from model element to the user story work items in where he is used. Never did this, it’s a manual process and probably people will forget the links, maybe with some kind of notification this would be valuable…
An interesting VS2010 capability is the connection between the layer diagram and the sources. This makes a trace possible between the high level design and the sources. See image below.
Because test cases are work item types in VS2010 they can be connected to any other ALM artifact, giving us the possibility to connect for example test cases to use case diagrams. Easier to accomplish and to maintain is the connection with test tasks and corresponding user story. But this doesn’t answers questions like; “which code is touched by this test”. VS2010 answers this question with Test Impact, see “Determining Which Builds Have Bug Fixes, New Features, or Requirements”, “Recommending Tests to Run That are Affected by Code Changes” and “Developing Tests from a Model”.
Another interesting traceability scenario can be build with test case generation, see this ‘old’ Model Based Testing beta 1 video. [some more info on MBT can be read on Rob’s blog]
Next, 
all have a work related task. So, not only traceability within the two sections is possible also traceability between the two sections is possible. answering questions like; “which task created this line of code?”… creating this link / trace is a manual task but it can be controlled by a check-in policy.
So, when someone asks you the question; “what about traceability in VS2010?” you now can canalize this and guide him/ her to the real traceability question they want to have answered [and tell the solution]….
< probably more to come on this interesting topic, also because the extensibility model of the diagrams is powerful enough to create your own required traceability between artifacts with notifications and work item linking… very very interesting >
VS2010 Modeling; Create Lifeline from Component
From the VS2010 MSDN sequence diagram documentation…
Relationship to other diagrams
You can use UML sequence diagrams together with other diagrams in several ways.
Lifelines and types
The lifelines you draw in a sequence diagram can represent typical instances of the components or classes in your system. You can create lifelines from types, and types from lifelines, and show the types on UML class diagrams and UML component diagrams. For more information, see Classes and Lifelines.
Beside we can create lifelines from/for classes we also can create lifelines for/from components… which is actually a very interesting feature.
Context menu on a component shows the create lifeline option [not available when clicking on a part ]
After the creation of several lifelines, you can draw the interactions between the components. There isn’t functionality like the bi-directional method creation in the class-sequence diagram interaction for the component-sequence diagram. Kind of logic, a component only has interfaces.
Why would you want to do this, create sequence diagrams for components?
While the component diagram 
is a static view of your system the sequence diagram is dynamic, it visualizes the flow in your application, the sequence of actions that occur in the system. So, you could use sequence diagrams to validate your system, your component design. Take a scenario, a requirement scenario, and create a sequence of actions from in a sequence diagram 
. By doing this you create a kind of simulated behavior of the component structure, which you can check on correctness and consistency.
The scenarios used for this can be found in the use case diagrams 
, which describe the actions that take place on/in the system. Now describes a use case diagram not really a scenario, you better can use an activity diagram for that 
, which can be based on the use case diagram as a kind of use case realization. Now the interesting thing is, testers use activity diagrams to create test cases, they have specific technologies to extract the right amount and type of scenarios [see http://robkuijt.nl/index.php?entry=entry080423-135750 ], these scenarios we can use to validate our component design which actually closes the loop.
It would be even more interesting and powerful if we not only could link sequence and component diagrams but also use case and activity diagrams making notification when an activity changes and a scenario can’t be run anymore on the purposed component… hard to accomplish, but interesting, versioning would be hard…
VS2010 Sharing Models and Diagrams
What is the use of models when you can’t share them. In a previous post [Copy-Past Modeling Diagrams and Modeling Elements within VSTS 2010] I already talked about the copy past capabilities of the models within team architect. Now beta 2 is out, I have to say VS 2010 Ultimate. So, it is possible to copy past elements and save them XPS-files..
But, what if you are the only one in the team with an Ultimate edition…
Lucky team-members, they still can open en view. See the [viewer] and believe me this is VS 2010 Premium.
A nice thing they can re-organize them. See the * and save it, opening this model in the ultimate edition will show the changes.
Beside the UML diagram’s also DGML and the layer diagram got this behavior.
How to keep you fingers on the keyboard within VSTS 2010 Architecture Edition
Keyboard junkies have a hard time with all that dragging and dropping of shapes and connectors around within VSTS 2010. So here are some tips for these junkies how to keep you fingers on the keyboard.
New default DSL Tools behavior…
Adding shapes to the design surface allows you to directly start typing, for example after adding a class shape to the design surface lets you start typing the class name. Hitting 'Enter’ will confirm the value and F2 lets you edit it again.
More interesting, in the compartments of the class shape hitting Enter twice adds an attribute or operation. So, type a name for an attribute, hit Enter to confirm the value and hit Enter again for adding a new attribute.
Very simple and also very quick for the creation of classes.
Fast diagram editing with shortcuts…
With the default behavior you still have to drag and drop class shapes on the design surface. To eliminated this piece of mouse handling you can create your own keyboard shortcuts. Cameron pointed me to this environment settings in Options dialog screen. The architecture team has created a very nice an clean overview of all the actions you can execute in this dialog. So, adding your own shortcut keys is very easy. Below I added the shortcut key “Alt-C” in the context of the Logical Class Diagram for adding Class shapes to my design surface.
I also added the shortcut keys for adding Attributes and operations, just because setting the focus to the compartments isn’t that easy with shortcuts…
And when this is still to hard for you, you can buy a drawing tablet.. with a nice tablet overlay.
and you will look as happy as this guy…
although it just looks like he isn’t that comfortable with it…
Copy-Past Modeling Diagrams and Modeling Elements within VSTS 2010
This is completely new for me… CTRL-A // CTRL-C
ALT-TAB // CTRL-V
It also works in other applications, even Outlook. This kind of functionality [copy past between models] was already written down in the DSL Tools Book [page 437].
Copy past between models is also possible, but than you have to look very careful what and how you do it. For example copy past within the same model create a model element with the same name with a number at the end.
It’s interesting to look at the Model Explorer, also in that one there are shapes added with the same name.
Now, copy pasting from one diagram to another diagram has the same behavior, modelelements are created with a number. [the number is added because they also get shown in the model explorer, two shapes with the same name isn’t possible]
If you want these shapes to be the same, and not a copy, you need to drag and drop the shape from the model explorer on design surface of the new diagram.
The benefit of this is that now these model shapes are connected, changing the name of one [on the diagrams or the model explorer ] will automatically synchronize the other elements.
Another thing to pay attention to is the copy-past behavior between different model projects…. actually you can see it immediately when pasting in the diagram of the other modeling project, no number added. So you could think that the behavior is the same as drag and drop from the model explorer. But that isn’t the case, while adding an other modeling project also a new root is created in the model explorer. So, those two model elements are two different things. Drag and drop isn’t possible between model projects.
If you do want to re-use mode elements in a different modeling project, you can us the copy past functionality, which works really nice. But, you also can copy past the content of the modeldefinition file to the other project. Don’t think that is the way to go… but it works, it also reminds the relationships between the elements. You could create a default package every project needs to us…
Soma on Architecture Tools…
Nice overview post on the Architecture Tools by Somarsegar. He uses some new bits for the images of the diagrams.
![y1pOvtjHPmcumaRA19YyvZNqNMPEGS3pYwfHuGvpDSmLZD0qqaJMpSF-VGysgRU-WIfWuR45LcB29n3I0V8bNJxAg[1]](http://www.clemensreijnen.nl/image.axd?picture=WindowsLiveWriter/SomaonArchitectureToolsandthelittledevil/66F49082/y1pOvtjHPmcumaRA19YyvZNqNMPEGS3pYwfHuGvpDSmLZD0qqaJMpSFVGysgRUWIfWuR45LcB29n3I0V8bNJxAg1_thumb.png "y1pOvtjHPmcumaRA19YyvZNqNMPEGS3pYwfHuGvpDSmLZD0qqaJMpSF-VGysgRU-WIfWuR45LcB29n3I0V8bNJxAg[1]")
The layer diagram has two more menu item groupings [I like the custom items] and strange numbers in the shapes, curious what that is.
Finally we have a nice overview how the Petshop application works :-)
MSDN VSTS2010 doc’s - Modeling User Requirements
Have been reading all the MSDN documentation about VSTS2010 last few days and I’m amazed by the quality of this. So if you don’t have the bits installed, just take a look at MSDN to get a deep dive in the new functionalities of VSTS2010.
This is a screenshot from the Team Architect doc’s about “Modeling User Requirements“…
and when you do have the bits installed, hit F1 sometimes… [I often forget that functionality]