一种面向特征的软件产品线非功能需求建模方法

分析传统非功能需求定义的不足,基于需求分析阶段的系统抽象—"需求模型"重新定义非功能需求,规范并简化功能需求与非功能需求之间的关系。扩展面向特征的软件产品线建模方法,在特征模型中显式地建模功能需求、非功能需求、非功能需求类型以及它们之间的相互关系,沿用传统特征模型中固有的变化性建模机制建模并管理非功能需求的变化性,显式地复用与非功能需求相关的建模知识和资产,为进一步研究定量评估产品线变体质量的新技术奠定基础。设计了一个基于多视图的特征建模方法,指导开发者在迭代的过程中建模非功能需求和功能需求,支持关注点分离和模型的复杂性管控。实现了工具原型并进行了实例验证。     

Improving software product line configuration: A quality attribute-driven approach

ContextDuring the definition of software product lines (SPLs) it is necessary to choose the components that appropriately fulfil a product’s intended functionalities, including its quality requirements (i.e., security, performance, scalability). The selection of the appropriate set of assets from many possible combinations is usually done manually, turning this process into a complex, time-consuming, and error-prone task.ObjectiveOur main objective is to determine whether, with the use of modeling tools, we can simplify and automate the definition process of a SPL, improving the selection process of reusable assets.MethodWe developed a model-driven strategy based on the identification of critical points (sensitivity points) inside the SPL architecture. This strategy automatically selects the components that appropriately match the product’s functional and quality requirements. We validated our approach experimenting with different real configuration and derivation scenarios in a mobile healthcare SPL where we have worked during the last three years.ResultsThrough our SPL experiment, we established that our approach improved in nearly 98% the selection of reusable assets when compared with the unassisted analysis selection. However, using our approach there is an increment in the time required for the configuration corresponding to the learning curve of the proposed tools.ConclusionWe can conclude that our domain-specific modeling approach significantly improves the software architect’s decision making when selecting the most suitable combinations of reusable components in the context of a SPL.     

Generative software product line development using variability-aware design patterns

Software Product Lines (SPLs) are an approach to reuse in-the-large that models a set of closely related software systems in terms of commonalities and variabilities. Design patterns are best practices for addressing recurring design problems in object-oriented source code. In the practice of implementing SPL, instances of certain design patterns are employed to handle variability, which makes these “variability-aware design patterns” a best practice for SPL design. However, currently there is no dedicated method for proactively developing SPLs using design patterns suitable for realizing variable functionality. In this paper, we present a method to perform generative SPL development with design patterns. We use role models to capture design patterns and their relation to a variability model. We further allow mapping of individual design pattern roles to (parts of) implementation elements to be generated (e.g., classes, methods) and check the conformance of the realization with the specification of the pattern. We provide definitions for the variability-aware versions of the design patterns Observer, Strategy, Template Method and Composite. Furthermore, we support generation of realizations in Java, C++ and UML class diagrams utilizing annotative, compositional and transformational variability realization mechanisms. Hence, we support proactive development of SPLs using design patterns to apply best practices for the realization of variability. We realize our concepts within the Eclipse IDE and demonstrate them within a case study.     

An approach to software product testing

An approach is presented that uses the following techniques: automatic test case generation, self-checking test cases, black box test cases, random test cases, sampling, a form of exhaustive testing, correctness measurements, and the correction of defects in the test cases instead of in the product (defect circumvention). The techniques are cost-effective and have been applied to very large products     

SEI's software product line tenets

Software product lines are emerging as a viable, important software development paradigm. Based on the Software Engineering Institute's research and experience, the concepts, activities, and practices described here can lead to successful product line development. How-to's, success stories, and lessons learned expand on the approach.     

基于构件和框架、面向方面的软件产品线开发方法CFB-AOD

本文提出了一种基于构件和框架、面向方面的软件产品线设计方法CFB-AOD(ComponentandFrameworkBased,AspectOrientedDesign)。CFB-AOD关注实际的软件开发过程,致力于在软件产品线的开发过程中融入构件技术、框架技术和面向方面技术,对软件开发特别是软件产品线开发有实际的指导意义。并以北航软件所白盒测试工具产品线QESat为例,介绍了CFB-AOD的实际运用。     

Intelligent software product line configurations: A literature review

A software product line (SPL) is a set of industrial software-intensive systems for configuring similar software products in which personalized feature sets are configured by different business teams. The integration of these feature sets can generate inconsistencies that are typically resolved through manual deliberation. This is a time-consuming process and leads to a potential loss of business resources. Artificial intelligence (AI) techniques can provide the best solution to address this issue autonomously through more efficient configurations, lesser inconsistencies and optimized resources. This paper presents the first literature review of both research and industrial AI applications to SPL configuration issues. Our results reveal only 19 relevant research works which employ traditional AI techniques on small feature sets with no real-life testing or application in industry. We categorize these works in a typology by identifying 8 perspectives of SPL. We also show that only 2 standard industrial SPL tools employ AI in a limited way to resolve inconsistencies. To inject more interest and application in this domain, we motivate and present future research directions. Particularly, using real-world SPL data, we demonstrate how predictive analytics (a state of the art AI technique) can separately model inconsistent and consistent patterns, and then predict inconsistencies in advance to help SPL designers during the configuration of a product.     

A business maturity model of software product line engineering

In the recent past, software product line engineering has become one of the most promising practices in software industry with the potential to substantially increase the software development productivity. Software product line engineering approach spans the dimensions of business, architecture, software engineering process and organization. The increasing popularity of software product line engineering in the software industry necessitates a process maturity evaluation methodology. Accordingly, this paper presents a business maturity model of software product line, which is a methodology to evaluate the current maturity of the business dimension of a software product line in an organization. This model examines the coordination between product line engineering and the business aspects of software product line. It evaluates the maturity of the business dimension of software product line as a function of how a set of business practices are aligned with product line engineering in an organization. Using the model presented in this paper, we conducted two case studies and reported the assessment results. This research contributes towards establishing a comprehensive and unified strategy for a process maturity evaluation of software product lines.     

A parallel portfolio approach to configuration optimization for large software product lines

Software product line (SPL) engineering demands for optimal or near‐optimal products that balance multiple often competing and conflicting objectives. A major challenge for large SPLs is to efficiently explore a huge space of various products and satisfy a large number of predefined constraints simultaneously. To improve the optimality and convergence speed, we propose a parallel portfolio approach, called IBEAPORT, which designs three algorithm variants by incorporating constraint solving into the indicator‐based evolutionary algorithm in different ways and performs these variants by utilizing parallelization techniques. Our approach utilizes the exploration capabilities of different algorithms and improves optimality as far as possible within a limited time budget. We evaluate our approach on five large‐scale real‐world SPLs. Empirical results demonstrate that our approach significantly outperforms the state of the art for all five SPLs on a quality indicator and a diversity indicator. Moreover, IBEAPORT quickly converges to a relatively stable hypervolume value even for the largest SPL with 6888 features.     

Systematic approach to new product development

This article presents a comprehensive product development methodology which systematically guides a product development team to develop products which meet or exceed stakeholders' expectations with efficient use of company's resources.     

A novel model-based testing approach for software product lines

Model-based testing relies on a model of the system under test. FineFit is a framework for model-based testing of Java programs. In the FineFit approach, the model is expressed by a set of tables based on Parnas tables. A software product line is a family of programs (the products) with well-defined commonalities and variabilities that are developed by (re)using common artifacts. In this paper, we address the issue of using the FineFit approach to support the development of correct software product lines. We specify a software product line as a specification product line where each product is a FineFit specification of the corresponding software product. The main challenge is to concisely specify the software product line while retaining the readability of the specification of a single system. To address this, we used delta-oriented programming, a recently proposed flexible approach for implementing software product lines, and developed: (1) delta tables as a means to apply the delta-oriented programming idea to the specification of software product lines; and (2) DeltaFineFit as a novel model-based testing approach for software product lines.     

A holistic approach to feature modeling for product line requirements engineering

Requirements engineering (RE) offers the means to discover, model, and manage the requirements of the products that comprise a product line, while software product line engineering (SPLE) offers the means of realizing the products’ requirements from a common base of software assets. In practice, however, RE and SPLE have proven to be less complementary than they should. While some RE techniques, particularly goal modeling, support the exploration of alternative solutions, the appropriate solution is typically conditional on context and a large product line may have many product-defining contexts. Thus, scalability and traceability through into product line features are key challenges for RE. Feature modeling, by contrast, has been widely accepted as a way of modeling commonality and variability of products of a product line that may be very complex. In this paper, we propose a goal-driven feature modeling approach that separates a feature space in terms of problem space and solution space features, and establish explicit mappings between them. This approach contributes to reducing the inherent complexity of a mixed-view feature model, deriving key engineering drivers for developing core assets of a product line, and facilitating the quality-based product configuration.     

Requirements engineering in software product line engineering

Many attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.     

Comprehensibility of UML-based software product line specifications

Software Product Line Engineering (SPLE) deals with developing artifacts that capture the common and variable aspects of software product families. Domain models are one kind of such artifacts. Being developed in early stages, domain models need to specify commonality and variability and guide the reuse of the artifacts in particular software products. Although different modeling methods have been proposed to manage and support these activities, the assessment of these methods is still in an inceptive stage. In this work, we examined the comprehensibility of domain models specified in ADOM, a UML-based SPLE method. In particular, we conducted a controlled experiment in which 116 undergraduate students were required to answer comprehension questions regarding a domain model that was equipped with explicit reuse guidance and/or variability specification. We found that explicit specification of reuse guidance within the domain model helped understand the model, whereas explicit specification of variability increased comprehensibility only to a limited extent. Explicit specification of both reuse guidance and variability often provided intermediate results, namely, results that were better than specification of variability without reuse guidance, but worse than specification of reuse guidance without variability. All these results were perceived in different UML diagram types, namely, use case, class, and sequence diagrams and for different commonality-, variability-, and reuse-related aspects.     

面向方面的软件产品线需求建模

为了将软件产品线的横切关注点在开发的早期阶段分离出来,完成系统分析向设计阶段的顺利过渡,提出了一种面向方面的软件产品线需求分析模型,并给出该模型需求分析的基本步骤.通过冷库管理系统的实例,给出了识别和描述功能需求、非功能需求和横切关注点的方法,利用UML类图完成方面和功能整合,在此基础上介绍了用关系矩阵和合并非功能需求集合的方法来描述非功能需求.实验结果表明,该方法能够有效简化软件产品线需求建模的复杂性.     

基于软件产品线的需求分析研究

软件产品线方法是一种面向特定领域的、大规模、大粒度的软件复用技术.在软件产品线的开发过程中,产品线需求分析是软件产品线开发的关键活动之一,软件产品线需求分析奠定了产品线构架的基础.通过分析软件产品线开发过程和软件产品线需求分析的特点,阐述了软件产品线需求分析方法以及软件产品线需求分析的实践风险.以领域分析和建模为切入点,对软件产品线的领域分析、需求建模和用例建模等关键方法和技术进行了重点的研究.     

PAxSPL: A feature retrieval process for software product line reengineering

Software product lines (SPLs) are a well-known solution to systematically create reusable software products. Among the approaches to create an SPL, the extractive approach is usually used when the organization already has a set of similar systems. These systems are analyzed to extract, categorize, and group their common and variant features throughout the SPL reengineering process. As there are different scenario variables, such as available artifacts and team experience, the activities and techniques used to perform these tasks may change. This may increase the effort and decrease the quality of retrieved features when users with low experience in SPL reengineering perform such tasks. However, there is a lack of a process supporting these tasks considering different scenarios. Therefore, we specify the P repare, A ssemble, and E x ecute Process for SPL Reengineering (PAxSPL), a process that provides support to prepare, assemble, and execute feature retrieval throughout the analysis of documentation and team experience. To initially evaluate PAxSPL, we conducted and reported an exploratory case study in a real development environment. The results indicated that our proposal helps in the assembly of a feature retrieval process according to user needs. Results were important to identify points for improvement in PAxSPL. We also could use the information gathered to improve the guidelines and provide this information to be used as basis of comparison for future users.     

Using a multi-method approach to understand Agile software product lines

ContextSoftware product lines (SPLs) and Agile are approaches that share similar objectives. The main difference is the way in which these objectives are met. Typically evidence on what activities of Agile and SPL can be combined and how they can be integrated stems from different research methods performed separately. The generalizability of this evidence is low, as the research topic is still relatively new and previous studies have been conducted using only one research method.ObjectiveThis study aims to increase understanding of Agile SPL and improve the generalizability of the identified evidence through the use of a multi-method approach.MethodOur multi-method research combines three complementary methods (Mapping Study, Case Study and Expert Opinion) to consolidate the evidence.ResultsThis combination results in 23 findings that provide evidence on how Agile and SPL could be combined.ConclusionAlthough multi-method research is time consuming and requires a high degree of effort to plan, design, and perform, it helps to increase the understanding on Agile SPL and leads to more generalizable evidence. The findings confirm a synergy between Agile and SPL and serve to improve the body of evidence in Agile SPL. When researchers and practitioners develop new Agile SPL approaches, it will be important to consider these synergies.     

Predicting failure-proneness in an evolving software product line

ContextPrevious work by researchers on 3 years of early data for an Eclipse product has identified some predictors of failure-prone files that work well. Eclipse has also been used previously by researchers to study characteristics of product line software.ObjectiveThe work reported here investigates whether classification-based prediction of failure-prone files improves as the product line evolves.MethodThis investigation first repeats, to the extent possible, the previous study and then extends it by including four more recent years of data, comparing the prominent predictors with the previous results. The research then looks at the data for three additional Eclipse products as they evolve over time. The analysis compares results from three different types of datasets with alternative data collection and prediction periods.ResultsOur experiments with a variety of learners show that the difference between the performance of J48, used in this work, and the other top learners is not statistically significant. Furthermore, new results show that the effectiveness of classification significantly depends on the data collection period and prediction period. The study identifies change metrics that are prominent predictors across all four releases of all four products in the product line for the three different types of datasets. From the product line perspective, prediction of failure-prone files for the four products studied in the Eclipse product line shows statistically significant improvement in accuracy but not in recall across releases.ConclusionAs the product line matures, the learner performance improves significantly for two of the three datasets, but not for prediction of post-release failure-prone files using only pre-release change data. This suggests that it may be difficult to detect failure-prone files in the evolving product line. At least in part, this may be due to the continuous change, even for commonalities and high-reuse variation components, which we previously have shown to exist.     

Managing requirements inter-dependency for software product line derivation

Software Product Line Engineering (SPLE) can reduce software development costs, reduce time to market and improve product quality. A software product line is a set of software products sharing a set of common features but containing variation points. Successful SPLE requires making selection decisions at variation points effectively and efficiently. A significant challenge is how to identify, represent and manage the inter-dependency of selection decisions for requirements. We developed the concept of a meta-model for requirement decision models to bring formalism and consistency to the structure and to model inter-dependencies between requirement selection decisions. Here we present a meta-model for requirement selection decisions that includes inter-dependencies and we use a mobile phone worked example to illustrate our approach. To support our method, we developed two separate tools, V-Define (for domain decision model construction) and V-Resolve (for new product derivation). Finally the results of a metal processing product line case study using the tools are described.