We can consider aspects of our programs as sets of elements of certain granularity connected by different kinds of relations, i.e. as a graph. So every model of our code that is a graph we call a structure. (Or stated in other words, a structure is a projection of our code onto a graph.) The elements and relations have certain properties that we choose to present as certain graphical attributes.

The structures view allows to get an overview on code dependencies. Available choices are package and class dependencies. To choose a specific diagram just open the appropriate view and select the project you want the diagram to show the dependencies from.

The Package Dependencies view displays all internal packages of the system and their dependencies to each other as a directed graph. A package depending on another means there is a class in the package that accesses a class in the other package. The nodes in the graph represent the packages, an edges between two nodes represent all dependencies between the two packages. The edge's size corresponds to the number dependencies between the packages, as well as the concrete number of dependencies is displayed as a label on an edge.

By selecting a node, the selected node and all adjacent nodes are highlighted. To unhighlight a node, simply click on the background. Selecting an edge highlights the source and target nodes.

Zooming is provided by scrolling with the Mouse Wheel while holding down CTRL. A context menu is available on the right mouse button that allows direct selection of preselected zoom levels.

Package dependency diagram

A node in the graph not only represents a package but also provides some viable information on abstractness/stability of a package [Robert C. Martin Design Principles and Design Patterns.Technical Report - ObjectMentor. 1996].

Dependency cycles

The view allows visualizing access violations between packages with regard to three dependency / package coupling principles [Robert C. Martin Design Principles and Design Patterns.Technical Report - ObjectMentor. 1996].

You can control which violation of dependency principles are highlighted:

Tool buttons for the package dependency diagram1)
	Acyclic Dependency Principle (ADP): Allow no cycles in the package dependency graph.
	Dependency Inversion Principle (DIP): Abstractions should not depend upon details. Details should depend upon abstractions.
	Stable Dependency Principle (SDP): Depend in the direction of intended stability. A component should only depend upon components that are more stable than it is.

The view uses two metrics for its axes: the X-axis uses the instability and the Y-axis represents the abstractness of a package [Ma96].

Three different corridors can be seen in the square. On the top left, a problematic region contains all packages that are abstract and unstable. In contrast to this, the lower right corner contains all packages that are stable and concrete, this results in a too rigid code structure and even small changes are hardly possible without effecting different components. Packages placed in the green region have a well balanced value between abstractness and instability.

The package names can be seen by hovering with the mouse on a package icon.

The abstractness-stability diagram