Multi-dimensional variability modeling

Rosenmüller, Marko; Siegmund, Norbert; Thüm, Thomas; Saake, Gunter

doi:10.1145/1944892.1944894

Cited by 57 publications

(53 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…A few works consider some forms of composition for FMs [69,9,63,61,28,35,48,28,72,56,58]. They can be used to inter-relate several FMs (like f m Arch150 and f m P lug ) through constraints.…”

Section: Related Workmentioning

confidence: 99%

Extraction and evolution of architectural variability models in plugin-based systems

et al. 2013

View full text Add to dashboard Cite

Variability management is a key issue when building and evolving software-intensive systems, making it possible to extend, configure, customize and adapt such systems to customers' needs and specific deployment contexts. A wide form of variability can be found in extensible software systems, typically built on top of plugin-based architectures that offer a (large) number of configuration options through plugins. In an ideal world, a software architect should be able to generate a system variant on-demand, corresponding to a particular assembly of plugins. To this end, the variation points and constraints between architectural elements should be properly modeled and maintained over time (i.e., for each version of an architecture). A crucial, yet errorprone and time-consuming, task for a software architect is to build an accurate representation of the variability of an architecture, in order to prevent unsafe architectural variants and reach the highest possible level of flexibility. In this article, we propose a reverse engineering process for producing a variability model (i.e., a feature model) of a plugin-based architecture. We develop automated techniques to extract and combine different variability descriptions, including a hierarchical software architecture model, a plugin dependency model and the software architect knowledge. By computing and reasoning about differences between versions of architectural feature models, software architect can control both the variability extraction and evolution processes. The proSend offprint requests to: posed approach has been applied to a representative, large-scale plugin-based system (FraSCAti), considering different versions of its architecture. We report on our experience in this context.

show abstract

Section: Related Workmentioning

confidence: 99%

Extraction and evolution of architectural variability models in plugin-based systems

et al. 2013

View full text Add to dashboard Cite

show abstract

“…Currently, we can find several approaches to support multi dimensional variability -e.g., [39]-. Some of those approaches have been applied concretely to language product lines [40].…”

Section: Language Variability How To Express It?mentioning

confidence: 99%

Reverse engineering language product lines from existing DSL variants

Méndez-Acuña

Galindo

Combemale

et al. 2017

Journal of Systems and Software

View full text Add to dashboard Cite

The use of domain-specific languages (DSLs) has become a successful technique to develop complex systems. In this context, an emerging phenomenon is the existence of DSL variants, which are different versions of a DSL adapted to specific purposes but that still share commonalities. In such a case, the challenge for language designers is to reuse, as much as possible, previously defined language constructs to narrow implementation from scratch. To overcome this challenge, recent research in software languages engineering introduced the the notion of language product lines. Similarly to software product lines, language product lines are often built from a set of existing DSL variants.In this article, we propose a reverse-engineering technique to ease-off such a development scenario. Our approach receives a set of DSL variants which are used to automatically recover a language modular design and to synthesize the corresponding variability models. The validation is performed in a project involving industrial partners that required three different variants of a DSL for finite state machines. This validation shows that our approach is able to correctly identify commonalities and variability.

show abstract

“…A variety of models may be used for different development activities and artifacts -ranging from requirements, source codes, certifications and tests to user interfaces. In an increasing number of scenarios, support for composing models and their variability is becoming more and more crucial [4][5][6][7][8][9][10][11][12][13][14][15][16].…”

Section: Introductionmentioning

confidence: 99%

“…When a multitude of subsystems (modular systems such as software components or services) or artifacts must be combined, several variability descriptions are to be related, organized and finally composed to form a consistent result. This context of use is broad, with first needs on organizing several software product lines with shared variabilities [5], evolving to compositional software product lines [4], in which a complex domain is captured and organized [14] into multiple product lines [8,11] with relations between input product lines' variability models. Handling these relations really lead to both reasoning on the represented configuration sets and maintaining a understandable organization (i.e.…”

Section: Introductionmentioning

confidence: 99%

“…defining abstraction layers, reflecting organizational structure with specific stakeholders [22], supporting collaborative design [23] or multi-level staged configurations [24]. Separation of these views also means that some relations and compositions must be done at some point to reason over the whole SPL, with references, constraints [25], a reduced form of composite model, and even in a semi-automatic way to synthesize an integrated model [11,15].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Composing Your Compositions of Variability Models

Acher

Combemale

Collet

et al. 2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Modeling and managing variability is a key activity in a growing number of software engineering contexts. Support for composing variability models is arising in many engineering scenarios, for instance, when several subsystems or modeling artifacts, each coming with their own variability and possibly developed by different stakeholders, should be combined together. In this paper, we consider the problem of composing feature models (FMs), a widely used formalism for representing and reasoning about a set of variability choices. We show that several composition operators can actually be defined, depending on both matching/merging strategies and semantic properties expected in the composed FM. We present four alternative forms and their implementations. We discuss their relative trade-offs w.r.t. reasoning, customizability, traceability, composability and quality of the resulting feature diagram. We summarize these findings in a reading grid which is validated by revisiting some relevant existing works. Our contribution should assist developers in choosing and implementing the right composition operators.

show abstract

Multi-dimensional variability modeling

Cited by 57 publications

References 25 publications

Extraction and evolution of architectural variability models in plugin-based systems

Extraction and evolution of architectural variability models in plugin-based systems

Reverse engineering language product lines from existing DSL variants

Composing Your Compositions of Variability Models

Contact Info

Product

Resources

About