Monografia Ufba Matheus Lessa

Undergraduate Program in Computer Science
"A VIABILITY STUDY ON DYNAMIC SOFTWARE

PRODUCT LINES: THE SMART HOME DOMAIN"
by
Matheus Lessa Gonalves da Silva
SALVADOR
December/2014
Federal University of Bahia

Computer Science Department
Graduate in Computer Science
MATHEUS LESSA GONALVES DA SILVA
"A VIABILITY STUDY ON DYNAMIC SOFTWARE

PRODUCT LINES: THE SMART HOME DOMAIN"
B.Sc. Dissertation presented to the Undergraduate

Program in Computer Science at Federal University
of Bahia in partial fulfillment of the requirements for
the degree of Bacharelin Computer Science.
Advisor: Eduardo Santana de Almeida
SALVADOR
December/2014
Machines take me by surprise with great frequency.

ALAN TURING
Resumo
Linhas de Produto De Software (LPS) tem sido vistas como uma aborgadem sistemtica e
eficiente para melhorar o desenvolvimento de software em domnios especficos. Ao longo
dos anos, a abordagem tem sido evoluda e amadurecida e, mais recentemente, o conceito de
Linhas de Produto de Software Dinmica (LPSD) comeou a ser iserida em domnios especficos
envolvendo sistemas ubquos e sensveis ao contexto. Sistemas deste tipo tem requerido auto
adaptaes para variaes dinamicas em requisitos de usurios e ambiente de sistema.
A idia de LPSD surge como necessidade primria e considera a variabilidade de tempo de
execuo ao invs de tempo de projeto, como em LPS tradicionais. O objetivo deste trabalho
investigar a viabilidade da implementao de uma Linha de Produto de Software Dinmica
no domnio de casas inteligentes, considerando seus principais modelos, arquitetura, padres
e tcnicas de implementao. Neste sentido, foi modelado, projetado e implementado uma
LPSD destinada a executar algumas das features comuns encontradas em verses comercializadas de solues para casas inteligentes. Alm disso, a fim de avaliar DSPL desenvolvida, foi
realizado um survey com cinco indivduos, considerando os artefatos desenvolvidos.
Palavras-chave: Linhas de Produto de Software Dinmica, Tcnicas de Implementao,
Domnio de Casas Inteligentes, Gerenciamento de Variabilidade.
iv
Abstract
In recent years, Software Product Lines (SPL) have been seen as a systematic and efficient
approach to improve software development in specific domains. Along the years, the approach
has been evolved and matured and more recently, the concept of Dynamic Software Product
Lines (DSPL) started to be introduced in specific domains involving pervasive and contextaware systems. These kind of systems have been required to self-adapt to dynamic variations
in user requirements and system environment. The idea of Dynamic Software Product Lines
arises from such primary need, and considers runtime variability rather than design time, as
in traditional SPLs. The objective of this work is to investigate the viability of implementing
a Dynamic Software Product Lines in the smart home domain, considering its main models,
architecture, patterns and implementation techniques. In this sense, it was modeled, designed
and implemented a dynamic software product line aimed to perform some of the common
features found in marketed versions of smart homes solutions. In addition, in order to evaluate
the developed DSPL, we conducted a survey with five subjects considering the assets developed.
Keywords: Dynamic Software Product Lines, Implementation Techniques, Smart Home
Domain, Variability Management.
Contents
List of Figures
viii
List of Tables
ix
List of Acronyms
.
.
.
.
.
.
.
1
2
2
3
3
3
3
4
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
7
9
10
11
11
12
13
13
15
.
.
.
.
16
16
16
17
17
Introduction
1.1 Motivation . . . . . . . . . . . . .
1.2 Problem Statement . . . . . . . .
1.3 Overview of the Proposed Solution
1.4 Out of Scope . . . . . . . . . . .
1.5 Statement of the Contributions . .
1.6 Research Design . . . . . . . . .
1.7 Dissertation structure . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Foundations on Software Product Lines and Dynamic Software Product Lines

2.1 Software Product Lines (SPL) . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 SPL Motivation and Benefits . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Development Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Variability in Software Product Lines . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Variability Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Dynamic Software Product Lines (DSPL) . . . . . . . . . . . . . . . . . . .
2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 DSPL Motivation and Benefits . . . . . . . . . . . . . . . . . . . . .
2.3.3 DSPL Development Cycle . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Classifying DSPL . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Viability Study
3.1 Introduction . . . . . . . . . .
3.2 The Domain . . . . . . . . . .
3.2.1 Feature Model . . . .
3.2.2 Architecture Overview
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
3.3
3.4
4
3.2.2.1 Physical Layer . . . . . . .

3.2.2.2 Communication Framework
3.2.2.3 Business Layer . . . . . . .
3.2.3 Features Specification . . . . . . . .
3.2.4 Non-functional requirements . . . . .
Development . . . . . . . . . . . . . . . . .
3.3.1 Implementation . . . . . . . . . . . .
3.3.1.1 Feature Format . . . . . . .
3.3.1.2 Development Techniques .
3.3.1.3 Implementation Details . .
Chapter Summary . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Evaluation
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . .
4.2 Definition . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Context . . . . . . . . . . . . . . . . . . . .
4.2.2 Research Questions . . . . . . . . . . . . . .
4.3 Data collection . . . . . . . . . . . . . . . . . . . .
4.3.1 Survey Design . . . . . . . . . . . . . . . .
4.3.2 Developing the Survey Instrument . . . . . .
4.3.3 Evaluating the Survey Instrument . . . . . .
4.3.4 Analyzing the data . . . . . . . . . . . . . .
4.4 Results . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 DSPL Modeling Questions . . . . . . . . . .
4.4.2 DSPL Implementation Techniques Questions.
4.4.3 SmartHomeRiSE Use Questions. . . . . . .
4.5 Threats to validity . . . . . . . . . . . . . . . . . .
4.6 Findings . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Chapter Summary . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
20
23
23
30
33
33
33
34
41
42
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
43
43
43
44
44
44
45
45
46
46
47
48
48
49
49
Conclusions
50
5.1 Research Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
References
52
vii
List of Figures
1.1
Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
SPL framework processes. Extracted from (Pohl et al., 2005)

Essential product line activities (Northrop, 2002) . . . . . .
Connected DSPL Overview from (Pohl et al., 2005) . . . . .
Disconnected DSPL Overview from (Pohl et al., 2005) . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
DSPL Feature Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SmartHomeRiSE Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
Scale Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware Programmatic Abstraction Model . . . . . . . . . . . . . . . . . . .
Actuator general example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sensor getPin() user example . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sensor act(Actuator a) example . . . . . . . . . . . . . . . . . . . . . . . . . .
SmartHomeRiSE Meta-model Architecture . . . . . . . . . . . . . . . . . . .
Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Reconfiguration Model, that defines if a feature will be adaptable or not
Metrics Eclipse Plugin Statistics . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
. 9
. 14
. 14
18
19
20
21
22
22
23
33
35
38
42
viii
List of Tables
4.1
Implementation Techniques Survey Responses . . . . . . . . . . . . . . . . . . 48
ix
List of Acronyms
FODA
Feature-Oriented Domain Analysis
SPL
Software Product Lines
DSPL
Dynamic Software Product Lines
SPLE
Software Product Lines Engineering
SCM
Software Configuration Management
GQM
Goal-Question-Metric
CP
Configurable Products
C-DSPL
Connected DSPL
D-DSPL
Disconnected DSPL
FOSD
Feature-Oriented Software Development
DSPLE
Dynamic Software Product Lines Engineering
1
Introduction
The diversification in software development has been a key issue for companies employing
new engineering practices. In this way, some software industry players adopted the Software
Product Line Engineering (SPLE) approach aiming faster product development with high quality
and low cost (Linden et al., 2007). The SPL approach allows that development companies
supply the large demand of software systems. There are many benefits achieved from the use
of SPL in software companies. For instance, (Linden et al., 2007) mention as an example the
improvements of the process side of software development. In addition, SPL supports large-scale
reuse, which contributes to cost reduction, decreases the time to market and improves the quality
of the resulting products.
Software Product Lines (SPL) are developed based on core assets (Northrop, 2002) and
each member of the product family is known as a variant, which is instantiated according to
their needs and rules of the common architecture. The feature variability managment is a key
concept for SPL engineering practices. On the other hand, the concept of feature consists in a
characteristic that can be common only in some products and need to be managed to it. (Linden
et al., 2007).
In general, the SPL products instantiation based on variability occurs during the development
phase (Linden et al., 2007). For instance, it happens during (i) the compile time, (ii) the linking
time, and sometimes on (iii) the loading time (M. Hinchey and Schmid, 2012). However, in
some cases there is a new need of adaptation of the products where the generation of variations
occurs at runtime which produces systems with higher level of automation (Talib et al., 2010).
The Dynamic Software Product Lines (DSPL) approach aims to address this need and achieving
runtime adoptions according to user needs and environmental behavior. DSPL extends the
SPL concept to deal with dynamic variability (Hallsteinsen et al., 2008). Beyond it, DSPL
engineering is an appropriate way of achieving and managing the adaptations at runtime that
1.1. MOTIVATION
operates in a predefined configuration space.

The DSPL approach allows its variants reconfigure themselves during their execution (Bencomo et al., 2008a). In fact, developers need to rely on a set of techniques to cope with such
dynamic behavior. In this sense, the choice of the most suitable implementation technique to
perform the runtime binding of the variation points plays an important role in the development
phase of DSPL.
1.1
Motivation
Emerging domains such as ubiquitous computing, mobile devices, and smart homes demands
adaptation and interaction of components at runtime. In this way, a DSPL solution is welcome
since the problem of runtime reconfiguration in this kind of systems can be seen in two different
ways: (i)) the system adapts itself spontaneously to respond to changes in the environment; (ii))
the system adapts itself to perform a action requested by the user. As the the systems have to
monitor their environment all the time and also prepared to work through an user stimulus, their
development is a complex task (Hallsteinsen et al., 2008).
Based on this scenario, DSPL has been incorporated as part of this approaches as a strategy to
deal with different configurations at runtime. Moreover, this promising area aims diversification
and development of new products efficiently and quickly, achieving even more high productivity,
quality, and low costs of development (Burgio et al., 2010).
1.2
Problem Statement
Despite several work investigate methodologies and development models (Bencomo et al., 2008a;
Istoan et al., 2009a; Parra et al., 2009; Lee et al., 2011; D. Kramer and Clark, 2013; Cetina et al.,
2009; Gnther and Sunkle, 2010), the literature still lacks of guidelines on implementing an
DSPL (Burgio et al., 2010). This fact turns the development of an DSPL even more difficult.
In this way, the goal of this work is to evaluate development techniques to manage the
DSPL variability through of techniques such as: inheritance, aggregation, polymorphism, design
patterns, metadatas, reflection and as on. Then, the work will focus on identifying in each
development technique chosen, key points to implement each type of variability control in DSPL
and then, in based on this background, implements a dynamic software product line prototype.
1.3. OVERVIEW OF THE PROPOSED SOLUTION
1.3
Overview of the Proposed Solution
In order to accomplish the goal of this dissertation, we propose an approach to an DSPL

development standard. This standard supports the DSPL implementation activities in order to
assist software engineers in the variability management activity. At the next steps, we developed
a case of study prototype to evaluate this standard.
1.4
Out of Scope
In order to focus on the viability study, was decided to not focus in some other additions of the
DSPL field. Below is some items out of the scope of this work.
DSPL Maintenance. The SmartHomeRiSE project does not include maintence tasks at
this point;
Compile time feature bind. This project follows the default design of an DSPL proposed
by (M. Hinchey and Schmid, 2012) and does not support feature binding at compile time
1.5
Statement of the Contributions
As result of this work, the following contributions can be highlighted

A study about DSPL implementation techniques that map one-by-one the feature
model entity to a specific implementation technique;
An abstract structure to model all entities from feature models that can create a
codified representation of the feature model variants and its constraints;
1.6
Research Design
The research design approach defined for this work is showed on Figure 1.1 and it can be
described through three main steps:
The first step aimed to investigate the dynamic software product lines area, as well as
complementary methods for an understanding of technical aspects and development of
the system. This way, we intended to define in details all activities previously established
for implementation of DSPL.
1.7. DISSERTATION STRUCTURE
The stage for DSPL implementation and building of scale model, in which allows testing
the possible reconfigurations at runtime.
Finally, the stage for evaluating the approach developed at model and implementation
level.
1.7
Dissertation structure
The remainder of this dissertation is organized as follows:

Chapter 2 reviews the essential topics used throughout this work: Software Product Lines
and Dynamic Software Product Lines.
Chapter 3 describes the viability study proposed for the DSPL development as well as
the architecture, the set of dynamic variability implementing techniques, and technologies
used during the DSPL development.
Chapter 4 describes a case study conducted to evaluate the implementation standard.
Chapter 5 provides the concluding remarks. It discusses the contributions, limitations,
threats to validity, and outline directions for future work.
1.7. DISSERTATION STRUCTURE
Figure 1.1: Research Design
2
Foundations on Software Product Lines and
Dynamic Software Product Lines
This chapter presents background interpretation on Software Product Lines (SPL). Furthermore,
it discusses variability and finally, was presented the Dynamic Software Product Lines (DSPL).
2.1
2.1.1
Software Product Lines (SPL)

Introduction
(Northrop, 2002) defines Software Product Lines (SPL) as:

A set of software-intensive systems that share a common, managed set of features
satisfying the specific needs of a particular market segment or mission and that are
developed from a common set of core assets in a prescribed way.
Core assets are considered the essence of software product lines (Northrop, 2002). They
consist in configurable elements of an SPL such as architecture, reusable software components,
domains models, where the architecture is the main element of this set. In addition, feature is a
prominent or distinctive user-visible aspect, quality, or characteristic of a system (Kang et al.,
1990). The concept of product line comes from the automobile industry, to face the increasing
demand of people wanting to buy different cars. Henry Ford used product line to allow mass
production with low costs, however, this reduced the possibilities for diversification. In order
to solve this problem, he started the mass customization, with the aim to produce goods on a
large scale and adapt them to the needs of individual consumers. For mass customization can be
financially viable to the automobile industry, Ford utilized common platforms for different types
2.1. SOFTWARE PRODUCT LINES (SPL)
of cars before planning what parts he must use in different cars. This approach has been also
used in industry such as digital cameras, office supplies and software industry. (Pohl et al., 2005)
called the systematic combination of the concept of mass customization and use of platforms for
the development of software products of Software Product Line Engineering (SPLE).
The purpose of the use of SPL is to reduce the engineering overall effort to produce a
set of similar products, through planned software reuse. The fundamental principles of SPL
engineering consist in identifying the common and variable parts and supporting a range of
products to maximize reusable variations and eliminate waste of generic implementation of
components used only once (Hallsteinsen et al., 2008).
2.1.2
SPL Motivation and Benefits
Companies usually adopt an SPL approach strongly based on economic considerations (Linden
et al., 2007). SPL supports large-scale reuse, which implies on lower costs, shorter time to market
and improves the quality of the resulting products. Despite of these benefits, it is necessary some
initial investments, which requires to build reusable assets, changing the organization. The use
of the SPL usually reaches a break-even after about three products.
Some benefits in adopting an SPL approach (Pohl et al., 2005):
Reduction of development cost. The cost to create all the system is reduced when core
assets are reused in different products. However, the companies have to make an upfront
investment for creating them.
Quality improvements. The reusable assets are more tested when using in several product
instances. It implies significantly in the quality of the product.
Reduction of time-to-market. The product release time is significantly reduced when
many artifacts are reused to build new products.
Reduction of Maintenance Effort. When an artifact is modified, for error correction,
the changes are propagated for all products. Furthermore, it is possible to reuse test
procedures that decrease the maintenance effort.
2.1.3
Development Cycle
The SPL life cycle consists of two processes: domain engineering and application engineering
(Pohl et al., 2005).
2.1. SOFTWARE PRODUCT LINES (SPL)
Figure 2.1: SPL framework processes. Extracted from (Pohl et al., 2005)
Domain Engineering: Aims to define the commonalities, and based on the similarities,
build domain assets that will serve of base for building individual products.
Application Engineering: Aims to build the applications through reuse, by using domain
artifacts and variability defined in Domain Engineering.
(Pohl et al., 2005) proposed a framework to support SPL development planning that incorporates the central concepts of conventional product line engineering. Figure 2.1 shows processes
and sub-processes of their framework. The framework relies on the difference between the
domain and application engineering processes. The domain engineering process is composed for
five key subprocesses: product management, domain requirements engineering, domain design,
domain realization, and domain testing. The application engineering process is composed by:
application requirements engineering, application design, application realization, and application
testing.
Defining and exploring variability throughout the different life cycle levels of a software
product line is called of managed variability. Figure 2.2 shows the keys activities to build and
maintain an SPL . These activities are inserted in management process of the variations in several
artifacts that compose an SPL. This management throughout the development encompasses the
separation of the product line in three parts: common components, variable parts (common only
among a few), and individual products as their own specific requirements. Each of the three
2.2. VARIABILITY IN SOFTWARE PRODUCT LINES
Figure 2.2: Essential product line activities (Northrop, 2002)

circles represents an activity:
Management: It supports and coordinates the Core Asset activity and Product Development.
Core Asset Development: Analysis the SPL domain and search of the reuse opportunities
within of the scope, motived by the domain engineering.
Product Development: It focus on combining and configuring the core assets to develop
specific components to instantiate a new product.
2.2
Variability in Software Product Lines
Variability is an essential property in domain artifacts of SPLE. As defined by (Pohl et al.,

2005) ,variability is defined during domain engineering, and it is exploited during application
engineering by binding the appropriate variants. Moreover, there are two important concepts
to understand variability: variability subject and variability object. Variability subject it is a
variable item or a property of the real world and variability object is a particular instance of
a variability subject. For example, on the cars domain to variability subject "color", we can
2.2. VARIABILITY IN SOFTWARE PRODUCT LINES
classify red, green, blue, as examples of variability object (Pohl et al., 2005). Variability subjects
and the corresponding variability objects are part of the context of a software product line. They
represent a subset of all possible variability subject and variability object necessary to create a
certain software product line. (Pohl et al., 2005) define variation point as "a representation of a
variability subject within domain artifacts enriched by contextual information" and variation as
"a representation of a variability object within domain artifacts".
Another important concept in variability of SPL is binding time. The binding time of the
variability is the moment in that a certain sub-process in application engineering binds variability
introduced by the corresponding sub-process in domain engineering (Pohl et al., 2005).
In conventional SPL the binding time can occur in different times such as: pre-compilation,
compilation, linking, load and runtime. However, the last one is uncommon for conventional
SPLE.
2.2.1
Variability Type
Currently, with the emergence of the DSPL area, the goal has been to move this time to binding
runtime, allowing dynamic variability. Dynamic variability occurs due to product variations
that appear in the execution environment or the product itself. These variations depend on
context variations, which are computationally accessible information extracted by monitoring
the execution environment or the current state of the product. In this case, an adaptation to a
given context corresponds to a product configuration of the DSPL (Bencomo et al., 2012).
Associated to the need to support unanticipated adaptation in dynamically adaptive systems
to two types of variability: (i) environment or context variability to represent the conditions
and events that can modify the current architecture of the system, and (ii) structural variability
to specify the architecture of the system which will evolve at runtime. In order to satisfy the
requirements for the new context, the system may add new features or organizing the current
configuration.(Bencomo et al., 2008b)
As adaptable systems, the DSPL needs to identify the environment where are inserted and
proceed all reconfiguration rules that are previously programed, even if the context changes
to a unknown one. In addition, the system must be prepared to add new features to meet new
requirements or simply to improve the current state of the system when new features become
available, all this dynamically (Bencomo et al., 2008b).
It is possible to divide dynamic adaptation in two different types: dynamic behavior the
systems deal with new environmental conditions unknown during development and dynamic reconfiguration it is necessary that variations of behavior can be predetermined before execution.
10
2.3. DYNAMIC SOFTWARE PRODUCT LINES (DSPL)
During the execution, the current state of the system is evaluated and the appropriate variants
are chosen (Bencomo et al., 2008b).
The transition from a product line where the variability is bounded at development time to
a system that adapts its behavior by binding variability at runtime has several consequences
(M. Hinchey and Schmid, 2012). Variability is no longer simply an engineering artifact, in DSPL
the variability model is the core artifact to guide the system adaptation. The DSPL should be
able to query the runtime variability model to identify adaptations.
Adaptive computing systems increase the need to deal with runtime variability, because
it modifies its internal structures dynamically and consequently, its behavior in response to
internal and external incentives (McKinley et al., 2004). For this reason, researchers introduced
DSPL approach, in which enables to bind variation points at runtime. These applications adapt
dynamically during runtime, according to changes in the environment and user requests (Burgio
et al., 2010).
The software reuse and techniques of variability implementation in SPL can be useful for
developing some types of self-adaptive systems. Developers have used these techniques to
implement variation point at runtime (Hallsteinsen et al., 2006), aiming for a good performance
of the products generated.
2.3
2.3.1
Dynamic Software Product Lines (DSPL)

Introduction
The evolution of the SPL regarding to unexpected software changes has drawn attention of
researchers for DSPL approach, in which the system is able to operate continuously in conditions
and environments harsh, meeting the users needs. However, a product derived from DSPL differs
of others instantiated of the SPL by the capacity to update dynamically the system configuration
after deployment (Burgio et al., 2010), and assists on the implementation of changes at
applications of emerging domains.
In terms of features, in DSPL, the adaptations at runtime are often based on components
and are described at the architectural level (Gomaa and Hussein, 2004). It allows the programmer specifies adaptation rules for reconfiguration components. This dynamic reconfiguration
approach uses a mapping of DSPL features for components that normally are handled at the
implementation (Lee, 2013). However, components normally are coarse-grained and limit the
customization of the DSPL. An alternative is using Feature-oriented Programming, because
this technique can implement feature modularly as it is a component (R.Wolfinger and Doppler,
11
2008).
Researchers have conducted several studies to investigate the aspects of reconfiguration of
product lines at runtime (Burgio et al., 2010) aiming to deliver high-quality software. The
product dynamic reconfiguration refers to change the product configuration developed at runtime.
The addition, removing and dynamic change of product features are some examples of dynamic
reconfiguration for SPL (Istoan et al., 2009b).
To manage the variability in DSPL is necessary to adopt different adaptation policies
(Bencomo et al., 2008a). The modification when detected at the operational context actives the
product reconfiguration to provide context-relevant services or collect quality request (Lee et al.,
2011).
The main activities of DSPL consist of monitoring the current situation and controlling the
adaptation through the management of variation points. These activities encompass several
properties, such as: (i) dynamic variability; (ii) treatment of unexpected changes in the context;
(iii) context-sensitivity; (iv) autonomy and adaptivity, (v) automatic decision-making, and (vi)use
in specific environments instead of marketplace (M. Hinchey and Schmid, 2012).
Such properties, indicates that DSPLs can benefit from research in many other areas, such as
situation monitoring and adaptive decision making that are also characteristics of autonomic
computing. Moreover, (Bencomo et al., 2008a) state that dynamically adaptive systems can be
conceptualized as DSPL.
2.3.2
DSPL Motivation and Benefits
Ubiquitous computing, service robotics, medical and life-support devices, and others emerging
domains vary considerably in requirements and resource constraints, because of this software is
becoming increasingly complex. Furthermore, in modern computing and network environments
it is necessary a high degree of adaptability from software. User requirements, computing
environments, and interface mechanisms between software and hardware such as sensors change
dynamically during runtime (Hallsteinsen et al., 2008).
More recently, DSPL became part of this approach list emerging as a promising field. Any
flaw in reconfiguration of an DSPL directly impacts the user experience because it happens
when the system is already under its control (Cetina et al., 2010). Thus, the main goal of DSPL
consists in adaptation of the variations based on the user needs and particular situations, with
less emphasis at the market. Moreover, the product generated from DSPL provide new variants
and different configurations, which are obtained at runtime.
12
2.3.3
DSPL Development Cycle
DSPL architecture is a single system architecture, which provides a basis for all possible
adaptations of the system. It does not need be built as part of an SPL (at development time)
(Hallsteinsen et al., 2008). This means that the whole variability may be achieved at runtime. In
this way, both the life cycles of DSPL, the domain engineering and the application engineering
differs life cycles of SPL.
The domain engineering and the application engineering in the DSPL context aims the
systematic development of the system and its use by exploring the adaptability. Thus, the
domain engineer must identify the possible adaptations and their triggers, besides the set of
possible system reactions, focusing in construction, while the application engineer must handle
the variations so that the system itself performs the reconfiguration (M. Hinchey and Schmid,
2012).
2.3.4
Classifying DSPL
In DSPL, when the binding time occurs at runtime, the features are maintained regardless of
whether the product will be used or not. Moreover, are produced configurable products (CP) that
has autonomy to reconfigure themselves and receive constant updates. The CP is produced by
the product line, as well as conventional SPL, however, in DSPL case, we need two artifacts to
control them: the decision maker and the reconfiguration. The former has function of capturing
all the information in its environment that suggests changes, as external sensors information or
information from a user for example. The latter is responsible for executing the decision by
using the standard SPL runtime binding (Cetina et al., 2008).
(Cetina et al., 2008) analyzed the reasons why a CP is reconfigured, and distinguished two
main kinds of reconfiguration scenarios: involution scenario, in that the new configuration of
a CP is performed with the available features of the system; and evolution scenario, the new
configuration occurs with the use of a new feature or update an existing one. The main difference
is that the first has a finite number of scenarios, as well as the available features of the system,
whereas in the second case the numbers of scenarios are difficult to be previewed as new features
unknown may appear.
According to (Cetina et al., 2008), several approaches for configurable product adaptation
are treated in the literature, thus they classify these approaches in two categories: Connected
DSPL (C-DSPL), wherein the DSPL is responsible for adapting the product, and Disconnected
DSPL (D-DSPL) where the CP itself is in charge of the product adaptation.
13
Figure 2.3: Connected DSPL Overview from (Pohl et al., 2005)
Figure 2.4: Disconnected DSPL Overview from (Pohl et al., 2005)

Figures 2.3 and 2.4 show an overview of the connected and disconnected DSPL with the
steps to send updates from the DSPLs to the CPs. The C-DSPL stay in touch with the products to
send updates and to deal with context changes, and D-DSPL produce CP, which can reconfigure
itself in order to deal with contextual changes.
In their work, (Cetina et al., 2008) compare the connected and disconnected approaches and
analyze advantages and disadvantages for DSPL. Thus, they state that C-DSPL produces highly
adaptable CP, but with the limiting that it should be necessarily connected to the DSPL, while
that the D-DSPL produces autonomic CPs, which need not be connected but with an adaptation
range shorter. Thus, in order to fill this gap, they proposed a hybrid approach, a mixed DSPL.
Where in involution scenarios, CPs behave as in disconnected DSPL and in evolution scenarios
CPs behave as in connected DSPL. Another approach to classify DSPLs was presented by
(Schmid, 2007). It consists in a taxonomy of different types of adaptivity that classifies DSPLs
by triggers of adaptation, direction and range of adaptivity. For each type, he discussed the main
14
2.4. SUMMARY
implications for Requirements Engineering. Among the main types were presented: bounded
adaptivity, representing planned chances, i.e. all the adaptations are known in advance, and open
adaptivity, which deals with unforeseeable changes that do not know what kind of adaptation
will occur.
In DSPL, it is necessary to understand when to adapt and which configurations choose. To
automate such decisions, it is necessary to model the relationships between the context variation
points and any product variants. Given this context, (Bencomo et al., 2012) classified two
difference types of DSPLs regarding to decision making: rule-based approaches and goal-based
approaches. The rule-based approaches perform the analysis and planning tasks at design time
based in the event-condition-action (ECA) rules. From the ECA rule, the system can trigger
events, holds current system configurations, and a set of reconfiguration steps. When the system
triggers events, it performs the reconfiguration steps. The advantage of this approach is the
adaptation behavior analysis and the validation at design time. However, it is necessary the
identification of all possible configurations at design time. Moreover, the number of rules can
become very high.
The goal-based approaches allow analysis and planning at runtime, because it adopts abstract
representations of the decision model. Goal-based approaches maximize an objective function
with explicit constraints, discarding invalids configurations. The advantage of this approach is
the reduction of problems related to the number of variants at design time. On the other hand,
this may incur in additional costs and a runtime overhead.
2.4
Summary
This chapter presents the result of the study regarding product families such as: Software Product
Lines (SPL), and Dynamic Software Product Lines (DSPL), as well as introducing the concept
of variability. However, the focus of this chapter was regarding the management of variability in
the DSPL approach, beyond its benefits, motivations, development cycle, and how deal with
with dynamic variability, including differences and similarities between both, SPL and DSPL.
The next chapter presents a viability study of the implementation of DSPL on the smart homes
domain.
15
3
The Viability Study
3.1
Introduction
The development of an DSPL is complex task and includes compliance of several activities. In
this sense, we present the development process of the DSPL named SmartHomeRiSE through of
a framework (Figure 1.1). Besides, each stage of the process is discussed along the chapter wich
includes the scope, the architecture, technologies, and implementation techniques used.
3.2
The Domain
Smart Home is considered the new trend of housing for the future. They need to be efficient,
fast and adaptable to the interests of residents and environmental changes. These characteristics
enable identify through the analysis of domain, a diversity of settings that can occur at runtime.
Based on this scenario, an DSPL named SmartHomeRiSE was developed. In addition, it
adapts itself responding both to user commands and to environmental changes, i.e., features are
activated, deactivated, and updated dynamically at runtime to satisfy the specifics.
The SmartHomeRiSE DSPL aimes to providing practicality for users, because is an automation system. In addition, it allows inserting of new devices and features, without compromising
the smooth operation of the home.
In this way, the variation points of the system SmartHomeRiSE were defined from the users
perspective and needs of the context, in which it is inserted.
16
3.2. THE DOMAIN
3.2.1
Feature Model
Figure 3.1 shows its feature model. We manage to model a set of features to satisfy a range of
system adaptations. Such set enables us to explore the DSPL nature of the system, identify and
manage variation points to support domain specific needs regarding users viewpoint.
The features of the DSPL are represented according to type such as: Mandatory, Optional,
Alternative, OR, Concrete, and Abstract. Moreover, it is possible to identify the features according to scale of priority such as: Low, Medium, and High. This classification allows
to identify the order which the features should be implemented.
In the feature model specified also was defined constraints regarding to dependence among
features such as: once activated Notify feature, necessarily the alternative features Wifi or
MobileNetwork are activated. In this same way, the Active feature when is requested at runtime,
subsequently active the Alarm feature in order to trigger another important resources for security
of the home.
3.2.2
Architecture Overview
The SmartHomeRiSE was developed as a Java application,following the DSPL model previously
mentioned, that manage the features variability for addition, removing and request by other
features. It was also built a house scale model and attached some devices, such as, Arduino,
sensors (e.g., temperature, gas and smoke, luminosity, and presence), and LEDs. These hardware
are used to act in the house and simulate environmental changes to help us to explore the dynamic
variability. Figure 3.2 shows the architecture diagram of the SmartHomeRiSE prototype.
The architecture is divided into physical layer that comprises a scale model, Arduino, sensors,
and actuators beyond the business layer where the features and user interface of the product
line are inserted. However, it was necessary to develop a communication framework that allows
the communication between these layers. In addition, this framework uses the programmatic
abstractions in order to spend the information collected through Arduino for the system since it
could be interpreted with the aim to control sensors and actuators.
3.2.2.1
Physical Layer
The physical layer (Figure 3.3) of SmartHomeRiSE consists of all hardware parts that were
used to control the prototype and simulate the environmental changes necessary to stimulate the
product line variability in runtime. In this layer, the Arduino works as main piece and attached to
it are all the sensors (light, presence and so on) and actuators (LEDs, motors and so on). It is also
17
WiFi
FromPolice
RequestAssistance
FromNeighbors
LockDoors
PresenceIllusion
AgainstRobery
Active
MobileNetwork
DataConnection
AgainstRobery
Security
ByEmail
Alternative
Or
Abstract
"Active" implies "Alarm"
Figure 3.1: DSPL Feature Model
Optional
Subtitles:
UserControlled
Concrete
ByPresence
ByLuminosity
AutomatedIllumination
Illumination
UserIllumination
AutomatedControlled
FromWindows
UserControlled
TemperatureControl
FromAirConditioning
AutomatedControlled
ByVoIP
"Notify" implies "DataConnection"
PanicMode
Mandatory
Alarm
Notify
SmartHomeRiSE
3.2. THE DOMAIN
18
3.2. THE DOMAIN
Figure 3.2: SmartHomeRiSE Architecture
19
3.2. THE DOMAIN
Figure 3.3: Scale Model

through the Arduino via USB connection, that the application can act on the prototype in order
to get environmental data and interact with the actuators. It will be important to remember at
this point that in the model implemented, the Arduino is not responsible for any decision of the
operation of the product line, this only works as a mediator of the business layer, written in Java
and running on a server, with the equipment connected to the house through the communication
framework developed
3.2.2.2
Communication Framework
The SmartHomeRiSE Arduino Communication Framework can be seen as an intermediate

communication layer between the business layer and the prototype. Being written in two parts,
one in Java in the main application, and another in C within the Arduino, this tool allows
programmatic use of all hardware connected to the prototype.
Inside the Java application the framework can be divided into two parts: programmatic
abstraction of sensors and actuators and Arduino messages manager class. The programmatic
abstraction of sensors and actuators is a hierarchical structure of classes (figure 3.4), which
defines the type of hardware (sensor or actuator) and its actions and is the interface between the
framework and features.
The message control class, that only can be seen by the hardware abstraction classes, is the
20
3.2. THE DOMAIN
Figure 3.4: Hardware Programmatic Abstraction Model
21
3.2. THE DOMAIN
Figure 3.5: Actuator general example
Figure 3.6: Sensor getPin() user example
22
3.2. THE DOMAIN
Figure 3.7: Sensor act(Actuator a) example

class responsible for absorbing all the logic of communication with Arduino. Using it, every
action requested by a feature to a hardware abstraction class instance is processed and sent to
the microcontroller through a standard message via USB port. In Arduino, the messages are
received, decoded and appropriate action is taken besides responses can also be sent back to the
message manage class. Figures 3.5, 3.6 and 3.7 show an example of each existent way of the
Arduino communication framework.
3.2.2.3
Business Layer
The business layer is where the kernel of the DSPL implementation is defined. By the using
of a set of techniques as Design Patterns, Feature-Oriented Software Development (FOSD),
inheritance, aggregation, polymorphism and interfaces and APIs as Java Reflection, Annotation
and Swin,g is in this layer where are the definitions of features and all variability control
mechanisms. The development details will be detailed in the Development section.
3.2.3
Features Specification
In this section was described the features of the SmartHomeRiSE, its priorities and relationships
with other features.
[F001] DataConnection
23
3.2. THE DOMAIN
Description: Feature is responsible for managing the functions which performs dada connection.
Priority: Medium
Feature Type: Optional and Abstract
Child features: F002, F003
[F002] Wifi
Description: Feature is responsible for performing the wifi connection.
Priority: Medium
Feature Type: Alternative and Concrete
Father feature: F001
Exclude: F003
[F003] MobileNetwork
Description: Feature is responsible for performing the connection available by mobile
devices.
Priority: Medium
Feature Type: Alternative and Concrete
Exclude: F002
[F004] Security
Description: Feature is responsible for managing the functions of protection against robbery.
Priority: High
Feature Type: Mandatory and Abstract
[F005] AgainstRobery
Description: Feature is responsible for managing the functions that prevents against robbery
and simulate presence inside of the home.
Priority: High
24
3.2. THE DOMAIN

Exclude: F003
[F006] Active
Description: Feature is responsible for managing the functions which lock all the doors and
notify the police or neighbors about a possible robbery.
Priority: Medium
Binding time: Runtime
Required: F012
[F007] LockDoors
Description: Feature is responsible for performing the closing of all the doors of home.
Priority: Medium
Feature Type: Optional and Concrete
[F008] RequestAssistance
Description: Feature is responsible for managing the functions that solicit for help from
police and from neighbors.
Priority: Medium
[F009] FromNeighbors
Description: Feature is responsible for performing solicitation of help from neighbors.
Priority: Medium
25
3.2. THE DOMAIN
Feature Type: OR and Concrete

[F010] FromPolice
Description: Feature is responsible for performing solicitation of help from police.
Priority: Medium
[F011] PresenceIlusion
Description: Feature is responsible for performing simulation of presence inside the home.
Priority: Medium
Feature Type: Mandatory and Concrete
[F012] Alarm
Description: Feature is responsible for managing the functions which performs the sending
of warning for the user.
Priority: Medium
[F013] AgainstRobery
Description: Feature is responsible for performing the warning sound against robbery.
Priority: Medium
[F014] PanicMode
Description: Feature is responsible for performing the panic mode, switching on all the
lights of home randomly.
26
3.2. THE DOMAIN
Priority: Medium
[F015] Notify
Description: Feature is responsible for managing the functions of notification for the user.
Priority: Medium
Required: F001
[F016] ByEmail
Description: Feature is responsible for performing the sending of reminder or notice for the
user by email.
Priority: High
[F017] ByVoip
Description: Feature is responsible for performing the sending of reminder or notice for the
user through audio.
Priority: Medium
[F018] TemperatureControl
Description: Feature is responsible for managing the functions which turns on/off airconditioning of home.
Priority: Medium
27
3.2. THE DOMAIN
[F019] FromAirConditionering
Description: Feature is responsible for managing the house air conditioner system.
Priority: Medium
Feature Type: OR and Abstract
[F020] AutomatedControlled
Description: Feature is responsible for performing the functions which turns on/off airconditioning of home from command of sensor.
Priority: Medium
[F021] UserControlled
Description: Feature is responsible for performing the functions which turns on/off airconditioning of home from command of the user.
Priority: Medium
[F022] FromWindow
Description: Feature is responsible for managing the function open/close windows of home.
Priority: Medium
Feature Type: OR and Abstract
[F023] UserControlled
Description: Feature is responsible for performing the function open/close windows of
28
3.2. THE DOMAIN
home from the command of the user.

Priority: Medium
[F024] AutomatedControlled
Description: Feature is responsible for performing the function open/close windows of
home from the command of sensor.
Priority: Medium
[F025] Illumination
Description: Feature is responsible for managing the functions of lighting of home.
Priority: High
[F026] UserIllumination
Description: Feature is responsible for performing the functions which turns on/off lights
of home from command of the user.
Priority: High
[F027] AutomatedIllumination
Description: Feature is responsible for managing the functions which turns on/off lights of
home from both commands, user and presence sensor.
Priority: Medium
29
3.2. THE DOMAIN

[F028] ByPresence
Description: Feature is responsible for performing the function which turns on/off lights of
home from the command of presence sensor.
Priority: Medium
[F029] ByLuminosity
Description: Feature is responsible for performing the function which turns on/off lights of
home from the command of luminosity sensor.
Priority: Medium
3.2.4
Non-functional requirements
Reliability
Description: Non-functional requirement associated to the frequency, severity, and ability to
recovery of failures of the feature as well as correction of the system.
[RNF03] Average time of failure
The tolerated time of downtime so that the feature be performed again after failure is of ten
seconds
[RNF03] Unavailability
The system could be temporarily unavailable when is necessary a correction of failure which
was detected by the user or by the system.
30
3.2. THE DOMAIN
[RNF04] Failure Rate

The failure rate may occur with a frequency of 2/100, i.e., in each hundred units operating of
time.
[RNF05] Percent of events causing failures
The events which can occur in the system at runtime correspond to failure of authentication to
send notification by email or by voip, however, the solution consist in immediate correction.
[RNF06] Probability of data corruption after failure
The data corruption will occur when the failure in the feature can be only solved restarting the
system.
Performance
Description: Non-functional requirement associated to the efficiency, use of resources, and the
system response time.
[RNF07] Activation/deactivation of features
The feature must be loaded in 10 seconds, after the user solicitation.
[RNF08] Reactivation of feature after failures
The feature must be reactivated 15 seconds after occur the execution failure.
[RNF09] Implementation of feature
The feature status must be shown during runtime.
[RNF10] Share notification
The share notification must be available soon after the request of the user or of the system itself.
Security
Description: Non-functional requirement associated to the integrity, privacy and authenticity of
data system.
[RNF11] Authentication to send notification
All operations for sending notifications by email or by voip must be enabled through of authen-
31
3.2. THE DOMAIN
tication. The access to the data base must be protected to the user not authorized.
Distribution
Description: Non-functional requirement associated to the distribution of the executable version
of the system.
[RNF12] Multi-User
The system must bear multi-user processing, i.e., several users can use the system at the same
time.
Patterns
Description: Non-functional requirement associated to the standards that must be followed by
the system or by development process.
[RNF13] Standards of development
The system must attend to the standards of development respecting name of variables and
parameters, beyond use object and functions common for them.
[RNF14] Interaction among platforms
The interaction among platforms must occur satisfactorily to ensure the correct execution of
the system.
Hardware and Software
Description: Non-functional requirements associated to the hardware and software used to
develop or perform the system.
[RNF15] Software
O software will be developed by using object-oriented programming techniques.
Development environment: Eclipse IDE, by using plugins (. . . ) e (. . . )
Execution environment: Desktop (. . . )
[RNF16] Hardware
The hardware must attend under minimum requirements the system, in which consist in high
capacity of memory and processing.
32
3.3. DEVELOPMENT
3.3
Development
The DSPL system named SmartHomeRiSE 1 was developed following the FeatureOriented Software (FOSD) process (Apel and Kstner, 2009). It consists a paradigm for favors
the systematic application of the feature concept in all stages of the software life cycle (i.e.,
consttruction, customization, and synthesis). This process involves the domain engineering
and application engineering, each one composed of several activities (M. Hinchey and Schmid,
2012).
3.3.1
Implementation
In the next sections will be detailed the techinical aspects of the development of the SmartHomeRiSE. The figure 3.8 shows a synthesis of a metamodel created to the application.
Figure 3.8: SmartHomeRiSE Meta-model Architecture
3.3.1.1
Feature Format
A design decision was to represent each feature as a class, i.e., each Mandatory, Alternative
or Optional concrete features has a class which performs its functionality. In this way, the
1 The
code SmartHomdeRiSE DSPL is available at:

risesmarthome/subversion/nodes
https://www.assembla.com/code/
33
3.3. DEVELOPMENT
feature model was converted into most appropriate representation for application engineering
since a notation with resources such as inheritance and the attributes expressing details of the
common features and variability. Figure 3.9 shows the class diagram, in which is presented all
classes necessary to represents the DSPL features.
3.3.1.2
Development Techniques
Inheritance: A technique commonly used in object-oriented software systems to enable

reuse of functionalities, in which a subclass is derived of a superclass by the insertion
of attributes and operations new in the derived class. Thus, a derived class from their
superclass, is specialized for specific context ??. In the Dynamic Software Product
Lines Engineering (DSPLE), the inheritance is used to model different subclasses of
variants of an abstract class, in which it are used by different features of the DSPL. In
SmartHomeRiSE, mainly due to the chosen format of the feature, inheritance is one of
the key points of implementation. Through it, the DSPL can be implemented faithfully
following the pattern set in the feature model automatically maintaining the characteristics
inherent to the possibility of a concrete feature direct son of another. In order to increase
the reusability and create a standardized format for the maintenance of instances of the
features it has created a hierarchical pattern definition where all features must inherit from
a base feature directly or indirectly, if this feature inherits from another feature. 3.1 shows
an example of applying this standard.
Listing 3.1: FeatureBase Class
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public abstract class FeatureBase {

p r i v a t e S t r i n g name ;
p r i v a t e boolean i s A c t i v e = true ;
private ArrayList <FeatureBase > r e q u i r e d F e a t u r e s ;
public abstract void proceedActions ( S t r i n g [ ] a r g s ) ;
public void addRequiredFeature ( FeatureBase f e a t u r e ){
i f ( r e q u i r e d F e a t u r e s == n u l l )
r e q u i r e d F e a t u r e s = new A r r a y L i s t < F e a t u r e B a s e > ( ) ;
r e q u i r e d F e a t u r e s . add ( f e a t u r e ) ;
}
public ArrayList <FeatureBase > getRequiredFeatures ( ) {
return r e q u i r e d F e a t u r e s ;
}
/ / a d d i t i o n a l l i n e s o f code
}
Listing 3.2: UserIlumination Class

1
2
3
@MandatoryFeature
public c l a s s UserIlumination extends FeatureBase {
34
Figure 3.9: Class Diagram
3.3. DEVELOPMENT
35
3.3. DEVELOPMENT
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
p r i v a t e A r r a y L i s t <Led > l e d s ;
private s t a t i c UserIlumination userIlumination = null ;
protected UserIlumination (){}
public s t a t i c UserIlumination getInstance
( A r r a y L i s t <Led > l e d s ) {
i f ( u s e r I l u m i n a t i o n == n u l l ) {
u s e r I l u m i n a t i o n = new U s e r I l u m i n a t i o n ( ) ;
u s e r I l u m i n a t i o n . setName ( " U s e r I l u m i n a t i o n " ) ;
userIlumination . setLeds ( leds ) ;
}
return u s e r I l u m i n a t i o n ;
}
}
Listing 3.3: AutomatedIluminationByLuminosity Class

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public c l a s s AutomatedIluminationByLuminosity extends

U s e r I l u m i n a t i o n implements A d a p t a b l e F e a t u r e {
p r i v a t e A r r a y L i s t <Led > l e d s T o A u t o m a t e ;
private LightSensor lightSensor ;
private s t a t i c AutomatedIluminationByLuminosity
automatedIluminationByLuminosity = null ;
private
A u t o m a t e d I l u m i n a t i o n B y L u m i n o s i t y ( ) {}
public s t a t i c AutomatedIluminationByLuminosity
getInstance () {
i f ( a u t o m a t e d I l u m i n a t i o n B y L u m i n o s i t y == n u l l ) {
automatedIluminationByLuminosity =
new A u t o m a t e d I l u m i n a t i o n B y L u m i n o s i t y ( ) ;
a u t o m a t e d I l u m i n a t i o n B y L u m i n o s i t y . setName
( " Automated I l u m i n a t i o n By L u m i n o s i t y " ) ;
automatedIluminationByLuminosity . setLedsToAutomate
( new A r r a y L i s t <Led > ( ) ) ;
automatedIluminationByLuminosity . setActive ( false ) ;
}
return automatedIluminationByLuminosity ;
}
}
Aggregation or composition and parametrization: This is an object-oriented technique

that allows objects support any functionality (Gacek and Anastasopoules, 2001). Moreover,
this technique is considered as reuse mechanism of classes with intend of increase the
productivity and quality in the software development. In order to promote the reuse,
this technique use several classes to compose another class. In addition, it increases
the productivity when is not necessary to rewrite the code of an specific class (if some
class exist with attribute and similar behavior). Using large-scale heritage and other basic
concepts of object orientation the use of aggregation/composition ends up becoming trivial.
So are several use cases of this implementation technique. In addition to the code snippets
attached above, aggregation/composition is also present in others product line classes.
36
3.3. DEVELOPMENT
Listing 3.4: The PanicMode Feature implemented with composition

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
p u b l i c c l a s s PanicMode e x t e n d s F e a t u r e B a s e {
Pa n i c Mo d e T h re a d p a n i c M o d e T h r e a d ;
p r i v a t e s t a t i c PanicMode panicMode = n u l l ;
p r i v a t e PanicMode ( ) { }
p u b l i c s t a t i c PanicMode g e t I n s t a n c e ( U s e r I l u m i n a t i o n u s e r I l u m i n a t i o n ) {
i f ( panicMode == n u l l ) {
panicMode = new PanicMode ( ) ;
panicMode . setName ( " P a n i c Mode " ) ;
panicMode . a d d R e q u i r e d F e a t u r e ( u s e r I l u m i n a t i o n ) ;
}
r e t u r n panicMode ;
}
/ / Some l i n e s o f c o d e
}
Polymorphism and Interfaces:This mechanism represents a key element of design patterns and object-oriented frameworks. It is implemented in object-oriented languages,
defining an abstract class (interface) as a common point of access (Gacek and Anastasopoules, 2001). Polymorphism is implemented by virtual functions. In order for a
derived class virtual function instance to override the base class virtual function instance,
its signature must match the base class virtual function exactly. The overriding functions
are virtual automatically. The use of keyword virtual is optional in derived classes (Muthig
and Patzke, 2003). Dynamic binding is enabled when a virtual function is invoked through
a derived class object which is referred indirectly by either a base class pointer or reference.
The features of SmartHomeRiSE can be of two types: user features, which are those which
run through users stimuli, and adaptable features, which was defined as the features that
run through environmental stimuli, recognized through sensors connected to the prototype.
In order to solve this problem was defined the AdaptableFeature interface that defines a
procededActions() method that does not receive the parameters. Within this method the
features that implement the interface should use programmatic abstractions of sensors
and actuators as parameters for its operation. At the snippets 3.5 and 3.6 are shown the
definition of the adaptable feature interface and a class that implements it, respectively.
The figure 3.10 also explains this model
Listing 3.5: The AdaptableFeature interface definition
1
2
3
public interface AdaptableFeature {

void proceedActions ( ) ;
}
Listing 3.6: A concrete adaptable feature example

1
2
public class AutomatedIluminationByPresence

p r i v a t e A r r a y L i s t <Led > l e d s T o A u t o m a t e ;
e x t e n d s U s e r I l u m i n a t i o n implements A d a p t a b l e F e a t u r e {
37
3.3. DEVELOPMENT
<< interface >>
FeatureBase
proceedActions(String args[]);
AdaptableFeauture
ConcreteFeature
proceedActions();
Figure 3.10: Dynamic Reconfiguration Model, that defines if a feature will be adaptable or not
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private PresenceSensor presenceSensor ;

private s t a t i c AutomatedIluminationByPresence automatedIluminationByPresence = null ;
/ / some l i n e s o f c o d e
@Override
public void proceedActions ( ) {
if ( isActive ()){
i f ( l e d s T o A u t o m a t e ! = n u l l && p r e s e n c e S e n s o r ! = n u l l ) {
f o r ( Led l e d : l e d s T o A u t o m a t e ) {
presenceSensor . act ( led ) ;
}
}
}
}
}
In summary, Figure 3.10 shows the approach used to perform adaptations triggered either
by the user, when the concrete feature overrides the void proceedActions(String args[])), or
by the environment, when the concrete feature implements the AdaptableFeature interface
and overrides the void proceedActions() method without parameters. In the second case,
the sensors on the house will provide the inputs parameters to the feature.
Abstract Classes: Abstract class has a pure virtual function, i.e., no object can be created
for an abstract class. Moreover, it is used as an interface for its derived classes. The
classes derived from an abstract class must override all of the base classs virtual functions
to become non-abstract. However, if a class derived from an abstract class, and this class
does not override all the pure virtual function in the base class, them this class is also an
abstract class (Svahnberg et al., 2005). As already said in the session about inheritance,
abstract classes are the basis for the construction of the structure created to give the
flexibility and standardization necessary for the implemented model. The snippet 3.1
shows the abstract class that structure the features. Below the code snippet represents the
abstract class that structure the classes of the programmatically abstraction of the sensors
and actuators.
Listing 3.7: The Hardware class is inherited by all classes that represents sensors and
actuators
38
3.3. DEVELOPMENT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
p u b l i c a b s t r a c t c l a s s Hardware {
private int pin ;
p r i v a t e S t r i n g name ;
p r i v a t e boolean isAnalog ;
p u b l i c Hardware ( i n t p i n , b o o l e a n i s A n a l o g ,
S t r i n g name ) {
t h is . pin = pin ;
this . isAnalog = isAnalog ;
t h i s . name = name ;
}
}
Reflection and Annotations: This technique is commonly used by programs which require the ability to examine or modify the behavior at runtime (Gacek and Anastasopoules,
2001). Moreover, it is a powerful technique and can enable applications to perform operations which would otherwise be impossible. The reflexive API incorporates structures that
represents all the language structure, besides be suitable to examine, modify its properties,
and control its implementation at runtime. In this way, it is possible that system obtains
information about its object type, attributes, constructors, and its inheritance structures, beyond dynamically load a new class, create new instances, and invoke methods (Svahnberg
et al., 2005). The Annotation Java API is a new addition to Java language that allows add
metadata directly to the code eliminating the need to have a separated file. As the notes
are directly inserted into the classes, is necessary use the reflection library to access them
and read their contents. The SmartHomeRiSE defines annotations to control variability
at runtime. It was defined two annotations, one to identify mandatory features and other
to identify alternative features, thereafter optional features can be identified as features
without annotations. The Java Reflection API is used both for read the Annotations and
for control the variability when adding and removing features.
Listing 3.8: Annotations definitions
1
2
3
4
5
6
7
8
9
10
@Target ( E l e m e n t T y p e . TYPE )
@ R e t e n t i o n ( R e t e n t i o n P o l i c y . RUNTIME)
public @interface A l t e r n a t i v e F e a t u r e {
C l a s s <? e x t e n d s F e a t u r e B a s e > [ ] a l t e r n a t i v e s ( ) ;
}
@Target ( E l e m e n t T y p e . TYPE )
@ R e t e n t i o n ( R e t e n t i o n P o l i c y . RUNTIME)
public @interface MandatoryFeature {
}
Listing 3.9: Using the annotations to identify the features

1
2
3
@AlternativeFeature ( a l t e r n a t i v e s =
{ MobileNetworkDataConnection . c l a s s })
39
3.3. DEVELOPMENT
4
5
6
7
8
9
10
11
public c l a s s WifiDataConnection extends

DataConnection {
private s t a t i c WifiDataConnection
wifiDataConnection = null ;
protected WifiDataConnection (){}
}
Listing 3.10: Reflexive variability control

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
p r i v a t e boolean e v a l u a t i o n F o r F e a t u r e H i e r a r c h y
( FeatureBase newFeature ) {
for ( FeatureBase featureBase : f e a t u r e s ) {
i f ( newFeature . getClass ( ) . g e t S u p e r c l a s s ( ) . equals ( featureBase . getClass ( ) ) ) {
k e e p F e a t u r e S t a t e ( featureBase , newFeature ) ;
exchangeRequiredFeature ( featureBase , newFeature ) ;
f e a t u r e s . remove ( f e a t u r e B a s e ) ;
return true ;
}
i f ( featureBase . getClass ( ) . g e t S u p e r c l a s s ( ) . equals ( newFeature . getClass ( ) . g e t S u p e r c l a s s ( ) ) ) {
exchangeBrotherFeaturesData ( featureBase , newFeature ) ;
return true ;
}
i f ( featureBase . getClass () . getSuperclass () . equals
( newFeature . getClass ( ) ) ) {
return f a l s e ;
}
}
return true ;
}
Design Pattern: It is a description or template concerning how to solve a problem that

can be used in many different situations (Gacek and Anastasopoules, 2001). It can be
exploited in the DSPL context since many of them identify system aspects may vary, and
offer reusable solutions for variability management.
(Keepence and Mannion, 1999) and (Gurp et al., 2001) detail and use some patterns to
model the variability in software product lines. However, in the context of this work were
implemented patterns such as: Singleton which by definition ensures that one class has
only one instance of itself and it provides a global access point for it; and Facade it
provides an unificade interface for a set of interfaces at a subsystem (Gamma et al., 1995).
The listings 3.11 and 3.12 show the usage of both design patterns, Facade and Singleton.
The Singleton design pattern was implemented in all features to guarantee a single feature
instance, fundamental to the maintence of the dynamic product line consistency. The
Facade design pattern is used to create a house abstraction class with the aim of create a
joint point to the user interface classes hiding the variability control complexity.
Listing 3.11: HouseFacade Implementation
1
2
3
p u b l i c c l a s s HouseFacade {
private ArrayList <FeatureBase > a v a l i a b l e F e a t u r e s ;
40
3.3. DEVELOPMENT
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
private ArrayList <FeatureBase > f e a t u r e s ;

p r i v a t e A r r a y L i s t < Hardware > h a r d w a r e L i s t ;
private AutomatedFeaturesRunnable
automatedFeaturesRunnable ;
p u b l i c HouseFacade ( ) {
f e a t u r e s = new A r r a y L i s t < F e a t u r e B a s e > ( ) ;
h a r d w a r e L i s t = new A r r a y L i s t < Hardware > ( ) ;
loadMandatoryFeatures ( ) ;
loadAvaliableFeatures ( ) ;
automatedFeaturesRunnable =
new A u t o m a t e d F e a t u r e s R u n n a b l e ( f e a t u r e s ) ;
( new T h r e a d ( a u t o m a t e d F e a t u r e s R u n n a b l e ) ) . s t a r t ( ) ;
}
public void removeFeature ( FeatureBase newFeature ){
/ * a d d i t i o n a l l i n e s o f code * /
}
public void addFeature ( FeatureBase newFeature ){
}
private void r e c r e a t e F a t h e r F e a t u r e
( FeatureBase feature ) {
}
p r i v a t e boolean e v a l u a t i o n F o r F e a t u r e H i e r a r c h y
( FeatureBase newFeature ){
}
return true ;
}
private void exc hangeB rothe rFeatu resDa ta
( FeatureBase featureBase , FeatureBase newFeature ) {
}
private void k e e p F e a t u r e S t a t e
( FeatureBase oldFeature , FeatureBase newFeature ) {
}
Listing 3.12: PanicMode Feature with singleton pattern

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
p u b l i c c l a s s PanicMode e x t e n d s F e a t u r e B a s e {
P a n i c Mo d e T h re a d p a n i c M o d e T h r e a d ;
p r i v a t e s t a t i c PanicMode panicMode = n u l l ;
p r i v a t e PanicMode ( ) { }
p u b l i c s t a t i c PanicMode g e t I n s t a n c e ( U s e r I l u m i n a t i o n u s e r I l u m i n a t i o n ) {
i f ( panicMode == n u l l ) {
panicMode = new PanicMode ( ) ;
panicMode . setName ( " P a n i c Mode " ) ;
panicMode . a d d R e q u i r e d F e a t u r e ( u s e r I l u m i n a t i o n ) ;
}
r e t u r n panicMode ;
}
}
3.3.1.3
Implementation Details
The system was implemented in Java with 2591 lines of code including 9 packages and 52
classes and C code on Arduino has 83 lines of code. Some other statistics about the Java code
are summarized in figure 3.11.
41
3.4. CHAPTER SUMMARY
Figure 3.11: Metrics Eclipse Plugin Statistics
3.4
Chapter Summary
This chapter presented the development process of an DSPL through of one framework, in
which contains all the essential activities, including choice of domain, the set of functional and
non-functional requirements, architecture, and technologies adopted during its construction.
Moreover, it presented a mechanism suitable to implement variability in the DSPl context with
intend to achieve more flexibility of the system at runtime. However, this mechanism was based
on object-oriented programming techniques.
In order to manage the dynamic variability satisfactorily, we created an implementation
standard by using these techniques discussed in this work, beyond to show its use for each
important aspect. Next chapter presents the evaluation performed during the development of the
project with intends to analyze the modeling and implementation aspects.
42
4
Evaluation
4.1
Introduction
This chapter describes a survey applied to validate the artifacts developed for this work. It is
organized as follow: Section 4.2 defines this case study; in Section 4.3 the data collection model
is presented and evaluated; Section 4.4 describe the results and this interpretation; the Section
4.5 analyze the threats to validity of the study; Sections 4.6 and 4.7 describe some findings and
summarizes the chapter.
4.2
4.2.1
Definition
Context
After the complete implementation of SmartHomeRiSE, in order to validate the application

developed both in relation to the constructed DSPL model as in regard the implementation
techniques used, was applied at Software Engineering Laboratory, between the 5th and 15th
December 2014, a survey with five participants where four of them were master students and
one was undergraduate student, all members of the RiSE, Reuse in Software Engineering Lab.
4.2.2
Research Questions
For this study it was decided two main points of analysis: analysis of DSPL modeling and DSPL
implementation techniques. Thus, the objective this study is to answer the following questions:
Does the created DSPL model represented in the feature model is correct and is
properly implemented in the application? Rationale: The goal is to assess whether the
43
4.3. DATA COLLECTION
model established for the application really represents the feature model and is able to
control its variations.
Does the developed implementation model and consequently the chosen techniques
used to implement it were effective in their roles? Rationale: The objective is to
evaluate for each characteristic of DSPL, it the technique used to implement it was
efficient.
Does the operation of the DSPL happen without fail? Rationale: In this question the
objective is to evaluate the operation of SmartHomeRiSE.
4.3
4.3.1
Data collection
Survey Design
In this survey, we used the design proposed by (Kitchenham, 2006) that suggests the use of closed
questions in self-administered questionnaires, however in order to cover all research questions
of the survey and give to the respondent the necessary understanding about the application, was
made a training and open questions were created too.
4.3.2
Developing the Survey Instrument
In order to perform a complete analysis of all developed artifacts of SmartHomeRiSE DSPL, the
survey was divided into five parts:
Background. In this first moment was given a conceptual background of the application and following stages of the study. To better illustrate the model and facilitate the
understanding of the architecture created for the software, were used the images 3.2 and
3.4 that respectively illustrate the architectural model of the system and a meta-model of
implementation of features. At this stage, the questions asked by the respondents were
answered.
DSPL Modeling Questions. In this section, consisting of five open questions, the respondent should using inputs obtained from the previous phase and their previous knowledge
to answer about their opinions regarding the modeling issues of implemented product line.
DSPL Implementations Techniques Questions. At this point of the study, the respondent has access to the system source code and using it together with the diagrams presented
44
4.3. DATA COLLECTION
above, it should answer about the used implementation techniques. For this, each implementation technique should be judged on their impact (positive or negative) in the
implementation of SmartHomeRiSE on four aspects: complexity, extensibility, reusability
and maintainability. This section has seven issues where in each the respondent should
examine the technique under the four aspects. The questions are in scale format with zero
values (extremely negative impact) to ten (extremely positive impact).
SmartHomeRiSE Use Questions. In this part of the study the respondent should use
SmartHomeRiSE and evaluate the performance of each feature individually and also
its relationship to other features. In order to not make the survey execution most timeconsuming was chosen a feature set having all kinds of features and possible relationships
between them. This set contains all the mandatory features of the feature model (Figure
3.1) in addition to all features belonging to the branch of the Illumination feature
Respondent Characterization. At the end of the survey, eight questions should be
answered about the previous skills of the respondents on the topics addressed in the
study.All questions were on a scale format from zero (do not know nothing) to five
(expert).
4.3.3
Evaluating the Survey Instrument
After the preliminary definition of the survey format and questionnaire questions, it was evaluated
along with a researcher from software engineering, member of RiSE Group. After this analysis,
the changes were discussed and the model was refined accordingly. Furthermore, it is important
to note that this researcher was not used as respondent in the survey.
4.3.4
Analyzing the data
In order to collect the data, the five respondents completed a digital questionnaire. After
designing and running the survey, the next step was to analyze the collected data. The main
analysis procedure was to check all responses, tabulate the data, identify the findings and classify
the options.
45
4.4. RESULTS
4.4
Results
In this section the analysis of the collected data will be shown and discussed Due to the volume
of data, not all the answers can be cited in the text, in this way the maturity of the respondent
in relation to the subject of the question, obtained from the characterization questionnaire, is
considered as a criterion of choice.
4.4.1
DSPL Modeling Questions
In the question: Does the presented feature model have any modelling fails? no respondents
found errors, but one of them commented that It must contain the possible adaptations of DSPL
in the proposed model. This is not considered a failure, but must be taken into consideration
when a DSPL is modeled.
In the second question, which says: Does the proposed application architectural model
follows the precepts of DSPL? (Environmental Adaptation, Reconfiguration Rules, Feature Oriented Development) two respondents agreed, but two of them made criticism of the
feature model presented. The critical of the respondent more experienced in DSPL modeling was:
As for the environmental adaptation and reconfiguration rules is missing elements representing
it explicitly in the model. As it is DSPL, there should be elements which would demonstrate
the run-time adaptation and which gave rise to this adaptation (environment, user, context etc.)
and the rules for this reconfiguration happen. I believe that this evidence was not modeled
explicitly.
Considering the question: How do you judge the model as extensibility and reusability?
all respondents thought that the model was sufficiently extensive and reusable but one of them
made a comment about the level of abstraction of the meta-model of implementation of features:
[...] I think he (the metamodel) should be at a lower level of abstraction for the system to be
better represented. This would encourage engineers who had to reuse or extend this model
later.
At the question: Based on the available meta-model, an application developed following him possess all the variability control mechanisms forecasted on feature model? all
respondents agreed in saying that the presented meta-model was adequate.
Considering the question: How do you judge the implementation format chosen for
the features (each feature being a class) according to extensibility, variability control in
runtime. three of the respondents agree and one preferred to not answer. Among the respondents
who agreed, the most experienced added: I think the format chosen for the features is ideal
46
4.4. RESULTS
with respect to extensibility, since the use of classes promote features relationship of father and
daughters through inheritance, in other words, if necessary adding a feature it is possible to
manage this in a more appropriate manner through inheritance of property.
4.4.2
DSPL Implementation Techniques Questions.
For the analysis of the DSPL implementation techniques, we developed a questionnaire where
subjects should score the impact of the technique used in implementing the DSPL on the following criteria: complexity, extensibility, reusability and maintainability. For this questionnaire, the
respondent was informed the expected definition each criterion as:
Complexity: Metric that measures the facility of understanding of a code. The code
easiest to understand is the code it will be less complex and vice versa. Many lines of code,
many methods and many nested repetition loops can be indications of a highly complex
code
Extensibility: Model scalability. For this study, an extensible model is the one that allows
a new feature, not previously mentioned, is added to it without serious impacts in the
current structure or large implementation efforts.
Reusability: For this study, we define as reusability criteria the ease of reuse of a feature,
either within the same application, as reusing the feature in case of expansion of the model
feature, or even in another application or domain.
Maintainability: The maintainability criterion was defined as the measuring of the
maintenance effort of a particular feature or any of its control structures. Well-defined
structures, layered model and so on are indications a system with good maintainability.
For this questionnaire was chosen a score scale format with values from 1 to 10. The
value 1 means that the use of this technique causes extremely negative impact regarding the
criteria evaluated and the value 10 mean extremely positive impacts. The questions asked to the
respondents were as follows:
Q1. Intense use of inheritance, aggregation, polymorphism and so on to define the product
line structure
Q2. The use of Annotations to manage the variability control of alternative features
Q3. The use of Annotations to manage the variability control of mandatory features
47
4.5. THREATS TO VALIDITY
Q4. The Interface definition to perform the polymorphic control of environment-adaptable

features
Q5. The use of Facade design pattern to the house abstraction
Q6. The use of Singleton design pattern to the maintenance of feature instances and
variability control
Q7. The use of Reflection to help on variability control when addition and removal of
features
Below, see the table bellow shows the arithmetic mean of the respondents responses to each
question and criterion.
Q1 Q2 Q3
Complexity
8
9
9.4
Extensibility
8.2 9.4 9.6
Reusability
9.2 9.2 9.4
Maintainability 9
8.8 9.2
Q4 Q5 Q6 Q7
9
8
8.6 8.4
9.2 8.6 8.4 7.8
9
8.6 8.4 7.2
8.8 8.2 6.8 8
Table 4.1: Implementation Techniques Survey Responses
4.4.3
SmartHomeRiSE Use Questions.
The feature set evaluation described in Subsection 4.3.1 remained stable among all respondents.
All reported that the features worked without error and followed the constraints of the feature
model. As the speed of adaptation, all responses varied between one and two in the range of one
to five. On this scale, the value one meants instant speed adaptation and five equivalent to say
that adaptation takes long or did not happen.
4.5
Threats to validity
Here are some threats to validity of this study

Sample size: The number of respondents is always a critical question in a survey. In this
case, mainly because it was necessary to use the product line, it was not possible to use
media such as the Internet or other research groups for the survey realization. Thus, the
study may contain biases.
48
4.6. FINDINGS
Quality of training: The quality of training conducted before applying the questionnaire
and the possible low specificity of a certain document used during training or execution
of the questionnaire may have impaired the correct understanding of the model and
application.
Translation of the answers: Most of the responses were written in portuguese and
translated to english by the author. This may have changed the direction of the response
4.6
Findings
Analyzing the data, it is possible to realize that although noticed some lack of understanding caused by possible failures in the construction of the models that represents the system
architecture and feature meta-model, the majority of respondents considered positively both
the model of DSPL when its implementation and implementation techniques.In addition, none
of the respondents reported failures in the implementation of product line and all judged its
implementation as being quite rapid or immediate. As one of the respondents reported, the
granularity of the models used to show the DSPL can be a problem including for the use of
the standard developed for the SmartHomeRiSE by teams of developers or another application
domain. One solution to this problem would be to create more models representing each given
level of granularity.
4.7
Chapter Summary
This chapter presented the context, motivation, technique and results of a study aiming to
evaluate the DSPL SmartHomeRiSE. To this, it was applied a survey with five participants, four
masters students and one undergraduate student, in order to evaluate the product line regarding
to the modeling of DSPL, implementation techniques and execution of the developed application.
The study results were positive. The product line was able to adequately respond to all incoming
stimuli, both from the user and from the environment. However, one of the respondents reported
that the figures used to represent the architectural and deployment models may show different
levels of granularity in order to facilitate understanding.
49
5
Conclusions
Dynamic software product lines (DSPL) are considered as a evolution of conventional software
product lines (SPL) since a product derivated of a DSPL must have the ability to changes itself
behavior at run-time in order to respond to stimuli from the environment. There are many studies
on methodologies and models for DSPL development, however the literature is still lacking
in work aimed at implementing this type of system (Burgio et al., 2010). In this work, we
use the smart home domain to study and understand how should be constructed a DSPL and
then was implemented and conducted a survey to assess it. In chapter 2 is given a theoretical
foundation of SPL and its main applications. Next DSPL is addressed and then discussed its
benefits, development cycle and classifications. The Chapter 3 details the conducted viability
study, showing the development techniques and applications in each issue of implementation of
DSPL. Chapter 4 presents a survey performed with 5 participants with the objective to evaluate
the SmartHomeRiSE both when it comes to the built DSPL modeling and in relation to the
implementation techniques used in its development. In this study the participants also had
contact with the prototype and were able to test some of the features developed.
5.1
Research Contribution
The main contributions of this research are described as follows:

Study and definition of implementation techniques of DSPL. To carry out this viability
study was analyzed some of software implementation techniques over commonly used in
the industry and their respective applications in DSPL implementation domain. Candidate
techniques were identified for the implementation of each characteristic of DSPL and then
a development model was created using those that were judged most appropriate.
50
5.2. FUTURE WORK
SmartHomeRiSE DSPL implementation. After the study of techniques, it was built a

smart home prototype, using Arduino, sensors and actuators, and the implementation of
DSPL, written in Java, which controlled the prototype. Moreover, we developed a set of
other artifacts such as functional and non functional requirements, features description
document and feature model diagram.
Evaluation Survey. After the end of the development of the application and prototype,
we conducted a survey that gathered important information on what had been developed
as well as opinions on new features and improvements.
5.2
Future Work
The current literature is still somewhat vague when it comes to DSPL implementation. To
contribute in this direction, as future work we would like to extend this viability study in
order to build a guideline on DSPL implementation techniques relating each product line
characteristic with one or more techniques. In this work, as shown in Chapter 2.4, we use some
of the software development techniques better known among developers. However, to create
a guideline on DSPL implementation techniques we intend to study the applicability of some
software development techniques less traditionally used in this field as aspect orientation, service
orientation, web-semantic etc. We believe that the creation of this guideline will be of great
importance to the area, then, after it, we plan to conduct a controlled experiment in order to
validate it.
51
References
Apel, S. and Kstner, C. (2009). An overview feature-oriented software development. Journal

of Technology (JOT), 5(8), 4984.
Bencomo, N., Sawyer, P., Blair, G., and Grace, P. (2008a). Dynamically adaptive systems are
product lines too: Using model-driven techniques to capture dynamic variability of adaptive
systems. In Proceedings 2nd Intl Workshop Dynamic Software Product Lines, pages 2332.
Bencomo, N., Blair, G., Flores, C., and Sawyer, P. (2008b). Reflective component-based
technologies to support dynamic variability. In Proceedings of the 2nd Workshop Variability
Modeling of Software-Intensive Systems (VaMoS).
Bencomo, N., Hallsteinsen, S. O., and de Almeida, E. S. (2012). A view of the dynamic software
product line landscape. IEEE Computer, 45(10), 3641.
Burgio, V. A., de Lemos Meira, S. R., and de Almeida, E. S. (2010). Characterizing dynamic
software product lines - A preliminary mapping study. In Software Product Lines - 14th International Conference, SPLC 2010, Jeju Island, South Korea, September 13-17, 2010. Workshop
Proceedings (Volume 2 : Workshops, Industrial Track, Doctoral Symposium, Demonstrations
and Tools), pages 5360.
Cetina, C., Trinidad, P., Pelechano, V., and Ruiz-Corts, A. (2008). An architectural discussion on dspl. In 2nd SPLC Workshop on Dynamic Software Product Line (DSPL), page
5968, Limerick, Ireland. Irish Software Engineering Research Centre (Lero), Irish Software
Engineering Research Centre (Lero).
Cetina, C., Haugen, O., Zhang, X., Fleurey, F., and Pelechano, V. (2009). Strategies for variability
transformation at run-time. In Proceedings of the 13th International Software Product Line
Conference, SPLC 09, pages 6170, Pittsburgh, PA, USA. Carnegie Mellon University.
Cetina, C., Giner, P., Fons, J., and Pelechano, V. (2010). Designing and prototyping dynamic
software product lines: Techniques and guidelines. In Proceedings of the 14th International
Conference on Software Product Lines: Going Beyond, SPLC10, pages 331345, Berlin,
Heidelberg. Springer-Verlag.
D. Kramer, S. Oussena, P. K. and Clark, T. (2013). Graphical user interfaces in dynamic software
product lines. In Proceeding of the International Workshop on Product Line Approaches in
Software Engineering (PLEASE), pages 2528. IEEE.
52
REFERENCES
Gacek, C. and Anastasopoules, M. (2001). Implementing product line variabilities. In Proceedings of the 2001 Symposium on Software Reusability: Putting Software Reuse in Context, SSR
01, pages 109117, New York, NY, USA. ACM.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements of
Reusable Object-oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston,
MA, USA.
Gomaa, H. and Hussein, M. (2004). Software reconfiguration patterns for dynamic evolution
of software architectures. In In Proceedings of the Fourth Working IEE/IFIP Conference on
Software Architecture, pages 7988. IEEE.
Gnther, S. and Sunkle, S. (2010). Dynamically adaptable software product lines using ruby
metaprogramming. In Proceedings of the 2Nd International Workshop on Feature-Oriented
Software Development, FOSD 10, pages 8087, New York, NY, USA. ACM.
Gurp, J. V., Bosch, J., and Svahnberg, M. (2001). On the notion of variability in software
product lines. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture,
WICSA 01, pages 45, Washington, DC, USA. IEEE Computer Society.
Hallsteinsen, S., Stav, E., Solberg, A., and Floch, J. (2006). Using product line techniques to
build adaptive systems. In Proceedings of the 10th international on Software Product Line
Confer.
Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic software product lines.
Computer, 41(4), 9395.
Istoan, P., Nain, G., Perrouin, G., and Jezequel, J.-M. (2009a). Dynamic software product lines
for service-based systems. In Proceedings of the 2009 Ninth IEEE International Conference
on Computer and Information Technology - Volume 02, CIT 09, pages 193198, Washington,
DC, USA. IEEE Computer Society.
Istoan, P., Nain, G., Perrouin, G., and Jezequel, J.-M. (2009b). Dynamic software product lines
for service-based systems. In Proceedings of the 2009 Ninth IEEE International Conference
on Computer and Information Technology - Volume 02, CIT 09, pages 193198, Washington,
DC, USA. IEEE Computer Society.
Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., and Peterson, A. S. (1990). Featureoriented domain analysis (foda) feasibility study.
53
REFERENCES
Keepence, B. and Mannion, M. (1999). Using patterns to model variability in product families.
IEEE Softw., 16(4), 102108.
Lee, J. (2013). Dynamic feature deployment and composition for dynamic software product
lines. In Proceedings of the 17th International Software Product Line Conference Co-located
Workshops, SPLC 13 Workshops, pages 114116, New York, NY, USA. ACM.
Lee, J., Whittle, J., and Storz, O. (2011). Bio-inspired mechanisms for coordinating multiple
instances of a service feature in dynamic software product lines. pages 670683.
Linden, F. J. v. d., Schmid, K., and Rommes, E. (2007). Software Product Lines in Action:
The Best Industrial Practice in Product Line Engineering. Springer-Verlag New York, Inc.,
Secaucus, NJ, USA.
M. Hinchey, P. S. and Schmid, K. (2012). Building dynamic software product lines. IEEE
Computer, 45(10), 2226.
McKinley, P. K., Sadjadi, S. M., Kasten, E. P., and Cheng, B. H. C. (2004). Composing adaptive
software. Computer, 37(7), 5664.
Muthig, D. and Patzke, T. (2003). Generic implementation of product line components. In
Revised Papers from the International Conference NetObjectDays on Objects, Components,
Architectures, Services, and Applications for a Networked World, NODe 02, pages 313329,
London, UK, UK. Springer-Verlag.
Northrop, L. M. (2002). Seis software product line tenets. IEEE, 19(4), 3240.
Parra, C., Blanc, X., and Duchien, L. (2009). Context awareness for dynamic service-oriented
product lines. In Proceedings of the 13th International Software Product Line Conference,
SPLC 09, pages 131140, Pittsburgh, PA, USA. Carnegie Mellon University.
Pohl, K., Bckle, G., and Linden, F. J. v. d. (2005). Software product line engineering: Foundations, principles and techniques.
R.Wolfinger, S.Reiter, D. P. H. and Doppler, C. (2008). Suporting runtime system adaptation through product line engineering and plug-in techniques1. In Proceedings of the 7th
International Conference on Composition-Based Software Systems (ICCBSS), pages 2130.
Schmid, K. (2007). Requirements engineering implications of dynamic software product lines.
In DSPL Workshop. IEEE Computer Society.
54
REFERENCES
Svahnberg, M., van Gurp, J., and Bosch, J. (2005). A taxonomy of variability realization
techniques: Research articles. Softw. Pract. Exper., 35(8), 705754.
Talib, M. A., Nguyen, T., Colman, A. W., and Han, J. (2010). Requirements for evolvable
dynamic software product lines. In Software Product Lines - 14th International Conference,
SPLC 2010, Jeju Island, South Korea, September 13-17, 2010. Workshop Proceedings (Volume
2 : Workshops, Industrial Track, Doctoral Symposium, Demonstrations and Tools), pages
4346.
55

Monografia Ufba Matheus Lessa

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Monografia Ufba Matheus Lessa

Enviado por

Direitos autorais:

Formatos disponíveis

Undergraduate Program in Computer Science

"A VIABILITY STUDY ON DYNAMIC SOFTWARE

Matheus Lessa Gonalves da Silva

Federal University of Bahia

MATHEUS LESSA GONALVES DA SILVA

"A VIABILITY STUDY ON DYNAMIC SOFTWARE

B.Sc. Dissertation presented to the Undergraduate

Advisor: Eduardo Santana de Almeida

Machines take me by surprise with great frequency.

Foundations on Software Product Lines and Dynamic Software Product Lines

3.2.2.1 Physical Layer . . . . . . .

SPL framework processes. Extracted from (Pohl et al., 2005)

DSPL Feature Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Implementation Techniques Survey Responses . . . . . . . . . . . . . . . . . . 48

Feature-Oriented Domain Analysis

Software Product Lines

Dynamic Software Product Lines

Software Product Lines Engineering

Software Configuration Management

Feature-Oriented Software Development

Dynamic Software Product Lines Engineering

operates in a predefined configuration space.

1.3. OVERVIEW OF THE PROPOSED SOLUTION

Overview of the Proposed Solution

In order to accomplish the goal of this dissertation, we propose an approach to an DSPL

Statement of the Contributions

As result of this work, the following contributions can be highlighted

1.7. DISSERTATION STRUCTURE

The remainder of this dissertation is organized as follows:

1.7. DISSERTATION STRUCTURE

Figure 1.1: Research Design

Software Product Lines (SPL)

(Northrop, 2002) defines Software Product Lines (SPL) as:

2.1. SOFTWARE PRODUCT LINES (SPL)

SPL Motivation and Benefits

2.1. SOFTWARE PRODUCT LINES (SPL)

2.2. VARIABILITY IN SOFTWARE PRODUCT LINES

Figure 2.2: Essential product line activities (Northrop, 2002)

Variability in Software Product Lines

Variability is an essential property in domain artifacts of SPLE. As defined by (Pohl et al.,

2.2. VARIABILITY IN SOFTWARE PRODUCT LINES

2.3. DYNAMIC SOFTWARE PRODUCT LINES (DSPL)

Dynamic Software Product Lines (DSPL)

2.3. DYNAMIC SOFTWARE PRODUCT LINES (DSPL)

DSPL Motivation and Benefits

2.3. DYNAMIC SOFTWARE PRODUCT LINES (DSPL)

DSPL Development Cycle

2.3. DYNAMIC SOFTWARE PRODUCT LINES (DSPL)

Figure 2.3: Connected DSPL Overview from (Pohl et al., 2005)

Figure 2.4: Disconnected DSPL Overview from (Pohl et al., 2005)

3.2. THE DOMAIN

"Active" implies "Alarm"

Figure 3.1: DSPL Feature Model

"Notify" implies "DataConnection"

3.2. THE DOMAIN

3.2. THE DOMAIN

Figure 3.2: SmartHomeRiSE Architecture

3.2. THE DOMAIN

Figure 3.3: Scale Model

The SmartHomeRiSE Arduino Communication Framework can be seen as an intermediate

3.2. THE DOMAIN

Figure 3.4: Hardware Programmatic Abstraction Model

3.2. THE DOMAIN