Modeling features for multi-criteria product-lines in the automotive industry

Bühne, Stan

doi:10.1049/ic:20040334

Cited by 20 publications

(6 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, within Phillips productlines are structured according to divisions, business units, and business lines [30]. Automotive manufacturers structure their product lines according to lines, body types and countries [31]. Some initial approaches have been proposed for coordinating multi-level product lines with regard to their commonalities and variability [24], [32].…”

Section: Product Managementmentioning

confidence: 99%

Software product line engineering and variability management: achievements and challenges

Metzger

Pohl

2014

Future of Software Engineering Proceedings

139

View full text Add to dashboard Cite

Software product line engineering has proven to empower organizations to develop a diversity of similar software-intensive systems (applications) at lower cost, in shorter time, and with higher quality when compared with the development of single systems. Over the last decade the software product line engineering research community has grown significantly. It has produced impressive research results both in terms of quality as well as quantity. We identified over 600 relevant research and experience papers published within the last seven years in established conferences and journals. We briefly summarize the major research achievements of these past seven years. We structure this research summary along a standardized software product line framework. Further, we outline current and future research challenges anticipated from major trends in software engineering and technology.

show abstract

Section: Product Managementmentioning

confidence: 99%

Software product line engineering and variability management: achievements and challenges

Metzger

Pohl

2014

Future of Software Engineering Proceedings

139

View full text Add to dashboard Cite

show abstract

“…Such multiple product lines are common, for example, in the automotive industry (e.g. Bühne et al, 2004). The criteria used to distinguish between the multiple product lines can be captured in a level-0 feature model, with a level-1 feature model used for product-line configuration and a level-2 feature model used for system configuration.…”

Section: Larger Example and Some Observationsmentioning

confidence: 99%

Staged configuration through specialization and multilevel configuration of feature models

Czarnecki

Helsen

Eisenecker

2005

Softw Process Imprv Pract

341

216

View full text Add to dashboard Cite

Feature modeling is a key technique for capturing commonalities and variabilities in system families and product lines. In this article, we propose a cardinality-based notation for feature modeling, which integrates a number of existing extensions of previous approaches. We then introduce and motivate the novel concept of staged configuration. Staged configuration can be achieved by the stepwise specialization of feature models or by multilevel configuration, where the configuration choices available in each stage are defined by separate feature models. Staged configuration is important because, in a realistic development process, different groups and different people make product configuration choices in different stages. Finally, we also discuss how multilevel configuration avoids a breakdown between the different abstraction levels of individual features. This problem, sometimes referred to as 'analysis paralysis', easily occurs in feature modeling because features can denote entities at arbitrary levels of abstraction within a system family.

show abstract

“…In our previous work, we have developed the OVM approach to document PL variability in graphical models (see [24,12]) and to relate those models to the base models. Also, we have related OVMs to FDs (see [11,13]) to eliminate specific deficits of FDs observed in the automotive industry.…”

Section: Separation Of Concernsmentioning

confidence: 99%

Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis

Metzger

Heymans

Pohl

et al. 2007

15th IEEE International Requirements Engineering Conference (RE 2007)

158

131

View full text Add to dashboard Cite

Feature diagrams are a popular means for documenting variability in software product line engineering. When examining feature diagrams in the literature and from industry, we observed that the same modelling concepts are used for documenting two different kinds of variability: (1) product line variability, which reflects decisions of product management on how the systems that belong to the product line should vary, and (2) software variability, which reflects the ability of the reusable product line artefacts to be customized or configured. To disambiguate the documentation of variability, we follow previous suggestions to relate orthogonal variability models (OVMs) to feature diagrams. This paper reuses an existing formalization of feature diagrams, but introduces a formalization of OVMs. Then, the relationships between the two kinds of models are formalized as well. Besides a precise definition of the languages and the links, the important benefit of this formalization is that it serves as a foundation for a tool supporting automated reasoning on variability. This tool can, e.g., analyse whether the product line artefacts are flexible enough to build all the systems that should belong to the product line. MotivationMany industry sectors face the challenge of how to satisfy the increasing demand for individualized software systems and software-intensive systems. The software product line (PL) engineering paradigm (SPLE, see [24]) has proven to empower organizations to develop a diversity of similar systems at lower cost, in shorter time, and with higher quality when compared with the development of single systems [24].Key to SPLE is to exploit the commonalities of the systems that belong to the PL and to handle the variation (i.e., the differences) between those systems. Commonalities are properties and qualities that are shared by all systems of the PL [14]; e.g., all mobile phones let users make calls. Two Kinds of VariabilityIn SPLE, two kinds of variability can be distinguished: Software variability and PL variability.Software variability refers to the "ability of a software system or artefact to be efficiently extended, changed, customized or configured for use in a particular context" [31]. This kind of variability is well known from the development of single systems. As examples, an abstract Java super-class allows different specializations to be used where the superclass is used; an interface allows different implementations to be chosen.PL variability [14,24,21] is specific to SPLE and describes the variation between the systems that belong to a PL in terms of properties and qualities, like features that are provided or requirements that are fulfilled. It is important to understand that defining PL variability, i.e., determining what should vary between the systems in a PL and what should not, is an explicit decision of product management (see [21,24]). As an example, product management might have decided that the mobile phones of their PL should either offer the GSM or the UMTS protocol.A chal...

show abstract

Modeling features for multi-criteria product-lines in the automotive industry

Cited by 20 publications

References 0 publications

Software product line engineering and variability management: achievements and challenges

Software product line engineering and variability management: achievements and challenges

Staged configuration through specialization and multilevel configuration of feature models

Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis

Contact Info

Product

Resources

About