Analyzing Architecture
The process of analyzing a software system for its architecture consists of performing an ordered hierarchical decomposition of the system and encoding the architect’s intent of how these subsystems are expected to interact using design rules.
The process is done iteratively. The DSM representation allows for a natural top down process of decomposition. This means that you can generally begin seeing the benefits of analysis almost immediately. The analysis is refined over time to progressively further decompose the system.
We have found the following steps useful. Many of the steps described here are for those who are trying to analyze a system that they don’t know anything about. If you already have an understanding of your system then it is all the more easier for you to do this analysis.
- Understand the Application Use – Establish a working knowledge of the function and use of the Application being analyzed and managed. For parties that did not develop the application, some suggestions including reading user documentation and running the application to get an understanding of what the application does.
- Create a preliminary DSM based on the code structure – The code organization is frequently a good starting point because developers naturally tend to group related functionality. Also, as an introduction to the DSM, using familiar structure helps developers understand how to read the DSM. Lattix LDM uses the package or directory structure to create the initial DSM.
- Interview the Architects – The architects and senior developers have a deep understanding of how the application is structured. If the application is very large it may be necessary to interview several architects each of whom is responsible for different parts of the system.
- Create a conceptual architecture diagram and a DSM to reflect that conceptual architecture. This is the critical step in the process. Once you have a conceptual architecture, then further refinements and decomposition can continue incrementally. Creating a conceptual architecture requires the following:
- Top level system decomposition: This means that you have decomposed the system into its subsystems. You have identified every piece of the code of the system and figured out which subsystem it belongs to. Typically, this implies that you have assigned each package or directory to the top level subsystem that it belongs to. For instance, many business applications have a top level decomposition into the following layers: data access layer, business logic layer and user interface. A top level decomposition would require that you identify each package as being in one of these top level subsystems.
- A general understanding of how the top level subsystems depend on each other. Create a DSM which reflects the conceptual architecture to see how the subsystems depend on each other.
- Refine the DSM – Based on comments received, changes can be made in the subsystem organization to reflect the conceptual architecture. This could involve moving subsystems, adding new levels in the hierarchy and even removing subsystems that are not relevant. At this time, the abstractions represented by the various subsystems are understood.
- Examine the Dependency Structure – Examine the dependencies to see the ones which appear to violate modularity based on the knowledge of the abstractions represented by the subsystems. One of the big advantages of a DSM is that from amongst the large number of dependencies it lets you focus your attention on those dependencies that appear to violate architectural principles.
- Define the Design Rules – Define the design rules based on the understanding of subsystem abstractions and their inter-relationships. Document design rationale for rules as part of constructing the rules. The dependencies that need to be fixed are marked as exceptions at the appropriate level. If necessary, propose a short-term and long-term architecture remediation plan.
Note that the ordering of the steps is merely suggestive; it is frequently changed because every individual situation is different. Some systems have much better documentation; at other places, there are key architects who possess the critical insights about how the system is designed. Iit may also be necessary to repeat some of the steps. Repetition occurs during step wise refinement; it also occurs because the documentation is outdated or because the information provided by the architect does not match the actual system implementation.
The White Paper on Lattix Process describes additional techniques for refining the Dependency Model of the Software System.