Results 1 - 10
of
69
Product derivation in software product families: a case study
- THE JOURNAL OF SYSTEMS AND SOFTWARE
, 2004
"... 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 th ..."
Abstract
-
Cited by 62 (8 self)
- Add to MetaCart
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.
COVAMOF: A Framework for Modeling Variability in Software Product Families
- In Proceedings of the Third International Software Product Line Conference (SPLC
, 2004
"... Abstract. A key aspect of variability management in software product families is the explicit representation of the variability. Experiences at several industrial software development companies have shown that a software variability model (1) should uniformly represent variation points as first clas ..."
Abstract
-
Cited by 46 (0 self)
- Add to MetaCart
(Show Context)
Abstract. A key aspect of variability management in software product families is the explicit representation of the variability. Experiences at several industrial software development companies have shown that a software variability model (1) should uniformly represent variation points as first class entities in all abstraction layers (ranging from features to code) and (2) allow for hierarchical organization of the variability. It furthermore (3) should allow for first class representation of simple, i.e. one-to-one, and complex, i.e. n-to-m, dependencies, and (4) allow for modeling the relations between dependencies. Existing variability modeling approaches only support the first two requirements, but lack support for the latter two. The contribution of this paper is a framework for variability modeling, COVAMOF, that provides support for all four requirements. 1
Variability Mechanisms in E-Business Process Families
- In Proc. of BIS, volume 85 of LNI
, 2006
"... Abstract Nowadays, process oriented software systems, like many business information systems, don’t exist only in one single version, but in many variants for better coverage of the target market. Until now, the corresponding customization has to be done manually, which isatimeconsuming and error-pr ..."
Abstract
-
Cited by 45 (1 self)
- Add to MetaCart
(Show Context)
Abstract Nowadays, process oriented software systems, like many business information systems, don’t exist only in one single version, but in many variants for better coverage of the target market. Until now, the corresponding customization has to be done manually, which isatimeconsuming and error-prone task, which could be realized much more efficiently by applying process family engineering techniques. Process family engineering is amodern software development approach, which allows for the rapid and cost-effective development and deployment of customer tailored process oriented systems. In this paper we present our findings in the area of process family architectures for e-business systems, described as variant-rich process models in the Business Process Modeling Notation. We moreover address variability implementation issues using Java variability mechanisms and code generators. 1
Integrating Compositional and Annotative Approaches for Product Line Engineering
"... Software product lines can be implemented with many different approaches. However, there are common underlying mechanisms which allow a classification into compositional and annotative approaches. While research focuses mainly on composition approaches like aspect- or feature-oriented programming be ..."
Abstract
-
Cited by 18 (9 self)
- Add to MetaCart
(Show Context)
Software product lines can be implemented with many different approaches. However, there are common underlying mechanisms which allow a classification into compositional and annotative approaches. While research focuses mainly on composition approaches like aspect- or feature-oriented programming because those support feature traceability and modularity, in practice annotative approaches like preprocessors are common as they are easier to adopt. In this paper, we compare both groups of approaches and find complementary strengths. We propose an integration of compositional and annotative approaches to combine advantages, increase flexibility for the developer, and ease adoption. 1.
A variability-aware module system
- In Proc. of OOPSLA
, 2012
"... Module systems enable a divide and conquer strategy to software development. To implement compile-time variability in software product lines, modules can be composed in different combinations. However, this way variability dictates a dominant decomposition. Instead, we introduce a variability-aware ..."
Abstract
-
Cited by 18 (9 self)
- Add to MetaCart
(Show Context)
Module systems enable a divide and conquer strategy to software development. To implement compile-time variability in software product lines, modules can be composed in different combinations. However, this way variability dictates a dominant decomposition. Instead, we introduce a variability-aware module system that supports compile-time variability inside a module and its interface. This way, each module can be considered a product line that can be type checked in isolation. Variability can crosscut multiple modules. The module system breaks with the antimodular tradition of a global variability model in product-line development and provides a path toward software ecosystems and product lines of product lines developed in an open fashion. We discuss the design and implementation of such a module system on a core calculus and provide an implementation for C, which we use to type check the open source product line Busybox with 811 compile-time options. 1
Generic Implementation of Product Line Components
- Proceedings of NetObjectDays
, 2003
"... An argument pro component-based software development is the idea of constructing software systems by assembling preexisting components instead of redeveloping similar or identical functionality always from scratch. Unfortunately, integrating existing components practically means adaptation and use r ..."
Abstract
-
Cited by 15 (0 self)
- Add to MetaCart
An argument pro component-based software development is the idea of constructing software systems by assembling preexisting components instead of redeveloping similar or identical functionality always from scratch. Unfortunately, integrating existing components practically means adaptation and use rather than use only, which makes an ideal component-based development hard to realize in practice. Product line engineering, however, tackles this problem by making components as generic as needed for a particular product family and thus allows component reuse. Such a component covers variabilities and thus its implementation must consider variabilities as well.
Representing Process Variation with a Process Family
"... Abstract. The formalization of process definitions has been an invaluable aid in many domains. However, noticeable variations in processes start to emerge as precise details are added to process definitions. While each such variation gives rise to a different process, these processes might more usef ..."
Abstract
-
Cited by 15 (6 self)
- Add to MetaCart
(Show Context)
Abstract. The formalization of process definitions has been an invaluable aid in many domains. However, noticeable variations in processes start to emerge as precise details are added to process definitions. While each such variation gives rise to a different process, these processes might more usefully be considered as variants of each other, rather than completely different processes. This paper proposes that it is beneficial to regard such an appropriately close set of process variants as a process family. The paper suggests a characterization of what might comprise a process family and introduces a formal approach to defining families based upon this characterization. To illustrate this approach, we describe a case study that demonstrates the different variations we observed in processes that define how dispute resolution is performed at the U.S. National Mediation Board. We demonstrate how our approach supports the definition of this set of process variants as a process family.
Software product line engineering with the UML: Deriving products
, 2006
"... Software product line engineering introduces two new dimensions into the traditional engineering of software-based systems: the variability modeling and the product derivation. The variability gathers characteristics that differ from one product to another, while the product derivation is defined as ..."
Abstract
-
Cited by 13 (2 self)
- Add to MetaCart
(Show Context)
Software product line engineering introduces two new dimensions into the traditional engineering of software-based systems: the variability modeling and the product derivation. The variability gathers characteristics that differ from one product to another, while the product derivation is defined as a complete process of building products from the product line. Software Product Line Engineering with the UML has received a lot of attention in recent years. However most of these works only concern variability modeling in UML static models and few works concern behavioral models. In addition, there is very little research on product derivation. This chapter investigates the product derivation in the context of the product line engineering with the UML. First, a set of extensions are proposed to model product line variability in two types of UML models: class diagrams (the static aspect) and sequence diagrams (the behavioral aspect). Then we formalize product derivation using a UML model transformation. An algorithm is given to derive a static model for a product and an algebraic approach is proposed to derive product specific statecharts from the sequence diagrams of the product line. Two simple case studies are presented, based on a Mercure product line and the banking product line, to illustrate the overall process, from the modeling of the product
Code Generation to Support Static and Dynamic Composition of Software Product Lines
"... Software product lines (SPLs) are used to create tailor-made software products by managing and composing reusable assets. Generating a software product from the assets of an SPL is possible statically before runtime or dynamically at load-time or runtime. Both approaches have benefits and drawbacks ..."
Abstract
-
Cited by 13 (7 self)
- Add to MetaCart
(Show Context)
Software product lines (SPLs) are used to create tailor-made software products by managing and composing reusable assets. Generating a software product from the assets of an SPL is possible statically before runtime or dynamically at load-time or runtime. Both approaches have benefits and drawbacks with respect to composition flexibility, performance, and resource consumption. Which type of composition is preferable should be decided by taking the application scenario into account. Current tools and languages, however, force a programmer to decide between static and dynamic composition during development. In this paper, we present an approach that employs code generation to support static and dynamic composition of features of a single code base. We offer an implementation on top of FeatureC++, an extension of the C++ programming language that supports software composition based on features. To simplify dynamic composition and to avoid creation of invalid products we furthermore provide means to (1) validate the correctness of a composition at runtime, (2) automatically instantiate SPLs in case of stand-alone applications, and (3) automatically apply interaction code of crosscutting concerns.
Feature-Based Product Line Instantiation using Source-Level Packages
, 2002
"... 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 a ..."
Abstract
-
Cited by 13 (5 self)
- Add to MetaCart
(Show Context)
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.