This is the sum of metric NumCls for this package, and all its direct and indirect subpackages.

This is the sum of metric NumOps, taken over all classes in this package, and more fine-grained measure of the size of the package.

Like metric NumCls, this counts all interfaces, regardless of their visibility.

• C has an attribute of type D
• C has an operation with a parameter of type D
• C has an association, aggregation, or composition with navigability to D
• C has a UML dependency or usage dependency to D
  UML dependencies are shown as dashed arrows in the diagrams (usage with stereotype 'use').
• C is a child of D
• C implements interface D

• Suggested in [Mar03].

This is the average number of internal relationships per class/interface, and is calculated as the ratio of R+1 to the number of classes and interfaces in the package.

• Suggested in [Mar03].

The number of elements outside this package that depend on classes or interfaces in this package. The dependencies considered are the same ones listed with metric R.

• Suggested in [Mar03].

The number of elements outside this package that classes or interfaces in this package depend on. The dependencies considered are the same ones listed with metric R.

• Suggested in [Mar03].

This is the ratio of efferent coupling (metric Ce) to total coupling (Ce+Ce). Values of metric I range between 0 and 1.

A value close to 0 indicates a package that does not rely much on other packages, but is heavily relied upon by other packages. Such a package should be stable, because it is hard to change: changes to the package potentially have a large impact on the model ("ripple effects").

A value close to 1 indicates a package that mostly relies on other packages, but that itself is not much relied upon. Such a package can be unstable, because it is easy to change: changes to the package are not likely to have a large impact on the model.

• Suggested in [Mar03].
• See also: rule SDP1.

This is the ratio of abstract classes and interfaces in the package to the total number of interfaces and classes in the package.

Values range from 0 to 1. Zero indicates packages without interfaces or abstract classes, 1 indicates a package consisting only interfaces and abstract classes.

• Suggested in [Mar03].

The Stable-Abstractions-Principle (SAP) says that a package should be as abstract as it is stable. With abstractness measured by metric A, and stability measured by metric I, the SAP demands that A+I be close to 1.

If you plot A vs. I in a graph, the "main sequence" is the theoretical optimal line where A+I=1. Metric D is the distance of the package from the main sequence, and is calculated as (A+I-1)*sqrt(2).

Values range from -sqrt(2) to +sqrt(2). Values close to zero indicate packages that adhere to the SAP. A large negative value indicates a package that is concrete and stable (A and I close to 0). Such a package can be "painful" because it is not extensible and prone to change. A large positive value indicates a package that is abstract and unstable. Such a package is extensible but has few dependents, and is therefore useless.

• Suggested in [Mar03].

This is a variation of metric D that has been normalized to range between 0 and 1. It is calculated as |A+I-1|. Values close to zero indicate packages that adhere to the SAP (see metric D).

• Suggested in [Mar03].

Top level packages have nesting level 0, their subpackages are at level 1, and so on.

The classes and interfaces of a package, and their dependencies, form a graph. This metric counts the number of connected components of that graph.

Ideally, all classes and interfaces of the package should be related directly or indirectly, so that there is only one connected component. If there are two or more connected components, you may consider moving some classes or interfaces to other packages, or splitting up the package.

• See metric R for the list of dependencies considered between the classes and interfaces.
• The graph considered is an undirected graph, directions of dependencies are ignored.
• You can view the connected components in the Graph Structures View.

See also Dep_Out for classes.

See also Dep_In for classes.

A package P depends on a package P' if

• a class or interface in P depends on a class or interface in P' (see metric R for a description of these dependencies).
• there is a UML dependency (dashed arrow) from P to P'.

This metric is similar to metric Ce, the difference is that Ce counts the individual classes or interfaces that are depended upon.

The metric counts, for instances of classes of this package, the messages they send to instances of classes from other packages. That is, outgoing messages that cross the package boundary. Note that messages to unclassified instances are not counted here.

The metric counts, for instances of classes of this package, the messages they receive from instances of classes from other packages. That is, incoming messages that cross the package boundary. Note that messages from unclassified instances are not counted here.

The metric counts, for instances of classes of this package, the number of messages they send to themselves or other instances of classes from this package. Note that messages to unclassified instances are not counted here.