UNIVERSIDADE FEDERAL DA BAHIA DISSERTAÇAO DE …§ão... · de execu¸caõ por meio da gestaõ...

UNIVERSIDADE FEDERAL DA BAHIA

UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA

DISSERTACAO DE MESTRADO

On the Implementation of Dynamic Software Product Lines: An

Exploratory Study

MICHELLE LARISSA LUCIANO CARVALHO

Programa Multi-Institucional de Pos-Graduacao em Ciencia da

Computacao

Salvador

Janeiro/2016

MICHELLE LARISSA LUCIANO CARVALHO

ON THE IMPLEMENTATION OF DYNAMIC SOFTWARE

PRODUCT LINES: AN EXPLORATORY STUDY

M.Sc. Dissertation presented to

the Multi-institutional Master Pro-

gramme in Computer Science at Fed-

eral University of Bahia and Feira de

Santana State University in partial

fulfillment of the requirements for the

degree of Master of Science in Com-

puter Science.

Advisor: EDUARDO SANTANA DE ALMEIDA

Salvador

Janeiro/2016

!!"

" "#$$%" #&'(&)*+,"-!.*/))/"0&'!11&"02.!&3+4"" 53"6*/"!78)/7/36&6!+3"+9":;3&7!."1+96<&'/"8'+:2.6"

)!3/1="&3"/>8)+'&6+';"162:;"?"-!.*/))/"0&'!11&"02.!&3+"#&'(&)*+4"@"A&)(&:+',"BC%D4"

" %%E"94"="!)4".+)+'4"" "

5'!/36&:+'="F'+94"G:2&':+"A&36&3&":/"H)7/!:&""

" I!11/'6&JK+"L7/16'&:+M"@"N3!(/'1!:&:/"O/:/'&)":&"P&*!&4"G1.+)&"F+)!6Q.3!.&?R316!626+":/"-&6/7S6!.&,"BC%D4"

"" %4"A+96<&'/"T"8'+:26+14"B4"R78)&36&JK+"T"7/.&3!17+14""

$4" A+96<&'/" T" :/1/3(+)(!7/36+4" R4" H)7/!:&," G:2&':+"A&36&3&":/4"RR4"N3!(/'1!:&:/"O/:/'&)":&"P&*!&4"RRR4"UV62)+4"

"" #II="CCW4$""

O!.*&".&6&)+X'S9!.&4"

Aos meus pais, Magali M. Luciano Carvalho

e Valmir de Jesus Carvalho.

AGRADECIMENTOS

”Tudo tem o seu tempo determinado, e ha tempo para todo proposito debaixo do ceu”

(Eclesiastes 3:1). Foi muito difıcil a trajetoria pra chegar ate aqui, mas consegui. Agradeco

primeiramente a Deus, pois Ele me deu forcas para nao desistir e sabedoria para fazer um

trabalho com diligencia.

Agradeco aos meus amados pais Magali e Valmir pelo apoio incondicional e paciencia.

Meus pais sao fundamentais para o meu crescimento pessoal e evolucao academica.

Agradeco a minha irma Laısa pelos conselhos e companhia. Como minha melhor

amiga, minha irma esta sempre presente e me da os melhores conselhos.

Agradeco a cada um dos meus amigos e familiares pela compreensao. Diversas vezes

precisei renunciar a companhia de todos com o intuito de concluir o mestrado.

Agradeco tambem ao professor Eduardo por ter acreditado em mim do comeco ao fim.

Amadureci muito com os ensinamentos.

Agradeco aos meus colegas do RiSE. A ajuda de cada um foi essencial para fechar esse

ciclo.

Finalizo meus agradecimentos com as sabias palavras de William Douglas e Rubens

Teixeira: ”O importante e saber o que quer. Sem objetivos nao existe progresso. E preciso

ter desejos, sonhos, planos. Se voce tiver uma visao e de fato implementa-la, estara

lancando as bases do seu sucesso.”

vii

“You cannot be anything you want to be. But, you can be everything

God wants you to be.”

—MAX LUCADO

RESUMO

A abordagem de Linhas de Produto de Software Dinamicas (LPSD) propoe desenvolver

Linhas de Produto de Software (LPS) que incorporam artefatos reutilizaveis e dinamica-

mente reconfiguraveis. O objetivo central de LPSD e tratar adaptabilidade em tempo

de execucao por meio da gestao de variabilidade, bem como maximizar a reutilizacao de

componentes. Por esta razao, identificar a solucao mais adequada para a implementacao

de LPSD implica na reducao da complexidade dos sistemas auto-adaptaveis e promove

benefıcios para os cenarios de reutilizacao e evolucao. No entanto, as mudancas inerentes

podem influenciar significativamente as configuracoes de LPSD, nomeadamente em termos

de componentes existentes e modelos de adaptacao. Neste sentido, cada nova funcionali-

dade adicionada deve ser mapeada para recursos existentes, minimizando assim os efeitos

de mudancas em cascata.

Embora a literatura apresente alguns estudos de implementacao nesse contexto, falta

a caracterizacao de mecanismos de acordo com os requisitos de LPSD. De fato, os

desenvolvedores precisam contar com um conjunto de mecanismos para lidar com a

variabilidade dinamica. Ademais, as pesquisas existentes comecaram recentemente a

investigar a necessidade de continuamente evoluir LPSD. No entanto, para o melhor do

nosso conhecimento, nenhuma das pesquisas existentes conduziram estudos empıricos para

avaliar quantitativamente o impacto de diferentes solucoes neste contexto.

A fim de entender e reduzir as questoes mencionadas, nos investigamos as areas de

LPS e LPSD para identificar quais mecanismos de implementacao tem sido abordados

para gerenciar a variabilidade dinamica. Neste sentido, um conjunto de criterios foi

desenvolvido visando caracterizar esses mecanismos e auxiliar os desenvolvedores na etapa

inicial do desenvolvimento de LPSD. Alem disso, um estudo exploratorio foi conduzido

a fim de investigar como as solucoes orientada a aspectos e orientada a objetos afetam

fatores relacionados a qualidade de codigo em um projeto de LPSD implementado no

domınio de casas inteligentes.

As principais constatacoes do estudo mostraram que a solucao orientada a aspectos

fornece artefatos com menor complexidade, baixo acoplamento, boa coesao, e apoiam

menor impacto de propagacao de mudanca. Por outro lado, os pacotes na solucao

xi

xii RESUMO

orientada a aspectos foram mais suscetıveis a mudancas do que na solucao orientada a

objeto, resultando em menor estabilidade.

Palavras-chave: Linhas de Produtos de Software Dinamica, Variabilidade Dinamica,

Sistemas Auto-adaptaveis, Mecanismos de Implementacao, Evolucao de Software, Estudo

Exploratorio.

ABSTRACT

The Dynamic Software Product Lines (DSPL) approach proposes to develop Software

Product Lines (SPL) that incorporates reusable and dynamically reconfigurable artifacts.

The central purpose of DSPL is dealing with adaptability at runtime through variability

management, as well as maximize the reuse of components. For this reason, identifying the

most suitable solution to implement DSPL implies in the reduction of the self-adaptable

systems complexity, and promotes benefits to the reuse and evolution scenarios. However,

the inherent changes may significantly influence DSPL settings, particularly in terms

of existing components and adaptation models. In this effect, every new feature added

should be mapped to existing assets, thus minimizing the ripple effects of changes.

Although the literature presents some implementation studies in this context, it lacks

the characterization of mechanisms according to DSPL requirements. In fact, developers

need to rely on a set of mechanisms to cope with dynamic variability. In addition, the

existing research recently started to investigate the need for continuously evolving DSPL.

Nevertheless, for the best of our knowledge, none of existing research conducted empirical

studies to quantitatively assess the impact of different solutions in this context.

In order to understand and reduce the aforementioned issues, we investigated SPL and

DSPL areas to identify which implementation mechanisms have been addressed to manage

the dynamic variability. In this sense, a set of criteria was developed aiming to characterize

these mechanisms for assisting developers at the early stage DSPL development. In

addition, an exploratory study was conducted in order to investigate how object-oriented

and aspect-oriented solutions can affect factors related to code quality in a DSPL project

implemented in the smart homes domain.

The main findings of the study showed that aspect-oriented solution provides assets with

lower complexity, lower coupling, good cohesion, and support lower change propagation

impact. On the other hand, the packages in aspect-oriented solution were more susceptible

to changes than in object-oriented solution, resulting in less stability.

Keywords: Dynamic Software Product Lines, Dynamic Variability, Self-adaptive

Systems, Implementation Mechanisms, Software Evolution, Exploratory Study.

xiii

CONTENTS

List of Figures xix

List of Tables xxi

List of Acronyms xxiii

Chapter 1—Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Statement of the Contributions . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Dissertation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2—Foundations on Software Product Lines and Dynamic Software Prod-

uct Lines 7

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Software Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Essential Activities and Benefits . . . . . . . . . . . . . . . . . . . 9

2.2.2 Development Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Commonalities and Variabilities in SPL . . . . . . . . . . . . . . . . 11

2.3 Dynamic Software Product Lines (DSPL) . . . . . . . . . . . . . . . . . . 13

2.3.1 Essential Activities and Benefits . . . . . . . . . . . . . . . . . . . 13

2.3.2 Development Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3 Dynamic Variability . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 SPL and DSPL Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Differences and similarities between SPL and DSPL . . . . . . . . . . . . 17

xv

xvi CONTENTS

2.6 SPL and DSPL Implementation . . . . . . . . . . . . . . . . . . . . . . . 19

2.6.1 Implementation Activities . . . . . . . . . . . . . . . . . . . . . . 20

2.6.2 Variability Implementation . . . . . . . . . . . . . . . . . . . . . . 20

2.7 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 3—An investigation of Mechanisms for Implementing DSPL Variability 23

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Observations from Research . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Characterization Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Towards Characterization of DSPL Implementation Mechanisms . . . . . 29

3.4.1 Variability Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4.2 Mechanisms Characterization . . . . . . . . . . . . . . . . . . . . 34

3.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 4—An Exploratory Study in the Smart Home Domain 39

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Exploratory Study Definition . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.2 Research Questions (RQs) . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.3 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.4 Criteria for the Assessment . . . . . . . . . . . . . . . . . . . . . 46

4.3 Exploratory Study Planning . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1.1 Feature Model. . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1.2 Reconfiguration Rules. . . . . . . . . . . . . . . . . . . . 49

4.3.1.3 Reference Architecture. . . . . . . . . . . . . . . . . . . . 51

4.3.1.4 Domain Architecture. . . . . . . . . . . . . . . . . . . . 54

4.3.1.5 Model composition. . . . . . . . . . . . . . . . . . . . . . 56

4.3.1.6 Implementation. . . . . . . . . . . . . . . . . . . . . . . 56

4.3.2 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3.3 Variable Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3.4 Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3.5 Training requirements . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.6 Quantitative Analysis Mechanisms . . . . . . . . . . . . . . . . . 65

4.4 Procedures and Protocols for Data Collection . . . . . . . . . . . . . . . 65

CONTENTS xvii

4.5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.6 Analysis and Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.6.1 Complexity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.6.2 Cohesion Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.6.3 Coupling Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.6.4 Package stability Analysis . . . . . . . . . . . . . . . . . . . . . . 80

4.6.5 Modularity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.6.6 Change Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . 87

4.6.7 Hypothesis testing . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.7 Main findings of the study . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.8 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.9 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.9.1 Construction validity . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.9.2 Internal validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.9.3 External validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.9.4 Conclusion validity . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.10 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Chapter 5—Conclusions 97

5.1 Main contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.2.1 Approaches for Variability Management and Implementation . . . 98

5.2.2 Smart Home Domain . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.2.3 Empirical Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.3 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Appendix A—Dynamic Software Product Lines in practice 115

A.1 Feature Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

LIST OF FIGURES

1.1 Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Essential product line activities from Northrop (2002) . . . . . . . . . . . 9

3.1 Literature Review Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Metrics Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 SmartHomeRiSE Feature Model . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 SmartHomeRiSE Reference Architecture . . . . . . . . . . . . . . . . . . . 52

4.4 SmartHomeRiSE Domain Architecture . . . . . . . . . . . . . . . . . . . . 54

4.5 Arduino Communication Framework . . . . . . . . . . . . . . . . . . . . 55

4.6 SmartHomeRiSE Class Model . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.7 Exploratory Study Design . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.8 Boxplots for Weighted Operation per Component (WOC) . . . . . . . . . . 71

4.9 Boxplots for Number of Code Lines (LOC) . . . . . . . . . . . . . . . . . 72

4.10 Boxplots for Lack of cohesion of operations (LCOO) . . . . . . . . . . . . 75

4.11 Boxplots for Coupling between components (CBC) . . . . . . . . . . . . 77

4.12 Boxplots for Response for a Class (RFC) . . . . . . . . . . . . . . . . . . 78

4.13 Boxplots for Depht of Inheritance Tree (DIT) . . . . . . . . . . . . . . . 80

4.14 Boxplots for Instability metric (IM) . . . . . . . . . . . . . . . . . . . . . 82

4.15 SoC mean values through SmartHomeRiSE evolution. . . . . . . . . . . . 84

4.16 Probability plots for SoC metrics . . . . . . . . . . . . . . . . . . . . . . 86

xix

LIST OF TABLES

2.1 Adapted from M. Hinchey and Schmid (2012) . . . . . . . . . . . . . . . 18

3.1 Characterization Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Analysis of Variability Implementing Mechanisms. . . . . . . . . . . . . . 35

4.1 Reconfiguration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Summary of Configurations at Runtime . . . . . . . . . . . . . . . . . . . 52

4.3 Reuse and Maintenance Scenarios in SmartHomeRiSE. . . . . . . . . . . . 67

4.4 WOC Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.5 LOC Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.6 LOCC Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.7 CBC Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.8 RFC Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.9 DIT Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.10 IM Descriptive Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.11 Summary of the SmartHomeRiSE implementation . . . . . . . . . . . . . . 88

4.12 Comparison between OO and AO according to Mann-Whitney Test . . . 90

4.13 Comparison among OO and AO releases according to Kruskal-Wallis Test . 91

xxi

LIST OF ACRONYMS

AFM Aspectual Feature Models

AOP Aspect-Oriented Programming

CC Conditional Compilation

DCL Dynamic Class Loading

DLL Dynamic Link Libraries

DP Design Patterns

DOP Delta-Oriented Programming

DSPL Dynamic Software Product Lines

FODA Feature-Oriented Domain Analysis

FOP Feature-Oriented Programming

FOSD Feature-Oriented Software Development

GQM Goal-Question-Metric

OOP Object-Oriented Programming

SCM Software Configuration Management

SOA Service-Oriented Architecture

SoC Separation of Concerns

SPL Software Product Lines

SPLE Software Product Lines Engineering

xxiii

Chapter

1The past does not have to be your prison. You have a voice in your destiny. You have a say in your life.

You have a choice in the path you take. — Max Lucado

INTRODUCTION

The Dynamic Software Product Lines (DSPL) approach aims to develop self-adaptive

systems by using the Software Product Lines Engineering (SPLE) principles (Hallsteinsen

et al., 2008). The software reuse community has proposed this promising research field as

an effective strategy to deal with reconfiguration at runtime.

By using the DSPL approach, software engineers can identify the reusable and dy-

namically reconfigurable core assets at development time, which are explicitly modeled

and developed as dynamic variability (Shen et al., 2011). In this sense, the SPL models

and variability management practices are used in order to deal with the design and

implementation of software changes that need to be handled at runtime.

The DSPL application proposes variability customization through configuration and

reconfiguration of runtime instances (i.e., the binding decisions occur within current

system during execution). The existing literature (Cetina et al., 2008, 2010; R.Wolfinger

and Doppler, 2008; Lee, 2013; Capilla et al., 2014) has already addressed how to manage

the development of DSPL, or deal with domain models and architecture. Nonetheless,

few attention has been given on how to deal with dynamic variability management that

DSPL require at the source code level (Bencomo et al., 2012).

In this dissertation, we investigate such a problem in details and propose a contribution

to DSPL development. This chapter contextualizes the focus of this work and starts

by presenting its motivation and a clearer definition of the research problem, in Section

1.1. Next, Section 1.2 provides details of the dissertation statement, highlighting the

1

2 INTRODUCTION

research goals. We present the steps taken to conduct this work in Section 1.3. The main

contributions are listed in Section 1.4. Section 1.5 describes the issues are not directly

addressed by this work, and finally Section 1.6 outlines the dissertation structure.

1.1 MOTIVATION

The adoption of suitable mechanisms to manage the dynamic variability bring advantages

such as performance, flexibility, and reuse (Apel et al., 2013). Some mechanisms as well

as paradigms, such as polymorphism, reflection, and service-oriented architecture are

known for enabling the implementation of variability in the context of DSPL. Nonetheless,

the developers have few information to decide which mechanism or paradigm should be

chosen in different situations. We argue that the choice of the correct solution can lead to

significant impacts on quality attributes of DSPL.

The mechanisms should be able to cope with dynamic features that affect several

modules and require modification of several components. Further, it should also detect

and resolve interactions among features. However, a research challenge for DSPL is to

find suitable variability mechanisms to support dynamic variability in the underlying

architecture and implementation (Tom Dinkelaker and Mezini, 2010).

Additionally, DSPL need to be continuously evolved in order to adopt new technologies

or meet new requirements. However, evolving DSPL poses significant challenges, such as

inconsistencies with respect to adaptation rules and directly impact on the running system

(Quinton et al., 2015). In this way, existing research recently started to investigate this

topic (Helleboogh et al., 2009; Capilla et al., 2014; Quinton et al., 2015). Nevertheless,

they focus on discussing variability models. None of them conducted empirical studies to

quantitatively assess the impact of different solutions for DSPL evolution. Thus, more

research in this topic is necessary, and in fact, it is the focus of this dissertation.

1.2 OBJECTIVE

The main goal of this dissertation is to conduct an exploratory study to quantitatively

asses the impact of different solutions under software quality on DSPL evolutionary

scenarios.

The research has the following specific objectives:

• Presenting a holistic overview of the existing studies that had been re-

ported regarding the variability mechanisms.

1.3 RESEARCH DESIGN 3

• Characterizing the variability mechanisms that can be handled in the

context of DSPL.

• Comparing the object-oriented and aspect-oriented solutions for DSPL

evolution.

1.3 RESEARCH DESIGN

The research design approach defined for this work is showed in Figure 1.1 and it can be

described through five main steps:

Figure 1.1: Research Design

The first stage aimed to investigate the DSPL field, as well as complementary ap-

proaches for an understanding of the conceptual and technical aspects. As a result, we

defined the second chapter with some foundations on these subjects.

From this initial study, we identified few work related to implementation activities in

the context of DSPL. In order to overcome this problem, we carried out a more specific

investigation targeted to variability implementation mechanisms. This review allowed us

to define criteria to characterize available mechanisms in the existing literature.

Next, we developed a DSPL project in the smart homes domain considering both,

domain engineering and application engineering processes. Finally, in order to investigate

how object-oriented and aspect-oiented solutions can affect factors related to code quality,

we conducted a quantitative assessment. It focused on the measures, such as size, cohesion,

coupling, separation of concerns, and instability.

1.4 STATEMENT OF THE CONTRIBUTIONS

As a result of the work presented in this dissertation, a list of the main contributions may

be enumerated:

• The definition of a set of criteria to characterize variability implementa-

tion mechanisms in the context of DSPL.

4 INTRODUCTION

The set of criteria was developed in order to characterize the variability mechanisms

addressed in few related work. These criteria are based on existing literature and

consist of one of the main contributions of this study.

• An initial characterizing of implementation mechanisms addressed to

dynamic variability.

Although the literature reports DSPL implementation studies, it lacks from charac-

terization of mechanisms according to the DSPL requirements. The mechanisms

characterization can assist developers in a preliminary stage of the DSPL.

• An assessment for comparing paradigms to implement DSPL through an

exploratory study.

It is essential to identify a better solution to implement DSPL applications aiming

to increase the software quality. In this sense, we conducted an exploratory study

in the smart home domain, from which we were able to understand the impact of

using different paradigms in the DSPL evolution.

In addition to the contributions mentioned, a paper presenting part of the findings of

this dissertation was accepted for publication:

• LESSA, Matheus; CARVALHO, Michelle; SANTOS, Alcemir; ALMEIDA, Eduardo.

SmartHomeRiSE: An DSPL to Home Automation. In: VI Brazilian Confer-

ence on Software: Theory and Practice. Tools Section. 2015, Belo Horizonte.

Moreover, we are currently submitting other papers to report the remaining results.

1.5 OUT OF SCOPE

As evolution on DSPL is part of a broader context, a set of related aspects will be left out

of its scope. Thus, the following issues are not directly addressed by this work:

• Software Product Lines. In this work, we conducted an exploratory study to

quantitatively assess the impact of different paradigms, such as object-oriented and

aspect-oriented for implementing DSPL evolution. Although the DSPL can also be

built as an SPL, this work has adopted a single infrastructure.

• Variability mechanisms. In this dissertation, we characterized a set of variability

mechanisms considered more suitable to implement DSPL. Nonetheless, not all of

1.6 DISSERTATION STRUCTURE 5

them were covered in our exploratory study, such as Dynamic Class Loading, Dyna-

mic Link Libraries, Feature - oriented Programming, Service - oriented Architecture,

(Delphi) Properties, Plug-in, and Delta. In order to implement a DSPL project, we

combined the following mechanisms: Polymorphism, Aggregation, Parametrization,

Design Patterns, and Reflection.

• Evolution impact analysis on the running system. This work was concerned

to investigate the impact of evolving in the context of DSPL at source code level.

Thus, the evolution aspects on the running system was not covered by our work.

• Evolving the DSPL automatically. In the exploratory study, we evolved a DSPL

application into releases. Although evolving the DSPL is tedious and error-prone,

our work did not focus on automating the evolution task and reuse.

1.6 DISSERTATION STRUCTURE

The remainder of this dissertation is organized as follows:

• Chapter 2 presents an overview about SPL basic concepts as well as DSPL, its

motivations, activities and benefits. The implementation activities in these contexts

are also discussed beyond the similarities and differences between both SPL and

DSPL aiming for understanding of the connection.

• Chapter 3 presents the basic concepts and key issues involved with the usage of

variability mechanisms in the context of DSPL. Moreover, it describes in details

the criteria defined to characterize variability mechanisms. Finally, it reports the

mechanisms considered most suitable to cope with variability in this context.

• Chapter 4 discusses the exploratory study to evaluate the applicability of two

solutions to implement DSPL considering evolutionary scenarios. The exploratory

study planning, protocol, data collection, data analysis, and outcomes are described

in details.

• Chapter 5 provides the concluding remarks. It presents the main contributions

and outline directions for future work.

• Appendix A describes some details of the exploratory study performed, such as

the SmartHomeRiSE features, its priorities and relationship with other features.

Chapter

2One of the major keys to success is to keep moving forward on the journey, making the best of the detours

and interruptions, turning adversity into advantage. –John C. Maxwell

FOUNDATIONS ON SOFTWARE PRODUCT LINES

AND DYNAMIC SOFTWARE PRODUCT LINES

2.1 INTRODUCTION

The competitiveness of the market and diversification in software development has been

a key issue for employing new engineering practices. In this way, some companies in

the software industry have adopted the Software Product Lines Engineering (SPLE)

approach aiming faster product development with high quality and low cost.It consists

of an emergent software engineering paradigm promoting reuse through the software life

cycle. SPLE allows that development companies supply the large demand of software

systems using platforms and mass customization (Pohl et al., 2005).

The SPLE cycle includes two main processes (Pohl et al., 2005): domain engineering

and application engineering. While the former aims to define which artifacts are common

and which ones are variable, the latter derives the products by using the common and

variable artifacts defined in domain engineering. The local where the variation occurs

represents the variation points that allow to include variable artifacts. The variation

ability is known as variability. It consists of a characteristic, in which can be common

only in some products (Linden et al., 2007). Moreover, this variability is often expressed

in terms of features, and it also appears to be high level abstractions that shape the

reasoning of stakeholders (Classen et al., 2008).

The variability management is an important activity that differentiates SPL from the

conventional software engineering. Its purpose is to identify, design, implement, and trace

7

8FOUNDATIONS ON SOFTWARE PRODUCT LINES ANDDYNAMIC SOFTWARE PRODUCT LINES

the flexibility in the SPL. The development of product lines, however, need to be adapted

to new requirements given the emergence of new technologies and services which cope

with flexible adaptation of software and changing needs.

This chapter presents the basic concepts and ideas involved with SPL and DSPL

approaches. Section 2.2 presents the concepts related to SPL. Next, in Section 2.3 the

concepts related to DSPL are discussed. Section 2.4 discusses about evolution in the

context of DSPL. Section 2.5 presents an overview about the differences and similarities

between both, SPL and DSPL. Section 2.6 describes SPL and DSPL implementation and

its activities. Finally, the chapter summary is presented in Section 2.7.

2.2 SOFTWARE PRODUCT LINES

According to Northrop (2002), Software Product Lines are families of software products

that share a set of common features and they can efficiently attend to software mass

customization. SPL are developed based on core assets, e.g., reusable software components,

domain models, architecture description, requirements statements, specifications, and

documentation. Each member of the SPL is known as a variant, which is instantiated

according to its needs and rules of the common architecture. The reference architecture

consists of a large number of components that can be connected through interfaces and

provide support to mass customization (Pohl et al., 2005).

The concept of software families was first introduced by Dijkstra and Parnas. Dijkstra

(1972) proposed a model of family-based development where differences in design decisions

distinguished family members. Parnas (1976) characterized families as groups of items

that are strongly related by their commonalities, where commonalities are more important

than the variations among family members. In addition, Kang et al. (1990) contributed

with the SPL concept introducing the Feature-oriented Domain Analysis (FODA) method.

The FODA method uses the result of the identification and classification of commonalities

and variabilities in the software domain to build assets.

The purpose of the use of SPLE is to reduce the engineering overall effort to produce

a set of similar products, through planned software reuse. The fundamental principles

of SPLE practices 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.2 SOFTWARE PRODUCT LINES 9

2.2.1 Essential Activities and Benefits

The development of an SPL involves three essential activities: Core Asset Development,

Product Development and Management (Northrop, 2002), which are showed in Figure 2.1.

Each rotation circle represents one key activity. All three are connected together as they

would in motion, showing that all three are closely related and highly interactive.

The main difference between this one and the aforementioned approach is the manage-

ment activity. This management throughout the development encompasses the separation

of the product line in three parts: common components, variable parts, and individual

products as their own specific requirements.

• Core Asset Development: it consists in analyzing the SPL domain and searching

the reuse opportunities within of the scope, motived by the domain engineering.

• Product Development: it is part of the application engineering and focus on com-

bining and configuring the core assets to develop specific components to instantiate

a new product.

• Management: an activity that supports and coordinates the Core Asset activity

and Product Development.

Figure 2.1: Essential product line activities from Northrop (2002)


Linden et al. (2007) stated that companies usually adopt the SPL approach strongly

based on economic considerations. SPL support large-scale reuse, which implies on lower

costs, shorter time to market and improve the quality of the resulting products. Despite

of these benefits, it is necessary some initial investment, which requires to build reusable

assets changing the organization. The use of the SPL usually reaches a break-even after

about three products.

Pohl et al. (2005) define some benefits in adopting the SPL approach:

• Reduction of development cost.When core assets are reused in different products

generated, the cost to create all the system is reduced.The costs to develop few

systems in SPLE are higher than in traditional software engineering. However, using

SPL approach, the costs are significantly lower for larger systems quantities.

• Quality improvements. The reusable assets get more tested as the number of

product increases. This implies significantly in the detection and correction of faults,

thereby increasing the quality of the product.

• Reduction of time-to-market. The product release time is significantly reduced

when it is relies on the SPL approach. Initially, the time is high because it is

necessary to develop reusable artifacts. Afterwards, the time to market is reduced

because many artifacts are reused to build new products.

• Reduction of Maintenance Effort. When an artifact is modified, the changes

are propagated for all products. In SPL, it is possible to reuse test procedures that

decrease the maintenance effort.

2.2.2 Development Cycle

The principles of SPLE comprises two processes (Pohl et al., 2005):

• Domain Engineering: It aims at defining what is common in all the products,

and based on the similarities build domain artifacts that can serve as basis for

building individual products.

• Application Engineering: It aims to build applications through reuse by using

domain artifacts and variability defined in domain engineering with the intent of

attending different needs of market and individual customers.

2.2 SOFTWARE PRODUCT LINES 11

2.2.3 Commonalities and Variabilities in SPL

SPLE establishes a systematic software reuse strategy. The goal is to identify commonality

(common functionality) and variability points among applications within a domain, and

build reusable assets to benefit future development efforts (Pohl et al., 2005). Core assets

are considered the essence of the SPL (Northrop, 2002). They consist of configurable

elements of an SPL such as architecture, reusable software components and, domains

models, where the architecture is the main element of this set. Linden et al. (2007)

separate the variability in three types, as follows:

• Commonality: common assets to all the products.

• Variability: common assets to some products.

• Specific products: it is required for a specific member of the family (it cannot be

integrated in the set of the family assets).

In the SPL context, both commonalities and variabilities are specified through features.

A feature consists of a prominent or distinctive user-visible aspect, quality or characteristic

of a system (Kang et al., 1990). SPL engineers consider features as central abstractions for

the product configuration, since they are used to trace requirements of a customer to the

software artifacts that provide the corresponding functionality. In this sense, the features

communicate commonalities and differences of the products between stakeholders, and

guide structure, reuse, and variation across all phases of the software life cycle (R.Wolfinger

and Doppler, 2008; Apel et al., 2013).

According to Kang et al. (1990); Muthig and Patzke (2003), features can be classified

as follow:

• Mandatory feature: it represents the common functionality that must be pre-

sented in all products of the family.

• Optional feature: it represents a functionality that may be part of a product.

• OR feature group: it allows the selection of one or more features of this group.

• XOR (alternative) feature group: They are mutual-exclusive functionality, i.e.,

it belongs to a group of features from which no more than one feature must be

selected.


The variability is viewed as being the capability to change or customize a system. It

allows developers to delay some design decisions, i.e., the variation points. A variation

point is a representation of a variability subject, for example, the type of lighting control

that an application provides. A variant identifies a single option of a variation point.

Using the same example, two options of lighting control can be chosen for the application

(e.g., user or autonomic lighting) (Pohl et al., 2005).

Although the variation points identified in the context of SPL hardly change over

time, the set of variants defined as objects of the variability can be changed. This is the

SPLE focus, i.e., the simultaneous use of variable artifacts in different forms (variants) by

different products (Gurp et al., 2001).

The variability management is an activity responsible to define, represent, explore,

implement, and evolve SPL variability (Linden et al., 2007) by dealing with the following

questions:

• Identifying what vary, i.e., the variable property or variable feature, which it is the

subject of the variability.

• Identifying why it varies, based on needs of the stakeholders, user, application, and

so on.

• Identifying how the possible variants vary, which are objects of the variability

(instance of a product).

Another important concept in variability of SPL is the binding time. It consists

of the moment 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: compilation,

linking, and runtime. These binding times are explained as follows:

• Compile-time: Select the variant before the actual program compilation or at

compile-time;

• Link-Time: Select the variant during module or library linking (i.e., the variability

point is bound at link time when a compiled module is linked to the variability

point);

• Runtime: Select variant during program execution (i.e., at any time during the

use of the system, functionality may be added, deleted, or both).

2.3 DYNAMIC SOFTWARE PRODUCT LINES (DSPL) 13

Dynamic adaptive systems (highly configurable) increase the need to deal with variabi-

lity at runtime, because it modifies its internal structures dynamically, and consequently,

its behaviour in response to internal and external incentives (McKinley et al., 2004). For

this reason, some researchers introduced the dynamic SPL approach to deal with changes

in the environment and the user requests during runtime.

2.3 DYNAMIC SOFTWARE PRODUCT LINES (DSPL)

Emerging domains, such as mobile, ubiquitous computing, and software-intensive em-

bedded systems demand high degree of adaptability from software. The capacity of

these softwares to reconfigure and incorporate new functionality can provide significant

competitive advantages. This new trend market requires SPL to become more evolvable

and adaptable (Bosch and Capilla, 2012). More recently, DSPL became part of this

emerging domains.

The DSPL approach has emerged within the SPLE field as a promising means to develop

SPL that incorporates reusable and dynamically reconfigurable artifacts (Hallsteinsen

et al., 2008). Thus, researchers introduced the DSPL approach enabling to bind variation

points at runtime. The binding of the variation points happens initially when software is

launched to adapt to the current environment, as well as during operation to adapt to

changes in the environment (Hallsteinsen et al., 2008).

According to M. Hinchey and Schmid (2012), the DSPL practices are based on: (i)

explicit representation of the configuration space and constraints that describe permissible

configurations at runtime on the level of intended capabilities of the system; (ii) the

system reconfiguration that must happen autonomously, once the intended configuration

is known; and (iii) at the traditional SPLE practices.

2.3.1 Essential Activities and Benefits

The development of a DSPL involves two essential activities: monitoring the current

situation for detecting events that might require adaptation and controlling the adaptation

through the management of variation points. In that case, it is important to analyze the

change impact on the product’s requirements or constraints and planning for deriving a

suitable adaptation to cope with new situations. In addition, these activities encompass

some properties, such as automatic decision-making, autonomy and adaptivity, and context-

awareness (Hallsteinsen et al., 2008; Bencomo et al., 2012).

The runtime variability can help to facilitate automatic decision making in systems


where human intervention is extremely difficult or impossible. For this reason, the DSPL

approach treats automatic decision making as an optional characteristic. The decision

to change or customize a feature is sometimes left to the user (Bosch and Capilla, 2012).

However, the context awareness and the autonomy and adaptability are treated at the

same way.

The adoption of a DSPL approach is strongly based on adapting to variations in

individual needs and situations rather than market forces and supporting configuration

and extension capabilities at runtime, which implies on more flexible changes software to

changing needs (Hallsteinsen et al., 2008; M. Hinchey and Schmid, 2012). Given these

characteristics, DSPL would benefit from research in several related areas. For example,

it can provide the modelling framework to understand a self-adaptive system based on

Service-oriented Architecture (SOA) by highlighting the relationships among its parts, as

well as, in the automotive industry where the need for post deployment, dynamic and

extensible variability increases significantly (Bosch and Capilla, 2012; Baresi et al., 2012;

Lee et al., 2012).

2.3.2 Development Cycle

The processes within DSPL life cycle differ from the processes of the traditional SPLE.

A DSPL is not built as part of an SPL (at development time), i.e., its architecture is

a single system architecture which provides a basis for all possible adaptations of the

system (Hallsteinsen et al., 2008). It means that the whole variability may be achieved at

runtime.

Both domain engineering and application engineering processes aim the systematic

development of the system and its use by exploring the adaptability. The principles of

DSPL characterize the processes as follows (M. Hinchey and Schmid, 2012):

• Domain Engineering: process that identifies the possible adaptations and their

triggers, besides the set of possible system reactions, focusing on construction.

• Application Engineering: handle the variations in such a way that the system

itself performs the reconfiguration.

The DSPL must be able to consult the dynamic variability model defined in the

domain engineering in order to identify possible adaptations. Accordingly, the reference

architecture must support the variations described by the variability model and provide

support for the entire range of adaptations handled during application engineering. The

2.3 DYNAMIC SOFTWARE PRODUCT LINES (DSPL) 15

reference architecture is a core asset that takes the entire development process into

account, since it provides a basis to check the validity of configurations according to

context conditions (Cetina et al., 2009b).

2.3.3 Dynamic Variability

Dynamic variability occurs due to product variations that appears in the execution

environment or the product itself. These variations depend on the 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).

Systems in DSPL should be prepared to identify contexts unknown at design time.

After that, systems must be prepared to add dynamically new features to meet new

requirements or simply to improve the current state of the system when new features

become available (Bencomo et al., 2008b). The simple transition from an SPL where

the variability is bounded at development time to a system that adapts its behavior by

binding variability at runtime has several consequences. 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 (M. Hinchey and Schmid, 2012).

Bencomo et al. (2008b) associated 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) 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 organize the current configuration.

Additionally, it is possible to divide dynamic adaptation in two different types: (i)

dynamic behavior, the systems deal with new environmental conditions unknown dur-

ing development; and (ii) dynamic reconfiguration, it is necessary that variations of

behavior be predetermined before execution. During the execution, the current state

of the system is evaluated and the appropriate variants are chosen (Bencomo et al., 2008b).

Implications for Dynamic Reconfiguration. According to Bosch and Capilla

(2012), the following factors often imply that earlier versions of systems components can

be replaced by new versions:


• Variation points change during the system operation (i.e., they become increasingly

dynamic);

• The set of variants for a variation point can be extended after system deployment

and while the system is operating;

• Systems increasingly select the variation as they seek to maintain or achieve certain

adaptation.

Therefore, the products generated from DSPL provide new variants and different

configurations dynamically. System features can trigger reconfigurations at runtime when

needed, and these features can adapt system behavior to different scenarios. These

reconfigurations consist of activating, deactivating, and updating of the systems features

(Istoan et al., 2009a).

The evolution capability has so far not been investigated in details in the context of

DSPL. However, it can be addressed aiming to investigate its impact. Emerging domains

require changes and extensions to the design in terms of both functionality and adaptation

capabilities. DSPL should deal also with the evolution of user needs and execution

environments in ways not foreseen at the time of initial design (Bencomo et al., 2012).

The DSPL approach can make easier the modification of the system implementation

when is needed to change the initial configuration space. Thus, it is possible to integrate

further adaptation capabilities by exploiting the variability model due to the open varia-

bility, since it consists of extending the system with new variations at runtime (Bencomo

et al., 2012). Such changes can be the addition, removal or modification of products or

transitions among products. The time when a mechanism is open for adding new variants

is mainly decided by the development and runtime environments, and the type of feature

that is represented by the variation point (Gurp et al., 2001).

2.4 SPL AND DSPL EVOLUTION

The change is part of SPL development. It can be initiated in order to correct, improve,

or extend assets or products. Many of the practices of a successful SPL initiate, manage,

or consume these changes. Both conceptual techniques and software tools are available to

assist in the management of these changes (McGregor, 2003).

Evolution has been widely studied in SPL context. Most existing work has focused

on the evolution of problem space (Svahnberg and Bosch, 2000). However, evolving

a variability model may also affect the solution space and vice versa. The problem

2.5 DIFFERENCES AND SIMILARITIES BETWEEN SPL AND DSPL 17

space refers to the system’s specifications established during the domain analysis and

requirements engineering phases, whereas the solution space refers to the related assets

created during the architecture, design, and implementation phases (Berg et al., 2005).

In contrast, existing research only recently started to investigate evolution in the

context of DSPL, and especially its impact on the running system. Evolving DSPL poses

significant challenges as both problem and solution spaces. The evolution of problem or

solution spaces can lead to inconsistencies within the given space, between spaces, and

with respect to rules for the runtime adaptation of the system (Quinton et al., 2015).

Variability models that are used in a DSPL have to co-evolve and be kept consistent

with the systems they represent to support reconfiguration even after changes to the

systems at runtime (Quinton et al., 2015). However, there is limited work to support

co-evolution. For instance, a set of evolution of the problem space and the solution

space as well as remapping operators to avoid inconsistencies between the two spaces are

described in Seidl et al. (2012).

Helleboogh et al. (2009) proposed the notion of super-types to describe the evolution

of variability models at runtime. Capilla et al. (2014) use super-types to automate the

modification of variants in a feature model at runtime. However, these approaches are

limited to a given set of changes e.g., the addition of a variant, as other kinds of changes

cannot be automated (Heider et al., 2012).

Talib et al. (2010) present a classification of required operations for jointly evolving

problem and solution space in a DSPL. However, they use the general term variability

model to describe any model of the variability of a software system. In addition, they

analyzed the impact of evolution operations on the consistency of the DSPL and an

architecture of a tool-supported approach that addresses some issues and supports the

evolution of DSPL.

They presented some requirements for DSPL and categorized them in terms of dynamic

reconfiguration and evolution. However, these requirements do not take into consideration

quality aspects. The DSPL approach offer automated product reconfiguration capabilities

but are not evolvable in the sense that they lack support for unanticipated change. In

general, the evolution in this context encompasses addition and update of features or

maintenance tasks. In this way, it is important to investigate these issues in more detail.

2.5 DIFFERENCES AND SIMILARITIES BETWEEN SPL AND DSPL

Although the central concept of DSPL is a traditional SPL, there are differences between

both approaches. SPL and DSPL are compared based on variability goals, binding time,


the stakeholders who decide the variability, models that define the variation points or

control the adaptations, and mechanisms to implement the variation points (Bencomo

et al., 2012).

A product derived from DSPL differs of others instantiated from SPL by the capacity to

adapt through the binding of variation points at runtime. In order to manage the variability

in DSPL, it is necessary to create reconfiguration rules, i.e., 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 (including safety, reliability and performance) (Lee et al., 2011).

DSPL are similar to traditional SPL regarding to reconfiguration focused on functional

capabilities. However, the variability is not simply an engineering artifact that is present

before runtime. DSPL must be able to consult the variability model to identify adaptation,

because this model is the core artifact for guiding system adaptation (M. Hinchey and

Schmid, 2012). Table 2.1 shows the relationships between both approaches.

Table 2.1: Adapted from M. Hinchey and Schmid (2012)

.

Software products lines Dynamic software products lines

Variability management describesdifferent possible systems.

Variability management describes different adaptationsof the system.

Reference architecture provides acommon framework for a set of indi-vidual product architectures.

DSPL architecture is a single system architecture,which provides a basis for all possible adaptationsof the systems.

Business scoping identifies the com-mon market for the set of products.

Adaptability scoping identifies the range of adaptationthe DSPL supports.

Two life cycle approach describestwo engineering life cycles, one fordomain engineering and for applica-tion engineering.

The DSPL engineering life cycles aims at systematicdevelopment of the adaptive system, and the usage lifecycle exploits adaptability in use.

According to M. Hinchey and Schmid (2012), the difference between SPL and DSPL

is based on a set of innovations, including: (i) variability modeling, wich describes the

differences among the systems; (ii) reference architecture that supports the variations;

(iii) business scoping that encompasses the understanding of entire domain or business

field, and (iv) both life cycles, such as domain engineering and application engineering.

Additionally, a product obtained from a traditional SPL to a specific configuration can

be quite tested before reaching the hands of the user. However, a product generated from

DSPL provides new variants and different configurations, which are obtained at runtime.

2.6 SPL AND DSPL IMPLEMENTATION 19

In this way, any flaw in reconfiguration of DSPL directly impacts the user experience,

because it happens when the system is already under its control (Cetina et al., 2010).

Thus, some studies have been performed to investigate the aspects of reconfiguration of

product lines at runtime aiming to deliver high-quality software (Buregio et al., 2010;

Tom Dinkelaker and Mezini, 2010; Lee and Kang, 2006; Cetina et al., 2008, 2010).

The removing and changing of product features are some examples of reconfiguration

for SPL. These features are bound statically, where the user selects the desired features.

Then, a generator creates the corresponding software product containing exactly the

necessary features (R.Wolfinger and Doppler, 2008). In the context of DSPL, however,

the product dynamic reconfiguration refers to remove and change the features developed

in runtime, i.e., it updates dynamically the system configuration after deployment (Istoan

et al., 2009a).

DSPL does not deal with an entire SPL in the traditional sense. It is considered as a

single system that adapts its behavior when the variability is rebound during operation

(Pena et al., 2007). The dynamic reconfiguration approach uses a mapping of DSPL

features for components that normally are handled at the implementation (Lee, 2013). In

addition, it allows the developer specifies adaptation rules for reconfiguration components.

Thus, the selection of mechanisms that support the runtime decisions consists of an

important activity. These mechanisms (e.g., design patterns, polymorphism, frameworks,

aspects) should manage and configure the dynamic variability satisfying the requirements

defined at architectural level. In addition, it must enable to implement the variation

points to adapt the applications according to the reconfigurable artifacts.

2.6 SPL AND DSPL IMPLEMENTATION

According to Pohl et al. (2005), the SPL implementation is based on the reference

architecture. It determines software reusable parts in the development of applications.

The development of SPL has the focus on the detailed design and the implementation of

reusable software assets, such as components and interfaces, which are implemented after

its validation. Although these are the main assets, other such as database tables, data

streaming formats, and protocols are also considered reusable software assets (Pohl et al.,

2005; Clements and Northrop, 2001).

SPLE encompass variability mechanisms enabling the implementation to select the

variants and build an application with the reusable artifacts. The key purpose of variability

mechanisms consists of minimizing code duplication, the reuse effort, and maintenance

effort. In general, variant characteristics require a generic implementation, which thus


contain some variant code (Muthig and Patzke, 2003).

2.6.1 Implementation Activities

The SPL implementation requires the management of commonality and variability among

a set of related products. The reference architecture has to map the domain requirements,

involving variation points, supporting platform, and mass customization. In addition, the

derivation of products should support to deliver products fast and customized to specific

customers. In order to develop applications is based on reusable artifacts, Pohl et al.

(2005) identified three important activities, as follows:

• Realizing Interfaces. Interfaces deal with common aspects of the components

(i.e., it determines functionalities for a number of components through a contract

between the parts). In this context, the interface can be used to access the variability

realized in components. The variability is implicitly through the independent abilities

of having variability both at the providing components side and at the requiring

side. Thus, the interface itself is an invariant and both the providing and requiring

components have to interpret it in the same way (Pohl et al., 2005). It means that

the components are responsible to encapsulate variants and decide which variant

can be exposed for the interface.

• Realizing Variable Components. The variability of the SPL has to be realized

in terms of reusable components. The interfaces provided and required constrain the

component design. In many cases, several variants of the component are realized,

where each of them combines certain variants (Pohl et al., 2005). According to

Clements and Northrop (2001), the component development provides the required

variability in the developed components through the use of variability implementation

mechanisms based on specific feature types.

• Compilation. This activity aims to compile the components into object files.

In order to perform it, the component and its interfaces must be designed and

implemented correctly following specific guidelines. Therefore, these objects files

are linked into working executable during application realization (Pohl et al., 2005).

2.6.2 Variability Implementation

Variability implementation is the last activity of domain realization. The implementation is

done based on the design of the components and interfaces. In addition, these components

2.6 SPL AND DSPL IMPLEMENTATION 21

and interfaces are implemented in program files. The realization of variability can be

performed in many ways and defines different binding times. It is important that the

reference architecture provides clear guidelines to implement it (Pohl et al., 2005).

In order to promote the handling of variability at code level, the binding time of the

variability must be known. In this case, after the identification of the feature type and

the binding timing, it is important to determine the parameters of variation, namely

what exactly is varying, and the variation points (i.e., the locations where changes occur)

(Sharp, 2000). According to Gacek and Anastasopoules (2001), the composition rules of

the variability must also be reflected at the code level, and be instantiated when creating

product instances.

Additionally, the feature implementation is usually spread across many source files

and modules. Therefore, the main parameters of variation are identified in the interfaces

and its corresponding implementation. Since the type of feature and binding time are

made known, a certain implementation mechanism can be recommended or not (Gacek

and Anastasopoules, 2001; Sharp, 2000).

In the same way that happens in SPLE, the DSPL implementation is based on the

reference architecture. However, the DSPL architecture provides explicit and deterministic

support for the entire range of adaptation, referred to as adaptability scoping (M. Hinchey

and Schmid, 2012). When developing a DSPL, the ultimate goal is to make it flexible

enough to be adapt at runtime as well as to meet new user requirements on request. For

this reason, the dynamic variability and possible system reactions need to be anticipated

in advance in order to achieve flexibility.

The variability on DSPL can be represented through dynamic features. These features

can be activated, deactivated, or updated at runtime. However, a research challenge is to

find variability mechanisms that support the implementation of these dynamic features

(Tom Dinkelaker and Mezini, 2010). In the context of DSPL, the implemented components

are usually more complex than components in a traditional SPL, since the latter provides

adaptable and highly configurable features (Bosch and Capilla, 2012).

The selection of an specific variability mechanism should be based on a systematic

analysis of technical requirements, constraints, the context where the mechanism can

be used, and the binding time (Gacek and Anastasopoules, 2001), since many existing

challenges address the introduction of variability mechanisms on DSPL. Automating and

validating runtime variability are hard tasks. Moreover, open variability models must be

flexible enough to support better the evolution of software products and post-deployment

changes, including runtime binding and rebinding (Gurp et al., 2001).


The proposed solutions in the existing literature benefit the variability management and

implementation, however, many challenges remain. Overall, researchers have conducted

several studies to investigate the aspects of SPL reconfiguration at runtime aiming to deliver

more adaptable and configurable software (Buregio et al., 2010). In this way, this current

dissertation investigates and discusses variability mechanisms to the implementation of

DSPL.

2.7 CHAPTER SUMMARY

This chapter presented an overview about SPL beyond basic concepts related to common-

alities and variabilities. It included the motivations and benefits for applying the SPLE

practices in software development. These practices have the focus on the detailed design

and the implementation of reusable software assets and encompass variability mechanisms

that enable the implementation to select the variants and build an application with the

reusable artifacts. In this sense, the variability management activity is considered essential

for the entire SPL life cycle.

This chapter also presented an overview about DSPL beyond basic concepts related

to runtime variability. It included the motivations and benefits for applying the DSPL

approach in software development that requires increasingly adaptation in runtime. More-

over, it included the basis for understanding the connection between both, SPL and DSPL

discussing its similarities and differences, evolution aspects, and implementation activities.

Next chapter presents the characterization of more suitable mechanisms considered

to implement dynamic variability. It includes a set of criteria defined for our study that

aims at assisting the software engineers at the early stage of DSPL implementation.

Chapter

3Don’t wait for inspiration.—John C. Maxwell

AN INVESTIGATION OF MECHANISMS FOR

IMPLEMENTING DSPL VARIABILITY

3.1 INTRODUCTION

The internal structures of systems that can adapt to new contexts are dynamically modified

and, consequently its behavior in response to internal and external stimulus which are

changes at the environment and adaptations according to user needs (Hallsteinsen et al.,

2008). DSPL appears to be an appropriate way to achieve and manage the dynamic

variability that can happen in a predefined configuration space.

Additionally, the DSPL approach allows its variants to reconfigure themselves during

their execution (Bencomo et al., 2008a). These variations depend on the context that the

system is inserted. Contexts are accessible information and computationally extracted by

monitoring the execution environment and the current state of the product. In this sense,

an adaptation to a given context corresponds to a product configuration in DSPL (Alves

et al., 2009).

The emergence of unpredicted feature(s) in the new variants (dynamically generated)

can cause configuration errors (Cetina et al., 2010), for example: (i) unexpected software

behavior; (ii) poor performance; and (iii) services that do not support users needs or

the adaptability scoping (i.e., context, triggers for adaptation, and reactions that system

should support) (Montero et al., 2008). The errors usually impose to the developers the

need to anticipate which characteristics of the potential available mechanisms cope with

the adaptations known beforehand.

23

24 AN INVESTIGATION OF MECHANISMS FOR IMPLEMENTING DSPL VARIABILITY

Although the literature reports DSPL implementation studies, it lacks from characteri-

zation of mechanisms according to the DSPL requirements (e.g., active/deactivate/update

features and control of the dynamic variability). In fact, developers need to rely on a set

of mechanisms to cope with such dynamic behavior. In this sense, a set of criteria was

developed in order to characterize the variability mechanisms addressed in the literature.

These criteria is based on existing literature and aim at assisting developers at the early

stage of DSPL implementation.

Thus, this chapter presents the basic concepts and key issues involved with the usage

of variability mechanisms in the context of DSPL. Section 3.2 presents observations from

research. Section 3.3 describes the characterization criteria developed for this dissertation.

The main findings are discussed in Section 3.4. Finally, Section 3.5 concludes the chapter.

3.2 OBSERVATIONS FROM RESEARCH

The research on DSPL increasingly has progressed in terms of investigating architectural

and dynamic reconfiguration aspects. Bencomo et al. (2012) provided an overview of

the existing DSPL landscape based on a study of the existing literature in this area. In

particular, the map this work in terms of types of contributions, their maturity, and

challenges. As a result, it was built a preliminary conceptual model that combines a

classic SPL model with the MAKE-K model for autonomic computing.

According to this work some areas, such as algorithm development and tool support

still lack extensive work and not in real industrial use yet. In addition, more studies

are found on software architecture, which combines service orientation and adaptation,

meta-models, and domain-specific languages. The authors state that many challenges

remain, but the results of future studies can take the next generation of DSPL to new

levels of autonomy, maintainability, and software reuse.

M. Hinchey and Schmid (2012) described many open issues on DSPL research including

the following: little support exist for DSPL evolution; approaches for runtime reconfigura-

tion, especially with respect to their relation to the overall system architecture; enlarging

modeling of the configuration options to capture context description and decision making;

DSPL reconfiguration has focused mainly on functional capabilities, while addressing

quality characteristics to only a limited extent; dealing with overly constrained situations

at runtime remains a concern and; how to better extend variability modeling so that

developers can use it as a basis.

Silva et al. (2013) analyzed and classified existing literature on DSPL area, defined

inputs that are needed to perform the dynamic derivation, described what composes these

3.2 OBSERVATIONS FROM RESEARCH 25

inputs, and presented the understanding of the process to perform the dynamic derivation.

This systematic literature review has been confirmed that variability management composes

a challenge to the DSPL development, mainly regarding to handle the variability over the

implementation phase.

Figure 3.1: Literature Review Design


In order to understand and reduce the aforementioned issues, we investigated SPL and

DSPL areas aiming to identify key aspects related to variability management, especially

which implementation mechanisms are addressed to manage the dynamic variability. Figure

3.1 shows the literature review design. From this assessment, we identified candidate

mechanisms to implement DSPL.

According to Gacek and Anastasopoules (2001); Sharp (2000) certain implementation

mechanism can be recommended or not when the binding time is made known. Since the

dynamic variability is achieved at runtime, we decided to use initially the binding time

as a criterion to select the candidate mechanisms to a characterization in the context of

DSPL.

The mechanisms used to implement variability achieved only at compile-time were not

considered. A set of additional criteria was defined in order to support the characterization

of the variability mechanisms and identify which of them are most suitable.

3.3 CHARACTERIZATION CRITERIA

Developers have adopted mechanisms at conceptual level to implement dynamic variability,

aiming a good performance of the generated products (Hallsteinsen et al., 2006). However,

this task is not enough to deal with the self-adaptable systems complexity. In this

way, the choice of the most suitable implementation mechanism should be added in

the development process, besides of the characterization criteria, which can be used to

facilitate the selection.

Aiming at identifying the proper mechanism to implement dynamic variability, the

following characterization criteria were defined based on previous work (McKinley et al.,

2004; Svahnberg et al., 2005; Apel et al., 2013). McKinley et al. (2004) addressed key

challenges to compose adaptive Software; Svahnberg et al. (2005) proposed a taxonomy

for selecting a suitable method to implement variability in the context of SPL; and Apel

et al. (2013) described a suitable vocabulary to characterize implementation mechanisms.

Moreover, the criteria derived in this study focused on the characterization of the mech-

anisms regarding the development cycle, the main activities, and properties of DSPL

(M. Hinchey and Schmid, 2012).

Table 3.1 shows each criterion (CC01–CC06) used to characterize the available mecha-

nisms. The criteria are presented by discussing the following characteristics: attribute, a

characterization requirement; description, a short description of the criterion; question,

an important issue based on the criterion; and relevance, an important aspect which

needs to be considered.

3.3 CHARACTERIZATION CRITERIA 27

Table 3.1: Characterization Criteria

CC01 - Goal

Attribute: QualityDescription: It identifies if the mechanism attend to the quality attributes.

Question: Does the mechanism improve the application in terms of quality attributes?Relevance: Quality attributes: reusability, flexibility, performance, and maintainability.

CC02 - Stakeholder

Attribute: Domain and application engineersDescription: It identifies based on a DSPL life cycle if the mechanism is able to cope with

the dynamic features.Question: Does the mechanism support the designing and implementation of dynamic

features?Relevance: The dynamic features affect several modules and require modification of several

classes or components.

CC03 - Binding time

Attribute: TimeDescription: The moment in which the variation points are bound.

Question: What time the decision of the variability are solved?Relevance: It can be defined as compile time, linking time, or runtime.

CC04 - Variability type

Attribute: FunctionalityDescription: Adding, removing and updating the features at runtime.

Question: Does the mechanism support activation, deactivation, and updating of features?Relevance: The mechanism should be efficient to implement optional, OR, and alternative

features at runtime.

CC05 - Representation

Attribute: Annotation and Composition.Description: The annotation-based approach annotates the base of code such that the code

belonging to a certain feature is tagged in accordance, and based-compositionapproach implements features as composable units, preferably a unit for func-tion.

Question: What is the manner to represent the variability using the mechanism?Relevance: The combination between the annotation-based and composition-based ap-

proaches is possible.

CC06 - Adaptability assurance

Attribute: Dynamic variabilityDescription: The project requests a mechanism that ensures the adaptation.

Question: Does the variability mechanism support the reconfiguration of the features atruntime?

Relevance: The mechanism should ensure that the application is performed of safe andacceptable way during the adaptation process checking all specifications.


The CC01 - Goal criterion enables to verify whether the mechanism under evaluation

supports the dependability properties when the variation points are bound. It analyzes

whether the use of a given mechanism for DSPL implementation can impact on the system

quality regarding reusability ; flexibility ; performance; and maintainability requirements in

order to develop a consistent DSPL with high quality. Then, the target mechanism allows

adapting the application by checking the valid configurations and choosing the variant

that best meets to the adaptation goals.

The CC02 - Stakeholder criterion evaluates the variability mechanisms based on

the DSPL life cycle. It identifies whether an specific mechanism assists the domain and

application engineers in the designing and implementation of dynamic features. In the

context of DSPL, the domain engineer identifies the possible adaptations and its triggers,

besides the set of possible system reactions, focusing on construction. On the other hand,

the application engineer handles the variability implementation in such a way that the

system itself performs the reconfiguration. In this sense, the variability mechanisms should

allow to cope such dynamic behavior.

The decision of the variability can be solved at compile time, linking time, or runtime.

In addition, the CC03 - Binding time criterion intends to evaluate the mechanisms

regarding its support for the variability decision during the application execution. Further-

more, the CC04 - Variability type criterion evaluates whether an specific variability

mechanism allows adding, removing, and updating of variants dynamically. It means that

the corresponding code can be injected into the system at runtime and/or dropped from

the logical formula that connects the variant in the variability model.

According to Groher and Voelter (2007), the instantiation of products happens due to

negative variability (unselected features are removed or disabled) and positive variability

(assets are associated to features depending on its configuration). In fact, when developers

deal with addition, removal and update of functionality, they have to perform a careful

evaluation of the implementation mechanisms that are going to be used. Enabling or

disabling a feature requires the ability to detect changes, evaluate the different alternatives,

and execute the reconfiguration in a proper way (Schmid and Eichelberger, 2008).

The fifth criterion (CC05 - Representation) enables to characterize the mechanisms

according to their way to represent variability. Mechanisms that represent the features

through annotation enable all the code belonging to deselected features be ignored at

runtime, (i.e., support negative variability). In contrast, mechanisms that represent

features as composable units build a variant by performing the composition of units

associated with the selected features (i.e., support positive variability) (Apel et al., 2013).

3.4 TOWARDS CHARACTERIZATION OF DSPL IMPLEMENTATION MECHANISMS 29

Finally, the CC06 - Adaptability assurance criterion evaluates the mechanisms

according to their ability to assurance the integrity and security of the application. The

mechanism should permit the reconfiguration and the roll-back of adaptations that do not

mismatch the configuration rules (i.e., it should ensure that the application be performed

in a safe and acceptable way during the adaptation process checking all specifications).

3.4 TOWARDS CHARACTERIZATION OF DSPL IMPLEMENTATION MECH-

ANISMS

Components implemented on SPL engineering are usually more complex than components

in traditional software engineering. These components are easily adapted to fit different

products, since SPL supports a higher level of generalization. In addition, the selection of

an specific variability mechanisms is essential to implement components in this context.

It should be based on a systematic analysis of technical requirements, constraints, the

context where the mechanism can be used, and the binding time of the variability (Gacek

and Anastasopoules, 2001).

The simple and maintainable way to implement the variability should be taken into

consideration when determining the mechanisms that will be used (Pohl et al., 2005).

The variability mechanism can facilitate the dynamic adaptation and it should detect

and resolve interactions between features that arise for a set of dynamic contexts of

the configuration. In addition, variability mechanisms should also be able to cope with

dynamic features that affect several modules and require modification of several classes or

components in the DSPL (Tom Dinkelaker and Mezini, 2010).

The implementation activities in the context of DSPL encompass variability mecha-

nisms, which change the variants dynamically in a controlled way and with none or minimal

human intervention. As a result, the software architect is able to know which runtime

changes affect which system features (Bosch and Capilla, 2012). The software reuse and

variability management mechanisms in an SPL context can be useful for developing some

types of self-adaptive systems.

Developers have used these mechanisms to implement variation points at runtime,

aiming a good performance of the products to be generated. However, more investigation

needs to be done. Among these mechanisms we can highlight: Polymorphism, Aggre-

gation/Delegation, Parametrization, Design Patterns (DP), Reflection, Dynamic Class

Loading (DCL), Dynamic Link Libraries (DLL), Feature - oriented Programming (FOP),

Service - oriented Architecture (SOA), Aspect, (Delphi) Properties, Plug-in, and Delta

(Gacek and Anastasopoules, 2001; Muthig and Patzke, 2003; Gomaa, 2004; Svahnberg


et al., 2005; R.Wolfinger and Doppler, 2008; Alves et al., 2009; Istoan et al., 2009b; Schaefer

et al., 2010; Apel et al., 2013; Muschevici et al., 2013). Since they are able to cope with

variability in runtime environments, we briefly introduce its concepts and discuss how

they support the implementation of dynamic variability, as follows.

3.4.1 Variability Mechanisms

Polymorphism. This mechanism represents a key element for design patterns and object-

oriented frameworks. It defines an interface (abstract class) as a common point of access

(Gacek and Anastasopoules, 2001). Polymorphism is implemented by virtual functions

in order to derive a class instance to override the base class instance. Its signature must

exactly match the base class virtual function. 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 overriding functions are virtual automatically.

Additionally, 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 class’s virtual functions

to become non-abstract. However, if a class is derived from an abstract class, this class

does not override all the pure virtual function in the base class, then this class is also an

abstract class (Svahnberg et al., 2005).

Design Patterns. It is a description or template concerning how to solve a problem

that can be used in many different situations (Gamma et al., 1995). It can be exploited in

the context of DSPL since many of them identify system aspects which may dynamically

vary, and offer reusable solutions for variability management (Gacek and Anastasopoules,

2001). Keepence and Mannion (2009) and Gurp et al. (2001) detail and use some patterns

to model the variability on SPL which can be also used in the context of DSPL.

Reflection. This mechanism 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 mechanism and can enable applications to perform operations

which would otherwise be impossible. The reflexive API incorporates structures that

represent all the language structure, besides be suitable to examine, modify its properties,

and control its implementation at runtime. In this way, it is possible the system obtains

information about its object type, attributes, constructors, and inheritance structures,


beyond dynamically load a new class, create new instances, and invoke methods (Svahnberg

et al., 2005).

In the context of DSPL, reflection is a mechanism strongly recommended, however,

their use should be handled carefully. The functionalities can be ”reflected” and manipu-

lated according to a configuration. Nevertheless, reflective systems are from their nature

difficult to understand, debug, and maintain (Svahnberg et al., 2005).

Aspect. Aspect-oriented Software Development (AOSD) is based on the aspect notion

as an abstraction aimed to modularize cross-cutting concerns and improve the system

reuse and maintenance. It addresses the problems caused by concerns that can be well

localized using classic implementation mechanisms. Classes and methods are further

implemented using these mechanisms. In addition, all other concerns that crosscut the

implementation of other concerns are implemented as aspects (Kiczales, 1996).

The most important AOSD concepts (Filman et al., 2004) are described as follows:

• Core: it is a base where the concerns are added using the aspects. A core corresponds

to the base modules of the system without aspects.

• Aspect: it is a modular unit designed to implement a concern. It eliminates code

scattering and tangling. Moreover, aspects can affect multiple other concerns with

one piece of code, thereby avoiding code replication.

• Join point: it consists of a well defined place in the structure or execution flow of

a program where additional behavior can be bound. The most common elements

of a join point model are method calls, though aspect languages have also defined

join points for a variety of other circumstances including field definition, access,

modification, exceptions, execution events and states.

• Pointcut: it describes a set of join points. A point-cut allows developers, for

example, to mark a specific set of methods, where they want their aspects advice

code to be implemented.

• Advice: an advice is like a method of an aspect that encapsulates the instructions

that are executed at a set of join points. Pieces of advice are bound to point-cuts

that define the set of predefined join points being advised.

• Inter-type declaration: an inter-type declaration injects a field, method or inter-

face from inside an aspect into an existing interface or class.


• Weaving: the application and aspects are combined using an aspect weaver, forming

an executable program. Weaving can happen in different ways depending on the

mechanisms used to implement it. For example, weaving can take at runtime, linking

the aspects while the base code is being executed.

AOP supports the dynamic selection of aspects at runtime (Damiani et al., 2012). In

the context of DSPL, dynamic crosscuts run additional code when certain events occur

at runtime. The semantics of dynamic crosscuts are commonly described and defined in

terms of an event based model (Lammel, 1999). The program executes different events

that are called join points. Examples of joint points are: variable reference, variable

assignment, execution of a method body, method call, etc. A pointcut is a predicate that

selects a set of joint points. Advice is code executed before, after, or around each joint

point matched by a pointcut (Wand et al., 2004).

Aggregation/Delegation. Aggregation enables objects to virtually support any

functionality by forwarding requests they can normally not satisfy to so-called delegation

objects which provide the requested services. Variability can be handled by means of

putting the standard or mandatory functionality in the delegating object and the variant

functionality in the delegation object (Gacek and Anastasopoules, 2001).

(Delphi) Properties. They are attributes of an object. A special kind of delegation

is achieved when properties are used to delegate implementation of an interface to a prop-

erty in the class that claims to implement the interface. In this case the property refers to

a class really implementing the interface. The selection of the referenced class can be done

at runtime depending for instance on the user’s interface (Gacek and Anastasopoules, 2001).

Delta. The Delta-oriented programming (DOP) is based on the delta modules notion

encapsulating changes to object-oriented programs. It provides the connection of the

delta modules with the products and a dynamic reconfiguration graph. A product for

a particular feature configuration is obtained by applying the relevant delta modules

incrementally to the empty product. Thus, DOP is considered as a compositional approach

and can be seen as an extension of feature-oriented programming (FOP). However, it

supports more flexible changes of functionality at runtime (Damiani et al., 2012).

Dynamic DOP supports evolution of DSPL to runtime reconfiguration. New feature

configurations can simply be added and existing feature configurations can be removed at

runtime. Also, existing implementations of features provided by specific delta modules


can be modified dynamically. In order to guarantee that the product will behave consis-

tently with respect to the new feature configuration after reconfiguration, the runtime

environment for dynamic DOP automatically checks whether a reconfiguration is safe.

Additionally, it updates existing objects allocated on the heap if the layout of the respective

classes is changed during a reconfiguration without requiring to halt the running system

(Damiani and Schaefer, 2011).

Plugin. This mechanism supports software extensibility, customizability, and evolu-

tion. Plug-in enables developers to build DSPL that support extensions and customization

through addition, removal, and replacement of components at runtime. In this sense, the

plug-in platform facilitates runtime adaptation and composition by loading and unloading

of plug-ins. DSPL are used to modeling high-level adaptation decisions together with

their technical implications and present them to users in easy-to-use wizard-like dialog

(Wolfinger et al., 2008).

SOA. By using SOA the variability is supported through specifying variants as services

and service binding as an additional kind of variation point, and specifying types for

variants. The use of services is motivated by the fact that services can be defined, invoked,

and composed considering their well-defined interfaces, but without considering their

implementation. A variant type describes when and where the variation will occur as well

as potential ranges for the variation (Galster, 2010).

In the context of DSPL, the variability management is supported by SOA principles.

It means that the variability could be supported and accelerated by dynamically adding

and integrating services. In this sense, it is considered as an effective way of designing

adaptable systems that can be reconfigured for contextual changes (Galster, 2010).

FOP. By using FOP a dynamic binding unit is tailored to an application scenario and

consists of a set of statically merged features. It is similar to a component but it includes

only required functionality (Apel et al., 2013). To yield a concrete program, a dynamic

binding unit is bound as a whole with other dynamic binding units at runtime. In this

way, a DSPL can be generated from an SPL statically selecting the features required for

dynamic binding and generating a set of dynamic binding units (R.Wolfinger and Doppler,

2008).

Additionally, flexible feature binding allows selecting features statically at compile-

time by using superimposition or dynamically at build-time using the decorator pattern.


However, runtime reconfiguration including an update of the heap structures according to

the new feature configuration is not supported (Damiani et al., 2012).

DLL. This mechanism consists of libraries that can be loaded when needed into appli-

cation at runtime. DLL can be useful for selection of variant functionalities. Separation

of variability is reached by developing distinct controls. In addition, the decision of which

control to load into an application is split across many others sub decisions (Gacek and

Anastasopoules, 2001).

DCL. This is a interesting mechanisms for a DSPL infrastructure, since the compo-

nents can be dynamically loaded. It provides the ability to install new components at

runtime and can be extremely useful in managing the components (Liang and Bracha,

1998). The traceability back to the decision model is therefore ensured (Gacek and

Anastasopoules, 2001).

Parametrization. Component behavior is determined by the values parameters are

being set to. The use of parameterization avoids code replication by centralizing design

decisions around a set of variables. It can be applied to make data types or object classes

flexible. In addition, this mechanism can enhance reusability and also ease traceability to

design decisions (Gacek and Anastasopoules, 2001).

3.4.2 Mechanisms Characterization

The set of candidate mechanisms aforementioned to implement variability in an DSPL

context was characterized. Table 3.2 presents its ranking according to the the criteria

(CC01–CC06). These mechanisms should support the automatic checking of generated

variants for correctness based on the reconfiguration rules previously established, which

ensure correct adaptations (Capilla et al., 2014). In this sense, this dissertation aims to

identify which implementation mechanisms are most suitable to manage the dynamic

variability.

The characterization of the mechanisms was performed based on previous research

(Gacek and Anastasopoules, 2001; Muthig and Patzke, 2003; Gomaa, 2004; Svahnberg

et al., 2005; R.Wolfinger and Doppler, 2008; Alves et al., 2009; Istoan et al., 2009b; Schaefer

et al., 2010; Apel et al., 2013; Muschevici et al., 2013) aiming to understand and identify

the main research related to mechanisms to implement variability achieved at runtime.

However, it is important to mention that this current work follows the default design


Table 3.2: Analysis of Variability Implementing Mechanisms.

MechanismCC01

CC02CC03 CC04 CC05

CC06A B C D E F G H I J L M

Polymorphism �� Aggregation � � �� Parametrization � � �� Reflection � � � �� Design Patterns � � � � � � � � � � � � � �DCL � � � � � � � � � � � � � �DLL � � � � � � � � � � � � � �FOP � � � � (?) � � �� (?)

SOA � � � � � � � � � � � � � �Aspect � � � � � � � � �� (Delphi) proper-ties

� � � � � � � � � � ��

Plug-in � � � � � � � � � � � � � �Delta � � � � (?) � � �� (?)

A: Reusability; B: Flexibility; C: Performance; D: Maintainability; ; E: Compile Time;F: Linking Time; G: Runtime; H: Removing Functionality; I: Adding Code (Optional);J: Substituting Code (Alternative); L: Annotation; M: Composition; �: Applicable; ��:Ineffective/Difficult; �: Not applicable; (?): Questionable.

of DSPL proposed by M. Hinchey and Schmid (2012) and does not support binding

of variability at compile time. Just implementation mechanisms targeted for dynamic

variability have been selected.

Table 3.2 shows a characterization summary of the mechanisms according to the char-

acterization criteria defined in the Section 3.3. From those requirements associated with

goal (CC01), performance is the requirement less accomplished. While the maintainability

and readability are provided by object-oriented mechanisms, performance is negatively

affected in more complex systems because of the great number of simultaneous accesses

(Lohmann et al., 2006). However, this deficiency can be fixed through the use of threads

with inheritance to load only dependencies necessary for request. Many mechanisms

accomplish the requirements, except the Polymorphism and Reflection. The former

is inefficient on promoting reuse, since it restricts reuse and performance (Gacek and


Anastasopoules, 2001); and the second is naturally hard to understand and consequently,

reduce the maintainability. In short, all mechanisms under review are efficient in this

matter.

Based on the stakeholder (CC02) criterion, the implementation mechanisms which

support variability achieved at runtime are suitable for DSPL. Accordingly to it, the

features can always exist in the final product, even if some of them are activated exclusively

during runtime. However, mechanisms, such as DP and SOA allow the domain engineers

to define reference architecture, whether in design decisions or frameworks (according

to possible adaptations) for the applications of a specific domain. The resolution of all

mechanisms should happen at the application engineering to define a technical architecture

according to particular requirements. Finally, only the use of FOP and Delta are still

questionable regarding to support (re)binding of features at runtime, since it corresponds

to mechanism still in experimental phase.

According to binding time (CC03) criterion, the mechanisms Aspect, Delta, Design

Patterns, SOA, Reflection, Delphi properties, and Aggregation can be used to

implement variability achieved in all the times. However, by only using this last one is

possible to achieve the binding at runtime in conjunction with DCL and DLL. Whereas

Polymorphism, DLL, and Parametrization are accomplished at compile time and runtime,

the DCL mechanism supports the variability timing just at runtime. In addition, the

resolution at runtime by using FOP is hard, likely can be possible with configuration files

or command-line parameters. Finally, the late binding time on DSPL favors flexibility

and it has been achieved with the usage of many mechanisms discussed in this study, as it

allows the binding of variation points at runtime.

Regarding to variability type (CC04) criterion, all the mechanisms are effective

to add features at runtime. However, removing features is not possible by using DLL

and ineffective by using Aspects. By using Parametrization, the selection among

alternative features are considered complicated tasks and error-prone, since the system

should control the decisions constants to be made and perform the change. In the same way,

the usage of Aggregation as well as Delphi properties (a delegation type addressed

to implementation of interface) to implement alternative features is inefficient.

In terms of representation (CC05), which is directly related to the variability type

(EC04), among the mechanisms inserted in the composition-based approach, we can high-

light Polymorphism, Design Patterns, DCL, DLL, SOA, Aspect, Delphi properties,

Plug-in, and Aggregation, since Parametrization can be inserted in the annotation-

based approach. Reflection and Delta mechanisms can be implemented by using both

3.5 CHAPTER SUMMARY 37

approaches.

Most mechanisms support the adaptability (CC06) of DSPL with exception of FOP,

because each variability type is implemented as increments in functionality and its binding

time at runtime is difficult. In addition, both FOP and Delta mechanisms have been

currently instrumented in the context of DSPL, thus it is not possible to ensure their

effectiveness. Based on such characterization, a set of these mechanisms was combined to

implement mandatory, alternative, or, and optional features through the definition

and planning of DSPL in the Smart Home domain.

Although characterization of different variability mechanisms is possible based on the

currently available literature, it is not simple to ensure the implementation of a given

variability. In a nutshell, more detailed analysis is required in order to support software

engineers in the implementation activities. Thus, the possible results obtained can be

integrated into the overall development process in the context of DSPL.

3.5 CHAPTER SUMMARY

The main goal this chapter was to perform a preliminary characterization of dynamic

variability implementation mechanisms in the context of DSPL. In this sense, a set of

criteria was developed in order to identify the most suitable mechanisms. These criteria

are based on existing literature and consist of one of the main contributions of this study.

The mechanisms characterization can assist developers in a preliminary stage of the DSPL.

In the next chapter, we present the design, planning, and results of the exploratory

study which aims to investigate the impact of different paradigms for DSPL evolution.

Chapter

4Strive for excellence, not perfection, because we don’t live in a perfect world. —Joyce Meyer

AN EXPLORATORY STUDY IN THE SMART HOME

DOMAIN

4.1 INTRODUCTION

The dynamicity of features implies on the DSPL lifecycle control, since many of them are

activated, deactivated, and updated at runtime. In this way, variability mechanisms can

be important to manage the DSPL lifecycle and map the variability aiming to support

reconfiguration. Thus, the choice of the most suitable mechanisms to implement dynamic

variability should be added as an important activity in the development process of a

DSPL. This activity aims to identify which of them reduce operating and maintainability

costs. As a result, it can be possible to ensure continual improvement for implementing

these systems.

DSPL (like any SPL) is a long-term investment that needs to continuously evolve to

meet requirements (Svahnberg and Bosch, 2000) or adopt new technologies (McGregor,

2003). However, the inherent changes may significantly influence DSPL settings, particu-

larly in terms of existing components and adaptation models (Quinton et al., 2015). In

this sense, every new feature added should be mapped to existing assets, thus minimizing

the ripple effects of changes. Nevertheless, for the best of our knowledge, none of existing

research conducted empirical studies to quantitatively assess, the impact of different

solutions under software quality on DSPL evolutionary scenarios. In addition, existing

research usually focuses on modeling variability (Capilla et al., 2014; Helleboogh et al.,

2009; Quinton et al., 2015).

39

40 AN EXPLORATORY STUDY IN THE SMART HOME DOMAIN

Wohlin et al. (2000) state that empirical studies in Software Engineering are key

strategies to the decision-making in an improvement seeking organization. It is performed

aiming to obtain objective and statistically significant results regarding the prediction,

understanding, controlling, and improvement of software development. Since some studies

have demonstrated the likely synergies between Aspect-oriented mechanisms and DSPL

(Voelter and Groher, 2007; Bartholdt et al., 2008; Morin et al., 2008; Tom Dinkelaker and

Mezini, 2010; Horcas, 2013), this chapter provides a quantitative assessment through an

exploratory study, aiming to investigate how object-oriented and aspect-oriented solutions

can affect factors related to code quality in a DSPL project. Our investigation focused on

the analysis of the following measures: size, separation of concerns, cohesion, coupling,

and instability.

In order to conduct the assessment, we organized the chapter following the concepts

proposed by Kitchenham et al. (1995); Kitchenham and Pickard (1998); Wohlin et al.

(2000); Juristo and Moreno (2010). The remainder of this chapter is organized as follow.

Section 4.2 presents the objective of the exploratory study, research questions, the

respective metrics, and criteria defined for the assessment. Section 4.3 describes the

planning of the exploratory study. Section 4.4 presents the procedures and protocols

defined for data collection. Section 4.5 describes the exploratory study operation steps.

Section 4.6 shows the analysis and the interpretation of the results. Section 4.7 presents

the main findings. Section 4.8 reports the lessons learned. Section 4.9 presents the validity

threats of the study and finally, Section 4.10 presents the chapter summary.

4.2 EXPLORATORY STUDY DEFINITION

The first activity of the exploratory study is responsible to state what is expected to

be achieved. It details the exploratory study in terms of problem and goal, as well as,

defining a set of research questions which will be answered based on the analysis (Wohlin

et al., 2000). The study is based on the analysis of one evolving DSPL. The DSPL was

developed from scratch and then it was adapted and implemented in aspect-oriented

design to complete the infrastructure setting.

4.2.1 Objective

The objective of an study states what is expected to be achieved as result (Runeson and

Host, 2009). The exploratory study was conduced based on the Goal-Question-Metric

(GQM) method (Basili et al., 1994), as follows:

4.2 EXPLORATORY STUDY DEFINITION 41

Goal: Analyze the aspect-oriented and object-oriented solutions to implement dyna-

mic variability for the purpose of evaluation of the source code with respect to their

size, separation of concerns, cohesion, coupling, and instability from the point of view

of Software Engineers and researchers in the context of an evolving DSPL.

Whereas the goal has already been defined, the questions that should be answered

and the corresponding metrics, will be described in the subsections as follows.

4.2.2 Research Questions (RQs)

The following questions were established in order to compare object-oriented and aspect-

oriented solutions in the evolution of DSPL.

RQ01. Does the aspect-oriented solutions provide less complex design than

object-oriented solutions?

RQ02. Does the use of aspect-oriented solutions provide more cohesive de-

sign than object-oriented solutions?

RQ03. Does the use of aspect-oriented solutions provide less coupled design

than the object-oriented solutions?

RQ04. Does the use of aspect-oriented solutions provide less instable pack-

age than object-oriented solutions?

RQ05. Does the use of aspect-oriented solutions provide more modular de-

sign than object-oriented solutions?

RQ06. Does the use of aspect-oriented solutions provide more stable design

than the object-oriented solutions?

RQ07. Does the use of aspect-oriented solutions has smoother change prop-

agation impact than the object-oriented solutions?


4.2.3 Metrics

The following metrics were established in order to compare object-oriented and aspect-

oriented solutions in the evolution of DSPL.

M01. Weighted Operation Count (WOC): The WOC metric was used to help

answering the questions RQ01 and RQ06. This metric measures the complexity of a

component based on its operations. It is an extension of the Weighted Method Count

(WMC) metric proposed by Chidamber and Kemerer (1994). However, WOC takes into

account the methods and advices of the aspect and treat them in the same way that

WMC treats the methods of the classes.

Specifically, the complexity of each operation is based on a number of parameters of

the operation. Whereas an operation without parameter has complexity equal to one, an

operation with parameter is equal to two, and so on. In this way, the measurement of

complexity assumes that an operation with more parameters than another operation is

probably more complex. Additionally, in aspect-oriented design not only methods and

advices inside the aspect are considered, but also methods inserted in the classes affected

by aspect through inter-type declarations.

The greater the number of complexity of the operations by component, more difficult is

to understand the system. In this way, it is harder to find the local where the source code

needs to be modified during the evolution activities. Moreover, the possibility of reuse

will be limited due to the difficulty for understanding the component implementation.

According to Chidamber and Kemerer (1994), a WOC value lower (0 and 10) is considered

acceptable for an application.

M02. Number of Code Lines (LOC): The LOC metric was used to help answering

the questions RQ01 and RQ06. This metric counts the number of code lines, and it is

a traditional measure of size. Comments concerning documentation or implementation

are not interpreted as code. Blank lines are also not counted. Programming style can

affect the results obtained by use this metric. Because of this, the same programming

style must be kept (Fenton and Pfleeger, 1998).

The greater the number of code lines, it is more difficult to understand the system, and

consequently, it is harder to find the lines that needs to be changed during the evolution

activities, and understand the implementation of functionalities that are desired to reuse.

M03. Lack of cohesion over operations (LCOO): The LCOO metric was used


to help answering the questions RQ02 and RQ06. This metric is an extension of the Lack

of Cohesion over Methods (LCOM) metric described in Chidamber and Kemerer (1994).

According to Sant’anna et al. (2003) and Figueiredo et al. (2008), this metric measures the

lack of cohesion of a component. Just like the WOC metric, the LCOO metric considerates

methods and advices inside the aspect, and methods inserted in the class affected by

aspect through inter-type declarations. In addition, it also treats methods and advices of

the aspect in the same way that LCOM treats the methods of the classes in object-oriented

design. Moreover, LCOO measures the amount of pairs of methods/advices that does not

access at least one same attribute.

Low cohesion in components increases complexity and results in errors during the

development process. The cohesion of methods/advices within a class/aspect is de-

sirable, since it promotes encapsulation. In addition, the lack of cohesion means the

component should probably be split into two or more sub components. It is easier to

maintain or reuse a component or one of its functions if the cohesion is high. According

to Chidamber and Kemerer (1994), a LCOO value lower than ten implies in a low cohesion.

M04. Coupling between components (CBC): The CBC metric was used to help

answering the questions RQ03 and RQ06. This metric is an extension of coupling metric

among objects (CBO), proposed by Chidamber and Kemerer (1994). The CBC metric was

adapted by Sant’anna et al. (2003) to deal with new coupling dimensions in aspect-oriented

software design. It counts the number of other components (class or aspect) to what it is

coupled. In this way, for each component, the CBC metric counts the number of other

classes or aspects that are used in attribute declarations, return types, formal parameters,

throws declarations, and local variables. In addition, it deals with classes or aspect that

are intercepted by the aspect defined in the pointcuts and classes that have attributes and

methods inserted through inter-type declarations. Based on these work, it is considered

acceptable the value CBC greater than six for a simple application.

The coupling between components should be low in order to provide the modularity

and promote encapsulation. Understanding a component involves another component, in

which it is coupled. In this way, the more independent component it is easier to reuse in

another application. This coupling measure is useful to determine how complex is the

testing of components. High coupling requires more rigorous tests.

M05. Response for a Class (RFC): The RFC metric was used to help answering

the questions RQ03 and RQ06. The RFC metric is a class coupling measure. This metric


measures the degree of communication among the classes of the system, i.e., it represents

the number of invoked methods by those class methods and the number of methods of a

class. RFC is the number of methods in the set.

In addition, the response set of a class consists of the set of methods invoked directly

by the methods in methods set of the class, that is, the set of methods that can potentially

be executed in response to a message received by that class. A variant of RFC excludes

methods indirectly invoked by a method (Chidamber and Kemerer, 1994). When a call is

made to a method that is affected by an aspect, that class invoke code described in the

aspect. These core-to-aspect invocations are counted when calculating RFC (Tsang et al.,

2004).

A large RFC has been found to indicate more faults, and the hard is its maintainability.

Classes with a high RFC are more complex and harder to understand. If a large number of

methods can be invoked in response to a message, the testing and debugging of the class

become complicated as it requires a greater level of understanding on the part of the de-

veloper. This metric is useful to evaluate understandability, maintainability, and testability.

M06. Depht of Inheritance Tree (DIT): The DIT metric was used to help

answering the questions RQ03 and RQ06. This metric has been extended by Sant’anna

et al. (2003) based on the metric proposed by Chidamber and Kemerer (1994) which has

the same name. In the aspect-oriented design, the DIT metric considers the inheritance

between aspects. It is defined as the maximum length from the node to the root of the

tree. In addition, it measures how many ancestor classes/aspects can potentially affect

this class/aspect.

It is more difficult to predict the behavior of a class/aspect that is deeper in the

hierarchy due to greater number of methods/advices that it is likely to inherit. The reuse

potential of inherited methods/advices of classes/aspects particular is great, since it is

deeper in the hierarchy. Deeper trees result in greater design complexity, since more

classes/aspects and methods/advices are involved. In short, the maximum value of DIT

should be maintained low (ten or less), in order to facilitate the comprehensibility of the

system.

M07. Instability Metric (IM): The IM metric was used to help answering the

questions RQ04 and RQ06. According to Martin (1995), the stability is measured by

calculating the effort to change a module without impacting other modules within the

application. In addition, a module should depend only on modules that are more stable


that itself. The number of incoming and outgoing dependencies is one indicator that

determines the stability and instability of a module.

Modules that contain multiple outgoing but few incoming dependencies are less stable

because of the consequences of changes in these modules. On the other hand, modules

containing more incoming dependencies are more stable because they are more difficult

to change. Stability can be calculated by comparing the incoming and outgoing module

dependencies: Instability I = Ce / (Ca + Ce).

Where:

I = degree of instability

Ce = efferent coupling (outgoing dependencies)

Ca = afferent coupling (incoming dependencies)

This metric has range between [0 , 1], where I = 0 indicates a maximally stable

module and I = 1 indicates a maximally unstable module.

M08. Concern Diffusion over Components (CDC): The CDC metric was used

to help answering the questions RQ05 and RQ06. This metric counts the number of

primary components of concern, i.e., components (classes, interfaces and aspect) whose the

main purpose is to contribute to the implementation of the concern evaluated. Moreover,

it counts the number of components which accesses the main components (Sant’anna

et al., 2003).

This metric measures the degree to which a concern is scattered by components in

software design. It is easier to understand a concern whether it is less scattered. Therefore,

less components are changed in maintenance activities, and consequently, it improves the

reuse activities.

M09. Concern Diffusion over Operations (CDO): The CDO metric was used to

help answering the questions RQ05 and RQ06. This metric counts the number of primary

operations of a concern, i.e., constructors, methods, and advices whose the purpose is

to contribute to the implementation of the concern evaluated. Moreover, it counts the

number of operations that accesses any primary component by either calling their methods

(Sant’anna et al., 2003).

This metric measures the scattering of a concern in terms of operations. The more


operations are affected by concern, the more difficult is be to understand it. As a result,

is be also more difficult to modify it in the maintenance activities and reuse it.

M10. Traditional change impact metrics (Yau and Collofello, 1985; Greenwood

et al., 2007), considering different levels of granularity: components, operations, and lines

of code. These metrics were used to help answering the questions RQ06 and RQ07.

4.2.4 Criteria for the Assessment

The central purpose of DSPL engineering is to deal with adaptability at runtime, as

well as maximize the reuse of components. For this reason, it is essential to identify a

better solution to implement DSPL applications aiming to increase the software quality

by affecting internal attributes such as size, cohesion, coupling, separation of concerns

(SoC) and instability.

The inappropriate use of variability mechanisms may lead to several undesirable

consequences related to the DSPL stability. They can negatively impact the internal

attributes increasing the complexity, making the assets harder to maintain and reuse as

well as making the evolution tasks more difficult than usual. Hence, it is essential to

perform an empirical investigation aiming to identify the most suitable solution in the

DSPL evolution.

According to Wohlin et al. (2000), an empirical study cannot be conducted without

measurements. It is important to measure the inputs and the output in order to control

the study and describe what causes the effect on the output. In addition, the metrics

(closely related to the concept of response variable) are the most effective way to supply

empirical evidence that may improve the understanding of different factors of the software

reusability and maintainability (Juristo and Moreno, 2010).

This work describes and refines classical and current metrics based on McCabe (1976);

Chidamber and Kemerer (1994); Martin (1995); Fenton and Pfleeger (1998); Tarr et al.

(1999); Sant’anna et al. (2003); Tsang et al. (2004); Figueiredo et al. (2008) aiming to

quantify the response variable. However, a more effective way of software engineers

understand and interpret the meanings of the collected data is associating the internal

and external attributes with metrics through measurement framework (Sant’anna et al.,

2003; Juristo and Moreno, 2010). In this sense, a measurement framework was defined

for this exploratory study aiming to capture the understanding of the size, cohesion,

coupling, SoC, and instability attributes. These attributes are predictors of the reusability

and maintainability qualities. Figure 4.1 shows the measurement framework, which it is


composed of nine metrics grouped according to the attributes they measure.

Figure 4.1: Metrics Framework

Identifying the most suitable solution to implement DSPL promotes benefits to the

maintenance activities and reuse of components, beyond the evolution tasks of DSPL. In

order to assess the measurement object, a set of metrics was used for both solutions aiming

to meet the following requirements: (i) measuring quality factors and (ii) supporting the

identification of advantages and drawbacks from the use of aspect in the DSPL evolution

in comparison with object-oriented design.

The metrics of the evaluation framework are described in terms of class, aspects,

methods, and advices. Whereas the components encompass class, interfaces, and aspects,

the methods and advices are called operations. Due to similarities among its constructions,

class, aspects, methods, and advices are treated and measured in the same way during

the definition of metrics of the framework.


4.3 EXPLORATORY STUDY PLANNING

This section presents the planning of the exploratory study based on Wohlin et al. (2000).

It describes the context of the exploratory study in detail, its hypothesis, independent

and dependent variables, the subjects selected for performing the empirical investigation,

and the study design.

4.3.1 Project

The exploratory study was conducted on off-line (not industrial software development) at

the Software Engineering Lab1 in the Federal University of Bahia2 by two member of the

Reuse in Software Engineering3 research group in the DSPL project context.

The main instrument used in this empirical evaluation consisted of a self-adaptive

system developed for the smart homes domain. Smart home is defined as an intelligent

residence that aims to provide services to turn the life of their inhabitants easier and

safer. The smart homes have been deemed by the research community as a particularly

useful domain to cope with dynamic variability management, and the creation of inherent

models and architectures (Cetina et al., 2009a,b, 2010, 2008; Hallsteinsen et al., 2006).

Additionally, the literature addresses methods and techniques regarding the implemen-

tation of smart homes (Cook et al., 2003; Yang et al., 2015). However, key issues such

as reuse, evolution, and maintenance remained poorly prioritized. In this way, a DSPL

named SmartHomeRiSE 4 was developed in order to deal with the issues.

The smart home domain was chosen as it is likely to support a diversity of product

configurations at runtime. In this sense, the SmartHomeRiSE DSPL provides convenience

for users based on its automation functions. Moreover, this system encompasses not

only the main activities of DSPL, but also a set of non-functional properties, such as:

adaptability, autonomy, context-sensitivity, and autonomic or self-adaptive decision-making

(M. Hinchey and Schmid, 2012). The main characteristics of SmartHomeRiSE are:

• Environmental monitoring: it senses environmental conditions and reacts using

a set of actuators.

• Adaptation control: it controls adaptation according to user’s need or environment

changes.

1LES http://wiki.dcc.ufba.br/LES/2UFBA https://www.ufba.br/3RiSE http://www.rise.com.br/riselabs/4The demonstration video is available at: https://www.youtube.com/watch?v=QtXFgy316p8

http://wiki.dcc.ufba.br/LES/

https://www.ufba.br/

http://www.rise.com.br/riselabs/

https://www.youtube.com/watch?v=QtXFgy316p8

4.3 EXPLORATORY STUDY PLANNING 49

• Dynamic reconfiguration: it allows activation, deactivation, and updating of

features.

• Adding of programmed or timed events: it allows to program functions when

the user is outside the house.

4.3.1.1 Feature Model. Figure 4.2 shows the variability model of the SmartHomeRiSE

project. The features are represented according to the type: mandatory, optional,

alternative, OR, abstract, and concrete. In addition, they were managed to satisfy a

range of system adaptations. Such set of features enables to explore the DSPL nature of

the system, identifying and managing variation points to support domain specific needs

regarding user’s viewpoint.

Figure 4.2: SmartHomeRiSE Feature Model

The SmartHomeRiSE DSPL is composed of three control systems: illumination, se-

curity, and temperature. The illumination control system encompasses the mandatory

feature UserIllumination and the OR features ByPresence and ByLuminosity. In addition,

the security control system includes the optional features Alarm and PanicMode and

the mandatory features LockDoors and Presenceillusion. Finally, the temperature control

system covers the alternative features FromWindow and FromAirConditioning and the

OR features FromWindow and FromAirConditioning.

4.3.1.2 Reconfiguration Rules. The features of DSPL are often based on compo-

nents and are described at the architectural level. It allows the domain engineer to

specify adaptation rules for reconfiguration components. However, it is necessary to adopt


different adaptation policies to manage the variability (Bencomo et al., 2008a). The

modification when detected at the operational context actives the product reconfiguration

to provide context-relevant services or collect quality requests (Lee et al., 2011). Table 4.1

shows some of the possible adaptations of the SmartHomeRiSE DSPL, which were defined

based on three reconfiguration scenarios.

Table 4.1: Reconfiguration Rules

Illumination Control:

The illumination system behaves according to user’s action and environmental behavior.

Rule 01:

If low luminosity is detected on the environment, the

ByLuminosity feature turns the light on,

otherwise the feature turns the light of.

Rule 02:

If presence is detected on the environment,

the ByPresence feature

turns the light on, otherwise the feature turns the light off.

Rule 03: The user turns the light on/off by the UserIllumination feature.

Constraint:If presence is detected on the environment with high luminosity,

the ByPresence feature keeps deactivated.

Security Control:

The security system behaves according to the user’s action.

Rule 01: The PresesenceIllusion feature turns the light on/off alternately.

Rule 02: The PanicMode feature flash the light.

Rule 03: The LockDoors feature closes all exteriors doors.

Rule 04: The Alarm feature turns on/off the buzzer.

Constraint 01:If gas and smoke is detected on the environment,

the Alarm feature keeps activated.

Constraint 02: The PanicMode feature requires UserIllumination feature.

Constraint 03: The PresenceIlusion feature requires UserIllumination feature.

Constraint 04: The Alarm feature requires PanicMode feature.

Temperature Control:

The temperature system behaves according to user’s action and environmental behavior.

Rule 01:

If high temperature is detected on the environment,

the FromAirConditioning feature (automated control)

turns the air-conditioning on, otherwise the feature

turns the air-conditioning off.

Rule 02:

If high temperature is detected on the environment, the

FromWindows feature (automated control) opens

the windows, otherwise the feature closes the window.

Constraint:If the FromWindows feature controls actuator, the

FromAirConditioning feature keeps deactivated.


The first reconfiguration scenario corresponds to house illumination, accordingly with

the user’s needs and environmental change. In this case, the UserIllumination feature

enables the user to turn on/off the lights of house wherever judged convenient. On the

other hand, the ByLuminosity and ByPresence features enable that the control system

itself reacts adequately to context changes for answering the control unit commands based

on operational parameters of the presence and lighting sensors.

The second reconfiguration scenario encompasses the security control required by the

user. The PanicMode and PresenceIllusion features depend on the illumination system,

both require the UserIllumination feature to turn on light alternately and turn on light

when the house is empty, respectively. In addition, the Alarm enables to turn on/off

buzzer, and the LockDoors feature supports to open/close the doors of house. All of these

features fulfill the user’s commands.

Considering that both illumination and temperature systems have similar behaviors,

the third reconfiguration scenario reacts according to user’s needs and context changes. The

FromWindow feature enables to open/close the windows, while the FromAirConditioning

feature turns on/off the air-conditioning. However, the automated control features

must comply with the control unit commands based on operational parameters of the

temperature sensor. In contrast, the user’s features must fulfil its commands.

4.3.1.3 Reference Architecture. The SmartHomeRiSE reference architecture is based

on the model-based approach defined by Cetina et al. (2009b). Figure 4.3 shows the

graph notation. It focuses on the feature model for feature dynamic reconfiguration. It is

necessary to detect which system elements are represented by each one. In this way, the

SmartHomeRiSE uses components classified into two categories, such as devices (sensors

and actuators) and control systems (illumination, security, and temperature), beyond

communication channels among them. The control systems, devices, and channels are

represented respectively by circle, square, and line.

Table 4.2 shows the control systems and channels of the SmartHomeRiSE that are

involved in a certain feature. This approach is effective to guide the choice of system

variants in response to changes in the context. For each feature, the configurations are

described, as follows:

• the Alarm feature requires two components: the Security control system and

Buzzer device. In addition, it requires a communication channel between both in

order to allow the control system to command the actuator.


Figure 4.3: SmartHomeRiSE Reference Architecture

Table 4.2: Summary of Configurations at Runtime

Security Illumination Temperature

Alarm = 6,B,2 UserIllumination = 5,A,1 UserWindow = 10,J,11

PanicMode = 5,A,1,E,6 ByPresence = 4,D,5,A,1 UserAirConditioning = 10,K,10

LockDoors = 6,C,3 ByLuminosity = 8,G,5,A,1 AutomatedWindow = 10,J,11,I,9

PresenceIlusion = 5,A,1,E,6 AutomatedAirConditioning = 10,K,12,I,9

• the LockDoors feature requires two components: the Security control system and

Doors device. It requires a communication channel between both in order to allow

the control system to command the actuator.

• the PanicMode feature requires three components: the Illumination and Security

control systems and Led device. In addition, it requires a communication channel

in order to allow the first control system commands the led. It requires another

communication channel between both control systems.


• the PresenceIlusion feature requires three components: the Security and Illumi-

nation control systems and Led device. In addition, it requires a communication

channel in order to allow the first control system to command the led. In addition,

it requires another communication channel between both control system.

• the UserIlumination feature requires two components: the Illumination control

system and Led device. In addition, it requires a communication channel between

both in order to allow the control system to command the actuator.

• the ByPresence feature requires three components: the Illumination control system,

and Led and Presence Sensor devices. In addition, it requires a communication

channel among control systems and devices in order to command the actuator and

sensor.

• the ByLuminosity feature requires three components: the Illumination control

system, and Led and Luminosity Sensor devices. In addition, it requires a

communication channel among control systems and devices in order to command

the actuator and sensor.

• the FromWindow(UserControl) feature requires two components: the Temperature

control system and Window device. In addition, it requires a communication

channel between both in order to allow the control system to command the actuator.

• the FromAirConditioning(UserControl) feature requires two components: the Tem-

perature control system and Air conditioner device. In addition, it requires

a communication channel between both in order to allow the control system to

command the actuator.

• the FromWindow(AutomatedControl) feature requires three components: the Tem-

perature control system, Temperature Sensor and Window devices. In addi-

tion, it requires a communication channel among the control system and devices in

order to command the actuator and sensor.

• the FromAirConditioning(AutomatedControl) feature requires three components:

the Temperature control system, Temperature Sensor and Air conditioner

devices. In addition, it requires a communication channel among the control system

and devices in order to command the actuator and sensor.


4.3.1.4 Domain Architecture. Figure 4.4 shows the SmartHomeRiSE architecture. It

was divided into physical and business layers. The first comprises a scale model and devices

such as, arduino, sensors (e.g., temperature, luminosity, and presence), and actuators

(e.g., LEDs). These devices were used to act in the house and simulate environmental

changes. The second encompasses the features and user interface of the DSPL.

Figure 4.4: SmartHomeRiSE Domain Architecture

An arduino communication framework was developed aiming to allow the communica-

tion between the physical and business layers. It consists of an intermediate communication

layer that uses the programmatic abstractions in order to spend the information collected

through arduino for the system.

Additionally, the communication framework was developed in (i) Java in the main


application, and (ii) C within the arduino. The Java application encompasses the

programmatic abstraction of sensors and actuators, and arduino messages manager class.

Figure 4.5(a) shows the hierarchical structure of classes that defines the type of hardware

(sensor or actuator) and its actions. In addition, it is the interface between the framework

and features.

(a) Hardware Programmatic Abstraction Model

(b) Sensor act(Actuator a) example

Figure 4.5: Arduino Communication Framework

Figure 4.5(b) shows an example of functioning of the arduino communication framework.

The message control class, that only can be seen by the hardware abstraction classes is

the class responsible for absorbing all the logic of communication with arduino. Using it,


every actions requested by a feature to a hardware abstraction class instance is processed

and sent to the micro controller 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 managent class.

4.3.1.5 Model composition. Figure 4.6 shows the SmartHomeRiSE class model. It

consists of a variability control structure that allows the reaction of features at runtime

by answering to reconfiguration triggers. The model composition is based on the feature

model and reference architecture.

This model explores aspects of dynamic reconfiguration and enables to simplify user

interaction. In addition, all features extend the FeatureBase abstract class that enables

them to share common properties, such as the list of required features.

4.3.1.6 Implementation. The system was implemented in Java with 4059 lines of

code including 09 packages, 53 classes, and 11 concrete features. In addition, the C

code on arduino has 83 lines of code. The implementation of SmartHomeRiSE is based on

practices of DSPL for managing variability adaptation control that occurs at runtime. In

addition, it has as a key characteristic the use of a set of variability mechanisms considered

most suitable according to the characterization discussed in the chapter 3.

This application is composed of a variety of devices that reacts to contextual informa-

tions at runtime and requires the activation/deactivation/update of features autonomously.

In summary, it is not recommended to use only one mechanism to implement all kinds

of features of DSPL. It is more suitable to combine two or more variability mechanisms

in order to achieve flexibility and attend a wide of adaptations possible according to the

feature model and reference architecture. A brief description of implementation of the

SmartHomeRiSE DSPL is presented, as follows:

• Reflection: the implementation of SmartHomeRiSE defines annotations to control

variability at runtime. It was defined three annotations, each one identifying

mandatory, optional, and alternative features. The Java Reflection API 5 allows

adding metadata directly to the code eliminating the need to have a separated file.

As the notes are directly inserted into the classes, is necessary to use the reflection

library to access them and read their contents. In this way, the Java Reflection

API is used for read the annotations and control the variability when activate and

5Java Reflection Tutorial http://tutorials.jenkov.com/java-reflection/index.html

http://tutorials.jenkov.com/java-reflection/index.html


Figure

4.6:

SmartHomeRiSEClass

Mod

el


deactivate features at runtime. The snippets 4.1, 4.2, and 4.3 show the use of Java

Reflection API to read the annotations and control the variability when activate

and deactivate features.

@Target ( ElementType .TYPE)

@Retention ( Retent ionPo l i cy .RUNTIME)

public @inte r f a c e MandatoryFeature {}



public @inte r f a c e OptionalFeature {}



public @inte r f a c e Al t e rnat iveFeature {Class<? extends FeatureBase > [ ] a l t e r n a t i v e s ( ) ;

}

Listing 4.1: Annotations definitions

@Alternat iveFeature ( a l t e r n a t i v e s={UserAirCondit ionerContro l . class })public class UserWindowControl extends FeatureBase {

private ArrayList<AutomaticWindow> automaticWindows ;

private stat ic UserWindowControl userWindowControl = null ;

protected UserWindowControl ( ) {}/* additional lines of code */

}

Listing 4.2: Using the annotations to identify the features

private boolean eva luat ionForFeatureHierarchy ( FeatureBase

newFeature ) {for ( FeatureBase f ea tureBase : f e a t u r e s ) {

i f ( newFeature . ge tC la s s ( ) . g e tSupe r c l a s s ( ) . equa l s (

f ea tureBase . ge tC la s s ( ) ) ) {keepFeatureState ( featureBase , newFeature ) ;

exchangeRequiredFeature ( featureBase , newFeature ) ;

f e a t u r e s . remove ( f ea tureBase ) ;


return true ;

}i f ( f ea tureBase . ge tC la s s ( ) . g e tSupe r c l a s s ( ) . equa l s (

newFeature . ge tC la s s ( ) . g e tSupe r c l a s s ( ) ) ) {exchangeBrotherFeaturesData ( featureBase , newFeature ) ;

return true ;

}i f ( f ea tureBase . ge tC la s s ( ) . g e tSupe r c l a s s ( ) . equa l s (

newFeature . ge tC la s s ( ) ) ) {return fa l se ;

}}return true ;

}

Listing 4.3: Reflexive variability control

• Design Pattern: in the context of this work were implemented patterns, such

as Singleton and Facade. Whereas the Singleton design pattern was implemented

to guarantee a single feature instance (it is fundamental to maintain the DSPL

consistency), the Facade design pattern is used to implement several concerns,

including joint point to the user interface classes. The snippets 4.4 and 4.5 show

the usage of both design patterns.

public class HouseFacade {private stat ic ArrayList<FeatureBase> ava l i ab l eFea tu r e s ;

private stat ic ArrayList<FeatureBase> f e a t u r e s ;

private stat ic ArrayList<Hardware> hardwareList ;

private stat ic AutomatedFeaturesRunnable automatedFeaturesRunnable

;

public HouseFacade ( ) {f e a t u r e s = new ArrayList<FeatureBase >() ;

hardwareList = new ArrayList<Hardware>() ;

loadMandatoryFeatures ( ) ;

l oadOpt iona lFeatures ( ) ;

l oadAva l i ab l eFeature s ( ) ;

automatedFeaturesRunnable = new AutomatedFeaturesRunnable (

f e a t u r e s ) ;

(new Thread ( automatedFeaturesRunnable ) ) . s t a r t ( ) ;

}


public void addAval iab leFeature ( FeatureBase f ea tureBase ) {/* additional lines of code */

}public void addFeature ( FeatureBase newFeature ) {

/* additional lines of code */

}/* additional lines of code */

private void r e c r ea teFatherFeature ( FeatureBase f e a t u r e ) {/* additional lines of code */

}private boolean eva luat ionForFeatureHierarchy ( FeatureBase

newFeature ) {/* additional lines of code */

}return true ;

}private void exchangeBrotherFeaturesData ( FeatureBase

featureBase , FeatureBase newFeature ) {/* additional lines of code */

}private void keepFeatureState ( FeatureBase oldFeature , FeatureBase

newFeature ) {/* additional lines of code */

}

Listing 4.4: HouseFacade Implementation

public class PanicMode extends FeatureBase {PanicModeThread panicModeThread ;

private stat ic PanicMode panicMode = null ;

private PanicMode ( ) {}

public stat ic PanicMode ge t In s tance ( User I luminat ion

use r I l uminat i on ) {i f ( panicMode == null ) {

panicMode = new PanicMode ( ) ;

panicMode . setName ("Panic Mode" ) ;

panicMode . addRequiredFeature ( u s e r I l uminat i on ) ;

}return panicMode ;

}


}

Listing 4.5: PanicMode Feature with singleton pattern

• Polymorphism: the features of SmartHomeRiSE can be run in accordance to the

user and environmental triggers. In order to solve this problem was defined an

interface named AdaptableFeature, which 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.

The composition model (Figure 4.6) shows the variability control structure 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 provide the inputs parameters to the feature. The action is recognized

through sensors connected to the prototype.

The snippets 4.6 and 4.7 show the definition of the adaptable feature interface and

a class that implements it, respectively.

public interface AdaptableFeature {void proceedAct ions ( ) ;

}

Listing 4.6: The AdaptableFeature interface definition

public class AutomatedIluminationByPresence extends

User I luminat ion implements AdaptableFeature{/* additional lines of code */

@Override

public void proceedAct ions ( ) {/* additional lines of code */

}}

Listing 4.7: ByPresence Feature implementing AdaptableFeature method

Additionally, abstract classes were the basis for the construction of the structure

created to give the flexibility and standardization necessary for the implemented mo-

del. The snippet 4.8 shows the abstract class that implements the programmatically

abstraction of the sensors and actuators.


public abstract class Hardware {

private int pin ;

private St r ing name ;

private boolean i sAnalog ;

public Hardware ( int pin , boolean i sAnalog , S t r ing name) {this . pin = pin ;

this . i sAnalog = isAnalog ;

this . name = name ;

}

/* additional lines of code */

}

Listing 4.8: The Hardware class is inherited by all classes that represents sensors

and actuators

• Parameterization: by using this mechanism, the feature’s behaviour of the

SmartHomeRiSE DSPL is determined in accordance with the values assigned to

parameters, in which it should be read. Thus, the attributes of a feature can be

filled by parameters.

• Aggregation (composition aggregation): the implementation of the features

of the SmartHomeRiSE DSPL was performed by using this variability mechanism,

in order to reuse the code of an specific class to compose another existing class

with similar attributes and behaviors. The code snippets 4.9 shows the LockDoors

feature implementantion by using this mechanisms.

public class PanicMode extends FeatureBase {PanicModeThread panicModeThread ;

private stat ic PanicMode panicMode = null ;

private PanicMode ( ) {}

public stat ic PanicMode ge t In s tance ( User I luminat ion

use r I l uminat i on ) {i f ( panicMode == null ) {

panicMode = new PanicMode ( ) ;

panicMode . setName ("Panic Mode" ) ;


panicMode . addRequiredFeature ( u s e r I l uminat i on ) ;

}return panicMode ;

}/* additional lines of code */

}

Listing 4.9: The PanicMode Feature implemented with composition aggregation

More data about the development of this DSPL is presented in Appendix A.

4.3.2 Hypothesis

Defining the hypothesis correctly is both the most important part and the most difficult

one in an empirical investigation. The exploratory study does not produce useful results,

in case the hypothesis is wrong. In addition, the definition must be detailed enough to

make clear what measurements are needed to demonstrate the effect (Kitchenham et al.,

1995).

According to Wohlin et al. (2000), the null hypotheses are those who the experimenter

want to reject, while the alternative hypotheses are those that the experimenter wants to

confirm. In this exploratory study, it was established the following null hypothesis and

alternative one.

Null Hypotheses. The null hypotheses state that there is no difference between the

object-oriented and aspect-oriented solutions in terms of internal attributes such as, size,

cohesion, coupling, SoC, and instability in the context of Dynamic Software Product Lines

projects. The corresponding null hypotheses are presented as follows:


Alternative Hypotheses. The null hypotheses state that there is difference between

the object-oriented and aspect-oriented solutions in terms of internal attributes such as,

size, cohesion, coupling, SoC, and instability in the context of Dynamic Software Product

Lines projects. The corresponding alternative hypotheses are presented as follows:

!"#

4.3.3 Variable Selection

The independent variables are those that we can control and change in the empirical

study. These variables should have some effect on the dependent variables and must

be controlled. In addition, the dependent variable should be derived directly from the

hypothesis Wohlin et al. (2000).

The independent variables of this study are both object-oriented and aspect-oriented

solutions. In this sense, one system (DSPL) was used to analyze the behavior of the

dependent variables (i.e., the metrics that are directly related to the response variable).

4.3.4 Subjects

The exploratory study was performed by two subjects, one master student (the dissertation

author) and one undergraduate student at the Software Engineering Lab in the Federal

University of Bahia. Both are member of the Reuse in Software Engineering (RiSE) labs.

The dissertation author was considered the domain engineer aiming defining the

feature model, the architecture reference, reconfiguration rules, and possible adaptations

for the application. In addition, she also identified and selected the variability mechanisms

considered relevant for the application domain. The second subject was considered

the application engineer, responsible for implementing and handling the variations and

4.4 PROCEDURES AND PROTOCOLS FOR DATA COLLECTION 65

reconfigurations.

4.3.5 Training requirements

The subjects had not knowledge concerning to some variability mechanisms (e.g., reflection,

design patterns) of the selected project, besides aspect-oriented development. Thus, it

was necessary to learn the mechanisms and paradigm specifications to implement the

project. As a consequence, the implementation took a considerable time and effort.

In contrast, the undergraduate student had previous experience in the development of

one self-adaptive system. Thus, it was assumed that this subject was already familiarized

with concepts related to smart home domain, facilitating the understanding of domain

engineering without the need of training.

4.3.6 Quantitative Analysis Mechanisms

The quantitative assessment was divided as complexity, cohesion, coupling, package

stability, and modularity. Each evaluation section describes the analysis concerning the

object-oriented and aspect-oriented solutions. Moreover, these factors are predictors for

external attributes as reusability and maintenance (Sant’anna et al., 2003).

For quantitative data, the analysis includes descriptive statistics, such as mean values,

standard derivation (StDev), maximum, minimum, boxplots, and probability plots aiming

to get understanding of the data that has to be collected in this exploratory study.

Regarding the hypotheses defined for the exploratory study, the non-parametric Tests,

such as Mann-Whitney-Wilcoxon Test (U Test), and Kruskal-Wallis Test (H-Test) were

used (Wohlin et al., 2000; Juristo and Moreno, 2010).

4.4 PROCEDURES AND PROTOCOLS FOR DATA COLLECTION

The implementation of DSPL project checks for correctness of both, the execution of the

demanded adaptations and the behavior of the system. For this reason, the use of suitable

mechanisms for the implementation of the variability enables to achieve the flexibility

needed to deal with the adaptations at runtime and can generate significant impacts at

the product quality, besides good performance.

The exploratory study was organized into several steps (Figure 4.7): identification

and selection of suitable variability mechanisms to implement DSPL; definition of the

application domain, feature model, reference architecture, reconfiguration rules, and


possible adaptations; building of the prototype that encompasses the scale model and

devices (e.g. sensors, arduino, and actuators); development of the subject DSPL with

complete releases. It corresponds to respective scenario changes; measurements and

metrics calculation; and quantitative analysis of the results.

Figure 4.7: Exploratory Study Design

In the first phase, the domain engineer performed a characterization of the variability

mechanisms aiming to identify the most suitable one in the context of DSPL and also that

ones that benefit the implementation of the project. Next, the same subject defined the

development process and built the prototype used to test the application. Based on the

previous phases, the application engineer built the DSPL into two designs, object-oriented

and aspect-oriented.

Additionally, the DSPL has been implemented into releases by domain engineer. The

4.4 PROCEDURES AND PROTOCOLS FOR DATA COLLECTION 67

complete releases correspond to respective scenario changes, simulating maintenance tasks

and reuse. Seven scenarios were considered in SmartHomeRiSE, resulting in eight releases.

The scenarios encompass different types of changes involving illumination, security,

and temperature control systems and mandatory, OR, optional, and alternative

features.

Table 4.3 shows the scenario changes of the SmartHomeRiSE according to the feature

types and its triggers. In both designs, the release R01 contains the core of DSPL. All

subsequent releases were designed to incorporate the required changes in order to include

the corresponding optional, OR, and alternative features. For instance, in the release

R02 two optional features were added. In addition, in the releases R07 and R08 were

considered the illumination and temperature features, respectively. For this reason, a

set features was removed in these releases.

Table 4.3: Reuse and Maintenance Scenarios in SmartHomeRiSE.Evolution

Feature Reuse TriggerR01 R02 R03 R04 R05 R06 R07 R08 User Environment

01 � � � � � � � � � �02 � � � � � � � � � �03 � � � � � � � � � �04 � � � � � � � � � �05 � � � � � � � � � �06 � � � � � � � � � �07 � � � � � � � � � �08 � � � � � � � � � �09 � � � � � � � � � �10 � � � � � � � � � �11 � � � � � � � � � �

(01): PresenceIllusion; (02): UserIllumination; (03): Alarm; (04): PanicMode; (05): Lock-Doors; (06): ByPresence; (07): ByLuminosity; (08): FromWindow(User); (09): FromAirCon-ditioning(User); (10): FromWindow(Automated); (11): FromAirConditioning(Automated); �:Included; �: Not included

For each implemented release, several metrics data were collected, such as size, cohesion,

coupling, SoC, and instability. The metrics data were collected using the following tools:

AOPMetrics 5 and ConcernMorph (Figueiredo et al., 2009) 6. The concrete result of

the data collected is presented in the next section. Moreover, it also presents and discusses

the quantitative analysis based on change scenarios for each solution of the DSPL project.

5AOPMetrics http://aopmetrics.tigris.org/6ConcernMorph http://homepages.dcc.ufmg.br/~figueiredo/concern/plugin/plugin.htm

http://aopmetrics.tigris.org/

http://homepages.dcc.ufmg.br/~figueiredo/concern/plugin/plugin.htm


4.5 OPERATION

Next, the exploratory study definition and planning, its operation phase was initiated in

order to collect the data that were analyzed. The collection of numerical data occurred

according to the object-oriented (OO) and aspect-oriented (AO) solutions and its releases.

For each release, all the data were collected through the metrics and checked in order to

ensure their validation.

• Size, cohesion, coupling, and package instability measures

In order to illustrate and give an overview of the data set collected to complexity,

cohesion, coupling, and package stability analysis, we used the boxplot (Wohlin

et al., 2000; Juristo and Moreno, 2010). It consists of an effective graph to show the

tendency of the data, skewness of samples, and the general dispersion.

In descriptive statistics, the boxplot shows groups of numerical data through their

quartiles and has lines (whisker) extending vertically from the boxes indicating

variability outside the upper and lower quartiles. Any point outside of this range is

called an outlier. Outliers may be plotted as individual points. In this study, the

boxplots were grouped into releases to reveal the variation among them in a same

solution, but at same time, it was possible to check the variation between the OO

and AO solutions.

• SoC measures

As the feature concept is closely related to that of concerns, we decided to group

them accordingly with its type to perform the modularity analysis. For instance, in

release 06, we grouped three mandatory features, four OR features, two optional

features, and two alternative features. In this way, it was possible to check how

the inclusion of different feature types can affect the concern modularity and stability

of the DSPL evolution for each solution.

For each group of features, releases, and solutions we identified the components

(e.g., classes, aspects) and operations (e.g., methods, advices) that contribute at the

implementation. By using the ConcernMorph tool was possible to collect the data

set considering the ratio of the measured value to the total value on that release.

For instance, CDO was calculated as the ratio of operations that contributes to the

implementation of a set of features to the total number of operations (i.e., the CDO

measure represents the percentage of operations that are used to implement a set of

features for each type).

4.6 ANALYSIS AND INTERPRETATION 69

An overall analysis was performed with the mean value of metrics for each solu-

tion/release. Next, we conducted an analysis considering the data variation. In this

case, probability plots were used to reveal details about the overall dispersion of

the metric values. The data are plotted against a theoretical distribution in such

a way that the points should form approximately a straight line. Departures from

this straight line indicate departures from the specified distribution.

The theoretical distribution should be chosen among known distributions, in such

way that it fairly fits the data. Probability plots can be useful for checking this

distributional assumption. We had tested the data with the set of distributions of

Minitab17 7 that could be applied to grouped data and did not require parameter-

ization. We selected the Normal distribution, since it best fitted the data according

to Anderson-Darling Test (AD). The lowest mean AD for curves (one for each

paradigm) defined the best distribution.

• Design stability measures

According to Figueiredo et al. (2008), it is possible to evaluate the design stability of

a software system comparing its versions. Whether the differences among its quality

measures are insignificant, then the software design is stable.

• Change propagation measures

The applied changes to the SmartHomeRiSE was varied in terms of addition and

removing of features. As a result, it was possible to provide additional indication

whether an specific paradigm supports better design stability for some types of

change.

4.6 ANALYSIS AND INTERPRETATION

This section discusses the assessment of the data collected. It consists of understanding

the data collected to arrive at conclusions about the relationships between factors, the

alternatives that improve the values of the response variables, and the influence of factors

on the response variables (Juristo and Moreno, 2010). The evaluation was organized based

on the quantitative analysis mechanisms defined in the planning phase. In addition, it

was conducted through descriptive statistics in order to get a general view of a data set

and its distribution.

7Minitab17 http://www.minitab.com/pt-BR/products/minitab/

http://www.minitab.com/pt-BR/products/minitab/


4.6.1 Complexity Analysis

The software complexity is related to the required maintenance effort as a result of

modifications as well as understandability issues. Large and highly complex components

lead to difficulties in terms of understanding and maintenance.

This subsection presents a quantitative analysis to answer: RQ01 – Does the aspect-

oriented solutions provide less complex design than object-oriented solutions? and RQ06 –

Does the use of aspect-oriented solutions provide more modular design than object-oriented

solutions? In particular, we were interested to know how the different paradigms affect

size measures in DSPL evolution.

Figure 4.8 and Figure 4.9 show the complexity criterion in each solution - Object-

Oriented and Aspect-Oriented concerning two measures: Weighted Operations per Com-

ponent (WOC) and Lines of Code (LOC), respectively. A general interpretation of

these measures is that lower values indicate a less complex solution. We next provide a

descriptive analysis of each measure.

• Weighted Operations per Component (WOC). In general, concerning the

number of operations, we could not identify a significant difference between the

measures of the two solutions and the variation among the releases was almost

similar. For this measure in AO, we counted advice blocks as operations belonging

to aspects. Table 4.4 shows the descriptive statistics to WOC measure for every

release.

Table 4.4: WOC Descriptive StatisticsRelease Variable Components Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 21 6,140 5,680 32,230 0,000 2,500 5,000 8,500 25,000AO 23 5,960 5,760 33,130 0,000 2,000 4,000 8,000 26,000

02OO 27 6,070 5,530 30,610 0,000 2,000 5,000 9,000 26,000AO 29 5,860 5,560 30,910 0,000 2,000 4,000 8,500 27,000

03OO 30 6,167 5,446 29,661 0,000 2,000 5,000 9,000 26,000AO 32 5,969 5,480 30,031 0,000 2,000 4,500 8,750 27,000

04OO 39 6,282 5,301 28,103 0,000 2,000 5,000 9,000 26,000AO 42 6,048 5,437 29,559 0,000 2,000 4,500 8,250 27,000

05OO 47 6,277 5,352 28,639 0,000 2,000 6,000 9,000 28,000AO 50 5,960 5,580 31,141 0,000 2,000 5,000 8,000 28,000

06OO 52 6,558 5,345 28,565 0,000 2,000 6,000 9,750 28,000AO 55 6,364 5,338 28,495 0,000 2,000 6,000 9,000 28,000

07OO 28 6,500 5,640 31,810 0,000 2,000 5,000 9,750 25,000AO 31 6,030 5,690 32,370 0,000 2,000 4,000 8,000 26,000

08OO 30 6,700 5,440 29,597 0,000 2,750 6,000 9,250 26,000AO 33 6,273 5,375 28,892 0,000 2,000 5,000 8,500 26,000

The variance among releases of each solution was also almost similar. Nonetheless,

we can see an outlier in all releases of both OO and AO. This outlier has occurred in a


"#!#

'#

&#

%#

*#+#

(#

)#

,#

!"#!!#

!'#

!&#

!%#

!*#!+#

!(#

!)#

!,#

'"#'!#

''#

'&#

'%#

'*#'+#

'(#

')#

',#

&"#

$"!# $"'# $"&# $"%# $"*# $"+# $"(#$")#

(a) OO

%#'#

!#

&#

)#

,#(#

*#

"#

+#

'%#''#

'!#

'&#

')#

',#'(#

'*#

'"#

'+#

!%#!'#

!!#

!&#

!)#

!,#!(#

!*#

!"#

!+#

&%#

$%'# $%!# $%&#$%)# $%,#$%(#$%*#$%"#

(b) AO

Figure 4.8: Boxplots for Weighted Operation per Component (WOC)

fundamental class, called HouseFacade, which is responsible for implementing several

concerns. In releases 02, 03, 04, 05, 06, and 07, the WOC value is increasing. The

plot shows that these releases have the upper whisker greater in the OO scenario.

Although the AO implementation add more pointcuts and advices needed to modu-

larize concerns (the main way for decomposing software into smaller parts, and at

the same time more comprehensible and manageable), observing the mean value

for all releases we have considered that the OO implementation is more complex

regarding the WOC measure.

• Lines of Code (LOC). In general, the variation of the data set among both


solutions was irregular. In OO, the median value among all releases was close and

irregular. The same applies with the releases in AO. However, the LOC mean value

in OO design is higher than in AO for all releases. Table 4.5 shows the descriptive

statistics to LOC measure for all releases.

"$

'""$

&""$

#""$

)""$

(""$

!"'$!"&$ !"#$ !")$ !"($ !"%$ !"+$ !"*

(a) OO

"#

*""#

!""#

&""#

$""#

'""#

%"*#%"!# %"&#%"$# %"'# %")# %"(# %"+#

(b) AO

Figure 4.9: Boxplots for Number of Code Lines (LOC)

In both solutions, the increase in maximum values until release 06 resulted in the

appearance of outliers, since new features were included during the evolution task.

The outliers have occurred in the Main and HouseFacade classes due to insertion of

OR and alternatives features. In this case, several concerns and joint points to

the user interface classes were implemented.


Table 4.5: LOC Descriptive StatisticsRelease Variable Components Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 21 64,8 66,8 4461,4 2,0 12,50 33,00 113,5 216,0AO 23 60,4 63,9 4085,5 2,0 9,000 33,00 102,0 213,0

02OO 27 67,9 69,3 4806,5 2,0 10,00 49,00 128,0 232,0AO 29 63,7 65,4 4274,4 2,0 9,500 46,00 103,5 213,0

03OO 30 70,0 72,4 5247,9 2,0 10,50 42,00 135,3 243,0AO 32 66,0 68,1 4634,8 2,0 9,500 42,00 112,8 213,0

04OO 39 71,5 80,0 6403,7 2,0 35,00 5,000 138,0 296,0AO 42 67,1 74,2 5507,9 2,0 34,00 4,500 107,3 268,0

05OO 47 74,3 89,0 7915,2 2,0 9,000 42,00 138,0 382,0AO 50 70,4 86,5 7483,6 2,0 8,800 38,00 102,0 345,0

06OO 52 78,1 95,2 9066,1 2,0 10,50 43,50 148,5 427,0AO 55 74,3 86,0 7390,3 2,0 9,000 41,00 145,0 408,0

07OO 28 70,7 83,9 7044,7 2,0 10,50 27,00 138,0 297,0AO 31 61,4 69,9 4892,2 2,0 9,000 25,00 133,0 221,0

08OO 30 73,3 81,9 6711,6 3,0 14,50 37,50 146,0 323,0AO 33 66,0 74,2 5501,2 3,0 8,000 33,00 123,0 257,0

The upper whisker of the release 06 was greater in AO than OO. We have associated

it with the occurrence of OR and alternative features in the same release. In this

case, new pointcuts and advices were included resulting in more lines of code and

increased complexity. On the other hand, the median value to LOC measure showed

that OO is more complex than AO, since the use of aspects reduce the number of

lines of code for all components.

As a general indicator for the size attribute, both OO and AO presented almost similar

behavior, resulting in very similar stability for evolution task and reuse. Although,

the implementation using aspects introduces more pointcuts and advices, beyond of

components needed to modularize the concerns, OO is more complex than AO regarding

to WOC measure. In addition, the mean, StDev, and variance values to LOC measure

showeed that OO is more complex than AO, since the use of aspects reduces the number

of lines of code for all components.

4.6.2 Cohesion Analysis

Cohesion refers to the degree that operations of a component belong to another component,

i.e., it measures the interdependence of a component. High cohesion is generally used in

support of low coupling. High cohesion means that the responsibilities of a given element

(e.g., a software component) are strongly related and highly focused (Larman, 2002). The

reuse, maintenance, and extensibility are the advantages achieved with highly cohesive

components.

This subsection presents a quantitative analysis to answer: RQ02 – Does the use of


aspect-oriented solutions provide more cohesive design than object-oriented solutions? and

RQ06 – Does the use of aspect-oriented solutions provide more stable design than the

object-oriented solutions? In particular, we were interested to know how the different

paradigm might affect cohesive measure in DSPL evolution.

Figure 4.10 shows the cohesion criterion in each solution concerning one measure, Lack

of Cohesion of Operations (LCOO). A general interpretation of this measure is that a

lower value indicates a less cohesion solution. We next provide a descriptive analysis of

the measure.

• Lack of cohesion of methods (LCOO). The LCOO variation presented similar

behavior comparing both OO and AO during evolution. Table 4.6 shows the

descriptive statistics to LCOO measure for every release. In general, AO was better

with respect to LCOO measurement, since the aspects filter out crosscutting behavior.

It means that AO is more cohesive than OO. The plot shows these findings by

comparing the third quartile for all releases.

Table 4.6: LOCC Descriptive StatisticsRelease Variable Components Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 21 9,430 23,820 567,26 0,00 0,00 0,00 9,000 108,00AO 23 4,130 7,6300 58,210 0,00 0,00 0,00 8,000 28,000

02OO 27 9,740 25,570 653,58 0,00 0,00 0,00 13,00 132,00AO 29 4,520 7,4100 54,970 0,00 0,00 0,00 8,000 28,000

03OO 30 9,600 24,390 594,73 0,00 0,00 0,00 13,25 132,00AO 32 4,880 7,6800 58,950 0,00 0,00 0,00 8,000 28,000

04OO 39 9,380 21,990 483,66 0,00 0,00 0,00 13,00 132,00AO 42 6,020 10,060 101,15 0,00 0,00 0,00 9,000 43,000

05OO 47 6,110 8,8000 77,400 0,00 0,00 0,00 9,000 28,000AO 50 6,120 10,970 120,35 0,00 0,00 0,00 8,250 49,000

06OO 52 6,870 9,2600 85,810 0,00 0,00 0,00 12,00 28,000AO 55 6,840 10,130 102,55 0,00 0,00 0,00 9,000 43,000

07OO 28 10,36 25,230 636,39 0,00 0,00 0,00 9,750 130,00AO 31 5,770 10,850 117,78 0,00 0,00 0,00 9,000 43,000

08OO 30 6,030 8,9400 79,900 0,00 0,00 0,00 9,250 26,000AO 33 6,450 9,0900 82,630 0,00 0,00 0,00 9,500 26,000

In OO, the releases 01, 02, 03, 04, and 07, the LCOO measure to the HouseFacade

component had a value greater than one hundred resulting in an outlier. In contrast,

in the releases 05, 06, and 08, this same component presented a value equal to

zero. We have associated this sharp variance with the inclusion of Optional and

OR features.

The high value as well as the value equal zero indicates that the component has

low cohesion. Whereas a LCOO measure of zero cannot support evidence that


"$

%"$

'"$

&"$

,"$

#"$

*"$

)"$

+"$

("$

%""$

%%"$

%'"$

%&"$

!"%$ !"'$ !"&$ !",$ !"#$ !"*$ !")$ !"+$

(a) OO

"$

%"$

+"$

&"$

*"$

)"$

("$

'"$

#"$

,"$

%""$

%%"$

%+"$

%&"$

!"%$ !"+$ !"&$ !"*$ !")$ !"($ !"'$ !"#$

(b) AO

Figure 4.10: Boxplots for Lack of cohesion of operations (LCOO)

a component is cohesive and has a stable interface, the high LCOO indicates a

component that shall be considered for splitting into several components.

In summary, it indicates that AO is more stable than OO for cohesion measure. It can be

seen that more scenarios in OO were affected regarding cohesion. The only major change

for AO occurred in one release, while in OO the major change occurred in five ones.

4.6.3 Coupling Analysis

Coupling describes the relationship or dependency between two or more components. The

more coupling between any two components, the more difficult it is for a programmer to


comprehend a given component. A system with high coupling means there are strong

interconnections between its modules. As a consequence, high coupling may lead to

difficulties in terms of maintenance and reuse. Thus, the coupling factor has direct impact

on software maintenance activities.


aspect-oriented solutions provide less coupled design than the object-oriented solutions?

and RQ06 – Does the use of aspect-oriented solutions provide more stable design than

the object-oriented solutions? In particular, we were interested to know how the different

paradigms affect the coupling measure in DSPL evolution.

Figure 4.11, Figure 4.12, and Figure 4.13 show the coupling criterion in each solution

concerning three measures: Coupling between components (CBC), Response for a Class

(RFC), and Depht of Inheritance Tree (DIT), respectively. A general interpretation of

these measures is that lower values indicate a less coupled solution. We next provide a

descriptive analysis of each measure.

• Coupling between components (CBC). Both solutions presented a constant

median among every release. The data set had a similar behavior comparing both

OO and AO from releases 01 to 05. However, outliers are showed in these releases.

We consider the outliers in the components that implement concerns related to

features and hardware management. In addition, the third quartile presented greater

value in OO than AO in the releases 01, 03, 06, 07, and 08. It indicates that OO

is more coupled than AO. Table 4.7 shows the descriptive statistics to CBC measure

for all releases.

Table 4.7: CBC Descriptive StatisticsRelease Variable N Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 21 3,100 4,610 21,290 0,00 0,00 1,00 4,500 16,00AO 23 2,957 4,517 20,407 0,00 0,00 1,00 4,000 16,00

02OO 27 3,593 5,139 26,405 0,00 0,00 1,00 4,000 16,00AO 29 3,448 4,968 24,685 0,00 0,00 1,00 4,000 16,00

03OO 30 3,870 5,490 30,120 0,00 0,00 1,00 5,250 16,00AO 32 3,750 5,328 28,387 0,00 0,00 1,00 4,750 16,00

04OO 39 4,026 5,728 32,815 0,00 0,00 1,00 5,000 20,00AO 42 3,810 5,452 29,719 0,00 0,00 1,00 5,000 18,00

05OO 47 4,255 6,212 38,586 0,00 0,00 1,00 5,000 24,00AO 50 4,180 6,190 38,314 0,00 0,00 1,00 5,000 24,00

06OO 52 4,404 6,350 40,324 0,00 0,00 1,00 8,750 26,00AO 55 4,236 6,077 36,925 0,00 0,00 1,00 8,000 24,00

07OO 28 3,710 5,860 34,290 0,00 0,00 1,00 5,750 23,00AO 31 3,161 4,734 22,406 0,00 0,00 1,00 5,000 16,00

08OO 30 3,833 5,325 28,351 0,00 0,00 1,00 10,000 16,00AO 33 3,182 4,647 21,591 0,00 0,00 1,00 5,500 14,00

In general, the presence of aspects is likely to decrease the coupling between core


"$

&"$

*"$

'"$

!"&$ !"*$ !"'$ !"($ !"%$ !"+$ !")$ !"#$

(a) OO

"$

%"$

&"$

#"$

!"%$ !"&$ !"#$ !")$ !"($ !"+$ !"'$ !"*$

(b) AO

Figure 4.11: Boxplots for Coupling between components (CBC)

classes and increase the coupling between core class and aspects. This is because

aspects are new entities on which core classes depend upon. Decreasing the coupling

between core classes is a beneficial issue, and increasing coupling between aspects

and core classes in return can be seen as a good trade-off. Given that a design might

involve coupling between classes, it would be better to have this coupling occurring

between the core classes and aspect, rather than having it happening between core

classes.

• Response for a Class (RFC). AO presented a growing median value in the

releases 04, 05, 06, 07, and 08. Surely it occured due to inclusion of OR and


Alternative features, since the components targeted at implementing of these

features had a high RFC value.

Table 4.8 shows the descriptive statistics to RFC measure for all releases. The

variance of the data set was almost similar. Nevertheless, the mean value is higher

in OO than AO for all releases. It indicates that OO implementation is more coupled

regarding the RFC measure.

"#

!#

&"#

&!#

*"#

*!#

+"#

+!#

%"#

%!#

!"#

!!#

'"#

'!#

("#

(!#

)"#

$"&# $"*# $"+# $"%# $"!# $"'# $"(# $")#

(a) OO

"$

#$

*"$

*#$

+"$

+#$

%"$

%#$

&"$

&#$

#"$

##$

'"$

'#

)"$

)#$

("$

!"*$!"+$!"%$!"&$!"#$ !"'$ !")$!"($

(b) AO

Figure 4.12: Boxplots for Response for a Class (RFC)

Additionally, the core-to-aspect invocations are counted when calculating RFC.

Thus, the RFC value increased in the presence of aspects. It means that the number

of entities that a class communicates with has been increased, and thus, the classes


Table 4.8: RFC Descriptive StatisticsRelease Variable Components Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 21 9,480 10,08 101,66 0,00 2,00 7,00 12,00 33,00AO 23 8,870 10,37 107,48 0,00 1,00 4,00 12,00 33,00

02OO 27 9,780 10,85 117,64 0,00 2,00 7,00 11,00 37,00AO 29 9,140 10,76 115,77 0,00 1,50 4,00 11,50 37,00

03OO 30 10,20 11,11 123,34 0,00 2,00 7,50 11,50 37,00AO 32 9,560 10,96 120,06 0,00 2,00 5,50 11,75 37,00

04OO 39 10,74 11,27 127,09 0,00 2,00 8,00 13,00 44,00AO 42 10,10 11,49 131,94 0,00 2,00 7,50 12,00 41,00

05OO 47 11,02 12,08 145,85 0,00 2,00 8,00 13,00 56,00AO 50 10,42 12,20 148,78 0,00 2,00 7,50 12,25 50,00

06OO 52 11,67 12,71 161,44 0,00 2,25 8,50 14,50 65,00AO 55 11,33 12,73 162,00 0,00 2,00 8,00 12,00 54,00

07OO 28 10,71 10,83 117,25 0,00 2,00 8,00 18,75 34,00AO 31 9,710 11,00 120,95 0,00 1,00 7,00 12,00 34,00

08OO 30 11,23 11,66 136,05 0,00 2,00 8,50 16,75 47,00AO 33 10,39 11,49 132,00 0,00 2,00 7,00 14,00 42,00

have to communicate with the aspects. However, we have noticed that by using

aspects it is possible to encapsulate the logic and the objects with which a class

communicates in a modular way.

• Depht of Inheritance Tree (DIT). Figure 4.13 shows that in OO solution, the

median value in the release 06 was high, besides showing an outlier in release 07. In

AO solution, both releases 05 and 07 presented an outlier. In addition, the median

value in the release 06 was also high.

In both solutions, the median presented similar DIT value. Except for release 01,

which had low value in AO, since the aspects helped in reducing the DIT value. In

general, the data set presented a similar behavior related to DIT measure and did

not show any interesting insight.

Table 4.9 shows the descriptive statistics to DIT measure for all releases. Observing

the mean value for all releases, we have considered the OO implementation is more

coupled regarding the DIT measure.

In summary, for the coupling measures, the variation between the solutions was very

similar. Observing the DIT measure, both solutions presented largely the same values.

The CBC and RFC plots show that in both solutions these measures presented more

irregular values for releases, in which the OR and Alternative features were included.

However, the OO solution presented more stable values for all releases.


$"

%"

&"

("

'"

!"

)"

+"

*"

,"

%$"

%%"

%&"

#$%" #$&" #$(" #$'" #$!" #$)" #$+" #$*"

(a) OO

!"

&"

'"

#"

*"

,"

("

%"

+"

)"

&!"

&&"

&'"

$!&" $!'" $!#" $!*" $!," $!(" $!%" $!+"

(b) AO

Figure 4.13: Boxplots for Depht of Inheritance Tree (DIT)

4.6.4 Package stability Analysis

Reuse and maintenance tend to be hard in highly interdependent designs. Martin’s

instability metric simultaneously measures the package stability and instability Martin

(1995). Based on the dependence analysis among packages it is possible to measure

responsiveness for software reuse and maintenance.

This subsection presents a quantitative analysis to answer:RQ04 – Does the use of

aspect-oriented solutions provide less instable package than object-oriented solutions? and




Table 4.9: DIT Descriptive StatisticsRelease Variable Components Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 21 1,667 2,153 4,633 0,00 0,00 1,00 4,000 6,000AO 23 1,522 2,108 4,443 0,00 0,00 0,00 4,000 6,000

02OO 27 1,852 2,196 4,823 0,00 0,00 1,00 4,000 6,000AO 29 1,724 2,170 4,707 0,00 0,00 1,00 4,000 6,000

03OO 30 1,967 2,220 4,930 0,00 0,00 1,00 4,250 6,000AO 32 1,844 2,201 4,846 0,00 0,00 1,00 4,000 6,000

04OO 39 2,077 2,181 4,757 0,00 0,00 1,00 4,000 6,000AO 42 1,929 2,168 4,702 0,00 0,00 1,00 4,000 6,000

05OO 47 2,213 2,216 4,910 0,00 0,00 1,00 5,000 6,000AO 50 2,080 2,431 5,912 0,00 0,00 1,00 4,000 11,000

06OO 52 2,346 2,231 4,976 0,00 0,250 2,00 5,000 6,000AO 55 2,291 2,225 4,951 0,00 0,00 2,00 5,000 6,000

07OO 28 1,964 2,396 5,739 0,00 0,00 1,00 3,500 8,000AO 31 1,645 2,090 4,370 0,00 0,00 1,00 2,000 6,000

08OO 30 2,100 2,234 4,990 0,00 0,00 1,00 4,250 6,000AO 33 1,909 2,213 4,898 0,00 0,00 1,00 4,000 6,000

paradigms affect the stability measure in DSPL evolution.

Figure 4.14 shows the instability criterion in each solution concerning one measure,

Instability Metric (IM). A general interpretation of this measure is that a value close

to zero indicates a less instable solution. We next provide a descriptive analysis of the

measure.

• Instability Metric (IM). The releases 01, 02, and 03 in OO presented constant

median value. It means that the inclusion of Optional features do not affect the

package stability within of a DSPL. On the other hand, in releases 04, 05, 06, 07,

and 08 owing to the inclusion of OR and Alternative features, the IM median

value was high and irregular, resulting in more instability. Table 4.10 shows the

descriptive statistics to IM measure for all releases.

The IM values closer to zero are preferable. However, changes made to other packages

directly affected packages containing aspects. Thus, in AO, the maximum values for

all releases were close to 1. Moreover, the IM median for all releases exceeded the

0.4 value comparing the OO solution, in which this value was lower than 0.4.

Although the variance of the data set between both OO and AO had been almost

similar, the IM mean value to the second solution was higher than in the former

solution, beyond irregular for all releases. In the AO, the crosscutting concerns

were modularized into aspects, resulting in more outgoing dependencies (Ce) than

incoming dependencies (Ca). It means that the packages in AO were more susceptible

to changes than in OO, resulting in less stability.


!$

!",$

!"+$

!"*$

!")$

!"-$

!"#$

!"'$

!"&$

!"($

,$

%!,$ %!+$ %!*$%!)$ %!-$ %!#$ %!'$ %!&$

(a) OO

!$

!"+$

!")$

!"#$

!"*$

!",$

!"&$

!"'$

!"-$

!"($

+$

%!+$ %!)$ %!#$ %!*$ %!,$ %!&$ %!'$ %!-$

(b) AO

Figure 4.14: Boxplots for Instability metric (IM)

4.6.5 Modularity Analysis

Separation of concerns consists in the ability of identifying, encapsulating and manipulating

parts of software that are relevant to a particular concern (Tarr et al., 1999). It improves

the software maintainability reducing the complexity, and consequently, it increases the

reuse of the components.


aspect-oriented solutions provide more modular design than object-oriented solutions? and




Table 4.10: IM Descriptive StatisticsRelease Variable Package Mean StDev Variance Minimum Q1 Median Q3 Maximum

01OO 9 0,408 0,365 0,133 0,00 0,038 0,333 0,768 0,857AO 9 0,433 0,375 0,140 0,00 0,036 0,533 0,793 0,857

02OO 9 0,417 0,370 0,137 0,00 0,026 0,333 0,774 0,900AO 9 0,432 0,372 0,138 0,00 0,025 0,476 0,778 0,900

03OO 9 0,421 0,375 0,141 0,00 0,019 0,333 0,786 0,917AO 9 0,433 0,375 0,140 0,00 0,019 0,458 0,786 0,917

04OO 9 0,427 0,374 0,140 0,00 0,024 0,346 0,778 0,938AO 9 0,437 0,375 0,141 0,00 0,024 0,438 0,773 0,955

05OO 9 0,432 0,381 0,145 0,00 0,018 0,364 0,792 0,950AO 9 0,438 0,380 0,145 0,00 0,018 0,436 0,785 0,962

06OO 9 0,431 0,383 0,146 0,00 0,015 0,342 0,796 0,957AO 9 0,437 0,381 0,145 0,00 0,015 0,409 0,789 0,966

07OO 9 0,413 0,360 0,130 0,00 0,037 0,375 0,753 0,900AO 9 0,436 0,375 0,141 0,00 0,036 0,500 0,780 0,938

08OO 9 0,414 0,368 0,135 0,00 0,031 0,353 0,767 0,909AO 9 0,429 0,373 0,139 0,00 0,030 0,478 0,765 0,938

paradigms affect SoC measures in DSPL evolution. A general interpretation of these

measures is that lower values indicate a modular solution. We next provide a descriptive

analysis of each measure.

• Overview of the modularity analysis for SmartHomeRiSE

Figure 4.15(a) and Figure 4.15(b) show the SoC criterion in each solution concerning

two measures: Concern Diffusion over Components (CDC) and Concern Diffusion

over Operations (CDO), respectively.

For OO, the CDC mean value was reduced from 01 until 06 releases. However, the

inclusion of optional features affected the degree of scattering across the modules.

In contrast, the same did not occurr for AO, in which presented constant mean

values for releases 01, 02, and 03.

It is important to highlight that the inclusion of alternative features not affected

the mean values in both solutions. It means that OO as well as AO are suitable to

encapsulate this type of feature not only considering the component level, but also

in the operations granularity level. On the other hand, the CDC plot shows that

the mean values were irregular with inclusion of the OR features since it increased

the mean values for AO solution in releases 05, 06, and 07.

The CDO mean values for AO were consistently the lowest in all releases, except 05

release. We have associated this with inclusion of OR features. By comparing the

CDC and CDO mean values in AO with the mean values in OO, it indicates that

AO was not so effective to reduce scattering of OR features across the modules.


!"

!#$"

!#%"

!#&"

!#'"

!#("

!#)"

!#*"

!#+"

,!$" ,!%" ,!&" ,!'" ,!(" ,!)" ,!*" ,!+"

--"

.-"

(a) CDC

!"

!#$"

!#%"

!#&"

!#'"

!#("

!#)"

!#*"

+!$" +!%" +!&" +!'" +!(" +!)" +!*" +!,"

--"

.-"

(b) CDO

Figure 4.15: SoC mean values through SmartHomeRiSE evolution.

Additionally, by observing the plots curves, we noticed that the OO and AO

implementations presented an irregular variation for CDC and CDO mean values.

For CDC mean value, AO presented more stable values than OO. In contrast, for

CDO mean values, OO presented more stable values than AO. As a matter of fact,


we cannot to state which solution offers a more stable design according to this overall

analysis.

• Dispersion analysis of modularity metrics for SmartHomeRiSE

Although the plots previously presented have been useful in terms of overall insight,

they were limited for analyze the dispersion of the data. The mean value can be

significantly skewed by outliers and do not represent the tendency of many part of

the data. For this reason, we conducted an analysis of the dispersion of the data

using probability plots aiming to gain confidence on the previous results.

Figure 4.16(a) and Figure 4.16(b) show the probability plots of the SmartHomeRiSE

releases for OO and AO. In these plots, a box with the AD value and their respective

p-value was provided, besides mean and StDev values. If the p-value is greater than

0.05 the data do not follow the specified distribution. A not-specified distribution

does not impact the analysis, since we just want to compare the curves of different

paradigms for different or similar behavior.

In the probability plots, each point is an CDC/CDO value for a group of features

in an specific release using an specific paradigm. The x-axis corresponds to the

CDC/CDO value and y-axis corresponds to the percentage number of plotted points

from the bottom up. Lower CDC/CDO values are plotted firstly from the bottom

up. For instance, in the square point at the lower part of the plot 4.16(b) represents

a CDO value 0.32 and the y-axis indicates that 3.43% of the points (in fact two

points) were plotted. In order to interpret the plot, we can observe that 88.23% of

the CDO values for OO are further to the right. This fact reveals that the mean

value for CDO is higher for OO than AO. In AO, 3.43% of the CDO mean value

is lower than OO. In addition, 18.13% of the CDO mean values are similar for

both solutions. It explains why in the overall analysis previously discussed, the AO

solution presented more releases with lower CDO mean value than OO solution.

The results of the CDC metric did not follow the same trend of the CDO metric. The

CDC mean values for both solutions were closely irregular. The plot 4.16(a) shows

that a range of the 74.3% to 92.4% of the CDC values were higher for OO than AO.

In contrast, the following CDC values were lower for OO: 3.43%, 62.3%, and the

range of the 22.2% to 39.9%. We believe that this situation occurs due to granularity

of components and operations. Whether the granularity of operations is lower than

granularity of components, then the distribution of group of features is proportional

in both solutions. On the other hand, since the granularity of components is higher,


(a) CDC

(b) CDO

Figure 4.16: Probability plots for SoC metrics


the impact on modularity metrics is higher too.

In general, the AO solution presented lower mean and StDev values for both, CDC

and CDO metrics than OO solution. As a result, we consider that AO was more

effective to modularize the concerns in DSPL evolution. In addition, the plot curves

show that AO solution presented more stable values for all releases.

4.6.6 Change Impact Analysis

The change is a key aspect for software development, since it matches to evolve require-

ments as well as improve software. In this case, the design stability is directly related

to effects of the changes. Ideally, the evolution tasks in the context of DSPL should be

conducted through non-intrusive and self-contained changes that favor insertions and not

require deep modifications into existing components.

Variability management plays an important role in DSPL evolution, due to the need

to avoid inconsistent adaptations at runtime. In this sense, the variability mechanism

should provide support to extend the system functionality, ensuring the DSPL architecture

stability, and not decrease modularity. These requirements are related to the Open-

Closed Principle, which states that “software should be open for extension, but closed

for modification” (i.e., extending the system functionality by adding new artifacts, but

minimizing the amount of modifications in the current code) (Martin, 2000).


aspect-oriented solutions provide more stable design than the object-oriented solutions?

and RQ07 – Does the use of aspect-oriented solutions has smoother change propagation

impact than the object-oriented solutions? In particular, we were interested to know how

the different paradigms affect the evolution and reuse tasks in the context of DSPL and

support the analyzes aforementioned.

We have used traditional change impact metrics (Yau and Collofello, 1985; Greenwood

et al., 2007), considering different levels of granularity: components, operations, and lines

of code. A general interpretation of these measures is that the lower the change impact

measures the more stable and resilient the design is to a specific change. Table 4.11 shows

the summary of the SmartHomeRiSE implementation and change propagation metrics.

In general, removing the number of lines of code, operations, and components did

not bring significant difference and variation between the measures of OO and AO. In

addition, both solutions had similar change propagation values. However, AO generally

require more new components, operations, and lines of code to implement the changes

during evolution and reuse tasks.


Table 4.11: Summary of the SmartHomeRiSE implementation

R01 R02 R03 R04 R05 R06 R07 R08

Absolute value

Lines of CodeOO 1361 1834 2100 2787 3490 4059 1980 2198

AO 1390 1846 2112 2819 3521 4087 1904 2177

OperationsOO 129 164 185 245 295 341 182 201

AO 137 170 191 254 298 350 187 202

ComponentsOO 19 24 27 36 43 48 26 28

AO 20 26 29 39 47 51 29 31

Lines of CodeAdded

OO - 473 266 687 703 569 0 1042

AO - 456 266 707 702 566 0 1011

RemovedOO - 0 0 0 0 0 2206 454

AO - 0 0 0 0 0 2183 463

OperationsAdded

OO - 35 21 60 50 46 0 45

AO - 33 21 63 44 52 0 42

RemovedOO - 0 0 0 0 0 90 21

AO - 0 0 0 0 0 93 21

ComponentsAdded

OO - 6 2 2 7 5 0 13

AO - 6 2 2 9 5 0 13

RemovedOO - 0 0 0 0 0 24 7

AO - 0 0 0 0 0 24 7

Observing the absolute values in releases 02, 05, 07, and 08, they indicate that

OO solution required existing components to be modified more extensively in order to

implement the changes. This behaviour was confirmed in the change propagation metrics,

since its values showed more extensive changes in terms of added lines of code and

operations. In these cases, AO solution is more in accordance with the Open-Closed

principle. On the other hand, the same did not happen in releases 04 and 06, since the

number of added lines of code and operations were exceeded in AO. In addition, the

release 03 presented similar values in both solutions.

The analysis of these scenarios through change propagation metrics have confirmed

that the inclusion of optional and alternative features have affected more the design

stability in OO than AO. Thus, it is more effective the use of aspects to manage these

type of features in DSPL evolution. When considering the inclusion of OR features, it

indicates that AO solution has more design stability impact. It means that aspects reduce

the absorbing of changes.

4.7 MAIN FINDINGS OF THE STUDY 89

4.6.7 Hypothesis testing

This subsection describes the Mann-Whitney-Wilcoxon and Kruskal-Wallis methods

applied to test the hypotheses defined for the exploratory study. These non-parametric

tests were performed due to the skewness of the samples. The results of both tests are

presented as follows.

• The Mann-Whitney-Wilcoxon Test was performed due to the skewness of the

samples presented in the graphs. It consists of an alternative test to the t-Student

Test to compare the means of two independent samples without assuming them to

follow the normal distribution.

Table 4.12 shows the results of these tests. Observing the p-value, we concluded

that the null hypothesis has not been rejected at the 0.05 significance level among

the median values of the metrics for both, OO and AO solutions.

• The non-parametric Kruskal-Wallis Test was also performed due to the skewness

of the samples presented in the graphs. It consists of an variance analysis by ranks

and does not require normal distribution.

Table 4.13 shows the results of these tests. For all metrics, the null hypothesis has

not been rejected at the 0.05 significance level. Thus, the sample distribution of the

releases were considered similar.

Although the tests have not rejected H0, it does not means that the null hypothesis

is true. In other words, the existing evidence has not been sufficient to reject it.

4.7 MAIN FINDINGS OF THE STUDY

The exploratory study aimed to quantitatively asses the impact of different paradigms for

DSPL evolution. The objective was to gather evidence on how object-oriented and aspect-

oriented solutions affect quality attributes in the context of DSPL. All the assessments of

the data set were essential to arrive at findings about the solutions. In particular, the

outliers were carefully treated in all releases. Its values were consistent with the remainder

of the data and contributed with the final outcome. The main findings of this study can

be summarized as:

• Although the AO implementation add more pointcuts and advices needed to mod-

ularize concerns, the OO implementation is more complex regarding the WOC

measure.


Table 4.12: Comparison between OO and AO according to Mann-Whitney Test

Release MetricsMann-

Whitney Up-value Release Metrics

Mann-Whitney U

p-value

01

WOC 234.5 0.8780

05

WOC 1108.5 0.6321LOC 231.0 0.8141 LOC 1132.5 0.7615CDC 251.5 0.6853 CDC 1175.0 1.0000CDO 245.5 0.9338 CDO 1152.5 0.8725LCOO 221.0 0.5778 LCOO 1119.0 0.6555CBC 238.0 0.9403 CBC 1170.0 0.9732DIT 230.5 0.7909 DIT 1102.5 0.5940RFC 225.0 0.7059 RFC 1114.5 0.6641IM 49.5 0.4513 IM 40.0 1.0000

02

WOC 380.5 0.8626

06


03

WOC 467.0 0.8596

07


04

WOC 786.0 0.7576

08


• Observing the LOC measure, we have considered that the OO implementation is

more complex than AO, since the use of aspects reduces the number of lines of code

for all components.

4.7 MAIN FINDINGS OF THE STUDY 91

Table 4.13: Comparison among OO and AO releases according to Kruskal-Wallis Test

Solutions Metrics Chi-Squared df p-value

OO

WOC 0.4975 7 0.9995LOC 0.1427 7 1.0000CDC 1.0818 7 0.9934CDO 0.8947 7 0.9964LCOO 0.6263 7 0.9988CBC 1.1025 7 0.9930DIT 4.5158 7 0.7188RFC 0.7729 7 0.9977IM 0.0185 7 1.0000

AO

WOC 0.8240 7 0.9972LOC 0.5606 7 0.9992CDC 1.6921 7 0.9749CDO 0.4450 7 0.9996LCOO 2.9524 7 0.8894CBC 1.3264 7 0.9877DIT 5.8551 7 0.5568RFC 1.0746 7 0.9935IM 1.0587 7 0.9938

• As a general indicator for the size attribute, both OO and AO presented almost

similar behavior, resulting in very similar stability for evolution task and reuse.

• In general, AO was better with respect to LCOO measurement, since the aspects

filter out crosscutting behavior. It means that AO is more cohesive than OO.

• In OO solution more scenarios were affected with regard to cohesion. As general

conclusion for the cohesion attribute, AO is more stable than OO.

• AO was better with respect to CBC measurement, since the presence of aspects is

likely to decrease the coupling between core classes.

• In general, the OO implementation is more coupled regarding the DIT measure.

• The RFC value increased in the presence of aspects. However, in AO solution is

possible to encapsulate the logic and the objects with which a class communicates

in a modular way.

• In general, for the coupling attribute, the variation between the solutions was very

similar. Observing the DIT measurement, both solutions presented largely the

same values. Regarding to CBC and RFC measurements, both solutions presented


more irregular values for releases, in which the OR and Alternative features were

included. However, the OO solution presented more stable values for all releases.

• Although the variance of the data set between both OO and AO had been similar,

the IM mean value to the second solution was higher than in the former solution,

beyond irregular for all releases. It means that the packages in AO were more

susceptible to changes than in OO, resulting in less stability.

• The inclusion of alternative features not affected the mean values in both solutions.

It means that OO as well as AO are suitable to encapsulate this type of feature not

only considering the component level, but also in the operations granularity level.

• By comparing the CDC and CDO mean values in AO with the mean values in OO,

it indicates that AO was not so effective to reduce scattering of OR features across

the modules.

• We cannot to state which solution offers a more stable design according to the

overall analysis, since it was limited for analyze the dispersion of the data.

• The analysis of the dispersion of the data using probability plots contributed for

gaining confidence on the results obtained from the overall analysis. In this case, we

have confirmed that the AO solution presented more releases with lower CDO mean

value than OO solution.

• In general, the AO solution presented lower mean and StDev values for both, CDC

and CDO metrics than OO solution. As a result, we consider that AO was more

effective to modularize the concerns in DSPL evolution. In addition, the AO solution

presented more stable values for all releases.

• The AO solution is not recommended to implement OR features in the context of

DSPL. New aspects have to be included in addition to the classes realizing the

features. Operations are also included more in AO solution due to the newly created

advices.

• The AO solution often changes less components and operations. Thus, it conforms

more closely to Open-Closed principle.

• In general, removing the number of lines of code, operations, and components did

not bring significant difference and variation between the measures of OO and AO.

In addition, both solutions had similar change propagation values. However, AO

4.8 LESSONS LEARNED 93

generally require more new components, operations, and lines of code to implement

the changes during evolution and reuse tasks.

• The analysis of the scenarios through change propagation metrics have confirmed

that the inclusion of optional and alternative features have affected more the

design stability in OO than AO. Thus, it is more effective the use of aspects to

manage these type of features for DSPL evolution. When considering the inclusion

of OR features, it indicates that AO solution has more design stability impact. It

means that aspects reduce the absorbing of changes.

4.8 LESSONS LEARNED

After concluding the exploratory study, some aspects should be taken into consideration.

Such aspects may aid further replications of the study, as they could be understood as

limitations faced in the present execution.

Domain. The smart home domain should be rediscussed since it is a nontrivial

domain and often a domain expert is necessary to aid in the process. For instance, the

domain encompasses the computerized systems to perform interactions with objects in

the physical environment (i.e., it is based on the Cyber-Physical Systems). Thus, it

is important that domain experts participate of the planning in order to solve possible

problems of integration. Moreover, as it can be seen in Appendix A, only basic features

were provided. Thus, the domain must support evolution, which will be reflected for

implementing new features.

Project. One graduate student and one master student implemented the DSPL

project. This aspect should be reconsidered in order to include more engineers and mainly

domain experts that will perform the exploratory study.

Paradigm. The transfer of the aspect-oriented solution to DSPL development is

largely dependent on the ability to understand the paradigm specification and implement

it. In this sense, a complete and detailed planning should be defined by software designers

in order to cover the concerns to be modularized into aspect in the DSPL evolution.

Evolution. In the exploratory study, the evolution of DSPL project was manually

carried out. However, as the number of new requirements grows, the inclusion of features

may become a complex task. Thus, an automatic inclusion of features could facilitate

the engineer work. In this sense, the impact of evolving in the running system should be

investigated in order to identify more flexible solutions in offering automatic configuration

and reconfiguration.


4.9 THREATS TO VALIDITY

The validity of the empirical study denotes the reliability of the findings and whether the

findings are true and not biased. In addition, the validity must be addressed during all

previous phases of the exploratory study (Runeson and Host, 2009). In this sense, the

constraints on the validity of this evaluation are discussed as following.

4.9.1 Construction validity

It reflects to what extent the operational measures that are studied really represent the

purpose of the study and what is investigated according to the research questions (Runeson

and Host, 2009). In other words, it is concerned with the relation between theory and

observation (Wohlin et al., 2000). In our exploratory study, we identified different threats

to construction validity, as follows:

Dependent variables. Complexity, cohesion, coupling, and instability are difficult

concepts to measure. For this study, the metrics were selected based on the previously

performed studies (Ferreira et al., 2014; Figueiredo et al., 2008; Gaia et al., 2014; Greenwood

et al., 2007), which obtained relevant results using them. In addition, in order to produce

robust answer about design stability, we used the traditional change impact metrics.

Reliability of measures. In order to increase the reliability of measures, the

AOPMetrics and ConcernMorph tools addressed in the literature were used to collect

the data set that was evaluated in this exploratory study. In addition, theConcernMorph

tool has automatically generated the results and the separation of concern had to be

performed manually. For this reason, the collected data set was checked in order to

minimize the bias.

Boredom. The exploratory study compares two paradigms and the subjects had

to implement eight releases for each design solution based on change scenarios defined.

The releases contain a certain quantity of code that must be changed, thus it might be a

repetitive work in some cases. In addition, the building of a prototype was necessary in

order to support the project. This situation led to define the exploratory study design

into two treatments. On the other hand, each treatment encompasses some tasks. In

this way, the subjects may feel upset with the exploratory study. In order to reduce the

boredom of the exploratory study, each subject became responsible for one treatment.

4.9 THREATS TO VALIDITY 95

4.9.2 Internal validity

There is a threat to the internal validity when an element that is unknown by the researcher

affects the investigated factor (Runeson and Host, 2009). In other words, the treatment

causes the outcome (the effect) (Wohlin et al., 2000).

There is a main threat to internal validity in the study instrumentation. This empirical

study cannot be considered a controlled experiment, since both subjects took part in the

development of the two systems and its respective releases. For this reason, we selected

one subject with considerable expertise in software development as application engineer,

and another one with expertise in DSPL as domain engineer.

Additionally, there are other likely threats that were considered in this exploratory

study, such as the assessment of a single domain, the variability mechanisms, and the

number of releases. In order to mitigate these threats, we aim to carry out further

empirical studies considering other domains, different variability mechanisms, and new

releases.

4.9.3 External validity

It is concerned with the generalization of the empirical study results (Runeson and Host,

2009). It was not possible to apply the same study in another research group due to the

time restriction. Nevertheless, the findings of the analysis can be used as baseline for

comparing other studies in the context of DSPL, since the exploratory study protocol has

been developed in detail and reviewed by researchers. Thus, it reduces the threat to the

external validity of the exploratory study.

4.9.4 Conclusion validity

It is concerned with the relationship between the treatment and the outcome. It determines

the capability of the study to generate conclusions. Hypothetically, the result should be

the same if another researcher later on conducted the same study (Wohlin et al., 2000;

Runeson and Host, 2009).

Since 3664 data points were collected, the reliability of the measurement process might

be an issue. For this reason, an independent author who did not collect the respective

data applied statistical analysis. Finally, the results of the study were described using

Descriptive statistics, which deal with numerical processing and presentation of a data set.

It is the most suitable method to describe the analysis and interpretation of this data

type collected.


4.10 CHAPTER SUMMARY

This chapter presented an assessment through the definition, planning, operation, analysis,

and interpretation of an exploratory study performed to compare different paradigms

for DSPL evolution. For this exploratory study, was performed analyzes, considering

complexity, cohesion, coupling, package instability, modularity, change propagation impact,

and design stability. The results pointed out few difference between the paradigms.

However, the descriptive statistic was important to achieve the concrete findings described

in Section 4.7.

In general, the AO solution presented better results in many analyses. Thus, it indicates

that the use of aspects increases the software quality by affecting internal attributes such

as size, cohesion, coupling, and SoC, besides reducing the change propagation impact

during the evolution task and reuse. In this sense, such paradigm may be suitable to be

applied on DSPL and it will depend of the context or customer needs.

The results from the mechanisms characterization and the exploratory study consist

of initial guidelines to support implementation activities in this context. Next chapter

presents the main conclusions, directions for future work, and related work.

Chapter

5The eye sees only what the mind is prepared to comprehend. — Robertson Davies, Tempest-Tost

CONCLUSIONS

This dissertation presents the conduction of an investigation on variability implementation

mechanisms (Chapter 3), from which we were able to select which ones can be handled in

the context of DSPL. The objective of the investigation was to present a holistic overview

of the existing studies that had been reported regarding the variability mechanisms.

Based on it, it was possible to obtain an overall view of DSPL area. We observed

that the dynamic variability implementation still is a remaining challenge and the lack

of a characterization of variability mechanisms for DSPL was identified as an interesting

gap that could be addressed. In this way, a set of criteria was developed in order to

characterize the variability mechanisms addressed in few related work. These criteria are

based on existing literature and aim at assisting developers at the early stage of DSPL

implementation.

Once characterized the variability mechanisms, it was developed a DSPL project using

a set of mechanisms considered most suitable. Thus, this dissertation also presents an

exploratory study in the smart home domain (Chapter 4), from which we were able to

understand the impact of using different paradigms in the DSPL evolution. The objective

of the exploratory study was to compare the object-oriented and aspect-oriented solutions

for DSPL evolution.

According to assessment, the aspect-oriented solution presented better results in many

analyses. In this sense, such paradigm was pointed out as a suitable solution for dealing

with specific situations. The use of aspects indicates that it provides assets with a good

modularity, good cohesion, and low change propagation impact.

97

98 CONCLUSIONS

Nonetheless, we understand that other domains could be used in order to assess

the application of the solutions to implement DSPL evolution. It means that another

exploratory study following the same research issues can be more conclusive stating which

solution is more suitable. In Section 5.1 we sketch the main contributions achieved so far

with this investigation. Next, in Section 5.2 we discuss the main related work. Section 5.3

we present concluding remarks. Finally, Section 5.4 we discuss future research directions.

5.1 MAIN CONTRIBUTIONS

We earlier described in the Section 1.4 the main contributions expected from this inves-

tigation. Some of the results have been already published. A paper resulting from this

investigation was accepted for publication:

• LESSA, Matheus; CARVALHO, Michelle; SANTOS, Alcemir; ALMEIDA, Eduardo.

SmartHomeRiSE: An DSPL to Home Automation. In: VI Brazilian Confer-

ence on Software: Theory and Practice. Tools Section. 2015, Belo Horizonte.

Moreover, we are currently submitting other papers to report the remaining results.

5.2 RELATED WORK

The evolution of DSPL regarding to unexpected software changes has got attention from

researchers investigating variability management. However, a few experience reports

present suitable mechanisms to implement dynamic variability (Cetina et al., 2009a;

Buregio et al., 2010). Moreover, several studies address variability modeling (Dinkelaker

et al., 2010), nevertheless, they have different focus because they do not describe the

implementation of a DSPL.

5.2.1 Approaches for Variability Management and Implementation

Gacek and Anastasopoules (2001) analyzed several implementation approaches with

respect to their use in order to handle product line variability at code level. Our approach

is similar, however, it is focused on implementation mechanisms targeted to the dynamic

variability. Gurp et al. (2001) also described some possible mechanisms for variability

implementation. Nevertheless, their study had different focus and did not perform a

comparison among the mechanisms targeted at the dynamic variability.

R.Wolfinger and Doppler (2008) integrated static binding of SPL and runtime adapta-

tion DSPL generating a tailor-made DSPL from a highly customizable SPL. They also

5.2 RELATED WORK 99

provided a feature-based adaptation mechanism that reduces the effort of computing an

optimal configuration at runtime. This approach shows that a seamless integration of

static binding and runtime adaptation reduces the complexity of the adaptation process.

Though they present an initial solution to control and correct errors that occur with

the emergence of new variants at runtime and their approach was aimed to use plug-in

techniques based on the .NET, it did not describe the implementation activities.

Bencomo et al. (2008b) associated the need to support unanticipated adaptations in

dynamically adaptive systems to two types of variability such as: environment or context

variability, when the evolution of the environment cannot be predicted at design time; and

structural variability, which covers the variety of the components (or features) and the

variety of their configurations. In order to satisfy the requirements for the new context,

the system may add new features or organizing the current configuration. Based on

this scenario, they proposed a mechanism for supporting runtime variability by using

component frameworks and reflection. However, the focus of this approach was aimed to

the notation and models to manage dynamic variability.

Alves et al. (2009) compared variability management between SPL and Runtime

Adaptation. They presented an initial discussion about the feasibility of integration for

variability management in both areas using some useful criteria for our work such as:

goal and binding time. However, these criteria were adapted for the context of DSPL by

considering the implementation of dynamic variability.

5.2.2 Smart Home Domain

Some studies, such as Cook et al. (2003); Yang et al. (2015); Cetina et al. (2010) addressed

issues concerning the development of smart homes. Cook et al. (2003) used artificial

intelligence to control the smart home actions based on predictive algorithms. Their

findings were relevant but the most important drawback appears on the evolution and

reuse aspects since that these algorithms are not sufficiently flexible and cannot deal with

not projected context changes. On the other hand, DSPL applications are designed to

respond to unexpected changes and to keep at least minimum functions started, however,

the agent-based decision model can be an improvement to our DSPL project targeted to

the smart home domain.

Another architectural approach was proposed by Yang et al. (2015) that presented an

architecture based on services to achieve the problem of interoperability among multiple

devices in the home environment. In our work, all the smart home applications are built

as an DSPL and the interoperability issue was treated by recofiguration rules providing

100 CONCLUSIONS

centralized control.

Cetina et al. (2010) designed and developed an prototype to deal with DSPL-design

issues with recovery from a failed reconfiguration or a reconfiguration triggered by mistake.

To address this challenge, they developed a technique that is based on RFID-enabled

cards to easily specify the current DSPL context. In addition, it has been applied with

the participation of human beings through a case study of the Smart Hotel. This work

has been useful to identify how to manage variation points in dynamic applications that

suffer changes at any moment because of human interference and the environment, in

which it is inserted. However, this approach is an insight of the application of prototyping

techniques at variability modeling and it does not present details on the implementation

of DSPL applications.

5.2.3 Empirical Studies

Some work use AOP to improve (i) the isolation of specific features, (ii) increase the

code quality, and (iii) reduce the impact of using aspects in designs of single systems

(Greenwood et al., 2007) and SPL evolutionary scenarios (Figueiredo et al., 2008). However,

none of them has analyzed the impact of AOP on evolution scenarios in the context of

DSPL.

Greenwood et al. (2007) reported a quantitative case study of object-oriented and

aspect-oriented implementations. The study was based on a number of system changes that

are typically performed during software maintenance tasks. They ranged from successive

refactorings to more broadly-scoped software increments relative to both crosscutting and

non-crosscutting concerns. The study included an analysis of the application in terms of

modularity, change propagation, concern interaction, identification of ripple-effects and

adherence to well-known design principles. However, the focus of this approach is not

aimed to variability management task.

Figueiredo et al. (2008) presented a quantitative study targeted for evolution of two SPL

in order to assess several facets of their aspect-oriented implementations.The investigation

focused upon a multi-perspective analysis of the evolving SPL in terms of modularity,

change propagation, and feature dependency. As a result, they identified a number of

scenarios which positively or negatively affect the architecture stability of aspectual SPL.

Though this work report the design stability and modularity analysis according to the

feature types, its approach was aimed the binding time at compile-time in the context of

SPL.

5.3 CONCLUDING REMARKS 101

Ferreira et al. (2014) reported the quantitative and qualitative analysis of how feature

modularity and change propagation behave in the context of two SPL developed in

three different variability mechanisms: Feature-oriented Programming (FOP), conditional

compilation (CC), and object-oriented design patterns. This work has been useful

to identify how to perform the design stability analysis by using traditional change

propagation metrics. However, it does not perform an analysis targeted to use of AOP.

Gaia et al. (2014) investigated whether the simultaneous use of aspects and features

through the Aspectual Feature Modules (AFM) approach facilitates the evolution of

SPL. The quantitative assessment was based on two SPL developed using four different

variability mechanisms, such as: feature modules aspects and aspects refinements of AFM;

aspects of AOP; feature modules of FOP; and CC with object-oriented programming. In

this work, the data set was collected through the change propagation and modularity

metrics. The results obtained from this analysis benefited the AFM option in a context

where the SPL has been involved with addition or modification of crosscutting concerns.

However, they identified a drawback of this approach that consists of a higher degree

of modifications to SPL structure when the refactoring of the component’s design is

required. This work has been useful to identify how to perform the modularity analysis

associating the feature and concern concepts. However, it does not report the obtained

results according to the feature types.

The aforementioned work have been useful, since they report conceptual discussions

about implementation mechanisms, variability management, and self-adaptive systems

implementation. Moreover, some of them report quantitative assessment targeted at

maintenance and reuse scenarios and software design stability. However, they did not

compare object-oriented and aspect-oriented implementations in the context of DSPL. We

believe that our work may provide an initial contribution to the DSPL engineering field.

5.3 CONCLUDING REMARKS

The exploratory study analyzed the smart home domain structured as a DSPL application,

based on commonality and variability analysis according to specific characteristics of

the domain. It also analyzed the possibility of use object-oriented and aspect-oriented

solutions to implement components with lower complexity, good cohesion, low coupling,

and good modularity. Moreover, the assessment encompassed the package instability,

change propagation impact, and design stability analysis.

The exploratory study was conducted with two subjects, and the paradigms were

compared among each other. The most of data analyzed were not significant making

102 CONCLUSIONS

it difficult to draw concrete conclusion about which solution is better. However, the

descriptive statistic was a key step in order to check the differences among the data

analyzed. For each factor, such as complexity, cohesion, coupling, and instability, the

descriptive statistics presented some results that must be considered when using both

solutions for DSPL implementation.

The Mann-Whitney-Wilcoxon and Kruskal-Wallis methods applied to test the hy-

potheses did not provide sufficient data to reject the null hypothesis. We believe that the

sample size was a possible reason for the results. The Mann-Whitney Test, for instance,

has little power with small samples and will always give a p-value greater than 0.05 no

matter how much the groups differ. Therefore, the test results have not stated that two

solutions are equal.

The main findings of the study showed that a solution fits best in particular cases. In

this sense, AO was pointed out as a suitable solution for dealing with specifics situations.

For example, the use of aspects indicates that it provides assets with lower complexity,

lower coupling, higher cohesion, and support lower change propagation impact. On the

other hand, the packages in AO were more susceptible to changes than in OO, resulting

in less stability.

5.4 FUTURE WORK

Due to the time constraints imposed on a M.Sc. degree, this work can be seen as an initial

step towards implementation of DSPL. In this way, more research need to be conducted

in order to improve what was started, and new paths should be explored. Thus, the

following issues should be investigated as future work:

Automating the evolution and reuse process. In the exploratory study, we

manually carried out the evolution of DSPL. However, as the number of new requirements

grows, the inclusion of features may become a complex task. Thus, an automatic features

inclusion could facilitate the engineer work. In addition, the impact of evolution on

the running system should be investigated in order to identify more flexible solutions in

offering automatic configuration and reconfiguration.

New empirical studies. This dissertation presented the definition, planning, analy-

sis, and interpretation of an exploratory study in the smart home domain. Nonetheless,

we believe that other domains should be used in order to assess the application of the

solutions to implement DSPL evolution. Further research actions should be taken in order

5.4 FUTURE WORK 103

to gather more solid evidence about the findings. As future work, we intend to conduct

new studies in other domains, considering also other paradigms and languages, such as

Delta-oriented Programming and Context-oriented Programming.

Implementation guidelines. Based on new exploratory studies, we believe that

we will be able to define a decision model and implementation guidelines for guiding

software engineers on the development of DSPL. The implementation guidelines and

decision model will support in the choice of a solution according to some criteria (e.g.,

complexity, cohesion, coupling, package stability, modularity, design stability, and change

propagation).

REFERENCES

Alves, V., Schneider, D., Becker, M., Bencomo, N., and Grace, P. (2009). Comparative

study of variability management in software product lines and runtime adaptable systems.

In Proceedings of the 3rd Intternational Workshop Variability Modeling of Software-

Intensive Systems (VaMoS 09), pages 9–17.

Apel, S., Batory, D., Kastner, C., and Saake, G. (2013). Feature-Oriented Software

Product Lines; Concepts and Implementation. Springer.

Baresi, L., Guinea, S., and Pasquale, L. (2012). Service-oriented dynamic software

product lines. IEEE Computer , 45, 42–48.

Bartholdt, J., Oberhauser, R., and Rytina, A. (2008). An approach to addressing entity

model variability within software product lines. In Proceedings of the Third International

Conference on Software Engineering Advances (ICSEA), pages 465–471. IEEE Computer

Society.

Basili, V. R., Caldiera, G., and Rombach, H. D. (1994). The goal question metric

approach. In Encyclopedia of Software Engineering . Wiley.

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 International Workshop Dynamic Software Product

Lines (DSPL), pages 23–32.

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, 36–41.

Berg, K., Bishop, J., and Muthig, D. (2005). Tracing software product line variability:

From problem to solution space. In Proceedings of the 2005 Annual Research Conference

105

106 REFERENCES

of the South African Institute of Computer Scientists and Information Technologists on

IT Research in Developing Countries , SAICSIT ’05, pages 182–191, Republic of South

Africa. South African Institute for Computer Scientists and Information Technologists.

Bosch, J. and Capilla, R. (2012). Dynamic variability in software-intensive embedded

system families. IEEE Computer , 45(10), 28–35.

Buregio, V. A., de Lemos Meira, S. R., and de Almeida, E. S. (2010). Characterizing

dynamic software product lines - A preliminary mapping study. In Proceedings of the

14th International Conference in Software Product Lines (SPLC), pages 53–60.

Capilla, R., Bosch, J., Trinidad, P., Ruiz-Cortes, A., and Hinchey, M. (2014). An

overview of dynamic software product line architectures and techniques: Observations

from research and industry. Journal of Systems and Software, 91, 3–23.

Cetina, C., Trinidad, P., Pelechano, V., and Ruiz-Cortes, A. (2008). An architec-

tural discussion on dspl. In 2nd SPLC Workshop on Dynamic Software Product Line

(DSPL), pages 59–68. Irish Software Engineering Research Centre (Lero), Irish Software

Engineering Research Centre (Lero).

Cetina, C., Haugen, O., Zhang, X., Fleurey, F., and Pelechano, V. (2009a). Strategies for

variability transformation at run-time. In Proceedings of the 13th International Software

Product Line Conference, SPLC ’09, pages 61–70, Pittsburgh, PA, USA. Carnegie Mellon

University.

Cetina, C., Giner, P., Fons, J., and Pelechano, V. (2009b). Using feature models for

developing self-configuring smart homes. In Fifth International Conference on Autonomic

and Autonomous Systems, ICAS 2009, Valencia, Spain, 20-25 April 2009 , pages 179–188.

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 (SPLC), pages 331–345. Springer-

Verlag.

Chidamber, S. R. and Kemerer, C. F. (1994). A metrics suite for object oriented design.

IEEE Transaction Software Engineering , 20, 476–493.

Classen, A., Heymans, P., and Schobbens, P.-Y. (2008). What’s in a feature: A require-

ments engineering perspective. In Proceedings of the 11th International in Fundamental

REFERENCES 107

Approaches to Software Engineering Conference, (FASE), volume 4961 of Lecture Notes

in Computer Science, pages 16–30. Springer.

Clements, P. C. and Northrop, L. (2001). Software Product Lines: Practices and Patterns .

SEI Series in Software Engineering. Addison-Wesley.

Cook, D., Youngblood, M., Heierman, E.O., I., Gopalratnam, K., Rao, S., Litvin, A.,

and Khawaja, F. (2003). Mavhome: an agent-based smart home. In Proceedings of

the First IEEE International Conference on Pervasive Computing and Communications

(PerCom), pages 521–524.

Damiani, F. and Schaefer, I. (2011). Dynamic delta-oriented programming. In Proceedings

of the 15th International Software Product Line Conference (SPLC), page 34. ACM.

Damiani, F., Padovani, L., and Schaefer, I. (2012). A formal foundation for dynamic

delta-oriented software product lines. In ACM SIGPLAN Notices, volume 48, pages

1–10. ACM.

Dijkstra, E. W. (1972). Structured programming. chapter Chapter I: Notes on Structured

Programming, pages 1–82. Academic Press Ltd.

Dinkelaker, T., Mitschke, R., Fetzer, K., and Mezini, M. (2010). A dynamic software

product line approach using aspect models at runtime. In Proceedings of the 1st Workshop

on Composition and Variability . ACM.

Fenton, N. E. and Pfleeger, S. L. (1998). Software Metrics: A Rigorous and Practical

Approach. PWS Publishing Co., 2nd edition.

Ferreira, G. C. S., Gaia, F. N., Figueiredo, E., and de Almeida Maia, M. (2014). On the

use of feature-oriented programming for evolving software product lines - A comparative

study. Sci. Comput. Program., 93, 65–85.

Figueiredo, E., Cacho, N., Sant’Anna, C., Monteiro, M., Kulesza, U., Garcia, A., Soares,

S., Ferrari, F., Khan, S., Castor Filho, F., and Dantas, F. (2008). Evolving software

product lines with aspects: An empirical study on design stability. In Proceedings of the

30th International Conference on Software Engineering (ICSE), pages 261–270. ACM.

Figueiredo, E., Whittle, J., and Garcia, A. (2009). Concernmorph: Metrics-based

detection of crosscutting patterns. In Proceedings of the the 7th Joint Meeting of the

European Software Engineering Conference and the ACM SIGSOFT Symposium on The

Foundations of Software Engineering , pages 299–300. ACM.

108 REFERENCES

Filman, R., Elrad, T., Clarke, S., and Ak?it, M. (2004). Aspect-oriented Software

Development . Addison-Wesley Professional.

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), pages 109–117. ACM.

Gaia, F. N., Ferreira, G. C. S., Figueiredo, E., and de Almeida Maia, M. (2014). A

quantitative and qualitative assessment of aspectual feature modules for evolving software

product lines. Science of Computer Programming , 96, 230–253.

Galster, M. (2010). Enhancing runtime variability in software product lines through

service-orientation. In SPLC Workshops , pages 47–52. Lancaster University.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995). Design Patterns: Elements

of Reusable Object-oriented Software.

Gomaa, H. (2004). Modeling adaptive and evolvable software product lines using the

variation point model. In Proceedings of the 37th Annual Hawaii International Conference

on System Sciences , pages 1–10. Society Press, IEEE Computer Society.

Greenwood, P., Bartolomei, T. T., Figueiredo, E., Dsea, M., Garcia, A. F., Cacho,

N., Sant’Anna, C., Soares, S., Borba, P., Kulesza, U., and Rashid, A. (2007). On

the impact of aspectual decompositions on design stability: An empirical study. In

ECOOP–Object-Oriented Programming , pages 176–200. Springer.

Groher, I. and Voelter, M. (2007). Expressing feature-based variability in structural

models. In Workshop on Managing Variability for Software Product Lines, SPLC .

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), pages 45–. 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.

REFERENCES 109

Heider, W., Rabiser, R., and Grunbacher, P. (2012). Facilitating the evolution of

products in product line engineering by capturing and replaying configuration decisions.

International Journal on Software Tools for Technology Transfer , 14(5), 613–630.

Helleboogh, A., Weyns, D., Schmid, K., Holvoet, T., Schelfthout, K., and Van Betsbrugge,

W. (2009). Adding variants on-the-fly: Modeling meta-variability in dynamic software

product lines. In Proceedings of the 3rd International Workshop on Dynamic Software

Product Lines (DSPL) at the 13th International Software Product Line Conference

(SPLC), pages 18–27.

Horcas, J. M. (2013). Modeling of quality attributes using an aspect-oriented software-

product line approach. In Proceedings of European Conference on Software Architecture

(ECSA).

Istoan, P., Nain, G., Perrouin, G., and Jezequel, J.-M. (2009a). Dynamic software product

lines for service-based systems. In Proceedings of the 9th IEEE International Conference

on Computer and Information Technology (CIT), pages 193–198. 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 9th IEEE International

Conference on Computer and Information Technology (CIT), pages 193–198. IEEE

Computer Society.

Juristo, N. and Moreno, A. M. (2010). Basics of Software Engineering Experimentation.

Springer Publishing Company, Incorporated.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., and Peterson, A. S. (1990).

Feature-oriented domain analysis (foda) feasibility study.

Keepence, B. and Mannion, M. (2009). Using patterns to model variability in product

families. IEEE Software, 16, 102–108.

Kiczales, G. (1996). Aspect-oriented programming. ACM Comput. Surv., 28(4es).

Kitchenham, B., Pickard, L., and Pfleeger, S. L. (1995). Case studies for method and

tool evaluation. IEEE Software, 12, 52–62.

Kitchenham, B. A. and Pickard, L. M. (1998). Evaluating software engineering methods

and tools: Part 9: Quantitative case study methodology. SIGSOFT Software Engineering

Notes , 23, 24–26.

110 REFERENCES

Lammel, R. (1999). Declarative aspect-oriented programming. In PEPM , pages 131–146.

Citeseer.

Larman, C. (2002). Applying UML and Patterns: An Introduction to Object -Oriented

Analysis and Design and the Unified Process. Pretice Hall PTR, Upper Saddle River,

NJ, USA.

Lee, J. (2013). Dynamic feature deployment and composition for dynamic software

product lines. In Proceedings of the 17th International Software Product Line Conference

(SPLC), pages 114–116. ACM.

Lee, J. and Kang, K. C. (2006). A feature-oriented approach to developing dynami-

cally reconfigurable products in product line engineering. In Proceedings of the 10th

International Conference (SPLC), pages 131–140.

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 670–683.

Lee, J., Kotonya, G., and Robinson, D. (2012). Engineering service-based dynamic

software product lines. Computer , 45, 49–55.

Liang, S. and Bracha, G. (1998). Dynamic class loading in the java virtual machine. In

Proceedings of the 13th ACM SIGPLAN Conference on Object-oriented Programming,

Systems, Languages, and Applications (OOPSLA), pages 36–44. ACM.

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.

Lohmann, D., Spinczyk, O., and Schroder-Preikschat, W. (2006). Lean and efficient

system software product lines: Where aspects beat objects. pages 227–255.

M. Hinchey, P. S. and Schmid, K. (2012). Building dynamic software product lines.

IEEE Computer , 45, 22–26.

Martin, R. C. (1995). Oo design quality metrics : an analysis of dependencies. ROAD

1995 , 2(3).

Martin, R. C. (2000). More c++ gems. chapter The Open-closed Principle, pages 97–112.

Cambridge University Press, New York, NY, USA.

REFERENCES 111

McCabe, T. J. (1976). A complexity measure. IEEE Transaction Software Engineering ,

2, 308–320.

McGregor, J. (2003). The evolution of product line assets. Technical report, Software

Engineering Institute, Carnegie Mellon University.

McKinley, P. K., Sadjadi, S. M., Kasten, E. P., and Cheng, B. H. C. (2004). Composing

adaptive software. Computer , 37(7), 56–64.

Montero, I., Pena, J., and Ruiz-Cortes, A. (2008). Representing runtime variability

in business-driven development systems. In Proceedings of the Seventh International

Conference on Composition-Based Software Systems (ICCBSS 2008), ICCBSS ’08, pages

241–, Washington, DC, USA. IEEE Computer Society.

Morin, B., Barais¡/a¿, O., and Jézéquel, J.-M. (2008). K@rt: An aspect-

oriented and model-oriented framework for dynamic software product lines. In Proceedings

of the 3rd International Workshop on Models@Runtime, at MoDELS .

Muschevici, R., Clarke, D., and Proenca, J. (2013). Executable modelling of dynamic

software product lines in the abs language. In 5th International Workshop on Feature-

Oriented Software Development, (FOSD), pages 17–24.

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), pages 313–329.

Springer-Verlag.

Northrop, L. M. (2002). Sei’s software product line tenets. IEEE , 19(4), 32–40.

Parnas, D. L. (1976). On the design and development of program families.

Pena, J., Hinchey, M. G., Resinas, M., Sterritt, R., and Rash, J. L. (2007). Designing

and managing evolving systems using a MAS product line approach. Science Computer

Programe, 66, 71–86.

Pohl, K., Bockle, G., and Linden, F. J. v. d. (2005). Software product line engineering:

Foundations, principles and techniques.

Quinton, C., Rabiser, R., Vierhauser, M., Grnbacher, P., and Baresi, L. (2015). Evolution

in dynamic software product lines: Challenges and perspectives. In Proceedings 19th

International Software Product Line Conference (SPL), pages 126–130. ACM.

112 REFERENCES

Runeson, P. and Host, M. (2009). Guidelines for conducting and reporting case study

research in software engineering. Empirical Software Engineering., 14, 131–164.

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 21–30.

Sant’anna, C., Garcia, A.and Chavez, C., Lucena, C., and v. von Staa, A. (2003). On

the reuse and maintenance of aspect-oriented software: An assessment framework.

Schaefer, I., Bettini, L., Damiani, F., and Tanzarella, N. (2010). Delta-oriented program-

ming of software product lines. In Proceedings of the 14th International Conference on

Software Product Lines (SPLC), pages 77–91.

Schmid, K. and Eichelberger, H. (2008). From static to dynamic software product lines.

In Software Product Lines, 12th International Conference, SPLC 2008, Limerick, Ireland,

September 8-12, 2008, Proceedings. Second Volume (Workshops), pages 33–38.

Seidl, C., Heidenreich, F., and Aßmann, U. (2012). Co-evolution of models and feature

mapping in software product lines. In Proceedings of the 16th International Software

Product Line Conference-Volume 1 , pages 76–85. ACM.

Sharp, D. C. (2000). Containing and facilitating change via object oriented tailoring

techniques. In Proceedings of the 1st Software Product Line Conference (SPLC).

Shen, L., Peng, X., Liu, J., and Zhao, W. (2011). Towards feature-oriented variability

reconfiguration in dynamic software product lines. In Top Productivity through Software

Reuse, pages 52–68. Springer.

Silva, J. R. F., Pereira da Silva, F. A., do Nascimento, L. M., Martins, D., Garcia, V. C.,

et al. (2013). The dynamic aspects of product derivation in dspl: A systematic literature

review. In Information Reuse and Integration (IRI), 2013 IEEE 14th International

Conference on, pages 466–473. IEEE.

Svahnberg, M. and Bosch, J. (2000). Evolution in software product lines. In Proceedings,

3rd International Workshop on Software Architectures for Products Families (IWSAPF-3),

pages 391–422. Springer LNCS.

Svahnberg, M., van Gurp, J., and Bosch, J. (2005). A taxonomy of variability realization

techniques: Research articles. Software: Practice and Experience, 35, 705–754.

REFERENCES 113

Talib, M. A., Nguyen, T., Colman, A. W., and Han, J. (2010). Requirements for evolv-

able dynamic software product lines. In Software Product Lines - 14th International

Conference, SPLC 2010, Jeju Island, South Korea, September 13-17, 2010. Workshop Pro-

ceedings (Volume 2 : Workshops, Industrial Track, Doctoral Symposium, Demonstrations

and Tools), pages 43–46.

Tarr, P., Ossher, H., Harrison, W., and Sutton, Jr., S. M. (1999). N degrees of separation:

Multi-dimensional separation of concerns. In Proceedings of the 21st International

Conference on Software Engineering (ICSE), pages 107–119. ACM.

Tom Dinkelaker, Ralf Mitschke, K. F. and Mezini, M. (2010). A dynamic software product

line approach using aspect models at runtime. In Proceedings of the 1st Workshop on

Composition and Variability 10 Rennes, France colocated with AOSD .

Tsang, S. L., Clarke, S., and Baniassad, E. L. A. (2004). An evaluation of aspect-oriented

programming for java-based real-time systems development. In Proceedings of the 7th

International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC),

pages 291–300.

Voelter, M. and Groher, I. (2007). Product line implementation using aspect-oriented and

model-driven software development. In Proceedings of the 11th International Software

Product Line Conference (SPLC), pages 233–242. IEEE Computer Society.

Wand, M., Kiczales, G., and Dutchyn, C. (2004). A semantics for advice and dynamic join

points in aspect-oriented programming. ACM Transactions on Programming Languages

and Systems (TOPLAS), 26, 890–910.

Wohlin, C., Runeson, P., Host, M., Ohlsson, M. C., Regnell, B., and Wesslen, A. (2000).

Experimentation in Software Engineering: An Introduction. Kluwer Academic Publishers.

Wolfinger, R., Reiter, S., Dhungana, D., Grunbacher, P., and Prahofer, H. (2008).

Supporting runtime system adaptation through product line engineering and plug-in

techniques. In Composition-Based Software Systems, 2008. ICCBSS 2008. Seventh

International Conference on, pages 21–30. IEEE.

Yang, C., Yuan, B., Tian, Y., Feng, Z., and Mao, W. (2015). A smart home architecture

based on resource name service. In Proceedings of the 17th IEEE International Conference

on Computational Science and Engineering (CSE), pages 1915–1920.

114 REFERENCES

Yau, S. S. and Collofello, J. S. (1985). Design stability measures for software maintenance.

IEEE Transaction Software Engineering , 11, 849–856.

Appendix

AUnless you try to do something beyond what you have already mastered, you will never grow. — Ronald

E. Osborn

DYNAMIC SOFTWARE PRODUCT LINES IN

PRACTICE

A.1 FEATURE SPECIFICATION

This section describes the SmartHomeRiSE features, its priorities and relationship with

other features.

[F01] SecurityControlPriority: High Variability: MandatoryRequires: — Excluded: —Binding Mode: Dynamic Father Feature: —

Child Feature:F02, F03,F04, F05

Type: Abstract

DescriptionSecurityControl managesthe security system

[F02] AlarmPriority: Low Variability: OptionalRequires: F04 Excluded: —Binding Mode: Dynamic Father Feature: F01Child Feature: — Type: Concrete

DescriptionAlarm turn onthe buzzer by automated control

115

116 DYNAMIC SOFTWARE PRODUCT LINES IN PRACTICE

[F03] LockDoorsPriority: Medium Variability: OptionalRequires: — Excluded: —Binding Mode: Dynamic Father Feature: F01Child Feature: — Type: Concrete

DescriptionLockDoors open/closethe doors by user control

[F04] PanicModePriority: Low Variability: OptionalRequires: F07 Excluded: —Binding Mode: Dynamic Father Feature: F01Child Feature: — Type: Concrete

DescriptionPanicMode flashthe lights by automated control

[F05] PresenceIlusionPriority: High Variability: MandatoryRequires: F07 Excluded: —Binding Mode: Dynamic Father Feature: F01Child Feature: — Type: Concrete

DescriptionPresenceIlusion feature turnsthe light on/off alternately by automated control

[F06] IlluminationControlPriority: High Variability: MandatoryRequires: — Excluded: —Binding Mode: Dynamic Father Feature: —Child Feature: F07, F08 Type: Abstract

DescriptionIlluminationControl managesthe illumination system

[F07] UserIlluminationPriority: High Variability: MandatoryRequires: — Excluded: —Binding Mode: Dynamic Father Feature: F06Child Feature: — Type: Concrete

DescriptionUserIllumination turn onthe the lights by user control

A.1 FEATURE SPECIFICATION 117

[F08] AutomatedIlluminationPriority: Medium Variability: OptionalRequires: F07 Excluded: —Binding Mode: Dynamic Father Feature: F06Child Feature: F09, F10 Type: Abstract

DescriptionAutomatedIllumination managesthe autonomic illumination control system

[F09] ByPresencePriority: Medium Variability: ORRequires: F07 Excluded: —Binding Mode: Dynamic Father Feature: F08Child Feature: — Type: Concrete

DescriptionByPresence turn onthe lights by automated control

[F10] ByLuminosityPriority: Medium Variability: ORRequires: F09 Excluded:Binding Mode: Dynamic Father Feature: F08Child Feature: — Type: Concrete

DescriptionByLuminosity turn onthe lights by automated control

[F11] TemperatureControlPriority: Medium Variability: OptionalRequires: — Excluded: —Binding Mode: Dynamic Father Feature: —Child Feature: F12, F15 Type: Abstract

DescriptionTemperatureControl managesthe temperature system

[F12] UserControlPriority: Medium Variability: MandatoryRequires: — Excluded: —Binding Mode: Dynamic Father Feature: F11Child Feature: F13, F14 Type: Abstract

DescriptionUserControl managesthe temperature control system from user

118 DYNAMIC SOFTWARE PRODUCT LINES IN PRACTICE

[F13] FromWindowPriority: Medium Variability: AlternativeRequires: — Excluded: —Binding Mode: Dynamic Father Feature: F12Child Feature: — Type: Concrete

DescriptionFromWindow (UserControl) openthe windows by user control

[F14] FromAirPriority: Low Variability: AlternativeRequires: F13 Excluded: —Binding Mode: Dynamic Father Feature: F12Child Feature: — Type: Concrete

DescriptionFromAir (UserControl) turn onthe air conditionair by user command

[F15] AutomatedControlPriority: Medium Variability: OptionalRequires: F12 Excluded: —Binding Mode: Dynamic Father Feature: F11Child Feature: F16, f17 Type: Abstract

DescriptionAutomatedControl managesthe autonomic temperature control system

[F16] FromWindowPriority: Medium Variability: ORRequires: — Excluded: —Binding Mode: Dynamic Father Feature: F15Child Feature: — Type: Concrete

DescriptionFromWindow (AutomatedControl)open the windows by automated control

[F17] FromAirPriority: Low Variability: ORRequires: F16 Excluded: —Binding Mode: Dynamic Father Feature: F15Child Feature: — Type: Concrete

DescriptionFromAir (AutomatedControl) turn onthe air conditionair by automated control

UNIVERSIDADE FEDERAL DA BAHIA DISSERTAÇAO DE …§ão... · de execu¸caõ por meio da gestaõ...

Documents

Transcript of UNIVERSIDADE FEDERAL DA BAHIA DISSERTAÇAO DE …§ão... · de execu¸caõ por meio da gestaõ...