Explanations in Software Product Lines Analysis
Total Page:16
File Type:pdf, Size:1020Kb
EXPLANATIONS IN SOFTWARE PRODUCT LINES ANALYSIS ### AFRAMEWORK FOR AN ABDUCTION AND DIAGNOSIS-BASED ANALYSIS OF VARIABILITY MODELS PABLO TRINIDAD MARTÍN-ARROYO UNIVERSITY OF SEVILLE PHD PROJECT ADVISED BY ANTONIO RUIZ-CORTÉS First published in 2008 by The ISA Group ETSI Informática Avda. de la Reina Mercedes s/n Sevilla, 41012. SPAIN Copyright c MMVIII The ISA Group http://www.isa.us.es In keeping with the traditional purpose of furthering science, education and research, it is the policy of the publisher, whenever possible, to permit non-commercial use and redistribution of the information contained in the documents whose copyright they own. You however are not allowed to take money for the distribution or use of these results except for a nominal charge for photocopying, sending copies, or whichever means you use redistribute them. The results in this document have been tested care- fully, but they are not guaranteed for any particular purpose. The publisher or the holder of the copyright do not offer any warranties or representations, nor do they accept any liabilities with respect to them. Support: This work was partially supported by the European Commission (FEDER) and Spanish Government under CICYT project Web-Factories (TIN2006-00472) and by the Andalusian Government under project ISABEL (TIC-2533). Contents 1 Summary ...........................................1 2 PhdProject .........................................3 2.1 Introduction ....................................... .......3 2.1.1 SoftwareProductLines ............................ ...3 2.1.2 FeatureModels ................................... ...4 2.1.3 Abductive Reasoning and Diagnosis . 6 2.2 InnovationDegree ................................. ........7 2.2.1 The problem: Explanations in Variability Models . 7 2.2.2 Hypothesis ..................................... ....7 2.2.3 StateoftheArt .................................... 9 2.2.4 SummaryofContributions ...........................11 2.3 Objectives ....................................... ........12 2.4 Methodology ...................................... ......13 2.5 WorkPlan ........................................ .......14 2.6 Conclusions ...................................... ........15 Bibliography . 17 ii Contents List of Figures 2.1 A Home Integration System (HIS) feature model . ....6 2.2 Ourresearchmethodology ............................ ........14 iv List of Figures Chapter 1 Summary Sofware Engineering researchers have proposed many techniques to deal with the complexity of producing a set of customized products. Software Product Lines (SPL) intend to build a set of customized products from a set of common features or core-assets and a set of product-specific assets that may be reusable or not for other products. In other terms, the products commonality and variability is analized to systematise the software reusability and reduce the production and maintenance costs. In this context, the set of products in an SPL is commonly defined by Vari- ability Models. The most frequently used variability models are feature mod- els(FM), that represent the set of products in terms of its features. FMs are a key artifacts in many of the SPL processes such as architectural design, prod- uct derivation or even marketing. In those activities extracting relevant in- formation from FMs is crucial. Most of the times, the size of FMs makes that analysis unfeasible so an automated support is needed. In last years, a catalog of analysis operations and different automation tech- niques have been proposed. However, this catalog is practically conditioned by the use of deductive reasoning techniques that makes explicit the implicit information within a FM. Other kinds of reasoning such as abduction and in- duction may help on obtaining useful information from feature models such as explanations that give a response about why errors appear or a configura- tion is not possible. In the PhD dissertation whose project we present, we firstly intend to pro- pose a new catalog of the operations that abductive reasoning may introduce to current catalogs. Secondly, we pretend to give a rigorous and even formal definition of those operations. Thirdly, we will propose several implementa- tions to the operations so, as the last contribution we will implement them into 2 Chapter 1. Summary our FAMA Framework tool so our results could be validated by the industry. Chapter 2 Phd Project 2.1 Introduction In this document, we present our PhD project as a first step towards the presentation of our PhD dissertation in the few next months. Our work will focus on the introduction of abductive and diagnostic reasoning to the auto- mated analysis of Software Product Lines. To understand the real dimensions of our PhD dissertation, in this Section we give a brief introduction to the con- text where it will be developed. In Section §2.2 we bring toghether a descrip- tion of the scope of the problem we are dealing with our PhD Thesis (§2.2.1), automating explanations in feature models; our working hypothesis (§2.2.2); a summary of the proposals in the context of our problem (§2.2.3); and the preliminary results we have obtained at date (§2.2.4). A summary of our high- level objectives is shown in Section §2.3. Section §2.4 shows our perspective of the research world and how it affects to our working plan presented in Section §2.5. Lastly, some conclusions are presented in Section §2.6. 2.1.1 Software Product Lines Software Product Lines (SPL) arise from the intention of reducing the cost of building families of software products that share a high percentage of com- mon features. Instead of building each product one by one from scratch, SPL engineering analyses the commonality and variability of a set of products to build a common set of assets or core–assets that are used to build the particu- lar products. Three main activities are considered in SPL engineering: 4 Chapter 2. Phd Project • Domain engineering, where the core–assets are built cantaining the com- mon features of all the derivable products. • Application engineering, where particular products are built from the core–assets plus a set of product–specific assets that might be introduced in the core–assets base if the can be reused for other products. • Management, which is the activity that provides the needed resources to domain and application engineering, coordinating and supervising their tasks. 2.1.2 Feature Models One of the main activities in domain analysis consists of clearly determin- ing the set of products that a SPL is able to build. In hardware product lines such as those in automotive industry, a customer may build a customized product from a selection of optional features. When you buy a car, you may select among air-conditioning, ABS, GPS or automatic gearbox for example. Similarly, SPL aim to describe its products in terms of features so a customer may choose a customized product. In this case, a feature might be defined as an increment in the functionality of a product (other definitions can be found in the bibliography, however differences do not affect to feature models). Commonly, products within a SPL are described by means of feature mod- els, which capture the commonality and variability of a SPL in terms of fea- tures. Feature models are tree-like structures where features are connected by means of two main kinds of relationships: i. Hierarchical relationships: they link a parent feature with one or more child features forming a tree-like structure. ii. Cross-tree constraints: relationships that express a more complex rela- tionship that cannot be defined in terms of hierarchical relationships which links two features that are not hierarchicaly linked. Most com- mon constraints are mutex and requires relationships. Since Kang et al. [16] firstly defined feature models in their FODA report in 1990, many authors have proposed changes to feature models to represent more complex relationships. FODA feature models use mutex and requires constraints and three kinds of hierarchical relationships: 2.1. Introduction 5 i. Mandatory: a binary relationship (a parent and a child feature) which in- dicates that whenever the parent feature appears in a product, the child feature must also appear. ii. Optional: a binary relationship which indicates that if the parent feature appears in a product, the child feature may appear or not, but may not be in a product if the parent feature is not. iii. Alternative: a set relationship (a parent and several child features) that forces the customer to select one and only one of the child features when- ever the parent feature appears in a product. Many authors have proposed their own kinds of hierarchical relationship that have caused to be no consensus on feature metamodels. Some examples of them are: • Or-relationship: a set relationship where any combination of features may be selected with the only restriction that at least one of them must be selected. • Set relationship: a set relationship decorated with cardinalities that indi- cate the number of child features that can be selected at the same time. 1 − 1 cardinality will be equivalent to an alternative relationship. 1 − N cardinality will be equivalent to an or-relationhip (where N is the num- ber of child features). • Cardinality relationship: a binary relationship decorated with cardinal- ities. The child feature may appear in a product as much times as the maximum cardinity (even Kleene closure is considered). Originally pro- posed by Czarnecki et al.[10], its semantics is not clear and may cause a misunderstanding to the modeler. It can be inferred from their article that they are only conceived to be used on leaf features (those that have no child features). Additionaly, a feature model may be extended with extra-functional infor- mation or attributes such as development time and cost, binding times, ver- sions or any other relevant information. The so-called extended feature mod- els[2, 5, 10] link attributes to features and optionally, complex relationships among attributes may be also represented. In Figure §2.1 you may find an example of a feature model that uses Czarnecki’s feature metamodel and its graphical notation [9].