next up previous
Next: Tight Class Cohesion ( Up: Cohesion Previous: Lack of Cohesion in


Improvement of LCOM ($ ILCOM$ )

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 $ ILCOM$specific view).
Handle
$ ILCOM$
Description
The Improvement of LCOM (cf. Lack of Cohesion in Methods 3.2.3) metric is a measure for the number of connected components in a class. A component are methods of a class sharing (being connected by) instance variables of the class. The less separate components there are the higher is the cohesion of the methods in the class.
Scope
Class
View
$ {V}^{ILCOM} = ({G}^{ILCOM}, {R}^{ILCOM})$
  • Grammar $ {G}^{ILCOM} = (\{\textrm{class}^{ILCOM}, \textrm{method}^{ILCOM},\\ \textrm{field}^{ILCOM}\}, \emptyset, \textrm{class}^{ILCOM})$
  • Relations $ \\ {R}^{ILCOM}: \{\textrm{methodof}^{ILCOM} : \textrm{method}^{ILCOM} \times \... ...xtrm{uses}^{ILCOM} : \textrm{method}^{ILCOM} \times \textrm{fieILCOM}^{ILCOM}\}$
  • Mapping $ \alpha^{ILCOM}$:
    $\displaystyle \alpha^{ILCOM}(\textrm{Class})$ $\displaystyle \mapsto$ $\displaystyle \textrm{class}^{ILCOM}$  
    $\displaystyle \alpha^{ILCOM}(\textrm{Field})$ $\displaystyle \mapsto$ $\displaystyle \textrm{field}^{ILCOM}$  
    $\displaystyle \alpha^{ILCOM}(\textrm{Method})$ $\displaystyle \mapsto$ $\displaystyle \textrm{method}^{ILCOM}$  
    $\displaystyle \alpha^{ILCOM}(\textrm{IsFieldOf})$ $\displaystyle \mapsto$ $\displaystyle \textrm{fieldof}^{ILCOM}$  
    $\displaystyle \alpha^{ILCOM}(\textrm{IsMethodOf})$ $\displaystyle \mapsto$ $\displaystyle \textrm{methodof}^{ILCOM}$  
    $\displaystyle \alpha^{ILCOM}(\textrm{Accessess})$ $\displaystyle \mapsto$ $\displaystyle \textrm{uses}^{ILCOM}$  

Definition
The $ ILCOM$value of a class $ c \in class^{ILCOM}$, with $ n$methods $ m_{1}, m_{2}, \dots, m_{n} \in M(c)$, having $ \{I(c, m_{i}) \in F(c)\}$represent the set of instance variables used by method $ m_{i}$- there are $ n$such sets $ \{I_{1}, \dots, I_{n} \in F(c)\}$- is defined as:
$\displaystyle F(c)$ $\displaystyle =$ $\displaystyle pred(c, \textrm{fieldof}^{ILCOM})$  
    $\displaystyle \textit{-\hspace{1pt}- set of fields contained in c}$  
$\displaystyle M(c)$ $\displaystyle =$ $\displaystyle pred(c, \textrm{methodof}^{ILCOM})$  
    $\displaystyle \textit{-\hspace{1pt}- set of methods contained in c}$  
$\displaystyle ILCOM(c)$ $\displaystyle =$ $\displaystyle \left\vert scc(F(c) \cup M(c), \textrm{uses}^{ILCOM}) \right\vert$  

Scale
Absolute.
Domain
Integers $ \in 1..\infty$.
Highly Related Software Quality Properties
 
Reliability 2.2
is positively influenced by cohesion.
Maturity 2.2.1:
Parts of a system showing a high cohesion may be highly directly related to maturity, since a mature system ought to have high cohesion values.

Maturity decreases with increasing ILCOM.

Re-Usability 2.4
is negatively influenced by coupling.
Understandability for Reuse 2.4.1:
Parts of a system showing a high cohesion may be highly directly related to understandability for reuse, since they implement only one concept.

Understandability decreases with increasing ILCOM.

Attractiveness 2.4.4:
Parts of a system showing a high cohesion may be highly directly related to attractiveness for reuse, since they implement only one concept.

Attractiveness decreases with increasing ILCOM.

Maintainability 2.6
decreases with increasing ILCOM.
Analyzability 2.6.1:
Parts of a system showing a high cohesion may be highly directly related to analyzability, since they implement only one concept.

Analyzability decreases with increasing ILCOM.

Changeability 2.6.2:
Parts of a system showing a high cohesion may be highly directly related to changeability, since they implement only one concept.

Changeability decreases with increasing ILCOM.

Stability 2.6.3:
Parts of a system showing a high cohesion may be highly directly related to stability, since they implement only one concept.

Stability decreases with increasing ILCOM.

Testability 2.6.4:
Parts of a system showing a high cohesion may be highly directly related to testability, since they implement only one concept.

Testability decreases with increasing ILCOM.

Portability 2.7
decreases with increasing ILCOM.
Adaptability 2.7.1:
Parts of a system showing a high cohesion may be highly directly related to adaptability, since they implement only one concept.

Adaptability decreases with increasing ILCOM.

Related Software Quality Properties
 
Re-Usability 2.4
might decrease with increasing ILCOM.
Learnability for Reuse 2.4.2:
Parts of a system showing a high cohesion may be highly directly related to learnability, since they implement only one concept.

Learnability might decrease with increasing ILCOM.

Operability for Reuse - Programmability 2.4.3:
Parts of a system showing a high cohesion may be highly directly related to programmability, since they implement only one concept.

Programmability might decrease with increasing ILCOM.

Efficiency 2.5
might decrease with increasing ILCOM.
Time Behavior 2.5.1:
Parts of a system showing a high cohesion may be directly related to time behavior, since they implement only one concept, and do not do any unrelated time consuming tasks.

Time behavior might get worse with increasing ILCOM.

Resource Utilization 2.5.2:
Parts of a system showing a high cohesion may be directly related to resource utilization, since they implement only one concept, and do not do any unrelated resource utilization.

Resource utilization might get worse with increasing ILCOM.

Portability 2.7
decreases with increasing ILCOM.
Replaceablity 2.7.4:
Parts of a system showing a high cohesion may be directly related to replaceability, since they implement only one concept.

Replaceablity might decreases with increasing ILCOM.

References
 
  • ILCOM is extensively discussed and evaluated in [11,12,2,19],
  • ILCOM is implemented in the VizzAnalyzer Metrics Suite.
Since
1.0

next up previous
Next: Tight Class Cohesion ( Up: Cohesion Previous: Lack of Cohesion in
Copyright © 2008-2009, ARiSA AB. Phone: +46-(0)470 70 8495 Email: info@arisa.se Valid CSS! Valid XHTML 1.0 Transitional