
Principles of Feature Modeling Damir Nešić Jacob Krüger Ştefan Stănciulescu Thorsten Berger Royal Institute of Otto-von-Guericke ABB Corporate Research Chalmers | University of Technology University Baden-Dättwil Gothenburg Stockholm, Sweden Magdeburg, Germany Switzerland Gothenburg, Sweden ABSTRACT 1 INTRODUCTION Feature models are arguably one of the most intuitive and success- Software product lines are portfolios of system variants in an appli- ful notations for modeling the features of a variant-rich software cation domain. They are typically engineered as an integrated soft- system. Feature models help developers to keep an overall under- ware platform that exploits the commonality and manages the vari- standing of the system, and also support scoping, planning, develop- ability among the variants [21, 66, 78], to facilitate systematic soft- ment, variant derivation, configuration, and maintenance activities ware reuse, enhance maintenance, and reduce costs. However, pro- that sustain the system’s long-term success. Unfortunately, feature duct lines are inherently complex because they integrate the featu- models are difficult to build and evolve. Features need to beiden- res—many with complex dependencies—of all possible system vari- tified, grouped, organized in a hierarchy, and mapped to software ants [27, 30] in the codebase of one software platform. To handle this assets. Also, dependencies between features need to be declared. complexity, features need to be managed and, therefore, modeled. While feature models have been the subject of three decades of Feature models [11, 24, 46, 68], introduced almost three decades research, resulting in many feature-modeling notations together ago, are the most common and popular notation for modeling the with automated analysis and configuration techniques, a generic features of a software product line. Engineers use them to describe set of principles for engineering feature models is still missing. features and their dependencies in an intuitive, tree-like structure. It is not even clear whether feature models could be engineered Product-line users derive individual variants—represented by a using recurrent principles. Our work shows that such principles valid combination of features and their values—from the feature in fact exist. We analyzed feature-modeling practices elicited from model. To this end, feature models offer various modeling con- ten interviews conducted with industrial practitioners and from cepts, such as optional and mandatory features, a feature hierarchy, 31 relevant papers. We synthesized a set of 34 principles covering feature groups, and cross-tree constraints, as illustrated in a toy eight different phases of feature modeling, from planning over mo- example in Fig. 1 (explained in detail in Sec. 2). Feature modeling del construction, to model maintenance and evolution. Grounded is supported by major product-line engineering tools [5], such as in empirical evidence, these principles provide practical, context- pure::variants [15], Gears [53], and FeatureIDE [77]. Many resear- specific advice on how to perform feature modeling, describe what chers, practitioners, and tool vendors have introduced additional information sources to consider, and highlight common characte- concepts, such as feature attributes, feature cardinalities [6, 7, 25] ristics of feature models. We believe that our principles can support or non-propositional constraints [14, 65], thus gradually increasing researchers and practitioners enhancing feature-modeling tooling, the expressiveness of feature models. synthesis, and analyses techniques, as well as scope future research. Feature modeling has been intensively considered in research and applied in practice [9, 11, 59], as witnessed by over 5,000 ci- CCS CONCEPTS tations of the original publication on feature modeling [46], the • Software and its engineering → Software product lines; software-product-line community’s hall of fame (splc.net/hall-of- Software reverse engineering. fame), experience reports [74, 78], and textbooks [4, 21, 66, 78]. To complement feature-modeling tooling, researchers contribu- KEYWORDS ted hundreds of feature-model analyses [7, 63, 76], refactorings Feature models, modeling principles, software product lines and management techniques [1, 2], as well as automated synthe- sis techniques [3, 72]. Most feature models are created manually ACM Reference Format: Damir Nešić, Jacob Krüger, Ştefan Stănciulescu, and Thorsten Berger. 2019. Vehicle Legend: Principles of Feature Modeling. In Proceedings of the 27th ACM Joint Euro- Feature pean Software Engineering Conference and Symposium on the Foundations of Mandatory Brakes Engine feature Optional Software Engineering (ESEC/FSE ’19), August 26–30, 2019, Tallinn, Estonia. feature ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/3338906.3338974 Alterantive Regenerative Electric Hybrid Petrol features Cross-tree F →F Permission to make digital or hard copies of all or part of this work for personal or Electric→ Regenerative constraints 1 2 classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation ID Requirement Validity on the first page. Copyrights for components of this work owned by others than the #ifdef Regenerative_Braking 1 Top vehicle speed limited to 180km/h [All engines] author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or if (mode==AUTO) brake_force=estimateForce(); 2 Top vehicle speed is adjustable by [El. engine] republish, to post on servers or to redistribute to lists, requires prior specific permission #endif the driver and/or a fee. Request permissions from [email protected]. ESEC/FSE ’19, August 26–30, 2019, Tallinn, Estonia © 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM. Figure 1: A feature model (top) with representations of fea- ACM ISBN 978-1-4503-5572-8/19/08...$15.00 https://doi.org/10.1145/3338906.3338974 tures in code (bottom left) and requirements (bottom right). ESEC/FSE ’19, August 26–30, 2019, Tallinn, Estonia Damir Nešić, Jacob Krüger, Ştefan Stănciulescu, and Thorsten Berger and often in the context of re-engineering legacy variants into a valuable concepts is the feature hierarchy, as it structures features software product line [11]. and allows users to navigate in the model. Beyond such ontological Despite decades of research, there is only limited knowledge on semantics, feature models express the set of all possible variants how feature models are, or should be, designed in practice. Despite (configuration-space semantics) by using constraints as follows. numerous surveys, experience reports, and case studies [9, 11, 59], Feature Modeling Concepts. Features can be mandatory (e.g., there is no modeling methodology for feature models that could be Engine in Fig. 1) or optional (e.g., Regenerative) within a product used to systematically design feature models based on established line. Optional features can be enabled or disabled for individual practices. It is not even clear whether practices that have been repor- variants, subjected to further constraints. The feature hierarchy im- ted adhere to recurrent principles, and, if so, to what extent. We are poses constraints in the form of parent-child implications, mainly only aware of one, 20-years old selection of design guidelines based to prevent the selection of features that would not have any effect on individual author experiences [58]. A modeling methodology, or when the parent feature is not selected. Features can have types. at least a set of consolidated principles representing best practices, Most notations restrict features to Boolean, while others offer va- would not only help practitioners design feature models, but would rious types for features [12, 14, 71]. The original FODA notation also help the research community conceive better modeling tools, defined features as Boolean, but also defines the notion of feature processes, and to scope future research. attributes—dedicated variables associated with features for holding Our long-term goal is to establish a modeling methodology and non-Boolean values (e.g., integer, real values). Similarly to FODA, process for feature modeling. In this paper, we present a study of other feature-modeling notations have adopted the concept of fea- feature-modeling practices we identified from a systematic lite- ture attributes [7]. Whether non-Boolean values are useful typically rature review of 31 papers and ten interviews with experts who depends on the domain. In our example, all features have Boolean created feature models in small to ultra-large projects with several values. Feature groups impose constraints on the grouped features. thousands of features. By triangulating from these two sources, we OR and XOR groups are most common, while MUTEX groups are collected practices performed by practitioners, analyzed them, and rare [14]. Some notations have introduced arbitrary bounds (cal- synthesized them into 34 general feature-modeling principles orga- led group cardinalities) specifying the minimum and maximum nized into eight categories (modeling phases): preparation and plan- numbers of features that can be selected from a group. In our ex- ning, training, information sources, model organization, modeling, ample, the features Electric, Hybrid, and Petrol belong to an XOR dependencies, model validation, and maintenance and evolution.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages12 Page
-
File Size-