ModuleCount Metrics

The ModuleCount metrics classify the modules (a generic name for anything that might be considered a separate entity) used in the system. A module is "used" whenever it is mentioned in the system code. The classification distinguishes modules that are in the standard library ("SL"), modules in the system ("UD" - user defined), and any remaining modules ("TP" - third party). Modules are also classified according to what "kind" they are, namely: primitives ("P"), classes ("C"), interfaces ("I"), enums ("E"), annotations ("A"), and exceptions ("Ex"). An early go at the rationale for why these metrics might be useful can be found in an essay I wrote.

There are a number of combinations possible, namely:

The need for "unknown" is because it is often the case that a module A refers to module B, but the definition of module B is not provided (even for user defined modules). Often the kind of module it is can be determined by context, but sometimes they can't — hence the need for "unknown".

Example

Below are the measurements for jgraph version 5.7.4.3.

SLP SLC SLI SLE SLA SLEx SLUnk TPC TPI TPE TPA TPEx TPUnk UDC UDI UDE UDA UDEx UDUkn
9 96,7 32,1 0 0 13 0 0 0 0 0 0 0 36,37 14,3 0 0 0 0

This indicates that all 9 primitive types were used, reference was made to 96 top-level JRE classes and 7 level-1 nested JRE classes. Also from the JRE are 32 top-level and 1 level-1 nested interfaces, and 13 top-level exceptions. There are no third party modules used at all. Of the modules identified as being in jgraph, 36 are top-level classes, 37 are level-1 nested classes, 14 are top-level interfaces, and 3 are level-1 nested interfaces.

Further Information