The Second Software
Product Line
Conference
Technical Papers
(Authors and Abstracts)
This material is being posted by Carnegie Mellon University's Software Engineering Institute (SEI) on this Web site as a community service.
The Second Software
|
|
The following information provides the title, author(s), and abstract of each of the 24 technical papers accepted for The Second Software Product Line Conference. Papers are alphabetically listed based on first author.
Günter W. Böckle, Siemens AG
Jesús Bermejo, Telvent
Peter Knauber, Fraunhofer IESE
Charles Krueger, BigLever Software, Inc.
Julio Cesar Leite, Pontifícia Universidade Católica do Rio de
Janeiro
Frank van der Linden, Philips
Abstract: The strengths of product line engineering have been described before. But how can an organization make the move from developing one-off products to product line engineering without major interruptions in the day-to-day work? This paper describes how to perform the transition to product line engineering and lists the various strategies for such a transition. It describes how to create an adoption plan and how to institutionalize product line engineering in an organization.
Jan Bosch, University of Groningen
Abstract: Software product lines have received considerable adoption in the software industry and prove to be a very successful approach to intra-organizational software reuse. Existing literature, however, often presents only a single approach towards adopting and evolving a software product line. In this paper, we present an overview of different approaches to architecture-centric, intra-organizational reuse of software artifacts. We relate these to maturity levels for product line artefacts and organizational models.
John Brown, Queen's University of Belfast
Ivor Spence, Queen's
University of Belfast
Peter Kilpatrick, Queen's University of Belfast
Danny Crookes, Queen's University of Belfast
Abstract: This paper explores techniques for implementing adaptable software components. Such techniques can greatly facilitate the implementation of software product lines. The techniques we present allow the construction of large, transparently adaptable components via composition and parameterisation. Functional and structural adaptation, to any level of nesting, is achieved at the point of instantiation via recursive argument lists whose structure mirrors that of the component. The techniques are currently based on the C++ language, although work is under way to extend them to other languages (particularly Java).
Arie van Deursen, CWI
Merin de Jonge, CWI
Tobias Kuipers,
Software Improvement Group
Abstract: In this paper we discuss the construction of software products from customer-specific feature selections. We address variability management with the Feature Description Language (FDL) to capture variation points of product line architectures. We describe feature packaging which covers selecting and packaging implementation components according to feature selections using the autobundle tool. Finally, we discuss a generic approach, based on the abstract factory design pattern, to make instantiated (customer-specific) variability accessible in applications.
The solutions and techniques presented in this paper are based on our experience with the product line architecture of the commercial documentation generator DocGen.
Stefan Ferber, Robert Bosch Research
Jürgen Haag, Robert Bosch
Gasoline Systems
Juha Savolainen, Nokia Research Center
Abstract: Re-engineering a legacy product line has been little addressed by current product line research activities. This paper introduces a method to investigate feature dependencies and interactions, which restricts the variants that can be derived from the legacy product line assets. Reorganizing the product line assets with respect to new requirements needs more knowledge than what is easily provided by the classical feature modeling approaches. Hence, adding all the feature dependencies and interactions into the feature tree results in unreadable and unmanageable feature models, which fail to achieve their original goals.
We therefore propose two complementary views to represent the feature model. One view shows hierarchical refinement of features similar to common feature modeling approaches in a feature tree. The second view describes what kind of dependencies and interactions there are between various features.
We show two examples of feature dependencies and interactions in the context of an engine control software product line and we demonstrate how our approach helps define correct product configurations out of product line variants.
Daniel Fey, Nokia Research Center
Robert Fajta, Nokia Research
Center
Andras Boros, Nokia Research Center
Abstract: A feature model captures the stakeholder-visible aspects and characteristics of a product line. By revealing a product line's inherent commonalities and variabilities, it acts as a key driver in the creation of core assets. Usability and usefulness, however, are important qualities for a feature model to possess in order to fulfill its role. In our opinion, these qualities can be ensured by building upon an adequate meta-model. The purpose of this article is to describe an extended meta-model for feature modeling. Meta-model elements, such as features and inter-feature relations, are presented in detail. We propose automated model analysis as the way of extracting information encapsulated in a feature model: algorithms are suggested for identification of the commonality and variability in the modeled product line and for automated consistency checking of products.
Lars Geyer, University of Kaiserslautern
Martin Becker, University
of Kaiserslautern
Abstract: Product Families typically comprise a set of software assets, which offer the possibility to configure the product family to the needs of a specific application. The configuration process is driven by the variabilities, i.e., the variable requirements that were implemented into the software assets in the form of variation points. During application engineering, a developer selects a consistent set of variabilities, this set is used in order to instantiate the family assets to the needed functionality. The paper describes the influence of this configuration step onto the application engineering process of a product family. In addition, it identifies the requirements imposed onto a configuration technique by the described product family application engineering process.
Michel Jaring, University of Groningen
Jan Bosch, University of
Groningen
Abstract: This paper focuses on variability in industrial software product lines. Variability is the ability to change or customize a software system, i.e., software architects anticipate change and design architectures that support those changes. If the architecture is used for different product versions, e.g., in a software product line context, it becomes important to understand where change has to be planned and the options possible in particular situations. Three variability issues have been identified in a case study involving a Dutch software company. In our opinion, this company, Rohill Technologies BV, is representative for small and medium sized enterprises in software industry. The issues identified are discussed and analyzed and illustrate the need for handling variability in a more explicit manner. In this paper, we suggest a method to represent and normalize variability in industrial software systems. The method is exemplified by applying it to Rohill’s software product line.
Truman Jolley, Boeing Commercial Airplanes
David Kasik, Boeing
Commercial Airplanes
Conrad Kimball, Boeing Commercial Airplanes
Abstract: Tension occurs when multiple organizations develop and deliver their own product lines to a single user community. We apply polarity management to governance of the shared architecture, products, and processes for delivery and management of tens of product lines containing hundreds of applications for thousands of engineering users in Boeing Commercial Airplanes. This paper focuses on the use of polarity management to construct extensible governance bodies and processes for a second phase of product line expansion. We define polarity to be two principles which are both true, but conflict. Polarities are often mistaken to be problems to be solved; however, polarities are held, not solved. Polarity management of the product line infrastructure, a complex customer-supplier network, identifies primary organizational tensions that require management; poorly held polarities cause chaos and failure.
Kyo Kang, Pohang University of Science and Technology
Patrick
Donohoe, Software Engineering Institute
Eunman Koh, Pohang University of
Science and Technology
Kwanwoo Lee, Pohang University of Science and
Technology
Jaejoon Lee, Pohang University of Science and Technology
Abstract: The product line engineering paradigm has emerged recently to address the needs to minimize the development cost and the time to market in this highly competitive global market. Product line development consists of product line asset development and product development using the assets. Product line requirements are essential inputs to product line asset development. These inputs, although critical, are not sufficient to develop product line assets. A marketing and product plan, which includes plans on what features are to be packaged in products, how these features will be delivered to customers (e.g., feature binding time), and how the products will evolve in the future, also drives product line asset development; thus this paper explores design issues from the marketing perspective and presents key design drivers that are tightly coupled with the marketing strategy. An elevator control software example is used to illustrate how the product line asset development is related with the marketing and product plan.
Tomoji Kishi, NEC Corporation
Natsuko Noda, NEC Corporation
Takuya
Katayama, Japan Advanced Institute of Science and Technology
Abstract: It is indispensable for strategic product-line development, to define proper scope of the product-line. Once scope has been defined, we examine product-line architecture for it to examine systematic reuse for the product-line. Therefore, in defining scope, we have to examine whether or no it is appropriate for products in the product-line to share the same architecture. The appropriateness of sharing the same architecture among multiple products has to be examined from two points of view. One is from the point of view of individual optimal, i.e. if it is good for each product to use the shared architecture, and the other is from that of whole optimal, i.e. if it is good for product-line as a whole to share the architecture. In this paper, we propose a method for product-line scoping. We consider scoping as decision-making activities, in which we evaluate multiple candidates of scoping, and select proper one examining the appropriateness from the two points of view. In order to demonstrate the applicability of the method, we applied the method to the scoping for products examined for on-board systems in Japanese ITS (Intelligent Transport Systems) projects.
Frank Van der Linden, Philips Medical Systems
Abstract: Between July 1999 and June 2001, 22 European companies and research institutes worked together in the ESAPS project to enhance their capabilities for engineering software for system families. This paper describes the main objectives of the project, and an overview of the results obtained in the project. Finally, the project is related to other projects and initiatives with similar goals.
Charles Krueger, BigLever Software, Inc.
Abstract: Variation management in a software product line is a multi-dimensional configuration management problem. In addition to the conventional configuration management problem of managing variation over time, software product lines also have the problem of managing variation among the the individual products in the domain space. In this paper, we illustrate how to divide and conquer the variation management problem into a collection of nine smaller problems and solutions. We also show how to address the nine problems with lightweight solutions that can reduce the risks, costs, and time for establishing and maintaining a software product line.
Mike Mannion, Glasgow Caledonian University
Abstract: Product line models are used to drive the generation of requirements for single systems in the product line. They are difficult to validate because they are large and complex. By modelling variability and dependency between requirements using propositional connectives a logical expression can be developed for the model. Validation of the selection of requirements from the model can be achieved by satisfying the logical expression. This approach can be used to validate the model as a whole. A detailed worked example is presented and the computational aspects of the approach are discussed.
Dirk Muthig, Fraunhofer IESE
Colin Atkinson, Fraunhofer IESE
Abstract: It has long been recognized that successful product line engineering revolves around the creation of a coherent and flexible product line architecture which consolidates the common parts of a product family for reuse and captures the variant parts for simple adaptation. However, it has been less clear what form such architectures should take and how they should be represented. One promising approach is offered by the new Model Driven Architecture (MDA) paradigm of the OMG, which holds that an organization's key architectural assets should be represented in an abstract "platform independent" way, in terms of UML models, and thereby shielded from the idiosyncrasies and volatility of specific implementation technologies. In this paper we discuss the opportunities and challenges involved in using the MDA paradigm for product line engineering, and explain how model driven, product line architectures can be developed, maintained and applied. After first outlining the core concepts of product line engineering and ad hoc strategies currently used to support it, the paper provides a detailed metamodel of the information that needs to be stored within a product-line architecture. It then explains how these concepts can be added to the existing UML metamodel in a clean and coherent way, thereby extending the language to support product-line engineering.
Rob van Ommering, Philips Research Laboratories
Jan Bosch,
University of Groningen, The Netherlands
Abstract: Architecture, components and reuse form the key elements to build a large variety of complex, high-quality products with a short lead-time. But the balance between an architecture-driven and a component-driven approach is influenced by the scope of the product line and the characteristics of the development organization. This paper discusses this balance and claims that a paradigm shift from variation to composition is necessary to cope with an increasing diversity of products created by an ever-larger part of an organization. We illustrate our claim with various examples.
Wolfgang Pree, University of California, Berkeley
Marcus Fontoura,
IBM Almaden Research Center
Bernhard Rumpe, Munich University of
Technology
Abstract: The Unified Modeling Language (UML) community has started to define so-called profiles in order to better suit the needs of specific domains or settings. Product lines represent a special breed of systems they are extensible semi-finished pieces of software. Completing the semi-finished software leads to various software pieces, typically specific applications, that share the same core. Though product lines have been developed for a wide range of domains, they apply common construction principles. The intention of the UML-F profile is the definition of a UML subset, enriched with a few UML-compliant extensions, that allows the annotation of such artefacts. The paper presents aspects of the profile with a focus on patterns and exemplifies its usage.
Daniel Simon, Universität Stuttgart
Thomas Eisenbarth,
Universität Stuttgart
Abstract: Software product lines have proved to be a successful and efficient means for managing the development of software in industry. The significant benefits over traditional software architectures have the potential to convince software companies to adopt the product line approach for their existing products. In that case, the question arises how to best convert the existing products into a software product line. For several reasons, an evolutionary approach is desirable. But so far, there is little guidance on the evolutionary introduction of software product lines.
In this paper, we propose a lightweight iterative process supporting the incremental introduction of product line concepts for existing software products. Starting with the analysis of the legacy code, we assess what parts of the software can be restructured for product line needs at reasonable costs. For the analysis of the products, we use feature analysis, a reengineering technique tailored to the specific needs of the initiation of software product lines.
Dennis Smith, Software Engineering Institute
Liam O'Brien, Software
Engineering Institute
John Bergey, Software Engineering Institute
Abstract: Options Analysis for Reengineering (OAR) is a systematic, architecture-centric means for mining existing components for a product line or new software architecture. The method incorporates a set of scalable techniques and exercises to collaboratively analyze existing components, determine viable mining options, and evaluate the most promising options. OAR has 5 activities which are followed in a systematic manner to identify components for mining and estimate the cost and risk of changes required to each legacy component to enable its reuse within a new software architecture. OAR provides visibility into this highly complex analysis activity. It also provides insights into implicit stakeholder assumptions, constraints, and other major drivers that impact the mining of components. Results from a pilot application of OAR are presented in this paper.
Steffen Thiel, Robert Bosch GmbH
Andreas Hein, Robert Bosch GmbH
Abstract: Product lines consider related products, their commonalities and their differences. The differences between the single products are also referred to as variability. Consequently, variability is inherent in every product line and makes the key difference compared to single systems. While on the requirements level the methods for analyzing product line variability are understood today, its transition to architecture remains vague. Bringing variability to architecture as an add-on is just a provisional solution and forebodes the risk of violating other intentions. This paper presents a systematic approach to integrating variability with product line architecture design. In particular, it promotes variability as an architectural driver, embeds variability requirements in the architecture design framework QUASAR, and gives guidelines and examples for documenting variability in architectural views.
Jan Gerben Wijnstra, Philips Research Laboratories
Abstract: The idea of software product families is becoming more and more popular, both in research and in industry. When listening to the ideal story, the benefits of product families are stressed and very little attention is paid to possible problems. However, in practice, it is important to know what these problems are and how they can be dealt with. In this paper we want to identify some of the most critical issues, and how the can be handled. This will be done based on the experiences from three industrial product families for professional markets. The focus will be on product families that use platforms with reusable assets for the development of the family members.
Stefan Voget, Robert Bosch GmbH
Martin Becker, University of
Kaiserslautern
Abstract: Often product lines are applied to stable domains, i.e. a set of common features is identifiable in advance and the evolution of the domain is manageable during lifetime. These prerequisites are not always given. But there may be a market pressure which requires to develop products with systematic and preplanned reuse in a domain not properly overlookable. In such a case the product line approach also offers a set of methods which helps to overcome the risks of an immature domain. In this paper we consider such risks and present some approaches to manage them. The considerations are substantiated by experiences made in the domain of driver information systems in an automotive context. The development is deeply influenced by technological changes (e.g. Internet, MP3-player, UMTS) that challenge the successful deployment of product line technology.
Sherif Yacoub, Hewlett-Packard Laboratories
Abstract: Performance analysis is a software engineering activity that involves analyzing a software application with respect to performance quality attributes such as response and execution times. Performance analysis tools provide the necessary support for the analyst to monitor program execution, record and analyze performance data, and locate and understand areas of poor performance. Performance analysis methods and techniques are highly dependent on the properties of the software system to be analyzed. Product line engineering applications possess some special properties that impose constraints on the selection of the performance analysis techniques to be applied and the tools to be used. The development of a component-based reference architecture is crucial to the success of a true product line. The component-based nature facilitates the integration of components and the replacement of a component with another to meet the requirements of an instance application of the product line. In this paper, we discuss performance analysis of component-based software systems and its automation. We discuss how component-based system properties influence the selection of methods and tools used to obtain and analyze performance measures. We use a case study of document content re-mastering product line to illustrate the application of a performance analysis method to component-based applications.
Jay van Zyl, Rubico Products (Pty) Ltd
Abstract: Software product lines present many benefits over the traditional methods of building systems. With the diverse implementation of both application and technology architectures, organizations are faced with complex design constraints. Layered architectures assist with breaking down complexity through separating elements based on their use and applicability. To really achieve high levels of re-use and productivity without only focusing on one architectural style, is difficult to do. This paper discusses two primary concepts namely, product line architecture and separation continuum. It starts by presenting a product line architectural view that shows how various concepts are separated based on abstraction. In order to provide context, the Software Engineering Institute and Carnegie Mellon University’s product line practices are briefly discussed. The separation continuum shows how vertical and horizontal layering can assist with separating user interface from business logic and data, also the separation of customer facing processes from infrastructure facing processes. Software product developers know that these relationships are not easily related. Customer facing business processes have different requirements to infrastructure facing processes. In order to tie all the concepts together, vertical layering is needed whereby the more abstract elements are separated from the implementation of those elements. An application assembly approach is discussed whereby the product line architecture is tied to the separation continuum showing how high levels of productivity can be achieved when realizing product lines. The approach presented in this paper is still under development with implementation on a limited number of product lines only. It is intended that the content will provoke and stimulate the thinking and experimentation needed to deal with application assembly by means of having a separation continuum and a matching product line architecture.