Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551

Contents lists available at ScienceDirect

Journal of King Saud University –

Computer and Information Sciences
journal homepage: www.sciencedirect.com

Metrics for reusability of java language components

Amit Rathee ⇑, Jitender K. Chhabra
Department of Computer Engineering, National Institute of Technology, Kurukshetra 136119, Haryana, India

a r t i c l e i n f o a b s t r a c t

Article history: Software reuse is a promising opportunity for a software development process that helps in achieving an
Received 6 November 2021 improved quality of the developed software system. Improved quality also promotes software architec-
Revised 11 April 2022 ture reuse opportunities. From the past few decades, software reuse is actively gaining popularity in the
Accepted 13 May 2022
form of Component Based Software Development (CBSD). The components being the basic unit in CBSD,
Available online 24 May 2022
accessing their reusability is a useful and open area of investigation. The extent of the reusability can be
quantified based on the extent of intra and inter-connectivity of the attributes/ characteristics of the
Keywords:
component. This can be computed by defining suitable metrics to measure the reusability of a compo-
JavaBeans
CBSD
nent. Although, there exist some metric suites such as CK, MOOD, Halstead, McCabe’s metric, etc. for
Component’s Reusability measuring the reusability of the object-oriented software systems, but they are not directly reusable
Metric Suite in the CBSD environment. This is due to the fact that these metrics are applicable only at the class level
and they do not target the interfaces of the component that are important and define the composability of
the component in the CBSD environment. Therefore, this paper aims to study the reusability, flexibility,
composability, and adaptability aspects of the software component. Further, based on the study con-
ducted, we propose a reusability metric suite specially designed for the JavaBeans. This metric helps to
measure the architecture level reusability of the JavaBeans. The JavaBeans component standard is spe-
cially targeted in this paper because components based on this standard are not fully explored and only
a few metric suites exist for measuring the reusability of the JavaBeans. The proposed component
reusability metric suite is validated both experimentally as well as against Briand’s framework.
Ó 2022 The Author(s). Published by Elsevier B.V. on behalf of King Saud University. This is an open access
article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

1. Introduction cept of reusable components in an international conference held at

Software reuse is a key technique that helps in developing large
and complex software systems rapidly and in a cost-effective man-
ner. Software reuse can help implement architecture-level
reusability. The importance of software reuse can be easily under-
stood from the fact that the U.S Department of Defense alone can
annually save a sum of $300 million by only enhancing the soft-
ware reuse by a factor of 1% (Anthes, 1993). Reusability has been
an active part of software development for the past several decades
and it has its roots back in 1969 when Mcllroy introduced the con-
Garmisch, Germany (McIllroy, 1968). Based on the study con-
ducted by Frakes and Succi aiming at determining the relationship
between the extent of reuse, software quality, and productivity
gain, it is concluded that promoting reuse always results in
improved underlying software system quality (Frakes and Succi,
2001). With the gain in the popularity of FOSS (Free and Open
Source Software), software components are managed in the form
of packages (Cosmo et al., 2009).
1.1. Reusability in Software Development

⇑ Corresponding author. Reusability in software development can be targeted in many

E-mail addresses: amit1983_rathee@rediffmail.com (A. Rathee), jitenderchhab- forms, namely design patterns, architectural patterns, software
ra@gmail.com (J.K. Chhabra). libraries, frameworks, algorithms, test cases, components, artifacts,
In this work we propose a new reusability metric suite for measuring reusability of procedures, requirement specifications, skills, and/ or ideas. One
Java language components.
approach that highly promotes the architectural level reuse is
called Component Based Software Development (CBSD). The CBSD
approach focuses on developing software by integrating indepen-
dent reusable units called components. The important part of a
Production and hosting by Elsevier
component is its interface and it plays a significant role in

https://doi.org/10.1016/j.jksuci.2022.05.010
1319-1578/Ó 2022 The Author(s). Published by Elsevier B.V. on behalf of King Saud University.
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).
A. Rathee and J.K. Chhabra
determining the reusability of a component. An interface of a com-
ponent gives details of the services it offers to the outside world by
defining a collection of operations. The interfaces of a component
play an important role and help in integrating different compo-
nents together to have fully functional software in the CBSD
environment.
To utilize the benefits of reusability, it is important to measure
the reusability factor of a component, and hence it’s underlying
architecture so that its suitability/ usefulness in software develop-
ment can be determined. This requirement arises because there
may exist more than one component that provides the functional-
ity needed by the software developer in the CBSD environment. In
such a situation, the developer needs to compare and choose the
single best component out of the pool of similar components. This
requires that there must be some metrics, which are capable of
quantifying the component characteristics and thus help in evalu-
ating, comparing, and finally choosing the best component. Such
metrics can help developers in identifying probable risks associ-
ated with the CBSD environment and hence help in improving var-
ious underlying software qualities such as reliability,
maintainability, etc.
1.2. Object-Oriented Software Reusability Metrics and Their
Limitations
In the industry as well as the research community, several well-
established software metrics and models are already proposed in
the literature for object-oriented software systems and they have
been successfully used in combination for measuring reusability
and/ or quality aspect of Object-Oriented (OO) software Systems
(Onyango et al., 2020; Padhy et al., 2018). These well-established
software metrics and models include Chidamber and Kemerer met-
rics suite, McCabe’s Cyclomatic Complexity metric, Halstead LOC
metric, and MOOD metric suite (Aggarwal et al., 2006; Harrison
et al., 1998; Chidamber and Kemerer, 1994; Ampatzoglou et al.,
2018). However, these metrics cannot be directly applied to a com-
ponent in the CBSD environment because of several reasons such
as:
1. Many metrics like McCabe and MOOD metric suites require
access to the internals of the code. However, sometimes
such access is restricted in the case of a black-box compo-
nent. Thus, inhibiting the use of many standard OO
metrics.
2. A component is generally a collection of two or more software
elements (class/ interface) and OO metrics are generally defined
and used in the context of individual software elements. Thus,
OO metrics constitute scalability issues in CBSD.
3. Most of the existing OO reusability metrics have a single speci-
fic aim and are focused on measuring certain complexity
aspects of software by generally utilizing its structural features.
However, there are other important software assets such as
documentation, semantic characteristics, and other external
quality parameters that may be utilized to enhance the
reusability measuring accuracy of a component. Hence, there
is a scope for improving existing metric suites.
4. Various key component-specific features/ characteristics such
as the presence of the interfaces, the complexity of the inter-
faces, completeness, and customizability remain undetectable
by Conventional OO metrics.
5. The overall architecture of a component is different from the
normal class. Thus, conventional OO metrics cannot optimally
determine accurate inter and intra component relations.
6. Conventional size metrics such as the Halstead LOC metric can-
not measure the reusability of a component. This is because a
lengthy component with fewer dependencies is considered to
5534
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
be more reusable as compared to its equivalent small-sized
component with higher dependencies.
7. McCabe’s Cyclomatic Complexity metric also cannot be applied
to measure the underlying complexity of a component in every
case. For instance, for black-box components, only interfaces
are visible for use. Therefore, a quantitative measure based on
the presence of a total number of linearly independent paths
becomes useless.
Alongside the above-mentioned software reusability/quality
metrics, there is another metric known as Turbo Modularization
Quality (TurboMQ) proposed by Mitchell and Mancoridis (2008).
This metric is a quality evaluation metric used to evaluate different
recovered architectures of software. It is a ground-truth
architecture-independent approach that promotes cohesive clus-
tering and penalizes excessive inter-cluster coupling. Based on this
characteristic of the TurboMQ metric, it has also been applied to
measure the quality of software components (Rathee and
Chhabra, 2019). However, here, it is necessary to determine how
this metric is useful in determining the overall reusability score
of JavaBeans.
The rest of this paper is organized as follows: Section 2 provides
a formal definition of a software component, explains the need for
computing reusability at the component level, and further provides
details about contributions and adopted methodology of the paper.
Section 3 provides necessary details about substantial work carried
out in the direction of reusability and metrics available at the com-
ponent level. Section 4 briefly discusses about various key termi-
nologies used during the computation of different metrics in the
proposed reusability metric suite. In Section 5, different metrics
belonging to the metric suite are elaborated in detail along with
details about a case study. This section is followed by Section 6
which provides details about the theoretical validation of the pro-
posed metric suite. Section 7 provides details about experimental
steps and formulated different research questions. Section 8 gives
necessary details about obtained results in this paper and their cor-
responding interpretations in context to formulated research ques-
tions. Finally, Section 10 completes the paper by specifying
necessary conclusions and possible future work details.
2. Reusability At Component Level: A Formal Representation
As discussed in subsection 1.1 of this paper, the reusability in
software engineering can be implemented in many different forms.
This creates the problem of a lack of a widespread, systematic
reuse approach in software engineering. Thus, it is not wrong to
claim that the current research community does not possess a
common consensus on what exactly is the reusable form of a soft-
ware component. In the software engineering world, the word
”component” (aka reusable unit) possesses different synonyms
including design pattern, architectural pattern, framework, and/
or underlying existing source code in the form of a method, class,
module, package, and library. Therefore, first, it is mandatory to
formally answer different questions in this paper before actually
explaining the proposed metric suite: How a software component
is defined? What are different component properties that help in
promoting reusability and adaptability?.
2.1. Need for Component’s Reusability Metrics
The author in Sametinger (1997) defines a component as an
identifiable, self-contained, and reusable part of a software system
that further describes a specific- functionality. It can be easily inte-
grated with other components in the system through its unique
interfaces (that encapsulate internals) in order to provide broader
functionality. These components must follow composition
A. Rathee and J.K. Chhabra
standards as laid out by underlying component models in order to
be directly reusable in the CBSD environment (Lau and Wang,
2007). Different component model standards specified in the liter-
ature include.NET component model, JavaBeans component model,
Common Object Request Broker Architecture (CORBA) component
model, X-MAN component model, Enterprise JavaBeans (EJB) com-
ponent model, and Component Object Model (COM) (Niekamp,
2005; Crnkovic et al., 2010). The suitability of the JavaBeans com-
ponent model is widely considered fruitful in different domains in
(Feljan et al., 2009; Lau and Di Cola, 2017; Furht, 2019). The
authors in Feljan et al. (2009) utilized the JavaBeans component
model for proposing a new domain-specific component model
called SaveCCM for real-time vehicular embedded systems. More-
over, the authors in Rathee and Chhabra (2019) proposed a model-
ing approach for identifying JavaBeans components by mining
object-oriented reusable software components from the underly-
ing software system. Therefore, due to the wider popularity of
the Java programming language and its close resemblance with
the JavaBeans component model standard (Jendrock et al., xxxx),
this paper focuses on software components designed and available
in the CBSD environment as per specifications of the JavaBeans
component model.
To the best of the author’s knowledge, the existing component
reusability measurement metrics provide very trivial information
and missed out on important parameters such as the complexity
of a component as in (Washizaki et al., 2004). Further, many of
these metrics are general in nature and do not target any specific
component model such as COM, JavaBeans, CORBA, etc. Moreover,
a JavaBeans is one of the most important and usable component
models for the Java language (Englander, 1997). Based on the man-
ual investigation and to the best of the author’s knowledge, there is
only a single metric suite by (Washizaki et al., 2004) that is espe-
cially proposed to measure the reusability of different JavaBeans
(components). However, this metric suite is having the following
shortcomings:-.
1. This metric suite is especially proposed for only black-box com-
ponents. Hence, it fails or is not that much effective for the
white/glass-box components.
2. This metric suite does not target measuring the complexity of
the JavaBeans interface. A complex component is hard to under-
stand and thus its applicability in the CBSD environment is
restricted (Gosain and Sharma, 2017; Anguswamy and Frakes,
2012). Thus measuring the complexity of the JavaBeans compo-
nent’s interface is necessary.
3. The authors in Washizaki et al. (2004) stress the fact that a com-
ponent having a higher number of business methods without
parameters or return value is considered self-completed. This
restriction in our opinion is not a good choice.
4. The computation of metrics is trivial and considers only the
presence or absence of the features present in the JavaBeans.
2.2. Overview of Contribution and Methodology
Based on the growing trends for CBSD in IT industries, the
growth of JavaBeans, and the lack of suitable JavaBeans reusability
estimation metric suite, this paper considers studying and measur-
ing JavaBeans reusability by proposing a new metric suite. The pro-
posed metric suite captures many characteristics such as cohesion,
complexity, completeness, coupling, customizability of the soft-
ware that is useful to comprehend the architecture, at the macro/
micro level, of the software under consideration. The proposed
metric suite measures different quality dimensions of the Java-
Beans and finally computes its reusability score. This reusability
score reflects the reuse quality of the component and can help in
choosing the best component from a pool of components that are
5535
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
designed for specific functionality. The key contributions of this
paper are summarized below:
1. Proposed a metric suite for measuring the reusability score of a
component that follows the specifications of the JavaBeans
Component Model.
2. Proposed multiple criteria, namely cohesion, complexity, com-
pleteness, coupling, and customizability that are not earlier
handled to measure reusability at the component level. To the
best of the author’s knowledge, the measurement criteria used
for these metrics are unique and depend on the key character-
istics of the JavaBeans.
The methodology adopted by authors in this paper includes
extracting different key characteristics of the JavaBeans, comput-
ing different metrics belonging to the metric suite, and performing
both theoretical and empirical validation of the proposed metric
suite. The key information extracted from the JavaBeans includes
association, inheritance, method calls, parameters, return type,
attribute usage, indirect usage, co-change, and semantic attributes
by utilizing a semi-automated tool designed by the authors. The
theoretical validation of the proposed metric suite is performed
against different properties of the Briand’s framework. The exper-
imental validation of the proposed reusability metric suite is done
by studying different software systems. The studied software sys-
tems are divided into three categories. The first category includes
ready-to-use components designed as per the specification of the
JavaBeans component model. The second category includes state-
of-art object-oriented software systems that are designed and
managed with the idea of reusability criteria promotion. Finally,
the third category includes normal object-oriented software
systems.
3. Literature Survey
During the last few decades, significant work is done in the
direction of software reuse while developing a new software sys-
tem. CBSD is one of the widely adopted approaches that promote
software reuse in the form of components. Components provide
functional reusability. Szyperski et al. provide a definition of a soft-
ware component that is widely been adopted among the research
community (Szyperski et al., 2002). They stress the fact that the
interfaces are the fundamental building blocks and each compo-
nent may have properties, methods, events, and relationships
among the interfaces of the different components. A search-
based multi-objective approach is proposed for identifying reusa-
ble software components from the existing source-code of an
object-oriented software system in Rathee and Chhabra (2019).
Shatnawi et al. give an approach for converting object-oriented
APIs into the corresponding component-based APIs (Shatnawi
et al., 2018). The authors conclude that component-based APIs
are more manageable as compared to their corresponding counter-
parts. The authors in Rathee and Chhabra (2019) conclude that
there is plenty of research opportunity for reusable components
in multimedia software and propose an approach for identifying
reusable multimedia components from legacy multimedia soft-
ware systems. The authors in Thapar and Sarangal (2020) proposed
a multi-criteria-based hybrid fuzzy metric approach for quantify-
ing the reusability of a software component based on its underly-
ing quantity. Papamichail et al. proposed a software reusability
evaluation approach based on trivial static analysis metrics
(Papamichail et al., 2019). The authors reduced subjectivity by
building a benchmark dataset and extracted the developers’ based
reuse rate at class and package level from it using the AGORA
search engine. This reuse rate is used as the actual ground truth
and is extracted from the structural properties of the source code.
A. Rathee and J.K. Chhabra
Structural properties of the code, as well as software architecture
such as coupling, cohesion, and complexity (CCC) have been uti-
lized for automatically identifying vulnerability in software by
proposing a framework (Chowdhury and Zulkernine, 2011). Many
of these architectural properties have also been computed at a
dynamic level in the form of different dynamic cohesion metrics
that help in observing the behavioral aspects of the software sys-
tem (Gupta and Chhabra, 2011). The whole purpose of computing
all such metrics is to promote reusability and a component-based
development approach (CBSD). CBSD has also been supported by
using the concept of Access Control Configurations (ACCs) in Sun
and Huang (2011), in which authors proposed various algorithms
and metrics that can efficiently evaluate and configure software
architecture with different ACCs. Through the above-mentioned
metrics and algorithms, many independent and optimized
classes/components are extracted and represented in the form of
APIs with suitable interfaces. The concept of APIs was used by
Cimino et al. by utilizing client-side APIs and user interfaces to
develop a device-independent mobile application Cimino and
Marcelloni (2012). The proposed approach first models the mobile
application platform-independent, and finally, the transformation
model is used to convert it to a specific platform application. Many
of the metrics and approaches of reusability usually contain some
redundancy and some researchers have reduced such redundan-
cies by using deep learning-based convolutional neural network
in the domain of ubiquitous networks (Song et al., 2019). The
authors in Papamichail et al. (2019) contributed a large-scale data-
set to the research community that contains the reusability aspect
of software components i.e. the degree to which a particular soft-
ware component is reusable. The extent to which a particular com-
ponent is reusable is based upon its actual reuse rate mined using
the AGORA code search engine and six source code properties,
namely documentation, cohesion, size, complexity, coupling, and
inheritance. An automated Reusable Service Identification (ReSIde)
approach is proposed for identifying reusable services by analyzing
variability and commonality from multiple object-oriented soft-
ware product variants (Shatnawi et al., 2020). The authors in
Mohammed et al. (2021) proposed a new approach to retrieve reu-
sable software components from repositories using NLP-based
Information Retrieval (IR) techniques. A multi-period multi-
objective model is proposed in Mehlawat et al. (2020) to optimize
involved maintenance cost and fitness evaluation of software com-
ponents in a multi-phase deliverable system. A generic methodol-
ogy is proposed in Papamichail and Symeonidis (2020) to identify
non-maintainable software components in the early stages of soft-
ware evolution using a one-class-classification approach based on
complexity, coupling, inheritance, and cohesion characteristics of
source code. An Artificial Neural Network (ANN) based component
reusability assessment approach is proposed in Sharma et al.
(2009). The reusability assessment approach is based on four key
factors, namely, portability, customizability, understandability,
and interface complexity.
Besides these, a few metrics are also proposed for estimating
the reusability of the object-oriented software and components.
C&K metric is the widely used suite that consists of six metrics.
Out of these the Weighted Methods per Class (WMC), Depth of
Inheritance Tree (DIT), Lack of Cohesion in Methods (LCOM), and
Coupling Between Object Classes (CBO) are commonly used
reusability metrics that are mainly applied at the class level
(Chidamber and Kemerer, 1994). Cho et al. propose metrics for
measuring different component characteristics, namely customiz-
ability, complexity, and reusability (Cho et al., 2001). The authors
in Boxall and Araban (2004) propose metrics for measuring the
understandability and reusability of interfaces of component that
is designed using the.NET & COM component model. Sharma
et al. studied the interface complexity of the JavaBeans component
5536
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
by conducting a small experiment and proposing a metric for the
same (Sharma et al., 2008). Bertoa et al. propose a set of usability
metric suite for a software component that measures five charac-
teristics, namely operability, compliance, understandability,
attractiveness, and learnability (Bertoa et al., 2006). Mijac et al. car-
ried out a systematic survey about reusability metrics proposed by
different researchers along with important information such as the
most cited papers, different factors that affects the reusability of a
software component, the number of factors used to measure
reusability (Mijač and Stapić, 2015).
Besides some OO reusability metrics discussed in subsection -
1.2, several metrics and frameworks have been already proposed
that help measure the reusability of a component (Koteska and
Velinov, 2012; Gui and Scott, 2009; Bi et al., 2009; Boxall and
Araban, 2004; Washizaki et al., 2004). The authors in Gui and
Scott (2009) proposed and utilized a new set of weighted static
coupling and cohesion metrics for evaluating the reusability aspect
of the Java components retrieved from the internet using a compo-
nent search engine. Three factors, namely the degree of resem-
blance among different entities, indirect coupling, and functional
complexity of classes and methods, differentiate proposed static
metrics from others. Authors in Washizaki et al. (2004) proposed
a metric suite for measuring the reusability of a black-box software
component based on features such as understandability, portabil-
ity, and adaptability factors of a component. A unified model for
measuring the reusability of a component is proposed in Koteska
and Velinov (2012) that can be easily adapted to accommodate dif-
ferent reusability requirements. Based on the critical survey, new
attribute addition is suggested to efficiently compute component
reusability. Bi et al. (2009) built a quantitative measurement model
based on the relationship between the reusability of a component
and its underlying complexity measure. Boxall et al. proposed a set
of metrics that are considered relevant to measure the understand-
ability and reusability of a black-box software component (Boxall
and Araban, 2004). Out of these metrics, Washizaki et al. (2004)
and Boxall and Araban (2004) are only applicable to black-box
components for which source code is not easily available.
Based on the literature survey, we conclude that some of the
already proposed metrics are very basic in nature and do not con-
sider the complexity of the underlying component. Especially, the
more closer metric suite is given by Washizaki et al. (2004) and it
consists of five metrics that measure the reusability of JavaBeans
based on the limited information available, namely EMI (Existence
of Meta-Information), RCO (Rate of Component Observability), RCC
(Rate of Component Customizability), SCCr (Self-Completeness of
Component’s Return Value), and SCCp (Self-Completeness of Com-
ponent’s Parameters). Out of these metrics, the EMI metric is very
trivial (gives binary output). The RCO metric measures only the
readable properties and does not measure anything about the pro-
vides and requires interface of the underlying component. The RCC
metric measures customizations as the number of writable proper-
ties/ fields and do not consider the importance of the internal of
the JavaBeans due to its black-box nature. Finally, the interface
complexity computation is very trivial (using SCCr and SCCp met-
ric) and is based on determining methods that do not return any
value and methods without any parameters. Moreover, the authors
in Washizaki et al. (2004) consider JavaBeans as a black-box. Con-
sidering internals can give much important information that can
help in measuring the reusability of JavaBeans with more accuracy.
The fuzzy-based approach by Thapar and Sarangal (2020) is also
not feasible because the fuzzy decision is based on stakeholders’
opinions and several other factors like security, recoverability,
administration efforts, testability, etc. Several of these attributes
are not always present. Most of the proposed metrics lack detailed
empirical analysis in order to validate the proposed metrics. Very
few metrics targets estimating the reusability of the components
A. Rathee and J.K. Chhabra
designed using a JavaBeans component model. Moreover, the met-
ric suite that is designed for the black-box components cannot be
directly applied to white-box/ glass-box components whose source
code is accessible. Some of the proposed approaches only consider
cohesion and coupling factors while determining the overall
reusability of the component. Finally, some of the proposed met-
rics are subjective in nature and are very difficult to measure on
a real-time application. Therefore, we propose a new suite of met-
rics that measures the reusability of the components with a fresh
idea to measure different dimensions of the underlying compo-
nent. These dimensions include cohesion, coupling, customizabil-
ity, self-completeness, and corresponding interface complexity.
Finally, based on these measured dimensions, the final reusability
score is computed.
4. Background and Used Terminologies
Before presenting different metrics for measuring the reusabil-
ity of the JavaBeans, it is mandatory to present various terminolo-
gies and naming conventions used for getting a precise definition
of a software component in an object-oriented software environ-
ment. It helps a user in understanding the idea and the concept
presented in this paper. The various terms and mathematical rep-
resentations that are formulated in this paper are as follows:
4.1. Software Component
A software component is basically defined as a piece of software
(a modular unit) that provides a unified predefined service via its
interface (Provides and Requires interfaces) and it is able to com-
municate with other components (Rathee and Chhabra, 2019). It
encapsulates its contents and can be easily replaced with another
similar component. It provides plug-and-play functionality in soft-
ware design and it supports software reuse. Moreover, it helps in
decomposing the software into manageable parts, resulting in
reduced complexity. Thus, a software component promotes
architecture-level reuse.
In OO software engineering, the term class and package are the
key composing elements that help implement modular program-
ming in the Java programming language. However, there is a sig-
nificant difference between a class, package, and component. A
class in object-oriented terminology is an implementation-time
unit used by programmers. It represents an entity and it generally
performs a micro functionality (a specific small task) in an appli-
cation. A component in the object-oriented terminology is the
design-time unit used by system designers and is larger in gran-
ularity than classes. A component is generally represented as an
aggregation of classes that together perform a macro functionality
(larger functionality that is closer to the business description such
as ”Shopping Cart” and ”Inventory”). Interfaces of a component
hide its underlying contents from the outside world. A package
in Java is a namespace to organize classes, sub-packages in order
to handle naming conflicts and to provide controlled access. The
key differences between classes, components, and packages are
summarized below along with highlighting the importance of
components:
1. A class is generally a less reusable unit as compared to its com-
ponent counterpart. This is because a class generally has more
dependencies with other classes, whereas a component pos-
sesses lesser outside dependencies. Hence, a component is a
more reusable unit.
2. The primary reuse relationship for classes is an inheritance,
whereas for the components the reuse relationship is aggrega-
tion/ composition.
5537
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
3. A component is having a more clear distinction between inter-
face and implementation concerns as opposed to its class
counterpart.
4. The package also contains a set of classes and sub-packages,
however, it is not always mandatory that such grouped classes
are related to each other. Hence, it cannot be considered as a
reusable component in the CBSD environment.
A software component can be created from scratch or it can be
extracted from existing software as independent clusters. In the
component-based software architecture, a component may contain
other components (cluster within another cluster) leading to the
hierarchical organization of the software architecture. Mathemati-
th
cally, a component at i level in the software architecture is basi-
cally represented as a pair C i ¼< Ei ; Ri >, where Ei is a set of
th
elements (contents of the component) belonging to the i compo-
nent. The contents of a component are a set of classes (and/ or
interfaces for Java/ C#). The Ri represents the set of relations that
the component at i
th
level possesses. Since a component at the i
th
th
level may require the services of the components at the ði þ 1Þ
level and it may provide services to the components at the
th
ði  1Þ level. Therefore, the set Ri is defined as
i i iþ1 i1
R # E  ðE [E Þ.This set is a binary relation set and it repre-
th
sents the directed connection of the contents of the i level compo-
th th
nent with any one of the contents present at ði  1Þ or ði þ 1Þ
level components.
4.2. Software Component’s Interface
Interfaces are the crucial part of a component in a component-
based software architecture of a system. These interfaces represent
the architectural interaction among different components in a
component-based software system. In a very common way, these
interfaces are specified in terms of a set of operations (methods/
functions) and they are generally classified as provides interface
(set of operations a typical component provides to its environ-
ment) and requires interface (set of operations a typical compo-
nent needs from its environment) (Crnkovic et al., 2010). As part
of source code, interfaces of a software component can be specified
using one of two approaches. One method of describing interfaces
is the language-independent approach in which various Interface
Description Languages (IDLs) are used. A survey of various IDLs is
available in Guerrero-Garcia et al. (2009). Another way to describe
interfaces of a component is the language-dependent approach in
which particular programming language styles are used to denote
a set of methods and attributes. In literature, several techniques
exist to identify a set of methods and attributes that constitute
interfaces of a component (Liu et al., 2018; Shatnawi et al., 2018;
Rathee and Chhabra, 2019; Rathee and Chhabra, 2019). Here, it is
important to note that a list of methods and attributes that consti-
tutes interfaces of a component may be different as different
approaches in literature use different mechanisms. Therefore, this
paper considers a formal definition of interfaces in order to define
metrics in an abstract way. In a formal way, interfaces of a compo-
th
nent at the i level in the software architecture are basically repre-
sented as a pair InterfacesðC i Þ ¼< Prov ides ; Requires >. Here,
i j
Prov ides is a set of methods and attributes that belongs to the i
i th
component and represents the set of features that are offered by
j
the component to its outside environment. Similarly, Requires is
a set of methods and attributes that actually belongs to some other
th
component say j (another component in the CBSD environment)
th
and represents the dependency of the i component on its outside
environment.
A. Rathee and J.K. Chhabra
4.3. Software Sub-component
A component C i identified from the existing source code of an
OO legacy software system is generally considered to possess a flat
organization of its contents, i.e. there is no specific organization
among its different contents identified from the existing software
system (Mishra et al., 2009; Shatnawi et al., 2018; Rathee and
Chhabra, 2019). Rather, all its contents are generally supposed to
be present at the same level because of the fact that such compo-
nents are identified by clustering different individual software ele-
ments together. This is unlike packages where the contents of a
package may have a hierarchical organization of its contents, i.e.
a package may contain sub-packages with no limit on the depth
of the sub-package. This means a sub-package may contain another
sub-package in the case of the definition of a package. Since a com-
ponent is considered to have a flat organization of its content
rather than to have a hierarchical arrangement of its contents (as
the case may be with packages). Therefore, this paper considers
it worth describing the concept of sub-component (a dynamic
group of contents of a component collectively identified as a single
entity) which is important for measuring the reusability of a com-
ponent in the CBSD environment. The concept of sub-component is
important and helps in providing logical organization of different
components. This logical structure helps us to easily understand
a component and to compute various metrics proposed in this
paper. In this paper, a sub-component at any stage is considered
as the group of contents of a component except for any one of
the contents currently considered for computing a particular met-
ric value. For example, say a component has total t contents
belonging to it, then, dynamic collection of (t-1) contents except
for the one for which the metric is to be computed, is commonly
termed as sub-component. Mathematically, a sub-component is
represented as:
C iSC ¼ ðEiSC ; RiSC Þ; s:t:
RiSC  Ri ; EiSC  Ei ; & jEiSC j ¼ jEi j  1
The concept of the sub-component is used to determine various
quality parameters, namely cohesion, coupling, etc. of the
component.
4.4. Disjoint Components
The components extracted from the software system are non-
overlapping in nature, such that for any two components C i and
C j at different hierarchical levels, there is Ei \ Ej ¼ U. Thus, any
two different components do not contain common contents and
they are always disjoint in nature.
4.5. Empty Component
A component that contains no contents in it and hence there are
no relations among the contents of a component is termed as the
empty component. Mathematically, it is represented as the pair
< U; U >.
4.6. Definition of Relations
The term relation in this paper denotes the dependencies
between different content of a component and the dependency
of a component on other components. These dependency relations
can be of different types, namely inheritance, reference, semantic,
aggregation, etc. Mahouachi, 2018; Chhabra et al., 2017. Table 1
specifies different kinds of relations considered in order to evaluate
the quality of a component.
5538
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
Mathematically, any relation of type i (as mentioned in Table 1)
among a pair of two elements say e1 and e2 is represented as
ri ðe1 ; e2 Þ. The presence of any such relation is denoted as
ri ðe1 ; e2 Þ ¼ 1 and it denotes the dependency of e1 on e2 . It is repre-
sented as ei1 ! ei2 . Furthermore, these relations are asymmetric in
nature, meaning that any relation existing as ei1 ! ei2 does not
automatically imply that ei2 ! ei1 . All these relations exist between
classes, interfaces, subpackages belonging to different components.
For the sake of computation, all these relations are categorized into
the following categories:
4.6.1. Class- Subpackage relations
These relations exist among the contents of a given component
and are referred to as the Intra relations of a component. These
relations are used to compute the cohesion quality parameter
(aka relatedness among different contents) of a component. It
denotes the correlation of a specific class/ interface with the rest
of the contents of the same component. These relations help us
to measure the functional relatedness among the contents of a
component and hence is a direct indicator of the quality of the
component. Mathematically, for a component C i ¼< Ei ; Ri >, a
class-subpackage relation is represented as r t ðei ; Sj Þ where Sj repre-
sents the subpackage of C i and Sj  Ei and ei R Sj . Any class-
subpackage relation of type t exists in a component denoted as
rt ðei ; Sj Þ ¼ 1 such that there exists at least one element say ej 2 Sj
such that rt ðei ; ej Þ ¼ 1 for some relation of type t. In other words,
we can say that a class-subpackage relation exists if and only if
there is a relation of any type that exists between a given class
of a component and any of the classes belonging to the subpackage
of the same component. Here, it is important to note that all kinds
of relations as mentioned in Table 1 can belong to the class-
subpackage category until they are confined to the component,
i.e. the software elements (contents) that are involved with the
dependency relation belong to the same component only.
4.6.2. Component- Component relations
Such relations exist among software components due to inter-
action/ dependency among contents belonging to different compo-
nents. These relations are also termed as Inter component
relations. These relations are used to compute the coupling quality
parameter (aka functional dependency among components) of a
component. From a reusability point of view, a component that
possesses no/ fewer interdependencies is considered best. Mathe-
matically, for any two components C i ¼< Ei ; Ri > and
j j j
C ¼< E ; R >, a component-component relation is represented as
rt ðei ; ej Þ where ei and ej are two distinct software elements (classes/
th th
interfaces) belonging to the i and j component respectively i.e.
i j
ei 2 E and ej 2 E . The value of component- component relation
between any two component C i and C j exist i.e. r t ðei ; ej Þ ¼ 1 if
and only if there exists a relation of type t between two compo-
nents and r t ðei ; ej Þ ¼ 1. In other words, we can say that a
component-component relation exists if and only if there is a rela-
tion of some type between any two classes belonging to a different
component. Here, all types of relations as mentioned in Table 1 can
belong to a component-component category as long as the
involved elements in the relation namely ei and ej belongs to a dif-
ferent component, i.e. the software elements (contents) that are
involved with the dependency relation belongs to the same
component only.
Fig. 1 diagrammatically shows these two kinds of relations
existing at class, subpackage, and component level by considering
a hypothetical example. In this hypothetical component diagram,
three components are considered, namely C-1, C-2, and C-3 respec-
A. Rathee and J.K. Chhabra Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551

Table 1
Different kinds of dependency relations in a component.

S. Relation Symbol Description

N. Name/Type Used
1 Association AR Represents ”has-a” relationship existing
between two classes say C1 and C2. Here, class
C1 has an association relationship with the
other class C2 iff C1 has an attribute of type C2.
2 Inheritance IR Represents ”Is-A” relationship existing
between two classes say C1 and C2. Here, class
C1 has an inheritance relation with another
class C2 iff C1 (sub/ child class) is a specialized
form of C2 (super/ parent class).
3 Call CR Represents the ”collaboration” relationship
that exists between two classes say C1 and C2.
Here, class C1 has a call relation with class C2
iff class C1 has a method call to one or more
methods belonging to class C2.
4 Parameter PR Two classes say C1 and C2 have this relation iff
a method in C1 has a parameter of class C2.
5 Return RR Two classes say C1 and C2 have this relation iff Fig. 1. Diagram depicting Component, Class, Subpackage, Class-Subpackage
any method in C1 has a return type of class C2. Relations, and Component- Component Relations.
6 Attribute AuR If any method in class say C1 directly accesses
Usage the attribute of another class say C2 or the CBSD technique. These components provide a cost-saving and
same class C1. These relations exist also within accelerated development environment for the developer and help
a given class. in promoting reusing existing resources in the form of compo-
7 Indirect/ InR Represents indirect method calls between
nents. Existing resource usability during the development of new
Transitive classes. Here, the class says C1 has an indirect
relation with another class say C2 if C1 has a software helps in developing it from scratch. However, component
method that has a method call to another reuse is still facing adoption problems due to the requirement that
method of the class say C3 and C3 has a the developers need to choose the best component out of a wide
method call to C2. set of third-party or in–house components. This is because of the
8 Co-Change CCR Represents co-change relations between
classes. Here, the two classes say C1 and C2
fact that multiple existing components can meet the requirement
have the co-change relation iff they are of the developers. This creates the problem of selecting the best
interrelated in the version control system. component out of the pool of possible components. Software met-
9 Semantic SR Represents token-based relations among rics can ease this problem by providing an automated way with
different classes or between methods
which the developers can assess the quality of the components.
belonging to a class.
Moreover, each software component fulfills the specifications laid
down by one of the component models such as JavaBeans. There-
tively. These components are drawn as rectangles and their con- fore, this paper proposes a metric suite that together measures dif-
tents are shown as circles (both filled and empty). The subpackage ferent dimensions of the JavaBeans based on different
of a component at any instance of time is defined as a collection of characteristics of the component and finally gives the overall
its all contents except one (shown by the blank circle). Here, in the reusability score of the JavaBeans and hence its underlying archi-
hypothetical diagram, the subpackage is shown as a collection of tecture. Different proposed metrics in this paper are detailed in
filled circles. In the considered hypothetical example, two types the following subsections:
of relationships are assumed to exist among different contents of
the same or different components (as discussed above) and are
5.1.1. Component Cohesion (CCoh) Metric
shown with two kinds of arrows. The solid arrow represents
A software component is a software element that conforms to a
class-subpackage relations at the component level. These kinds of
component model and its design mainly focuses on providing a
relations are confined only within the component and they are
unique functionality for the overall software system. It means that
due to the interaction of intra classes belonging to a component.
the cohesion of a component must be sufficiently high the consti-
These relations are used to compute the cohesion at the compo-
tuting elements of a component (different classes and interfaces)
nent level. Similarly, the component-component relations are
have different methods that are similar in many aspects and
shown by the dotted arrows. These kinds of relations exist among
related methods are present at one place. Here, the cohesion of a
components due to the interaction between inter classes of compo-
component is dependent on the cohesion among its content. The
nents. These relations help in determining the coupling of a com-
original set of object-oriented metrics cannot be directly applied
ponent with others.
to measure the cohesion of a component. This is because the orig-
inal object-oriented metrics are applicable at the single class level
5. Proposed Software Component’s Reusability Assessment only. However, generally, a component is a collection of two or
Metric Suite more classes. Therefore, they cannot be directly applied to the
component level. Moreover, different kinds of relations existing
This part of the paper presents the mathematical formulation in a component are divided into two categories, namely class-
and details of a case study carried out for the proposed reusability subpackage relations and component- component relations (as
assessment metric suite proposed in this paper. This section is discussed in Section 4 above). Out of these two possible kinds of
divided into the following two sections: relations, the class-subpackage relations are used to compute the
overall cohesion of a component. In this paper, the proposed cohe-
5.1. Metric Suite Definition and Computation sion metric CCoh is based on two kinds of cohesion measurements:

Software components are the key elements for the rapid devel- 1. Inner Cohesion
opment, deployment, and evolution of a software system using the 2. Outer Cohesion
5539
A. Rathee and J.K. Chhabra
The inner cohesion denotes the cohesion of the individual content
(class/ interface) belonging to a component. The inner cohesion of a
content ej belonging to the component C i is denoted as InCohði; jÞ
and it aims at measuring the cohesion level among different meth-
ods/ functions and the member variables belonging to the content
ej . Because the inner cohesion measures how efficiently different
methods and member variables are functionally related to each other.
Therefore, the inner cohesion measurement in this paper is based on
two kinds of relations, namely AuR and SR as depicted in Table 1
above. The AuR relation denotes the member variable access within
a method belonging to a class that belongs either to the same class
or to the other class. The SR relations are used to compute the seman-
tic cohesion among different pairs of methods belonging to a class.
The rest of the relations depicted in Table 1 do not contribute to
the inner cohesion of an element because they represent relation-
ships between two or more different elements. These relations
denote dependency/ relatedness among distinct elements and they
do not contribute to the measurement of relatedness within a single
software element. Hence, this paper considers only AuR and SR rela-
tions during inner cohesion measurement. For measuring the AuR
based inner cohesion, the member variable access to the same class
is taken into account. In a highly cohesive class, methods belonging
to it must have a strong bonding with the member variables belong-
ing to it. Similarly, the semantic cohesion is measured among differ-
ent pairs of methods and is determined by finding out the common
tokens shared by both. Here, the tokens are determined by parsing
the said pair of methods and extracting the elementary tokens
belonging to them. These two kinds of inner cohesion (IC) for the
th
k class containing a total of m methods are calculated using the fol-
lowing equations:
X
m X
m
CommonShareði; jÞ
IC AuR ðkÞ ¼
i¼1 j¼1
mðm1Þ
X
m X
m CCohi ¼
CommonShareði; jÞ
i¼1 j¼1
IC SR ðkÞ ¼ mðm1Þ
MatchingðV i ; V j Þ
CommonShareði; jÞ ¼ Matching
ðV i ; V j ÞþNonMatchingðV i ; V j Þ
Here, the CommonShareði; jÞ measures the extent to which the
sharing occurs among the ith and jth method of a class. It is mea-
sured using the MatchingðV i ; V j Þ and NonMatchingðV i ; V j Þ func-
tions. These two functions are based on two vectors V i and V j of
size nand they represent the set of member variables (in case
of IC AuR ) or tokens (in case of IC SR ) that are accessed by the corre-
sponding method mi and mj respectively. The corresponding entry
in these vectors is 1 (one) iff the corresponding method accesses
the corresponding member variable or the corresponding token
belongs to it, otherwise, it is 0 (zero). These functions return the
total number of matching (entries at corresponding index in two
vectors are either both 1 or 0) and nonmatching (entries at corre-
sponding index in two vectors are not either both 1 or 0) entries
present at different indices of two vectors V i and V j . In the above
formulas, the expression m  ðm  1Þ is used to normalize the val-
ues in the range [0. . .1]. This expression denotes the maximum
possible number of pairwise methods. Since a component contains
many classes that constitute its content. Therefore, the inner cohe-
th th
sion of the j class belonging to the i component is computed
using the following equation:
InCoh ði; jÞ ¼ w1  IC AuR ðjÞ þ w2  IC SR ðjÞ
Here, w1 and w2 are the weight (also called importance) factors
assigned to two considered relations, namely AuR and SR. More-
over w1 þ w2 ¼ 1 and w1 ; w2 2 ½0; 1. These weights are determined
by experts (developers) and they help in inculcating expert opinion
5540
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
during inner cohesion measurement. The outer cohesion of a con-
tent belonging to a component refers to the cohesion of the content
with the rest of the contents belonging to a component (referred to
as subpackage of a component). The outer cohesion of a content ej
belonging to the component Ciis denoted as OutCohði; jÞ and it
aims at measuring the cohesion of an individual content with the
rest of the contents belonging to the component. In this paper,
the outer cohesion is computed based on the class-subpackage
relations existing in a component. Lager the number of relations
between a class and a subpackage more is the class related with
other contents of the component. The outer cohesion of a compo-
nent for the jth class of the ith component is computed using the
following equation:
X X
n1
t
 
r x ej ; ey
x¼1 y¼1;;y –j
OutCoh ði; jÞ ¼
t  ðn  1Þ
Here, t denotes the total number of different relations as
depicted in Table 1 above, and (n-1)is the total number of
 
classes belonging to a subpackage. The relation r x ej ; ey denotes
the xth kind of relation (total t) existing between a class (de-
noted as ej ) and anyone of the rest of the classes belonging to
the subpackage (denoted as ey ). This relation exists, i.e.
 
rx ej ; ey ¼ 1 iff there exist xth kind of relation between a jth
and the yth class that belongs to a package. Here, in the above
equation, the expression t  ðn  1Þ denotes the maximum possi-
ble relations existing between a class and a subpackage. Finally,
the overall cohesion of a component is computed using these
two kinds of cohesion and finally averaging them as shown in
the following equation:
X
N
ðW 1  InCoh ði; jÞ þ W 2  OutCoh ði; jÞÞ
j¼1
N
Here, W 1 and W 2 are the weights and denotes the importance
given to the inner and the outer cohesion of content respectively.
N is the total number of elements (classes/ interfaces) belonging
to the component. The value of these weights varies in the range
[0. . .1].
5.1.2. Component Coupling (CCup) Metric
The reusability of a component is restricted by the outer
dependency of a component (coupling) with other components.
In other words, larger the dependency of a component with
others, the lesser will be its reusability. This is because the
presence of such a component makes it mandatory that other
dependent components are also available in the system. In this
paper, the coupling of a component is measured using the
component-component relations existing among different com-
ponents due to the interaction between their contents. This
paper calculates the coupling of a component C i in two steps.
Let us suppose that the component C i is having component-
component relations with other components say C j ; C k ; C l ; . . . ; C t .
Then in the first step, the pairwise coupling of C i with one
another component say C j is calculated (identified using the
component- component relations). Let mand nare the total
number of classes belonging to these components respectively.
Here, the pairwise coupling COUP ij is given by the following
equation.
X
t X
m X
n
 
rx ey ; ez
x¼1 y¼1 z¼1
COUPij ¼
t m n
A. Rathee and J.K. Chhabra
P P Pn  
In this equation, the expression tx¼1 m y¼1 z¼1 r ey ; ez aims at
x In the second step, the Tentative list is pruned to get the Actual
finding different kinds of relations (as indicated in Table 1) which
originates from different classes belonging to the component C i
and terminates at different classes belonging to another compo-
nent C j . The denominator here again gives the maximum number
of possible connections among two pairs of components. The
denominator is used to obtain values in the range [0. . .1]. Finally,
the overall coupling of a component C i that is dependent on say
Nother components is obtained by averaging the pairwise coupling
values as measured in the first step. This constitutes the second
step of the proposed component coupling metric. Mathematically,
this step is formulated in the following equation:
X
N the Actual and Present lists as shown in the following equation.
COUPik
k¼1
CCupi ¼
N jPresentj
Here, the denominator used helps us normalize the metric value
in the range of [0. . .1].
5.1.3. Degree of Customizability (DC) Metric
A component is designed aiming that it can be directly reused in
the software development process. The requirement of a customer
varies from software to software. This requires that a reusable code
(component) that provides customization in terms of its features is
considered as more reusable as compared to its counterpart that
provides few/ no customization. In this paper, the degree of cus-
tomizability for a component C i is measured in terms of the num-
ber of member variables whose value can be customized by the
developer before integrating the component with the rest of the
software being developed. Here, the customization denotes the
ability to change the values of different member variables as per
customer requirements. The previous two metrics (cohesion & cou-
pling) are unable to measure this degree of customization. There-
fore, we propose a new metric for this. Our proposed
customization metric aims at measuring this degree of freedom
provided by the underlying JavaBeans. As, in JavaBeans, the BeanIn-
foclass is generally used by the bean implementers for specifying
the methods, properties, and events of a bean. This information
is beneficial for JavaBeans users. Therefore, the total number of
properties specified in the BeanInfoclass can be a direct measure
of customization in the underlying JavaBeans. However, our pro-
posed metric moves one step forward and uses the internals of
the JavaBeans for measuring the customization provided with
more accuracy. The proposed metric is a three-step process. In
the first step, the proposed customization metric determines the
possible list of member variables (properties) that can be directly
initialized by the users of the bean. This list named Tentativecon-
tains member variable names and is obtained from various con-
structors as present in different classes belonging to the
component (JavaBeans). This list is termed Tentativebecause not
all of these member variables are directly accessible outside to
the bean users. This statement is supported by the fact that the
process of customization in JavaBeans is provided by special
bean-compliant builder tools. Such tools rely on the getterand set-
termethods to access the member variable’s original value and
assign it a new user-assigned value before integrating the compo-
nent in the software application. Mathematically, the Tentativelist
for a component C i containing nclasses is obtained using the below
equation. Here, the function getConstructorVariablesðjÞ gives the
member variable names that belong to the jth class and are initial-
ized in the constructor.
X
n metric is proposed aiming at measuring the extent to which the
Tentative ¼ f getConstructorVariablesðjÞg
j¼1
5541
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
list that contains the final set of customizable member variables.
The pruning is done by checking for the presence of corresponding
getter and setter methods in the class. The presence of such meth-
ods against any member variable helps a member variable in plac-
ing spots in the Actuallist. Here, it is important to note that these
two lists have the following relationships with each other:
Actual  Tentativ e
In the third step, another list called Presentis obtained that con-
tains possible customizable member variable names. This list is
obtained from the BeanInfoclass of the JavaBeans. Finally, the
degree of customizability of a component C i is computed using
The value of the DC i the metric varies in the range [0. . .1].
DC i ¼
jActualj
5.1.4. Self-Completeness of Component (SCC) Metric
The self-completeness of a component metric is proposed in
order to measure the completeness of the component from two
aspects namely (1) syntactical completeness, and (2) functional
completeness. The Syntactical Completeness (SynComp)measures
the extent to which a component fulfills the JavaBeans standards.
Similarly, the Functional Completeness (FunComp)measures the
extent to which the provides interface of a component lists the
functionality defined in the component.
Since the JavaBeans are the reusable software components that
encapsulate many objects in a single object called a bean. There-
fore, for a normal Java class to be a JavaBeans, it must follow var-
ious properties and conventions as given below1:
1. It must have a no-argument constructor so that the JavaBeans
object can be easily instantiated in the bean editing and integra-
tion framework.
2. It should be serializable.
3. It should not have any public member variables/ properties.
4. It should provide getterand settermethods for accessing differ-
ent properties.
5. It should provide a bean information class that helps third-
party tools in providing various features of JavaBeans such as
introspection and customization.
Based on the above-mentioned conventions that must be fol-
lowed by any bean, we defined the Syntactical Completeness (Syn-
Comp) metric for a component. It measures the extent to which a
component is designed as per JavaBeans specifications. The
description of this metric for a component C i is as shown in the
equation below:
x
SynCompi ¼
y
Here, xdenotes the total number of properties that the current
component possesses and ydenotes the total number of properties
(as identified above) that a component must fulfill in order for a
component to be a valid JavaBeans and always x <¼ y. In our case,
y = 5 (All these properties must be fulfilled by a valid JavaBeans).
Again, for a component, its services are only available via its
provides interface. If this provides interface does not fully list the
functionality available in its source code, then, its use is by nature
limited. In this paper, the functional completeness (FunComp)
1
http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/
A. Rathee and J.K. Chhabra
provides interface of a component list functionality defined in the
underlying source code of the component (source-code of its dif-
ferent classes). The proposed metric is based on the Method Call
Graph (MCG) that exists in a component and the presence of inde-
pendent method chains present in the formulated MCG. An MCG is
a graph G = <V, E>, where V is the set of vertices and different
methods defined in the component (belonging to different classes)
constitutes the vertex set V. Similarly, E is the set of directed edges
and denotes the method call relation that exists between any two
vertices (methods). In this graph, the independent method chain is
the finite path (sequence of edges), which joins a sequence of ver-
tices such that it has a unique distinct (no cycle) first and last ver-
tices. The first node (method name) represents the unique
functionality present in the source code of the component and it
should be present in the provides interface list of the component.
This is because the rest of the methods in the chain will be called
only if the first method (identified as the first node) will be called.
Any call to a method in the chain other than the first indicates the
usage of incomplete functionality in the system and it should be
penalized while determining the reusability of the component.
The proposed functional completeness metric is based on the func-
tionality (methods) depicted in the provides interface of the com-
ponent and the location of that method in the independent method
chains. For a component C i having a provides interface of size N,
this metric is computed using the following expression as shown
in the equation below:
X
N
methodWeightðkÞ
k¼1
FunCompi ¼ where
N

1  0:1  loc; LocationChainðkÞ – 0
methodWeight ðkÞ ¼
1; LocationChainðkÞ ¼ 0
Here, methodWeightðkÞ provides the penalized score for the kth
method in the range of [0. . .1] based on its location in the indepen-
dent method chains. This location denotes the depth of the said
method in the method chain and is determined by the
LocationChainðkÞ function. This function returns the location loc
of the kth method in the independent method chain. This location
starts from 0 (denotes the first node/ method in the chain) and
gradually increases as we move deeper into the method call chain.
Greater this location means deeper the presence of the method and
hence more penalty is imposed. The penalty mechanism is chosen
because the location other than 0 denotes the broken functionality
and is not considered as a good choice. Here, the broken function-
ality means that a method other than the head (starting method) is
directly called. The complete functionality is only available if only
the head of the chain is called. In the proposed metric, we used a
penalty of 10% with each increase in depth of the chain. The reason
behind choosing such a penalty score is to measure the functional
completeness with more accuracy and in this scheme, a 10% pen-
alty is considered in an ad hoc manner only. In our proposed met-
ric, the penalty on or after the depth of 9 (loc = 9) is taken as 90%.
This restriction is chosen in order to maintain the overall value of
penalty positive (after the depth of 10, the penalty becomes
negative).
Finally, based on the above discussed two aspects, namely syn-
tactic and functional completeness, the Self- Completeness of Com-
ponent (SCC) metric for a component C i is defined as follows:
SCC i ¼ SynCompi  FunCompi
5.1.5. Component Complexity Interface (CCI) Metric
In a software component, its interface plays an important
role and all interaction takes place through it. Moreover, if
5542
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
the component is a black-box, then only its interface is visible
to the outside world. Therefore, the complexity of the compo-
nent’s interface plays a direct role in its reusability. The com-
plexity of the interface of a component directly affects the
understandability and hence its reusability (Hristov et al.,
2012; Washizaki et al., 2004). This is because the developer’s
decision regarding using a component is based on the fact that
how efficiently the new requirements met with the functional-
ity provided by the component. This requires that the compo-
nent possess high understandability. According to Washizaki
et al., the understandability of a component means, ‘‘not being
complex”and is measured as the effort required in recognizing
the underlying concept and the applicability of the component.
A component with high understandability always possesses high
reusability. Therefore, in this paper, the CCI metric is proposed
for measuring the complexity of the component based on its
interface. This complexity measurement is based on two
aspects, namely (1) complexity arising because of the Message
Passing (MP) mechanism used in the interface method, and
(2) the semantic complexity of the interface method. The MP
complexity is based on the understandability efforts required
due to the total number of parameters passed and their corre-
sponding data type used. Similarly, the semantic complexity is
based on the efficient choice of the naming conventions used
to define different symbols, words (aka tokens) used in the
methods defined in the component interface.
The component complexity due to the MP mechanism used in
the interface methods considers the following three parameters
for determining the overall complexity of the interface method:
1. The total number of parameters passed in the interface method.
2. The data type used for the parameters passed in the interface
method.
3. The return type used for the interface method.
These three parameters are used because their nature and type
directly affect the understandability efforts needed at the devel-
oper’s end for getting the underlying concept and functionality
defined in the component. The MP complexity of the kth interface
method is based on the Return Type (RT) used and Parameter Type
(PT) used for various passed parameters. Mathematically, it is mea-
sured using the following equation:
X
t
ComplexityMP ðkÞ ¼ wRT þ wPT ðiÞ
i¼1
Here, tis the total number of arguments/ parameters passed to
the interface method. The expression wRT denotes the weight value
based on the used return type in the interface method. Similarly,
the expression wPT is the weight value based on the data type of
the ith parameter. Different data types used in JavaBeans are clas-
sified into four types namely (1) Simple, (2) Medium, (3) Complex,
and (4) Highly Complex. The Simple category includes primitive
data types of Java such as int, float, Boolean, etc. The Medium cat-
egory includes extended primitive data types such as Integer,
String, Date, etc. (defined in terms of objects in Java). The complex
category includes non-primitive data types such as Vector, Array.
Finally, the highly complex category includes Java’s reference data
types such as List, Map, etc., and user-defined data types. Table 2
shows different weights assigned to different data types used as
the parameter or return type of the interface method. These
weights are randomly chosen such that the overall complexity
remains within the range of ½0; 1. When all of these different cat-
egories of data types are present together then the complexity
always remains in the range of 0 and 1. The complexity of the
interface method also varies according to the total number of
A. Rathee and J.K. Chhabra
parameters passed in the interface method. The Table 3 depicts dif-
ferent weights assigned as per the number of parameters passed
and its corresponding category of the data type.
The second part in the complexity measurement of a compo-
nent is based on the semantic complexity present in the inter-
face method. The semantic similarity is measured between
different words identified by tokenizing the source code of
the interface method. The semantic similarity is based on the
lexical database known as WordNet (Miller, 1995) that is pre-
pared by Princeton University for the English language. The
WordNet group different nouns, verbs, adjectives, and adverbs
into sets of cognitive synonyms called synsets. These synsets
are interlinked and arranged in a hierarchical order based on
the conceptual-semantic and lexical relations (Pawar and
Mago, 2018). The semantic similarity among any two pairs of
words say w1 and w2 is based on the path length that exists
in the hierarchical structure. This path length is inversely
related to the semantic similarity, i.e. if the path length is more
than the words are not semantically related and vice versa. The
understandability based on the semantic complexity is directly
related to the semantic similarity. If the semantic similarity is
low (i.e. path length is more) then the understandability is also
low and hence higher semantic complexity. In this paper, the
semantic-based complexity of the kthinterface method is calcu-
lated using the following equation:
X
n X
n
1 per specifications of the JavaBeans component model. Therefore,
pathlen ðwi ;wj Þ
i¼1 j¼iþ1
ComplexitySEM ðkÞ ¼
n
Here, nis the total number of tokens/ words extracted from the
Pn Pn 1
interface method. The expression i¼1 j¼iþ1 pathlen ðwi ;wj Þ finds the
semantic similarity between different pairs of words based on
the path length. Finally, the overall complexity of the kth interface
method is calculated as follows:
Complexity ðkÞ ¼ ComplexityMP ðkÞ þ ComplexitySEM ðkÞ
Based on this the CCI metric for a component having Nmethods
defined in its provides interface is defined as follows:
X
N form of a vector. These vectors are used to compute the inner cohe-
Complexity ðiÞ
i¼1
CCIi ¼
N belonging to the considered JavaBeans. As the considered JavaBeans
Here, the denominator Nis used in order to normalize the values
in the range of [0. . .1].
5.1.6. Component Reusability (CR) Metric
Reusability measurement of components is an important
aspect. This helps the developers in choosing the best component
that fulfills all the requirements of integrating it with other compo-
nents. This proposed metric for measuring the reusability of the
component C i is based on above mentioned six metrics and is
defined as follows:
a1  CCohi þ ð1  a2  CCupi Þ þ a3  DC i þ a4  SCC i þ a5  CCIi
CRi ¼
a1 þ a2 þ a3 þ a4 þ a5
Here, a1 ; a2 ; a3 ; a4 ; and a5 are the coefficients that denote
importance assigned to different five factors, namely Cohesion,
Coupling, Customizability, Self-Completeness, and Complexity of
component interface that affects the reusability of the component.
Based on our manual investigation of different factors that affect
the reusability of the component, these coefficients are given
importance in the following order:
a1 > a2 P a5 P a3 > a4
5543
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
Here, the manual investigation of different factors is carried out
by using the hit and trial approach on sample components spe-
cially designed to be reusable in a CBSD environment and assigning
different random integer weight factors to these coefficients. In
each case, the component’s reusability value is computed and the
validation is carried out by presenting it to industry experts. After
manual evaluation, the best values are considered as the final coef-
ficient values in this paper. The main reasons behind using the hit
and trial approach in this paper are manifold. One main reason is
the acquired knowledge regarding the importance of various
reusability factors by us based on our previous research investiga-
tions (Rathee and Chhabra, 2018; Rathee and Chhabra, 2019;
Rathee and Chhabra, 2020). Another reason is the fact that auto-
mated implementation of various existing approaches useful in
determining the weight-based importance of various parameters
is not readily available (Heng et al., 2020; Zou et al., 2009). There-
fore, based on the fact that the importance of different factors is
well-known in advance and implementing various weight-based
importance techniques is time-consuming, this paper uses the hit
and trial approach to validate pre-acquired knowledge.
5.2. A Case Study
As the proposed metric suite in this paper aims at measuring
the overall reusability score of a component that is designed as
to demonstrate how different metrics belonging to the metric suite
are practically computed, a case study is carried out for a Digital
Clock 2JavaBeans. Fig. 2 depicts the UML structure of this JavaBeans
and it consists of two classes, namely DigitalClock and Digi-
talClockBeanInfo Out of these two classes, the class named Digi-
talClockBeanInfoprovides introspection properties and gives details
about different services that it provides to the outside world. The
source code of this JavaBeans is manually investigated to determine
different structural and semantic information required during com-
puting different metrics belonging to the proposed metric suite. For
computing CCohmetric value, the AuR and SR information are identi-
fied at the method level and this information is presented in the
sion value, which comes out to be 0:47 based on the pairwise com-
parison between vector representations of different methods
only single class, therefore, the value for outer cohesion for this Java-
Beans is 0. Hence, the overall value for CCoh metric is 0:47. The con-
sidered JavaBeans does not require any external library or
component, therefore, the value of the CCup metric is 0. The value
of DC metric depends on the number of member variables for which
the getterand settermethods are defined. The value of the DC metric
for considered JavaBeans comes out to be 0:54. The considered
example fulfills all the syntactical specifications of the JavaBeans
and the value of SynComp is 1. The DigitalClockBeanInfo(provides
interface) of the JavaBeans does not list all the functionalities iden-
tified by the presence of different independent paths in the call-
based graph of the component. The value of the functional complete-
ness comes out to be 0:47. Hence, the overall value of the SCC metric
is 1  0:47 ¼ 0:47. The value of the CCI metric is determined from
the DigitalClockBeanInfoclass based on the complexity of different
parameters passed to various methods defined in this class and
WordNetbased semantic complexity of the considered JavaBeans.
The computed value of the CCI metric is 0:20. Based on these metric
values, the overall reusability for the considered Digital Clock Java-
Beans is CR ¼ 0:54 based on different alpha parameter values shown
in Table 5. Further, as the considered JavaBeans does not possess any
2
https://www.codeproject.com/Articles/3788/Digital-Clock
A. Rathee and J.K. Chhabra Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551

Table 2
Weight values assigned to different Data Types on JavaBeans.

Data Type Category

Simple Medium Complex Highly Complex
Assigned Weight 0.10 0.20 0.30 0.40

Table 3
Weight values assigned based on the total number of parameters passed.

Data Type Category

Simple Medium Complex Highly Complex
1–3 0.10 0.15 0.20 0.25
4–6 0.20 0.30 0.40 0.50
Number Of Parameters/ Arguments Passed 7–9 0.30 0.45 0.60 0.75
>=10 0.40 0.60 0.80 1.0

Fig. 2. Typical structure of a Digital Clock JavaBeans Component.

5544
A. Rathee and J.K. Chhabra
external dependency to other components, therefore, the value of
the TurboMQmetric comes out to be 1 because a TurboMQmetric
measures the balance between cohesion and coupling.
6. Theoretical Validation of the Proposed Reusability Metric
Suite
The theoretical soundness of the newly proposed metric suite
provides strength and validation to the proposed metric suite.
Therefore, this section of the paper provides a theoretical analysis
based on their mathematical properties. The commonly used vali-
dation frameworks available in the literature are (Briand et al.,
1996; Weyuker, 1988). This paper considers evaluation against
Briand’s framework. The reason behind choosing Briand et al.’s val-
idation framework is that Weyuker’s validation framework is
mainly used to only validate complexity measure metrics. But,
Briand’s framework mathematically formalizes all important inter-
nal software attributes such as size, length, cohesion, coupling, and
complexity. The Briand et al. framework mainly consists of four
properties that need to be fulfilled by any metric. These properties
are discussed against the proposed reusability metric suite in the
following subsections:
Property 1:Non-Negativity
This property of Briand’s validation framework measures the
sizeof the underlying system and it states that for any system the
size should always be non-negative at any instance of time. The
value of each of the metrics in the proposed component reusability
metric suite varies in the normalized range of [0, 1] with the fact
that zero denotes the minimum value and one denotes the maxi-
mum possible value. Moreover, the Component Reusability (CR)
Metric computes the overall reusability score to a component
and the assigned value is always positive in nature (based on the
values of used metric values). The higher score to this metric is
an indication of the more reusable component in the CBSD envi-
ronment. Therefore, our proposed metric suite fulfills the first
property of Briand’s framework.
Property 2:Null Value
This property of Briand’s framework denotes that if the size of
the system is null,i.e. if either the total number of elements belong-
ing to the system is zero or the relationships between elements is
null, then the corresponding metric value is null/ zero. For our pro-
posed metric suite, this property holds because in such cases the
corresponding metric value is always zero. This is because different
metrics in the proposed metric suite are calculated based on differ-
 
ent kinds of relations of type tdenoted asr x ej ; ey . Therefore, if
there does not exist any kind of dependence relation within or
among components, then the corresponding metric value is always
zero/ null (as the numerator of each metric is always zero because
of null dependencies). Hence, this property holds for our proposed
reusability metric suite.
Property 3:Monotonicity
This property of Briand’s framework states that if in a system
new relations are added then the overall metric value should not
decrease. The proposed CCoh metric is based on the inner (InCoh)
and outer (OutCoh) computed cohesion values computed using
the class-subpackage relations. These values are directly propor-
tional to the total number of relations in a component. Therefore,
if the frequency of the relations increases, then, the overall value
of the CCohmetric increases. Similarly, the proposed CCupmetric
is directly proportional to the total number of component- compo-
nent relations. Hence, any increase in the total number ultimately
results in an overall increase in the value of the CCupmetric.
Another proposed customizability (DC)and complexity (CCI)met-
rics are independent of the total number of relations within or
among components. Hence, both themetrics are independent of
5545
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
the variations due to the changes in the total number of relations.
The self-completeness (SCC)metric is only dependent on the call
relations among different contents of the component. These call
relations may increase as well as decrease the imposed penalized
score based on the location of the interface methods. However, it
is important to note here that this imposed penalized score in no
way affects the methods defined inside the interface of the compo-
nent. Hence, the overall metric value remains unchanged. Based
upon this, it can be concluded that, this property holds for the pro-
posed metric suite because if the degree of relations is increased at
the component level, then the value of the corresponding metric
also increases due to an increase in the CCoh (Cohesion) metric
value.
Property 4:Merging of Unconnected Components
This property of Briand’s framework denotes that if two unre-
lated and unconnected components are merged together into a sin-
gle component, then the value of the corresponding metric for the
new component should not increase. This is because of the fact that
the unconnected components are being encapsulated together in a
single component. This means, the total number of class-
   
subpackage r t ei ; Sj and the component- component r t ei ; ej
relations, on which different proposed metrics are based, do not
get changed (total number of such relations before and after merg-
ing remains unchanged). However, because, unconnected compo-
nents are merged together, therefore, the value of OutCoh(Outer
Cohesion) decreases due to an increase in the total number of
classes belonging to the subpackage i.e. (n-1) parameter value in
the expression of OutCoh. This happens because of the fact that
the merged unconnected components provide a higher degree of
reusability independently as compared to the merged scenario.
This ultimately results that the overall value of the reusability
score assigned by the CRmetric decreases. Hence, for our proposed
metric suite, this property holds, as merging does not result in the
increase in the final reusability score assigned to the component.
7. Experimentation
In the present study, the proposed metrics serve a very clear
and specific purpose of measuring the reusability of JavaBeans
(reusable components) that are already present over the Internet
or are available in the form of a third-party library. As per the
ISO/ IEC 9126-1 standard, in a software product, the external qual-
ity attributes should always be related to the internal measures of
the product and vice versa. Therefore, in this paper, we carried out
an experimental evaluation of the proposed metric suite. This helps
us to validate the proposed metric suite empirically. The carried
out experiment is based on GQM (Goal/ Question/ Metric) para-
digm. It provides a basic template and guideline that helps in car-
rying out the experiment in a systematic manner. In the GQM
paradigm, the five-goal dimensions that are followed are as
follows:
1. The object of the Study: Components (JavaBeans)
2. Purpose: To analyze the quality of the JavaBeans especially from
the CBSD environment point-of-view
3. Quality Focus: Reusability score associated with the component
4. Viewpoint: Software developer
5. Environment: Existing JavaBeans, components, and open-
source Java software systems
One of the major hurdles present in the research associated
with the software metric is the difficulty of empirical evaluation.
Empirical evaluation of most of the existing metrics is based only
on modest experimental support. Therefore, this paper carried
out a wider empirical evaluation of the proposed metric suite.
We consider three categories of software for carrying out the
A. Rathee and J.K. Chhabra
experiment. The first category consists of existing JavaBeans that
are collected from various sources such as ComponentSource.com,
elegantjbeans.com. These repositories provide a wide variety of
the best and the largest collection of ready-to-use JavaBeans pro-
vided by third-party vendors. The second category consists of
open-source Java software that provides reusable components in
the form of an API/ library. These software are hosted under the
Apache Commons3project. The different software in this category is
designed such that they are least dependent on the other libraries.
The third category of the considered software consists of different
open-source software systems that are not designed by taking
reusability in mind as the case with the software systems considered
in the second category. Table 4 summarizes and gives details about
various software considered from these three categories. These
details include the size of the component, the number of classes
belonging to the component, the package present in the component
structure, and a brief description of the functionality provided by the
component.
This paper considers three categories of software, out of which
category C-1 are ready-made components/ JavaBeans. However,
the software considered in the categories C-2, and C-3 are normal
open-source software systems and they are not ready to use Java-
Beans. Therefore, it is mandatory to convert them in the form of
JavaBeans before evaluating them with the proposed metric suite.
This paper considers different packages present in the software
systems belonging to category C-2 and C-3 as independent compo-
nents and finally converts them into corresponding JavaBeans
using the approach proposed by Rathee and Chhabra (2019).
Finally, this paper considers giving answers to the following
research questions for justifying the necessity and urgency of the
proposed metric suite based on the carried out experiment:
RQ1 What is the relationship between different Coupling,
Cohesion, Customizability, Completeness, and Interface
Complexity?
This research question is statistically answered by finding the
strength and direction of the association between two nonpara-
metric ranked variables using the well-known Spearman’s Cor-
relation Coefficient. This research question further helps in
determining if or not all the considered component characteris-
tics are important.
RQ2 Do the TurboMQ metric measure the same or different
dimensions as the CR metric?
As the proposed metric suite measures the overall component
reusability score using the proposed CR metric. In literature,
the TurboMQ metric is a well-known quality metric that is com-
monly used to measure the modularity of the underlying com-
ponent. Therefore, this research question is designed for
determining whether or not the proposed CR metric measure
some extra characteristics as of the metric TurboMQ. Thus, this
research question helps in determining the usefulness of the
proposed CR metric.
8. Results and Interpretations
In this section of the paper, we present the obtained experimen-
tal results as part of the empirical evaluation of our proposed
reusability metric suite. Further, the obtained results are analyzed
and their interpretation is provided. Different proposed metrics are
computed by manually analyzing the underlying source code and
computing different metric values. Table 5 provides details about
the obtained results after experimentally analyzing the considered
software systems. Moreover, integer values are assigned to differ-
ent coefficients ða1 ; a2 ; a3 ; a4 ; a5 Þ used for calculating the overall
3
https://commons.apache.org/
5546
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
component reusability (CR) score. The integer values are assigned
based on the criteria as discussed in Section 5 above and they
are shown in Table 5. These values are used to compute the
reusability score of a component in this paper.
From the results shown in Table 5, it is clear that the software
considered in the category C-1, possessess a higher reusability score
for the underlying JavaBeans. The average reusability score for this
group is 92.4%, which is as per our expectations. This group has high
cohesion, customization, completeness, and low coupling and com-
plexity of the interfaces. Similarly, the software systems considered
in category C-2 also possess a sufficiently higher reusability score
with an average reusability score of 72.8%. This conforms to the fact
that such libraries/ APIs are designed by keeping component charac-
teristics in mind by the developers but as they are not modeled as
per particular component model standards, their reusability in the
CBSD environment is limited as compared to the components con-
sidered in category C-1. Different components in this category (C-
2) are logical in nature (provides and requires interfaces are not
identified) and they cannot be directly reused in the CBSD environ-
ment for developing new software systems. Finally, the software
considered in category C-3 possesses an average reusability score
of 54.2%. This low reusability score points out the fact that these soft-
ware are not designed from a reusability point of view. They possess
higher coupling and low cohesion and these characteristics are not
desirable from the component point of view. Hence, the developers
do not consider reusability aspects at all while designing these sys-
tems and they have very limited reusability for the development of
new software systems.
Based on the results shown in Table 5, it can be clearly concluded
that the proposed CR metric in this paper is capable of accurately
predicting the actual reusability score of different software compo-
nents. Now, in order to further validate the obtained results of
Table 5, the authors in this paper carried out the task of practically
validating these different reusability values from a team of practi-
tioners (domain/ IT experts). For this purpose, a team of 20 random
practitioners is created in order to keep the investigation process
unbiased. Each of these team members is presented with different
software components and based on the domain expertise they are
asked to investigate the reusability of the presented components.
Further, in order to keep the comparison fair and simple, the inves-
tigation of the reusability of different components is done on fixed
criteria, namely cohesiveness, external dependency, ease of com-
posing components, functional completeness, customizability, and
maintenance efforts required to modify the component. These
selected criteria are mostly similar to the proposed metrics in the
metric suite of this paper. Each team member evaluates the compo-
nent and assigns a score to these evaluation criteria on a scale of 1 to
5 (here, 1 means strongly disagree and 5 means strongly agree).
Finally, the average mean of these assigned values is evaluated
and compared with the reusability scores of different software cat-
egories taken in Table 5. The manual comparison of the mean values
of the practitioners’ reusability score with the CR metric values as
depicted in Table 5 is found comparable. Further, this claim is statis-
tically cross-verified by doing a two-tailed t-test. The p-value of this
test is 2:1012  1012 and it is significantly smaller than the signifi-
cance level alpha = 0.05. Based on this comparison, the authors pro-
vide practical validations for the proposed metric suite of this paper.
RQ1 What is the relationship between different Coupling,
Cohesion, Customizability, Completeness, and Interface
Complexity?
This research question aims at determining the relationship
between different pairs of component characteristics, namely
cohesion, coupling, customizability, completeness, interface
complexity, and reusability. Spearman’s nonparametric rank coef-
ficient is used to determine the correlation and direction of
A. Rathee and J.K. Chhabra Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551

Table 4
Summary of various considered components/ software.

S. Component Name Size (in Total No. Of Description

No. KB) Classes/ Packages
Considered JavaBeans (C-1)
1. Networking 281 51/ 12 Provides ready to use network protocol implementation that provides support for various protocols
JavaBeans Collection namely FTP, HTTP, POP3, SMTP, and MIME
2. Entry Mask JavaBeans 511 60/ 10 Provides Ready-made validation logic for accurate data entry. It gives yourJavaTM based true solution
advantage of masking. Data is being checked on keypress.
3. Tree JavaBeans 681 124/ 8 Provides feature-rich tree for hierarchical representation of data.
4. Table JavaBeans 545 164/ 10 Provides total control over information management through tables.
5. Printer JavaBeans 216 17/ 3 Provides an implementation of full Java printing functionality
Considered Apache Commons Components/ Library (C-2)
1. Lang 1334 141/ 12 Provides a host of helper utilities for java.lang API
2. Math 5311 265/ 22 Provides a library of lightweight mathematics and statistics components not available in Java
programming language.
3. FileUpload 1614 67/ 5 Provides file upload capability for servlets and web applications.
4. Text 466 45/ 4 Provides a set of algorithms that works on strings.
5. RNG 1144 124/ 10 Provides implementations of pseudo-random numbers generators that are either faster and/ or of
higher quality than java.util.Random
Considered other Open-Source Software Systems (C-3)
1. Junit 4.5 60 27/ 4 A unit testing framework for the Java programming language.
2. Easy Mock 2.4 163 63/ 3 A Java-based mocking framework used to unit test Java applications.
3. JDOM 1.1.3 230 62/ 6 Java based library for parsing XML documents.
4. XGen Source Code 290 30/ 6 Java source code generator from the structured input file.
Generator 0.3.8
5. Servlet API 2.4 89 41/2 A Java library that provides server-side functionality to the application.

Table 5
Experimental Results for different considered software systems.

S. N. Category Component Name Proposed Metric Suite Average Practitioner’s Feedback Score
CCoh CCup DC SCC CCI CR
a1 ¼ 5 a2 ¼ 4 a3 ¼ 2 a4 ¼ 1 a5 ¼ 4
1 Networking JavaBeans Collection 0.93 0.13 0.84 0.92 0.18 0.93 4.34
2 Entry Mask JavaBeans 0.84 0.18 0.82 0.97 0.22 0.87 3.87
3 Tree JavaBeans 0.89 0.22 0.86 0.95 0.27 0.92 4.76
4 C-1 Table JavaBeans 0.91 0.11 0.88 0.94 0.24 0.97 4.29
5 Printer JavaBeans 0.92 0.16 0.85 0.98 0.19 0.93 4.88
6 Lang 0.78 0.31 0.85 0.88 0.11 0.71 3.76
7 Math 0.72 0.38 0.88 0.89 0.08 0.63 4.21
8 C-2 FileUpload 0.83 0.19 0.91 0.92 0.10 0.82 3.87
9 Text 0.76 0.35 0.88 0.87 0.07 0.66 2.56
10 RNG 0.81 0.22 0.89 0.86 0.09 0.77 4.13
11 Junit 4.5 0.62 0.53 0.86 0.92 0.18 0.54 3.45
12 Easy Mock 2.4 0.59 0.48 0.91 0.88 0.14 0.54 2.98
13 C-3 JDOM 1.1.3 0.64 0.44 0.88 0.91 0.16 0.59 3.98
14 XGen Source Code Generator 0.3.8 0.52 0.51 0.87 0.89 0.12 0.46 3.52
15 Servlet API 2.4 0.68 0.52 0.92 0.93 0.13 0.58 4.56

association among different pairs of considered component charac-
teristics. Here, Spearman’s test is chosen over Pearson’s Correlation
because different metric values are not normally distributed. The
normality is checked using the Shapiro–Wilk normality test. The
obtained p-value of the Shapiro–Wilk normality test is 0:00145
and this value is sufficiently lower than 0:05. Hence, we chose
Spearman’s test over Pearson because Pearson’s test requires a nor-
mal distribution of data. Table 6 shows Spearman’s Correlation
Coefficient values between different pairs of characteristics.
From the values shown in Table 6, it can be clearly observed
that the cohesion and coupling characteristics are strongly nega-
tively linearly correlated. It means an increase in one characteristic
value automatically results in the decrease of the other character-
istic value. Since this paper considers measuring functional cohe-
sion at the component level. Therefore, if a component is
functionally sound (it contains all its related elements together,
hence, higher cohesion) then its computed coupling is automati-
cally least. This confirms the obtained strong negative Spearman’s
correlation results between coupling and cohesion metric. The
interface complexity and completeness characteristics are strongly
positively linearly correlated. As the self-completeness of a compo-
nent increases, it results in an increased size of the BeanInfo class
of the component. Any increased size results in understandability
issues at the programmers’ end. Hence, the obtained positive cor-
relation as observed from the Spearman Correlation value. Simi-
larly, the characteristic pairs named customizability and
cohesion, completeness and coupling, completeness and customiz-
ability, interface complexity and coupling, interface complexity
and customizability are weakly correlated. This relationship can
be clearly observed in the diagram shown in Fig. 3. Moreover,
the component reusability metric is strongly positively and nega-
tively related to the cohesion and coupling characteristics of the

5547
A. Rathee and J.K. Chhabra
Table 6
Spearman’s Correlation Coefficient Values.
CCoh CCup
CCoh 1
CCup 0.92504 1
DC 0.44366 0.392565
SCC 0.526535 0.40085
CCI 0.424413 0.37364
CR 0.977086 0.95618
component. As the cohesion of a component increases, the
reusability increases and vice versa. Similarly, as the coupling of
a component significantly decreases, the underlying reusability
increases incredibly and vice versa. The reusability of a component
is negatively related to the customization characteristic. As the dif-
ficulty of component customization increases, the reusability
decreases. Further, as the self-completeness of a component
increases, the reusability score also increases. Finally, the compo-
nent reusability increases with the increase in the component’s
interface complexity and vice versa. This is because, the compo-
nent’s interface measures understandability based on semantic
relatedness based on WordNet, therefore, as the relatedness
increases, the overall reusability also increases.
RQ2 Do the TurboMQ metric measure the same or different
dimensions as the CR metric?
TurboMQ is a metric that is widely used for evaluating the mod-
ularization quality of any system (Mitchell, 2003). This metric
measures quality in terms of inter and intra dependency relations
present in the component. Table 7 shows the values of TurboMQ
and CR metric values for different considered software systems.
As for the software systems in the category, C-2 and C-3 are con-
cerned, different packages are considered as individual compo-
nents. Therefore, the TurboMQ score shown is the average value
of individual components belonging to a software system.
Fig. 3. Pairwise Spearman Correlation Coefficient values.
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
DC SCC CCI CR
1
0.3926 1
0.49332 0.81956 1
0.40904 0.525514 0.467412 1
The TurboMQ metric is not upper bound and a higher score is
always preferred. A higher score is always an indicator of good
modularization quality. From the results shown in the Table 7, it
is observed that for some systems (say Servlet API, JUnit), the Tur-
boMQ value is sufficiently high, however, the reusability of the cor-
responding component is low and vice versa (say Printer
JavaBeans, RNG). Therefore, in order to draw a clear relationship
between two variables, we carried out Spearman’s Correlation
Coefficient analysis and the results are shown in the scatter plot
shown in Fig. 4.
From the plot, it can be clearly observed that TurboMQ and CR
metrics have a non-linear relationship with each other. The R-
squared statistics value of the plot is 0.48. It denotes that the over-
lap between TurboMQ and CR metric is only 48%. Statistically, it
means that the linear regression model between the considered
TurboMQ and the proposed CR metric provides response data to
only 48% of the response variable variations (Hair et al., 2013).
The rest of the 52% variability of the response data about its mean
remains unexplained. Therefore, it is concluded that the proposed
CR metric is capable of covering some extra features that are not
generally covered by the TurboMQ metric alone. Hence, the useful-
ness of the proposed metric for measuring the quality of the com-
ponent is justified. Therefore, the research community can use the
proposed CR metric to determine the overall quality of a
5548
A. Rathee and J.K. Chhabra Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551

Table 7
TurboMQ V/S CR metric.

S. N. Category Component Name TurboMQ CR

1 Networking JavaBeans Collection 1.84 0.93
2 Entry Mask JavaBeans 1.93 0.87
3 C-1 Tree JavaBeans 1.43 0.92
4 Table JavaBeans 2.32 0.97
5 Printer JavaBeans 1.04 0.93
6 Lang 0.65 0.71
7 Math 0.87 0.63
8 C-2 FileUpload 1.43 0.82
9 Text 0.83 0.66
10 RNG 0.65 0.77
11 Junit 4.5 1.25 0.54
12 Easy Mock 2.4 2.04 0.54
13 C-3 JDOM 1.1.3 1.56 0.59
14 XGen Source Code Generator 0.3.8 1.56 0.46
15 Servlet API 2.4 1.05 0.58

component and the metric suite can easily be utilized as fitness
functions during reverse engineering/ component extracting from
an object-oriented software system.
The TurboMQ and CR metric values as shown in Table 7 are not
collinear and the experimental evaluation shows an overlap of 48%
only. Therefore, it is necessary to further investigate the relationship
between the two metrics. This investigation is performed by authors
by carrying out practical validation from a team of experts. The team
is presented with the obtained results shown in Table 7 along with
the source code of different software and components. The team car-
ried out an investigation on the variability between two metric val-
ues such as for a Tree JavaBeansthe TurboMQ metric value is having a
smaller value as compared to EasyMocksoftware. Still, Tree JavaBean-
shas higher reusability as compared to EasyMock.The investigation
report of the experts suggests that TurboMQ metric value only pro-
motes cohesiveness and penalizes outer dependency. However, the
overall reusability of a component in the CBSD environment requires
important features such as the presence/ absence of the compo-
nent’s interface, semantic complexity, and availability of documen-
tation. These extra features are not detectable in the TurboMQ
metric and they directly reflect the efforts devoted by the mainte-
nance/ developer team. The expert team is unable to find any extra
feature that is detectable by the TurboMQ metric while remaining
undetectable by the proposed CR metric.
9. Comparison with Existing Competitive Approach
It is important to evaluate the proposed metric suite against the
state-of-art metric suite in order to determine the feasibility and
usefulness in the real development environment. This paper con-
siders evaluating the proposed metric suite against the metric suite
proposed by authors in Washizaki et al. (2004). In literature,
Washizaki et al. (2004) present a closer state-of-art contending
approach for measuring the reusability of JavaBeans software com-
ponents. They measured the reusability with the help of the pro-
posed metric suite, especially for the black-box JavaBeans
components. The authors also performed a statistical analysis of
125 JavaBeans components and proposed a confidence interval
for different metrics in the metric suite for determining the quality
factor of the component. The overall reusability score for the com-
ponent (COR) is computed based on the parameters, namely Exis-
tence of Meta-Information (EMI), Rate of Component
customization (RCC), and Self-Completeness of Component’s
Return ValueðSCC r Þ. The reusability metric (COR) of Washizaki
et al. (2004) assigns binary values to the reusability of the compo-
nent. It means it classifies the component as either Reusableor Non-
reusable based on whether the metric value is ‘greater than zero’ or
‘negative’. The approach by Washizaki et al. (2004) is the closest
state-of-art contender to the proposed metric suite in this paper.
Therefore, this approach is selected for evaluation purposes in this
paper.
As the reusability metric of Washizaki et al. (2004) is specially
designed for JavaBeans, therefore, this paper considers evaluating
different JavaBeans as specified under the C-1 category in Table 4.
The results of the evaluation are presented in Table 8. Table 8 pre-
sents different intermittent metric values (such as EMI, RCC,SCC r ),
Component Overall Reusability score (COR), reusability interpreta-
tion based on the COR metric value, and the reusability scores as
computed using the proposed Component Reusability (CR) metric
of this paper. The COR metric does not predict one JavaBeans as
reusable namely Entry Mask JavaBeans. Whereas, the reusability
metric of this paper (CR) considers every JavaBeans as reusable
in nature and assigns a significantly high reusability score to every
component. After performing a manual analysis of the Entry Mask
JavaBeans, it was found that the said component is actually having
higher reusable quality (as captured by our proposed reusability
metric, CR) based on high cohesion, low coupling, and lower inter-
face complexity.
The key differences between the component reusability metric
of this paper (CR metric) and the one of Washizaki et al. (2004),
i.e. COR metric, are as follows:

1. The COR metric does not consider the important quality param-
eters such as cohesion, interface complexity, and coupling while
determining the overall reusability of the component as
Fig. 4. Scatter Plot between TurboMQ and CR metric. opposed to our proposed reusability metric (CR).

5549
A. Rathee and J.K. Chhabra
Table 8
Reusability metric score comparison with the state-of-art contending approach.
JavaBeans Name The Rival approach by Washizaki et al. (2004)
EMI RCC
Networking JavaBeans Collection 1 0.56
Entry Mask JavaBeans 1 0.33
Tree JavaBeans 1 0.62
Table JavaBeans 1 0.68
Printer JavaBeans 1 0.79
2. The COR metric does not rank the overall reusability score (it
considers all components equally reusable whose reusability
score is > 0).
3. The COR metric cannot be used for comparing different compo-
nents together. This is because it assigns only a binary score (ei-
ther usable or non-reusable) to the component. Therefore, this
metric cannot be used to select one component out of the com-
ponent pool having similar functionality.
The reusability metric suite in this paper is proposed especially
for JavaBeans. However, this metric suite can easily abstract away
and serve other platforms beyond the considered JavaBeans except
for the SCC metric. A few things that must be fulfilled by such a plat-
form include the presence of different interfaces of the component,
provisions of initializing and retrieval of different member variables
(similar to getter and setter methods of JavaBeans). The proposed
SCC metric requires little modifications in the rules of the SynComp
part of this metric. These rules need to be formulated as per the syn-
tactical specifications of the new platform. Moreover, it is a strong
belief of the authors that these metrics can be easily automated as
per the specifications of different component models.
10. Conclusions and Future Work
With the increasing use of the CBSD in the IT industry, there is
an increased demand for a component library having multiple
components corresponding to various functionalities. These com-
ponents help in promoting architecture level reuse during software
development. However, this requires that the reusability factor of
the component should be measured in order to compare it with
the reusability of other similar functional components. This can
be used to determine the best-suited component for the CBSD
use. Therefore, the primary objective of this paper is to propose a
metric suite for estimating the reusability of the components
designed for the Java language.
This paper proposes the measurement of reusability by propos-
ing different metrics that measure the cohesion, coupling, cus-
tomizability, completeness, and interface complexity
characteristics of the component. Based on these metric values,
the final component reusability score is estimated using the pro-
posed metric. The paper evaluates the proposed metric suite
against three categories of Java language software. These cate-
gories include software from a wide variety, having readymade
JavaBeans components, object-oriented software systems designed
using component characteristics in mind, and simple object-
oriented software systems. The proposed metric suite is tested
both experimentally and statistically. The obtained results clearly
demonstrate that the proposed metric suite is a very good indica-
tor of the reusability for the components designed in the Java
language.
This work primarily intended to estimate the reusability of
components is designed especially for the Java language. However,
it is our belief that the proposed metric suite is having a wider
scope and can be easily used by researchers in developing,
5550
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
Proposed Approach
SCCr COR Interpretation CR
0.72 0.63 Reusable 0.93
0. 54 0.55 Non-reusable 0.87
0.87 0.63 Reusable 0.92
0.47 0.05 Reusable 0.97
0.71 0.63 Reusable 0.93
comparing, and evaluating component metrics. Our future work
in this direction also includes developing metrics and automated
tools that compute the proposed metric suite for components
beyond JavaBeans. The proposed metric suite can be used with
code search engines such that its results are arranged as per their
reusability values in order to help the developers iidentify the right
component in minimal time.
Declaration of Competing Interest
The authors declare that they have no known competing finan-
cial interests or personal relationships that could have appeared
to influence the work reported in this paper.
References
Aggarwal, K., Singh, Y., Kaur, A., Malhotra, R., 2006. Empirical study of object-
oriented metrics. J. Object Technol. 5, 149–173.
Ampatzoglou, A., Bibi, S., Chatzigeorgiou, A., Avgeriou, P., Stamelos, I., 2018.
Reusability index: A measure for assessing software assets reusability. In:
International Conference on Software Reuse. Springer, pp. 43–58.
Anguswamy, R., Frakes, W.B., 2012. A study of reusability, complexity, and reuse
design principles. In: Proceedings of the 2012 ACM-IEEE International
Symposium on Empirical Software Engineering and Measurement. IEEE, pp.
161–164.
Anthes, G.H., 1993. Software reuse plans bring paybacks. ComputerWorld 27, 73–
74.
Bertoa, M.F., Troya, J.M., Vallecillo, A., 2006. Measuring the usability of software
components. J. Syst. Softw. 79, 427–439.
Bi, S., Dong, X., Xue, S., 2009. A measurement model of reusability for evaluating
component. In: 2009 First International Conference on Information Science and
Engineering. IEEE, pp. 20–22.
Boxall, M.A., Araban, S., 2004. Interface metrics for reusability analysis of
components. In: 2004 Australian Software Engineering Conference.
Proceedings. IEEE, pp. 40–51.
Boxall, M.A., Araban, S., 2004. Interface metrics for reusability analysis of
components. In: 2004 Australian Software Engineering Conference.
Proceedings. IEEE, pp. 40–51.
Briand, L.C., Morasca, S., Basili, V.R., 1996. Property-based software engineering
measurement. IEEE Trans. Software Eng. 22, 68–86.
Chhabra, J.K. et al., 2017. Improving modular structure of software system using
structural and lexical dependency. Inf. Softw. Technol. 82, 96–120.
Chidamber, S.R., Kemerer, C.F., 1994. A metrics suite for object oriented design. IEEE
Trans. Software Eng. 20, 476–493.
Cho, E.S., Kim, M.S., Kim, S.D., 2001. Component metrics to measure component
quality. In: Proceedings Eighth Asia-Pacific Software Engineering Conference.
IEEE, pp. 419–426.
Chowdhury, I., Zulkernine, M., 2011. Using complexity, coupling, and cohesion
metrics as early indicators of vulnerabilities. J. Syst. Architect. 57, 294–313.
Cimino, M.G., Marcelloni, F., 2012. An efficient model-based methodology for
developing device-independent mobile applications. J. Syst. Architect. 58, 286–
304.
Di Cosmo, R., Zacchiroli, S., Trezentos, P., 2009. Package upgrades in foss
distributions: Details and challenges. arXiv preprint arXiv:0902.1610.
Crnkovic, I., Sentilles, S., Vulgarakis, A., Chaudron, M.R., 2010. A classification
framework for software component models. IEEE Trans. Software Eng. 37, 593–
615.
Crnkovic, I., Sentilles, S., Vulgarakis, A., Chaudron, M.R., 2010. A classification
framework for software component models. IEEE Trans. Software Eng. 37, 593–
615.
Englander, R., 1997. Developing JAVA beans. O’Reilly Media Inc..
Feljan, J., Carlson, J., Žagar, M., 2009. Using javabeans to realize a domain-specific
component model. In: 2009 35th Euromicro Conference on Software
Engineering and Advanced Applications. IEEE, pp. 474–477.
Frakes, W.B., Succi, G., 2001. An industrial study of reuse, quality, and productivity.
J. Syst. Softw. 57, 99–106.
Furht, B., 2019. Handbook of internet computing. CRC Press.
A. Rathee and J.K. Chhabra
Gosain, A., Sharma, G., 2017. Object-oriented dynamic complexity measures for
software understandability. Innovations Syst. Softw. Eng. 13, 177–190.
Guerrero-Garcia, J., Gonzalez-Calleros, J.M., Vanderdonckt, J., Munoz-Arteaga, J.,
2009. A theoretical survey of user interface description languages: Preliminary
results, in: 2009 Latin American Web Congress, IEEE. pp. 36–43.
Gui, G., Scott, P.D., 2009. Measuring software component reusability by coupling
and cohesion metrics. JCP 4, 797–805.
Gupta, V., Chhabra, J.K., 2011. Dynamic cohesion measures for object-oriented
software. J. Syst. Architect. 57, 452–462.
Hair, J.F., Ringle, C.M., Sarstedt, M., 2013. Partial least squares structural equation
modeling: Rigorous applications, better results and higher acceptance. Long
Range Planning 46, 1–12.
Harrison, R., Counsell, S.J., Nithi, R.V., 1998. An evaluation of the mood set of object-
oriented software metrics. IEEE Trans. Software Eng. 24, 491–496.
Heng, L., Zhihua, D., Jianzhong, L., Dong, W., Zilong, M., 2020. Parameter estimation
method of experimental data based on grey distance measure. In: 2020 IEEE
2nd International Conference on Civil Aviation Safety and Information
Technology (ICCASIT). IEEE, pp. 438–441.
Hristov, D., Hummel, O., Huq, M., Janjic, W., 2012. Structuring software reusability
metrics for component-based software development. In: Proceedings of Int.
Conference on Software Engineering Advances (ICSEA).
Jendrock, E., Ball, J., Carson, D., Evans, I., Fordin, S., Haase, K., The java ee 5 tutorial.
url:https://docs.oracle.com/javaee/5/tutorial/doc/.
Koteska, B., Velinov, G., 2012. Component-based development: A unified model of
reusability metrics. In: International Conference on ICT Innovations. Springer,
pp. 335–344.
Lau, K.K., Di Cola, S., 2017. An Introduction to Component-Based Software
Development. volume 3. # N/A.
Lau, K.K., Wang, Z., 2007. Software component models. IEEE Trans. Software Eng. 33,
709–724.
Liu, C., van Dongen, B., Assy, N., van der Aalst, W.M., 2018. Component interface
identification and behavioral model discovery from software execution data. In:
2018 IEEE/ACM 26th International Conference on Program Comprehension
(ICPC). IEEE, pp. 97–9710.
Mahouachi, R., 2018. Search-based cost-effective software remodularization. J.
Computer Sci. Technol. 33, 1320–1336.
McIllroy, M., 1968. Mass-produced software components software engineering
concepts and techniques vol 1076 ed buxton jm, nauran p and randell b
petrocelli/charter.
Mehlawat, M.K., Gupta, P., Mahajan, D., 2020. A multi-period multi-objective
optimization framework for software enhancement and component evaluation,
selection and integration. Inf. Sci. 523, 91–110.
Miller, G.A., 1995. Wordnet: a lexical database for english. Commun. ACM 38, 39–41.
Mishra, S.K., Kushwaha, D.S., Misra, A.K., 2009. Creating reusable software
component from object-oriented legacy system through reverse engineering.
J. Object Technol. 8, 133–152.
Mitchell, B.S., 2003. A heuristic approach to solving the software clustering
problem, in: International Conference on Software Maintenance, 2003. ICSM
2003. Proceedings., IEEE. pp. 285–288.
Mitchell, B.S., Mancoridis, S., 2008. On the evaluation of the bunch search-based
software modularization algorithm. Soft. Comput. 12, 77–93.
Mijač, M., Stapić, Z., 2015. Reusability metrics of software components: survey, in:
26th Central European Conference on Information and Intelligent Systems
(CECIIS 2015).
Mohammed, S.W. et al., 2021. Retrieval of software components using nlp based ir
model. Mater. Today: Proc.
Niekamp, R., 2005. Software component architecture, in: Gestión de Congresos-
CIMNE/Institute for Scientific Computing, TU Braunschweig.
Onyango, K.A., Muketha, G.M., Micheni, E.M., 2020. A metrics-based fuzzy logic
model for predicting the reusability of object-oriented software.
5551
Journal of King Saud University – Computer and Information Sciences 34 (2022) 5533–5551
Padhy, N., Satapathy, S., Singh, R., 2018. State-of-the-art object-oriented metrics and
its reusability: a decade review. In: Smart Computing and Informatics. Springer,
pp. 431–441.
Papamichail, M.D., Symeonidis, A.L., 2020. A generic methodology for early
identification of non-maintainable source code components through analysis
of software releases. Inf. Softw. Technol. 118, 106218.
Papamichail, M.D., Diamantopoulos, T., Symeonidis, A.L., 2019. Measuring the
reusability of software components using static analysis metrics and reuse rate
information. J. Syst. Softw. 158, 110423.
Papamichail, M.D., Diamantopoulos, T., Symeonidis, A.L., 2019. Software reusability
dataset based on static analysis metrics and reuse rate information. Data Brief
27, 104687.
Pawar, A., Mago, V., 2018. Calculating the similarity between words and sentences
using a lexical database and corpus statistics. arXiv preprint arXiv:1802.05667.
Rathee, A., Chhabra, J.K., 2018. Clustering for software remodularization by using
structural, conceptual and evolutionary. J. Univers. Comput. Sci. 24, 1731–1757.
Rathee, A., Chhabra, J.K., 2019. Mining reusable software components from object-
oriented source code using discrete pso and modeling them as java beans.
Inform. Systems Front., 1–19
Rathee, A., Chhabra, J.K., 2019. A multi-objective search based approach to identify
reusable software components. J. Computer Languages 52, 26–43.
Rathee, A., Chhabra, J.K., 2019. Reusability in multimedia softwares using structural
and lexical dependencies. Multimedia Tools Appl., 1–22
Rathee, A., Chhabra, J.K., 2020. Identification and construction of reusable
components from object-oriented legacy systems using various software
artifacts. In: Computational Intelligence Techniques and Their Applications to
Software Engineering Problems. CRC Press, pp. 111–135.
Sametinger, J., 1997. Software engineering with reusable components. Springer
Science & Business Media.
Sharma, A., Kumar, R., Grover, P., 2008. Empirical evaluation and validation of
interface complexity metrics for software components. Int. J. Software Eng.
Knowl. Eng. 18, 919–931.
Sharma, A., Grover, P., Kumar, R., 2009. Reusability assessment for software
components. ACM SIGSOFT Software Engineering Notes 34, 1–6.
Shatnawi, A., Shatnawi, H., Saied, M.A., Shara, Z.A., Sahraoui, H., Seriai, A., 2018.
Identifying software components from object-oriented apis based on dynamic
analysis. In: Proceedings of the 26th Conference on Program Comprehension.
ACM, pp. 189–199.
Shatnawi, A., Seriai, A., Sahraoui, H., Ziadi, T., Seriai, A., 2020. Reside: Reusable
service identification from software families. J. Syst. Softw. 170, 110748.
Song, S., Que, Z., Hou, J., Du, S., Song, Y., 2019. An efficient convolutional neural
network for small traffic sign detection. J. Syst. Architect. 97, 269–277.
Sun, L., Huang, G., 2011. Towards accuracy of role-based access control
configurations in component-based systems. J. Syst. Architect. 57, 314–326.
Szyperski, C., Gruntz, D., Murer, S., 2002. Component software: beyond object-
oriented programming. Pearson Education.
Thapar, S.S., Sarangal, H., 2020. Quantifying reusability of software components
using hybrid fuzzy analytical hierarchy process (fahp)-metrics approach. Appl.
Soft Computing 88, 105997.
Washizaki, H., Yamamoto, H., Fukazawa, Y., 2004. A metrics suite for measuring
reusability of software components, in: Proceedings. 5th International
Workshop on Enterprise Networking and Computing in Healthcare Industry
(IEEE Cat. No. 03EX717), IEEE. pp. 211–223.
Weyuker, E.J., 1988. Evaluating software complexity measures. IEEE Trans. Software
Eng. 14, 1357–1365.
Zou, Y., Chen, Y., Gong, K., 2009. Method of determining weights of indices in group
evaluation based on soft sets, in: 2009 Third International Symposium on
Intelligent Information Technology Application, IEEE. pp. 150–153.