VML* – A Family of Languages for Variability Management in Software Product Lines (original) (raw)
Related papers
Engineering languages for specifying product-derivation processes in software product lines
Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 2009
The goal of a Software Product Line (SPL) is to create a set of reusable software assets for the rapid production of a software systems family aimed at a specific market segment. The main objective of SPL engineering is to construct, as automatically as possible, specific products after selecting the particular set of features that must be included in them. Unlike traditional engineering of single systems, SPL engineering often requires dealing with three different languages at each stage of the software lifecycle: (1) a language for specifying the variability of the SPL (e.g. a feature model); (2) a language for designing the reusable software assets (e.g. UML 2.0); and (3) a language that specifies how these reusable assets must be composed for constructing specific products. There are currently available enough languages for variability specification and software assets design, but there is a general lack of languages for specifying and automating the composition of these assets. This paper presents as a novel contribution a process to engineer this kind of language. The process produces an editor and a "compiler", which automates the composition of reusable assets, for a particular language. To explain this process a language has been developed to compose reusable assets of architectural models.
A model-driven approach to variability management in product-line engineering
2006
Object-oriented frameworks play an essential role in the implementation of product-line architectures (PLAs) for product families. However, recent case studies reveal that deriving products from the shared software assets of a product-line is a timeconsuming and expensive activity. In this paper, we present a model-driven approach for product derivation in framework-based product-lines. This approach aims to alleviate the aforementioned problems by bridging the gap between domain and application engineering activities in product-line-based development. Our approach is centered on a layered model embracing different artifacts ranging from models for conceptual and architectural variability to models for the realization of variation points. The approach provides mechanisms for enforcing the variation rules throughout the product derivation process and for documenting the variability issues in frameworks and the derived applications. We demonstrate the approach using an existing Java GUI framework.
Integrated Variability Modeling of Features and Architecture in Software Product Line Engineering
2006
Existing methods and tools supporting product line variability management typically emphasize either the feature or the architecture level. There have been attempts to combine these aspects, but no widely accepted method is available so far. This paper reports ongoing research in designing and implementing product line variability models, where the focus lies in treating features and architectural elements as parts of an integrated model. The research is carried together with our industry partner Siemens VAI.
Towards metamodel support for variability and traceability in software product lines
Proceedings of the 5th …, 2011
In Software Product Lines (SPL), where a greater variety of products are derived from a common platform and constantly changed and evolved, it is important to manage the SPL variability and the traceability among its artifacts. This paper presents a metamodel which aims to coordinate SPL activities, by managing different SPL phases and their responsibles, and to maintain the traceability and variability among different artifacts. The metamodel was built for a SPL project in a private company working in the medical information management domain, which includes four products encompassing 102 different modules and 840 features. The metamodel is divided into five sub-models: project and risk management, scoping, requirements and testing. It is represented in the UML notation. Organizations using this metamodel as basis for their approaches, can easily understand the relationships between the SPL assets, communicate to the stakeholders, and facilitate the evolution and maintenance of the SPL. The metamodel can also be adapted to the single system development context.
On the notion of variability in software product lines
Proceedings Working IEEE/IFIP Conference on Software Architecture, 2001
Software product lines are used in companies to provide a set of reusable assets for related groups of software products. Generally a software product line provides a common architecture and reusable code for software product developers. In this article we focus on mechanisms that help developers vary the architecture and behavior of a software product line to create individual products. We provide the reader with a framework of terminology and concepts that help understand the concept of variability better. In addition, we present a number of variability mechanisms in the context of this framework. Finally, we provide a method for incorporating variability into software product lines.
A variability management process for software product lines
2005
The software product line approach (PL) promotes the generation of specific products from a set of core assets for a given domain. This approach is applicable to domains in which products have welldefined commonalities and variation points. Variability management is concerned with the management of the differences between products throughout the PL lifecycle. This paper presents a UMLbased process for variability management that allows identification, representation and delimitation of variabilities as well as identification of mechanisms for variability implementation. The process is illustrated with excerpts of a case study carried out within the context of an existing PL for the Workflow Management System (WfMS) domain. The case study was carried out based on the experimental software engineering concepts. The results have shown that the proposed process has made explicit a higher number of variabilities than does the existing PL process, and it offers better support for variability tracing.
2007
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.
Language Support for Managing Variability in Architectural Models
2008
The effective management and composition of architectural variabilities has long been of importance to product line architects. Architects need to describe how conceptual variabilities are composed and realised through architectural decompositions of a product line. Architecture variabilities need to be described in terms of the chosen design decompositions, which do not often correspond naturally to feature model decompositions. Also, the fine-grained nature of certain architectural variabilities makes it difficult to represent them in a modular fashion, and describe how they are composed across different views. In order to address these issues, this paper presents a variability modelling language (VML), which supports first-class representation of heterogeneous forms of architectural variabilities. The language complements existing architectural modelling approaches for product lines by providing mechanisms to: (i) explicitly reference variation points in multiple architectural views, and (ii) support compositions involving both fine-grained and coarse-grained variabilities in an orthogonal fashion. The completeness and simplicity of VML is assessed through four case studies from different domains.
Variability Management in Domain-Specific Languages
Domain-specific languages (DSLs) have demonstrated their capability to reduce the gap between the problem domain and the technical decisions during the software development process. However, building a DSL is not an easy task because it requires specialized knowledge and skills. Moreover, the challenge becomes even more complex in the context of multi-domain companies where several domains coexist across the business units and, consequently, there is a need of dealing not only with isolated DSLs but also with families of DSLs. To deal with this complexity, the research community has been working on the definition of approaches that use the ideas of Software Product Lines Engineering (SPLE) for building and maintaining families of DSLs. In this paper, we present a PhD thesis that is aimed to contribute to this effort. In particular, we explain the challenges that need to be addressed during the process of going from a family of DSLs to a software language line. Then, we briefly discuss the state of the art, and finally we introduce a research plan.
A Model-based on Role for Software Product-Line Evolving Variability
Modeling evolving variability has always been a challenge for software Product line developers. Indeed, the most recent approaches discuss the problem with the architecture aspect through languages or models. Despite the contributions of these approaches, they have not discussed the possibility to represent the evolving Product line variability with the current UML role given that the latter was designed for a single software system. In this paper, we focused on the use of the concept of evolving role resulting from the adaptation of UML role to represent the evolving variability in the software product line.