Analysis of techniques for implementing software product lines variabilities

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Pós-gradua¸cão em Ciência da Computa¸cão. ANALYSIS OF TECHNIQUES FOR IMPLEMENTING SOFTWARE PRODUCT LINES VARIABILITIES Pedro Osandy Alves Matos Júnior ˜ DE MESTRADO DISSERTAC ¸ AO. Recife 21 de agosto de 2008.

(2)

(3) Universidade Federal de Pernambuco Centro de Informática. Pedro Osandy Alves Matos Júnior ANALYSIS OF TECHNIQUES FOR IMPLEMENTING SOFTWARE PRODUCT LINES VARIABILITIES. Trabalho apresentado ao Programa de P´ os-gradua¸ c˜ ao em Ciˆ encia da Computa¸ c˜ ao do Centro de Inform´ atica da Universidade Federal de Pernambuco como requisito parcial para obten¸ c˜ ao do grau de. Mestre em Ciˆ encia da Com-. puta¸ c˜ ao.. Orientador: Prof. Dr. Paulo Henrique Monteiro Borba. Recife 21 de agosto de 2008.

(4) Matos Júnior, Pedro Osandy Alves Analysis of techniques for implementing software product lines variabilities / Pedro Osandy Alves Matos Júnior - Recife : O Autor, 2008. xxii, 121 p. : il., fig., tab. Dissertação (mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, 2008. Inclui bibliografia. 1. Engenharia de software. 005.1. CDD (22. ed.). I. Título. MEI2009- 072.

(5)

(6)

(7) Aos meus pais..

(8)

(9) ACKNOWLEDGEMENTS Agrade¸co, em primeiro lugar, a meus pais, por todo o apoio que me deram desde que nasci. Eles que sempre estiveram ao meu lado, oferecendo ajuda quando eu necessitava, me consolando nos momentos tristes e também compartilhando meus momentos de alegria. Sem eles, não teria conseguido chegar até aqui. Agrade¸co, em especial, ao meu orientador, Paulo Borba, por todas as dicas, comentários e sugestões que ele me deu durante esses anos. Por sempre ter se mostrando dispon´ıvel quando eu necessitei, nunca medindo esfor¸cos para ver o sucesso dos seus ´ desnecessário comentar que, sem ele, esse trabalho não existiria. Muitos de alunos. E seus comentários foram u ´teis para o desenvolvimento desse trabalho. Muitos outros foram e serão u ´teis durante toda a minha vida. Agrade¸co também a` minha querida namorada, Camila, que esteve bastante presente nos u ´ltimos meses em que estive concluindo esse trabalho. Sua presen¸ca, carinho e compreensão foram muito importantes para mim durante a conclusão dessa disserta¸caõ. Não posso deixar de citar também todos os amigos e companheiros do SPG, pessoas com quem eu aprendi e me diverti bastante. Desses, fa¸co uma men¸caõ especial a Márcio (Marcinho SBT) e Ivan (Graaaande l´ıder), pois estiveram diretamente ligados a esse trabalho. Muito do que produzi durante esses anos foi resultado de reuniões e conversas informais com essas pessoas maravilhosas. Menciono ainda Rafael Duarte que, apesar de não ser membro do SPG, também esteve bastante presente. Agrade¸co também a todas as pessoas ligadas ao projeto FLIP. Também menciono aqui a grande contribui¸caõ do CNPq e FINEP, por fomentarem esse projeto de pesquisa.. vii.

(10)

(11) True glory consists in doing what deserves to be written; in writing what deserves to be read; and in so living as to make the world happier for our living in it. —PLINY THE ELDER.

(12)

(13) RESUMO Linhas de Produtos de Software (LPS) são conjuntos de sistemas de software que compartilham uma base comum de funcionalidades e satisfazem a necessidades espec´ıficas de determinados segmentos de mercado. LPS são desenvolvidas a partir de uma arquitetura comum e compartilham um conjunto de artefatos reusáveis (projetados para um dom´ınio de aplica¸caõ espec´ıfico). Entre as atividades principais na constru¸caõ e manuten¸caõ de uma LPS está a gerência das varia¸co˜es nos diversos artefatos que a compõem. Em particular, a escolha de técnicas de programa¸caõ que possibilitem a introdu¸cão de varia¸co˜es em artefatos de implementa¸cão é uma atividade que merece bastante aten¸cão. A escolha de qual técnica utilizar para lidar com determinados tipos de varia¸cões nos artefatos de implementa¸cão de uma LPS pode gerar impactos significativos tanto na qualidade desses artefatos como na qualidade dos produtos finais gerados. Apesar da importância dessa atividade, poucos estudos publicados mostram compara¸cões entre as diversas técnicas que permitem a implementa¸caõ de varia¸cões em software. A maioria dos trabalhos existentes limita-se a avalia¸co˜es qualitativas dessas técnicas, não analisando o impacto dessas técnicas nos atributos de qualidade de LPS existentes através de métricas de software. O foco do presente trabalho é a compara¸cão entre algumas das técnicas de implementa¸cão de varia¸cões usadas na ind´ ustria de software. Para tal, primeiro apresentamos um catálogo de tipos de varia¸cões, onde varia¸cões são classificadas de acordo com a sua estrutura e localiza¸cão no código da aplica¸caõ. As varia¸co˜es apresentadas no catálogo foram identificadas através de uma análise realizada em uma LPS do dom´ınio de jogos para dispositivos móveis. Em seguida, apresentamos propostas de solu¸cão que utilizam algumas das principais técnicas de programa¸caõ para lidar com cada tipo de varia¸caõ espec´ıfico. Como parte desse trabalho, analisamos o impacto da utiliza¸cão de cada solu¸cão proposta através de dados qualitativos e quantitativos. Analisamos ainda a composi¸caõ do uso dessas solu¸cões para implementar varia¸co˜es em LPS e como um catálogo de tipos de varia¸co˜es e um conjunto de propostas de solu¸cões podem guiar a implementa¸caõ ou reestrutura¸caõ de varia¸co˜es em uma LPS. Palavras-chave: Linhas de Produtos de Software, Programa¸cão Orientada a Aspectos, Mixins. xi.

(14)

(15) ABSTRACT Software Product Lines (SPLs) are sets of software systems that share a common base of features and satisfy the needs of specific market segments. SPLs are developed from a common architecture and share a set of reusable artifacts (designed for a specific domain). Among the main activities in the life cycle of a SPL is the management of variations in all the artifacts that belongs to it. Particularly, the choice of programming techniques that enable variability in implementation artifacts is an activity that deserves much attention. The choice of which technique to use in order to deal with variations in the implementation artifacts of a SPL can result in significant impacts on the quality of these artifacts and also in the resulting products. Although this is an important topic, few published studies show comparisons of the many techniques that enable variability in software. Most of these works are limited to qualitative evaluations of these techniques, not analyzing the real impact of these techniques in the quality attributes of SPLs. The focus of this thesis is the comparison of variability enabling techniques that are used by the software industry. To accomplish this task, we first present a catalog of variation types, where variations are grouped according to their structure and location in the source code. The variation types presented in the catalog were identified by an analysis in a SPL from the mobile games domain. After, we presented a set of proposed solutions to implement variavilities. These proposed solutions use different programming techniques in order to deal with the identified variation types. As part of this work, we analyze the impact resulting from each proposed solution using both qualitative and quantitative evaluation. We also analyze the composition of these solution in order to implement variabilities in SPLs and discuss how the presented catalog of variation types and the set of proposed solutions can guide the implementation of variations in a SPL. Keywords: Software Product Lines, Aspect-Oriented Programming, Mixins. xiii.

(16)

(17) CONTENTS. Chapter 1—Introduction 1.1 1.2. 1. Main Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Chapter 2—Background 2.1. 2.2. 2.3 2.4. 5. Software Product Lines . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Commonalities in Software Product Lines . . . . . . . . . . 2.1.2 Variabilities in Software Product Lines . . . . . . . . . . . . Techniques for Implementing Variabilities in Software Product Lines 2.2.1 Conditional Compilation . . . . . . . . . . . . . . . . . . . . 2.2.2 Inheritance and Mixins . . . . . . . . . . . . . . . . . . . . . 2.2.3 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Aspect-Oriented Programming . . . . . . . . . . . . . . . . . 2.2.5 Program Transformations . . . . . . . . . . . . . . . . . . . 2.2.6 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Summary of Presented Techniques . . . . . . . . . . . . . . Games for Mobile Devices Domain . . . . . . . . . . . . . . . . . . 2.3.1 BestLap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. Chapter 3—Metrics and Criteria for Software Product Lines Evaluation 3.1 3.2 3.3 3.4 3.5. 3.6. Complexity Metrics . . . . . . . . . . . . . . . . . . . . . Modularity Metrics . . . . . . . . . . . . . . . . . . . . . Separation of Concerns Metrics . . . . . . . . . . . . . . Efficiency Metric . . . . . . . . . . . . . . . . . . . . . . Adaptations of Metrics to Software Product Lines . . . . 3.5.1 The Measurement Object . . . . . . . . . . . . . 3.5.2 Classes Dependent on Inter-Type Declarations . . 3.5.3 Separation of Concerns vs Separation of Variants Summary . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. Variation Type 1: Variation in Class Attribute . . . . . . . . . . . . . . . 4.1.1 Proposed Solutions for Variation in Class Attribute . . . . . . . . xv. 5 8 8 11 12 14 17 17 20 21 21 21 22 23 25. Chapter 4—Variation Types and Proposed Solutions 4.1. 2 3. 25 26 26 27 27 27 29 30 33 35 38 40.

(18) xvi. CONTENTS. 4.1.2. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. Evaluation of Proposed Solutions for Variation in Class Attribute 4.1.2.1 Evaluation of Solutions for Alternative Initialization Values 4.1.2.2 Evaluation of Proposed Solutions for Optional Attributes Variation Type 2: Variation in Class Hierarchy . . . . . . . . . . . . . . . 4.2.1 Proposed Solutions for Variation in Class Hierarchy . . . . . . . . 4.2.2 Evaluation of Proposed Solutions for Variation in Class Hierarchy Variation Type 3: Variation in the Whole Body of a Method . . . . . . . 4.3.1 Proposed Solutions for Variation in the Whole Body of a Method 4.3.2 Evaluation of Proposed Solutions for Variation in the Whole Body of a Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variation Type 4: Variation in the Beginning or End of Method Body . . 4.4.1 Proposed Solutions for Variation in the Beginning or End of Method Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Evaluation of Proposed Solutions for Variation in the Beginning or End of Method Body . . . . . . . . . . . . . . . . . . . . . . . . . Variation Type 5: Variation in a Structure Around Method Body . . . . 4.5.1 Proposed Solutions for Variation in a Structure Around Method Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Evaluation of Proposed Solutions for Variation in a Structure Around Method Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Final Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Beyond the Catalog of Variation Types . . . . . . . . . . . . . . . 4.6.2 Crosscutting Variabilities vs Non-crosscutting Variabilities . . . . 4.6.3 Quantification in Aspect-Oriented Programming . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Chapter 5—Evaluation 5.1. Applicability of Proposed Solutions . . . . . . . . . . . . . . . . . . . . .. Chapter 6—Concluding Remarks 6.1 6.2 6.3. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Issues and Future Work . . . . . . . . . . . . . . . . . . . . . . . .. 45 45 53 59 60 62 68 70 76 82 83 85 90 91 94 97 97 98 98 98 99 111 113 114 114 115.

(19) LIST OF FIGURES. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8. The key activities for software product lines development [22]. . . . . . . Costs for developing N kinds of systems as single systems compared to product line engineering [53]. . . . . . . . . . . . . . . . . . . . . . . . . . The variability funnel with early and delayed variability [36]. . . . . . . . Example of a feature diagram. . . . . . . . . . . . . . . . . . . . . . . . . Inheritance technique used to define specializations. . . . . . . . . . . . . Feature composition implemented with single inheritance. . . . . . . . . . Feature composition implemented with multiple inheritance or mixins. . . Screen captures from BestLap mobile game. . . . . . . . . . . . . . . . .. 7 9 11 15 16 17 23. 3.1. Refactoring of Screen class. . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 4.1 4.2 4.3 4.4 4.5. Extraction of Logging variability (intermediate designs). . . . . . . . . . . Extraction of Logging variability (final designs). . . . . . . . . . . . . . . Results of Vocabulary Size metric for PS1, PS2 and PS3. . . . . . . . . . Results of LOC metric for PS1, PS2 and PS3. . . . . . . . . . . . . . . . Results of NOA and NOEDA metrics for MainCanvas class (PS1, PS2 and PS3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of CBC and N CV CScreenSize metrics for MainCanvas class (PS1, PS2 and PS3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CDC metric for ScreenSize concern. . . . . . . . . . . . . . . . . . . . . . Average bytecode size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of VS and LOC metrics for PS1, PS2 and PS4. . . . . . . . . . . Results of NOA and NOEDA metrics for Resources class (PS1, PS2 and PS4). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of CBC and NCC metrics for Resources class (PS1, PS2 and PS4). CDC metric for Debug concern. . . . . . . . . . . . . . . . . . . . . . . . Average bytecode size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of VS and LOC metrics for PS5 and PS6. . . . . . . . . . . . . . CBC metric for MainCanvas class (PS5 and PS6). . . . . . . . . . . . . . Results of NCC and NCVC metrics for PS5 and PS6. . . . . . . . . . . . Average bytecode size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of VS metric for PS7, PS8, PS9, PS10 and PS11. . . . . . . . . . Results of LOC metric for PS7, PS8, PS9, PS10 and PS11. . . . . . . . . Average bytecode size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results of VS and LOC metrics for PS12, PS13 and PS14. . . . . . . . . Results of NCC and CDC metrics for PS12, PS13 and PS14. . . . . . . .. 37 37 46 48. 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22. xvii. 6. 49 49 50 52 54 55 56 57 57 63 64 64 66 77 77 79 86 87.

(20) xviii. LIST OF FIGURES. 4.23 Average bytecode size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.24 Results of VS and LOC metrics for PS15, PS16 and PS17. . . . . . . . . 4.25 Average bytecode size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9. Screen captures from Arena optional feature. . . . . . . . . . . . Results of VS and LOC metrics for Arena feature experiment. . CLOC metric for Arena feature experiment. . . . . . . . . . . . Results of NOA and NOO metrics for Arena feature experiment. WOC metric for Arena feature experiment. . . . . . . . . . . . . LCOO metric for Arena feature experiment. . . . . . . . . . . . Results of CBC and NCC metrics for Arena feature experiment. Results of DoS and CDC metrics for Arena feature experiment. Average bytecode size for Arena feature experiment. . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 88 94 95 100 105 106 107 108 108 109 109 110.

(21) LIST OF TABLES. 2.1. Programming techniques support for different variability types. . . . . . .. 4.1 4.2 4.3. Variation types and number of proposed solutions. . . . . . . . . . . . . . 35 Solutions proposed to handle Variation in Class Attribute. . . . . . . . . 39 LOC metric for solutions used to implement alternative initialization values for class attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Metrics for showing the impact of use of Proposed Solution 2 on Screen128X128 aspect and Proposed Solution 3 on Screen128X128 properties file. . . . 50 BS metric for the solutions used to implement alternative initialization values for class attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Summary of the results obtained by the proposed solutions against the quality criteria for SPLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 LOC metric for solutions used to implement optional class attributes. . . 54 Metrics for showing the impact of use of Proposed Solution 2 on DebugAspect and Proposed Solution 4 on ResourcesDebug class. . . . . . . . 54 BS metric for the solutions used to implement optional attributes. . . . . 58 Summary of the results obtained by the proposed solutions against the quality criteria for SPLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Solutions proposed to handle Variation in Class Hierarchy. . . . . . . . . 60 LOC metric for the solutions used to implement Variation in Class Hierarchy. 63 CBC metric for the aspects used by Proposed Solution 6. . . . . . . . . . 63 Concern diffusion and variant diffusion metrics for the aspects used in Proposed Solution 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Concern tangling and variant tangling metrics for the aspects of used in Proposed Solution 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 BS metric for the implementations of Proposed Solution 5 and Proposed Solution 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Summary of the results obtained by the proposed solutions against the quality criteria for SPLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Solutions proposed to handle Variation in the Whole Body of a Method. . 69 LOC metric for solutions used to implement Variation in the Whole Body of a Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Metrics for the solutions used to implement Variation in the Whole Body of a Method on SoundEffects class. . . . . . . . . . . . . . . . . . . . . . 76 Metrics for Proposed Solution 8 and Proposed Solution 9. . . . . . . . . . 78 Metrics for Proposed Solution 10. . . . . . . . . . . . . . . . . . . . . . . 78 Metrics for Proposed Solution 11. . . . . . . . . . . . . . . . . . . . . . . 78. 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23. xix. 22.

(22) xx. LIST OF TABLES 4.24 BS metric for the solutions used to implement Variation in the Whole Body of a Method (a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.25 BS metric for the solutions used to implement Variation in the Whole Body of a Method (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.26 Summary of the results obtained by the proposed solutions against the quality criteria for SPLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.27 Solutions proposed to handle Variation in the Whole Body of a Method. . 4.28 LOC metric for solutions used to implement Variation in the Beginning or End of Method Body. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.29 Other complexity metrics and CBC metric for the solutions used to implement Variation in the Beginning or End of Method Body. . . . . . . . . . 4.30 BS metric for the solutions used to implement Variation in the Beginning or End of Method Body. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.31 Summary of the results obtained by the proposed solutions against the quality criteria for SPLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.32 Solutions proposed to handle Variation in the Whole Body of a Method. . 4.33 LOC metric for solutions used to implement Variation in a Structure Around Method Body. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.34 Complexity metrics for comparing the impact of the solutions used to implement Variation in a Structure Around Method Body in artifacts specific of Proposed Solution 16 and Proposed Solution 17. . . . . . . . . . . . . 4.35 BS metric for the solutions used to implement Variation in a Structure Around Method Body. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.36 Summary of the results obtained by the proposed solutions against the quality criteria for SPLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8. Metrics for BestLap SPL where Arena feature is implemented using conditional compilation technique. . . . . . . . . . . . . . . . . . . . . . . . Metrics for BestLap SPL where Arena feature is implemented using Java’s inheritance mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metrics for BestLap SPL where Arena feature is implemented using CaesarJ’s mixin-based inheritance mechanism. . . . . . . . . . . . . . . . . . Metrics for BestLap SPL where Arena feature is implemented using AOP technique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOEDA and NOEDO metrics for BestLap SPL where Arena feature is implemented using AOP technique. . . . . . . . . . . . . . . . . . . . . . Bytecode Size metric values for Arena feature experiments. . . . . . . . . Summary of the results for Arena feature experiments. . . . . . . . . . . Bytecode Size metric values for Arena feature experiments . . . . . . . .. 80 81 81 83 86 86 88 89 90 94. 95 96 96 100 102 103 104 105 110 111 112.

(23) LISTINGS. 2.1 2.2 3.1 3.2 4.1 4.2 4.3 4.4 4.5 4.6 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19. 4.20. 4.21. 4.22. Conditional compilation example. . . . . . . . . . . . . . . . . . . . . . . AOP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Polygon class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Square aspect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Variation in Class Attribute (a). . . . . . . . . . . . . . . . . Example of Variation in Class Attribute (b). . . . . . . . . . . . . . . . . Example of variation in class attribute (c). . . . . . . . . . . . . . . . . . Example of Attribute Defined by Conditional Compilation solution used to handle attributes with alternative initialization values. . . . . . . . . . . Example of Attribute Defined by Conditional Compilation solution used to handle optional attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Attribute Defined by Inter-Type Declaration solution used to handle attributes with alternative initialization values. . . . . . . . . . . Example of Variation in Class Hierarchy (a). . . . . . . . . . . . . . . . . Example of Variation in Class Hierarchy (b). . . . . . . . . . . . . . . . Example of Variation in Class Hierarchy (c). . . . . . . . . . . . . . . . . Example of Variation in Class Hierarchy (d). . . . . . . . . . . . . . . . Example of Class Hierarchy Defined by Conditional Compilation solution used to handle variability in the hierarchy structure of MainCanvas class. Example of Class Hierarchy Defined by Inter-Type Declaration solution used to handle variability in the hierarchy structure of MainCanvas class Example of Variation in the Whole Body of a Method (a). . . . . . . . . Example of Variation in the Whole Body of a Method (b). . . . . . . . . Example of Variation in the Whole Body of a Method (c). . . . . . . . . Example of Whole Body of a Method Defined by Conditional Compilation solution used to handle alternative behaviors for playSound method in SoundEffects class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Whole Body of a Method Defined by Inter-type Declaration solution used to handle alternative behaviors for playSound method in SoundEffects class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Whole Body of a Method Defined by Around Advice solution used to handle alternative behaviors for playSound method in SoundEffects class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example of Whole Body of a Method Defined by Strategy solution used to handle alternative behaviors for playSound method in SoundEffects class. xxi. 13 18 30 31 38 39 39 41 41 42 59 59 59 59 61 62 68 68 69. 70. 71. 73 74.

(24) xxii. LISTINGS. 4.23 Example of Whole Body of a Method Defined by Method Override solution used to handle alternative behaviors for playSound method in SoundEffects class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.24 Example of Variation in the Beginning or End of Method Body. . . . . . 4.25 Example of Variation in the Beginning or End of Method Body Defined by Conditional Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.26 Example of Variation in the Beginning or End of Method Body Defined by After/Before Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.27 Example of Variation in the Beginning or End of Method Body Defined by Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.28 Example of Variation in a Structure Around Method Body. . . . . . . . . 4.29 Example of Structure Around Method Body Defined by Conditional Compilation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.30 Example of Structure Around Method Body Defined by Around Advice. . . 4.31 Example of Structure Around Method Body Defined by Inheritance. . . .. 75 82 84 84 85 90 91 92 93.

(25) CHAPTER 1. INTRODUCTION Software Product Lines (SPLs) [22] are families of software products that share a base set of common features. They are developed from a common architecture, and share a portfolio of reusable assets. The adoption of SPLs is a solution to software development enterprises that develop software systems that have to adapt to different constraints or to satisfy the requirements of clients with distinct or conflicting expectations. They can choose to develop a single managed SPL, and instantiate software systems according to their needs, instead of developing many independently managed software systems which do not reuse efforts among their development activities, or do it in an ad-hoc way. The adoption of development strategies based on SPLs can bring advantages like short time-to-market, reduced development costs, better quality in the resulting products and improved client satisfaction [22]. Despite all these advantages, the development of SPLs also implies additional investments and complexity, as most of the activities are concerned in creating assets that are reusable. The existing literature has already addressed how to manage the development of SPLs, or to deal with generality in high-level assets, like domain models and architectures. However, little attention has been given on how to actually deal with the generality that SPLs require at the source code level [13]. Some programming techniques are known for enabling the implementation of variabilities, however, programmers have little information to decide which technique should be chosen in different situations. We argue that the choice of the correct technique can lead to significant impacts on the quality attributes of SPLs. Few works have been published on this topic and most of them focus on discussing qualitative attributes of each technique [13, 52, 59, 25]. Also, a very small number of them conducts experiments and use metrics to quantitatively assess the impact of each technique. More research in this topic is indeed necessary. In fact, that is the focus of this work. One assumption of our work is that there is no variability implementation technique that always outperforms the others. Indeed, this assumption has been evidenced by other researchers [13, 52, 59, 25]. Some techniques are not able to implement some types of variabilities in a scalable way. Also, different domains imply different expectations for the development techniques. A software development company that creates information systems, for example, may give priority to well modularized and easy to understand components, whereas a company that develops embedded systems, usually priorizes low consumption of resources in the resulting products. In order to compare techniques, we have first defined a set of comparison criteria: complexity of implementation artifacts, modularity, separation of concerns and efficiency in size of the resulting applications. Although we may not have considered every possible 1.

(26) 2. INTRODUCTION. criteria, we think that this is a good set because these criteria are relevant in most application domains. We also have considered some metrics to evaluate these criteria. While most of the metrics are well established for single systems engineering, we also have defined new metrics for our purposes and defined some guidelines to use of the well established metrics in the context of SPLs. In addition to that, we have developed a simple tool to help the calculation of metrics following our guidelines. To compare the techniques, we have first provide a set of proposed solutions to implement variabilities. These solutions define how a technique can be applied to address a specific type of variation in the source code. We have grouped these solutions into a catalog of variation types. For every type of variation from the catalog, a portfolio of proposed solutions is offered to deal with it. The criteria for grouping proposed solutions into variation types were the location in the source code where the variation appears and the varying source code structure. With this decision, we intend to help the implementation of variabilities in existing source code, using the extractive and reactive SPL adoption strategies, as we explain in the next chapters. We have conducted rigorous analyzes for every variation type of the catalog. A single variation point in the source code of an existing SPL (initially implemented with the conditional compilation technique) is implemented with each proposed solution associated with that variation type. After, we compared the impact of the use of each solution in respect to the criteria we have defined. This gives to the programmer the necessary information to choose a solution to apply, given the current context and priorities for each criteria. Also, our proposed solutions are not just a recommendation of a technique to be used. They are a description of how a specific variation type can be handled by a given technique. Thus, it becomes easier for the programmer to apply the solution. In the future, these proposed solutions could be included in a SPL development tool to provide semi-automation to the variability implementation activity, as discussed later. As we consider separation of concerns as a criteria to choose techniques, we also have performed a case study where a whole crosscutting variability from a industrial mobile game is implemented using our approach. We then, compare results obtained by each technique. We have identified the necessity to perform this case study because the full benefits of using a technique that supports modular implementation of crosscutting concerns, like aspect-oriented programming, are only seen when a whole concern is implemented with this technique. We discuss this issue later in this work. The case study was also useful to evaluate our hypothesis that our catalog of variation types,and portfolio of variability implementation proposed solutions, can be used as a guideline to implement variabilities in SPLs. 1.1. MAIN OBJECTIVES. The main goals of this work are: The definition of criteria, metrics and guidelines to evaluate implementations of SPLs; A catalog of variation types, in conjunction with a portfolio of proposed solutions.

(27) 1.2 ORGANIZATION. 3. (using different techniques) to address each variation type; Evaluation of the performance of each proposed solution according to different criteria, in order to help software developers to decide which solution is best suited for his special case; Evaluate the performance of some techniques to implement crosscutting variabilities.. The problem we try to solve is the fact that software developers often do not have the necessary information to choose a variability enabling technique, when implementing a SPL. The consequences of this problem can be negative impacts on quality attributes of both implementation and resulting products of this SPL. The concrete benefits of our solution are: an increased confidence of the software developer when choosing which technique to use in order to implement variabilities in a SPL; a reduction in the chance that a software developer chooses a technique that have a negative impact on a critical quality factor of the SPL being implemented. 1.2. ORGANIZATION. The remainder of this text is organized as follows: Chapter 2 presents some background information that is relevant to the understanding of this work. Concepts of Software Product Lines are explained, as well as some variability enabling techniques are presented. Finally, it discuss particularities and variabilities found in domain of mobile games, and also presents BestLap, an industrial mobile game used as case study in this work; Chapter 3 discuss the criteria used to compare variability implementation techniques, in conjunction with the metrics used to assess these criteria. In this chapter, it is discussed how traditional software metrics can be applied in a context of SPLs and some new metrics are presented to this purpose; Chapter 4 presents the catalog of variation types that we have identified. For every variation type, a set of specific proposed solutions is provided. We evaluate the use of these solutions to handle a single occurrence of the variation type in the source code of BestLap using our set of metrics and criteria. We also make some considerations about the use of the variation types catalog and set of proposed solutions; Chapter 5 evaluates the use of the variation types catalog and variability implementation solutions to implement a crosscutting variability of BestLap; Chapter 6 concludes this work, discussing the summary of results and presenting some related works. It also discuss some open issues and points some future works..

(28)

(29) CHAPTER 2. BACKGROUND In this chapter, we present some background information that is relevant to the understanding of this thesis. This chapter is organized as follows: in Section 2.1, we introduce concepts related to Software Product Lines and variabilities; Section 2.2 complements the previous section, by discussing some of the most relevant techniques to handle variabilities at the implementation level; finally, in Section 2.3, we introduce the domain of games for mobile devices and discuss what kinds of variabilities can be find in this domain. 2.1. SOFTWARE PRODUCT LINES. The Software Engineering Institute (SEI) defines Software Product Lines (SPLs) as a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [57]. The concept of software families were first introduced by Dijkstra and Parnas. Dijkstra [27] proposed a model of family-based development where differences in design decisions distinguished family members. Parnas [51] characterized families as groups of items that are strongly related by their commonalities, where commonalities are more important than the variations among family members. The concept of software reuse is also not new. It has been proposed some decades ago [49] as a possible solution to the existing software crisis. The SPL approach differs from common software reuse by ensuring that each reusable asset is developed within a software family scope and has a clear purpose in this scope. Moreover it enforces management commitment with the development process. These are critical success factors to any reuse program. Since reusable assets are harder to develop and maintain, the decision to develop a component in a reusable fashion should be carefully analyzed by cost x benefit models. A reusable asset should only be developed when a cost x benefit analysis shows that it is better than developing specific components for each application. The SPL approach also enforces that any necessary customizations to reusable assets, in order to build specific products (named instances), are well documented. This constraint enforces that a product instantiation is a straightforward process. Thus, most of the work in a SPL is concentrated on developing and documenting reusable assets, while the instantiation of a product is an easier task. It is also important to say that reusable assets does not only means implementation artifacts, but every common or customizable artifact that is shared among the SPL instances. Reusable assets can be artifacts that are part of the development process (for example, requirements and design documents) or part of the final product (for example, binary files, images, sound files, documentation). We define core asset as being any artifact that is used to instantiate more than one product in a SPL. Thus, core assets 5.

(30) 6. BACKGROUND. Figure 2.1 The key activities for software product lines development [22].. refers to the set of artifacts (be it part of the development process or part of a final product) that are shared by at least two instance of a SPL. The key activities in SPLs development are shown in Figure 2.1. Each of the three circles represent an activity. The Core Asset Development activity is motivated by the domain engineering, whose focus is to analyse the SPL domain and search for reuse opportunities within its scope. The core assets provide support for the Product Development activity, which is part of the application engineering. The focus of the Product Development activity is to combine and configure core assets and, if necessary, to develop application specific components in order to instantiate a new product. Both activities are supported and coordinated by the Management activity. Pohl et al. list some benefits from adopting a SPL approach [53]: Reduction of Development Costs. When core assets are reused to instantiate several products, the overall cost to create all the system is drastically reduced. The cost to create new products on a mature SPL should be very low. Despite that, higher upfront investments are required in order to develop reusable assets. Thus, the initial costs to develop a SPL are higher than the initial cost to develop a single product, however the total accumulated cost is lower as the SPL evolves, when comparing to the development of several independent systems. Figure 2.2 shows a comparison of the accumulated costs to develop a SPL with n instances or n independent software products. The break-even point in the figure is the point where the costs are the same for developing the systems separately as for developing them by a SPL approach. As shown in Figure 2.2, some empirical studies revealed that the upfront investments to initiated a SPL usually Pay-off around three systems [22]. This three systems number is not a rule, though. Many factors contribute to when the break-even point will be reached, like application domain, organization experience, and SPL adoption strategy [48, 42]; Enhancement of Quality. As the number of instances increase, the reusable assets get more tested. In a mature SPL, the reusable assets already had their.

(31) 2.1 SOFTWARE PRODUCT LINES. 7. Figure 2.2 Costs for developing N kinds of systems as single systems compared to product line engineering [53].. quality assured in many products, thus, new products using these assets tends to be more reliable than products developed from scratch; Reduction of Time-to-Market. As the effort required to instantiate a new product in a SPL is much lower than the effort required to develop a independent system, the time to release new products can be significantly reduced. Because of the upfront investments required to develop a SPL, the time-to-market of the first products should be higher than the regular time-to-market to develop a single system. The time-to-market tends to be reduced for new products, as the SPL evolves.. SPLs can be developed using different adoption strategies. In [48, 42], three adoption strategies for SPLs are proposed: proactive, reactive, and extractive. In the proactive approach, the organization analyzes, designs, and implements a fresh SPL to support the full scope of products needed on the foreseeable horizon. In the reactive approach, the organization incrementally grows an existing SPL when the demand arises for new products or new requirements on existing products. In the extractive approach, the organization extracts existing products into a single SPL. For small or medium-sized organizations, or domains where time-to-market is critical, reactive and extractive approaches are preferred, since the proactive approach demands high upfront investments and creates more risks..

(32) 8 2.1.1. BACKGROUND. Commonalities in Software Product Lines. Commonalities constitutes the basis of SPLs. They can be defined as the set of decisions that are common to all products in a software family. They are the motivating factors to develop a SPL. The more commonalities a set of software products have, the more a enterprise will benefit from developing them in a SPL approach. In fact, it only makes sense to develop a SPL when the members of the software family have a substantial set of commonalities among them. This is coherent with the Parnas’ concept of software familes [51]: ¨We consider a set of programs to constitute a family, whenever it is worthwhile to study programs from the set by first studying the common properties of the set and then determining the special properties of the individual family members¨. Coplien[24] also presents commonalities as abstractions. If we examine a family of related software systems, we can ignore some details and reason about the whole family through abstractions. These abstractions are the commonalities. Coplien also distinguish deductive commonality from inductive commonality. The former relates to experience, whereas the latter relates to learning. We discover commonalities in an inductive way when we are familiar with the set of system to be developed. Thus, we can propose abstraction based on our past experience. When we face a new situation, no learned model applies well. We try to find abstractions by seeking for repetition. In the absence of analogy and experience, deductive reasoning is applied. 2.1.2. Variabilities in Software Product Lines. Variability is another key concept for the understanding of SPLs. Variation management is a key discriminator between conventional software engineering and SPL engineering. Before proceeding with this section, it is important to distinguish variability in time from variability in space. Variability in time refers to the evolution of a software system over the time. It is addressed in conventional software engineering through configuration management activities and is not the focus of this thesis. On the other hand, variability in space refers to the differences among the instances of a SPL at a fixed point in time. Conventional software engineering deals with variability in time only, whereas SPL engineering deals with variability in both time and space [43]. On the remaining of this thesis, when we use the term variability alone, we are referring to variability in space. Variability in SPLs allows developers to delay some design decisions. We refer to these delayed decisions as variation points. Acording to [53], a variation point is a representation of a variability subject within domain artefacts enriched by contextual information. For each individual instance of a SPL, we bind specific decisions to the variation points. These specific decisions are called variants. Whenever a decision is made, we say that the variability is bound. Figure 2.3 illustrates how the available space of design decisions differs from common system engineering to SPL engineering. The funel on the left side represents the evolution of the domain of design decisions on common systems engineering, whereas the funnel on the right side represents the same information for SPL engineering. In both cases, the initial possibilities of final systems is very large at the requirements specification phase. In single systems engineering, the number of possible systems is reduced in a fast way,.

(33) 2.1 SOFTWARE PRODUCT LINES. 9. Figure 2.3 The variability funnel with early and delayed variability [36].. through the development lifecycle, culminating to a single product at the end. On the other hand, in SPLs development the number of possible systems is smoothly reduced as the development evolves, leading to a set o possible instances at the end. That is, SPLs engineering allows developers to late bind variabilities. Variabilities can be classified based on their binding time, i.e the time in which the specific variant is decided. The binding time for a variability can be: Compile-Time: variability is resolved when the source code for the SPL is being compiled. We also consider variabilities that are bound before the actual compilation, like the ones implemented by code preprocessor tools, as part of this category; Load-Time: variability is resolved during module or library linking, just before the execution of the program; Run-time: variability is bounded when the program is running. The context information to decide which variant to be selected can be provided by input from the user, or inferred from the running environment (adaptative systems).. Variability only makes sense when it is related to a commonality base [24]. We can not talk about variability when we do not have a commonality as referential. Thus, we can classify variability by the way they relate to the commonality base: Positive variability: leaves the commonality model untouched and add an extra behavior; Negative variability: removes existing behavior from the commonality base, breaking some existing assumptions on the commonality model..

(34) 10. BACKGROUND. Positive variability is preferred against negative variability, since it preserves the commonality assumptions and thus, makes the overall SPL easier to understand and maintain. For example, one way to implement negative variabilities is to use inheritance with cancelation [56]. This technique violates the Liskov substitutability principle [46], which states that an instance of a class should always be substitutable by an instance of any of its subclasses without breaking programs that was written making assumptions about the parent class. Based on the argument that negative variabilities break the common structure, which is the skeleton of the component, Patzke and Muthig [52] suggest that they should be avoided and turned into positive ones. Coplien [24], however, states that there are some situations where negative variabilities should be considered; for example, when almost all instances of a SPL behaves in the same way and one particular instance excepts from the rule. Moreover, he states that negative variabilities should be considered in a context where the variation becomes larger than the commonality. We agree with this position but with the observation that the system designer should carefully think about the use of negative variabilities, since they can be harmful to the overall understanding of the SPL structure. The system design should always consider the possibility to transform negative variabilities into positive ones. Furthermore, in cases where the number of variations is much higher than the number of commonalities, maybe it is the time for the system designer to do a cost x benefit analysis in order to decide if it is really worth to take the SPL engineering approach. Variabilities can also be classified by their relationships with other variabilities. A common way to show the variabilities of a product family is to use feature diagrams, which were first introduced in the Feature-Oriented Domain Analysis (FODA) methodology [39]. Feature diagrams present all the features of a product family in a hierarchical tree, representing the relationships among these features. Features shown in a feature diagram can be one of the following four types: Mandatory Features: represent the commonality of a product family. mandatory features must be included in every product of the family;. The. Optional Features: as the name says, this feature is a variability, which can be present or not in a specific product of the family; Mutual-Exclusive Alternative Features (XOR-Features): features of this type belong to a group of features from which no more than one must be selected; OR-Features: like XOR-features, this kind of feature also belongs to a group of features, however, the selection of more than one feature of this group is allowed.. An example of a feature diagram is shown in Figure 2.4. This feature diagram represents a family of cars. In a feature diagram, features are represented by rectangles containing their names and the relationships among them are represented by lines and arcs. A mandatory feature is identified by a black circle above the feature’s rectangle, whereas a optional feature is identified by an empty circle. In the example, every car.

(35) 2.2 TECHNIQUES FOR IMPLEMENTING VARIABILITIES IN SOFTWARE PRODUCT LINES. 11. Figure 2.4 Example of a feature diagram.. must support some kind of fuel and must be painted in some color, however, not every car is obligated to have an airbag. OR-features and XOR-features are identified by an arc which groups them together. An black arc represents a set of OR-features, while an empty arc represents a set of XOR-features. In the example shown in Figure 2.4, cars are allowed to support, as fuel, either only gasoline, only ethanol, or both. A car can, however, be painted in only one color: blue, black or red. The feature diagram from Figure 2.4 was created in Captain Feature [4], an multi-platform tool for modeling features and drawing feature diagrams. Although feature diagrams are useful to provide a graphical visualization for the features (commonalities and variabilities) of a SPL and their relationships, the graphical elements from the diagram are not able to specify every possible relationships constraints. When more complex constraints are necessary, they are usually specified as a complement to the diagram in natural language, or in a constraint specification language which allows automated checking. 2.2. TECHNIQUES FOR IMPLEMENTING VARIABILITIES IN SOFTWARE PRODUCT LINES. In the previous section, we introduced the concept of SPLs and how the variabilities interact among them in a SPL context. In this section, we focus on presenting some of the most relevant technologies to deal with variabilities at the implementation artifacts of a SPL. Components in a SPL context are usually more complex than components developed for a single software product. They must support a higher level of generalization than it is used in common systems engineering. These components should also be easily adapted to fit in the context of different software products. The objective of this section is not to provide a detailed description of each technique, but to briefly introduce their concepts and to discuss how they support the implementation of variabilities. These techniques are presented in the next subsections..

(36) 12. BACKGROUND. 2.2.1. Conditional Compilation. Conditional compilation, or code preprocessing is one the most elementar, yet most powerful, techniques to enable variabilities in implementation artifacts. When using this technique, the blocks of source code related to a variability are enclosed by special preprocessor directives. The source code artifacts which contain these directives must be preprocessed before they can be compiled. For the purposes of this work, we have used Antenna [1], a set of Ant [2] tasks suitable for developing J2ME applications. Antenna provides, among other features, a source code preprocessor. Antenna preprocessor provides a set of directives which support variability in source code. The most important are [1]: #ifdef [identifier] The identifier represents a variable, which can be related to a variability. This directive checks whether or not the variable is defined. If true (the variable is defined), the code that follows is processed. Nested blocks are processed as well. If false (the variable is not defined), the code that follows is commented and nested blocks are not evaluated. The directive must be closed with #endif; #ifndef [identifier] Similar to the previous directive, but the condition is evaluated to true if the identifier is not defined; #elifdef [identifier] Works as a standard else if statement for ifdef/ifndef blocks. Can only be used inside blocks started by ifdef/ifndef; #elifndef [identifier] Similar to the previous directive, but the condition is evaluated to true if the identifier is not defined; #if [expression] Works similar to the ifdef directive, however evaluates an expression instead of a single identifier. It also must be closed with endif; #elif [expression] Works as a standard else if statement and can complement only in blocks started by an if statement; #else Works as a standard else statement only preprocesses the code that follows when none of the previous conditions in the defining block were true. Complements inside any block started with the if/ifdef/ifndef directive; #endif Must be used to close any block started with if/ifdef/ifndef.. Listing 2.1 shows an example where an optional feature is implemented with Antenna’s source code preprocessor. The class in the example represents a bank account. The blocks of source code which are enclosed by preprocessor directives implement an feature which notifies clients (by e-mail or SMS) every time a debit or credit operation is performed in their bank accounts. The N OT IF Y CLIEN T S symbol is associated with this optional feature. The ifdef tags in lines 15, 24 and 29 (in conjunction with their endif enclosing directives) ensure that the blocks of code which belong to this feature will only be considered during the compilation step if the N OT IF Y CLIEN T S symbol is defined.

(37) 2.2 TECHNIQUES FOR IMPLEMENTING VARIABILITIES IN SOFTWARE PRODUCT LINES. 13. during the code preprocessing step. Notice that preprocessor directives dot not depend on any structure of the Java language, and thus be used to implement variabilities at any location in the source code. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33. public c l a s s Account { private long number ; private double b a l a n c e ; private C l i e n t c l i e n t ; public Account ( long number , C l i e n t c l i e n t ) { t h i s . number = number ; this . balance = 0 ; this . c l i e n t = c l i e n t ; } public void c r e d i t ( double v a l u e ) { balance = balance + value ; //#i f d e f NOTIFY CLIENTS t h i s . n o t i f y C l i e n t ( ” C r e d i t O p e r a t i o n : ”+ v a l u e ) ; //#e n d i f } public void d e b i t ( double v a l u e ) { i f ( b a l a n c e >= v a l u e ) { balance = balance − value ; } //#i f d e f NOTIFY CLIENTS t h i s . n o t i f y C l i e n t ( ” Debit O p e r a t i o n : ”+ v a l u e ) ; //#e n d i f } //#i f d e f NOTIFY CLIENTS private void n o t i f y C l i e n t ( S t r i n g message ) { [...] } //#e n d i f } Listing 2.1 Conditional compilation example.. As the conditional compilation technique is based on tagging the implementation artifacts with meta-information, which is independent from the actual compilation of the artifact, it shows itself as a very powerful tool for implementing variabilities in a SPL. Conditional compilation can be used to implement complex variabilities, and yet result in zero overhead in the resulting applications. This technique, however, has its drawbacks. The first is that, as the preprocessor must take place just before the compiler, the variabilities implemented with this technique must be decided at compile-time. Another drawback is that this technique provides.

(38) 14. BACKGROUND. no modularity for the variability implementation. The implementation of the variability is not confined in a set of modules dedicated to this special purpose, but rather spread throughout other implementation artifacts, which imposes difficulties to the understanding of the implementation of the variability and maintenance activities related to this variability. Moreover, the overall understanding of the source code of the SPL can be compromised, specially when many variabilities are implemented with this technique and when many cases of interaction among these variabilities occur - which result in nested ifdefs in the implementation artifacts. In spite of these drawbacks, this technique is heavily used in operating systems and embedded systems domains, as application of these domais have to deal with strong resources restrictions and the conditional compilation technique usually results in no memory and processing overheads to handle the variabilities. 2.2.2. Inheritance and Mixins. Inheritance is a mechanism provided by languages of the object-oriented paradigm. This mechanism allows specialized classes (subclasses) to refine the structure and behavior of more general classes (parent classes). These refinements can define new attributes and operations and also redefine the behavior of some operations that already existed in the parent class (method override). Programmers of the object-oriented paradigm often see inheritance as mechanism to provide code reuse. If two or more classes have some common behavior or structure, this commonality can be placed in an abstraction (parent class) which theses classes can refine. Positive variabilities fits well in this context. They can be implemented as refinements of classes, adding the necessary behavior and structure to deal with each variability. As instances of a subclass can be used in contexts where instances of a parent class is expected, the rest of the program do not need to be modified. Also, in most objectoriented languages, a method call can be late bound to an object at run-time. This mechanism is known as dynamic binding or virtual methods, and allows variabilities to be decided at run time. The decision of the variability is done by instantiating the correct class. Some object-oriented design patterns like Factory Method and Abstract Factory can be used to handle this variability in class instantiation [34]. Negative variability can not be addressed well with inheritance technique. The restriction that instances of subclasses should be able to substitute instances of their parent classes in any context, imposes that structure and behavior can be added, but not removed when refining classes. This restriction is often referred to as Liskov substitution principle [46]. This is a high desirable property of object-oriented programs, even if it is not enforced by the programming language. Consider a scenario where a programmer creates a class A, which represents an ordered list of elements. Other programmers could use instances of class A with the assumption that it preserves the order of the elements which are inserted. Now, consider that the same programmer creates a class B, which refines A (B is a subclass of A) and do not preserve the ordered list constraint. Note that as B is a subclass of A, instances of B can be used in contexts where instances of A are expected. If an instance of B is used in a context where instances of A are expected and.

(39) 2.2 TECHNIQUES FOR IMPLEMENTING VARIABILITIES IN SOFTWARE PRODUCT LINES. 15. Figure 2.5 Inheritance technique used to define specializations.. the context depend on the assumption that this instance would preserve the order of the elements, the program would be incorrect, because this assumption is broken in class B. Negative variability can be implemented using inheritance technique by overriding some methods in the subclasses. By using method override, it is possible to cancel the behavior of some method, by just leaving the new definition of the method with an empty body, or by implementing some new functionality which breaks some pre or post conditions of the overridden method. Inheritance can be used to implement both optional and alternative features. The most simple form of inheritance, single inheritance, allows each subclass to have a maximum of one parent class, whereas the latter can be refined by an arbitrary number of subclasses. Thus, one (optional) refinement can be defined for a class, as well as many (alternative) refinements. The fact that single inheritance allows only one parent class per subclass, however, has an impact when it is necessary to compose two or more refinements. Consider the Car product line example we have discussed in Section 2.1.2. Suppose that a car is specified in a class named Car which abstracts what type of fuel is used by the car’s engine. Cars which support Gasoline or Ethanol as fuel can be defined as specializations (subclasses) of the Car class, GasolineCar and EthanolCar classes 1 . A UML (Unified Modeling Language) class diagram [33] for this example is shown in Figure 2.5. This single example can be easily accomplished using a single inheritance mechanism. Now, suppose that we want to specify cars which support both gasoline and ethanol as fuel. To implement this new specialization of car with single inheritance, a developer would define a new subclass, GasolineAndEthanol class which refines Car class directly. This schema is shown in Figure 2.6. The main problem of this approach is that, although GasolineAndEthanol class is a semantic composition of GasolineCar and EthanolCar 1. We have omitted other features to simplify the discussion..

(40) 16. BACKGROUND. Figure 2.6 Feature composition implemented with single inheritance.. classes, it is impossible to define a class which inherits the structure and behavior from both GasolineCar and EthanolCar classes at the same time. The consequence of this limitation is source code replication. Part of the refinements defined in GasolineCar and EthanolCar classes would have to be repeated in GasolineAndEthanol class. In this example, we have considered only a single composition of two features, in order to show the problem. This scenario can get even worse if we consider compositions of multiple optional features. The single inheritance mechanism does not scale well to feature compositions at classes level, so another solution is required. On possible solution is to use multiple inheritance. Multiple inheritance allows subclasses to extend directly from more than one parent class and thus, allow a feature composition to be define as refinement of two or more classes (a subclass with two or more parent classes). This approach avoids source code replication, since structure and behavior is inherited in the composition class from the two or more parent classes. Figure 2.7 shows how GasolineAndEthanol class can be defined as a composition of GasolineCar and EthanolCar classes using multiple inheritance. Multiple inheritance solves the feature composition problem but creates new problems, such as ambiguities that arise when a clash occurs in the names of attributes or operations inherited from different parent classes2 and the lack of a standard semantics [19]. One alternative to multiple inheritance is to use mixins based inheritance. Mixins allows features composition at the class level in a scalable way and avoid some of the problems of multiple inheritance [19]. Mixins often are implemented using a technique called linearization which is much simpler than multiple inheritance. For the purposes of this work, we used the mixins mechanism of CaesarJ [15] programming language. A deeper discussing about the semantics of mixins and how they avoid the problems of multiple inheritance are out of the scope of this work. In the next section, we discuss delegation, a technique which is often used in association with inheritance. 2. Often referred to as the diamond problem..

(41) 2.2 TECHNIQUES FOR IMPLEMENTING VARIABILITIES IN SOFTWARE PRODUCT LINES. 17. Figure 2.7 Feature composition implemented with multiple inheritance or mixins.. 2.2.3. Delegation. In this technique, the developer removes variabilities from the classes which implement the commonality and place them in specific classes. The classes from which the variabilities were removed hold references to objects which are able to deal with specific variations. When a code related to some variation (optional or alternative) needs to be executed, the class calls the associated operation from the variability object, that is, it delegates the variability to another object. In object-oriented programs, delegation is often used in association with inheritance. The classes which implement the commonality base hold referentes to objects which implement optional or alternative variabilities. Often, an abstract data type is used to declare these references and the correct objects are instantiated at run-time. One classic example of delegation and inheritance techniques being used together to implement variabilities is the Strategy design pattern [34]. 2.2.4. Aspect-Oriented Programming. Aspect-oriented programming (AOP) was proposed as a solution to the problem of implementing crosscutting concerns [40]. Crosscutting concerns are functional or nonfunctional characteristics of a program whose implementations are naturally spread throughout the program’s source code. They can not be implemented using traditional objectoriented techniques in a modular way. Classical examples of crosscutting concerns are:.

(42) 18. BACKGROUND. logging, persistence control, concurrency control and transaction control. Two problems arise when crosscutting concerns are implemented using only objectoriented techniques: scattering and tangling. We say that the implementation of a concern in scattered when it is present in many modules of a system, that is, many modules contribute to the implementation of this concern. In addition to that, the implementation of may concerns can be tangled in a module, that is, source code lines related to different concerns are interleaved in the same module. Tangling and scattering difficult the understanding of programs and make maintenance activities harder. It also becomes very difficult to enable specific concerns at compile-type or even at run-time, as required in a SPL infrastructure. Aspect-oriented languages support two concepts: quantification and obliviousness [31]. Crosscutting concerns are defined apart from the other concerns (base code) in specific modules (often called aspects). These modules can define new a behavior which affects the base code in many different points (quantification). Also, the base code is often oblivious to the existence of these modules (aspects). AspectJ [44] is an aspect-oriented extension to Java. Programming with AspectJ involves both aspects and classes to separate concerns. Concepts that are well defined with object-oriented constructs are implemented in classes. Crosscutting concerns are usually separated using units called aspects, which are integrated with the classes through a process called weaving. Thus, an AspectJ application is composed of both classes and aspects. Therefore, each AspectJ aspect defines a functionality that affects different parts of the system. Aspects may define pointcut designators (or pointcuts for short), advices, and intertype declarations. Pointcut match join points, which are a set of points during program execution flow, where we may want to execute a piece of code. Code to be executed at join points matched by pointcuts is declared as an advice. Intertype declarations are structures that allow introducing fields and methods into a class, changing the hierarchy of a type (making a class extend another class or implement an interface), and turning checked exceptions into unchecked exceptions. AspectJ language enables the implementation of crosscutting variabilities in a SPL. It also makes the variability decision mechanism easier. Once the aspects are created, they can be added or not during or after the compilation of the program, using the AspectJ weaver. Standard AspectJ supports weaving only before the program is loaded into the virtual machine, and once an aspect is weaved into the a program, this process can not be undo. This is a restriction of the current AspectJ weaver, though. It is not limitation of the AOP paradigm. Remind the example introduced in Section 2.2.1, when we discussed conditional compilation. The implementation of the client notification concern were tangled with other concerns in Account class. With AOP, it is possible to define this concern in a single aspect. Listing 2.2 shows the implementation of the referred example using AspectJ. Aspect NotifyClients implement the discussed concern by defining two advices and one inter-type declaration. 1 public c l a s s Account { 2 private long number ; 3 private double b a l a n c e ;.

(43) 2.2 TECHNIQUES FOR IMPLEMENTING VARIABILITIES IN SOFTWARE PRODUCT LINES. 19. 4 private C l i e n t c l i e n t ; 5 6 public Account ( long number , C l i e n t c l i e n t ) { 7 t h i s . number = number ; 8 this . balance = 0 ; 9 this . c l i e n t = c l i e n t ; 10 } 11 12 public void c r e d i t ( double v a l u e ) { 13 balance = balance + value ; 14 } 15 16 public void d e b i t ( double v a l u e ) { 17 i f ( b a l a n c e >= v a l u e ) { 18 balance = balance − value ; 19 } 20 } 21 } 22 23 a s p e c t N o t i f y C l i e n t s { 24 a f t e r ( Account account , double v a l u e ) : 25 e x e c u t i o n ( void Account . c r e d i t ( double ) ) 26 && t h i s ( a c c o u n t ) && a r g s ( v a l u e ) { 27 a c c o u n t . n o t i f y C l i e n t ( ” C r e d i t O p e r a t i o n : ”+ v a l u e ) ; 28 } 29 30 a f t e r ( Account account , double v a l u e ) : 31 e x e c u t i o n ( void Account . d e b i t ( double ) ) 32 && t h i s ( a c c o u n t ) && a r g s ( v a l u e ) { 33 a c c o u n t . n o t i f y C l i e n t ( ” Debit O p e r a t i o n : ”+ v a l u e ) ; 34 } 35 36 private void Account . n o t i f y C l i e n t ( S t r i n g message ) { 37 [...] 38 } 39 } Listing 2.2 AOP Example. See that the source code of Account class is oblivious to the existence of NotifyClients aspect. It should be noticed, however, that simple refactorings in Account could break NotifyClients aspect. In a ideal scenario, one programmer should be able to develop Account class, at the same time that another programmer develops NotifyClients aspect, without communicating. In that way, the programmer responsible for Account class would be oblivious to the existence of any aspect affecting this class. And both artifacts, Account and NotifyClients, could evolve independently. This scenario, however, is not possible because AspectJ’s constructs dependent on syntactic elements of the the base.

(44) 20. BACKGROUND. code. So, although there is no syntactic reference in a classes to aspects, these two elements can be semantically coupled [50]. One solution to this problem is to define interfaces between aspects and classes, as proposed by some researchers [58, 41, 35]. Quantification is supported by AspectJ’s pointcut model. It is possible to define advices which affects many joinpoints in a program. Although this is a clear benefit of AspectJ, it can also cause some problems. If quantification is not used carefully it can lead to advices that affects more joinpoints than it is desirable, resulting in incorrect programs. Some approaches were proposed to tame the power of AspectJ’s pointcuts [9, 17]. Other extensions to the Java language provide aspect orientation. ABC [16] is an open an highly customizable AspectJ compiler which allows developer to easily extend the base AspectJ language by creating new joinpoints, adding new constructs to the language or optimizing the weaving process. In [47], an extension to ABC is proposed to optimize the weaving process, reducing the overhead on the size of the resulting application and offering opportunities for other obfuscation tools to make further optimizations. In this work, we have used this extension, since we examine the mobile games domain, in which the size of the deployed application is a very important issue. CaesarJ [3] is another AOP extension to Java. It supports AspectJ’s pointcuts and advices constructs but do not support inter-type declarations. It also support some advanced features, like mixins, virtual inner classes and wrappers [15]. 2.2.5. Program Transformations. Program transformation systems can also be used to implement variabilities in a SPL. They are able to describe complex variability patterns, even crosscutting ones. They can also be used to implement variabilities in different levels of granularity, ranging from a single line of source code to the package or component level. Program transformation systems can be language dependent or independent. In addition to the fact that they can be used in conjunction with any programming language, language-independent program transformation systems can be used to implement variabilities of any granularity, since they are not restricted by a set of language constructs. One example of a language independent transformation system is XVCL (XML-Based Variant Configuration Language) [37]. On the other hand, language-specific program transformation systems can explore a set of language constructs in order to specify transformations in a more clean and safe way. One example of a language-specific program transformation system is the Java Transformation System (JaTS) [6], which is designed for the Java programming language. JaTS transformations are written in a language that extends Java with JaTS constructs. The goal of the constructions is to allow type (class or interface) matching and the specification of new types that are to be generated. A JaTS transformation consists of two parts: a left-hand side (matching template) and a right-hand side (replacement template). Both sides consist of one or more type declarations written in JaTS. The left-hand side of a transformation is matched with the source Java type being transformed, which implies that both must have similar syntactic structures. The right-hand side defines the type that will be produced by the transformation..