Software Product Families Research Articles

EXPRESSING PRODUCT DIVERSIFICATION — CATEGORIZING AND CLASSIFYING VARIABILITY IN SOFTWARE PRODUCT FAMILY ENGINEERING

In a software product family context, software architects design architectures that support product diversification in both space (multiple contexts) and time (changing contexts). Product diversification is based on the concept of variability: a single architecture and a set of components support a family of products. Software product families have to support increasing amounts of variability, thereby making variability engineering a primary concern in software product family development. The first part of this paper (1) suggests a two-dimensional, orthogonal categorization of variability realization techniques and classifies these variability categories into system maturity levels. The second part (2) discusses a case study of an industrial software product family of mobile communication infrastructure for professional markets such as the military. The study categorizes and classifies the variability in this product family according to criteria common to virtually all software development projects.

Communicating the variability of a software-product family to customers

Variability is a central concept in software product family development. Variability empowers constructive reuse and facilitates the derivation of different, customer specific products from the product family. If many customer specific requirements can be realised by exploiting the product family variability, the reuse achieved is obviously high. If not, the reuse is low. It is thus important that the variability of the product family is adequately considered when eliciting requirements from the customer. In this paper we sketch the challenges for requirements engineering for product family applications. More precisely we elaborate on the need to communicate the variability of the product family to the customer. We differentiate between variability aspects which are essential for the customer and aspects which are more related to the technical realisation and need thus not be communicated to the customer. Motivated by the successful usage of use cases in single product development we propose use cases as communication medium for the product family variability. We discuss and illustrate which customer relevant variability aspects can be represented with use cases, and for which aspects use cases are not suitable. Moreover we propose extensions to use case diagrams to support an intuitive representation of customer relevant variability aspects.

Product derivation in software product families: a case study

From our experience with several organizations that employ software product families, we have learned that, contrary to popular belief, deriving individual products from shared software assets is a time-consuming and expensive activity. In this paper we therefore present a study that investigated the source of those problems. We provide the reader with a framework of terminology and concepts regarding product derivation. In addition, we present several problems and issues we identified during a case study at two large industrial organizations that are relevant to other, for example, comparable or less mature organizations.

First class feature abstractions for product derivation

The authors have observed that large software systems are increasingly defined in terms of the features they implement. Consequently, there is a need to express the commonalities and variability between products of a product family in terms of features. Unfortunately, technology support for the early aspect of a feature is currently limited to the requirements level. There is a need to extend this support to the design and implementation level as well. Existing separation of concerns technologies, such as AOP and SOP, may be of use here. However, features are not first class citizens in these paradigms. To address this and to explore the problems and issues with respect to features and feature composition, the authors have formalised the notion of features in a feature model. The feature model relates features to a component role model. Using our model and a composition algorithm, a number of base components and a number of features may be selected from a software product family and a product derived. As a proof of concept, the authors have experimented extensively with a prototype Java implementation of their approach.

Representing variability in a family of MRI scanners

AbstractPromoting software reuse is probably the most promising approach to the cost‐effective development and evolution of quality software. An example of reuse is the successful adoption of software product families in industry. In a product family context, software architects anticipate product variation and design architectures that support product derivation in both space (multiple contexts) and time (changing contexts). Product derivation is based on the concept of variability: a single architecture and a set of components support a family of products. Modern software product families need to support increasing amounts of variability, leading to a situation where variability engineering becomes of primary concern. Variability is often introduced as an ‘add‐on’ to the system without taking the consequences for more than one lifecycle phase such as design or architecture into account. This paper (1) suggests a Variability Categorization and Classification Model (VCCM) for representing variability in the software lifecycle and (2) discusses a case study of a large‐scale software product family of Magnetic Resonance Imaging (MRI) scanners developed by Philips Medical Systems. The study illustrates how variability can be made an integral part of system development at different levels of abstraction. VCCM has been applied to the scanner family as an analysis tool. Copyright © 2003 John Wiley & Sons, Ltd.

소프트웨어 제품 군을 개발하기 위한 점진적 방법

소프트웨어 제품 군 개발 방법은 모든 멤버 시스템에 대한 공통점과 차이점들을 분석하여 표준 소프트웨어 구조와 컴포넌트들을 개발하여 생산라인을 갖추고, 제품 개발 조직에서 여러 버전을 병행하여 생산하고 관리하는 방법이다. 기존의 제품 군 방법은 성공하였을 경우에 경제적 이익은 크나, 초기 투자비가 매우 크다는 것과 첫 제품이 늦게 나온다는 것이 문제점으로 지적되고 있다. 이 논문에서 우리는 초기 비용을 적게 들이면서 궁극적으로 제품군 개발 방법을 조직에 적용할 수 있는 점진적 방법을 제안한다. 이 방법은 초기 버전을 개발할 때부터 변화 가능성에 관한 정보를 기록하여 차기 버전의 개발에 활용한다. 이 변화 분석의 결과는 본격 제품 군 개발로의 전환을 쉽게 해 준다. 변화 가능성을 기록하는 변경 사양서의 생성과 개선 기법을 중심으로 우리의 방법을 설명하고, YBS 시스템 개발을 예로 그 적용을 보인다. 우리가 제안한 방법은 초기에 많은 투자를 할 수 없거나 초기버전을 빨리 시장에 내 놓아야 하는 경우에 적용할 수 있는 저 위험 제품 군 개발 방법이다. In a software product line approach, developers first develop common software architecture and components by analyzing the characteristics of all software members, and then produce each application by integrating components. The approach is considered very effective means for developing and maintaining in parallel a software product family. Main disadvantage of this approach is that it requires a big up-front investment in preparing product line. Therefore, it takes time to deliver the first version. In this paper, we present an incremental method to develop software families, which requires small additional cost for initial versions and allows an organization to move smoothly to full-scale product line. We present our method by explaining how to record and upgrade the results of variations analysis, and show the application of our method by developing a family of YBS. Our method is a low-risk approach that can be effectively applied to an organization that starts developing software systems but has to deliver the first versions quickly to the market.

Communicating the variability of a software-product family to customers

Variability is a central concept in software product family development. Variability empowers constructive reuse and facilitates the derivation of different, customer specific products from the product family. If many customer specific requirements can be realised by exploiting the product family variability, the reuse achieved is obviously high. If not, the reuse is low. It is thus important that the variability of the product family is adequately considered when eliciting requirements from the customer. In this paper we sketch the challenges for requirements engineering for product family applications. More precisely we elaborate on the need to communicate the variability of the product family to the customer. We differentiate between variability aspects which are essential for the customer and aspects which are more related to the technical realisation and need thus not be communicated to the customer. Motivated by the successful usage of use cases in single product development we propose use cases as communication medium for the product family variability. We discuss and illustrate which customer relevant variability aspects can be represented with use cases, and for which aspects use cases are not suitable. Moreover we propose extensions to use case diagrams to support an intuitive representation of customer relevant variability aspects.

Structuring product family requirements for n-dimensional and hierarchical product lines

The software product-line approach (for software product families) is one of the success stories of software reuse. When applied, it can result in cost savings and increases in productivity. In addition, in safety-critical systems the approach has the potential for reuse of analysis and testing results, which can lead to a safer system. Nevertheless, there are times when it seems like a product family approach should work when, in fact, there are difficulties in properly defining the boundaries of the product family. In this paper, we draw on our experiences in applying the software product-line approach to a family of mobile robots, a family of flight guidance systems, and a family of cardiac pacemakers, as well as case studies done by others to (1) illustrate how domain structure can currently limit applicability of product-line approaches to certain domains and (2) demonstrate our progress towards a solution using a set-theoretic approach to reason about domains of what we call n-dimensional and hierarchical product families.

Software product families in Europe: the Esaps & Cafe projects

The EU and European governments have been funding product family development projects for years. This article overviews the different projects, the topics each has addressed, and the main results obtained thus far.

XML implementation of frame processor

A quantitative study has shown that frame technology [1] supported by Fusion toolset can lead to reduction in time- tomarket (70%) and project costs (84%). Frame technology has been developed to handle large COBOL- based business software product families. We wished to investigate how the principle of frame approach can be applied to support product families in other application domains, in particular to build distributed component- based systems written in Object- Oriented languages. As Fusion is tightly coupled with COBOL, we implemented our own tools based on frame concepts using the XML technology. In our solution, a generic architecture for a product family is a hierarchy of XML documents. Each such document contains a reusable program fragment instrumented for change with XML tags. We use a tool built on top of XML parsing framework JAXP to process documents in order to produce a custom member of a product family. Our solution is cost- effective and extensible. In the paper, we describe our solution, illustrating its use with examples. We intend to make our solution available to public in order to encourage investigation of frame concepts in other application domains, implementation languages and platforms.

Feature combination and interaction detection via foreground/background models

One approach to building complex software product families is to partition the possible functions of the system into conceptual chunks called features. Ideally, system instances are rapidly assembled by combining features desired by the particular customer. Unfortunately, features often interact, meaning their combination causes unintended undesirable behavior even though in isolation the features work fine. This paper describes an approach to feature combination and interaction detection via foreground/background models, which allows expressing features as augmentations to the behavior of a base model. It also classifies interactions into three categories, based on how they can be detected, and describes implemented tools which can detect interactions from the three categories. I show why this approach avoids falsely detecting the spurious Type I interactions to which many existing approaches are prone. The tools and methodology, as well as the prevalence of spurious interactions in existing approaches, are illustrated through application to telephony features from the feature interaction contest associated with FIW'98. This data provides evidence that the foreground/background approach catches more nonspurious interactions, with less human effort, than competing approaches.

Jargons for domain engineering

In the Family-oriented Abstraction, Specification and Translation (FAST) domain engineering process for software production, a member of a software product family is automatically generated from a model expressed in a DSL. In practice, the time and skill needed to make the DSLs proved to be bottlenecks. FAST now relies on jargons, a kind of easy-to-make DSL that domain engineers who are not language experts can quickly make themselves. We report our experiences with jargons in the FAST process, and describe the benefits they provide above and beyond conventional DSLs for software production and other purposes.

Notes on the second international workshop on development and evolution of software architectures for product families

Abstract : In February 1998, the European Architectural Reasoning for Embedded Software (ARES) project sponsored the Second International Workshop on Development and Evolution of Software Architectures for Product Families. The workshop brought together practitioners and academics from Europe and the United States who are working in the area of software product families; that is, the production of related software systems from a common set of core assets. Chief among those assets is a shared software and/or system architecture. This workshop explored problems of architecture creation, description, evaluation, recovery, and architecture-based process in the context of building a product family. This report summarizes the discussions and outcomes of the workshop.

Automatic extraction of executable program subsets by simultaneous dynamic program slicing

Developers of software product families and maintainers of “legacy” software can benefit from the ability to automatically extract a correctly functioning subset of the code of a system that performs a desired subset of its behaviors. This article introduces a technique for automatic subsetting based on computing asimultaneous dynamic program slice of the code for a set of representative inputs. I show first why the naive approach (unioning traditional dynamic slices) fails, then give an abstract algorithm that succeeds in any slicing framework satisfying certain (mild) assumptions. Experiments using an implementation within the ISAT environment indicate that the algorithm consistently produces significantly smaller subsets than three competing approaches. I also discuss how to characterize the subset's correctness on inputs of interest outside the set used to compute the slice.

InfoExec: object-oriented/semantic database implementation

In 1988 Unisys released the InfoExec family of advanced data-management products for its A Series mainframe computer systems. The paper reviews the background to this major development activity and explains why the relational and entity-relational approaches were rejected in favour of an object-oriented/semantic approach. Object-oriented/semantic concepts are explained via a simple example and the InfoExec family of software products is briefly described, as is the underlying software structure. The current status and performance of the software is also reviewed.