Sotograph Product Family
Measure Architecture Conformance and Quality
Using predefined queries and metrics, Sotograph detects a wide range of potential problems and gathers information about many quality aspects. Besides architecture conformance there is also adherence to coding guidelines and rules, the existence of duplicated code blocks, and the identification of cyclically coupled elements. Sotograph also calculates metric values which measure size, coupling and complexity on different abstraction levels. This information can serve as input for Sotograph's other analysis tools, e.g. to visualize cyclically coupled groups.
The following analyses are relevant for architecture management:
- Differences between architecture and implementation
- Interface violations: External access of private parts of subsystems
- Detection of all classes, files, packages and subsystems which are strongly coupled by cyclical relationships
- Identification of large duplicated code blocks
- Detection of methods, classes, files, packages and subsystems which are suspicious because of their size, coupling or complexity
It is also possible to specify and monitor project-specific rules and metrics.
The screen dump below shows a graph with all subsystems and their dependencies layed out according to an architecture. Architecture violations are colored blue.
Illustration of packages that are strongly coupled by cyclical relationships. The packages are colored based on the comprising subsystem, i.e. all packages of the same subsystem have the same color. The variety of colors indicates that the cyclical relationships cross several subsystem boundaries.
Structural bottleneck: the central class “ContentController” is used by many classes and is itself dependenton many other classes. Sotograph makes it easy to detect objects with such characteristics.
Monitoring Architectural, Quality and Structural Changes
Sotograph automatically manages a chronological sequence of information about the evolution of a software system. Using this information Sotograph can determine which architecture violations and quality problems have been introduced or removed between two versions. Furthermore, it has all the necessary information to visualize, on a high abstraction level, how the structure of a software system evolved over time.
As soon as it becomes possible to automatically detect architecture conformance violations and other quality related problems, the demand to check a software system at regular intervals, detect new problems and to fix them soon as possible emerges naturally. However, if this kind of monitoring takes too much time it will not be carried out on a regular basis.
For this reason, Sotograph is able to limit its focus to the problems that were introduced since the last analyzed version. Besides these new problems, items that were removed are also of interest. Inspecting them makes it possible to check whether or not previously diagnosed problems have been fixed.
Besides changes of quality aspects, Sotograph can also track structural changes. The illustration below shows the modifications between two system versions in a subsystem graph. Subsystems that were modified are colored. Newly implemented classes are inserted into the subsystems.
Sotograph provides an additional visualization tool which enables the generation of more specific graphs. The visualization ranges from architecture modules down to method level. Supplemental information, like overridden methods, can be mapped to the graphs or is provided by coloring graph nodes. It is possible to choose among a number of predefined layout algorithms.
The screen dump depicted below is a part of a graph which has been generated by Sotograph. It is visualizing all references between subsystems. The strength of coupling is expressed by the thickness of the line. Starting with any kind of graph it is always possible to drill down to the underlying source code.
The screen dump depicted below shows the subsystems of a software system and their relationships. A layered architecture is used as layout in a way that every pillar in the graph stands for an architecture layer. The subsystems are colored according to their associated layer.
Inheritance relationships between the packages of a Java system. The classes and their inheritance relationships have been aggregated to the package level. The thickness of the edges symbolizes the number of underlying inheritance relationships.