See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/342428503

Examining the reuse potentials of IoT application frameworks

Article  in  Journal of Systems and Software · June 2020

DOI: 10.1016/j.jss.2020.110706

CITATIONS READS

7 1,509

3 authors:

Paraskevi Smiari Stamatia Bibi

University of Western Macedonia University of Western Macedonia
6 PUBLICATIONS   21 CITATIONS    67 PUBLICATIONS   1,452 CITATIONS   

SEE PROFILE SEE PROFILE

Daniel Feitosa
University of Groningen
37 PUBLICATIONS   341 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MARS: sMart fArming with dRoneS (NSRF-2018 - RESEARCH - CREATE - INNOVATE) View project

Software Patterns & Refacorings View project

All content following this page was uploaded by Stamatia Bibi on 22 February 2021.

The user has requested enhancement of the downloaded file.

Examining the reuse potentials of IoT application frameworks
Paraskevi Smiari, Stamatia Bibi, and Daniel Feitosa
1
Department of Electrical and Computer Engineering, University of Western Macedonia, Greece
2
Data Research Centre, University of Groningen, The Netherlands
psmiari@uowm.gr, sbibi@uowm.gr, d.feitosa@rug.nl

Abstract: The major challenge that a developer confronts when building IoT systems is the management of a
plethora of technologies implemented with various constraints, from different manufacturers, that at the end need
to cooperate. In this paper we argue that developers can benefit from IoT frameworks by reusing their compo-
nents so as to build in less time and effort IoT systems that can easily integrate new technologies. In order to
explore the reuse opportunities offered by IoT frameworks we have performed a case study and analyzed 503
components reused by 35 IoT projects. We examined (a) the types of functionality that are most facilitated for
reuse (b) the reuse strategy that is most adopted (c) the quality of the reused components. The results of the case
study suggest that the main functionality reused is the one related to the Device Management layer and that
Black-box reuse is the main type. Moreover, the quality of the reused components is comparable to the rest of
the components built from scratch.

Keywords: IoT applications; Reusability; Black-box reuse, White- box reuse effort estimation.

1. Introduction
Over the last decade, the emerging paradigm of the Internet of Things (IoT) dominates the digital transformation
[69] landscape, providing benefits related to better quality of life and greater insight into businesses. The IoT
describes the network of devices that are connected via the Internet, enabling the collection, exchange and analy-
sis of generated information. According to Statista1, by 2025, the total amount of installed IoT devices will reach
75.44 billion worldwide, which corresponds to a fivefold increase compared to the amount of 2015. The next
generation of mobile connection technology, 5G, is expected to boost the application of IoT in everyday life,
further democratizing a range of services [67] that include, among others, healthcare, education, manufacturing
and home automation. IoT is considered as a system of systems that comprises physical things, various commu-
nication channels and a combination of complete software solutions, including data and operations. Hence, man-
aging various hardware, software and network technologies, in order to implement IoT applications, has proven
to be a major challenge for developers.
Given the aforementioned, developing IoT applications with the conventional platforms, is becoming increas-
ingly difficult for developers that lack experience and knowledge [67] in a domain that is still in its infancy. The
main difficulty is that developers need to adapt their applications to multiple platforms and spent effort to learn
and use platform APIs and information models [8]. To deal with this problem literature has suggested the use of
frameworks [1], [12], [64] that are platform independent and consist of highly modularized software building
blocks [28], [51]. Typically, IoT frameworks present a set of common concepts (e.g., Devices, Gateways, Data
Management) [69] that can be reused by developers in order to save time and effort. In the recent years, Open
Source Software (OSS) frameworks have become a key supplier of critical software components [41], dominat-
ing the industry of IoT [1], [56]. Currently there are several available OSS frameworks with big support from the
community that can facilitate reuse in the context of IoT application development. However, as pointed by Chen
et al. [10], the reuse of OSS components encompasses challenges with respect to component selection, compo-
nent integration, and system maintenance [10]. Thus, such endeavor involves three major tasks that the reuser
needs to perform:

1
https://www.statista.com/statistics/976045/iot-revenue-forecast-worldwide/
a) Identify the reusable asset: In this step the reuser has to identify the most suitable asset that implements the
type of functionality she wants to integrate in the new system [41]. According to Schwittek and Eicker, it is of
paramount importance to define the reused functionality based on the application domain [50] where it will be
integrated and the associated requirement [46] that it is intended to fulfill. In the IoT application domain, the
reusable functionalities can be mapped to the layers of the architecture [69] of a typical IoT system. According to
Zimmerman [69], an IoT solution comprises of many devices that communicate through a network and generate
data that are integrated to be managed in the IoT cloud platform and further processed to be presented to the
end-user. All of the above functionalities that are supported by IoT systems require the relevant identification
and access management mechanisms. It is important for the reuser to examine the IoT reuse options based on
the types of functionality that the reusable components offer. For example, it is expected that components related
to Communication Protocols may be more easily available compared to components related to Devices virtual-
ization. Taking into consideration the availability of the reusable resources, the reuser may optimize the reuse
process.
b) Integrate the reusable asset: In this step the developer has to decide upon the strategy for integrating the
reusable asset to the new system. There are several cases where the assets are integrated in the new system simp-
ly as they are, indicating Black-box reuse [16]. In other cases, new functionalities must be implemented on the
reused components for integrating them, indicating White-box reuse [16]. In the latter case it is important to
have an approximation of the effort required to integrate the reused component, which can be measured as the
effort required to apply the changes. In IoT development, due to the large scale of operations when building ap-
plications [56], it is important to know from the beginning the reuse strategy for integrating components based
on the types of functionalities that can be reused. For example, it is highly possible to retrieve Device Manage-
ment components (i.e., Operational components) that can be used as is, whereas Presentation components (i.e.,
Building Charts components) may require a lot of customization and potentially deemed prohibitive.
c) Evaluate the reusable asset: In this step the reuser needs to ensure that the quality of the reusable compo-
nents does not compromise the overall quality of the application [7], [34]. This is particularly important for IoT
application components, since they are expected to possess various quality characteristics that are related to their
ability to be a) extendible [53] so as to handle the variability of heterogeneous devices and technologies, b) flex-
ible [28] so as to easily adapt to changes caused by the external environment and implement new requirements,
c) reusable [31] so as to allow further reuse in future IoT applications, saving time and effort, and d) functional
[8] so as to offer several functionalities through their public APIs. We clarify that other quality attributes, e.g.,
understandability and effectiveness, may also be important [6]. For this purpose, it is important to examine the
quality of the reused components to ensure that they do not deteriorate the quality of the new system.
In this study we examine the reuse opportunities offered by OSS IoT frameworks in order to assist practitioners
in performing the aforementioned tasks for deciding upon the following:
- What functionalities can be reused from IoT frameworks?
- Which reuse strategy should be adopted with respect to the functionality reused?
- What is the quality of the reused components with respect to the functionality reused?
To answer the aforementioned concerns, we have performed a case study on 503 components, originating from 7
different IoT projects coming from the Eclipse IoT framework that has been reused by 35 IoT projects. Eclipse
IoT framework was selected because it is frequently used in research [1], [29], [54], has a strong support from
industrial players like Bosch and QIVICON, and is often reused for building commercial products (e.g., Mixtile
Hub, Coqon). In order to draw conclusions regarding reuse opportunities from IoT frameworks, we have down-
loaded and analyzed the source code of the applications that reused Eclipse IoT frameworks and examined the
components that were reused.
The rest of this paper is organized as follows. Section 2 discusses the related work. Section 3 describes the case
study design whereas Section 4 presents the results obtained from the case study. Section 5 discusses the results
of this case study and Section 6 addresses the threats to validity of the research performed. Finally, Section 7
concludes the paper and presents ideas for future work.

2. Related Work
2.1 Software Reuse
Software reuse is a widely known and used technique for the creation of a new software product that is based on
the adoption of existing software components. Reusable components can bring many benefits in the software
development process some of them being the reduction of cost and effort [62] and the increase of productivity
[34]. Research activities focusing on the advantages of software reuse, have also pointed out that it has a positive
impact in quality [5] and maintainability [34] of the software. Software reuse is also known in literature for the
improvement of software system flexibility [25]. This is achieved through the separation of the stable parts of
systems from the specification of their composition [25]. Improved flexibility has also been identified with the
usage of frameworks as argued by Wang et al. [61] who proposed a framework which aims at assembling com-
ponents in distributed systems. Many research efforts are found in literature examining various aspects of soft-
ware artifact reusability [25]. We will describe these efforts by categorizing them based upon the tasks of the
software reuse process that we referred to in Section 1: a) the reusable component identification b) the reuse
strategy adopted regarding the integration of the component to the target system c) the evaluation of the reused
components.
The first step, when it comes to the reusability of components, is the identification of the appropriate reusable
software component. Research has focused on clustering techniques in order to identify components of similar
functionality and reusability. Such techniques have been thoroughly discussed by Jatain et al. in [25] as well as
Saied et al. [49] who managed to spot reusable components on third party libraries through usage pattern mining.
Automated mechanisms that identify reusable components by searching routines with a specific input have also
been proposed by Podgurski and Pierce [43]. The authors created a method that identifies reusable components
through behavior sampling by giving a randomly chosen sample. When it comes to selecting the most appropri-
ate candidate for reuse research has shown that familiarity with the domain or architecture [58] is a major factor.
Other techniques to prioritize and select the most suitable candidate, besides interoperability [59], is to take into
account the functional and non-functional requirements [59] of the specific domain. By evaluating reusable
components through metrics that indicate the acceptance of a component by the developers [40], we can effec-
tively estimate the reusability, leading to a more suitable selection prior to integrating it.
The next step, after identifying the suitable reusable component, is to integrate it into the target software system.
Ye [63] has mentioned several limitations when it comes to integrating reusable components in a system. These
limitations can be extracted from the environment we want to integrate the component in and such can be the
implementation language, the performance, or the quality. It is observed that in service oriented architectures the
potential in reusability is high because developers often choose to learn an existing service than to implement it
from scratch, thus making it necessary for the existence of an integration framework [68]. Such framework is
presented by Yu et al. aiming at integrating user interface components with the help of a declarative composition
language called XPIL [65] which is based on XML. Although, it is often required to parameterize the reusable
components in order to integrate them in the existing environment [20], research has shown that, by continuously
testing components and recommending those that have the lowest failure rate [27], it can enable the integration
of reusable components especially in an environment that supports continuous integration.
The third step we need to consider, when creating reusable components, is to evaluate the reused component in
terms of quality. A wide range of studies have been performed for assessing the quality of a certain reusable arti-
fact based on structural properties (e.g., encapsulation, coupling and cohesion). Bansiya and Davis [6] proposed
QMOOD, a hierarchical quality model, for assessing the quality of object-oriented artifacts that relates structural
properties to high-level quality attributes (e.g., reusability, flexibility, etc.). Prakash et al. used a suite of metrics
[44], that he divided into procedural and object oriented, based on the classical metrics suite proposed by Chid-
amber and Kemerer [11]. These metrics were also used by Padhy et al. [39] in order to create prediction methods
to spot whether or not components are qualified as reusable. Additionally, reusability indices [2] have been in-
troduced that are based on both non-structural and structural metrics. In this context data mining techniques [44],
[62] have been adopted for evaluating the quality of the reusable assets by taking into consideration several
software quality metrics, some of them being the metrics suite provided by Chidamber and Kemerer [11].
In this study we have selected to adopt the QMOOD model [6] to assess the quality of the reusable components
since it is a model that has been thoroughly used in literature to investigate software quality [13], [37], [38] and
software reusability [3], [4]. Additionally, another motivation for selecting QMOOD [6], is the fact that it pro-
vides 6 indices, Reusability, Extendibility, Flexibility, Functionality, Understandability and Effectiveness that
assess the quality aspects that are of interest in the case of component reuse in the context of IoT [8], [28], [31],
[53].
2.2 Designing IoT applications
In this section we will initially present the typical architectural design of IoT applications and then proceed with
describing the efforts performed for facilitating reuse in the IoT context. Several studies can be found in
literature that propose reference architectures for developing modular and reusable software services for IoT
systems [64], [69]. According to Fremantle [17] an IoT architecture consists of seven layers (see Fig. 1).
The Devices layer, represents a plethora of heterogeneous devices that are connected to the internet usually as
digital twins stored to the cloud. The Communication layer, supports the connectivity of devices through several
communication protocols. The Aggregation/Bus layer works as a gateway for the different devices and enables
the communication between devices as well as bridging and transforming between protocols. The Event
Processing & Analytics layer, represents the data retrieved from the bus layer and stored to the database for
analyzing events. The External Communication layer, indicates the communication achieved outside of devices
with the usage of processing models. The Device Management layer includes all the functions available that
handle devices. Lastly the Identity & Access Management layer, which is responsible for controlling the access
provided, managing different identities and managing the security of the devices and the environment in general.

Fig. 1. IoT reference architecture [17]

The similarities between the different IoT platform architecture models are appointed by Guth et al. [21]. Guth et
al. concluded that the various layers of the different architectures can be mapped to a single abstract reference
architecture. As an example the architecture proposed by Cisco [57] offers similar functionalities and presents
common layers to [17] as the “Communication layer” in Fremantle’s architecture [17] can be mapped to the
“Connectivity” layer in Cisco’s [57]. Another similar architecture is the one proposed by Krčo [30] who suggests
layers such as the “Device” layer. The IoT architecture proposed by Yelamarthi et al. [64] presents a “Sensors”
layer corresponding to the “Devices layer” in [17]. Additionally, the “External Communications layer” [17] can
be found in the “User interface devices” layer in the IoT architecture proposed by Yelamarthi et al [64].
Several researchers adopted the architecture presented in [17] to build IoT platforms. Specifically, Zamfir et al.
[66] proposed a platform for prototyping IoT applications in the healthcare monitoring sector. Additionally,
Neagu et al. [36] focused on creating cloud solutions for IoT in the healthcare sector, introducing a Sensing as a
Service platform. Levina et al. [33] adopted the IoT reference architecture presented in [17] for developing an
intelligent transportation system. The reference architecture proposed by Fremantle was also used as a ground
rule for implementing IoT platforms for Smart Homes by Pessoa et al. [42]. The architecture was chosen due to
its extensibility and modularity while the main goal was to increase specific aspects of smart homes, such as
security.
Reuse potentials in the IoT domain, with respect to the different types of IoT services have been explored by a
few researchers. Katasonov et al., introduced a middleware platform called UBIWARE [26] for supporting the
communication between IoT services. This platform consists of a selection of tools that enable the
implementation of agents and adapters. The middleware is based on the usage of reusable Java components,
which enable communication and collaboration of services in heterogeneous environments. Additionally,
Lazarescu [31], introduced a platform focused on establishing wireless communications in the context of IoT for
achieving low cost and long-term environmental monitoring. The authors defined generic requirements gathered
from different IoT environmental monitoring applications and managed to structure a platform which can be
reused in a wide range of similar long-term environmental monitoring applications. Cicozzi et al. promoted the
reusability of design artifacts in IoT systems through Model Driven Engineering and self-adaptive systems
proposing the MDE4IoT framework [12]. A model-based system was also introduced by Shani and Broodney
who proposed a solution to reuse already existing IoT models [52]. To achieve that the authors adopted semantic
mediation models to spot commonalities between models. Chatuverdi et al. examined the reusability of data
management functionality focusing on reusing streaming dataflows [9]. The authors proposed dataflow reuse
algorithms that identify common tasks that can be reused in order to create a merged dataflow containing all the
streams. Smirek et al. examine possible reusability at the user interface level [55] by comparing two frameworks,
one of which being part of the Eclipse IoT family. The authors examined whether the functionalities of the two
frameworks allow them to create a more abstract and customizable user interface.
Despite the fact that several researchers proposed models and frameworks that can support the reuse in the
specific layers of the IoT applications architecture, the reuse from existing open source frameworks has not been
yet addressed. In this paper we examine the reuse potentials of open source components that are already
available and can support the development of platform independent IoT applications.

3. Case Study Design Evaluation

In this section, we present the design of the case study performed to assess the reusability potentials of IoT
frameworks. We report the details of this case study based on the guidelines of Runeson et al. [48]. Our work
comprises an embedded multiple-case study, where the involved contexts are the different IoT functionality
types, the cases are the IoT projects and the units of analysis are their reused components. Thus, in Section 3.1,
we present the research objectives of the study. In Sections 3.2 and 3.3, we describe the IoT frameworks that
participate in this study and the data collection processes. Finally, in Section 3.4 and 3.5 we provide an overview
of the data and the data analysis process.

3.1 Research Objectives and Questions

The overall goal of this case study is to examine the reuse potentials of IoT application frameworks with respect
to a) the type of functionality that the reused component implements, b) whether customization is required for
integrating the reused component to the target system, and c) the quality of the reused components compared to
the native ones. To ease the design and reporting of the case study, we split the aforementioned goal into three
research questions based on the analysis perspectives that we introduced in Section 1.
(RQ1) Which types of functionality offer the most components in the context of IoT application develop-
ment?
This research question aims at identifying the types of functionalities implemented in IoT frameworks that offer
the larger pool of reusable components. The classification scheme adopted to assess the types of functionalities
was inspired by the architecture proposed by Fremantle [17]. We choose to adopt this architecture model since it
has been used in numerous research activities [36], [42], [66]. Also we believe that the specific reference archi-
tecture presents commonalities with the majority of the rest of the proposed architectures [30], [57], [64] across
literature, thus making it a respectable choice. This architecture defines seven core types of functionalities ac-
cording to the corresponding layers: the Devices layer, the Communication layer, the Aggregation/Bus layer, the
Event Processing & Analytics layer, the External Communication layer, the Device Management layer and the
Identity & Access Management layer [17], [69]. A more detailed presentation of the different functionalities of-
fered by each layer can be found in Section 2 and Fig. 1.
The answer to this research question will provide both researchers and practitioners with an overview of the re-
use potentials offered by each type of functionality. On the one hand, practitioners will be aware of the types of
components that can be more easily found and reused in the context of IoT applications. On the other hand, re-
searchers will be able to identify types of implemented functionalities that are currently sparsely reused, examine
the associated rationale and propose solutions, e.g., to prioritize maintenance and development of new reusable
components.
(RQ2) Do the reused software components require customization?
This research question aims to identify whether or not the reused components are customized when integrated to
the target system and, if customized, to analyze the measured effort. The term customization, in software com-
ponent reuse, refers to the modification of the source code of the reused components so as to fulfill the purpose
of the target system where they are employed [16]. This research question is further decomposed as follows.
RQ2.1 Which reuse strategy (i.e. White-box reuse or Black-box reuse) is adopted when integrating the reused
IoT components to the target application? To answer this RQ we discriminate between white-box reuse and
black-box reuse [23]. White-box reuse according to Ravichandran and Rothenberg [47], [16] allows for the cus-
tomization of the reused artifact while Black-box reuse aims to the direct integration of the artifact based on its
API using software components “as is,” with no code modification.
The analysis in this question will provide an overview of how many of the reused components where customized
(white-box reuse) and how many were not (black-box reuse) per type of functionality. The answer to this RQ is
useful to both researchers and practitioners since it will appoint the types of functionalities that can be reused “as
is”. Such IoT functionalities can be universally standardized in order to allow platforms interworking, a fact that
currently is very important when it comes to IoT application development.
RQ2.2 What is the customization effort required to integrate the reused components in the case of White-box
reuse?
This research question captures the customization effort required for tailoring the functionality of the software
component to fit in the target system when White-box reuse strategy is adopted. We clarify that Black-box reuse
was not considered in this RQ since it requires no modifications [18]. According to Frakes and Terry [16], the
customization effort is the cost associated with the new code, implemented for incorporating the reused code into
the target system. The integration effort, in our case, is measured as the number of source lines of code (SLOC)
for implementing new functionalities related to the reused artifacts. In particular, the effort is calculated as the
SLOC added, deleted or modified in order to customize the original component that exists in the IoT develop-
ment framework to the target system. The use of SLOC is a common practice when measuring the effort required
to implement software within the context of software reuse [19], [45].
The output of this research question will provide insights to practitioners on the effort required, when adopting
White-box reuse for each type of IoT functionality reused.
(RQ3) Do reused components present higher quality compared to the native components in the context of
IoT application development?
This research question aims at investigating if the quality of the reused components is higher compared to the
quality of the native components, in which the reused ones are introduced. The quality of components measured
by assessing six indices of the QMOOD model [6], Reusability, Flexibility, Extendibility, Functionality, Under-
standability and Effectiveness. The QMOOD model was selected since it has widely been used in literature [4],
[13], [37] and it includes a variety of quality aspects that are appointed as important when evaluating IoT appli-
cations [28], [53]. The output of this research question will be a comparison between the quality of the reused
and the native components per type of functionality offered in IoT applications.
The answer to this question will help practitioners evaluate the reused components in terms of quality and guide
maintenance activities in the long-term by prioritizing the maintenance of the ones with lower quality (compared
to the native components). Furthermore, researchers can easily identify components of different functionality
types that are in need for applying methods and tools that improve quality.
3.2 Case Selection and Units of Analysis
This section presents the details of the projects that were selected for examining the reuse potentials in IoT ap-
plications. In this embedded multiple-case study, the involved contexts are the different IoT functionality types,
the cases are the Eclipse IoT projects and the units of analysis are their reused components.
The selected projects are part of the Eclipse IoT framework. Eclipse IoT2 offers 35 open source projects which
implement protocols, services and gateways among others. We addressed reuse opportunities from Eclipse IoT
for a variety of reasons:
 Eclipse IoT projects provide all the benefits of an open source project, that are big embracement from
the community [60] and cost efficiency [35] which renders it a primary choice when it comes to reusing
components for building IoT solutions [8], [52].
 The initiative of Eclipse IoT is supported by many commercial companies (Bosch, Sierra Wireless,
Aloxy, Othermo, IBM and Red Hat) that have adopted these frameworks. This fact shows that this
framework is expected to further attract developers to IoT technologies.
 Eclipse IoT projects are consistently used for empirical research the last years in the context of building

2
https://iot.eclipse.org/,
https://www.eclipse.org/californium/, https://www.eclipse.org/ditto/, https://www.eclipse.org/kura/,
https://www.eclipse.org/leshan/, https://projects.eclipse.org/projects/iot.milo, https://www.eclipse.org/paho/,
https://www.eclipse.org/smarthome/
 cloud services [29], communication protocols [56], enabling solutions for the vehicle domain [24],
providing solutions for manufacturing systems [14].

In this study we aim to analyze components of IoT projects that have already been reused by other projects and
implement the types of functionalities presented in Fig. 1. Therefore, in order to retrieve the reused components,
we considered the following steps.
a) Initially tracked all the Eclipse IoT projects as mentioned in the official website of eclipse IoT2 (35 projects)
b) Searched for Eclipse IoT projects built with Maven, finding 15 of them. We applied this criterion since it pro-
vides an easy mechanism to facilitate reuse between different projects. Moreover, Maven offers detailed reuse
information between software components, i.e., the number of times each package has been reused and the name
of the component that reuses it.
c) Examined if the 15 Eclipse IoT projects have been reused (by inspecting the information provided by Maven).
From these 15 projects, seven of them have been actually reused. For each component in these seven Eclipse IoT
projects, named the “source” components, we recorded:
 The name of the project and the name of the component from Eclipse IoT projects that has
been reused, as the “source component” (in total, 503 components from the seven projects
were analyzed).
 The name of the project and the name of the component that has reused components from
Eclipse IoT projects, the “target” component.

Therefore, only the Eclipse IoT projects that have been reused by other projects were further analyzed, as we
were not able to acquire reuse information for the rest of the Eclipse IoT projects. The seven projects from which
we could extract reuse information are: Californium, Ditto, Kura, Leshan, Milo, Paho and SmartHome. The rest
of the Eclipse IoT projects did not present any reuse instances and therefore excluded from the analysis.
Table 1 presents a summary of the seven IoT projects whose components are reused by other projects. Appendix
A presents a summary of the projects that reuse Eclipse IoT.

Table 1: Eclipse IoT reused projects

Project Description #Classes LoC Releases # Forks # Contributors # Classes reused
by other projects
Californium Devices & services 662 141.118 29 247 49 75
(2015) Communication
Ditto Handles devices 3.361 420.944 14 41 21 25
(2017) heterogeneity
Kura Communication with 1.965 317.578 42 215 38 36
(2014) IoT hardware
Leshan M2M 367 48.849 27 260 25 27
(2015) communication
Milo Data Transfer 1.478 184.368 21 165 18 74
(2017)
Paho Communication of 344 68.626 14 534 41 26
(2013) IoT applications
SmartHome Support of IoT smart 2.197 363.735 4 845 178 240
(2014) home devices

3.3 Data Collection

The dataset used in this study consists of 503 rows, i.e., one for each reused component (a component is
considered to be a class). For every component, we recorded 3 sets of metrics: related to Reuse, Effort and
Quality. We also synthesized these metrics at the project level in order to answer the three research questions.
Table 2 presents the metrics considered within the scope of this study and their description.
In order to collect the data for this study we followed the process summarized in the next steps, also depicted in
Fig. 2.
Step 1: We searched the Maven3 repository for the seven Eclipse IoT projects that were reused (see Table 1).
These projects are considered as the “source” of the reused components. Then we recorded the projects that re-
used the seven Eclipse IoT projects, as reported in Maven. These projects are considered as the “targets” of the
reused components. The output of this step is a list of the “source” and “target” projects.
Step 2: In this step, we downloaded both source and target projects from GitHub. In order to retrieve the reused
classes, we searched all “import” directives in the target projects that included the path to classes of the source
projects. The “import” directives were considered to be reuse indicators of particular classes of the source pro-
jects. The output of this step is the list of the reused components (classes) from the source projects.

Step 3: In this step, we classified the reused components based on the Type of Functionality they offer. The
functionality of each component was mapped to one of the seven architectural layers introduced by Fremantle
[17]. The process for mapping the functionality of each component was based on the keywords presented in Fig.
1. The keywords were selected based on the words (and synonyms) included in the names of the layers of well-
known IoT architectures [30], [57], [64] and the semantics behind every “source” component to further verify
the type of functionality it is meant to implement. For example, the class MqttMessage is part of the implemen-
tation of the MQTT messaging protocol offered by the project Paho. Since MQTT is a protocol that relates to
communications this class will be categorized as part of the Communication layer. The first author of the study
parsed the source code of the components and manually classified each reused component to a type of function-
ality based on the keywords of Fig. 1. In 70% of the cases the classification was easy since the name of the com-
ponent was very representative of its functionality (and usually included as term or sub-term one of the keywords
of Fig. 1). A one-third sample of these cases was inspected by the other authors to ensure consistency. In 30% of
the cases the classification output was not clear. These cases were further discussed among the authors for reach-
ing a consensus. In 5% of these cases there was further discussion and disagreements that were resolved by in-
ternal author voting.

Table 2: IoT source selection metrics

Type of
Metric Description
metric
Development with
Shows if a component has been built with reuse (Yes/No)
Reuse [50]
Devices layer
Communication layer
Aggregation/Bus layer
Reuse Metrics Type of
Event Processing & Analytics layer
Functionality [17]
External Communication layer
Device Management layer
Identity & Access Management layer
Black-box
Reuse Strategy [47]
White-box
= Added SLOC + modified SLOC + deleted SLOC in the components reused by the “target”
Integration Effort projects.
Effort metrics
[19], [45] If the “source” component is reused more than once then the integration effort is calculated as the
average Integration Effort for all the cases that it has been reused.
Functionality [6] 0.12*CAM + 0.22*NOP + 0.22*CIS+0.22*DSC+0.22*NOH
Extendibility [6] 0.5*ANA-0.5 * DCC + 0.5 * MFA + 0.5*NOP
*
Quality Reusability [6] -0.25*DCC + 0.25*CAM +0.5*CIS + 0.5*DSC
Metrics [6] Flexibility [6] 0.25*DAM-0.25*DCC + 0.5*MOA+0.5*NOP
Understandability [6] -0.33*ANA+0.33*DAM-0.33*DCC+0.33*CAM-0.33*NOP-0.33*NOM-0.33*DSC
Effectiveness [6] 0.2*ANA+0.2*DAM+0.2*MOA+0.2*MFA+0.2*NOP

3
https://mvnrepository.com/
 Total number of components reused per Type of Functionality
Reused components (Is calculated as the total number of times the different values of Type of Functionality are observed
for the components where Development with Reuse= “Yes” )
Total number of native components per Type of Functionality
Native components (Is calculated as the total number of times the different values of Type of Functionality are observed
for the components where Development with Reuse= “No” )
Total number of components reused in the form of Black-box Reuse per Type of Functionality
Synthesized
Black-box reuse (Is calculated as the total number of times the different values of Type of Functionality are observed
metrics
for the components where Development with Reuse= “Yes” and Reuse Strategy = “Black-box” )
Total number of components reused in the form of White-box Reuse per Type of Functionality
White-box reuse (Is calculated as the total number of times the different values of Type of Functionality are observed
for the components where Development with Reuse= “Yes” and Reuse Strategy = “White-box” )
=E/L
Reuse Frequency
E= Number of classes that are reused from external sources, in the target system
[16]
L= Total number of classes in the target system

*Metrics and indices coming from QMOOD model

CAM = Cohesion Among Methods of Class
NOP = Number of Polymorphic Methods
CIS = Class Interface Size
DSC = Design Size in Classes
NOH = Number of Hierarchies,
ANA = Average Number of Ancestors
DCC = Direct Class Coupling
MFA = Measure of Functional Abstraction
DAM = Data Access Metric
NOM = Number of Methods
MOA = Measure of Aggregation [6]

Step 4: In this step, we classified the Reuse Strategy into Black-box reuse or White-box reuse [47]. By Black-
box reuse we mean an instantiation of a new object from the reused class or the utilization of a parameter or
function of a reused class that has not been subject to changes [47]. White-box reuse refers to the extension of
the reused class by adding new functionalities or implementing existing definitions [47]. To define the type of
reuse we analyzed the project’s dependency tree to identify the system files (.class) that exist in compiled pack-
ages projects that are downloaded from the Maven repository. The identification of the original Eclipse IoT re-
used components relied on the naming of the system class. We searched each one of these classes in the source
code of the “target” projects, and when we identified class extensions in a project, we marked them as White-box
reuse. We also searched the target system for the keywords “extends” or “implements” or “override” in methods
that could indicate the addition/implementation/modification of a class. The remaining Eclipse IoT classes in the
“target” projects were considered to be Black-box reuse (since they were not extended/modified in target source
code).
Step 5: Next, in the case of White-box reuse we recorded the Integration Effort required to customize the reuse
component to the target system. The Integration Effort is measured as the source lines of code (SLOC) devel-
oped for integrating the reused component. For this purpose, we recorded the SLOC developed in the case of
White-box reuse. In particular, we used a diff tool 4 (for comparing source code delta) to assess the number of
lines added, modified and deleted between the original component and the reused one. In most of the cases of
White-box reuse, functionalities were added by either extending a parent class, implementing an interface or
overriding a method.
Step 6: As a final step, we recorded the Quality of both the reused components and the native components, i.e.,
classes of the target system that were built from scratch. In this step, we analyzed the dependency tree of each
“target” project to identify if a class has been reused or it is built from scratch (native). First, we marked as re-
used all systems classes (.class files) that exist in the compiled packages of the “target” projects that are down-
loaded from the Maven repository. The identification of the original Eclipse IoT reused components relied on the
naming of the system class and the extended classes relied on the process described in Step 4. There were also
other native components reused from Maven repository, which did not originate from the Eclipse IoT project that

4
https://www.jetbrains.com/help/idea/comparing-files-and-folders.html
were excluded from the analysis. All other classes of the built projects (i.e., other than reused ones) are tagged as
native. The quality of the components was assessed by utilizing the QMOOD model [6] and Percerons5 tool. In
particular, we calculated the following quality indices:
- Functionality indicates the level at which a class provides operations to other classes.
- Extendibility indicates the level at which code can be expanded to accommodate new requirements.
- Reusability indicates the level at which code can be applied to different contexts.
- Flexibility indicates the level at which code can be altered to be adapted into different contexts.
- Understandability indicates the level at which code can be comprehended
- Effectiveness indicates the level at which code can perform specific operations successfully

Fig. 2. Case selection process

3.4 Data Analysis

The data analysis of this case study includes the calculation of a) the frequency and descriptive statistics of reuse
properties across the different types of IoT functionality and b) the application of Significance tests for checking

5
https://extreme.se.uom.gr/
whether the differences across reused functionality types are significant. In the case of applying Significance
tests we initially performed a Shapiro-Wilk test in order to investigate whether our data are normally distributed.
Since the test indicated that our data are not normally distributed, we then used non-parametric tests (Kruskal-
Wallis H test and a Mann-Whitney U test) considering the fact that our data set satisfies the following assump-
tions:
 the dependent variables are either continuous or ordinal
 the independent variables consist of two or more categorical and independent groups.
- In the case where the groups are only two the Mann-Whitney U test is performed
- Otherwise the Kruskal-Wallis H test is performed
 we have independence of observations, since our data consist of different projects that reuse different
components

For RQ1, we provide the descriptive statistics (Mean, Min, Max, St. deviation) and performed a Kruskal-Wallis
H test ( ( ), ) to check the difference between the level of reuse across different functionality types. The de-
pendent variables consist of the No of Reused components and the No of Native components whereas the inde-
pendent variable is the Type of functionality. Additionally, we also calculated the corresponding statistics for the
components that are native (they are built from scratch) in the “target” projects. Among the variables that are of
interest in this question is the Reuse Frequency (see

Table 2) that is an indication of the level of reuse in the “target” system.

Concerning RQ2, we provide the descriptive statistics (Mean, Min, Max, St. deviation) related to the total num-
ber of times where the two different reuse strategies are observed (Black-box reuse, White-box reuse). We also
provide the corresponding frequency of the two types of reuse strategy in the form of a bar chart. We then per-
form a Mann-Whitney U test (U, p) to check whether the difference between the two reuse strategies is signifi-
cant with respect to the functionality type of the reused component. The dependent variable is associated with
the Type of Functionality while the independent variable consists of the Black-box and White-box type of reuse.
Additionally, in the case where White-box reuse is observed we also provide the related descriptive statistics
(Mean, Min, Max, St. deviation) regarding the Integration Effort required to customize the component to the
“target” class and perform a Kruskal-Wallis H test ( ( ), ) to check the difference between the effort across
different functionality types. In this case, the dependent variable is attributed as the Integration Effort whereas
the independent variable is considered to be the Type of Functionality.
Similarly, in RQ3, we provide the descriptive statistics (Mean, Min, Max, St. deviation) related to the quality
attributes (Extendibility, Flexibility, Reusability, Functionality, Understandability, Effectiveness) of both the
reused components and the native ones of the “target” projects. Then we perform a Mann-Whitney U test (U, p)
to check whether the difference between the quality in the reuse and the native components is significant. The
dependent variables refer to the Reusability, Functionality, Flexibility, Extendibility, Understandability and Ef-
fectiveness while the independent variable consists of the Reused and the Native components)
In Table 3 we provide an overview of the data analysis methods employed per research question.

Table 3. Data analysis overview

RQ Variable Analysis Calculations
Dependent Variables: Descriptive statistics Mean, Min, Max, Std.
No of Reused components, No of Native components Dev, Reuse Frequency
RQ1
Independent Variable: Kruskal-Wallis H Test ( ),
Type of functionality
Dependent Variables: Descriptive statistics Mean, Min, Max, Std.
RQ2.1 Type of functionality Dev
Independent Variable: Bar Chart Frequencies
 Black-box reuse, White-box reuse Mann-Whitney U Test ,
Dependent Variables: Descriptive statistics Integration Effort, Min,
Integration Effort Max, Std. Dev
RQ2.2
Independent Variable: Kruskal-Wallis H Test ( ),
Type of functionality
Dependent Variables: Descriptive statistics Mean, Min, Max, Std.
Reusability, Functionality, Flexibility, Extendibility, Dev
RQ3 Understandability, Effectiveness Mann-Whitney U Test ,
Independent Variable:
Reused components, Native components

3.5 Data Overview

In this section, we present an overview of the data used in the study. First, we categorized the data into reused
and native components. Next, we calculated the descriptive statistics that give us an overview of the data as
presented in detail in Table 4 and Fig. 3. When focusing in White-box reuse the average integration effort that is
required is 214.18 lines of code. Additionally, the Reusability appeared to have a higher average value in the
reused components compared to the other metrics, whereas Understandability appeared to have the lowest. As
for the native components, Flexibility, Extendibility and Understandability appear to have higher mean values
compared to the reused components.

The total components from the “target” projects that were found in each Type of Functionality are presented in
Fig. 3 and each bar is split into the total percentage of native and reused components that were found in each
type respectively. Although in total multiple components target the External Communication layer (27.1%), the
Communication layer (22.6%) and the Event Processing & Analytics layer (22.4%), we observed that the
Devices and Device Management layer appear to be reused more than the rest of the layers, with 70% and 11%
of the components being reused respectively. This finding is intuitive since, when referring to the Reused
components per Type of Functionality (see Fig. 3), selecting components that will enable building and handling
diverse devices without the need to rewrite functionality is of high importance in IoT projects and thus, the
Devices (70%) and the Device Management layers (11%) appear to have more instances.

Furthermore, the Devices layer appears to be the lowest in total components, which is understandable since this
category refers to lower level devices and sensors and it would not be a point of interest in some of the projects.
However, there are more reused components (70%) than native components (30%). On the contrary, the
Communication, the Event Processing & Analytics and the External Communication layers appear to have the
lowest amount of reused components (2%) compared to the native ones, which suggests that these components
are much more often rewritten.

Table 4. Data overview

Reused Native
White box Black box
Min Max Mean St. Min Max Mean St. Min Max Mean St.
Dev Dev Dev
27 1421 214.18 203.2 - - - - - - - -
Integration effort
7
Reusability 0.25 90.73 13.23 12.99 0.25 67.78 8.75 10.10 0.25 422.79 3.98 9.64
Flexibility -0.25 1.00 0.27 0.16 -0.25 2.24 0.32 0.39 -0.25 114.75 0.60 1.84
Functionality 0.32 42.07 6.46 6.31 0.1 36.35 4.17 5.00 0.10 209.68 1.90 4.75
Extendibility -0.32 1.51 0.49 0.36 -0.54 3.5 0.43 0.49 -25.06 116.5 0.89 2.15
Understandability -61.71 -0.33 -9.30 8.68 -45.32 -0.33 -5.25 6.20 -157.29 0.00 -3.60 6.01
Effectiveness -0.20 0.87 0.55 0.15 -0.2 2.0 0.41 0.32 -0.20 46.40 0.52 0.89
 Fig. 3. Type of functionality of reused and native components bar chart

4. Results

In this section, we present and interpret the results of this case study, organized by research question and based
on the data analysis presented in Section 3.4.

4.1 RQ1 – Which types of functionality offer the most components in the context of IoT application develop-
ment?
To address this research question, we provide the descriptive statistics of the reused components per type of
functionality (see Table 5) and examine the reuse potentials, per type of implemented functionality, of the reused
components. Table 5 presents the summary statistics for the seven types of functionality offered by the Eclipse
IoT projects. It can be observed that most reused components (see Mean– column 2) offer functionality related to
the Device Management layer. Such functionality includes standard operations for handling IoT devices, e.g.,
configuration, remote management, provisioning, maintenance and monitoring. External Communication com-
ponents are also reused frequently, offering functionality related to the communication of IoT devices with the
applications that handle the derived data, e.g., wrappers, APIs and clients.

In terms of highest reuse frequency (see the rightmost column in Table 5), we notice that Device layer is the
most recurrent type. The components that implement functionality related to this layer usually represent the dif-
ferent kinds of hardware equipment that can be used in the context of IoT, from the more abstract form (“thing”)
to the more specialized form (e.g., sensors, actuators and mobile devices). Moreover, we find components that
represent device properties like operational range, lifespan, etc. Overall, it seems that practitioners seek to reuse
high-level IoT functionality such as the representation and management of devices. This can be interpreted intui-
tively, as these functionalities are context-free and are more likely to be reused [14]. Therefore, we summarize
that device functionalities share commonalities that can be reused and additionally present the same management
requirements.

The least reused components are related to the Identity & Access Management layer and to the Communication
layer. We observe that practitioners tend to reuse fewer of such components probably because they are consid-
ered to be safety-critical for IoT applications that need to avoid third-party attacks [28], ensuring the smooth
operation of the devices. Moreover, components that implement context-aware functionalities (e.g., communica-
tions and aggregation) are highly dependent on the protocol that a device (and its manufacturer) can support and,
thus, are less reused. Also, such functionalities are commonly implemented from scratch [12], as they need to be
configured based on the specific requirements and deployment details of a particular IoT application and its re-
strictions in terms of hardware and communication protocols. To investigate if the aforementioned differences
are statistically significant, we performed a Kruskal-Wallis H test, which suggested that there are significant
differences in the reusable components of the different types of functionality (x^2 (6) = 38.59, p= <0.001).

Table 5: Reuse per type of functionality

Type of functionality Reused Components Native Components

Frequency
St. Dev

St. Dev

Reuse
Mean

Mean
Max

Max
Min

Min

Devices 6.81 1 45 8.63 7.66 1 18 9.07 0.88

Communication 4.43 1 27 4.27 66.63 1 1315 160.54 0.06
Aggregation/Bus 5.16 1 20 4.21 64.57 1 1203 142.33 0.08
Event Processing & Analytics 5.05 1 39 5.16 63.49 1 2897 266.96 0.08
External Communication 7.07 1 98 11.4 48.75 1 1130 96.47 0.15
Device Management 9.31 1 93 10.3 27.89 2 181 27.33 0.33
Identity & Access Management 2.95 1 9 2.14 31.50 1 190 42.02 0.09
Kruskal-Wallis H test (6) = 38.59 = <0.001

4.2 RQ2 – Do the reused software components require customization?

In this section, we first present and interpret the results regarding the reuse strategy that is mostly adopted,
differentiating between Black-box reuse and White-box reuse. Next, we focus on White-box reuse and examine
the integration effort required to customize the reused component to the target class.

4.2.1 RQ2.1 - Which reuse strategy (i.e., White-box reuse or Black-box reuse) is adopted when integrating the
reused IoT components to the target application?

In Fig. 4, we present the type of Reuse Strategy employed per type of functionality. The results suggest that most
of the components are integrated in the “target” project in the form of Black-box reuse (72.6%). As we can ob-
serve in Fig. 4 and Table 6, the Device Management components are, on average, mostly reused “as is” (i.e.,
Black-box reuse). Moreover, White-box reuse was required in 27.4% of the components. To investigate if the
aforementioned differences are statistically significant, we performed a Mann-Whitney U test, which suggested
that there are significant differences in the different types of reuse in terms of the different types of functionality
for all the types of functionality.
Black-box reuse is the dominant form in third-party IoT components (i.e., not developed in-house), which can be
interpreted in two ways. On the one hand, practitioners may not be willing to devote effort and time to under-
stand the reused components and, therefore, they select components that can be reused as is. This interpretation
is in accordance with related work that also appoints the dominance of Black-Box reuse in the case of reusing
third-party, open source software components [22]. On the other hand, the reused components offer core func-
tionality (i.e., Device Management layer), which is the least likely to require changes. For example, general pur-
pose components like the ones representing devices, communication protocols, management operations or stand-
ard cryptography algorithms are the least likely to require changes.

Identity and Access layer

Device Management layer
External Communication layer
Event Processing and Analytics layer % black box
Aggregation/Bus layer % white box
Communication layer
Devices layer

0.0% 20.0% 40.0% 60.0% 80.0% 100.0%

Fig. 4. Reuse Strategy per Type of Functionality

Table 6: Type of Reuse per type of functionality

Type of functionality Black-box reuse White-box reuse
Mean Min Max St.Dev Mean Min Max St.Dev
Devices 6.67 1 45 8.26 1.55 1 4 1.13
Mann-Whitney U test = 69.500 = 0.001
Communication 4.34 1 26 4.15 1.02 1 2 0.16
Mann-Whitney U test = 871.000 = <0.001
Aggregation/Bus 4.72 1 19 3.89 1.26 1 3 0.51
Mann-Whitney U test = 2718.000 = <0.001
Event Processing &Analytics 4.66 1 38 4.75 1.18 1 4 0.51
Mann-Whitney U test = 1927.500 = <0.001
External Communication 6.70 1 96 11.07 1.43 1 5 0.82
Mann-Whitney U test = 1671.500 = <0.001
Device Management 8.71 1 91 9.90 1.27 1 5 0.60
Mann-Whitney U test = 10610.500 = <0.001
Identity & Access Management 2.70 1 9 2.15 1 1 1 0.00
Mann-Whitney U test = 12.000 = 0.012

4.2.2 RQ2.2 - What is the customization effort required to integrate the reused components in the case of White-
box reuse?
To investigate the effort required for the integration of the components with respect to the different types of re-
used functionality, we calculated the descriptive statistics and performed a Kruskal-Wallis H test for the variable
Integration Effort, but only for the cases where the reuse type is White-box. The summarized results are present-
ed in Table 7.
We observed that the type of functionality that requires the greatest effort on average, in the case of White-box
reuse, regards the Device Management layer. This result can be interpreted intuitively since components in this
layer are responsible for supporting specific smart devices. As IoT frameworks focus on accommodating a sub-
stantial range of devices [67], it is expected that such reusable components (from the framework) are quite ge-
neric and would require a significant amount of code to fully characterize the smart devices.
Additionally, we found that components implementing functionality related to the Identity & Access Manage-
ment layer are the ones that required the least integration effort. This finding suggests that the implemented
standards are most often sufficient (e.g., in terms of reliability and security) for the target applications, which is
understandable as the authorization standards and protocols are becoming widespread across various industries
and application domains [32], also enabling more complete off-the-shelf components.

Table 7: Effort required to integrate the reused components per type of functionality

Type of functionality Integration Effort Std. Dev Min Max

Devices 159.42 111.74 60.00 394.00
Communication 192.84 178.17 27.00 944.00
Aggregation/Bus 162.53 100.29 27.00 781.00
Event Processing & Analytics 127.86 91.86 44.00 553.00
External Communication 223.53 214.06 27.00 968.00
Device Management 264.26 244.76 42.00 1421.00
Identity & Access Management 83.00 25.85 61.00 119.00
Kruskal-Wallis H test (6) = 41.826 = <0.001

4.3 RQ3 – Do reused components present higher quality compared to the native components in the context of IoT
application development?

In Table 8 we present the results regarding the quality of the reused components. For this research question, we
examined the offered functionalities by assessing the six quality indicators defined in the QMOOD model [6],
i.e., Reusability, Flexibility, Functionality, Extendibility, Understandability and Effectiveness. Overall, it is
observed that reused components present higher quality in terms of Reusability and Functionality. This is
expected since the reused components come from the Eclipse IoT development framework that is built to
facilitate reuse and offer abstractions that will help developers adopt functionalities that are typical to the
particular application domain such [29], [56].
In terms of Flexibility, Extendibility and Effectiveness, the reused components present similar values to native
components, suggesting that reusing IoT components does not jeopardize the quality of the target system. This
result is also verified by Feitosa et al. [15] who argue that reused components present similar maintainability
compared to native ones. In terms of Understandability, the reused components appear to more comprised than
native ones. This result is expected since the metric used for the calculation of Understandability considers that
inheritance and polymorphism have a negative effect on Understandability [6]. Since the components under
study support the representation of abstractions to a great degree, the reusable code is considered to be less un-
derstandable. However, we argue that this result can be counterbalanced by the fact that the reusable compo-
nents, and the projects hosting them, usually provide a very detailed documentation that is considered to affect
implicitly the Understandability [41]. Table 8: Quality of the Eclipse IoT projects and destination components per type
of functionality offered

Reusability Flexibility Functionality Extendibility Understandability Effectiveness

Reused

Reused

Reused

Reused

Reused

Reused
Layer

Native

Native

Native

Native

Native

Native

Mean 6.2 2.0 0.2 0.08 2.9 0.9 1.8 0.5 -4.3 -1.8 0.5 0.1
Min 3.5 0.8 0.2 0.0 1.6 0.3 0.5 0.0 -4.6 -2.6 0.4 0.0
Devices

Max 6.8 3.6 0.3 0.3 3.2 1.6 0.9 1.5 -3.2 -1.0 0.6 0.2
St.dev 1.2 1.4 0.01 0.1 0.6 0.6 0.2 0.9 0.6 1.1 0.05 0.1
= 1.000 5.500 1.000 10.000 0.000 0.000
 = 0.007 0.029 0.007 0.334 0.011 0.011
Mean 6.1 4.4 0.6 0.6 2.8 2.1 0.3 1.2 -3.8 -4.2 0.3 0.7
Communication

Min 0.3 0.3 -0.3 -0.3 0.1 0.1 0.0 -25.1 -17.5 -153.5 -0.2 -0.2
Max 34.0 138.0 2.2 114.8 17.2 101.4 3.0 116.5 -0.3 0.0 2.0 46.4
St.dev 7.3 7.9 0.5 2.8 3.6 4.0 0.6 3.1 3.8 6.7 0.4 1.3
= 76908.500 100500.500 81414.500 74121.000 91997.000 75676.000
= <0.001 0.629 0.001 <0.001 0.704 0.003
Mean 9.2 4.5 0.4 0.4 4.5 2.3 0.4 1.5 -5.7 -4.3 0.5 0.7
Aggregation/

Min 0.3 0.3 -0.3 -0.2 0.3 0.1 0.0 -0.5 -26.7 -51.2 -0.2 -0.2
Max 39.9 282.0 2.2 36.2 19.4 154.7 3.5 36.5 -0.3 0.0 1.6 14.4
Bus

St.dev 10.5 10.8 0.4 2.4 5.3 5.8 0.6 2.8 5.9 5.4 0.3 1.2
= 1210.500 2481.500 1230.500 3201.000 17767.000 21522.500
= <0.001 0.035 0.001 0.205 0.006 0.345
Mean 9.8 3.4 0.3 0.5 4.7 1.6 0.5 1.1 -4.0 -3.6 0.4 0.6
Event Processing

Min 0.3 0.3 -0.3 -0.3 0.1 0.1 0.0 0.0 -14.8 -58.7 -0.2 -0.2
& Analytics

Max 34.0 75.5 2.2 11.3 17.2 34.5 2.0 11.5 -0.3 0.0 1.4 6.2
St.dev 9.1 5.4 0.4 0.8 4.5 2.4 0.4 1.4 3.3 4.1 0.3 0.6
= 34767.500 63182.500 34580.500 63405.500 47513.000 47701.500
= <0.001 0.029 <0.001 0.029 0.135 0.143
Mean 7.6 4.0 0.2 0.6 3.6 1.9 0.3 0.5 -4.4 -3.2 0.3 0.4
Communication

Min 0.3 0.3 -0.3 -0.3 0.1 0.1 -0.3 -0.6 -45.3 -157.3 -0.2 -0.2
External

Max 67.8 422.8 1.3 38.8 36.4 209.7 1.5 40.0 -0.3 0.0 0.6 15.8
St.dev 12.1 11.7 0.4 1.4 6.1 5.6 0.4 1.6 8.5 6.5 0.2 0.7
= 103420.000 114031.000 102754.000 140076.500 99368.000 105025.000
= <0.001 <0.001 <0.001 0.105 0.137 0.350
Mean 14.4 3.3 0.3 0.1 7.0 1.5 0.6 0.3 -10.0 -4.8 0.6 0.2
Management

Min 1.1 0.3 -0.2 -0.3 0.6 0.1 -0.5 0.0 -61.7 -12.6 0.4 -0.2
Device

Max 90.7 12.0 1.0 0.8 42.1 5.3 1.5 1.5 -1.7 -1.0 0.9 0.6
St.dev 13.3 2.7 0.1 0.3 6.4 1.2 0.3 0.4 8.8 4.0 0.1 0.2
= 299.000 721.500 286.000 723.000 605.000 94.500
= <0.001 0.001 <0.001 0.001 0.001 <0.001
Mean 7.0 3.5 0.5 0.5 3.2 1.6 0.7 0.5 -5.0 -3.3 0.5 0.4
Identity &

Min 1.1 0.3 -0.3 -0.3 0.5 0.1 0.0 0.0 -16.8 -31.7 -0.2 -0.2
Access

Max 23.0 31.0 2.2 3.3 10.6 13.7 1.0 4.0 -0.3 0.0 2.0 2.0
St.dev 6.2 4.9 0.5 0.5 2.9 2.2 0.4 0.7 4.4 4.2 0.5 0.3
= 1515.500 2563.500 1652.000 3240.000 2108.500 2899.500
= <0.001 0.017 <0.001 0.641 0.018 0.911

5. Discussion
In this section, we illustrate the relevance of our findings through an example use case involving a reuse decision
making process in the context of an IoT application development. Additionally, we interpret the results obtained
by this case study and elaborate on implications to both researchers and practitioners.

5.1 Applicability of empirical findings

In Section 1, we described three major tasks of the reuse process, i.e., a) identify the reusable asset, b) integrate
the reusable asset and c) evaluate the reusable asset. In this section, we elaborate on an example decision making
process, presenting the data that would guide it. To that end, in Table 9 we rank the different functionality types
for each metric considered in this study, which are grouped according to the three major tasks. For example,
when identifying reusable assets (wondering “what to reuse?”), one may look into the reuse frequency metric
(column RF) and check the top three reused functionalities, finding that components related to the Devices, the
Device Management and the External Communications layers are more commonly reused. To help the reader
further, we provide examples of popular components on the right side of Table 9.
In our example, the reuser intends to develop a small-scale Smart Home application that will manage a set of
smart lamps manufactured by different companies. The goal is to create a holistic solution exploiting the existing
reusable components that are freely available, which will be configured to meet the needs of a Smart Home.
Table 9. IoT component reuse ranking
Task | Relevant Question | Metrics
Identification Integration Evaluation
What to Does it need
What is their quality?
reuse? customization?

Understandability
Integration Effort

Functionality
Extendibility

Effectiveness
components
Example of Popular

Reusability
White-Box

Black-Box

Flexibility
Functionality
Reused Component
#Reused
RF

Devices 1 3 1 3 3 6 7 6 1 2 2 Thing
Communication 7 6 6 4 5 7 1 7 6 1 6 NetworkService
Aggregation/Bus 6 4 4 6 4 3 3 3 5 6 3 MQTTActionListener
Event Processing & 5 5 5 5 2 2 4 2 4 4 5 MemoryPersistence
Analytics
External Communication 3 2 2 2 6 4 6 4 7 3 7 ChartProvider
Device Management 2 1 3 1 7 1 5 1 3 7 1 OnOffStatus
Identity & Access 4 7 7 7 1 5 2 5 2 5 4 AuthorizationModelFactory
Management

Based on Table 9 and the architecture model of Fig. 1, the developer should start by reusing components from
the Devices layer. The Devices layer implements the lower level components of the architecture representing the
devices around which the developer will build a centralized solution. These components present the highest
reuse frequency and also possess the highest Extendibility. Additional components implementing Device
functionality may need extra coding since these components are often integrated via White-Box reuse in the
target system. However, the expected necessary effort is not that high.
The next step is to implement functionality related to the management of the devices (such as turn the lights
on/off, change their color, or update their firmware) by reusing components from the Device Management layer.
These components are top-ranked in terms of Reusability, Functionality, Effectiveness and reuse frequency,
making them the perfect candidates to manage all the functionalities performed by the IoT devices. Moreover,
most of these components are integrated via Black-box reuse. However, if additional code is required (i.e.,
White-box reuse), the developer should be aware that this integration can be costly since they depicted the
maximum effort.
In order to facilitate the Communication of the smart lamps, some basic components can be reused for the
protocol that each device supports. These components are highly ranked in terms of Flexibility and
Understandability, allowing for the implementation of a uniform communication solution that will accommodate
the diversity of protocols successfully. However, these components are not reused frequently and, thus, the
reuser may need to search carefully to identify the appropriate components for reuse. Furthermore, a special
focus is given to reusing Aggregation/Bus components since they are responsible for bridging the different
devices. The smart lamps are from different manufacturers and, therefore, we need to write extra native code to
provide a more uniform solution. Fortunately, these components appear to be highly ranked for most quality
attributes.
The next step is to handle all the data retrieved from our smart lamps (e.g., energy consumption). Components
related to Event Processing & Analytics, such as general purpose data storage and retrieval procedures, can be
reused in our example. However, since we want to satisfy specific use cases like identifying peaks of energy
consumption, we would choose to expand these components by writing our own algorithms and automations
from scratch. The same goes for the Identity & Access Management layer, in which we reuse components for
already existing solutions (e.g., authentication), but we also expand them by writing native code in order to have
an application that will be configured based on our specific needs (e.g., customized security).
In the end, we structure the entire solution by reusing components related to the External Communication layer,
providing functionalities related to data visualization, such as charts. We also need to implement native code, as
we want to satisfy certain use cases that cannot be fulfilled through reuse, such as combining UI components to
create a better user experience. This layer appears to have quite high Understandability, which is what we are
looking for when creating a system that can be easily configured to meet the users’ needs.

5.2 Implications to researchers and practitioners

The results of this study provide useful information and guidance to practitioners on planning the reuse of com-
ponents in the context of IoT application development. In particular, some take away messages that we can pro-
vide based on our case study are:
• When identifying reuse opportunities, Engineers of IoT can greatly benefit from reusing a core set of
general purpose components, which in our case regard the Event Processing & Analytics layer and the
Devices layer. These components, in their majority, can be reused as is without requiring any integra-
tion effort.
• Regarding the integration of reused components, we highlight that although components from the De-
vice Management layer are heavily reused (and necessary), they may require a substantial integration
effort, which should be factored in the design and implementation phased of an IoT application.
• Regarding the evaluation of reusable assets, we mainly found that reuse in the context of IoT develop-
ment seems not to jeopardize the overall quality of the IoT system while also improving its reusability
and functionality.
Based on the results of this case study, we encourage researchers to:
• Further explore the reuse of components in the context of IoT application development by examining
other Open Source projects. Researchers can investigate whether the same type of components, as ap-
pointed by this study, have been systematically reused.
• Introduce a process for systematic, planned reuse of IoT components. Such a process would define
clear procedures for: (a) identifying and sorting the reusable components, (b) integrating the reused
components into the new applications and (c) maintaining these components.

6. Threats to Validity
To conclude this section, we refer to the threats to validity of this case study divided by construct, internal, relia-
bility and external aspects [48]. Construct validity defines how effectively a test or experiment measures up to its
claims. Internal validity is related to the examination of causal relations examining whether an experimental en-
vironment is adequate to support the claim. External validity examines whether the results of a study can be gen-
eralized to other cases. Reliability is associated to the reproducibility of the study, i.e., the ability of other re-
searchers to repeat the same process, collect data and reach the same results.
 A possible threat to construct validity is related to the metrics that are used to answer our research questions.
Since, to our knowledge, there are not any studies available in literature examining the reuse potentials from IoT
development frameworks, we selected the metrics based on general purpose studies examining software reuse
metrics [16], models [50] and strategies, [47]. Each metric selected in this study is based on the relevant
reference from existing literature. With respect to the synthesized metrics (Reused components, Native
components, Black-box reuse, White-box reuse) we selected to use these metrics in order to be able to map the
reused components to the type of IoT functionality that they serve. Regarding the effort metrics, we believe that
the lines of code are indicators of the effort required to integrate the reused components. This metric has been
also adopted in [19] and [45] for assessing the reuse effort. Moreover, since the scope of the study is to compare
customization effort between reusable components that offer different functionalities and not to provide a typical
reuse effort estimation model, we believe that this metric is an indicative for comparing the difference between
the customization effort of reusable components. Nevertheless, we acknowledge that there are other metrics that
can also be used. Concerning the type of functionality, we based our categorization on the reference architecture
proposed by Fremantle [17]. The specific architecture was chosen a) considering its high adoption by other
research practitioners in literature [36], [42], [66] and b) considering its high coverage in IoT architecture aspects
[30], [57], [64]. We acknowledge though, that the choice of the reference architecture model may alter the
observed results. For the quality assessment of the reused components, we have used QMOOD model [6], which
is an established quality model that has been rigorously validated and reused in literature [4], [13], [37].
However, we acknowledge that other quality models could lead to variations in the observed results.
Regarding internal validity, the proposed study attempted to form an association between a) the reuse strategy
and the type of functionality implemented by the reused components and b) the quality characteristics (such as
flexibility, reusability, functionality, extendibility, understandability and effectiveness) and the type of function-
ality implemented by the reused components. We cannot claim that this association forms a causal relationship
between the type of functionality of the reused components and the reuse strategy adopted or the quality of the
components. The results just indicate trends and common practice when it comes to selecting and integrating
components in the context of IoT application development. Some of these trends can be verified intuitively while
others may be surprising.
With regard to reliability, we believe that the followed research process ensures the replication of our study. The
process that has been followed in this study has been thoroughly documented in the case study design, provided
in Section 3. In addition, the extraction of the data and the associated structural metrics was performed with the
help of the publicly available tools (Maven repository, Github, Percerons) and therefore any interested researcher
can repeat the analysis and derive the same results. We acknowledge though potential researchers’ bias during
the data collection due to the manual classification of components into types of functionality performed by the
first author. The first author of the study parsed the source code of the components and classified each reused
component to a type of functionality based on the keywords of Fig. 1. In most of the cases the classification was
easy since the name of the components clearly indicated its function. For these case, one-third of the sample
were inspected by the other authors to ensure consistency. Additionally, the classification was not straightfor-
ward in 30% of the cases, in which scenario all authors discussed to reach consensus.
Finally, we acknowledge that the external validity, is threatened by the fact that the data set examines a subset
of IoT reuse opportunities coming from the 7 projects supported by Eclipse IoT framework. Since we wanted to
measure actual reuse opportunities, as observed in practice with the help of Maven repository statistics, we were
forced to select only frameworks whose components were reused by other projects. In Maven Repository we
were able to retrieve other reused frameworks, such as Microsoft Azure IoT, Amazon SDKs but we made the
choice not to analyze frameworks that are platform specific, compromising the interoperability of the applica-
tions. Therefore, concerning the generalizability, we can say that a replication of the analysis performed in this
study to other IoT frameworks would be useful for further generalizing the results regarding reuse opportunities
in the IoT development context.

7. Conclusions
In this paper, we explored the reuse opportunities stemming from 7 popular projects coming from the Eclipse
IoT framework for building IoT applications. We performed a case study and investigated a) the types of func-
tionalities that can be reused; b) the reuse strategy that is adopted and the effort required for integrating the re-
used components with respect to the type of functionality that they implement and c) the quality of the reused
components with respect to the type of functionality that they implement. We analyzed 503 reused components
integrated in 35 target IoT applications. The results of this case study suggest that: the main reused functionality
is related to the Device Management layer; the main reuse strategy is Black-box reuse; and the effort for integrat-
ing the reused components can range from 27 lines of code to 1421 lines of code. The quality of the reused com-
ponents is slightly higher, in terms of Reusability and Functionality, compared to components built from scratch
in most cases. As future work we intend to further explore reuse opportunities within IoT frameworks by exam-
ining other open source frameworks, retrieving candidate components and comparing them.

Acknowledgement

This research was co-funded by the European Union and Greek national funds through the Operational Program
Competitiveness, Entrepreneurship, and Innovation, grant number T1EDK-04873

References
1. Aly, M., Khomh, F. and Yacout, S.: Kubernetes or OpenShift? Which Technology Best Suits Eclipse Hono
IoT Deployments. 2018 IEEE 11th Conference on Service-Oriented Computing and Applications (SOCA).
IEEE, (2018)
2. Ampatzoglou, A., Bibi, S., Chatzigeorgiou, A., Avgeriou, P., & Stamelos, I.: Reusability index: A measure
for assessing software assets reusability. International Conference on Software Reuse. Springer, Cham,
(2018)
3. Ampatzoglou, A., Kritikos, A., Kakarontzas, G., & Stamelos, I.: An empirical investigation on the reusabil-
ity of design patterns and software packages. Journal of Systems and Software, 84(12): pp. 2265-2283.
(2011).
4. Ani, Z. C., Basri, S., & Sarlan A.: A reusability assessment of UCP-based effort estimation framework using
object-oriented approach. Journal of Telecommunication, Electronic and Computer Engineering (JTEC) 9.3-
5: pp. 111-114 (2017)
5. Arvanitou, E. M., Ampatzoglou, A., Chatzigeorgiou, A., & Avgeriou, P.: Software metrics fluctuation: a
property for assisting the metric selection process. Information and Software Technology 72: pp.110-124
(2016).
6. Bansiya, J., Davis, C. G.: A hierarchical model for object-oriented design quality assessment. IEEE Transac-
tions on software engineering, 28(1): pp. 4-17 (2002)
7. Bibi, S., Stamelos, I., Gerolimos, G., & Kollias, V. (2010). BBN based approach for improving the software
development process of an SME—a case study. Journal of Software Maintenance and Evolution: Research
and Practice, 22(2).
8. Bröring, A., Schmid, S., Schindhelm, C.K., Khelil, A., Kaebisch, S., Kramer, D., Phouc, D. L., Mitic, J., An-
icic, D., Teniente, E.: Enabling IoT ecosystems through platform interoperability. IEEE software 34.1: pp.
54-61 (2017)
9. Chaturvedi, S., Tyagi, S., & Simmhan, Y.: Collaborative Reuse of Streaming Dataflows in IoT Applications.
In 2017 IEEE 13th International Conference on e-Science (e-Science): pp. 403-412 (2007)
10. Chen, W., Li, J., Ma, J., Conradi, R., Ji, J., & Liu, C.: An empirical study on software development with
open source components in the chinese software industry. Software Process: Improvement and Practice,
13(1): pp. 89-100 (2008).
11. Chidamber S.R., Kemerer. C.F.: A Metrics Suite for Object Oriented Design, IEEE Transactions on Soft-
ware Engineering, 20 (6): pp. 476-493 (1994)
12. Ciccozzi, F. & Spalazzese, R.: MDE4IoT: supporting the internet of things with model-driven engineering.
International Symposium on Intelligent and Distributed Computing. Springer, Cham, (2016)
13. Couto, C. M. S., Rocha, H.,Terra, R.: A quality-oriented approach to recommend move method refactorings.
In Proceedings of the 17th Brazilian Symposium on Software Quality: pp. 11-20 (2018)
14. Dorofeev, K., Cheng, C. H., Guedes, M., Ferreira, P., Profanter, S., & Zoitl, A.: Device adapter concept to-
wards enabling plug&produce production environments. 2017 22nd IEEE International Conference on
Emerging Technologies and Factory Automation (ETFA). IEEE, (2017)
15. Feitosa, D., Ampatzoglou, A., Gkortzis, A., Bibi, S. and Chatzigeorgiou, A., 2020. CODE Reuse in Practice:
Benefiting or Harming Technical Debt. Journal of Systems and Software, p.110618.
16. Frakes, W. & Terry, C.: Software reuse: metrics and models. ACM Computing Surveys (CSUR) 28.2: pp.
415-435 (1996)
17. Fremantle, P.: A reference architecture for the internet of things. WSO2 White paper (2015)
18. Gaffney Jr, J. E., & Durek, T. A.: Software reuse—key to enhanced productivity: some quantitative models.
Information and Software Technology, 31(5): pp. 258-267, (1989).
19. Gui, G., Scott, P. D.: Coupling and cohesion measures for evaluation of component reusability. In Proceed-
ings of the 2006 international workshop on Mining software repositories ACM pp. 18-21 (2006)
20. Gupta, A., Cruzes, D., Shull, F., Conradi, R., Rønneberg, H., Landre, E.: An examination of change profiles
in reusable and non reusable software systems. Journal of Software Maintenance and Evolution: Research
and Practice, 22(5), pp. 359-380 (2010)
21. Guth, J., Breitenbücher, U., Falkenthal, M., Fremantle, P., Kopp, O., Leymann, F., & Reinfurt, L.: A de-
tailed analysis of IoT platform architectures: concepts, similarities, and differences. In Internet of Every-
thing. Springer, Singapore: pp. 81-101 (2018)
22. Haefliger, S., Von Krogh, G., & Spaeth, S.: Code reuse in open source software. Management science,
54(1): pp. 180-193 (2008).
23. Heinemann, L., Deissenboeck, F., Gleirscher, M., Hummel, B., & Irlbeck, M.: On the extent and nature of
software reuse in open source java projects. In International Conference on Software Reuse. Springer, Ber-
lin, Heidelberg: pp. 207-222, (2011).
24. Höttger, R., Ozcelikors, M., Heisig, P., Krawczyk, L., Cuadra, P., & Wolff, C.: Combining Eclipse IoT
Technologies for a RPI3-Rover along with Eclipse Kuksa. Software Engineering (Workshops). (2018)
25. Jatain, A., Nagpal, A. & Gaur, D.: Agglomerative Hierarchical Approach for Clustering Components of
Similar Reusability. International Journal of Computer Applications, 68(2) (2013)
26. Katasonov, A., Kaykova, O., Khriyenko, O., Nikitin, S., & Terziyan, V. Y.: Smart Semantic Middleware for
the Internet of Things. Icinco-Icso 8: pp.169-178 (2008)
27. Kessel, M., & Atkinson, C.: Integrating reuse into the rapid, continuous software engineering cycle through
test-driven search. 2018 IEEE/ACM 4th International Workshop on Rapid Continuous Software Engineering
(RCoSE). IEEE, (2018)
28. Kim, J. E., Boulos, G., Yackovich, J., Barth, T., Beckel, C. & Mosse, D.: Seamless integration of heteroge-
neous devices and access control in smart homes. In Intelligent Environments (IE), 2012 8th International
Conference on IEEE: pp. 206-213 (2012)
29. Kovatsch, M., Lanter, M. & Shelby, Z. Californium: Scalable cloud services for the internet of things with
coap. 2014 International Conference on the Internet of Things (IOT). IEEE, (2014)
30. Krčo, S., Pokrić, B., & Carrez, F.: Designing IoT architecture (s): A European perspective. In 2014 IEEE
World Forum on Internet of Things (WF-IoT): pp. 79-84 (2014)
31. Lazarescu, M. T.: Internet of things low-cost long-term environmental monitoring with reusable wireless
sensor network platform. Internet of Things. Springer, Cham. pp.169-196. (2014)
32. Leiba, Barry. "Oauth web authorization protocol." IEEE Internet Computing 16, no. 1 (2012): 74-77.
33. Levina, A. I., Dubgorn, A. S., & Iliashenko, O. Y.: Internet of things within the service architecture of intel-
ligent transport systems. In 2017 European Conference on Electrical Engineering and Computer Science
(EECS) IEEE: pp. 351-355 (2017)
34. Lim, W. C.: Effects of reuse on quality, productivity, and economics. IEEE software 11.5: pp. 23-30 (1994)
35. Morgan, L., & Finnegan, P.: Benefits and drawbacks of open source software: an exploratory study of sec-
ondary software firms. IFIP International Conference on Open Source Systems. Springer, Boston, MA,
(2007)
36. Neagu, G., Florian, V., Stanciu, A. & Preda, S.: Sensing as a service approach in health monitoring. In 2016
15th RoEduNet Conference: Networking in Education and Research, IEEE: pp. 1-5 (2016)
37. O'Keeffe, M. & Cinnéide, M. O.: Search-based software maintenance. In Conference on software mainte-
nance and reengineering (CSMR'06), IEEE: pp. 10-pp (2006)
38. Osbeck, J., Virani, S., Fuentes, O. & Roden, P.: Investigation of automatic prediction of software quality. In
2011 Annual Meeting of the North American Fuzzy Information Processing Society, IEEE: pp. 1-6 (2011)
39. Padhy, N., Singh, R. P. & Satapathy, S. C.: Software reusability metrics estimation: Algorithms, models and
optimization techniques. Computers & Electrical Engineering, 69: pp. 653-668 (2018)
40. Papamichail, M., Diamantopoulos, T., Chrysovergis, I., Samlidis, P., & Symeonidis, A.: User-perceived re-
usability estimation based on analysis of software repositories. 2018 IEEE Workshop on Machine Learning
Techniques for Software Quality Evaluation (MaLTeSQuE). IEEE, (2018)
41. Paschali, M. E., Ampatzoglou, A., Bibi, S., Chatzigeorgiou, A. and Stamelos, I.: Reusability of open source
software across domains: A case study. Journal of Systems and Software 134: pp. 211-227 (2017)
42. Pessoa, T. Q., Duarte-Figueiredo, F., NodePI: An integrated platform for smart homes. In 2017 IEEE 9th
Latin-American Conference on Communications (LATINCOM), IEEE: pp. 1-6 (2017)
43. Podgurski, A. and Pierce, L.: Retrieving reusable software by sampling behavior, ACM Transactions on
Software Engineering and Methodology 2: pp. 286–303 (1993)
44. Prakash, B. A., Ashoka, D. V., Aradhya, V. M.: Application of data mining techniques for software reuse
process. Procedia Technology, 4: pp. 384-389 (2012)
45. Prieto-Diaz, R. & Freeman, P.: Classifying software for reusability. IEEE software, 4(1), 6 (1987)
46. Raemaekers S., Deursen A.V. & Visser J.: An Analysis of Dependence on Third-party Libraries in Open
Source and Proprietary Systems, 6th International Workshop on Software Quality and Maintainability
(SQM’ 12), (2012)
47. Ravichandran, T., & Rothenberger, M. A.: Software reuse strategies and component markets. Communica-
tions of the ACM 46.8: pp.109-114 (2003)
48. Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering.
Empirical software engineering, 14(2), 131 (2009)
49. Saied, M. A., Ouni, A., Sahraoui, H., Kula, R. G., Inoue, K., & Lo, D.: Improving reusability of software li-
braries through usage pattern mining. Journal of Systems and Software 145: pp. 164-179 (2018)
50. Schwittek W. & Eicker S.: A Study on Third Party Component Reuse in Java Enterprise Open Source Soft-
ware, 16th International Symposium on Component-based Software Engineering (CBSE’ 13), ACM: pp.
75–80 (2013)
51. Serna, M. A., Sreenan, C. J., Fedor, S.: A visual programming framework for wireless sensor networks in
smart home applications. In 2015 IEEE Tenth International Conference on Intelligent Sensors, Sensor Net-
works and Information Processing (ISSNIP): pp. 1-6 (2015)
52. Shani, U. & Broodney, H.: Reuse in model-based systems engineering. 2015 Annual IEEE Systems Confer-
ence (SysCon) Proceedings. IEEE, (2015)
53. Smiari, P., Bibi, S.: A Smart City Application Modeling Framework: A Case Study on Re-engineering a
Smart Retail Platform. In 2018 44th Euromicro Conference on Software Engineering and Advanced Appli-
cations (SEAA) IEEE: pp. 111-118 (2018)
54. Smiari, P., Bibi, S., & Feitosa, D.: Examining the Reusability of Smart Home Applications: A Case Study on
Eclipse Smart Home. In International Conference on Software and Systems Reuse, Springer, Cham: pp. 232-
247 (2019)
55. Smirek, L., Zimmermann, G., Beigl, M.: Just a smart home or your smart home–a framework for personal-
ized user interfaces based on eclipse smart home and universal remote console. Procedia Computer Science,
98: pp. 107-116 (2016)
56. Tanganelli, G., Vallati, C. and Mingozzi, E. CoAPthon: Easy development of CoAP-based IoT applications
with Python. 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT). IEEE, (2015)
57. The Internet of Things Reference Model - Whitepaper. Cisco (2014)
58. Torchiano, M. & Morisio, M.: Overlooked aspects of COTS-based development. IEEE software 21.2: pp.
88-93 (2004)
59. Tran, V., Liu, D.B. and Hummel, B. Component-based systems development: challenges and lessons
learned. Proceedings Eighth IEEE International Workshop on Software Technology and Engineering Prac-
tice incorporating Computer Aided Software Engineering. IEEE, (1997)
60. Von Krogh, G., Spaeth, S. and Lakhani, K. R.: Community, joining, and specialization in open source soft-
ware innovation: a case study. Research policy 32.7: pp. 1217-1241 (2003)
61. Wang, G., Ungar, L., Klawitter, D.: Component Assembly for Object-Oriented Distributed Systems, IEEE
Computer: pp. 71-78 (1999)
62. Wangoo, D. P., Singh, A.: A Classification based Predictive Cost Model for Measuring Reusability Level of
Open Source Software (2018)
63. Ye, Y., Fischer, G. and Reeves, B.: Integrating active information delivery and reuse repository systems.
ACM SIGSOFT Software Engineering Notes. Vol. 25. No. 6. ACM, (2000)
64. Yelamarthi, K., Aman, Md S. and Abdelgawad, A.: An application-driven modular IoT architecture. Wire-
less Communications and Mobile Computing 2017 (2017)
65. Yu, J., Benatallah, B., Saint-Paul, R., Casati, F., Daniel, F., & Matera, M.: A framework for rapid integration
of presentation components. Proceedings of the 16th international conference on World Wide Web. ACM,
(2007)
66. Zamfir, M., Florian, V., Stanciu, A., Neagu, G., Preda, Ş., & Militaru, G.: Towards a platform for prototyp-
ing IoT health monitoring services. In International Conference on Exploring Services Science Springer,
Cham: pp. 522-533 (2016)
67. Zanella, A., Bui, N., Castellani, A., Vangelista, L., Zorzi, M.: Internet of things for smart cities. IEEE Inter-
net of Things journal, 1(1): pp. 22-32 (2014)
68. Zhu, H.: Building reusable components with service-oriented architectures. IRI-2005 IEEE International
Conference on Information Reuse and Integration, Conf, 2005. IEEE, (2005)
69. Zimmermann, A., Schmidt, R., Sandkuhl, K., Wißotzki, M., Jugel, D., & Möhring, M.: Digital enterprise ar-
chitecture-transformation for the internet of things. 2015 IEEE 19th International Enterprise Distributed Ob-
ject Computing Workshop. IEEE, (2015)

Appendix A: Projects that reuse Eclipse IoT projects

Project Description #Classes LoC Releases # Forks # Contributors # Reused
Classes
Integration systems 18.461 2.176.350 158 4.000 605 49
Apache Camel
framework
IoT devices connector 648 119.809 43 94 32 10
Eclipse Hono
service
Eclipse Leshan M2M communication 367 48.849 27 260 25 67
Mule CoAP CoAP capable 13 3.001 1 2 1 5
connector applications
IoT messaging 443 39.398 5 24 14 44
Rhiot
platform
Middleware for IoT 245 40.801 20 2 17 15
IoTDM
data management
Performance testing 273 48.736 24 31 19 2
PerfCake
framework
Middleware for sensor 443 86.804 13 41 11 1
GSN
networks
SiteWhere IoT platform 1.195 150.579 39 298 13 4
Bosch IoT Examples for Bosch 21 4.101 1 34 22 12
Things IoT Things service
Communication 26 3.703 16 3 2 10
Eclipse Kura
addons for Eclipse
Addons
Kura
Component for 36 4.266 2 5 2 18
Dentrassi Camel providing OPC UA
client and server
DFKI COS Service platform 1.142 265.678 6 0 5 3
BaSys Platform
Set of libraries that 866 90.312 16 88 37 2
PLC4J Driver
enables coomunication
OPC UA
with PLC
Apache High performance 4.650 913.479 66 1.200 91 3
ActiveMQ message broker
Apache Stratos PaaS framework 1.438 189.727 53 111 48 4
Spring Support for Eterprise 2.950 405.617 204 831 141 10
Integration Integration Patterns
WSO2 Axis2 Framework for axis2 361 43.481 62 144 77 7
Transports based transports
WSO2 MB WSO2 message broker 292 49.481 26 74 29 40
MQTT MQTT Notification 2 380 0 14 4 1
Notification Plugin for Jenkins
Plugin
Applozic Android Chat SDK 327 64.660 66 304 19 2
Android SDK
AWS AppSync Android AWS 220 45.786 34 41 17 2
 SDK AppSync SDK
CA Mobile API Android CA Mobile 531 97.305 24 17 15 3
Gateway API Gateway SDK
Android Airspace 145 24.497 25 5 3 1
AirMap service for drones
SDK
Labstack Android library for 4 81 0 0 1 2
Android labstack platform
TNT4J Track and trace API 164 31.107 217 12 7 2
Qiscus SDK Android Chat SDK 176 30.791 177 75 13 1
Android
Ibis Adapter Stateless integration 1.108 198.028 204 41 27 3
Framework framework
MQTT server and 58 9.401 34 56 15 12
Vert.x MQTT
client
MQTT lightweight 130 14.917 14 636 35 9
Moquette
broker
Platform for managing 2.733 247.650 28 138 27 11
Eclipse Kapua
IoT gateways
Web-based 1.232 146.817 142 33 17 3
Joynr communication
framework
Server for OGC 464 64.117 20 31 11 4
FROST-Server
Sensor Things API
Load testing for 25 3.685 6 1 7 7
MQTT
MQTT broker
Home automation 3.384 394.788 90 2600 535 787
OpenHab2
platform

View publication stats