Change Dependency Between Classes ($CDBC$ )

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 $CDBC$specific view).

Handle

$CDBC$

Description

The Change Dependency Between Classes ($CDBC$) measures the class level coupling. It is a measure assigned to pairs of classes describing how dependent one class (client class) is on the other (server class). This allows conclusions on the follow-up work to be done in a client class, when the server class is changed in the course of re-engineering.

Scope

Class pairs

View

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

• Grammar ${G}^{CDBC} = (\{\textrm{class}^{CDBC}, \textrm{method}^{CDBC}\}, \emptyset, \textrm{class}^{CDBC})$
• Relations ${R}^{CDBC} = \{\textrm{call}^{CDBC} : \textrm{method}^{CDBC} \times \textrm{me... ...\textrm{inherits}^{CDBC} : \textrm{class}^{CDBC} \times \textrm{class}^{CDBC}\}$
• Mapping $\alpha^{CDBC}$:
  

  $$\alpha^{CDBC}(\textrm{Class}) \mapsto \textrm{class}^{CDBC}$$

  $$\alpha^{CDBC}(\textrm{Method}) \mapsto \textrm{method}^{CDBC}$$

  $$\alpha^{CDBC}(\textrm{IsMethodOf}) \mapsto \textrm{containsMethod}^{CDBC}$$

  $$\alpha^{CDBC}(\textrm{InheritsFrom}) \mapsto \textrm{inherits}^{CDBC}$$

  $$\alpha^{CDBC}(\textrm{IsOfType}) \mapsto \textrm{typeRef}^{CDBC}$$

  $$\alpha^{CDBC}(\textrm{Accessess}) \mapsto \textrm{access}^{CDBC}$$

  $$\alpha^{CDBC}(\textrm{Invokes}) \mapsto \textrm{call}^{CDBC}$$

  
  

Definition

The $CDBC$value of a pair of classes $CC, SC \in class^{CDBC}$is defined as:

$$CDBC(CC, SC) = min\left(n, A \right)$$

$$\textit{-\hspace{1pt}- with $n$\ is the number of methods}$$

$$A = \sum^{m_{1}}_{impl=1}\alpha_{impl} + (1-k) \sum^{m_{2}}_{interface=1} \alpha_{interface}$$

$$\textit{-\hspace{1pt}- with $m_1$\ are the methods in $CC$\ accessing}$$

$$\textit{\hspace{1pt} the implementation of $SC$\ being possibly}$$

$$\textit{\hspace{1pt} affected}$$

$$\textit{-\hspace{1pt}- with $m_2$\ are the methods in $CC$\ accessing}$$

$$\textit{\hspace{1pt} the interface of $SC$\ being possibly affected}$$

$\alpha$is determined according to the following table:

Table 3.1: Relationship types between CC and SC and their corresponding contribution $\alpha$ to change dependency.

Relationship types between $CC$ and $SC$	$\alpha =$ number of methods of $CC$
	potentially affected by a change
$SC$ is not used by $CC$ at all	0
$SC$ is the class of an instance variable of $CC$	n
Local variables of type $SC$ are used within $j$	j
methods of $CC$
$SC$ is a superclass of $CC$	n
$SC$ is the parameter type of j methods of $CC$	j
$CC$ accesses a global variable of class $SC$	n

Scale

Ordinal.

Domain

Integers in $0..\infty$, 0 means there is no change dependency between the pair of classes.

Highly Related Software Quality Properties

 

Re-Usability 2.4

is negatively influenced by coupling.

Understandability for Reuse 2.4.1:

Parts, which have a high (outgoing) efferent coupling may be highly inversely related to understandability, since they are using other parts of the system which need to be understood as well.

Understandability decreases with increasing CDBC.

Attractiveness 2.4.4:

Parts that have a high (outgoing) efferent coupling may be highly inversely related to attractiveness, since they are using other parts of the system which need to be understood as well, and represent dependencies.

Attractiveness decreases with increasing CDBC.

Maintainability 2.6

decreases with increasing CDBC.

Analyzability 2.6.1:

Parts that have a high (outgoing) efferent coupling may be highly inversely related to analyzability, since they are using other parts of the system which need to be analyzed as well.

Analyzability decreases with increasing CDBC.

Changeability 2.6.2:

Parts that have a high (outgoing) efferent coupling may be inversely related to changeability, since they are using other parts of the system which might need to be changed as well.

Changeability decreases with increasing CDBC.

Stability 2.6.3:

Parts showing a high (outgoing) efferent coupling may be inversely related to stability, since they are using other parts of the system, which are can affect them.

Stability decreases with increasing CDBC.

Testability 2.6.4:

Parts that have a high (outgoing) efferent coupling may be highly inversely related to testability, since they are using other parts of the system which increase the number of possible test paths.

Testability decreases with increasing CDBC.

Portability 2.7

decreases with increasing CDBC.

Adaptability 2.7.1:

Parts that have a high (outgoing) efferent coupling may be inversely related to adaptability, since they are using other parts of the system that might need to be adapted as well.

Adaptability decreases with increasing CDBC.

Related Software Quality Properties

 

Functionality 2.1

is both negatively and positively influenced by coupling.

Interoperability 2.1.3:

Parts that have a high (outgoing) efferent coupling may be directly related to interoperability, since they are using/interacting with other parts of the system.

Interoperability might increase with increasing CDBC.

Security 2.1.4:

Parts that have a high (outgoing) efferent coupling may be inversely related to security, since they can be affected by security problems in other parts of the system.

Security might decrease with increasing CDBC.

Reliability 2.2

might decrease with increasing CDBC.

Fault-tolerance 2.2.2:

Parts that have a high (outgoing) efferent coupling may be inversely related to fault-tolerance, since they can be affected by faults in other parts of the system.

Fault-Tolerance might decrease with increasing CDBC.

Recoverability 2.2.3:

Parts that have a high (outgoing) efferent coupling may be inversely related to recoverability, since their data is distributed in other parts of the system making their recovery difficult.

Recoverability might decrease with increasing CDBC.

Re-Usability 2.4

might decrease with increasing CDBC.

Learnability for Reuse 2.4.2:

Parts that have a high (outgoing) efferent coupling may be inversely related to learnability, since they are using other parts of the system which need to be understood as well.

Learnability might decrease with increasing CDBC.

Operability for Reuse - Programmability 2.4.3:

Parts having a high (outgoing) efferent coupling may be inversely related to learnability, since they are using other parts of the system, which represent dependencies.

Programmability might decrease with increasing CDBC.

Efficiency 2.5

might decrease with increasing CDBC.

Time Behavior 2.5.1:

Parts that have a high (outgoing) efferent coupling may be inversely related to time behavior, since they are using other parts of the system, thus execution during test or operation does not stay local, but might involve huge parts of the system.

Time behavior might get worse with increasing CDBC.

Resource Utilization 2.5.2:

Parts that have a high (outgoing) efferent coupling may be inversely related to resource utilization, since they are using other parts of the system, thus execution during test or operation does not stay local, but might involve huge parts of the system.

Resource utilization might get worse with increasing CDBC.

References

 

• CDBC is extensively discussed and evaluated in [11,12,2,19],
• it is implemented in the VizzAnalyzer Metrics Suite.

Since

1.0

Copyright © 2008-2009, ARiSA AB. Phone: +46-(0)470 70 8495 Email: info@arisa.se