Defining Domain-Specific Modeling Languages to Automate Product Derivation: Collected Experiences

Tolvanen, Juha-Pekka; Kelly, Steven

doi:10.1007/11554844_22

Cited by 52 publications

(27 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In addition, MDE helps reduce DSL development costs. 3,4 It therefore represents a synergistic union that can significantly improve software development.…”

mentioning

confidence: 99%

Habitation: A Domain-Specific Language for Home Automation

et al. 2009

View full text Add to dashboard Cite

“…In addition, MDE helps reduce DSL development costs. 3,4 It therefore represents a synergistic union that can significantly improve software development.…”

mentioning

confidence: 99%

Habitation: A Domain-Specific Language for Home Automation

et al. 2009

View full text Add to dashboard Cite

“…They are mainly based on the creation of some kind of Domain-Specific Modelling Languages (DSMLs), which capture the variability of a family of products [18]. Different products are instantiated by means of creating different models that conform to the metamodel of the DSML.…”

Section: Discussion and Related Workmentioning

confidence: 99%

Engineering Languages for Specifying Product-Derivation Processes in Software Product Lines

Sánchez

Loughran

Fuentes

et al. 2009

Software Language Engineering

View full text Add to dashboard Cite

Abstract. The goal of a Software Product Line (SPL) is to provide 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.

show abstract

“…This can be achieved by using techniques from model-driven engineering [21,23] like automated model transformations to derive the final product from a given product configuration. While this works well for deriving most parts of the product implementation [8,24,25], it has limitations for the product's user interface (UI) part: A high quality UI must not only adhere to certain functionality defined by a product configuration (e.g., the presence or absence of UI elements) but also meet usability requirements like adequate layout, composition into screens, and choice of UI element types.…”

Section: Introductionmentioning

confidence: 99%

User interface engineering for software product lines

Pleuss

Hauptmann

Dhungana

et al. 2012

Proceedings of the 4th ACM SIGCHI Symposium on Engineering Interactive Computing Systems

View full text Add to dashboard Cite

Software Product Lines (SPL) are systematic approach to develop families of similar software products by explicating their commonalities and variability, e.g., in a feature model. Using techniques from model-driven development, it is then possible to automatically derive a concrete product from a given configuration (i.e., selection of features). However, this is problematic for interactive applications with complex user interfaces (UIs) as automatically derived UIs often provide limited usability. Thus, in practice, the UI is mostly created manually for each product, which results in major drawbacks concerning efficiency and maintenance, e.g., when applying changes that affect the whole product family. This paper investigates these problems based on real-world examples and analyses the development of product families from a UI perspective. To address the underlying challenges, we propose the use of abstract UI models, as used in HCI, to bridge the gap between automated, traceable product derivation and customized, high quality user interfaces. We demonstrate the feasibility of the approach by a concrete example implementation for the suggested model-driven development process.

show abstract

Defining Domain-Specific Modeling Languages to Automate Product Derivation: Collected Experiences

Cited by 52 publications

References 6 publications

Habitation: A Domain-Specific Language for Home Automation

Habitation: A Domain-Specific Language for Home Automation

Engineering Languages for Specifying Product-Derivation Processes in Software Product Lines

User interface engineering for software product lines

Contact Info

Product

Resources

About