Monitoring and Enforcing Architecture

Monitoring and Enforcing Architecture#

Design Rules are used to specify and enforce software architecture. Code changes made as part of routine maintenance and enhancements can automatically be analyzed against the design rules during the build or as part of a CI/DevOps pipeline. Design Rule violations are flagged. The developers can then decide whether these violations are programming errors or reflect changes in architectural intent.

Once design rules are specified, they can be used in a variety of ways:

  • You can update the Lattix project within Architect to generate an Update Report. This report includes a complete list of all violations, as well as a list of all new violations and a list of all old violations that no longer exist.

  • You can update the Lattix project using LDC, a command line utility to generate an Update Report. This report includes a complete list of all violations, as well as a list of all new violations and a list of all old violations that no longer exist. LDC can be integrated as a part of the build system or as part of a CI/DevOps pipeline.

Rules can be qualified by the type of dependency. Rules can also be specified using tags and keywords (such as $parent and $self).

Specifying Design Rules#

Every project has a set of default rules based on the module type of the project. To see the default rules, select $root and select the Rules tab. For Java, this is what you would see:

image0

This is a tabular view of rules. A tabular view is important because the rules are applied in sequence. However, it is often more convenient to add and remove rules using a tree view of rules. You can bring up the tree view of rules by clicking on the tree view icon in the upper left of the Rules tab.

Rules specified at a higher level are inherited by the lower level subsystems. Inherited rules are greyed out and cannot be edited. Rules are applied in sequence, therefore, inherited rules can be overridden by new rules at lower levels.

image1

To add a rule in the tree view, simply select subsystem (external or within $root) and click on Can Use, Cannot Use, or Must Use

The definitions of the three types of rules are as follows:

  • Cannot Use rule creates a violation if there is a dependency

  • Can Use rule will never create a violation. This rule is used to explicitly say that dependencies are allowed. Also, you can override a cannot use the rule that is on a parent subsystem

  • Must Use rule creates a violation if there is no dependency

Design Rules for External Systems#

Note that you can also control the dependencies on external systems. By definition, external systems are everything that isn’t loaded in. For Java and .NET, it is often used to control third-party libraries that are used. For database, this is often a quick way to catch stored procedures and triggers that might refer to missing or deleted elements of the database.

Can Use and Cannot Use rules are used to permit or disallow use of specific external systems.

Must Use rules are used to mandate the required use of an external system. This is helpful for critical things like security related use, or can be used in the pursuit of non-functional requirements around topics like software compliance.

Using the Add Dialog#

You can bring up the Rule dialog from the Add… button midway down the Rules tab.

image2

For the selected subsystem, this dialog allows you to specify the target/provider for the rules. Rules can be marked as exceptions which can be useful if you are unable to fix the dependency but simply want to prevent further architectural erosion. You can also specify a description to explain the rationale for the rule.

The Dependency Filter allows you to pre-filter certain kinds of dependencies before applying the rule. This can be used to allow only certain kinds of dependencies. For instance, you can disallow all dependencies from one subsystem to another except for the dependencies of interfaces.

Rules using the DSM#

You can select one or more cells in a DSM and right click to bring up a pop-up menu to set rules in a DSM.

image3

Rules using the Conceptual Architecture Diagram#

You can select a dependency edge in a CAD and right click to bring up a pop-up menu to set rules in a CAD.

image4

Export and Import Rules#

You can export the rules associated with your project by File –> Export Rules.

You can also import a rules file into Lattix by File –> Import Rules. Note that any rules found to refer to non-existent partitions are ignored.

Note: You can also export and import rules in batch mode by using ldcscript and the Import/Export Rules script.

Contents