- How do I interpret the Dependency Structure Matrix (DSM)?
- What is partitioning?
- Why is lower triangular important?
Generally, we attempt to transform the matrix to represent the architecture in a lower triangular form. A lower triangular form represents a layered system which is a very common architectural pattern for large systems.
- Can I change the default DSM conventions used by Lattix Architect?
- How can I learn more about DSMs and Dependency Models?
- What is a Conceptual Architecture Diagram (CAD)?
- How does this approach compare to other types of modeling such as UML?
- Is the Dependency Model approach useful for forward engineering or reverse engineering?
- Can you do round trip engineering with Dependency Models?
- Can I create subsystems for code that does not exist?
- Certain metrics are expandable and some are not. Why?
- Why aren't line numbers displayed for certain dependencies?
Read down a column to see the dependencies for each subsystem on other subsystems. Click on a cell to see the actual dependencies in the Usage properties tab. You can get a quick overview of DSMs by watching some of our videos.
Partitioning is a grouping algorithm. It re-orders the subsystems around to create groupings called "virtual partitions". The default DSM partitioning algorithm seeks to create a lower block triangular matrix by moving subsystems which provide below subsystems which use. For instance, as a result of partitioning, you should expect to see library subsystems show up below the systems which make use of the library facilities. Default partitioning will also identify interdependent subsystems and put them in the same block. Lattix supports many different partitioning algorithms.
The default conventions used by Lattix Architect have dependencies for each subsystem being read down a column. The default also keeps users above providers. This is convenient for stacked architectures. You can reverse either of these conventions through Preferences menu item under View.
The Conceptual Architecture Diagram is a "box in a box" diagram. It depicts the ordered hierarchical decomposition. The placement of the boxes can also be used to convey information about the architecture. The boxes can be stacked vertically to display the layers. The boxes are arranged on the same row to indicate components which are within the same layer but are independent of each other. The CAD is a simple diagram which is easily understood by managers, users and business stakeholders. It is derived from the DSM. It is useful during the evaluation process for collecting feedback on the architecture for various architects and developers.
They are complimentary approaches. UML is suitable for detailed modeling of applications developed using object oriented languages. Dependency Models are useful for understanding, communicating and maintaining the big picture view of the application architecture. You can find a more detailed explanation here.
The Dependency Model approach can be used in both cases: forward engineering and reverse engineering. Lattix supports both modes. In fact, it is trivial to round trip a dependency model.
Absolutely. In fact, the approach is so lightweight that the round trip engineering can be automated in the build process. The only time an intervention is required is if a design rule is violated or when the architecture is being changed explicitly.
Yes - you can create a project even when there is no code that is associated with it. You can create subsystems and specify rules. If you want, you can also specify dependencies manually between subsystems.
The top level metrics are for the entire system. Some of the metrics are expandable. This is done where it makes sense to examine the metrics for each of the subsystems. For instance, when you are examining Dependency Counts, it makes sense to see what the Dependency Counts are for each of the subsystems. On the other hand, when you examine Complexity, this is not so clear. Complexity is not a sum (or a linear) relationship of the metrics of each subsystem, because the computation of Complexity also factors in the dependencies between the subsystems.
The line number are extracted in a variety of ways depending on the language. For Java, the line number is extracted from the class file. It is possible for the user to strip this information from the class file. The class file for interfaces does not contain line numbers. For .NET the line number is extracted from the PDB file generated by Visual Studio. If this file is not present, the line number will not be extracted. For languages where source code is analysed (such as C/C++), line numbers should normally be found.