Lattix uses the Dependency Structure Matrix of Design Structure Matrix (DSM) to understand your architecture. A DSM is a simple, compact and visual representation of a system in the form of a square matrix.
Frequently, when discussing software dependencies you are thinking about directed graphs that looks something like this:

The DSM represents the same information as a graph, but in a more concise format:

The DSM is particularly good at analyzing large, complex software systems. A number of partitioning algorithms can be used on the DSM for architectural discovery and management. They help identify layering (hierarchy) and componentization (modularity) within the software system even after the architecture has eroded.
The results of the partitioning algorithms are displayed as square boxes, called virtual partitions, within the DSM. Here is an example:

Lattix provides powerful support for refactoring that typically results from architectural erosion over time. Lattix provides powerful capabilities to improve modularity.

Architecture Editor – You have complete flexibility to change the architecture without changing the code; this allows you to plan out your refactoring work before touching the code. You can create or delete any of the abstractors, create or remove dependencies and specify rules. All changes made to the architecture in Lattix are automatically remembered in a worklist. Undo and redo capabilities make it easy to try alternative what-if architectures and to understand the impact of those refactorings.

Round Trip through the Model – User can maintain the architecture in Lattix as the system is refactored over time. A powerful update facility provides the ability to continuously update the model as code changes are made over time.

Algorithm Support – Lattix provides a number of algorithms to help in the refactoring process. These algorithms help you break cycles, mode subsystems to reduce coupling and cohesion, and understand the relationships between modules.

Lattix uses the concept of design rules to specify the allowed nature of the relationship between various subsystems. Design Rules allow the architecture to be specified, communicated and enforced within the entire development team.

Rules can be specified or overridden at any level of the hierarchy. Rules can be kept broad or made as narrow as needed. You can:

• Create rules for internal and external dependencies
• Specify layering rules
• Specify rules for independent components
• Create rules based on the type of dependencies
• Create rules based on the type of source or target subsystem

Rules based architecture enforcement can be automated. Command line utilities (LDC command line) can be used to monitor and enforce the architecture. Lattix can also be embedded in the build system to generate report and notifications of architectural violations.