Posted by & filed under Tips.

One of the new features of 2.0 is “Architecture”. Loosely described Architecture is a mapping of any abstraction onto the source of a project.  The abstraction can be anything – Functional Decomposition, Requirements, Staff, Security Classification, Internal vs Externally Owned code – whatever you can dream up, Understand’s Architect component lets you map it onto our source. And as the source changes it keeps it mapped correctly, including adding/removing files and entities.

Over the next few weeks, I’ll be showing you all the places Architecture can be used.  Yesterday, for instance, I showed how the Calendar architecture can be used to limit where you search in Find in Files.

Today, I’ll explain a relatively new feature – the Architecture Dependence Graph Browser.  Basically, pick an architecture, right click on it, and choose ‘Dependence Graph”.

Something like this pops up (BTW: this is a broad overview of the products in our Maintain family at the source level):


That is Understand 2.0 running on my iMac. Let’s zoom in on part of the image and explain it a bit more:


“Filesystem” is the name of the architecutre – it is the automatic one generated by directory structure.

At the highest level are components Measure, Maintain, and Impact.  At a lower level and clustered under “Qt” are qt/CoreExtensions – which are extensions we’ve made to Qt classes that are usable by any Qt user, and qt/STIExtensions which are derivations of Qt classes specific to being embedded in a Scitools product or tool (for example an entity tree).

Blue lines indicated dependence – so “measure” depends on “impact”. Red lines indicate mutual dependence. “Impact” depends on “CoreExtensions” and vice-versa.

Using the toolbar at the top, I can select graph nodes and expand/contract/cluster:

2008-04-10 22.08

I won’t get into that now – but play around with it, it should be obvious what they do.

The question that comes to my mind is “Why is CoreExtensions, a library,  dependent on Impact, an application” – and the dependecy graph browser can tell you exactly why. Just click on the “qt/CoreExtensions” node and select “impact” in the list of dependent architectures. Below there is a list of all references that caused the dependence:


I see that most of the dependencies occur in the main.cpp file and relate to how we start our various Qt applications.  I confess to thinking this is a bit backwards. So I’ll talk with our Chief Architect tomorrow to see why it is done that way. 

Note also that you can click on each reference to visit it in the source. I’m sure he and I will do that tomorrow morning as we explore the dependenices to determine if they fit our architectural modularity/separation goals.