On the notion of variability in software product lines

Gurp, Jilles van; Bosch, Jan; Svahnberg, Mikael

doi:10.1109/wicsa.2001.948406

Cited by 290 publications

(186 citation statements)

References 17 publications

Supporting

Mentioning

160

Contrasting

Unclassified

Order By: Relevance

“…Mechanisms to accommodate variability include software product lines, configuration wizards / tools in commercial software, configuration interfaces of software components, or dynamic runtime composition of web services [2][3].…”

Section: A Research Problemmentioning

confidence: 99%

Handling Variability in Software Architecture: Problems and Implications

Galster

Avgeriou

2011

2011 Ninth Working IEEE/IFIP Conference on Software Architecture

View full text Add to dashboard Cite

Section: A Research Problemmentioning

confidence: 99%

Handling Variability in Software Architecture: Problems and Implications

Galster

Avgeriou

2011

2011 Ninth Working IEEE/IFIP Conference on Software Architecture

View full text Add to dashboard Cite

“…The approach is still preliminary and details are missing, in particular it is not clear to what extent it can be automated. However, the idea of combining several derivation approaches is interesting and our approach could probably be incorporated in this general framework as one of the derivation strategies (in 442 approaches [13,15,29]. Our approach, aiming at introducing constraints on the development productivity gains.…”

Section: Related Workmentioning

confidence: 99%

Product Line Use Cases: Scenario-Based Specification and Testing of Requirements

Bertolino

Fantechi

Gnesi

et al. 2006

Software Product Lines

View full text Add to dashboard Cite

Use Cases can be employed in system requirements engineering to capture requirements from an external point of view. In product line modeling, commonalities and variabilities of a family of systems have to be described. To this purpose, we have defined extensions and modifications of the Use Cases notation, called Product Line Use Cases (PLUCs). In order to guarantee the conformance of the derived product with respect to the product line we add the capability of expressing constraints over the Product Use Cases that can be derived from a PLUC. Using this notation, it is possible to express in the requirements specification of the product line not only the possible variant characteristics that can differentiate products of the same line, but also which combinations of variant characteristics are "legal" and which are not. Testing is another activity in which PLUCs show their utility. Indeed, for a product belonging to a product line, testing is a crucial and expensive part of software development. Yet the derivation of test cases for product lines has so far received little attention. We outline a simple methodology for this purpose, which relies on the early requirements specification expressed as PLUCs.

show abstract

“…The commonalities between the individual products (applications) can be used to create so-called common assets, which are reusable components that can be customised for the individual products. The field of variability management [27] of SPFs mainly concerns how the differences between the products can be managed. This paper presents a method about how the common assets can be customised for a specific product based on a selection of features and is therefore a form of variability management.…”

Section: Software Product Families and Software Architecturementioning

confidence: 99%

First class feature abstractions for product derivation

et al. 2004

Self Cite

View full text Add to dashboard Cite

Abstract: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.

show abstract

On the notion of variability in software product lines

Cited by 290 publications

References 17 publications

Handling Variability in Software Architecture: Problems and Implications

Handling Variability in Software Architecture: Problems and Implications

Product Line Use Cases: Scenario-Based Specification and Testing of Requirements

First class feature abstractions for product derivation

Contact Info

Product

Resources

About