Mining architectural violations from version history

Abstract

Software architecture conformance is a key software quality control activity that aims to reveal the progressive gap normally observed between concrete and planned software architectures. However, formally specifying an architecture can be difficult, as it must be done by an expert of the system having a high level understanding of it. In this paper, we present a lightweighted approach for architecture conformance based on a combination of static and historical source code analysis. The proposed approach relies on four heuristics for detecting absences (something expected was not found) and divergences (something prohibited was found) in source code based architectures. We also present an architecture conformance process based on the proposed approach. We followed this process to evaluate the architecture of two industrial-strength information systems, achieving an overall precision of 62.7 % and 53.8 %. We also evaluated our approach in an open-source information retrieval library, achieving an overall precision of 59.2 %. We envision that an heuristic-based approach for architecture conformance can be used to rapidly raise architectural warnings, without deeply involving experts in the process.

Appendices

Appendix A: Formal Definition

In this appendix section, we describe the heuristics proposed by ArchLint.

1.1 Notation

The definition of the heuristics relies on the following notation:

• $\mathcal {C}=\{c_{1}, c_{2}, ..., c_{n}\}$ is the set of all classes in the system under analysis.

• C P={c p ₁,c p ₂,...,c p _n } is the set of components in the high-level component model.

• d e p e n d s(c ₁,c ₂,t,v) indicates that class c ₁ has a dependency of type t with class c ₂ in a given version v.

• c o m p(c) is the component cp of a class c.

• m o d(c) is the module m of a class c.

• fi r s t(c) is the version in which class c was originally inserted in the repository.

• H is the identifier of the last version of the system in the repository.

In a depends predicate, the pattern _ (underscore) matches any value. For example,

d e p e n d s(c ₁,c ₂,_,_) indicates that class c ₁ depends on class c ₂, despite the dependency type and the version.

1.2 Detecting Absences

D e p C o m p C l a s s(c,t,c p) is the set of classes in a component cp that—in the current version of the system—have a dependency of type t with a class c, as follows:

$$\begin{array}{@{}rcl@{}} DepCompClass(c,t,cp) = \left\{ x\in \mathcal{C}\ |\ depends(x,x,t,H) \wedge comp(x) = cp \right\} \end{array} $$

C l a s s C o m p(c p) is the set of classes in the component cp, as follows:

$$\begin{array}{@{}rcl@{}} ClassComp(cp) = \left\{ x \in \mathcal{C} \ | \ comp(x) = cp \right\} \end{array} $$

D e p S c a R a t e(c,t,c p) is the ratio between (i) the number of classes in component cp that have a dependency of type t with a target class c and (ii) the total number of classes in component cp, as follows:

$$\begin{array}{@{}rcl@{}} DepScaRate(c,t,cp)=\frac{|DepCompClass(c,t,cp)|}{|ClassComp(cp)|} \end{array} $$

C r e a t e d W i t h o u t D e p(c,t,c p) is the set of classes of a component cp that were committed in the repository for the first time without a dependency of type t with a target class c, as defined next:

$$\begin{array}{@{}rcl@{}} CreatedWithoutDep(c,t,cp) = \left\{x \in \mathcal{C}\ |\ comp(x) = cp\ \wedge \neg depends(x,c,t,first(x))\right\} \end{array} $$

D e p A d d(c,t,c p) is the set of classes in component cp initially created without a dependency of type t with a target class c but that later were maintained to include this dependency, as follows:

$$\begin{array}{@{}rcl@{}} DepAdd(c,t,cp) = \left\{x \in CreatedWithoutDep(c,t,cp)\ |\ depends(x,c,t,H)\right\} \end{array} $$

D e p I n s R a t e(c,t,c p) is the ratio between (i) the number of classes in the component cp originally created without a dependency of type t with a target class c, but that have this dependency in the last version of the system under analysis, and (ii) the total number of classes in component cp originally created without a dependency of type t with class c, as follows:

$$\begin{array}{@{}rcl@{}} DepInsRate(c,t,cp) = \frac{|DepAdd(c,t,cp)|}{|CreatedwithoutDep(c,t,p)|} \end{array} $$

Finally, the candidates for absences in a component cp are defined as follows:

$$\begin{array}{@{}rcl@{}} Absences(cp) = \left\{(x,c,t) \ |\ comp(x) = cp\ \wedge \neg depends(x,c,t,H)\ \wedge \right. \\ DepScaRate(c,t,p) \geq A_{sca}\ \wedge \\ \left. DepScaRate(c,t,p) \geq A_{ins}\right\} \end{array} $$

1.3 Detecting Divergences

1.3.1 Heuristic #1

D e p S y s M o d(m) is the set of classes in the current version of the system that have a dependency with classes of a module m, as follows:

$$\begin{array}{@{}rcl@{}} DepSysMod(m) = \left\{x \in \mathcal{C}\ |\ depends(x,c,\_,H)\ \wedge\ mod(c)= m\right\} \end{array} $$

D e p C o m p M o d(m,c p) is the set of classes in component cp that have a dependency with a module m, as defined next:

$$\begin{array}{@{}rcl@{}} DepCompMod(m,cp) = \left\{ x \in DepSysMod(m)\ |\ comp(x) = cp\right\} \end{array} $$

D e p S c a R a t e(m,c p) is the ratio between (i) the number of classes in component cp that have a dependency with a module m and (ii) the total number of classes in the current version of the system that have a dependency with classes of m, as follows:

$$\begin{array}{@{}rcl@{}} DepScaRate(m,cp) = \frac{|DepCompMod(m,cp|)}{|DepSysMod(m)|} \end{array} $$

D e p A d d A n y(m,c p) is the set of classes in component cp that have established—in any version of the system—a dependency with a class in module m, as defined next:

$$\begin{array}{@{}rcl@{}} DepAddAny(m,cp) = \left\{x \in \mathcal{C}\ |\ comp(x) = cp\ \wedge\ depends(x,c,\_,\_)\ \wedge mod(c) = m \right\} \end{array} $$

D e p D e l(m,c p) is the set of classes returned by D e p A d d A n y(m,c p) that in the current version of the system no longer have a dependency with classes in module m, as defined next:

$$\begin{array}{@{}rcl@{}} DepDel(m,cp) = \left\{x \in DepAddAny(m,cp)\ |\ \neg depends(x,c,\_H)\ \wedge \mod(c) = m\right\} \end{array} $$

D e p D e l R a t e(m,c p) is the ratio between (i) the number of classes in component cp that no longer have a dependency with classes in module m and (ii) the total number of classes in component cp that have established a dependency with any class in module m, as defined next:

$$\begin{array}{@{}rcl@{}} DepDelRate(m,cp)= \frac{|DepDel(m,cp)|}{|DepAddAny(m,cp)|} \end{array} $$

H e a v y U s e r(m) is a function that returns the component whose classes mostly depend on classes located in module m, i.e., the component cp that provides the following maximal value:

$$\underset{\forall cp\ \in \ CP}{\max} \left(\frac{|DepCompMod(m,cp)|}{|DepSysMod(m)|}\right) $$

However, this maximal value must be greater than 0.5. Otherwise, the function H e a v y U s e r returns null.

Finally, the candidates for divergences in a given component cp are defined as follows:

$$\begin{array}{@{}rcl@{}} Div_{1}(cp) = \lbrace \ (x, c) & |\ \ comp(x) = cp\ \wedge\ mod(c) = m\ \wedge\ &depends(x, c,\!\_,H)\ \wedge \\ &{}DepScaRate(m, cp)\ \leq\ D_{sca} \wedge \\ &{\kern-2.5pt}DepDelRate(m, cp)\ \geq\ D_{del} \wedge \\ &{\kern-2.9pc}HeavyUser(m)\ \neq\ cp \ \rbrace \\ \end{array} $$

1.3.2 Heuristic #2

D e p A d d A n y(c,t,c p) is the set of classes in component cp that have established—in any version of the system—a dependency of type t with a class c, as defined next:

$$\begin{array}{@{}rcl@{}} DepAdd(c,t,cp) = \left\{x \in CreatedWithoutDep(c,t,cp)\ |\ depends(x,c,t,H)\right\} \end{array} $$

D e p D e l(c,t,c p) is the set of classes returned by D e p A d d A n y(c,t,c p) that no longer have a dependency of type t with a class c (i.e., the dependencies were removed), as defined next:

$$DepDel(c,t,cp)\,=\, \lbrace \; x \in DepAddAny(c,t,cp) \, | \, comp(x)\! =\! cp \ \wedge \ \neg depends(x, c, t,H) \; \rbrace $$

Additionally, D e p D e l R a t e(c,t,c p) is the ratio between (i) the number of classes in component cp that no longer have a dependency of type t with a class c, and (ii) the total number of classes in component cp that have established a dependency of type t with a class c, as defined next:

$$DepDelRate(c,t,cp) = \frac{|DepDel(c,t,cp)|}{|DepAddAny(c,t,cp)|} $$

Finally, the candidates for divergences in a given component cp are defined as follows:

$$\begin{array}{@{}rcl@{}} Div_{2}(cp) = \lbrace & (x, c, t)\; | \;comp(x) = cp \ \wedge \ depends(x, c, t,H) \wedge\\ &{\kern.1pc}DepScaRate(c,t,cp) \leq D_{sca} \wedge\\ &{\kern-.2pc}DepDelRate(c,t,cp) \geq D_{del} \;\rbrace \end{array} $$

1.3.3 Heuristic #3

This heuristic assumes that r f(c p ₁,c p ₂) denotes the number of references from classes in component c p ₁ to classes in component c p ₂, as defined next:

D e p D i r W e i g h t(c p ₁,c p ₂) is defined as follows:

$$\begin{array}{@{}rcl@{}} DepDirWeight(cp_{1},cp_{2})=\frac{rf(cp_{1},cp_{2})}{rf(cp_{1},cp_{2})+rf(cp_{2},cp_{1})} \end{array} $$

Finally, the candidates for divergences in a given component cp are defined as follows:

$$\begin{array}{@{}rcl@{}} Div_{3}(cp_{1}) = \left\{ (x,c)\ |\ comp(x) = cp_{1}\ \wedge comp(c) = cp_{2}\ \wedge cp_{1} \neq cp_{2}\ \wedge \right. \\ depends(x,c,\_,H)\ \wedge \\ \left. D_{dir} \leqslant DepDirWeight(cp_{1},cp_{2}) < 0.5 \right\} \end{array} $$

Appendix B: M2M Conformance Process

In this section, we show the results achieved after each iteration when detecting architectural violations in the M2M system. Table 14 shows the iterations performed for detecting absences. Tables 15 and 16 shows the results achieved by the second and third heuristics for detecting divergences, respectively. Heuristic #1 for divergences did not report warnings in the M2M system.

Table 14 Detecting absences in the M2M system

Table 15 Detecting divergences in the M2M system using Heuristic #2

Table 16 Detecting divergences in the M2M system using Heuristic #3

Appendix C: Lucene Conformance Process

In this section, we show the results achieved after each iteration when detecting architectural violations in the Lucene system. Tables 17, 18, and 19 shows the results achieved by the first, second and third heuristics for detecting divergences, respectively. The heuristic for absences did not report warnings in the Lucene system.

Table 17 Detecting divergences in Lucene using Heuristic #1

Table 18 Detecting divergences in Lucene using Heuristic #2

Table 19 Detecting divergences in Lucene using Heuristic #3