Results 1 - 10
of
13
Implementing product line variabilities
- In Proceedings of the 2001 Symposium on Software Reusability
, 2001
"... Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperati ..."
Abstract
-
Cited by 69 (0 self)
- Add to MetaCart
(Show Context)
Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperative that they support the description of the product line as a whole, as well as its instantiation for the derivation of individual products. Literature has already addressed how to create and instantiate generic product line assets, such as domain models and architectures to generate instance specific ones [1, 2, 3], yet little attention has been given on how to actually deal with this genericity at the code level. This paper addresses the issue of handling product line variability at the code level. To this end various implementation approaches are examined with respect to their use in a product line context.
I.: Key activities for product derivation in software product lines
- Journal of Systems and Software
, 2011
"... * corresponding author ..."
(Show Context)
Model-based Configuration Support for Product Derivation
- in Software Product Families,” PuK 2005, 2005. © 2006 WASET.ORG
"... Software Product Families can be used for software mass customization. One major problem within family-based software engineering is the lack of methodological support for application engineering. The large number of decisions and dependencies between these decisions make the task complex and error- ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
(Show Context)
Software Product Families can be used for software mass customization. One major problem within family-based software engineering is the lack of methodological support for application engineering. The large number of decisions and dependencies between these decisions make the task complex and error-prone. Impacts of decisions are not known or overseen during application engineering. Functionality is newly implemented where reuse would have been possible because the large number of artifacts is hardly manageable. The methodology described in this paper combines the well known research areas of software product families and model-based configuration in order to fill this gap. The methodology is based on a configuration model that represents functionality and variability provided by the product family. Basically, the configuration model provides two layers of configurable assets, i.e. a feature layer and an artifact layer. The artifact layer reflects the (variable) structure of the product family artifacts and the feature layer is thecustomer view on the functionality in the artifact layer. A mapping between the feature layer and the artifact layer allows for automated inferring of the needed software artifacts for a given selection of features. We call the resulting process of application engineering enhanced with automated inferences model-based product derivation.
Verification of Variable Software: An Experience Report ⋆
"... Abstract. We report on our experiences with formal specification and verification of variable and customizable software realized in a software product family architecture using the Java Modeling Language (JML) and the KeY verification system. Software product families can be adapted to different dep ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
(Show Context)
Abstract. We report on our experiences with formal specification and verification of variable and customizable software realized in a software product family architecture using the Java Modeling Language (JML) and the KeY verification system. Software product families can be adapted to different deployment scenarios and provide instantiable feature sets as requested by the customer. Along a small case study we explore how to generate JML specifications for/from a given feature configuration and report on verification attempts of selected methods of the derived product. We identify challenges that need to be solved to allow scalable specification and verification of variable software. 1
FOOM- Feature-based Object Oriented Modeling: Implementation of a Process to extract and extend Software Product Line Architecture Abstract
"... Using a product line approach to software development and evolution requires much more than a re-use program: it requires the implementation of a common architecture across all members of the product family. FOOM represents a synthesis of FODA (Feature Oriented Domain Analysis) and Horseshoe models. ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Using a product line approach to software development and evolution requires much more than a re-use program: it requires the implementation of a common architecture across all members of the product family. FOOM represents a synthesis of FODA (Feature Oriented Domain Analysis) and Horseshoe models. It includes Object Oriented approach to Product Line Family architecture. It focuses on identifying user-driven features throughout the product line architecture; organizing the architectural assets to lend them to substantial re-use; and instantiating multiple products from a single architecture. FOOM represents a set of processes that will assist an organization to adopt a product line practice, which will lend itself to constant evolution, provide a high degree of customer focus, and be readily integrated into an organizations ’ overall business plan.. In its entirety, FOOM is a synthesis of FODA and the horseshoe models, but we are concerned with the aspects that integrate and extend FODA methodology in this paper.
An Iterative Model for Agile Product Line Engineering
"... Agile software development (ASD) and software product line engineering (SPLE) seem to be two rewarding yet disparate schools of thoughts in software engineering. ASD encourages strong business involvement in development activities, focuses only on the requirements at hand, and deems huge investment ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
(Show Context)
Agile software development (ASD) and software product line engineering (SPLE) seem to be two rewarding yet disparate schools of thoughts in software engineering. ASD encourages strong business involvement in development activities, focuses only on the requirements at hand, and deems huge investment in requirement and design upfront unjustifiable. On the other hand, SPLE considers intensive domain analysis and flexible & detailed software design as prerequisites to any development effort. SPLE plans for potential future projects, and dedicates considerable resources for preplanning efforts. Integrating ASD and SPLE, although is challenging, has a huge potential of magnifying enhancements in quality, cuts in cost and reductions in time-to-market. In this paper, we present our research on this integration. We propose a model that enables agile organizations to establish product lines without disturbing the agility of their practices. The model is a bottom-up application-driven approach that relies on automated tests to derive core assets from existing code. 1.
Implementation Issues in Product Line Scoping
- In Proceedings of the 6 th International Conference on Software Reuse (ICSR-6
"... Often product line engineering is treated similar to the waterfall model in traditional software engineering, i.e., the different phases (scoping, analysis, architecting, implementation) are treated as if they could be clearly separated and would follow each other in an ordered fashion. However, in ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
(Show Context)
Often product line engineering is treated similar to the waterfall model in traditional software engineering, i.e., the different phases (scoping, analysis, architecting, implementation) are treated as if they could be clearly separated and would follow each other in an ordered fashion. However, in practice strong interactions between the individual phases become apparent. In particular, how implementation is done has a strong impact on economic aspects of the project and thus how to adequately plan it. Hence, assessing these relationships adequately in the beginning has a strong impact on performing a product line project right. In this paper we present a framework that helps in exactly this task. It captures on an abstract level the relationships between scoping information and implementation aspects and thus allows to quickly analyze implementation aspects of the project. We will also discuss the application of our framework to a specific industrial project.
Keywords:
, 2011
"... Software product lines Product derivation Process a b s t r a c t Background: The derivation of products from a software product line is a time consuming and expensive activity. Despite recognition that an effective process could alleviate many of the difficulties associated with product derivation, ..."
Abstract
- Add to MetaCart
(Show Context)
Software product lines Product derivation Process a b s t r a c t Background: The derivation of products from a software product line is a time consuming and expensive activity. Despite recognition that an effective process could alleviate many of the difficulties associated with product derivation, existing approaches have different scope, emphasise different aspects of the derivation process and are frequently too specialised to serve as a general solution. Objective: To define a systematic process that will provide a structured approach to the derivation of products from a software product line, based on a set of tasks, roles and artefacts. Method: Through a series of research stages using sources in industry and academia, this research has developed a Process Model for Product Derivation (Pro-PD). We document the evidence for the construc-tion of Pro-PD and the design decisions taken. We evaluate Pro-PD through comparison with prominent existing approaches and standards. Results: This research presents a Process Model for Product Derivation (Pro-PD). Pro-PD describes the tasks, roles and work artefacts used to derive products from a software product line. Conclusion: In response to a need for methodological support, we developed Pro-PD (Process Model for Product Derivation). Pro-PD was iteratively developed and evaluated through four research stages. Our research is a first step toward an evidence-based methodology for product derivation and a starting point for the definition of a product derivation approach. 2012 Elsevier B.V. All rights reserved. 1. Introduction and