Analysing software using Lattix

Understanding software systems using Dependency Structure Matrices

Analysing 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 with each other using design rules.

The Dependency Structure Matrix (DSM) allows you to see the benefit of analysis almost immediately. 

The analysis is refined over time to progressively further decompose the system. The following basic steps are normally performed when analysing a software system using Lattix:

Understand the application use

Establish knowledge of the function and use of the software being analysed. If you didn't develop the application, you can usually get this from 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 organisation 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. 
• 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

Changes can be made in the subsystem organisation to reflect the conceptual architecture. This could involve moving subsystems, adding new levels in the hierarchy and even removing subsystems that are not relevant.

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.

• Lattix Overview

• Analysing software using Lattix