CONTEXTUAL GOAL MODELS FOR DYNAMIC SOFTWARE PRODUCT LINES

(1)

Universidade Federal de Pernambuco Centro de Informática

Post-graduation in Computer Science

CONTEXTUAL GOAL MODELS FOR DYNAMIC SOFTWARE PRODUCT

LINES

Gabriela Guedes de Souza

Ph.D. Thesis

Recife-PE 2017

(2)

Gabriela Guedes de Souza

CONTEXTUAL GOAL MODELS FOR DYNAMIC SOFTWARE PRODUCT

LINES

Ph.D. Thesis presented to the Post-Graduation Program in Computer Science of the Informatics Centre of the Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Philosophy Doctor in Computer Science.

Advisor: Ph.D. Carla Taciana Lima Lourenço Silva Schuenemann

Recife-PE 2017

(3)

Acknowledgments

I would like to thank God for giving me the strength to carry on with this work. A special thanks to my parents, Amauri and Deuzeni, for their love and support. Thanks to my sister and all my family for being there for me.

I would also like to thank all my friends from LER and from IFPB - Cajazeiras for those moments we spent together, helping one another.

Thanks to the professors and the staff at CIn-UFPE who, in their own way, have con-tributed to my education.

Finally, I would like to thank my advisor Carla Silva for her guidance and support and for not giving up on me.

(4)

Resumo

[Contexto] Linhas de Produto de Software Dinâmicas (LPSDs) são LPSs em que a

configu-ração ocorre em tempo de execução. Abordagens para LPSD proveem meios para modelar variabilidade, além de um processo de configuração para amarrar a variabilidade de acordo com mudanças no contexto e/ou requisitos não-funcionais (RNFs) em tempo de execução. Contudo, levar em conta contextos e RNFs pode resultar em múltiplas configurações possí-veis, às vezes conflitantes. A maioria das abordagens para DSPL não possuem uma maneira de priorizar essas possíveis configurações para poder selecionar uma delas, e aquelas que pos-suem não levam em conta a prioridade dos RNFs para o contexto atual. [Objetivo] Neste tra-balho, propõe-se uma abordagem de Engenharia de Requisitos (ER) para LPSDs, chamada ConG4DaS (do inglês, Contextual Goal models For Dynamic Software product lines), que provê: (i) modelos para capturar variabilidade usando objetivos, RNFs, contextos e seus rel a-cionamentos; e (ii) um processo de configuração que leva em conta contextos, RNFs e suas prioridades e interações. [Método] Foi feita uma avaliação baseada em simulações para com-parar ConG4DaS com outra abordagem, com respeito ao nível de satisfação do softgoal prio-ritário. Foram simulados vários contextos diferentes de dois exemplos de LPSD e comparou-se as configurações geradas pelas duas abordagens. Também foi realizada uma pesquisa, usando questionário online, com pesquisadores de ER e LPSD para avaliar a utilidade perce-bida de ConG4DaS. [Resultados] Na avaliação baseada em simulações, o número de contri-buições positivas para o softgoal prioritário e a diferença entre o número de contricontri-buições positivas e negativas para o mesmo softgoal eram maiores nas configurações escolhidas por ConG4DaS do que nas configurações aleatoriamente selecionadas da outra abordagem. Con-tudo, quando comparam-se as configurações de ConG4DaS com as da outra abordagem que foram selecionadas manualmente, não há diferença significativa entre elas. No questionário, os dois grupos de pesquisadores (tanto de ER, como de LPSD) perceberam ConG4DaS como útil para modelagem e configuração da variabilidade de LPSD. Entretanto, no grupo de ER houve mais respostas positivas do que no grupo de LPSD.

Palavras-chave: Engenharia de Requisitos, Linhas de Produto de Software Dinâmicas,

(5)

Abstract

[Context] Dynamic Software Product Lines (DSPLs) are SPLs in which configuration occurs

at runtime. DSPL approaches provide means for modelling variability as well as a configura-tion process for binding variability according to runtime changes in the context and/or non-functional requirements (NFRs). However, taking contexts and NFRs into account may result in multiple and, sometimes, conflicting possible configurations. Most of DSPL approaches do not provide means for prioritizing possible configurations in order to select one of them, and those that provide, do not take into account the NFRs’ priority for the current context.

[Objec-tive] In this work, we propose a Requirements Engineering (RE) approach for DSPL,

ConG4DaS (Contextual Goal models For Dynamic Software product lines), which provides: (i) models for capturing variability with goals, NFRs, contexts and the relationship between them; and (ii) a configuration process that takes contexts, NFRs and their priority and interac-tions into account. [Method] We have used simulation based assessment to compare ConG4DaS with another approach with respect to the satisfaction level of the highest priority softgoal. We simulated several different contexts of two DSPL examples and compared the configurations generated by both approaches. We also performed a survey, using an online questionnaire, with RE and DSPL researchers to evaluate ConG4DaS perceived usefulness.

[Results] In the simulation based assessment, in the configurations selected by ConG4DaS

the number of positive contributions and the difference between the numbers of positive and negative contributions to the highest priority softgoal are greater than in the randomly selected configurations of the other approach. However, when comparing ConG4DaS configurations to the manually selected configurations of the other approach, there is no significant differ-ence between them. In the survey, both groups of researchers (RE and DSPL) perceived ConG4DaS as useful for modelling and configuring DSPL variability. But the RE group gave more positive answers than the DSPL group.

Key-words: Requirements Engineering, Dynamic Software Product Lines, Goal Models,

(6)

List of Figures

Figure 1 - Example of SD model ... 29

Figure 2 - example of SR model ... 30

Figure 3 - Example of i*-orthogonal model ... 31

Figure 4 - GSC2SPL process... 33

Figure 5 - GCL-Tool module structure... 35

Figure 6 - Study selection process ... 41

Figure 7 - Papers published per year ... 44

Figure 8 - Number of papers per variability model used ... 47

Figure 9 - DE process of ConG4DaS ... 61

Figure 10 - Mobile Game’s intentional i*-orthogonal model ... 63

Figure 11 - Context Model for Mobile Game... 64

Figure 12 - Contextual i*-orthogonal model of Mobile Game ... 66

Figure 13 - i*-orthogonal model of Mobile Game... 69

Figure 14 - Create Optional Artefacts sub-process ... 70

Figure 15 - AE process of ConG4DaS... 72

Figure 16 - Partial view of Mobile Game i*-orthogonal model ... 76

Figure 17 - Partial view of the selected configuration ... 79

Figure 18 – Feature configuration of Mobile Game ... 80

Figure 19 - REFAS variability view of Mobile Game... 94

Figure 20 - Softgoals satisficing view of Mobile Game... 95

Figure 21 - Context model of Smart Home... 97

Figure 22 - i*-orthogonal model of Smart Home ... 97

Figure 23 - REFAS variability view of Smart Home... 99

Figure 24 - Softgoals satisficing view of Smart Home... 100

Figure 25 - REFAS configuration for scenario 9 of Mobile Game... 112

Figure 26 - ConG4DaS configuration for scenario 9 of Mobile Game... 113

Figure 27 - REFAS configuration for scenario 1 of Mobile Game... 114

Figure 29 - REFAS configuration for scenario 23 of Smart Home ... 116

Figure 30 – Answers to affirmative 8... 122

Figure 31 - Answers to affirmative 9 ... 122

Figure 40 - Answers to question 19 ... 125

Figure 44 - RE group answers to question 2 ... 128

Figure 45 – DSPL group answers to question 2 ... 128

(7)

Figure 49 - DSPL group answers to question 5 ... 130

Figure 52 - RE group answers to affirmative 8... 131

Figure 53 - DSPL group answers to affirmative 8 ... 131

Figure 55 - DSPL group answers to affirmative 9 ... 131

Figure 57 - DSPL group answers to affirmative 10... 132

Figure 60 – RE group answers to affirmative 12 ... 133

Figure 70 - RE group answers to question 18... 137

Figure 72 - Metamodel of the Context Model ... 160

Figure 73 - Metamodel of the i*-orthogonal language ... 161

Figure 74 - Feature Model of Mobile Game ... 165

Figure 75 - Reorganized FM of Mobile Game ... 167

Figure 76 - Context view of Mobile Game ... 177

Figure 77 – Softgoals view of Mobile Game ... 177

Figure 78 - Assets view of Mobile Game ... 177

Figure 79 - Context view of Smart Home ... 178

Figure 80 – Softgoals view of Smart Home ... 178

Figure 81 - Assets view of Smart Home ... 178

Figure 90 - REFAS – random configuration for scenario 1 of Mobile Game ... 183

Figure 98 - REFAS – manual configuration for scenario 1 of Mobile Game ... 185

(8)

Figure 106 - ConG4DaS configuration for scenario 1 of Smart Home ... 187

Figure 138 - REFAS – random configuration for scenario 1 of Smart Home ... 193

Figure 145 - REFAS– random configuration for scenario 8 of Smart Home ... 195

(9)

Figure 168 – REFAS – random configuration for scenario 31 of Smart Home ... 203

Figure 169 – REFAS – random configuration for scenario 32 of Smart Home ... 203

Figure 170 - REFAS – manual configuration for scenario 1 of Smart Home... 204

Figure 177 - REFAS– manual configuration for scenario 8 of Smart Home ... 206

(10)

List of Tables

Table 1 – List of Studies Included on the Systematic Mapping and their general information ... 45

Table 2 – Distribution of studies by type of variability model ... 48

Table 3 – Distribution of studies by information used for selecting variant ... 50

Table 4 – Distribution of studies by strategy used for solving conflicts in configuration selection ... 51

Table 5 – Variability model and configuration strategy of new studies ... 56

Table 6 – Priority4Context table for Mobile Game ... 67

Table 7 - Weight of all types of contribution link... 78

Table 8 – Summary of related work comparison ... 87

Table 9 – Priority4Context table for Smart Home ... 96

Table 10 -Truth table of Mobile Game ... 102

Table 11 -Truth table of Smart Home ... 103

Table 12 –Results of Mobile Game ... 106

Table 13 - Results of Smart Home... 108

Table 14 - Participants' comments on affirmative 13 ... 123

Table 15 - Participants' comments on affirmative 14 ... 124

Table 16 - Participants' comments on question 24 ... 126

Table 17 – Comments from DSPL group on question 12 ... 133

Table 18 – Comments from RE group on affirmative 13 ... 134

Table 19 – Comments from DSPL group on affirmative 13 ... 134

Table 20 – Answers from RE group to question 14 ... 134

Table 21 – Answers from DSPL group to question 14... 134

Table 22 – Answers from DSPL group to question 17... 136

Table 23 – Answers from RE group to question 19 ... 137

Table 24 - Answers in RE group for Phase 2 ... 137

Table 25 - Answers in DSPL group for Phase 2 ... 138

Table 26 - Answers in RE group for Phase 3 ... 139

Table 27 - Answers DSPL group for Phase 3... 139

Table 28 - Publications related to this thesis ... 145

Table 29 - Template of Goal2Feature table ... 163

Table 30 - Goal2Feature table for Mobile Game ... 166

Table 31 - Updated Goal2Feature table for Mobile Game ... 167

Table 32 - Template for describing use case scenarios ... 170

Table 33 - Description of Play Game use case ... 174

Table 34 - Pilot study questionnaire ... 216

Table 35 – Answers to Phase 1 of pilot study... 220

Table 37 – Answers to Phase 3 and 4 of pilot study ... 220

Table 38 - Survey questionnaire... 221

(11)

List of Listings

Listing 1 - AE-Step 1 in pseudo-code ... 73

Listing 5 – Values of context variables for Mobile Game ... 180

(12)

List of Acronyms

A Agree

AE Application Engineering

AOM Aspect-Oriented Modelling

BPMN Business Process Model and Notation

ConG4DaS Contextual Goal models For Dynamic Software product lines

COP Constraint Optimization Problem

CSP Constraint Satisfaction Problem

CVL Common Variability Language

D Disagree

DE Domain Engineering

DiVA Dynamic Variability in complex, adaptive systems

DL Digital Library

DSL Domain Specific Language

DSML Domain Specific Modelling Language

DSPL Dynamic Software Product Line

E-SPL Early Software Product Line

ECA Event-Condition-Action

EE Energy Efficiency

EMF Eclipse Modelling Framework

ERU Efficiency in Resource Usage

FM Feature Model

FUSION FeatUre-oriented SelfadaptatION

G2SPL Goal to Software Product Line

GCL-Tool Goal and Context for product Line – Tool

GORE Goal Oriented Requirements Engineering

GS2SPL Goals and Scenarios to Software Product Line

GPS Global Positioning System

GSC2SPL Goals, Scenarios and Contexts to Software Product Line

HQI High Quality Interaction

HyVarRec Hybrid Variability Reconfiguration engine

(13)

LER In Portuguese, Laboratório de Engenharia de Requisitos – Require-ments Engineering Lab

MAPE Monitor, Analyse, Plan, and Execute

MDD Model-Driven Development

NFR Non-Functional Requirement

OVM Orthogonal Variability Model

PLUSS Product Line Use case modeling for Systems and Software engineering

PRiM Process Reengineering i* Method

QoS Quality of Service

RE Requirements Engineering

REFAS Requirements Engineering For self-Adaptive Software systems

SA Strongly Agree

SAS Self-Adaptive System

SAT boolean Satisfiability

SD Strategic Dependency model

SDA Strongly Disagree

SF Safety

siCPS software intensive Cyber-Physical System

SM Save Money

SPL Software Product Line

SPLE Software Product Line Engineering

SR Strategic Rationale model

StArt State of the Art through Systematic Reviews

TAM Technology Acceptance Model

U Undecided

UML Unified Modeling Language

VF Validity Formulas

(14)

2.4 i*-orthogonal ... 28 2.5 GSC2SPL Process ... 32 2.5.1 GSC2SPL - Domain Engineering ... 32 2.5.2 GSC2SPL – Application Engineering... 34 2.6 Summary ... 35 3 Systematic Mapping ... 37 3.1 Introduction ... 38 3.2 Research Protocol... 39 3.2.1 Research Questions ... 39 3.2.2 Search Process ... 39

3.2.3 Inclusion and Exclusion Criteria ... 42

3.2.4 Quality Assessment ... 42

3.2.5 Data Extraction ... 43

3.2.6 Data Synthesis ... 43

3.3 Results and Discussion... 43

3.3.1 Overview of the Studies ... 44

3.3.2 RQ1 – Variability Modelling... 46

3.3.3 RQ2 – Variability Configuration... 49

3.4 Threats to Validity ... 52

3.5 Other studies ... 53

3.6 Summary ... 56

4 ConG4DaS – Contextual Goal models For Dynamic Software product lines ... 58

4.1 Overview ... 59

(15)

4.2.1 Specify Requirements in Goal Model ... 62

4.2.2 Specify Context Model ... 63

4.2.3 Represent Variability ... 67

4.2.4 Create Optional Artefacts ... 69

4.3 Application Engineering ... 71 4.3.1 Contextual Configuration ... 72 4.3.2 Variant Prioritization... 76 4.3.3 Feature Configuration ... 80 4.4 Summary ... 81 5 Comparative Study ... 82 5.1 Introduction ... 83 5.2 Related Work ... 83

5.3 Comparing Modelling Characteristics ... 86

5.4 Simulation Based Assessment ... 88

5.4.1 Assessment Design... 90

5.4.2 Results and Analysis ... 105

5.4.3 Discussion ... 110 5.4.4 Threats to Validity... 116 5.5 Summary ...118 6 Survey Evaluation... 119 6.1 Introduction ...120 6.2 Pilot Study ...120 6.2.1 Participants’ Experience ... 121

6.2.2 ConG4DaS Domain Engineering Evaluation ... 122

6.2.3 ConG4DaS Application Engineering Evaluation... 124

6.2.4 Overall Evaluation of ConG4DaS ... 125

6.2.5 Lessons Learnt ... 126

6.3 Survey Results ...127

6.3.1 Participants’ Experience ... 128

6.3.2 ConG4DaS Domain Engineering Evaluation ... 130

6.3.3 ConG4DaS Application Engineering Evaluation... 134

6.4 Discussion ...137 6.5 Summary ...140 7 Conclusion ... 141 7.1 Considerations...142 7.2 Contributions ...144 7.2.1 Publications... 144 7.3 Limitations ...145 7.4 Future Work ...146 References ... 148

(16)

A Metamodels ... 159

A.1 Metamodel of the Context Model ...160

A.2 Metamodel of the i*-orthogonal language...160

B Create Optional Artefacts ... 162

B.1 Create Feature Model...163

B.2 Reorganize Feature Model ...165

B.3 Create Use Case Scenarios...168

B.4 Improve Use Case Scenarios ...175

C REFAS Models ... 176

C.1 Mobile Game ...177

C.2 Smart Home ...177

D Simulation Based Assessment Artefacts ... 179

D.1 Context Values ...180

D.2 ConG4DaS Configurations for Mobile Game ...181

D.3 REFAS – Random Configurations for Mobile Game ...183

D.4 REFAS – Manual Configurations for Mobile Game ...185

D.5 ConG4DaS Configurations for Smart Home ...187

D.6 REFAS – Random Configurations for Smart Home ...192

D.7 REFAS – Manual Configurations for Smart Home ...204

E Survey Evaluation Artefacts ... 215

E.1 Pilot Study Questionnaire...216

E.2 Pilot Study Answers ...219

E.3 Survey Questionnaire ...221

(17)

1

Introduction

In this chapter, we present the context, the motivation, goals and research questions of this thesis. Then, we discuss the methodology used for its reali-zation and present the outline of the document.

(18)

1.1 Context

Advances in technologies, platforms and devices have increased the demand for per-vasive, mobile and autonomic software. Users require software systems that are capable of continuously offer their services even in changing conditions. According to Hinchey, Park and Schmid (2012), the need to cope with these challenges has led to the development of many different approaches for adapting to changing needs, including self-adapting, agent-based, autonomous, emergent, and bio-inspired systems.

As a result of the interest in systems that are capable of adapting themselves, research-ers have investigated the use of Dynamic Software Product Lines (DSPL) (HALLSTEINSEN

et al., 2008), which propose the use of Software Product Line (SPL) techniques for

develop-ing adaptive systems. Given the success of SPLs, DSPLs offer a promisdevelop-ing strategy to deal with the design and implementation of software changes that need to be handled at runtime (BENCOMO, HALLSTEINSEN and DE ALMEIDA, 2012).

SPL approaches are capable of modelling variability in terms of variation points (what may vary in the software) and variants (possible variations for the variation point), and, when a new product is required, they provide means for configuring variability (bind variation points to a variant). Dynamic Software Product Lines extend these SPL’s capabilities to runtime. Dynamic variability management, as provided by DSPLs, has multiple application areas, such as Software as a Service (SaaS), self-* systems, pervasive systems and context-aware mobile systems (BÜRDEK et al., 2014). In summary, DSPLs may be applied to the development of systems capable of adapting themselves to runtime changes in the execution environment or user requirements.

According to Capilla et al. (2014), a DSPL should possess the following properties:  Runtime variability support and management: a DSPL should allow the analysis and

reconfiguration of the system’s variability at runtime;

 Multiple and dynamic binding: when the system adapts its properties to a new context, features can be bound several times and at different binding times;

 Context-awareness and self-adaptation for autonomic behaviour: DSPLs should handle context information that is used to dynamically select new system options depending on the environment conditions.

Taking all this in consideration, a Requirements Engineering (RE) approach for DSPLs should provide models for capturing variability and also a way for configuring this variability taking into account the conditions that trigger and drive the adaptation. Those

(19)

con-ditions may be related to the external environment where the DSPL operates, i.e. the context, or to the non-functional requirements (NFRs) it should satisfy, which may be operationalized as internal system properties or quality constraints or the quality of service (QoS) it provides.

1.2 Motivation

In general, DSPL approaches use context information or the satisfaction level of non-functional requirements for deciding when the DSPL should be reconfigured and for choosing a configuration for the situation (BENCOMO, HALLSTEINSEN and DE ALMEIDA, 2012) (CAPILLA et al., 2014) (HINCHEY, PARK and SCHMID, 2012).

However, contexts and NFRs may influence each other. It is possible that, for a given context, the NFRs’ priority or their required satisfaction level may change (SAWYER et al., 2012). For example, a mobile application may perform online backup of the user’s data in order to satisfy the data availability NFR. But, if the device is using mobile connection and the user’s data plan is ending, the reduce data plan usage NFR may have higher priority than

data availability in that case. According to the results of the systematic mapping we

per-formed (GUEDES et al., 2015), which is presented in Chapter 3, most approaches do not model the interactions between contexts and NFRs, therefore, they do not take them into ac-count when configuring the DSPL.

Additionally, during the configuration process, conflicts must be solved when there are multiple possible configurations for the current situation. This may occur when different contexts or NFRs are valid at the same time, and one requires an adaptation conflicting with the adaptation required by another.

An example of this situation is when a home automation system has the goal of reduc-ing energy consumption and it detects that the temperature inside the house is high. In this case, the system should open the windows to let in some breeze, instead of turning on the air conditioner, which would consume more energy. If at the same time the system detected it is raining outside, it should close the windows to prevent water damage to the furniture. Howev-er, these two configurations (windows open and windows closed) cannot happen at the same time, so the system should decide which one should be prioritized in order to choose only one of them.

Thus, in the configuration process there should be a way to prioritize variants. One possible solution is to prioritize variants according to stakeholders’ goals. Additionally, since

(20)

the NFRs’ priority may change according to the context, prioritizing variants with respect to how they satisfy the NFRs for current context should also be considered.

With respect to choosing one configuration among multiple, sometimes conflicting, configurations, we found, through a systematic mapping (GUEDES et al., 2015), that most approaches do not deal with this issue. Among the studies that address this issue, 15 of 54 selected studies, only one of them (GREENWOOD et al., 2011) takes the NFRs’ priority for the current context, and in another one (SAWYER et al., 2012) the required satisfaction level for the current context is taken into account. But in none of them the set of goals or softgoals (which may be used to model NFRs) changes according to context.

In summary, there is a lack of DSPL approaches that address these issues (interactions between contexts and NFRs, conflict solving in the configuration process, taking NFRs priori-ty into account). Thus, we intend to deal with these issues in this work.

1.3 Research Goals

Considering the motivation presented in the previous section, we decided to propose a DSPL approach that is capable of configuring its requirements variability considering con-texts, NFRs’ priority and stakeholders’ goals. Therefore, the objective of this thesis is to

pro-vide a process for configuring DSPL’s requirements variability based on context information, NFRs’ priority, stakeholders’ goals, and the relationships among them.

Based on this goal, the following research question was proposed:

Do the configurations generated by a process that takes into account stakeholders’ goals, contexts and NFRs’ priority provide higher satisfaction level to the top priority NFR than those generated by an approach that does not consider these elements?

In order to answer the research question, the research goal was decomposed in the fol-lowing specific goals:

1 Investigate how current approaches model requirements variability in DSPL; 2 Investigate how current approaches configure requirements variability in DSPL;

3 Propose an approach for modelling requirements variability in DSPL that integrates goals, contexts and NFRs;

4 Propose a configuration process that uses goals, contexts, NFRs and their interactions for adapting the DSPL;

(21)

6 Evaluate the proposed approach in regard to its perceived usefulness.

1.4 Methodology

This research started with a study of the main concepts from the areas it is related to, namely Requirements Engineering and Dynamic Software Product Lines. The studied con-cepts are presented in Chapter 2.

Then, to fulfil the first two specific goals of our research, we did an exploratory study of the current literature, executing a systematic mapping. According to Kitchenham and Char-ters (2007), Systematic Mapping Studies (also known as Scoping Studies) are designed to provide a wide overview of a research area, since they allow the evidence in a domain to be plotted at a high level of granularity.

Systematic mappings are used to direct the focus of future systematic reviews and to identify areas where more primary studies should be conducted. Thus, they are also useful to PhD students who are required to prepare an overview of the topic area in which they will be working (KITCHENHAM and CHARTERS, 2007). Therefore, we conducted a systematic mapping for providing an overview about variability management in DSPLs and identifying how we could contribute to this area. Chapter 3 presents the results of the systematic map-ping.

The next step was to propose an approach for modelling the requirements variability of DSPLs. We looked for a modelling language that combined goals, contexts and NFRs. i*-orthogonal (LIMA, 2011) provides goal models with context annotations and is capable of modelling NFRs as softgoals, but it does provide means for relating contexts and softgoals priority. Therefore, we proposed a table for capturing this information, which is called Priori-ty4Context and describes the priority of all softgoals for each context. Thus, combining i*-orthogonal and the Priority4Context table, we fulfilled the third specific research goal by pro-posing ConG4DaS (Contextual Goal models For Dynamic Software product lines) Domain Engineering process, which is presented in Chapter 4.

For achieving the fourth specific research goal, we proposed ConG4DaS Application Engineering process, which is also presented in Chapter 4. This process defines steps for con-figuring i*-orthogonal models based on the current context and for ranking possible variants for achieving stakeholders’ goals based on how they contribute to the softgoals’ satisfaction, also considering softgoals’ priority.

(22)

In order to evaluate our approach (fifth and sixth specific research goals), we had to select a research method. For Easterbrook et al. (2008), one of the first steps in choosing an appropriate research method is to choose a philosophical stance. In fact, the stance you adopt affects which methods you believe that lead to acceptable evidence in response to your re-search question(s) (EASTERBROOK et al., 2008).

We have decided to take a positivist point of view in this research. This means we believe that reality can be broken into simpler components and knowledge can be built by studying these components. More precisely, our point of view is positivist, since post-positivists “tend to accept the idea that it is more productive to refute theories than to prove them, and we increase our confidence in a theory each time we fail to refute it, without neces-sarily ever proving it to be true” (EASTERBROOK et al., 2008).

Thus, quantitative research suits better our philosophical stance. For evaluating ConG4DaS with respect to the satisfaction of the highest priority softgoals (fifth specific re-search goal), we performed a simulation based assessment, in which we defined metrics to quantify the satisfaction level of softgoals. And for evaluating ConG4DaS with respect to the perceived usefulness, we conducted a survey which, according to Easterbrook et al. (2008), is a primarily quantitative method. The results of the simulation based assessment are presented in Chapter 5, and the results from the survey evaluation are in Chapter 6.

1.5 Structure of the Thesis

The remainder of this thesis is organized as follows:

2 – Background – presents the background concepts used throughout this work,

in-cluding Self-Adaptive Systems, Dynamic Software Product Lines and Goal-Oriented Re-quirements Engineering. It also describes the approaches that are the basis of our proposal.

3 – Systematic Mapping – presents the protocol and results of a systematic mapping

on the area of variability management of Dynamic Software Product Lines. Then, it presents some recent studies that were published after the mapping.

4 – ConG4DaS – Contextual Goal models For Dynamic Software product lines –

presents our approach for the Requirements Engineering phase of DSPLs, describing its Do-main Engineering and Application Engineering processes.

(23)

5 – Comparative Study – presents some related work, comparing them to ConG4DaS with respect to some modelling capabilities. Then, it reports a simulation based assessment of ConG4DaS AE process regarding the satisfaction level of the highest priority softgoal.

6 – Survey Evaluation – describes the survey evaluation of ConG4DaS with respect

to the perceived usefulness.

7 – Conclusion – presents the conclusion of this thesis, including its contributions,

(24)

2

Background

This chapter presents the main concepts of the areas related to this work, which includes Self-Adaptive Systems, Dynamic Software Product Lines and Goal-Oriented Requirements Engineering. It also briefly describes the mod-elling language and GORE approach used as baseline for our proposal.

(25)

2.1 Self-Adaptive Systems

Self-adaptive systems are capable of dynamically changing their behaviour in order to adapt to environmental changes. Self-adaptation is particularly necessary for applications that must run continuously, even under adverse conditions and changing requirements (WHITTLE

et al., 2010). Examples of domains that require this capability include automotive systems,

telecommunications, and environmental monitoring systems.

Typically, in self-adaptive systems design decisions are moved towards runtime to control dynamic behaviour and that an individual system reasons about its state and environ-ment (BRUN et al., 2009). Reasoning usually involves the MAPE (Monitor, Analyse, Plan, and Execute) control loop (DOBSON et al., 2006). The cycle starts by monitoring the envi-ronment and collecting data from it; next, the system analyses data, checking whether changes have been made. After that, the system has to plan its course of action, deciding the best way to reach its goals. Finally, the system executes the plan. In the next section, we present one paradigm for developing self-adaptive systems.

2.2 Software Product Lines

A Software Product Line may be seen as a family of software systems that share many characteristics, but may vary in others. According to Pohl, Böckle and van der Linden (2005), Software Product Line Engineering (SPLE) is a paradigm to develop software systems using platforms and mass customization. They argue that the use of SPLE brings improvements in cost, quality, productivity and time to market. The same authors proposed an SPLE frame-work that consists of two separate processes:

 Domain Engineering (DE): responsible for establishing the reusable platform and de-fining the commonality and the variability of the product line. During DE, variability is defined in variability models (POHL, BÖCKLE and VAN DER LINDEN, 2005). This process is called Core Asset Development in (CLEMENTS and NORTHROP, 2002);

 Application Engineering (AE): responsible for deriving product line applications from the platform established in domain engineering. In AE, for deriving a new prod-uct, the variability must be configured. This process is called Product Development in (CLEMENTS and NORTHROP, 2002).

(26)

2.2.1 Variability

Informally, variability is the ability to vary or change. In SPLE, variability must be managed to allow mass customization, i.e. the commonalities and the differences in the appl i-cations of the product line have to be modelled (POHL, BÖCKLE and VAN DER LINDEN, 2005).

The variability subject is a variable item of the real world or a variable property of such an item (POHL, BÖCKLE and VAN DER LINDEN, 2005), i.e., it represents what can vary. The variability object is a particular instance of a variability subject (POHL, BÖCKLE and VAN DER LINDEN, 2005), i.e. variability objects are the different shapes a variability subject may have, representing how it varies. In SPLE, variability subjects and their variabil-ity objects are represented and modelled in terms of variation points and variants.

Variation points (VPs) are the representation of a variability subject within domain artefacts enriched by contextual information (POHL, BÖCKLE and VAN DER LINDEN, 2005). A variant is a representation of a variability object within domain artefacts (POHL, BÖCKLE and VAN DER LINDEN, 2005).

While the variability of a software product line distinguishes different applications of the product line, the commonality denotes features that are part of each application in exactly the same form (POHL, BÖCKLE and VAN DER LINDEN, 2005).

The variability of an SPL is defined during the domain engineering, then, it is config-ured during the application engineering. During the DE, variation points and their correspond-ing variants are identified and modelled, denotcorrespond-ing how the products of a SPL may be custom-ized. The commonality is also modelled, i.e. the features that all products of a SPL must have. During the AE, which is the process that generates products from the SPL, each variation point is bound to a specific variant.

2.2.2 Dynamic Software Product Lines

When a product of an SPL is delivered, all of its VPs have been bound at design time, the product can no longer change to a new configuration. However, when VPs may be bound at runtime and the product is capable of changing its configuration, we call it a Dynamic Software Product Line (DSPL). In DSPLs, variability configuration occurs at runtime, i.e., the AE process is executed at runtime if a new configuration is needed.

(27)

For Hallsteinsen et al. (2008), DSPL can be seen as one among several approaches to building self-adapting/managing/healing systems, providing a way of modelling adaptive sys-tems by using SPL variability management techniques to deal with the variable functionality this kind of systems may present at runtime. Thus, the self-adaptive system itself is seen as a DSPL and every possible configuration of the SAS could be seen as a product of the DSPL (BENCOMO et al., 2008).

Therefore, when we refer to DSPLs, “we are not necessarily dealing with an entire product line in the traditional sense, but we might perceive the DSPL to be a single system, adapting its behaviour when variability is rebound during operation.” (HINCHEY, PARK and SCHMID, 2012)

Thus, the DSPL has to monitor the environment and/or its own properties to detect when it should adapt itself. So its variability should be associated to the environment context or system properties in order to select a variant to cope with current situation.

2.3 Goal-Oriented Requirements Engineering

Requirements define what the system should do, describing the services that it pro-vides and the constraints on its operation (SOMMERVILLE, 2011). Requirements Engineer-ing (RE) is the software development phase that involves discoverEngineer-ing, documentEngineer-ing, and maintaining a set of requirements of a software system (KOTONYA and SOMMERVILLE, 1998).

In Goal-Oriented Requirements Engineering (GORE) approaches, requirements are specified in terms of goals. A goal is an objective the system should achieve and it may cover a functional or non-functional concern (LAMSWEERDE, 2001). Some of the advantages of using goals are (LAMSWEERDE, 2001) (LIASKOS et al., 2006):

 Goals provide precise criterion for requirements pertinence. A requirement is pertinent if it contributes to the satisfaction of at least one stakeholders’ goal;

 Goals may be formulated at different levels of abstraction. Goal refinement provides a mechanism for structuring complex requirements;

 Alternative goal refinements allow the identification of requirements variability, by capturing alternative ways for achieving stakeholders’ goals.

(28)

In DSPLs, goal-based approaches adopt more abstract representations of the decision model, allowing for analysis and planning at runtime (BENCOMO, HALLSTEINSEN and DE ALMEIDA, 2012) .

One particular GORE approach that has been used as basis for many works is the i* framework (YU, 1995). In this framework, participants of the organizational environment of the system-to-be and the system itself are modelled as organizational actors that depend on one another to achieve their goals. In the next section, we present an extension of i*.

**2.4 i*-orthogonal**

i*-orthogonal (LIMA, 2011) is an extension of the i* framework (YU, 1995) with el-ements for context annotations – derived from (ALI, DALPIAZ and GIORGINI, 2010) – and cardinality. In this section, we provide a brief description of i* elements and the new elements introduced in i*-orthogonal.

In the i* framework, there are two models: Strategic Dependency (SD) and Strategic Rationale (SR). The SD model is used to represent actors and the dependencies among them. Figure 1 shows an example of a SD model. The depending actor of a dependency relationship is called depender, while the actor that is depended upon is called dependee. Every dependen-cy relationship also has a dependum, which is the element that denotes the type of the depend-ency. There are four types of dependum:

 Goal: represents an intentional desire of an actor (GRAU et al., 2011);

 Softgoal: softgoals are similar to (hard) goals except that the criteria for the softgoal's satisfaction are not clear-cut (GRAU et al., 2011). They may be used to represent non-functional requirements;

 Task: used to denote that the actor wants to accomplish some specific task, performed in a particular way (GRAU et al., 2011);

 Resource: used when the actor desires the provision of some entity, physical or infor-mational (GRAU et al., 2011).

(29)

Figure 1 - Example of SD model

Source: Thesis’ author

In Figure 1, the User actor is the depender of the Add Photo goal dependency and the

Integrity [Photo] softgoal dependency and it is the dependee of the Photo resource

dependen-cy. Analogously, the Mobile Media actor is the dependee of the Add Photo and Integrity

[Photo] dependencies and it is the depender of the Photo dependency.

In the SR model, the actors are expanded to show their specific intentions. Figure 2 shows an example of a SR model. There are four types of elements that may be placed inside an actor boundary. They are the same types of the dependum: goal, task, resource, and soft-goal. There are three types of relationships to link the internal elements of an actor:

 Means-ends links: these links indicate the relationship of a means (task) to attain an end (goal) (GRAU et al., 2011). They are used to indicate that a goal can be achieved by performing a particular task. These links are a type of OR decomposition, i.e. the goal may be achieved by executing only one the tasks;

 Task decomposition links: these links are used to relate a task to its sub-elements (GRAU et al., 2011). A task may be decomposed into all four types of elements. Task decomposition links are a type of AND decomposition, i.e. to execute a task, all its sub-elements must be fulfilled;

 Contribution links: these links are used to indicate how an element contributes to a softgoal (GRAU et al., 2011).

(30)

Figure 2 - example of SR model

Source: Thesis’ author

In Figure 2, Mobile Media has a goal, Manage Media, which can be achieved by exe-cuting the Add Photo task. Add Photo is decomposed into the Album Selected and List of

Photos Updated goals and also into the Store Photo task. Store Photo is decomposed into the Photo Saved goal and the Availability [Photo] softgoal. Photo Saved may be achieved by

exe-cuting the Save Online task, which contributes positively to the Availability [Photo] softgoal, or the Save Locally task, which has a negative influence on the same softgoal.

As stated before, i*-orthogonal adds elements for context annotations and cardinality. These new elements modify the semantics of some i* elements. Figure 3 presents a SR model with i*-orthogonal notation. In i*-orthogonal, any relationship may have context annotations, which are small rectangles with a context expression attached to a relationship link. Here is how they modify the relationship:

 Dependency: when a dependency has a context annotation, it means that the depender has this dependency only when the related context is active. When the context is not active, the dependency must be removed from the configuration;

 Means-end link: when a means-end link has a context annotation, it means that the task (means) of the relationship is available only when the related context is active. It does not mean that the task must be executed in the context, but that is available as an

(31)

alternative to achieve the goal (end). When the context is not active, the task (means) is removed from the set of alternatives to fulfil the goal (end);

 Task decomposition link: when the related context is active, it means that the sub-element must be fulfilled in order to execute the task, i.e., the AND semantic is pre-served when the context is active. However, when the context is not active, the sub-element is removed from the set of sub-elements that need to be fulfilled for the parent task, i.e., the task is no longer decomposed into that sub-element;

 Contribution link: when a contribution link has a context annotation, it means that the element has that contribution to the softgoal only when the related context is active. When the context is not active, the contribution does not occur.

In regard to the cardinality, it may be present in elements or means-end groups. The cardinality of an element may be [0..1], which means it is optional, and [1..1], which means it is mandatory. If the element is a sub-element of a task decomposition link, then its cardinality must be [1..1], except when the task decomposition is context annotated.

When a goal has more than one end link to optional tasks, then these means-end links to optional tasks should be grouped. The cardinality is removed from the optional tasks and inserted in the group. The group cardinality may be <1..1>, <1..n>, <m..n> or <0..n>.

Figure 3 - Example of i*-orthogonal model

(32)

In Figure 3, the means-end link from the Save Online task is annotated with C1 con-text. Assuming C1 means that there is Internet connection, then, Save Online is only available when C1 occurs, i.e., when the device is connected to the Internet. Moreover, the means-end group related to the Photo Saved goal has cardinality <1..2>, which means that at least one of the alternative tasks must be selected.

In the next section we present a GORE approach for SPL that uses i*-orthogonal for modelling the SPLs variability.

2.5 GSC2SPL Process

Goals, Scenarios and Contexts to Software Product Line (GSC2SPL) (VARELA, 2015) is a requirements engineering process for SPLs that covers both Domain Engineering and Application Engineering. GSC2SPL’s Domain Engineering sub-process allows automatic generation of feature models and use case scenarios for the SPL, based on its i*-orthogonal goal model (LIMA, 2011).

The Application Engineering sub-process allows ad-hoc or context-based product con-figuration. Figure 4 depicts the GSC2SPL process using BPMN (Business Process Model and Notation) (BPMN, 2011). GSC2SPL is based on the processes GS2SPL (Goals and Scenarios to Software Product Lines) (GUEDES et al., 2012) and E-SPL (Early Software Product Line) (LIMA, 2011).

2.5.1 GSC2SPL - Domain Engineering

In the Domain Engineering sub-process, the requirements artefacts of the SPL are elaborated, starting with the i*-orthogonal goal model. The i*-orthogonal model is, then, used to automatically generate the feature model and use case scenarios. This sub-process consists of the following activities:

1. Specify Requirements in Goal Model: in this activity, stakeholders’ goals are mod-elled using the i* framework. It is considered optional if the i* model is available, which is the activity’s output;

(33)

Figure 4 - GSC2SPL process

Source: Adapted from Varela (2015)

2. Specify Context Model: this activity proposes some guidelines to build the contexts model. This context model is created according to the concepts and notation presented in (ALI, DALPIAZ and GIORGINI, 2013). The outputs of this activity are the i*-orthogonal model with context annotations and the contexts model;

(34)

3. Represent Variability: here, guidelines are used to identify variation points in the i*-orthogonal model and insert cardinality. The output is the complete i*-i*-orthogonal model, including contextual annotations and cardinality;

4. Feature Model Elaboration: this activity provides guidelines to generate the SPL’s feature model from the i*-orthogonal model. The output of this activity is the feature model.

5. Feature Model Refinement: this is an optional activity and it should be executed when the FM generated by the previous activity needs to be refined. Refinement is re-quired if the FM has repeated features, features with more than one parent or when the analyst decides to change the feature for a more meaningful one. The output of this ac-tivity is the refined FM;

6. Use Case Scenarios Elaboration: this activity consists in the generation of use case scenarios from the i*-orthogonal model. It is divided in three steps: step 1 concerns the discovery of actors, step 2 is for discovering use cases, and step 3 is for discover-ing and describdiscover-ing use case scenarios. The outputs of this activity are the use case sce-narios;

7. Use Case Scenarios Refinement: the use case descriptions generated by the guide-lines proposed in the previous activity are not complete. This occurs because i* mod-els are not meant for modelling behaviour or exceptions. Therefore, the requirements analyst should revise the scenarios, complementing their description. The outputs of the activity are the refined use case scenarios.

2.5.2 GSC2SPL – Application Engineering

The Application Engineering sub-process is executed when a new product is required. Its purpose is to configure the SPL’s RE artefacts to generate the product’s specific RE arte-facts. This sub-process consists of the following activities:

8. Ad-hoc Configuration: this activity is executed when the analysts decide to configure a new product without making the contextual analysis;

9. Contextual Configuration: this activity is for configuring a new product based on the context where the product is intended to operate. Here, the i*-orthogonal model is ana-lysed and the mandatory elements and those related to the current context are selected;

(35)

10. Variant Prioritization: when more than one configuration is possible, there may be optional elements that are not related to any context, they are ranked based on the pri-ority given to softgoals (used to model NFRs). An utility function is used for indicat-ing the overall value of each configuration and the one with the highest value is select-ed;

11. Product Artefacts Configuration: in this activity, the products artefacts are generat-ed basgenerat-ed on the selectgenerat-ed configuration, i.e. the SPL’s requirements models are config-ured for the specific product.

GSC2SPL is supported by GCL-Tool (Goal and Context for product Line - Tool) (VARELA, 2015), which provides model editors for all requirements models (i*-orthogonal model, feature model and scenarios) and the automatic model transformations of the process. The relationship among the modules and editors of GCL-Tool are depicted in Figure 5.

Figure 5 - GCL-Tool module structure

Source: Adapted from Varela (2015)

2.6 Summary

In this chapter we presented the baseline of this work: Self-Adaptive Systems, Dynam-ic Software Product Lines, Goal-Oriented Requirements Engineering, i*-orthogonal and GSC2SPL. We described how self-adaptive systems use the MAPE loop to determine when to adapt and also some of their modelling dimensions. Next, we presented SPL’s definition, in-cluding its Domain and Application Engineering processes, and its difference to Dynamic SPL.

(36)

Then, we discussed some advantages of using goal-oriented approaches for require-ments engineering and we made a brief presentation of the i*-orthogonal (LIMA, 2011) mod-elling language, which is an extension of the i* framework that allows context annotations and introduce scardinality in some elements. Finally, we presented GSC2SPL, a RE process for SPL. GSC2SPL uses i*-orthogonal models to generate feature models and use case sce-narios and it also allows context-based product configuration.

In the next chapter we present a systematic mapping on variability management for DSPL. Our intention was to find out what kind of models are used to model variability in DSPLs and how variability is configured.

(37)

3

Systematic Mapping

We have conducted a systematic mapping in the area of variability man-agement in Dynamic Software Product Lines. This chapter presents the re-port of this systematic mapping, including the research protocol, results and threats to validity. Since the systematic mapping was conducted in the first semester of 2015, we present some related studies that were published after the mapping was finished.

(38)

3.1 Introduction

As shown in the previous chapter, Software Product Lines (SPLs) offer an effective way to develop a series of similar and domain-specific systems that share a common core, but may have some variable characteristics (CLEMENTS and NORTHROP, 2002). Dynamic Software Product Lines (DSPLs) are SPLs in which the variability configuration occurs at runtime (BENCOMO et al., 2008).

Just as an SPL, a DSPL should be capable of capturing variability, i.e. modelling vari-ation points and variants. However, the DSPL should have those variability models available at runtime, not only at design time, because the DSPL needs to reason over the alternatives space in order to (re)configure itself according to runtime conditions.

For the configuration process, they should monitor some variables in order to detect changes that require the system to adapt. When adaptation is required, a new product configu-ration must be selected and to do this some information must be considered, e.g. contexts and non-functional requirements (NFRs). However, when various types of information are used, there may be conflicts (each one lead to a different configuration) and those conflicts should be resolved before the configuration process continues.

For this systematic mapping, our goal was to find out which models are mostly used to capture the variability in DSPL and how those models are implemented for runtime usage. We would also like to discover how automatic configuration (or adaptation) occurs in DSPLs, in terms of what triggers this configuration process and the aspects taken into account to select a new configuration.

In order to fulfil our goal we have conducted a systematic mapping of the available literature on DSPL area. The search process in the digital libraries was completed in April/2015, so any study indexed after that month was not reviewed in this mapping. Howev-er, at the end of this chaptHowev-er, we present some studies published after the mapping. We did not include them in the systematic mapping report because they were not selected following the same rigorous process.

The results of the systematic mapping are synthetized in this chapter and were used to identify trends and gaps for research on variability management of DSPL. This systematic mapping was also reported in (GUEDES et al., 2015).

CONTEXTUAL GOAL MODELS FOR DYNAMIC SOFTWARE PRODUCT LINES

CONTEXTUAL GOAL MODELS FOR DYNAMIC SOFTWARE PRODUCT

LINES

CONTEXTUAL GOAL MODELS FOR DYNAMIC SOFTWARE PRODUCT

LINES

Acknowledgments

Resumo

Abstract

List of Figures

List of Tables

List of Listings

List of Acronyms

Contents

1

Introduction

1.1 Context

1.2 Motivation

1.3 Research Goals

1.4 Methodology

1.5 Structure of the Thesis

2

Background

2.1 Self-Adaptive Systems

2.2 Software Product Lines

2.3 Goal-Oriented Requirements Engineering

2.4 i*-orthogonal

2.5 GSC2SPL Process

2.6 Summary

3

Systematic Mapping

3.1 Introduction

**2.4 i*-orthogonal**