Mapping SPL Feature Models to a Relational Database
Total Page:16
File Type:pdf, Size:1020Kb
Mapping SPL Feature Models to a Relational Database Hazim Shatnawi∗ H. Conrad Cunningham University of Mississippi University of Mississippi Department of Computer and Information Science Department of Computer and Information Science University, Mississippi 38677 University, Mississippi 38677 [email protected] [email protected] ABSTRACT may vary in how those features are realized. To identify these com- Building a software product line (SPL) is a systematic strategy for monalities and variabilities, developers must analyze the domain reusing software within a family of related systems from some ap- to identify the organization’s business goals, the SPL’s scope, the plication domain. To dene an SPL, domain analysts must identify types of products to be developed, and the features of those prod- the common and variable aspects of systems in the family and cap- ucts. They often document the details of the feature analysis as a ture this information so that it can be used eectively to construct tree-structured feature model. A parent node represents a decision specic products. Often analysts record this information using a fea- in the design of a product. The children of that node represent more ture model expressed visually as a feature diagram. The overall goal detailed decisions for realizing the parent decision. The constraints of this project is to enable wider use of SPLs by identifying relevant among the nodes determine how valid products can be congured concepts, dening systematic methods, and developing practical in the SPL. tools that leverage familiar web programming technologies. This Feature models are represented in various ways in the litera- paper presents a novel approach to specication of feature models: ture. These include the FODA feature diagram [18] and several capture the details using automatically generated user interfaces, extensions [8, 12, 13, 16, 19, 27], special purpose languages [17, 33], encode the models in a relational database, and then validate the and formal models [4, 31]. However, these have one or more short- models and construct specic products using SQL. comings: some do not support automated analysis of SPLs or spe- cic product congurations; some focus on specic programming KEYWORDS languages; and some require the mastery of language, logic, or algebraic concepts unfamiliar to many programmers. Software product line, feature model, relational database, domain The overall goal of this project is to enable wider use of SPLs analysis, domain design, feature selection. by identifying relevant concepts, dening systematic methods, and ACM Reference format: developing practical tools that leverage familiar web programming Hazim Shatnawi and H. Conrad Cunningham. 2017. Mapping SPL Feature technologies. In Section 5, we present a novel approach to speci- Models to a Relational Database. In Proceedings of ACM SouthEast Conference, cation of feature models: encoding them in a relational database Kennesaw, GA, USA, April 2017 (ACMSE‘17), 8 pages. (RDB). An RDB separates the concept of a feature from its actual im- DOI: 10.475/123_4 plementation, which helps developers and clients to understand the feature model. We leverage the capabilities of the database query 1 INTRODUCTION language (SQL) to extract information about features and their re- Four decades ago Parnas observed that “software will inevitably lationships to validate the model and construct specic products. exist in many versions” [23]. Thus, a “software designer should be The database design also enables our tool to generate a web-based aware that he is not designing a single program but a family of user interface for product conguration. programs” [24]. He describes a software family as a set “of programs Before we present our approach, let us review relevant aspects whose common properties are so extensive that it is advantageous of software product lines, feature models, and relational databases. to study the common properties of the programs before analyzing 2 SOFTWARE PRODUCT LINES individual members” [23]. That is, developers should study the commonalities of the programs before studying their variabilities. According to the Software Engineering Institute (SEI), an SPL is These ideas underlie contemporary research on software product a “set of software-intensive systems sharing a common, managed lines [26]. set of features that satisfy the specic need of a particular market A software product line (SPL) in some application domain is a segment or mission and that are developed from a common set of set of related systems that share common software features but core assets in a prescribed way” [10]. A feature is a stakeholder- visible behavior of a software system [18]. Czarnecki and Eisenecke ∗Also with National Center for Computational Hydroscience and Engineering. [12] suggest making a feature visible not only helps the customer to understand the software, but it also helps domain engineers, Permission to make digital or hard copies of part or all of this work for personal or software engineers, and others in the development of the SPL. classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation SPLs focus on reusing domain knowledge [22]. A domain is an on the rst page. Copyrights for third-party components of this work must be honored. abstract space in which a set of related systems share common ter- For all other uses, contact the owner/author(s). minology, requirements, and design choices. An organization can ACMSE‘17, Kennesaw, GA, USA © 2017 Copyright held by the owner/author(s). 123-4567-24-567/08/06...$15.00 build reusable software assets that capture the detailed knowledge DOI: 10.475/123_4 specic to a certain domain area. Consider a company that develops ACMSE‘17, April 2017, Kennesaw, GA, USA Hazim Shatnawi and H. Conrad Cunningham Root D A C B excludes requires E FG H Figure 2: A feature model for a product line Figure 1: SPL development process A feature model documents the product line architecture result- ing from the domain analysis [18]. In traditional feature models, a software for banks. Instead of developing a unique banking system model is depicted as a tree that represents all design choices (i.e., for each client, the company can use its general knowledge of bank- features) as nodes and the constraints that one choice imposes on ing systems—the domain—to produce a family of similar systems others by various types of edges between the nodes. Based on the that share common core functionalities but that can be customized dened relationships among the features in the model, the prod- for specic clients. This family forms a software product line. uct line can generate a specic product by selecting a valid set Figure 1 shows the development of an SPL consisting of two pro- of features—a set of features that satises all the constraints (i.e., domain engineering application engineering cesses: and [1]. rules). Domain engineering is the process of analyzing a domain by study- A feature model captures the commonalties and variabilities by ing the stakeholders’ requirements, reviewing existing systems representing the primary relationships among features as a tree. domain analysis within the domain, and performing . The domain The root represents the entire product line. An edge between a analysis identies the types of products included in the SPL and parent and a child is a relationship between a high-level design identies the design choices that are common to the entire domain decision and a detailed design decision needed in its realization. and those that vary among the specic applications. These design Kang proposed feature models for use in the Feature-Oriented choices are implemented as software parts that represent the com- Domain Analysis (FODA) method [18]. Other researchers have mon and variable features of a product. In addition, the domain extended the feature modeling notation in various ways [12, 13, 16, analysis examines customers’ requests and decides whether to in- 19, 27]. tegrate these requests within the product line or just to implement In feature models, features are connected by two kinds of rela- them as custom features for specic requests. tionships: Application engineering is the process of delivering a product by selecting a valid set of features from the SPL and implementing • Relationships between parent and child features new customer requirements that are within the scope of the SPL. • Cross-tree inclusion or exclusion constraints between fea- Domain analysis with feature modeling represents the problem tures space of a product line. A problem space denes a feature as a high- We can express a feature model visually as a feature diagram level abstraction by separating the feature from its implementation as shown in Figure 2. Root nodes are called concepts. Each con- details. This gives the stakeholders a clear description of the product cept represents a domain [2] or a complete product line [6]. The line features. The solution space represents features as source code model structures the other features into a multi-level parent-child and converts the stakeholders’ selections into concrete products. hierarchy. There are four kinds of parent-child relationships in feature 3 FEATURE MODELS models: mandatory, optional, alternative, and OR features [4, 12, 18, A feature model captures all the design choices in one high-level 27]. description [3, 14, 29]. Each feature corresponds to one design Mandatory features are software artifacts that must appear in choice. Some features are shared across all products in a product all possible congurations (generated products) of a product line. line (i.e., a commonality). Some only appear in specic products A mandatory feature can be a parent or child feature. If the feature (i.e., a variability). The success of an SPL depends upon eective is mandatory, then it has to be selected in the generated product management of the variabilities.