PhD-FSTC-2017-39 The Faculty of Sciences, Technology and Communication DISSERTATION Defense held on 21/07/2017 in Luxembourg to obtain the degree of DOCTEUR DE L’UNIVERSITÉ DU LUXEMBOURG EN INFORMATIQUE by Benjamin BEHRINGER Born on 9 July 1984 in Essen (Germany) PROJECTIONAL EDITING OF SOFTWARE PRODUCT LINES– THE PEOPL APPROACH Dissertation defense committee Dr Steffen Rothkugel, Dissertation Supervisor Associate Professor, Université du Luxembourg Dr Thorsten Berger Assistant Professor, University of Gothenburg and Chalmers University of Technology Dr Denis Zampunieris, Chairman Professor, Université du Luxembourg Dr Ina Schäfer Professor, Technische Universität Braunschweig Dr Martina Lehser, Vice Chairman Professor, Hochschule für Technik und Wirtschaft des Saarlandes (host institution) Benjamin BEHRINGER: Projectional Editing of Software Product Lines— The PEoPL Approach, © July 2017 ABSTRACT The features of a software product line—a portfolio of system variants—can be realized using various variability implementation techniques. Each technique represents a feature’s software artifacts (a.k.a. feature artifacts) differently, typically classified into anno- tative and modular variability representations, each with distinct advantages and disadvantages. Annotative representations, such as C preprocessor annotations, are easy to apply, but clutter source code and hinder program comprehension. Modular representations, such as feature modules, support comprehension, but are difficult to realize. Most importantly, to engineer feature artifacts, developers need to choose one representation and adhere to it for evolving and maintaining the same artifacts. We present the approach PEoPL (Projectional Editing of Product Lines), which combines the advantages of different variability rep- resentations. When engineering a feature artifact, developers can choose the most-suited representation for the given task, switch representations on demand, and even use different representations in parallel. PEoPL relies on separating a product line into an in- ternal and external representation, the latter by providing editable projections used by the developers. In summary, we contribute a programming-language-independent internal representation of variability, seven editable projections re- flecting different variability representations (e.g., annotative, modu- lar, variant-specific, reuse-specific), facilities for modeling, analyzing and managing variability, a supporting IDE, and a tailoring of PEoPL to Java and fault trees. We evaluate PEoPL using three different methodologies. First, we classify PEoPL using a well-defined set of quality criteria along with other implementation techniques, finding that PEoPL provides a novel engineering flexibility, and that the approach is indeed desirable. Second, we evaluate PEoPL’s practicality, scalability, and flexibility in eight Java-based product lines, finding that all can be realized, projections are feasible, and that variant computation is fast (<45ms on average for our largest subject Berkeley DB). Third, to learn more about PEoPL’s practicality and usability, we conduct two pilot user studies, finding that the approach is usable, and that switching representations is useful. We conclude that PEoPL is ready for real users. iii ACKNOWLEDGEMENTS Pursuing a PhD was a challenging and exciting endeavour that would not have been possible without the people who supported me in many different ways. While the PEoPL approach is my own original idea, realizing a proof of concept of PEoPL’s size and complexity required the help and dedication of other people. So, first and foremost, I want to thank my friends in the PEoPL team. I thank Jochen Palz, who contributed substantially to PEoPL’s implementation. Jochen was always support- ive during my numerous I-have-a-new-nice-idea-let’s-implement-it- now episodes and spent sleepless nights with me over fixing this and that, especially, when a deadline was close. I also thank Moritz Fey, who joined the PEoPL team as a bachelor’s student and contributed to several parts of PEoPL’s implementation and the analysis of data ever since (e.g., pilot user studies). Moreover, I thank Thomas Mechen- bier, who helped me with the variational fault tree implementation. I also want to thank Thorsten Berger for his highly valuable sup- port, feedback, and guidance. Thorsten was always open for my ideas and substantially helped me shape my research. His commitment to details influenced the way I think and deal with problems. It is always a great pleasure to collaborate with Thorsten. I want to express my deepest gratitude to Martina Lehser for her versatile support. Martina encouraged me to pursue a PhD, provided me with an excellent environment, guaranteed me unrestricted free- dom, and supported me financially to build the PEoPL group. It was a great experience to be able to explore and find an interesting re- search topic on my own in such a supportive environment. I am very grateful to Steffen Rothkugel for giving me the chance to pursue my PhD in his group. Although our collaboration was mainly remote, Steffen always found the time to discuss my research with me. I admire his structured thinking, presentation skills and work ethics. Steffen had a great impact on the researcher I am today. Moreover, I thank Nicolas Navet, who was one of my CET members. Nicolas gave me valuable feedback on my research ideas. I would also like to thank Ina Schäfer and Denis Zampunieris for joining my dissertation defense committee. I am grateful to all the colleagues at the htw saar and the University of Luxembourg with whom I had the pleasure to collaborate and discuss my research, including Eric Wagner, Christoph Karls, Michael Sauer, Sarah Theobald, Mario Korherr, Jean Botev, Laurent Kirsch, and Johannes Klein. Moreover, I thank all students I had the pleasure to work with during my lectures and user studies. Their feedback iv was very valuable to me. I decided not to list names hoping that the students in question will know. I also like to thank all the participants of the 2016 FOSD meeting, which was held at the IT University of Copenhagen. It was a very fruitful event that helped me initiate new collaborations and eventu- ally shape my work. I thank Maria Rupprecht for taking the time to proofread my dis- sertation. Last but not least, I want to thank Ele, who made numerous sacri- fices and often saw me hunched over my work. “As distance tests a horse’s strength, so time reveals a person’s heart”—Chinese proverb. v CONTENTS ithe(in)flexibility of variability engineering 1 1introduction 2 1.1 PEoPL Overview . 3 1.2 Contributions . 5 1.3 Reading Guide and Outline . 7 1.4 Publications . 9 2engineeringvariabilityinclassicalapproaches10 2.1 Process of Engineering and Managing Variability . 10 2.2 Configuring Variability . 11 2.3 Modeling Variability . 12 2.4 Implementing Variability . 14 2.4.1 Overview of Implementation Approaches . 14 2.4.2 Annotative Representations . 16 2.4.3 Modular Representations . 22 2.4.4 Variant Representations . 28 2.5 Challenges Caused by Variability . 29 2.5.1 Challenge I: Implementation . 29 2.5.2 Challenge II: Comprehension . 31 2.5.3 Challenge III: Maintenance and Evolution . 35 2.6 Concluding Remarks . 36 ii engineering and managing variability in peopl 37 3implementingvariability: peopl’sflexibility 38 3.1 PEoPL’s Core Idea: An Overview . 38 3.2 PEoPL’s Benefits: Addressing the Challenges . 39 3.3 Projections I: Variability Representations . 41 3.3.1 Textual Annotation Projection . 42 3.3.2 Visual Annotation Projection . 42 3.3.3 Feature Module Projection . 45 3.3.4 Blending Annotation and Module Projections 45 3.3.5 Variant Projection . 46 3.3.6 Fade-in Feature Module Projection . 47 3.3.7 Reuse Projection . 48 3.4 Projections II: Non-Code Feature Artifacts . 50 3.4.1 Variational Mathematical Formulas . 50 3.4.2 Variational Fault Trees . 51 3.5 Projections III: Variability-aware File Explorers . 57 3.6 Concluding Remarks . 58 4modelingandmanagingvariability 59 4.1 Product Line Setup and Variant Derivation . 59 4.1.1 Simple Product Line Declaration . 59 vi contents vii 4.1.2 Advanced Product Line Declaration . 60 4.2 Product Line Correctness . 63 4.2.1 Artifact-related Feature Dependency Analysis 63 4.2.2 Variant-based Data-Flow Analysis . 64 4.3 Concluding Remarks . 65 5evaluationi: the product line engineer’sview 66 5.1 Classification I: Comparing Techniques and Tools . 66 5.1.1 Preplanning Effort . 67 5.1.2 Adoption . 68 5.1.3 Variability Implementation Flexibility . 69 5.1.4 Uniformity . 70 5.1.5 Granularity . 71 5.1.6 Modularity . 71 5.1.7 Feature Traceability . 72 5.1.8 Information Hiding . 73 5.1.9 Expressive Power . 73 5.1.10 Homogeneous Extensions . 74 5.1.11 Variant Editing . 75 5.2 Case Studies . 76 5.2.1 Objectives . 76 5.2.2 Case Study Subjects . 76 5.2.3 Investigation . 77 5.2.4 Threats to Validity . 80 5.2.5 Lessons Learned . 81 5.3 Pilot User Studies . 82 5.3.1 Objectives . 82 5.3.2 Participants and Study Format . 83 5.3.3 Material and Tasks . 84 5.3.4 Method and Analysis . 86 5.3.5 Results . 86 5.3.6 Threats to Validity . 91 5.3.7 Interpretation and Lessons Learned . 92 5.3.8 Future Research Questions . 95 5.4 Concluding Remarks . 95 iii realizing peopl using language engineering 96 6peopl’stoolingandarchitecture 97 6.1 Why and How PEoPL Uses a Language Workbench . 97 6.2 The MPS Language Workbench . 98 6.2.1 Structure . 99 6.2.2 Editor . 101 6.2.3 Generator . 102 6.3 An Overview on PEoPL’s Architecture . 102 6.3.1 Internal Variability Representation . 104 6.3.2 External Variability Representation . 104 6.3.3 Variability Management Facilities . 104 contents viii 6.3.4 Extras . 104 7peopl’sinternalvariabilityrepresentation 105 7.1 CoreVar’s Language Structure . 105 7.1.1 Variability Formalism . 105 7.1.2 Variational AST Formalism .