The Road to Feature Modularity?
Total Page：16
File Type：pdf, Size：1020Kb
The Road to Feature Modularity? [Discussion Paper] Christian Kästner Sven Apel Klaus Ostermann Philipps University Marburg University of Passau Philipps University Marburg ABSTRACT tation locally, and to compose them flexibly. In contrast, Modularity of feature representations has been a long stand- others have repeatedly challenged that many contemporary ing goal of feature-oriented software development. While forms of feature-oriented programming provide merely syn- some researchers regard feature modules and corresponding tactic compositions, lack proper interfaces, and provide only composition mechanisms as a modular solution, other re- closed-world reasoning. searchers have challenged the notion of feature modularity We led numerous heated discussions and found that dif- and pointed out that most feature-oriented implementation ferent people have very different assumptions of what to mechanisms lack proper interfaces and support neither mod- expect from modularity, which is also enforced by different ular type checking nor separate compilation. We step back notions of modularity in different communities. We distin- and reflect on the feature-modularity discussion. We distin- guish a notion of cohesion and locality often found in the guish two notions of modularity, cohesion without interfaces software-engineering community and a notion of informa- and information hiding with interfaces, and point out the tion hiding using interfaces currently coming more from the different expectations that, we believe, are the root of many programming-languages community. In our understanding, heated discussions. We discuss whether feature interfaces the major part of the community around feature-oriented should be desired and weigh their potential benefits and software development focuses on cohesion and neglects infor- costs, specifically regarding crosscutting, granularity, feature mation hiding and interfaces. interactions, and the distinction between closed-world and Behind the discussion of modularity is lurking another open-world reasoning. Because existing evidence for and discussion about taking an open-world view or a closed-world against feature modularity and feature interfaces is shaky view on features. In an open-world view not all features and inconclusive, more research is needed, for which we are necessarily known, whereas, in a closed-world view, we outline possible directions. globally reason about a closed set of feature implementations. How suitable are open-world and closed-world views for Categories and Subject Descriptors: D.2.2 [Software]: applications such as software product lines? Software Engineering—Design Tools and Techniques; D.3.3 In this discussion paper, we share and discuss our current [Software]: Software Engineering—Language Constructs understanding of this debate. Although we aimed at a neutral and Features view, we cannot avoid bias from our own background, which certainly shaped much of this paper. Although not intended General Terms: Design, Languages as retrospect justification, our discussion can be interpreted as such. Hence, we are open about our bias: The first Keywords: modularity, interfaces, module systems, vari- two authors have a background rooted in the locality and ability, granularity, crosscutting, feature interactions, feature cohesion notion, increasingly learning to appreciate other modules, feature models notions, whereas the third author has a background rather rooted in the programming-languages community and has a 1. INTRODUCTION more critical view on lacking interfaces. Over the last years, we have frequently discussed what mod- Although we cannot present a general solution for feature ularity means for feature-oriented software development. We modularity—we are not even entirely convinced that feature and others have typically claimed that we want to modu- interfaces should be a dominating goal—we discuss challenges larize feature representations to make features explicit in (especially fine granularity and feature interactions) and design and implementation, to reason about their implemen- possible research directions. Most insights are not new in isolation, but we hope to contribute a personal view on the debate that we gathered over several years. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are 2. FEATURE MODULARITY not made or distributed for profit or commercial advantage and that copies So what is feature modularity? Already the term modularity bear this notice and the full citation on the first page. To copy otherwise, to is so overloaded with different definitions and interpreta- republish, to post on servers or to redistribute to lists, requires prior specific tions that it seems infeasible to extract one general meaning. permission and/or a fee. SPLC’11 August 21-26, 2011, Munich, Germany. Hence, we explore two different notions of feature modularity Copyright 2011 ACM 978-1-4503-0789-5/11/08 ...$10.00. (and probably bluntly forget others): one based on cohesion Feature module Base and one based on information hiding. But first, we need to clarify what kind of feature representations we are discussing. 1 class Stack { ... 2 void push(int v) {/*...*/} 3 int pop() {/*...*/} 2.1 Representing features 4 } There are different views on what a feature is and how it Feature module Top manifests in a program. In previous work on feature-oriented 1 refines class Stack { languages and tools, researchers view features mostly from 2 int top() {/*...*/} a syntactic or structural perspective: When added to a 3 } program, a feature manifests in additions or modifications of development artifacts [5]. Hence, such work focuses on Feature module Undo the representation of features in the sense of concerns in 1 refines class Stack { ... 2 int backup; design documents and implementations. Interesting issues 3 void undo() {/*...*/} that arise from this view are how to arrange a code base 4 void push(int v) { such that features become explicit and composable. 5 backup=top(); 6 original(v); //calling push of Base At the same time, there is an alternative perspective on 7 } features, inspired by early work on feature-interaction de- 8 } tection in telecommunication systems: Features are viewed in terms of the behavior they induce. They are semantic units that interact and give rise to the observable behavior Figure 1: AHEAD-style feature-oriented implemen- a user is interested in [28, 30, 34]. The code structures that tation of a stack with three feature modules. implement a feature are of less interest in this perspective. The two perspectives are two sides of the same coin, both We believe that, for many tasks, locality and cohesion encourage abstraction, but both emphasize different proper- provide a significant advantage compared to implementations ties. Here we take side with the syntactical and structural of a feature in which feature code is scattered across the perspective, as it guided our research for many years. Of code base and tangled with code of other features. Locality course that does not mean that the semantic perspective is and cohesion help developers to get an overview and to less important; nevertheless, we address the issue of modu- focus their attention when maintaining source code. For larity from our perspective. example, in annotative approaches [39]—such as using #ifdef directives of the C preprocessor to mark scattered feature 2.2 Locality and cohesion implementations—we need to perform a global search to The core idea of feature-oriented programming was to use find all fragments of a feature. (It is this context in which features as an additional dimension of decomposing a pro- we argue that views as in FeatureMapper [31], C-CLR [65], gram [60] (as addition, not as replacement for other forms CIDE [38], and others provide a virtual separation of concerns of decomposition using packages, classes, methods, abstract and emulate locality and cohesion, cf. [38, 39].) data types, functions, and so forth). When decomposing a program into features, the individual parts are typically called 2.3 Information hiding feature modules [11]. Seminal papers on feature-oriented pro- Information hiding and encapsulation, enforced with inter- gramming claim that feature-oriented programming “allows faces and typically associated with module systems, are to compose objects from individual features or abstract sub- another side of modularity, typically emphasized in the classes in a fully flexible and modular way” [60] and that “fea- programming-language community.2 The idea behind in- ture refinements are modular, albeit unconventional, building formation hiding and encapsulation is to distinguish between blocks of programs” [11]. an internal and an external part of a module. The internal In this context, a feature module is regarded as a unit part is hidden (encapsulated) from other modules. The exter- of composition (and often as a transformation that applies nal part is called an interface (described more or less formally changes to other features [11, 51]). Decomposing a program in different contexts) and describes a contract with the rest into feature modules has the goal of making features explicit of the world. The contract enforces the desired abstraction in design and implementation. Modularity in this context and corresponding invariants. To understand a module, we means locality and cohesion. The idea is to place everything need to look only at the module itself and at (imported) related