Software applications are becoming increasingly large and complex. For example, some dated reports of Mac Office state that it contains 30,000,000 lines of code. Windows XP was reported as consisting of 45,000,000! Considering that there are 40 lines of text on an average book-page, that means that Mac Office is a 750,000 page epic while XP comes in at a block-busting 1,125,000 pages.
To make matters worse, these lines of code are not quite as palatable as the English lines of text you will find in most novels. They contain a huge number of inter-dependencies that even an Umberto Eco enthusiast would find impossible to retain. And yet these systems must still be effectively managed as a whole across their initial development and subsequent evolution. For example, given the scale, different parts of a system may be farmed out to different sub-teams of developers and these parts must work together when re-integrated. Likewise the development team must ensure that all parts of the resultant system perform at an acceptable speed for the user, even when crunching large data sets. Other system-wide concerns include security, configurability (for each customer) and maintainability.
These are typically the concerns of software architects: members of the development team who’s core job is to structure the system to maximize its ability to meet these system-wide concerns. But even if the architect does manage to define the appropriate architecture for their software system, it may not be realized in the implementation. This can be for a multitude of reasons: implementation is concerned with micro-detailed specification (programming) of how to achieve the system’s functionality, and developers may be unable to keep the architect’s macro-level perspective in mind; larger development team may not be fully aware of all the subtleties of the architecture, particularly as new developers come onboard; and the developers may be aware of the architecture but are under time-to-market pressures that make them deviate in their implementation;
Whatever the reason, the resultant inconsistency between the intended architecture and the implemented architecture means that the criteria that the architect was trying to embody in the system may not be fully addressed.
Dr Jim Buckley leads an Architecture Recovery and Consistency (ARC) team in Lero that endeavours to raise consistency between the intended and designed architecture. Aspart of this effort, Dr Jacek Rosik (a post-doctorate researcher on the team) has created a tool (JITTAC) that provides developers with real time information on the location of inconsistencies between the intended architecture and the implemented architecture. It does this by allowing developers build a nodes-and-edges diagram of the architecture of their system. The architect can then map pieces of the existing source code to the nodes in the diagram. The tool then analyses this source code and detects dependencies between code that has been mapped to different nodes. Thus it is able to update the diagram, reinforcing locations where these dependency-edges reflect the architect’s expected edges, but also highlighting where the dependency-edges don’t reflect the architect’s expectations.
The result is a diagram that allows architects identify where developers have drifted from their intended architecture. The tool allows them to navigate to the lines of code responsible and assess the inconsistency more fully.
The approach has been trialled in a number of companies including IBM, QAD Ireland and several Irish-based Financial Services companies. In each case the approach identified several violations that surprised the architect involved and led to further exploration. Interestingly, in many cases these led to changes in the architectural model rather than the code itself. This happened when the ‘violation’ was deeply embedded in the code base and the effort required to remove it was deemed excessive with respect to the value such a removal would have. To address this violation-embedding issue, JITTAC now provides real-time violation-introduction information to software developers as they code: that is, if a developer inserts a violation while coding, they get informed of it immediately.
In other cases the architectural model changed because the ‘violation’ actually added value in a way that the original architect did not anticipate. Here insights obtained during development implied a refined architecture that the architect was happy to accept. Consequently this area, traditionally referred to as ‘architecture conformance’ is probably better referred to as ‘architecture consistency’. In other instances, the source code was changed, resulting in a more consistent embedding of the architecture, and the architectural concerns, over the system.
The effects of this work are significant: architectural issues off concern are better reflected in the implementation or, when they are not, the team is more aware of the issues. In addition developer insight-led changes to the architecture are now made explicit and the resultant system is easier to maintain going forward.