Technology

What is a DSM?

DSM stands for Dependency Structure Matrix or Design Structure Matrix. It is a way to represent systems. The DSM representation was invented more than 30 years ago. Since then, the use of DSMs has advanced by ongoing work at MIT, Harvard, University of Illinois, and a number of other places where DSMs have actually been applied to the analysis of complex systems. Lattix is the first company to apply DSMs to Software Architecture. The process of representing software architecture typically consists of simple matrix transformations which are guided by the dependencies between the subsystems.

Initial DSM

The figure below illustrates a DSM for a system that has been decomposed into 4 subsystems: Module A, Module B, Module C and Module D. The x-axis and the y-axis of the matrix represent the same subsystems which are numbered sequentially.
The dependencies for each subsystem are read down a column. Reading column 1, we see that Module A depends on Modules C with a dependency strength of '7'. We also note that Module A does not depend on Module B and Module D as those cells are empty. The identity diagonal represents the dependency of a module on itself. By convention, the identity diagonal contains a dot ('.').

Module A depends on Module C
Module B does not depend on other modules
Module C depends on Module A and B
Module D depends on Module A and C

Reordering the DSM

We will now reorder the subsystems in the DSM through a process called partitioning. Though Lattix supports a large number of partitioning algorithms, the algorithm that we describe here is called component partitioning and is well suited for software systems.

Partitioning yields a block triangular matrix. The overall goal of this algorithm is to order a system starting with the subsystems that use the most of other subsystems and ending with the subsystems that provide the most to other subsystems, while grouping systems that have interdependence (cycles) together in the ordering. Partitioning algorithms yield a "block triangular" form the matrix. In a "block triangular" matrix all cells outside of the blocks and above the identity diagonal are empty. Furthermore, those blocks which contain dependencies above the identity diagonal are guaranteed to have cyclic dependencies. This partitioning gives us three blocks. Module A and C have been grouped into one block because they are coupled to each other. Partitioning helps us determine the layering that is typical in most medium to large scale software systems.

Representing Hierarchy in a DSM

We can combine Module A and C into a compound Module A-C which contains Module A and Module C.

Lattix's innovative use of DSM in representing hierarchies is the key to representing and managing large scale architectures. Note that what we have called "Module" is simply an abstraction - it can be a small abstraction representing a single class or a large abstraction represnting an entire subsystem containing thousands of classes.

Top Level View of the DSM

We can now collapse Module A-C so that we don't see Module A and C.

The dependency that Module D has on Module A-C is an aggregation of the dependencies that Module D had on Module A and Module C. By default, the aggregation is a simple summation although other approaches to aggregation can also be configured in Lattix LDM.

To summarize: we performed a series of simple matrix transformations. In these transformations we were guided by the dependencies betweent the subsystems. We started with a system that consisted of 4 modules: Modules A, B, C and D. Through a sequence of transformations, we ended up with a system that consists of 3 Modules: Module D, Module A-C and Module B. Module A-C in turn consists of Modules A and C. Futhermore, we ordered the modules in a particular way so as to get a layered representation of the system with the lowest layer being Module B. Module A-C is layered in top of Module B and Module D is in turn layered on top of Module A-C.

You can also read up more about the history and how DSMs have been used by the systems engineering community here.

Design Rules: The Key to Managing Architecture

The DSM representation is a blueprint of a software system’s architecture; each cell of the DSM represents design intent. Design rules are simply a way of specifying allowed and disallowed dependencies.
With the context of a map of the existing subsystems, their current decomposition, and the existing dependencies between subsystems, this framework is ready for codifying the architect’s intent through a set of formal design rules. Typically, a design rule is applied to a subsystem and is then inherited by every subsystem contained within it. This allows a widely pervasive rule to be applied simply by clicking on a single cell of the DSM. The Lattix LDM solution can then inform or enforce when developers inadvertently create architectural violations.
The matrix representation itself provides a powerful way to specify and visualize design rules.

Rules can also be specified to standardize external libraries that can be used so that redundancy is minimized, architectural integrity is maintained and licensing issues are managed.
Some of the things that you can do with Design Rules include:

Specify and Enforce Layering
Maintain Hidden Subsystems
Keep Components Independent
Manage External Library Usage

The Lattix White Paper on Design Rules describes in detail how design rules are specified and applied.

What is a Dependency Model?

A Dependency Model is the representation of the architecture of a system. It consists of:

An ordered hierarchical decomposition of the System into its Subsystems
Display of current dependencies between Subsystems
Design Rules for allowable dependencies between Subsystems

Even though a Dependency Model does not require a DSM for its representation, that is our preferred depiction for most purposes. For simplicity you can think of a Dependency Model as a DSM with the addition of Design Rules.

Dependency Model = DSM + Design Rules