Software Product Line

This paper highlights the benefits, in terms of quality, productivity and time-to-market, of applying a generative approach to increase the abstraction level to build applications based on the notification of changes in databases. Most of the databases maintain meta-tables with information about all stored tables; this information is used in an automatic process to define the software product line (SPL) variability. The remaining variability can be specified by means of domain specific languages. Code generators can automatically query the meta-tables, analyze the input specifications and configure the current product. The paper also introduces the Exemplar Driven Development process to incrementally develop code generators and the Exemplar Flexibilization Language that supports the process implementation.

Aligning the software process and the documentation process is a recipe for having both software and documentation in synchrony where changes in software seamlessly ripple along its documentation counterpart. This paper focuses on documentation for Software Product Lines (SPLs). A SPL is not intended to build one application, but a number of them: a product family. In contrast to single-software product development, SPL development is based on the idea that the distinct products of the family share a significant amount of assets. This forces a change in the software process. Likewise, software documentation development should now mimic their code counterpart: product documentation should also be produced out of a common set of assets. Specifically, the paper shows how DITA process and documents are recasted using a feature-oriented approach, a realization mechanism for SPLs. In so doing, documentation artifacts are produced at the same pace and using similar variability mechanisms that those used for code artifacts. This accounts for three main advantages: uniformity, separation of concerns, and timely and accurate delivery of the documentation.

Safety critical systems developed as part of a product line must still comply with safety standards. Standards use the concept of Safety Integrity Levels (SILs) to drive the assignment of system safety requirements to components of a system under design. However, for a Software Product Line (SPL), the safety requirements that need to be allocated to a component may vary in different products. Variation in design can indeed change the possible hazards incurred in each product, their causes, and can alter the safety requirements placed on individual components in different SPL products. Establishing common SILs for components of a large scale SPL by considering all possible usage scenarios, is desirable for economies of scale, but it also poses challenges to the safety engineering process. In this paper, we propose a method for automatic allocation of SILs to components of a product line. The approach is applied to a Hybrid Braking System SPL design.

A Feature Model (FM) is an information model to represent commonalities and variabilities for all the products of a Software Product Line (SPL). The complexity and big size of real feature models makes their manual analysis for determining the product configurations validity a tedious or even infeasible task. Efficient solutions for the diagnosis of errors in the Automated Analysis of Feature Models (AAFM) already exist such as FMDiag and FlexDiag. Thus, this work describes the fundamental basis for both diagnosis algorithms to apply the first of them on the validity of FM product configurations. The results highlight the applicability and efficiency of FMDiag and invite us to look for additional applications of that algorithm in the AAFM scenarios.

Some quality attributes are known to have an impact on the overall architecture of a system, requiring to be properly handled from the early stages of the software development. This led to the creation of different and unrelated approaches to handle specific attributes, such as security, performance, adaptability, etc. The challenge is to propose a flexible approach that could be configured to address multiple attributes of interest, promoting the reuse of best practices and reduction of development costs. We advocate the use of Software Product Line (SPL) principles to manage and customize variability in software processes targeted for the generation of architectural models from requirements models. Hence, in this paper we propose F-STREAM, a flexible and systematic process to derive architecture models from requirements. We define a common core process, its variation and extension points. The definition of this process was performed based on a survey of the existing approaches. As example, we instantiate a process for adaptive systems.

platforms, new operational requirements, different contexts and so on, agility remains more and more solicitated for software evolution. For software evolution of Software Product Line Engineering (SPLE), the Feature Model (FM) is the basic instrument that supports the evolution of SPL at the variability level. We would like to improve FM diagrams to make them understandable during the evolution of the corresponding product lines. More precisely, FM evolution can become more systematic and more intelligent. In our work, we aim to evolve FMs by means of smart techniques. Hence, we represent feature models by an ontology. This latter will permit, among others, the inference of knowledge about the evolution of the FMs. By obtaining different versions of the FMs, these can be used as a learning base of a learning algorithm. So, for a given FM, a new version can be predicted as being an evolution version of the FM. In this paper, we present the FM metamodel extension necessary to represent the semantics of the evolution rules. Thus, with a model driven approach, FMs are transformed into FM ontologies. A running example about an Electric Brake Parking System extracted from the SPLOT repository is presented.

Software and Systems Product Line (SSPL) engineering has shown capabilities to reduce costs and time to market. This is thanks to the creation and management of a common platform dedicated to develop a family of products. These latters can be a family of mobile phones, a family of different brake systems variants for automative needs, etc. Recently, more and more large-scale companies start to implement SSPL engineering in their domains by adopting Model-Based Systems Engineering (MBSE). Systems Product Line (PL) engineering is much broader than software PL engineering. Therefore, various aspects of variability (e.g. functional and quality attributes variabilities) have to be considered in MBSE. However, variability integrated in MBSE is still limited to functional variability. This paper contributes to enhance the SSPL modelling based on SysML by extending the SysML language. The principle aim is to include various aspects of variability. In fact, a holistic variability model is pr...

Software product line (SPL) engineering is a software engineering approach to building configurable software systems. SPLs commonly use a feature model to capture and document the commonalities and variabilities of the underlying software system. A key challenge when using a feature model to derive a new SPL configuration is determining how to find an optimized feature selection that minimizes or maximizes an objective function, such as total cost, subject to resource constraints. To help address the challenges of optimizing feature selection in the face of resource constraints, this paper presents GAFES, an artificial intelligence approach, based on genetic algorithms (GAs), for optimized feature selection in SPLs. Our empirical results show that GAFES can produce solutions with 86-97% of the optimality of other automated feature selection algorithms and in 45-99% less time than existing exact and heuristic feature selection techniques.

Feature Models (FMs) are a popular formalism for modelling and reasoning about commonality and variability of a system. In essence, FMs aim to define a set of valid combinations of features, also called configurations. In this paper, we tackle the problem of synthesising an FM from a set of configurations. The main challenge is that numerous candidate FMs can be extracted from the same input configurations, yet only a few of them are meaningful and maintainable. We first characterise the different meanings of FMs and identify the key properties allowing to discriminate between them. We then develop a generic synthesis procedure capable of restituting the intended meanings of FMs based on inferred or user-specified knowledge. Using tool support, we show how the integration of knowledge into FM synthesis can be realized in different practical application scenarios that involve reverse engineering and maintaining FMs.

Software systems are seen more and more as evolutive systems. At the design phase, software is constantly in adaptation by the building process itself, and at runtime, it can be adapted in response to changing conditions in the executing environment such as location or resources. Adaptation is generally difficult to specify because of its crosscutting impact on software. This article introduces an approach to unify adaptation at design and at runtime based on Aspect Oriented Modeling. Our approach proposes a unified aspect metamodel and a platform that realizes two different weaving processes to achieve design and runtime adaptations. This approach is used in a Dynamic Software Product Line which derives products that can be configured at design time and adapted at runtime in order to dynamically fit new requirements or resource changes. Such products are implemented using the Service Component Architecture and Java. Finally, we illustrate the use of our approach based on an adaptive e-shopping scenario. The main advantages of this unification are: a clear separation of concerns, the selfcontained aspect model that can be weaved during the design and execution, and the platform independence guaranteed by two different types of weaving.

In Software Product Lines variability refers to the definition and utilization of differences between several products. Feature Diagrams (FD) are a well-known approach to express variability, and can be used to automate the derivation process. Nevertheless, this may be highly complex due to possible interactions between selected features and the artifacts realizing them. Deriving concrete products typically involves the composition of such inter-dependent software artifacts. This paper presents a feature-based composition approach to automatically derive a product architecture from a given feature configuration. The proposed approach relies on the combination of Model-Driven Engineering (MDE) and Aspect-Oriented Modeling (AOM) techniques. We introduce a metamodel to reify each feature as a high-level aspect model. Product derivation is achieved by weaving the set of aspect models corresponding to a particular feature configuration. The weaving strategy is derived from an in-depth cross-analysis of both the feature interactions and the aspect model dependencies.

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Adoption strategies for Software Product Lines (SPL) frequently involve bootstrapping existing products into a SPL and extending an existing SPL to encompass another product. One way to do that is to use program refactorings. However, the traditional notion of refactoring does not handle appropriately feature models (FM), nor transformations involving multiple instances of the same SPL. For instance, it is not desirable to apply a refactoring into a SPL and reduce its configurability. In this paper, we extend the traditional notion of refactoring to an SPL context. Besides refactoring programs, FMs must also be refactored. We present a set of sound refactorings for FMs. We evaluate this extended refactoring definition for SPL in a real case study in the mobile games domain.

Os modelos de processos de negócio servem como fonte de requisitos para a modelagem de sistemas de informação que podem ser construídos para operacionalizar processos organizacionais. Embora os requisitos possam ser representados através dos Casos de Uso, a transformação de um modelo em nível de negócio para um modelo em nível de sistema é dificultada devido à notação ou linguagem utilizada para modelar o negócio ser diferente da utilizada para modelar o sistema. Essa diferença entre modelos é uma das barreiras na obtenção ou definição de requisitos de qualidade, pois o engenheiro de requisitos pode ter pouco conhecimento sobre os conceitos de processos de negócio e a falta de iniciativas (abordagens, métodos, técnicas, processos ou ferramentas) que apoiem esse processo pode induzir o profissional a projetar o sistema de forma equivocada. Este trabalho conduz uma revisão sistemática com o objetivo de apresentar o atual estado da arte sobre a derivação de Casos de Uso a partir de modelos de processos de negócio, bem como fornecer um guia aos engenheiros de requisitos, apresentando um leque de possibilidades dessas iniciativas e seus principais conceitos e fundamentos.

Objective: Evaluate the value of a product line in terms of maintainability, extensibility and configurability with refer to the interested stakeholders: customers, maintainers, producers. Rationale: There are values that customers constantly require in a modern software application. Some of these values are supported by product lines. Nevertheless, in the industrial and scientific communities the conjecture that customer values clash with those of producers/maintainers is diffused. Design of Study: we have designed and carried out a case study in an industrial context on an ongoing project to verify the validity of a product line in creating value for stakeholders. So data was collected as the project was being executed along a nine month period. Then, descriptive statistics and hypothesis testing were carried out. Results: experience acquired during the execution of an industrial project has allowed the authors to point out the differences between program families and software product lines. Also, the case study has shown how product lines contribute to stakeholder value proposition elicitation and reconciliation. Conclusions: This study has represented a first step towards analyzing the value that product lines represent for various stakeholders.

Early aspects are crosscutting concerns that are identified in the early life cycle phases of a software system's development. Nominally these phases include the requirements analysis, domain analysis and architecture design phases. Early aspects cannot be localized and tend to be scattered over multiple early life cycle artifacts or artifact elements (such as sections in a requirements document, or modules in an architectural design). Unless these crosscutting concerns can be localized and managed as distinct ...

Software Product Line Engineering has significant advantages in family-based software development. The common and variable structure for all products of a family is defined through a Product-Line Architecture (PLA) that consists of a common set of reusable components and connectors which can be configured to build the different products. The design of PLA requires solutions for capturing such configuration (variability). The Flexible-PLA Model is a solution that supports the specification of external variability of the PLA configuration, as well as internal variability of components. However, a complete support for product-line development requires translating architecture specifications into code. This complex task needs automation to avoid human error. Since Model-Driven Development allows automatic code generation from models, this paper presents a solution to automatically generate AspectJ code from Flexible-PLA modelspreviously configured to derive specific products. This solution is supported by a modeling framework and validated in a software factory.

Engineering. Increased expressiveness is attained and important domain knowledge that would otherwise be lost can be included, allowing improved configuration support to be provided. The stakeholders' goals for a specific product can also be represented with soft constraints, allowing incomplete and inconsistent specifications to be inputted and then be automatically processed and analyzed. The approach is supported by a tool, which is capable of detecting inconsistencies, identifying the required trade-offs and explaining them to the stakeholder, who can then make an informed trade-off decision.

Feature Models are used in different stages of software development and are recognized to be an important asset in model transformation techniques and software product line development. The automated analysis of feature models is being recognized as one of the key challenges for automated software development in the context of Software Product Lines. In our previous work we explained how a feature model can be transformed into a constraint satisfaction problem. However cardinalities were not considered. In this paper we present how a cardinality-based feature model can be also translated into a constraint satisfaction problem. In that connection, it is possible to use off-the-shelf tools to automatically accomplish several tasks such as calculating the number of possible feature configurations and detecting possible conflicts. In addition, we present a performance test between two off-the-shelf Java constraint solvers. To the best of our knowledge, this is the first time a performance test is presented using solvers for feature modelling proposes ⋆ This work was partially supported by the Spanish Science and Education Ministry (MEC) under contracts TIC2003-02737-C02-01 (AgilWeb)

Context-aware computing is widely accepted as a promising paradigm to enable seamless computing. Several middlewares and ontology-based models for describing context information have been developed in order to support contextaware applications. However, the context variability, which refers to the possibility to infer or interpret different context information from different perspectives, has been neglected in the existing context modeling approaches. This paper presents an approach for context-aware software development based on a flexible product line based context model which significantly enhances reusability of context information by providing context variability constructs to satisfy different application needs.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works.

Software product lines are of strategic importance to the organizations that adopt them, affecting both an organization's position in an existing market and its ability to react to new and changing markets. An organization's production system (i.e., how it builds its products) is also of strategic importance, directly affecting, for example, that organization's ability to deliver new products quickly (i.e., its time to market). The production strategy for a software product line is the high-level description of how the production system realizes both the core assets and products. The production strategy is derived from the organization's business strategy and is intended to coordinate the actions of the core asset and product developers. The strategy describes how the product line practices should be employed so that the product line organization will achieve its production goals. This technical note describes a technique, which is based on well-known procedures for ...

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works.

The software product line approach to the development of software intensive systems has been used by organizations to improve quality, increase productivity, and reduce cycle time. These gains require different approaches to a number of the practices in the development organization including testing. The planned variability that facilitates some of the benefits of the product line approach poses a challenge for testrelated activities. This chapter provides a comprehensive view of testing at various points in the software development process and describes specific techniques for carrying out the various test-related tasks. These techniques are illustrated using a pedagogical product line developed by the Software Engineering Institute (SEI).

Here, we discuss this question, along with how the idea of a "project" and project management techniques must expand to fit a product line context. In particular, we'll show how the "overall guidelines, policies, and procedures" that Thayer and Pyster spoke of 20 years ago remain crucially important in product line organizations today. A software product line is a group of products that share a common, managed set of features. The products satisfy the specific needs of a particular market or mission, and are developed from a common set of core assets in a prescribed way. Beyond simple reuse or a component-based development strategy, a software product line lets an organization manage and evolve its product family holistically, as a single, unified entity. Product line engineering is a growing software engineering subdiscipline, and many organizations 4 -including Philips, 5 Hewlett-Packard, 6 Nokia, 7 Raytheon, 3 and Cummins 3 -are using it to achieve extraordinary gains in productivity, time to market, and product quality. Essentially, fielding a product line involves three activities: ■ developing core assets, focus -Richard H. Thayer and Arthur B. Pyster, 1984 1 I n traditional software engineering project management, managers provide focused guidance to a team responsible for producing a specific result in a specified amount of time. Today, however, organizations are increasingly taking a product line approach to software to exploit product commonalities. How does the traditional concept of a project-a temporary endeavor aimed at creating a unique product or service 2hold up under this new paradigm?

conduct research activities and teach undergraduate and graduate courses. My research is focused on strategic software engineering. I develop techniques that support corporations' efforts to radically improve their productivity relative to producing software-intensive products. My research team is working on tools and techniques that support large scale reuse. As a Senior Partner of Luminary Software, I have had more than thirty years experience with research and trends of software design and development. I have over a decade of substantial experience working on a wide variety of systems developed using object-oriented techniques. This experience includes distributed, real time, embedded systems as well as business information systems in a multi-tiered environment. I have worked in various domains. These include telephony, financial, personnel, medical, scientific, aerospace, and the murky regions of legal domain and expert witness testimony. My roles vary from an independent consultant mentoring corporate and project management through an actual project team member assisting with day-to-day tasks. I have assisted software development organizations transition their projects as they adopted new techniques such as product line development, object-oriented development, and iterative, incremental development. In addition, as an instructor I have developed and conducted classes that are highly rated by the attendees. As a Visiting Scientist at the Software Engineering Institute I have 11 years of experience working with world class software engineers and researchers addressing the problems of government agencies and corporations. The SEI team with which I work is internationally recognized for work in software product lines and software architecture. We have assisted with software product lines in domains such as automotive, medical, financial, and aviation.

NI~f &~M-o"e4 tX ~01 F, F77, FI FFT",F F The National Institute of Standards and Technology was established in 1988 by Congress to "assist industry in the development of technology . . . needed to improve product quality, to modernize manufacturing processes, to ensure product reliability ... and to facilitate rapid commercialization ... of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's competitiveness; advance science and engineering; and improve public health, safety, and the environment. One of the agency's basic functions is to develop, maintain, and retain custody of the national standards of measurement, and provide the means and methods for comparing standards used in science, engineering, manufacturing, commerce, industry, and education with the standards adopted or recognized by the Federal Government. As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and applied research in the physical sciences and engineering and performs related services. The Institute does generic and precompetitive work on new and advanced technologies. NIST's research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303. Major technical operating units and their principal activities are listed below. For more information contact the Public Inquiries Desk, 301-975-3058.

Software development organizations are continuously looking for better ways to manage their projects. An emerging approach to achieve this is Inner Source, which refers to the adoption of Open Source development practices within the confines of an organization. With an Inner Source approach, individuals, teams, and departments within an organization can start software projects, very similar to the Open Source model. This affects the way projects are managed in a variety of ways. Firstly, it will affect strategic aspects such as a software sourcing strategy that includes decisions on which software can be "Inner-Sourced." Secondly, at the tactical level, organizations should choose an appropriate Inner Source adoption model that suits the goals and scope of the organization. Finally, it will affect the operational aspects of a project, for example, in the way different people across a whole organization can access the source code and make improvements. Furthermore, Inner Source makes communication much more transparent. While Inner Source offers a variety of potential benefits to an organization, there are also a number of challenges to address. This chapter discusses how the introduction of Inner Source may affect conventional software developing environments and especially how it affects software project management aspects. Based on our studies and those presented in the literature, it outlines a number of benefits of Inner Source as well as a number of challenges and some suggestions as to how they can be addressed.

Over the past twenty years, there have been many contributions in the area of automated analysis of variability models. However, the majority of these researches are focused on feature models. We propose that the knowledge obtained during recent years on the analysis of feature models can be applied to automatically analyse different variability models. In this paper we present FaMa OVM and FaMa DEB, which are prototypical implementations for the automated analysis of two distinct variability models, namely Orthogonal Variability Models and Debian Variablity Models, respectively. In order to minimise efforts and benefit from the feature model know-how, we use FaMa Framework which allows the development of analysis tools for diverse variability modelling languages. This framework provides a well tested system that guides the tool development. Due to the structure provided by the framework, FaMa OVM and FaMa DEB tools are easy to extend and integrate with other tools. We report on the main points of both tools, such as the analysis operations provided and the logical solvers used for the analysis.

Orthogonal Variability Model (OVM) is a modelling language for representing variability in Software Product Line Engineering. The automated analysis of OVMs is defined as the computer-aided extraction of information from such models. In this paper, we present FaMa-OVM, which is a pioneer tool for the automated analysis of OVMs. FaMa-OVM is easy to extend or integrate in other tools. It has been developed as part of the FaMa ecosystem enabling the benefits coming from other tools of that ecosystem as FaMaFW and BeTTy.

Open-Source (OS) software development differs widely from close-source development practices because of a number of reasons: project organization, distributed developers, code-centric, etc. These characteristics force the development tools used in the context of OS development to fulfill a set of requirements such as being extensible, multiplatform, version control support, etc. In this paper we set the basis for a discussion about the features that a success OS tool for the development of Software Product Lines (SPLs) should provide. As a starting point, we analyse the projects of four major OS development tool and summarize its main features in a reference feature model. Next, we introduce some the most popular OS feature modeling tools available in the SPL community and check how they support the identified features.

Documenting and managing the variability among products of a product line is an essential task in software product line engineering. Feature Model (FM) and Orthogonal Variability Model (OVM) are both modelling languages employed for this purpose. In this position paper we propose a transformation between FM and OVM models, thus allowing the interoperability between their modelling tools, particularly analysis tools. The current model transformation tools, particularly those that permit manipulating models from development environment such as Eclipse, and yet those with support to deal with metamodels, seem to be highly appropriate to carry out this task. Therefore we intend to use MOMENT2, which is a model transformation engine that provides support for graph transformation language, as a way of validating our proposal. To the best of our knowledge, there is no proposal for the automated transformation of FM into OVM, not to mention a solution based on model transformation.

Dynamic Software Product Line (DSPL) engineering has proved itself as an efficient way to deal with run-time product adaptation. DSPLs have been successfully applied in domains such as smart homes, mobile devices or multimedia systems. However, existing DSPLs focus their efforts on highly adaptive products or on autonomic products. In this paper, we classify DSPLs according to their adaptation mechanisms and we also propose mixed DSPL which simultaneously address both adaptivity and autonomy. Finally, we discussed the underlying infrastructure to develop mixed DSPLs.

The combination of Software Product Lines (SPL) and Service-Oriented Architectures (SOA) development practices is expected to become a new development paradigm maximizing reuse and business integration. However, multiples issues must be still addressed in order to clarify the connections between both fields. One of the key questions to answer is how SPL practices can be used to support serviceoriented applications. In this context, identifying and managing the points of variability in composite Web services emerges as an inevitable step for making possible such integration. In this position paper we give a first step toward such direction by introducing a comprehensible overview of the main variability points in Web service flows.

Systems such as adaptative and context-aware ones must adapt themselves to changing requirements at runtime. Modeling and implementing this kind of systems is a difficult operation. Software Product Lines (SPL) approach has already coped with modeling a set of software products that share a common base of features by means of feature models. We propose using feature models to model the potential states of a product in what it is called Dynamic SPL. The objective of this paper is generating a component architecture that supports the dynamics of products and which is easily inferred from a feature model. The resultant model performs an automated analysis of the feature model in real-time to correctly response to changes.