Product Line Engineering Using Domain-Specific Languages

Voelter, Markus; Visser, Eelco

doi:10.1109/splc.2011.25

Cited by 70 publications

(51 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Therefore, it is rational to be aware of their advantages and disadvantages through their systematic comparison. Boundaries between domain-specialisation are not obvious: any language is more or less domain-specific [1]. In this section, we outline some characteristics that are typical for a pure DSML and GPML.…”

Section: Abstract Syntax Concrete Syntax and Semanticsmentioning

confidence: 99%

See 1 more Smart Citation

Security in Embedded Systems: A Model-Based Approach with Risk Metrics

Vasilevskaya¹

2015

View full text Add to dashboard Cite

Section: Abstract Syntax Concrete Syntax and Semanticsmentioning

confidence: 99%

“…To conclude our discussions about DSMLs and GPMLs, Figure 2.5 (presented by Voelter [1]) illustrates views on relations between domains and languages. Figure 2.5(a) shows the relations between domains as a hierarchical structure where a domain of a pure GPML is the lowest level.…”

Section: Abstract Syntax Concrete Syntax and Semanticsmentioning

confidence: 99%

Security in Embedded Systems: A Model-Based Approach with Risk Metrics

Vasilevskaya¹

2015

View full text Add to dashboard Cite

“…Therefore, it is rational to be aware of their advantages and disadvantages through their systematic comparison. Boundaries between domain-specialisation are not obvious: any language is more or less domain-specific [2]. In this section, we outline some characteristics that are typical for a pure DSML and GPML.…”

Section: Domain-specific Vs General-purpose Modellingmentioning

confidence: 99%

Designing Security-enhanced Embedded Systems: Bridging Two Islands of Expertise

Vasilevskaya¹

2013

View full text Add to dashboard Cite

The increasing prevalence of embedded devices and a boost in sophisticated attacks against them make embedded system security an intricate and pressing issue. New approaches to support the development of security-enhanced systems need to be explored. We realise that efficient transfer of knowledge from security experts to embedded system engineers is vitally important, but hardly achievable in current practice. This thesis proposes a Security-Enhanced Embedded system Design (SEED) approach, which is a set of concepts, methods, and tools that together aim at addressing this challenge of bridging the gap between the two areas of expertise.First, we introduce the concept of a Domain-Specific Security Model (DSSM) as a suitable abstraction to capture the knowledge of security experts in a way that this knowledge can be later reused by embedded system engineers. Each DSSM characterises common security issues of a specific application domain in a form of security properties, which are further linked to a range of solutions.As a next step, we complement a DSSM with the concept of a Performance Evaluation Record (PER) to account for the resource-constrained nature of embedded systems. Each PER characterises the resource overhead created by a security solution, a provided level of security, and the evaluation technique applied.Finally, we define a process that assists an embedded system engineer in selecting a relevant set of security solutions. The process couples together (i) the use of the security knowledge accumulated in DSSMs and PERs, (ii) the identification of security issues in a system design, and (iii) the analysis of resource constraints of a system and available security solutions. The approach is supported by a set of tools that automate its certain steps.We use a case study from a smart metering domain to demonstrate how the SEED approach can be applied. We show that our approach adequately supports security experts in description of knowledge about security solutions in the form of formalised ontologies and embedded system engineers in integration of an appropriate set of security solutions based on that knowledge.

show abstract

“…To this end, we use the approach described in [7]. It uses the principle of "negative variability" [25] which means that product derivation starts from a superimposed model (created manually) which contains the implementation for all features in the whole SPL. The model elements are annotated with presence conditions over features.…”

Section: Application Of Spl Concepts To the Uimentioning

confidence: 99%

“…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. This requires to customize the UI beyond purely automated derivation [15,4].…”

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

Product Line Engineering Using Domain-Specific Languages

Cited by 70 publications

References 16 publications

Security in Embedded Systems: A Model-Based Approach with Risk Metrics

Security in Embedded Systems: A Model-Based Approach with Risk Metrics

Designing Security-enhanced Embedded Systems: Bridging Two Islands of Expertise

User interface engineering for software product lines

Contact Info

Product

Resources

About