What is Abstractness vs. Instability Graph?

Question

I recently used NDepend and it produced a good report on my .net assemblies and related pdbs.

The most interesting thing I found in the report was abstractness vs. instability graph. I wanted to understand this in real detail, I read their docs and online metrices but it could only help to an extent.

Primarily I wish to understand how to evaluate the graph correctly and techniques to control abstractness with stability.

There's a very good article here that talks on this but what more in addition to this I need is 'how do I control this ? [controlling abstractness with stability]'

Answer 1

Abstractness is a measure of the rigidity of a software system. Higher the abstraction, lower the rigidity (or greater the flexibility) and vice versa. If the components of the system depend on abstract classes or interfaces such a system is easier to extend and change than if it depended directly on concrete classes.

Stability is a measure of tolerance to change as in how well the software system allows changes to it without breaking it. This is determined by analyzing the interdependencies of the components of the system.

Robert C. Martin's article on OO metrics describes these concepts in more quantitative terms.

Excerpt from the article:

The responsibility, independence and stability of a category can be measured by counting the dependencies that interact with that category. Three metrics have been identified:

Ca : Afferent Couplings : The number of classes outside this category that depend upon classes within this category.

Ce : Efferent Couplings : The number of classes inside this category that depend upon classes outside this categories.

I : Instability : (Ce ÷ (Ca+Ce)) : This metric has the range [0,1]. I=0 indicates a maximally stable category. I=1 indicates a maximally instable category.

A : Abstractness : (# abstract classes in category ÷ total # of classes in category). This metric range is [0,1]. 0 means concrete and 1 means completely abstract.

In any software system particularly large ones, balance is critical. In this case, a system should balance abstractness with stability in order to be "good". The position on the A-I graph shows this. Please read the article for the explanation.

Answer 2

Both abstractness and instability can be used alone to evaluate your code. You know in advance how abstract or stable some module should be. For example, you want presentation layer to be moderately abstract and highly stable, because lower modules depend on it. On the other hand, you want infrastructure layer to be highly concrete (low abstractness) and highly instable, because it should implement what upper layers are demanding.

Once that is clear, you can combine abstractness and instability into one graph, and that is the instability-abstractness graph. You want your code to exhibit as much abstractness as it is stable, in order to balance the needs to support future changes in requirements.

But anyway, you should have strong understanding of instability and abstractness metrics alone before trying to understand them working together. You can find some examples on what instability means in this article: How to Use Module Coupling and Instability Metrics to Guide Refactoring

There is a related article deriving a CQLinq query that measures instability of all modules in the application: How to Measure Module Coupling and Instability Using NDepend