Number Of local Methods ( )

Next: Structural Complexity Up: Interface Complexity Previous: Number of Attributes and

Number Of local Methods ( )

Works with all instances of a common meta-model, regardless of whether they were produced with the Java or the UML front-end. The respective extends (Java) or generalization (UML) relations expressing the inheritance between two classes are mapped onto relations of type inheritance in the common meta-model (and the

specific view).

Handle

Description

Number of local Methods measures the number of methods locally declared in a class. Inherited methods are not considered. It is the size of the interface of a class and allows conclusions on its complexity.

Scope

Class

View

${V}^{NOM} = ({G}^{NOM}, {R}^{NOM})$

Grammar ${G}^{NOM} = (\{\textrm{class}^{NOM}, \textrm{method}^{NOM}\}, \emptyset, \textrm{class}^{NOM})$
Relations ${R}^{NOM}: \{\textrm{methodof}^{NOM} : \textrm{method}^{NOM} \times \textrm{class}^{NOM}\}$

Mapping $\alpha^{NOM}$ :

$\displaystyle \alpha^{NOM}(\textrm{Class})$	$\displaystyle \mapsto$	$\displaystyle \textrm{class}^{NOM}$
$\displaystyle \alpha^{NOM}(\textrm{IsMethodOf})$	$\displaystyle \mapsto$	$\displaystyle \textrm{methodof}^{NOM}$
$\displaystyle \alpha^{NOM}(\textrm{Method})$	$\displaystyle \mapsto$	$\displaystyle \textrm{method}^{NOM}$

Definition

The

value of a class $c \in class^{NOM}$ is defined as:

$\displaystyle M(c)$	$\displaystyle =$	$\displaystyle pred(c, \textrm{methodof}^{NOM})$
		$\displaystyle \textit{-\hspace{1pt}- set of methods directly contained in c}$
$\displaystyle NOM(c)$	$\displaystyle =$	$\displaystyle \left\vert M(c) \right\vert$

Scale

Absolute.

Domain

Integers $\in 0..\infty$ .

Highly Related Software Quality Properties

Re-Usability 2.4

is both negatively and positively influenced by NOM.

Understandability for Reuse 2.4.1:: Understanding if a class is suitable for reuse depends on its size.
Understandability declines with increasing NOM.
Learnability for Reuse 2.4.2:: Learning if a class is suitable for reuse depends on the size and complexity of its interface. NOM measures interface size.
Learnability might decline with increasing NOM.
Operability for Reuse - Programmability 2.4.3:: How well a class can be integrated depends the complexity of its interface. NOM measures interface size.
Programmability might decline with increasing NOM.
Attractiveness 2.4.4:: Attractiveness of a class depends on the size of the potentially reused code.
Attractiveness increases with increasing NOM.

Maintainability 2.6

declines with increasing NOM.

Analyzability 2.6.1:: The effort and time for diagnosis of deficiencies or causes of failures in software entity, or for identification of parts to be modified is directly related to its size.
Analyzability declines with increasing NOM.
Changeability 2.6.2:: Changing a class requires prior understanding, which, in turn, is more complicated for large systems.
Changeability declines with increasing NOM.
Testability 2.6.4:: Complete testing requires coverage of all execution paths. The number of possible execution paths of a system increases with its size.
Testability declines with increasing NOM.

Portability 2.7

declines with increasing NOM.

Adaptability 2.7.1:: As for changeability 2.6.2, the size of software has a direct impact. Each modification requires understanding which is more complicated for large systems.
Adaptability declines with increasing NOM.
Replaceablity 2.7.4:: The substitute of a component must imitate its interface. Large interfaces are difficult to check for substitutability and to actually substitute. Interface size is specifically assessed by NOM.
Replaceablity decline with increasing NOM.

Related Software Quality Properties

Functionality 2.1

might increase with increasing NOM.

Interoperability 2.1.3:: Interoperability requires to be able to locate the parts of a system responsible for interoperability. The size of in these parts might indicate a better ability to interact.
Interoperability might increase with increasing NOM.
Security 2.1.4:: Relating NOM to security requires to be able to locate the parts of a system responsible for security. The size of these parts might indicate a higher security.
Security might increase with increasing NOM.

Reliability 2.2

might increase with increasing NOM.

Maturity 2.2.1:: Due to reduced analyzability 2.6.1 and testability 2.6.4, bugs mights be left in the software. Therefore, also maturity may be influenced negatively by interface size.
Maturity might decline with increasing NOM.
Fault-tolerance 2.2.2:: Relating NOM to fault-tolerance requires to be able to locate the parts of a system responsible for fault-tolerance. The size of these parts might indicate a better ability to interact.
Fault-Tolerance might increase with increasing NOM.
Recoverability 2.2.3:: Relating NOM to recoverability requires to be able to locate the parts of a system responsible for recoverability. The size of these parts might indicate a higher recoverability.
Recoverability might increase with increasing NOM.

Efficiency 2.5

might decline with increasing NOM.

Time Behavior 2.5.1:: Static size might indicate a higher execution time due to increased number of instruction cache misses, long jumps, etc.
Time behavior might get worse with increasing NOM.
Resource Utilization 2.5.2:: Static size might indicate a higher memory utilization.
Resource utilization might get worse with increasing NOM.

Maintainability 2.6

declines with increasing NOM.

Stability 2.6.3:: Due to reduced analyzability 2.6.1 and testability 2.6.4, also stability may be influenced negatively by size.
Stability might decline with increasing NOM.

References

The NOM metric is extensively discussed in [14,2,4,11],
and evaluated in a case study [19],
NOM is implemented in the VizzAnalyzer Metrics Suite.

Since

Compendium 1.0

Next: Structural Complexity Up: Interface Complexity Previous: Number of Attributes and