# Recovery and Analysis of Architecture Descriptions using Centrality Measures

Sanjay Thakare1, Arvind W Kiwelekar2
Babasaheb Ambedkar Technological University,
Maharashtra, India.
<EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

The necessity of an explicit architecture description has been continuously
emphasized to communicate the system functionality and for system maintenance
activities. This paper presents an approach to extract architecture
descriptions using the centrality measures from the theory of Social Network
Analysis. The architecture recovery approach presented in this paper works in
two phases. The first phase aims to calculate centrality measures for each
program element in the system. The second phase assumes that the system has
been designed around the layered architecture style and assigns layers to each
of the program element. Two techniques to assign program elements are
presented. The first technique of layer assignment uses a set of pre-defined
rules, while the second technique learns the rules of assignment from a pre-
labelled data set. The paper presents the evaluation of both approaches.

Keywords: Architecture Recovery, Centrality Measures, Module Dependency View,
Layered Architecture Style, Supervised Classification, Architecture
Descriptions.

##  1 Introduction

The value of explicit software architecture has been increasingly recognized
for software maintenance, and evolution activities [15]. Especially
architecture descriptions relating coarsely granular programming elements
found as a useful tool to effectively communicate system functionality and
architectural decisions [22, 29]. These descriptions also support dependency
analysis which drives the task of software modernization [6]. Despite the
numerous benefits, a legacy or open-source software system often lacks such
kind of architecture descriptions. Moreover when such architecture
descriptions are available, these are not aligned with the latest version of
system implementation [26].

In such situations, a light-weight architecture recovery approach which
approximately represents the true architecture of a system may be more
convenient over the sophisticated techniques of architecture recovery. Such a
light-weight approach shall quickly extract relevant information necessary to
build architecture descriptions so that it can provide much-needed assistance
to software architects dealing with re-engineering and modernization of
existing systems, thus increasing their productivity.

Intending to design a light-weight approach, this paper presents an
architecture recovery approach based on centrality measures from the theory of
Social Network Analysis [23, 1]. Three observations drove the rationale behind
using centrality measures for architecture extraction: (i) Most of these
measures provide a highly intuitive and computationally simple way to analyze
interactions when a graph represents the structure of a system. (ii) These
measures quantify the structure of a system at multiple levels, i.e., at a
particular node level, in relation to other nodes in the graph, and at a group
of nodes or communities. (iii) These measures support the development of data-
driven approaches to architecture recovery.

The centrality measures-based approach presented in this paper recovers
architecture descriptions in two phases. In the first phase, a centrality
score is assigned to each program element. We assume that the system
functionality is decomposed among multiple layers, and so in the second phase,
a layer is assigned to each program element.

The paper primarily contributes to existing knowledge-base of architecture
recovery domain in the following ways. (1) The paper demonstrates the use of
centrality measures in recovering high-level architecture descriptions. (2)
The paper describes a data-driven approach to architecture recovery using
supervised classification algorithms. (3) The paper presents an evaluation of
supervised classification algorithms in extracting architectural descriptions.

Rest of the paper is organized as follows: The centrality measures used in the
paper are defined in Section II. Section III describes the central element of
the approach. The algorithmic and data-driven approaches to the problem of
layer assignment are explained in Section IV. The results and evaluation of
the approach are presented in Section V. The section VI puts our approach in
the context of existing approaches by discussing its features in relation with
them. Finally, the paper concludes in Section VII.

Figure 1: An Example of Class Dependencies with and their centrality scores.

---

PID | ind | outd | deg | bet | clos | eig
---|---|---|---|---|---|---
A | 0 | 3 | 3 | 0 | 0.71 | 0
B | 0 | 1 | 1 | 0 | 0.5 | 0
C | 1 | 1 | 2 | 2 | 0.6 | 0.055
D | 2 | 2 | 4 | 2.5 | 1 | 0.27
E | 2 | 3 | 5 | 5.5 | 0.8 | 0.0055
F | 3 | 0 | 3 | 0 | 0 | 1
G | 2 | 0 | 2 | 0 | 0 | 0.99
L2 | 1 | 5 | 6 | 0 | 1 | 0.5
L1 | 4 | 5 | 9 | 1 | 1 | 0.5
L0 | 5 | 0 | 5 | 0 | 0 | 1

##  2 Social Network Analysis Measures

The theory of Social Network Analysis (SNA) provides a generic framework to
analyze the structure of complex systems. This framework includes a rich set
of measures, models, and methods to extract the patterns of interactions among
systems’ elements. A complex system is expressed as a network of nodes and
edges to support the analysis of systems from diverse application domains.

Examples of complex systems that have been analyzed with the help of SNA
include communities on social media platforms[23], and neural systems[1]. The
techniques from SNA have been applied to control the influence of the
disease[30] to understand biological systems[27], to investigate the protein
interactions [2], and to examine animal behavior[31].

These diverse applications of SNA show that a complex system exhibits certain
graph-theoretic common properties such as centrality, scale-free, small world,
community structure, and power-law degree distribution [19, 21, 20, 1, 4, 7].
Some of these commonly observed SNA measures relevant to our study are
described below.

The theory of Social Network Analysis (SNA) provides a range of measures with
varying levels. Some are applied at the node level where others applied at the
network level. The node-level measures are fine-grain measures that are
calculated from the nodes which are directly connected to a given node. The
Centrality measures[28] are the examples of node-level measures that quantify
the importance of an individual or a node in the network. A central node is an
influential node having significant potential to communicate and access the
information. There exists different centrality measures and they are derived
from the connections to a node, position of a node in the network, distance of
a node from others, and relative importance of nodes.

###  2.1 Degree centrality

This measure determines the central node based on the connections to the
individual node. A node with a higher degree in the network is considered as
the most influential one. In a directed graph, two different centrality
measures exist in-degree and out-degree based on the number of incoming and
outgoing edges respectively. The degree centrality of a node $v$ is equal to
the number of its connections normalized to the maximum possible degree of the
node.

$C_{D}(v)=deg(v)$ (1) $NC_{D}=\frac{C_{D}(v)}{n-1}=\frac{deg(v)}{n-1}$ (2)

###  2.2 Closeness centrality

This measure aims to identify an influential node in terms of faster and wider
spread of information in the network. The influential nodes are characterized
by a smaller inter-node distance which signify the faster transfer of
information. The closeness centrality is derived from the average distance
from a node to all the connected nodes at different depths. However, the
distance between the disconnected components of the network is infinite and
hence it is excluded. For the central node, the average distance would be
small and is calculated as the inverse of the sum of the distance to all other
nodes. The normalized closeness($NC_{C}$) is in the range from 0 to 1 where 0
represents an isolated node and 1 indicates a strongly connected node.

$C_{C}(v)=\sum(\frac{1}{d_{vw}})$ (3) $NC_{C}=\sum(\frac{n-1}{d_{vw}})$ (4)

###  2.3 Betweenness centrality

This measure aims to identify those central nodes which are responsible for
connecting two or more components of the network. Removal of such a central
node would mean a disconnection of the complete network. Hence, these nodes
act as a bridge to pass the information [4, 32]. Betweenness centrality is
defined as the number of shortest paths passing through a node.

$C_{B}(v)=\sum_{s\neq v\neq t}\frac{\sigma_{st}(v)}{\sigma_{st}}$ (5)

where, $\sigma_{st}$ is the total number of shortest paths from a node $s$ to
$t$ and $\sigma_{st}(v)$ is the number of paths that pass through $v$. The
relative betweenness centrality of any node in the graph with respect to the
maximum centrality of the node is calculated from $C_{B}(v)$.

$C_{B}^{{}^{\prime}}(v)=\frac{2C_{B}(v)}{n^{2}-3n+2}$ (6)

###  2.4 Eigenvector centrality

The Eigenvector centrality is a relative centrality measure, unlike the
previous three measures that are absolute one. The Eigenvector centrality
calculation depends on the largest real Eigenvalue present in the symmetric
adjacency matrix. The centrality of a node $v$ is proportional to the sum of
the centralities of the nodes connected to it [3, 4].

$\lambda v_{i}=\sum_{j=1}^{n}{a_{ij}v_{j}}$ (7)

In general, it requires the solution of the equation $Av=\lambda v$ where $A$
is an adjacency matrix.

Figure 1 shows the centrality scores of various programming elements
calculated by considering the dependencies as shown in the figure. Here, it is
to be noted that centrality scores can be calculated at different granularity
levels i.e., at the object, method, class, package or at a logical layer. In
the figure, centrality scores are calculated at class and layer level. Here,
we have considered a layer as logical encapsulation unit loosely holding
multiple classes.

##  3 Approach

The broad objective of the approach is to extract high-level architecture
descriptions from the implementation artefacts so that the analysis specific
to an architecture style can be performed. In this paper, we demonstrate the
approach with the help of implementation artefacts available in a Java-based
system such as Java and JAR files. However, the method can be extended to
other language-specific artefacts. Similarly, the approach assumes that a
system under study is implemented around the Layered architecture style and
demonstrates analyses specific to the Layered architecture style.

Figure 2: Block diagram of a tool implement in Java to discover layered
architecture using centrality.

As shown in Figure 2, the approach consists of following two phases.

  1. 1.

Dependency Network Builder and Analysis [Phase 1]: The purpose of this phase
is to retrieve the dependencies present in the implementation artefacts. For a
Java-based system, this phase takes Java or Jar files as an input and
generates a dependency network. The programming elements such as Classes,
Interfaces, and Packages are the nodes of the network and the Java
relationships such as $extends$, $implements$, and $imports$ are the edges in
the dependency network. The output of this stage is represented as a graph in
Graph Modeling Language (GML) notations. In the second stage, a centrality
score to each node is assigned. The centrality score includes the different
measures described in Section 2, and they are calculated at the Class and
Interface levels. The output of this stage is a data file in the CSV format
describing the centrality score assigned to each program element.

  2. 2.

Architecture Style Recovery and Analysis [Phase 2] The purpose of this phase
is to perform architecture style-specific activities. In this paper, the
activities of this phase are illustrated by assuming Layered architecture
style. For the Layered architecture style, we define a sub-activity called
layer assignment. The layer assignment activity aims to assign the most
appropriate layer to a program element.

Additional style-specific analyses such as analysis of layer violations, and
performance modeling can be supported once the programming elements are
assigned to appropriate layers.

The Phase 1 activities which include building a dependency network and
calculating centrality scores are straightforward to realize when the tools
such as $JDependency$ are available. The Phase 2 activities that are
performing style-specific analyses can be realized in multiple ways. Two such
techniques to realize architecture style-specific analyses are described in
the following section.

Centrality | Upper | Middle | Lower
---|---|---|---
In-degree | low | - | high
Out-degree | high | - | low
Betweenness | low | high | low
Closeness | high | high | low
Eigenvector | low | low | high

Table 1:  Relative Significance of centrality measures with respect to layers $\delta_{il}$ and $\delta_{iu}$ |  Lower and upper bound for in-degree centrality values.
---|---
$\delta_{ol}$ and $\delta_{ou}$ |  Lower and upper bound for out-degree centrality values.
$\delta_{b}$ |  Critical Value for between-ness centrality
$\delta_{c}$ |  Critical Value for closeness centrality
$\delta_{e}$ |  Critical Value for eigen-value centrality
Table 2: Configuration Parameters

##  4 Layer Assignment

The objective of the layer assignment stage is to identify the most
appropriate layer based on the centrality measures. We assume a three-layers
based decomposition. Here, we use the term layer in the loose sense that a
layer is a logical coarse-grained unit of encapsulating program elements and
not in the strict sense as that used for Layer architecture style [5]. The
decision to decompose all the system responsibilities into three layers is
based on the observation that functionalities for the majority of the
applications can be cleanly decomposed into three coarse-grained layers. For
example, many applications typically use architectural styles such as Model-
View-Controller (MVC), Presentation-Abstraction-Control (PAC),[5] and a 3-tier
style, i.e. Presentation, Business Logic, and Data Storage.

Algorithm 1 : primaryLabel(inDegree, outDegree, n)
Input: inDegree[1:n],outDegree[1:n]: Vector, n:Integer
Output: inPartition[1:n], outPartition[1:n] Vector

1:Initialize $\delta_{iu}$, $\delta_{il}$, $\delta_{ou}$ and $\delta_{ol}$

2:for node in 1 to n do

3: if $in(node)=0$ and $out(node)=0$ then

4: $inPartition[node]\leftarrow lower$

5: $outPartition[node]\leftarrow lower$ 5

6: else

7: if $in(node)>\delta_{il}$ then

8: $inPartition[node]\leftarrow lower$

9: else

10: if $in(node)<\delta_{iu}$ then

11: $inPartition[node]\leftarrow upper$

12: else

13: $inPartition[node]\leftarrow middle$

14: end if

15: end if

16: if $out(node)>\delta_{ou}$ then

17: $outPartition[node]\leftarrow upper$

18: else

19: if $out(node)<\delta_{ol}$ then

20: $outPartition[node]\leftarrow lower$

21: else

22: $outPartition[node]\leftarrow middle$

23: end if

24: end if

25: end if

26:end for

Two different techniques are developed to assign layers to program elements
based on centrality measures. The first techniques uses a set of pre-defined
rules. The second technique automatically learns the assignment rules from the
pre-labelled layer-assignments using a supervisory classification algorithm.

###  4.1 Rule-Driven Layer Assignment

Dependencies among the program elements are used to identify logical units of
decomposition. These dependencies are quantified in-terms of centrality
measures described in Section 2. The measure of degree centrality from Section
II-A is further divided as in-degree ($inDeg$) and out-degree ($outDeg$)
measures which count the number of incoming and outgoing edges of a node.
Total five measures of centrality are used. A set of configuration parameters,
as shown in Table 2, are defined. These parameters provide flexibility while
mapping program elements to a specific layer.

Five accessor functions namely $in$, $out$, $between$, $closeness$ and $eigen$
are defined to get the values of in-degree centrality, out-degree centrality,
betweenness centrality, closeness centrality and eigenvector centrality
associated to a specific node. These functions are used to assign a program
element to a specific layer from three layers, i.e. upper, middle and lower.
Table 1 describes the relative significance of various centrality measure
regarding upper, middle and lower layers.

The Algorithm 1 is operated on a dependency-network in which nodes represent
program element and edges dependencies. The objective of this algorithm is to
partition the node space representing into three segments corresponding to
lower, middle and upper layers. The algorithm calculates two different
partitions. The first partition i.e. $inPartition$ is calculated using the in-
degree centrality measure while the second partition is calculated using the
out-degree centrality measure.

Algorithm 2 refineLabel(inParticion, outPartition, n)
Input: inPartition[1:n], outPartition[1:n]: Vector
n: Integer
Output: nodeLabels[1:n]: Vector

1:Initialize $\delta_{b}$, $\delta_{c}$ and $\delta_{e}$

2:for node in 1 to n do

3: if $inPartition[node]=outPartition[node]$ then

4: $nodeLabels[node]\leftarrow outPartition[node]$

5: else

6: $nodeLabels[node]\leftarrow\newline
upDown(inPartition[node],outPatition[node])$

7: end if

8:end for

After the execution of Algorithm 1 each node is labeled with two labels
corresponding to layers. The various combination of labels include (lower,
lower), (middle, middle), (top, top), (middle, top), and (middle, lower). Out
of these six labelling, the labels (middle, top), and (middle, lower) are
conflicting because two different labels are assigned to a node. This conflict
needs to be resolved.

The Algorithm 2 resolves the conflicting labels and assigns the unique label
to each node. The conflicting labels are resolved by using the rules described
in the decision Table 3. The function $upDown$ called in the Algorithm 2 uses
these rules. The rules in Table 3 resolve the conflicting assignments using
the centrality measures of closeness, between-ness, and Eigen vector, while
the primary layer assignment is done with in-degree and out-degree centrality
measures. When Algorithm 2 is executed, some of the nodes from the middle
layer bubble up to the upper layer, and some nodes fall to the lower level.
Some nodes remain at the middle layer. The vector $nodeLabels$ holds the
unique labelling of each node in the dependency network after resolving all
conflicts.

Table 3: Decision Table used to Refine Layering Layer | Measure | Significance | Rationale
---|---|---|---
upper | in | 0 |  Classes with in-degree value equal to 0 are placed in the upper layer.
out | high |  Classes with high out-degree are placed in the top layer because they use services from layers beneath them.
closeness | high |  Classes with high closeness value are placed in the upper layer because of large average distance from top layer to bottom layer.
middle | between | high |  Classes with high betweenness value are placed in the middle layer as they fall on the path from top layer to bottom layer.
lower | in | high |  Classes with high in-degree value are placed in the bottom layer because they are highly used.
out | 0 |  Classes with out-degree value equal to zero are placed to bottom layer because they only provide services.
eigen | 1 |  Classes with eigen value equal to 1 are placed to bottom layer because they are highly reused.
in | - |  Classes with in-degree and out-degree values are equal to 0 are placed to bottom layer, because they are isolated classes.

###  4.2 Supervised Classification based Layered Assignment

The configuration parameters need to be suitably initialized for the correct
functioning of the algorithmic-centric approach discussed in the previous
section. The system architect responsible for architecture recovery needs to
fine tune the parameters to get layering at the desired level of abstraction.
To overcome this drawback a data-driven approach is developed to assign labels
to the programming elements.

Table 4: Sample observations from the Datasets used for Supervised Learning Id |  Label |  In-Degree |  Out-Degree |  Closeness |  Between- ness |  Eigen- vector |  Layer
---|---|---|---|---|---|---|---
HealthWatcher
1 |  ComplaintRecord |  1 |  10 |  1.714 |  19 |  0.0056 |  2
2 |  ObjectAlreadyInserted Exception |  37 |  0 |  0 |  0 |  0.347 |  1
3 |  ObjectNotFound Exception |  53 |  0 |  0 |  0 |  0.943 |  1
4 |  ObjectNotValidException |  41 |  0 |  0 |  0 |  0.883 |  1
5 |  RepositoryException |  60 |  0 |  0 |  0 |  1 |  1
ConStore
1 |  Cache |  2 |  1 |  1 |  0 |  0.0162 |  2
2 |  CacheObject |  4 |  0 |  0 |  0 |  0.053 |  2
3 |  LRUCache |  0 |  2 |  1 |  0 |  0 |  2
4 |  MRUCache |  1 |  2 |  1 |  7 |  0.0246 |  2
5 |  ItemQuery |  1 |  20 |  0.412 |  47.166 |  0.0388 |  2

In the data-driven approach, the problem of layered assignment is modeled as a
multi-class classification problem with three labels i.e. lower (1), middle
(2) and upper (3) with numerically encoded as 1,2, and 3 respectively. The
classification model is trained on the labeled data-set. The data set, as
shown in Table 4, includes program element identifiers, values of all the
centrality measures and layering labels as specified by the system architect
responsible for architecture recovery. The layering labels can be used from
the previous version of the system under study or the labels guessed by system
architect to explore different alternatives for system decomposition.

We implement three supervised classification algorithm namely K-Nearest
Neighbour, and Support Vector Machine and Decision Tree. These are the machine
learning algorithms particularly used for multi-class classification problems.
A detailed comparison of these various algorithms can be found in [12]
Python’s Scikit-Learn [11] library is used to develop classification model
based on these algorithms. Table 4 shows the format of the sample dataset used
to train the classification models. The developed models are evaluated against
the classification metrics such as accuracy, precision, recall, and F1-Score.
.

Figure 3: An Architecture of a System Designed to Test the approach Table 5:
Accuracy and Confusion Matrix for Data-Driven and Algorithmic Approach
Constore (Size: 66 classes or interfaces) Confusion Matrix
---
SVM |  Decision Tree |  KNN classifier |  Rule based
Layer |  lower |  middle |  upper |  lower |  middle |  upper |  lower |  middle |  upper |  lower |  middle |  upper
lower |  43 |  0 |  0 |  43 |  0 |  0 |  40 |  3 |  0 |  27 |  16 |  0]
middle |  14 |  0 |  1 |  13 |  2 |  0 |  12 |  3 |  0 |  9 |  5 |  1
upper |  6 |  0 |  2 |  6 |  0 |  2 |  7 |  1 |  0 |  4 |  2 |  2
Accuracy = 0.68 |  Accuracy = 0.71 |  Accuracy = 0.65 |  Accuracy =0.52
Recall (R), Precision (P), F1-Score (F1) Evaluation
|  R |  P |  F-1 |  R |  P |  F-1 |  R |  P |  F-1 |  R |  P |  F-1
lower |  0.68 |  1.00 |  0.81 |  0.69 |  1.00 |  0.82 |  0.68 |  0.93 |  0.78 |  0.68 |  0.63 |  0.65
middle |  0.00 |  0.00 |  0.00 |  1.00 |  0.13 |  0.24 |  0.43 |  0.20 |  0.27 |  0.22 |  0.33 |  0.26
top |  0.67 |  0.25 |  0.36 |  1.00 |  0.25 |  0.40 |  0.00 |  0.00 |  0.00 |  0.67 |  0.25 |  0.36
HealthWatcher(Size: 135 classes or interfaces) Confusion Matrix
lower |  47 |  1 |  9 |  49 |  4 |  4 |  41 |  8 |  8 |  28 |  16 |  13
middle |  20 |  5 |  12 |  15 |  20 |  2 |  7 |  28 |  2 |  6 |  30 |  1
upper |  5 |  1 |  35 |  7 |  0 |  34 |  6 |  6 |  29 |  3 |  9 |  29
Accuracy = 0.64 |  Accuracy = 0.76 |  Accuracy = 0.72 |  Accuracy = 0.63
Recall (R), Precision (P), F1-Score (F1) Evaluation
|  R |  P |  F-1 |  R |  P |  F-1 |  R |  P |  F-1 |  R |  P |  F-1
lower |  0.65 |  0.82 |  0.73 |  0.69 |  0.86 |  0.77 |  0.76 |  0.72 |  0.74 |  0.76 |  0.49 |  0.60
middle |  0.71 |  0.14 |  0.23 |  0.83 |  0.54 |  0.66 |  0.67 |  0.76 |  0.71 |  0.55 |  0.81 |  0.65
upper |  0.62 |  0.85 |  0.72 |  0.85 |  0.83 |  0.84 |  0.74 |  0.71 |  0.72 |  0.66 |  0.66 |  0.66
Test Architecture System (Size = 16 Classes) Confusion Matrix
lower |  5 |  2 |  0 |  4 |  3 |  0 |  5 |  2 |  0 |  5 |  2 |  0
middle |  1 |  4 |  0 |  0 |  5 |  0 |  1 |  4 |  0 |  1 |  4 |  0
upper |  1 |  0 |  3 |  0 |  1 |  3 |  4 |  0 |  0 |  1 |  0 |  3
Accuracy = 0.75 |  Accuracy = 0.75 |  Accuracy = 0.56 |  Accuracy =0.75
Recall (R), Precision (P), F1-Score (F1) Evaluation
|  R |  P |  F-1 |  R |  P |  F-1 |  R |  P |  F-1 |  R |  P |  F-1
lower |  0.71 |  0.71 |  0.71 |  1.00 |  0.57 |  0.73 |  0.50 |  0.71 |  0.59 |  0.71 |  0.71 |  0.71
middle |  0.67 |  0.80 |  0.73 |  0.56 |  1.00 |  0.71 |  0.67 |  0.80 |  0.73 |  0.67 |  0.80 |  0.73
upper |  1.00 |  0.75 |  0.86 |  1.00 |  0.75 |  0.86 |  0.00 |  0.00 |  0.00 |  1.00 |  0.75 |  0.86

##  5 Evaluation

###  5.1 Test cases

The following software systems are used to evaluate the performance of the
architecture recovery approach developed in this paper. It includes:

  1. 1.

Test Architecture system: A small-scale test architecture system, as shown in
Figure 3, has been specially designed to test the approach. It is a simulated
architecture test case. It includes 16 classes without the implementation of
any functionalities. It includes only dependencies among classes, as shown in
Figure 3. The classes named as SEC, TX, SERI in the figure represent
crosscutting concerns.

  2. 2.

ConStore: ConStore is a small scale Java-based library designed to manage
concept networks. The concept network is a mechanism used to represent the
meta-model of an application domain consisting of concepts and connections
between them. The ConStore is a framework for detailing out the concepts and
creating a domain model for a given application. It provides services to
store, navigate and retrieve the concept network[13].

  3. 3.

HealthWatcher: The HealthWatcher is a web-based application providing
healthcare-related services[10]. This application provides services to users
to communicate health-related issues. Users can register, update and query
their health-related complaints and problems. The application follows a
client-server, layered architecture style.

All these applications are selected as test cases because the layering of the
program elements was known in advance.

###  5.2 Results and Evaluation

The performance of classification models is typically evaluated against
measures such as accuracy, precision, recall, and F1-Score [9]. These metrics
are derived from a confusion matrix which compares the count of actual class
labels for the observations in a given data set and the class labels as
predicted by a classification model. Four different metrics are derived by
comparing true labels with the predicted labels. These are accuracy, recall,
precision and F1-score. Table 5 shows the performance analysis against these
metrics. The table compares the performance of algorithmic-centric approach
and data-driven approach for all the test cases.

####  5.2.1 Accuracy Analysis

The accuracy is the rate of correction for classification models. Higher the
value of accuracy, better is the model. From the accuracy point of view, one
can observe from the Table 5 that the data-driven approach performs better as
compared to the algorithmic-centric approach. The decision-based classifier
preforms better on all the test cases with an average accuracy of 74%. This is
because the performance of algorithmic approach depends on the proper tuning
of various configuration parameters. The results shown in Table 5 are obtained
with the values of configuration parameters shown in Table 6.

| ConStore | Healthwatcher | Test Arch.
---|---|---|---
$\delta_{il}$ | 4 | 10 | 2
$\delta_{iu}$ | 1 | 1 | 1
$\delta_{ol}$ | 4 | 2 | 2
$\delta_{ou}$ | 1 | 5 | 2
$\delta_{b}$ | 6 | 9 | 6
$\delta_{c}$ | 0.8 | 0.8 | 0.6
$\delta_{e}$ | 0.6 | 0.5 | 0.6
Table 6: Configuration Parameters used during layer recovery

The machine learning models automatically learn and adjust the model
parameters for the better results of accuracy. In case of algorithmic
approach, the configuration parameter tuning is an iterative process and need
to try different combinations.

####  5.2.2 Recall, Precision, F1-Score Analysis

Recall indicates the proportion of correctly identified true positives while
precision is the proportion of correct positive identification. High values of
both recall and precision are desired, but it isn’t easy to get high values
simultaneously for recall and precision. Hence, F1- score combines recall and
precision into one metrics. From the recall, precision, and F1-score point of
view, one can observe from Table 5 that decision tree-based classifier
performs better with the highest F1-score of 0.86 for the upper layer
classification of test architecture system. Recalling class labels with higher
precision for middle layer is a challenging task for all the models described
in this paper. This is because of the presence of many not so cleanly
encapsulated functionalities in a module at the middle layer and mapping
crosscutting concerns to one of the three layers.

##  6 Earlier Approaches and Discussion

Recovering architecture descriptions from the code has been one of the widely
and continuously explored problem by Software Architecture researchers. This
has resulted in a large number of techniques[17], survey papers [8] and books
[14] devoted to the topic. In the context of these earlier approaches, this
section provides the rationale behind the implementation decisions taken while
developing our approach.

###  6.1 Include Dependencies vs Symbolic Dependencies

The recent study reported in [16] has recognized that the quality of recovered
architecture depends on the type of dependencies analyzed to recover
architecture. The study analyzes the impact of symbolic dependencies i.e.
dependencies at the program identifier level versus include dependencies i.e.
at the level of importing files or including packages. Further, it emphasizes
that symbolic dependencies are more accurate way to recover structural
information. The use of include dependencies is error prone owing to the fact
that a programmer may include a package without using it.

We used include dependencies in our approach because extracting and managing
include dependencies are simple as compared to symbolic dependencies. Further,
we mitigated the risk of unused packages by excluding these relationship from
further analysis. Many programming environments facilitate the removal of
unused packages. One of our objectives was to develop a data-driven approach
and cleaning data in this way is an established practice in the field of data
engineering.

###  6.2 Unsupervised Clustering vs Supervised classification

The techniques of unsupervised clustering have been adopted widely to extract
high-level architectures through the analysis of dependencies between
implementation artefacts [17]. These approaches use hierarchical and search-
based methods for clustering. These approaches usually take substantial search
time to find not so good architectures [18]. One of the advantages of
clustering methods is that unlabelled data sets drive these methods. But, the
identified clusters of program elements need to be labelled with appropriate
labels.

Our choice of supervised classification method is driven by the fact that
centrality measures quantify the structural properties with reference to a
node, and relation of the nodes with respect to others. Processing such
quantified values in efficient way is one of the advantages of many of
supervised classification methods. Further, assigning program elements with
layering labels is not an issue if such information is available from the
previous version of software, which is the case for many re-engineering and
modernization projects. In the absence of such labelled data set, the approach
presented in the paper can still be adopted in two stages. In the first stage,
a tentative layer labelling can be done through algorithmic approach followed
by the labelling through supervised classification method.

The architecture descriptions extracted by the approach can be viewed as
multiple ways of decomposing a system rather than a single ground truth
architecture which is often difficult to agree upon and laborious to discover
[8]. One of the architecture out of these extracted architectures can be
selected by assessing these architectures for the properties such as minimal
layer of violation [25, 24] or satisfaction of a particular quality
attribute[14] or any other project specific criteria.

###  6.3 Choice of Number of Layers

We described the working of the approach by assuming a three-layer
decomposition, But this is not a strict restriction. The algorithmic centric
method can be adapted by redesigning rules for additional layers while
supervised classification method can be adjusted by relabelling program
element with a number of layers considered.

##  7 Conclusion

The paper presents an approach to recover high-level architecture from system
implementations. The main highlights of the approach presented in the paper
include: (i) The approach uses the centrality measures from the field of
Social Network Analysis to quantify the structural properties of an
implementation. (ii) The dependency graph formed by including programming
units(i.e. classes in Java) is treated as a network, and centrality measures
are applied to extract structural properties. (iii) The paper treats a layer
as a coarsely granular abstraction encapsulating system functionalities. Then
paper maps a group programming elements sharing common structural properties
manifested through centrality measures to a layer. (iv) Paper describes two
mapping methods for this purpose called algorithmic centric and data-driven.
(v) Overall data-driven methods perform better compared to the algorithmic
centric method to map a program element to a layer.

Paper makes particular assumption such as availability of Java-based system
implementation; a system is decomposed into three layers and availability of
pre-labelled data set for supervised classification. These are the assumption
made to simplify the demonstration of the approach and its realization. Hence,
these assumptions do not make the approach a restrictive one. However, these
assumptions can be relaxed, and the approach is flexible enough to extend.

Exploring the impact of fusing structural properties along with some semantic
features such as a dominant concern addressed by a programming element would
be an exciting exercise for future exploration.

## References

  * [1] Réka Albert and Albert-László Barabási.  Statistical mechanics of complex networks.  Reviews of modern physics, 74(1):47, 2002.
  * [2] Gil Amitai, Arye Shemesh, Einat Sitbon, Maxim Shklar, Dvir Netanely, Ilya Venger, and Shmuel Pietrokovski.  Network analysis of protein structures identifies functional residues.  Journal of Molecular Biology, 344(4):1135 – 1146, 2004.
  * [3] Phillip Bonacich.  Some unique properties of eigenvector centrality.  Social networks, 29(4):555–564, 2007.
  * [4] Stephen P Borgatti.  Centrality and network flow.  Social networks, 27(1):55–71, 2005.
  * [5] Frank Buschmann, Kevlin Henney, and Douglas C Schmidt.  Pattern-oriented software architecture, on patterns and pattern languages, volume 5.  John wiley & sons, 2007.
  * [6] Daniel Escobar, Diana Cárdenas, Rolando Amarillo, Eddie Castro, Kelly Garcés, Carlos Parra, and Rubby Casallas.  Towards the understanding and evolution of monolithic applications as microservices.  In 2016 XLII Latin American Computing Conference (CLEI), pages 1–11. IEEE, 2016.
  * [7] Linton C Freeman.  Centrality in social networks conceptual clarification.  Social networks, 1(3):215–239, 1979.
  * [8] Joshua Garcia, Igor Ivkovic, and Nenad Medvidovic.  A comparative analysis of software architecture recovery techniques.  In 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 486–496. IEEE, 2013.
  * [9] Cyril Goutte and Eric Gaussier.  A probabilistic interpretation of precision, recall and f-score, with implication for evaluation.  In European conference on information retrieval, pages 345–359. Springer, 2005.
  * [10] Phil Greenwood, Thiago Bartolomei, Eduardo Figueiredo, Marcos Dosea, Alessandro Garcia, Nelio Cacho, Cláudio Sant’Anna, Sergio Soares, Paulo Borba, Uirá Kulesza, et al.  On the impact of aspectual decompositions on design stability: An empirical study.  In European Conference on Object-Oriented Programming, pages 176–200. Springer, 2007.
  * [11] Jiangang Hao and Tin Kam Ho.  Machine learning made easy: A review of scikit-learn package in python programming language.  Journal of Educational and Behavioral Statistics, 44(3):348–361, 2019.
  * [12] Ch Anwar Ul Hassan, Muhammad Sufyan Khan, and Munam Ali Shah.  Comparison of machine learning algorithms in data classification.  In 2018 24th International Conference on Automation and Computing (ICAC), pages 1–6. IEEE, 2018.
  * [13] http://www.cse.iitb.ac.in/constore.  http://www.cse.iitb.ac.in/constore, 2009.
  * [14] Ayaz Isazadeh, Habib Izadkhah, and Islam Elgedawy.  Source code modularization: theory and techniques.  Springer, 2017.
  * [15] Daniel Link, Pooyan Behnamghader, Ramin Moazeni, and Barry Boehm.  The value of software architecture recovery for maintenance.  In Proceedings of the 12th Innovations on Software Engineering Conference (formerly known as India Software Engineering Conference), pages 1–10, 2019.
  * [16] Thibaud Lutellier, Devin Chollak, Joshua Garcia, Lin Tan, Derek Rayside, Nenad Medvidović, and Robert Kroeger.  Measuring the impact of code dependencies on software architecture recovery techniques.  IEEE Transactions on Software Engineering, 44(2):159–181, 2017\.
  * [17] Onaiza Maqbool and Haroon Babri.  Hierarchical clustering for software architecture recovery.  IEEE Transactions on Software Engineering, 33(11):759–780, 2007\.
  * [18] Sina Mohammadi and Habib Izadkhah.  A new algorithm for software clustering considering the knowledge of dependency between artifacts in the source code.  Information and Software Technology, 105:252–256, 2019.
  * [19] M. E. J. Newman.  Random graphs as models of networks.  arXiv preprint cond-mat/0202208, 2002.
  * [20] Mark EJ Newman.  The structure and function of complex networks.  SIAM review, 45(2):167–256, 2003.
  * [21] Mark EJ Newman, Steven H Strogatz, and Duncan J Watts.  Random graphs with arbitrary degree distributions and their applications.  Physical review E, 64(2):026118, 2001.
  * [22] Alexia Pacheco, Gabriela Marín-Raventós, and Gustavo López.  Designing a technical debt visualization tool to improve stakeholder communication in the decision-making process: a case study.  In International Conference on Research and Practical Issues of Enterprise Information Systems, pages 15–26. Springer, 2018.
  * [23] Zizi Papacharissi.  The virtual geographies of social networks: a comparative analysis of facebook, linkedin and asmallworld.  New media & society, 11(1-2):199–220, 2009.
  * [24] Santonu Sarkar and Vikrant Kaulgud.  Architecture reconstruction from code for business applications-a practical approach.  In 1st India Workshop on Reverse Engineering,(IWRE), 2010.
  * [25] Santonu Sarkar, Girish Maskeri, and Shubha Ramachandran.  Discovery of architectural layers and measurement of layering violations in source code.  Journal of Systems and Software, 82(11):1891–1905, 2009.
  * [26] Arman Shahbazian, Youn Kyu Lee, Duc Le, Yuriy Brun, and Nenad Medvidovic.  Recovering architectural design decisions.  In 2018 IEEE International Conference on Software Architecture (ICSA), pages 95–9509. IEEE, 2018.
  * [27] Juliana Saragiotto Silva and Antonio Mauro Saraiva.  A methodology for applying social network analysis metrics to biological interaction networks.  In Advances in Social Networks Analysis and Mining (ASONAM), 2015 IEEE/ACM International Conference on, pages 1300–1307. IEEE, 2015.
  * [28] Rishi Ranjan Singh.  Centrality measures: A tool to identify key actors in social networks.  arXiv preprint arXiv:2011.01627, 2020.
  * [29] Colin C Venters, Rafael Capilla, Stefanie Betz, Birgit Penzenstadler, Tom Crick, Steve Crouch, Elisa Yumi Nakagawa, Christoph Becker, and Carlos Carrillo.  Software sustainability: Research and practice from a software architecture viewpoint.  Journal of Systems and Software, 138:174–188, 2018.
  * [30] Duncan J Watts.  Networks, dynamics, and the small-world phenomenon 1.  American Journal of sociology, 105(2):493–527, 1999.
  * [31] Tina Wey, Daniel T Blumstein, Weiwei Shen, and Ferenc Jordán.  Social network analysis of animal behaviour: a promising tool for the study of sociality.  Animal behaviour, 75(2):333–344, 2008.
  * [32] Douglas R White and Stephen P Borgatti.  Betweenness centrality measures for directed graphs.  Social Networks, 16(4):335–346, 1994.