As the software evolves, the architecture tends to degrade or degenerate (also known as “architecture decay” or “architecture erosion”). How do we know if the architecture is decaying and how to address it? One answer is to look at the “architectural smells” perspective. If new architectural smells get accumulated over time, it clearly indicates architectural decay.
It is not uncommon to see legacy projects running into millions of lines of code. For an architect new to a legacy project, it is very hard to understand the existing architecture, determine the extent of decay, identify smells and metric violations, and perform refactoring without breaking the working code – and performing all this manually is a tedious task. Fortunately there are many tools available that can simplify the task of an architect. In this article, we take a quick look at different kinds of tools relevant for architecture refactoring.
Kinds of tools relevant for architecture refactoring:
* Architecture comprehension and visualization
One of the pre-requisites for performing architecture refactoring is to understand the architecture. An architect needs to understand the components, how they are connected to each other, the extent of dependencies, etc. For this purpose, tools for architectural visualization are useful. Example of tools: Structure101.
* Architecture smell identification tools
There are tools that identify architectural and design smells. These tools help identify the extent of decay in the software as well as the specific instances of smells that may need to be refactored. Sometimes, violation of architectural metrics can also be considered as a smell and such violations also become candidates for refactoring. Example of tools: Sotograph.
* Tools for performing architectural refactoring
Numerous tools for refactoring candidate identification (i.e., smell identification tools) exist. Also, even IDEs have automated support for refactoring code and design smells. There are tools that provide suggestion for refactoring, but they do not perform the architectural refactoring themselves. There are even some tools that show you how the performed refactoring could look like but it is upto you to perform it. However, we have not come across any tools that automate refactoring architectural smells. If you know any (or developed one!), please drop us a mail – we are keen to learn about them.
Architectural analysis tools support architectural visualization, dependency analysis, and smell identification. They are static analysis tools – they analyse the software without executing them. For instance, there are tools that automatically identify layers, visualise them, and also identify layering violations (e.g. Lattix DSM). There are limitations with this approach because the analysis is static in nature. For example, if the software performs things such as reflection, runtime manipulation, etc, the tools may not be able to understand them and find smells with that.
Many tools provide ways to specify architecture or constraints in the architecture. The mechanism is a tool-specific basis. For example, you can specify “allowed” or “not-allowed” dependency rules between components using a textual or diagrammatic notation and check the actual architecture against the set rules. Another example is specify the layers in a notation that the tools understand and then let the tool detect layering violations.
With that, here is a list of tools that are useful for architecture visualization, identifying smells or for performing refactoring:
- Structure 101 – Commercial tool for Java, C++, C#, … [Has very powerful visualization and dependency analysis features.]
- Stan4J (Structural Analysis for Java) — Commercial Java tool [Helps visualize the software in terms of dependency relationships. Helps find smells such as cyclic dependencies and hub-like structures at both architectural and design level]
- InFusion — Commercial Java, C++, and C tool [Finds mostly design flaws but also reports architectural smells such as SAP violation (Stable Abstraction Principle violation). Excellent tool and scales for large code-bases.]
- Sotograph, Sonargraph and SotoArc – Family of commercial tools that supports various languages [Powerful tools that visualises the architecture. Reports architectural smells and shows potential refactoring of the smell as well – so you can decide if you want to actually perform the refactoring.]
- Lattix DSM – Commercial (Design Structure Matrix) tool for various languages [Helps visualise the dependency structure. Helps find layering and dependencies violations, for example.]
- SonarJ — Commercial Java tool; has Eclipse plug-in.
- Bauhaus – Visualization and smell detection tool; has academic and commercial licenses [Reports architectural violations and can define architectural rules as well.]
[That is not an exhaustive list. Please suggest any other tools that you use]
As an architect, it is important to use relevant tools to manage or repay technical debt (and avoid ‘code rot’ or ‘design rot’). Fortunately lots of tools are available that help in your job for identifying smells and for performing refactoring. Hope you will explore such tools in future.