Does Your Architecture Smell?

Kent Beck coined the term “code smell” in the popular Refactoring book by Martin Fowler and defined it informally as “certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring”. An excessive number of smells in a software system impair the quality of the software and makes the software hard to maintain and evolve.

Based on the scope of the impact made by a smell, we may perceive smells in three categories – implementation smells, design smells, and architecture smells. Implementation smells have limited scope, typically confined to a class or file, have a limited local impact, and require relatively the least effort to refactor. Long method, magic number, and empty catch block are the examples of implementation smells. Design smells impact a set of classes and thus refactoring a design smell may introduce a change in a few classes. Examples of design smells are insufficient modularization (god class), multifaceted abstraction (divergent change), and broken hierarchy (refused bequest). Further, architecture smells span multiple components and have a system level impact.

Let us understand various architecture smells that may arise in a software system. Here, an architecture component could be a namespace (or a package in Java world), or a project (assembly).

1. Cyclic Dependency: This smell arises when two or more architecture components depend on each other directly or indirectly.
2. Unstable Dependency: This smell arises when a component depends on other components that are less stable than itself.
3. Ambiguous Interface: This smell arises when a component offers only a single, general entry-point into the component.
4. God Component: This smell occurs when a component is excessively large either in the terms of LOC or number of classes.
5. Feature Concentration: This smell occurs when a component realizes more than one architectural concern/feature.
6. Scattered Functionality: This smell arises when multiple components are responsible for realizing the same high-level concern.
7. Dense Structure: This smell arises when components have excessive and dense dependencies without any particular structure.

Let us analyze an open-source C# project using Designite and understand these smells in more detail. For this case study, I chose DotNetOpenAuth. Designite reports more than 84 thousand lines of code containing 117 namespaces and 684 classes in 36 assemblies (excluding test projects). Also, the tool reports 96 architecture smells as shown in the following figure.

There are 21 cyclic dependencies among namespaces in the analyzed projects. One instance of such a cycle involves DotNetOpenAuth.OpenId.Extensions.UI, DotNetOpenAuth.OpenId.Extensions, DotNetOpenAuth.OpenId.Extensions.SimpleRegistrationnamespaces. It’s a cycle of length 3. Unit cycles (with length 2; A depends on B, B depends on A) are relatively easier to spot manually. However, cycles of length 3 or more are subtly hidden in your code and you need tools such as Designite to help you reveal such instances.

There are 41 instances of unstable dependencies. Stable Dependencies Principle (SDP) states that the dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is. Unstable dependencies architecture smell occurs when the principle is not followed.
Here, stability (or rather instability) of a component is computed as follows:

I = Ce/(Ce + Ca)

I represent the degree of instability of the component.
Ca represents the afferent coupling (or incoming dependencies), and
Ce represents the efferent coupling (or outgoing dependencies)

In our analyzed example, one of the instances has been detected in DotNetOpenAuth.ApplicationBlock namespace which depends on two less stable namespaces DotNetOpenAuth.OAuth2, DotNetOpenAuth.OAuth. This makes DotNetOpenAuth.ApplicationBlock namespace relatively harder to change because it depends on the relatively instable namespaces.

Ambiguous interfaces are interfaces that offer only a single, general entry-point into a component. This smell typically appears in event-based publish-subscribe systems where interactions are not explicitly modeled and multiple components exchange event messages via a shared event bus. Designite detects this smell when it finds a namespace which is not too small and contains only one public or internal method. In our running example, ProviderEndpoint class in DotNetOpenAuth.OpenId.Provider namespace provides one public method with the following signature.

public Task PrepareResponseAsync(CancellationToken cancellationToken = default(CancellationToken))


Having only one non-static public/internal method in the entire namespace (which is not a small one; 5 classes) and the presence of public events handlers make this namespace suffer from ambiguous interface architecture smell.

Namespace DotNetOpenAuth.Messaging contains 55 classes! Each component must contain a manageable number of classes and should not be too large in terms of lines of code. A large component is difficult to understand and thus harder to maintain. Designite detects god component architecture smell when a component has more than 30 classes or 27000 lines of code (following the recommendations by Martin Lippert et al. in Refactoring in Large Software Projects).

A feature concentration architecture smell occurs when a component is realizing more than one architectural concern/feature. In other words, the component is not cohesive. Akin to LCOM (Lack of Cohesion of Methods) that is applicable to classes, Designite computes LCC (Lack of Component Cohesion) to measure the component cohesion. To compute LCC, Designite identifies relationships among classes (association and inheritance) and club the related classes in groups. LCC is then computed by dividing the number of groups by total classes in the namespace.

Namespace DotNetOpenAuth in project DotNetOpenAuth.Core has 11 classes. Designite identifies the following related groups in the namespace: [Assumes, UriUtil], [IHostFactories, IRequireHostFactories], [MachineKeyUtil], [IEmbeddedResourceRetrieval, Util, Logger, Reporting, RequiresEx, Strings]. Each group of classes is not interacting with other groups in the same namespace. Although, you might decide to still keep them in the same namespace because they are semantically same but the smell makes you think and reconsider whether these groups should be kept in the same namespace. Based on the information, LCC of the component is 0.36 which is quite high and thus the tool identifies feature concentration smell in the component.

Scattered functionality indicates that two or more namespaces are realizing a same architectural concern (kind of opposite to the feature concentration smell). Designite checks access to external namespaces that occur together from a method. If such accesses happen many times in a component, it leads to scattered functionality architecture smell in the accessed components. It is an indication that possibly classes or methods must be moved from one component to another to reduce the coupling and enhance the cohesion of the components.

In our running example, DotNetOpenAuth.Messaging namespace in DotNetOpenAuth.Core project accesses DotNetOpenAuth and DotNetOpenAuth.Messaging.Bindings together many times. It indicates that both of these components probably share an architecture responsibility.

The last smell in our consideration is dense structure. This smell occurs when the components form a very dense dependency graph. Thus, only one instance at maximum can occur per analysis session. Designite forms a dependency graph among all the namespaces and computes the average degree of the graph. The average degree of a graph can be computed as follows:

Average degree = 2 * |E| / |V|

Where E is the set of all the edges among the vertexes and V is the set of all vertexes belonging to the graph.

The default threshold used by Designite to identify dense structure is average degree >= 5 (it is customizable). In our running example, the average degree is 5.44 that implies that each component is associated with more than 5 other components on an average which is large. It indicates that coupling among components is high and efforts must be dedicated to reducing it.

To analyze further, I took the dependencies revealed by Designite and fed into an R program to visualize the dependencies among components. The dependency graph looks quite complex that validates the presence of dense structure architecture smell.

Many of the above-mentioned smells use certain thresholds. There is no one single standard for choosing appropriate thresholds and hence the set of thresholds that seems good for one developer might not hold good with another developer or team. Fortunately, we can change these thresholds based on the needs in Designite. One can go to Analysis menu, choose Preferences, and change the thresholds. Even further, if you don’t want Designite to analyze and report a specific smell, you can disable the detection using Preferences dialog.

An important note about smells. Smells are indicators of potential quality issues. Therefore, a tool detecting a smell in your code doesn’t mean that you have to refactor the smell. The tool doesn’t understand the context of the code and therefore it is up to you as a developer or an architect to take a cue and analyze further whether the smell is a real quality issue or the architecture is reflecting your intentional decisions.