A Tool Support for Model-Driven Development: An Industrial Case Study from a Measurement Domain

End-user programming may utilize Domain-Specific Modeling Languages (DSMLs) to develop applications in the form of models, using only abstractions found in a specific problem domain. Indeed, the productivity benefits reported from Model-Driven Development (MDD) are hard to ignore, and a number of MD...

Full description

Saved in:
Bibliographic Details
Published inApplied sciences Vol. 9; no. 21; p. 4553
Main Authors Kos, Tomaž, Mernik, Marjan, Kosar, Tomaž
Format Journal Article
LanguageEnglish
Published Basel MDPI AG 01.11.2019
Subjects
Online AccessGet full text
ISSN2076-3417
2076-3417
DOI10.3390/app9214553

Cover

More Information
Summary:End-user programming may utilize Domain-Specific Modeling Languages (DSMLs) to develop applications in the form of models, using only abstractions found in a specific problem domain. Indeed, the productivity benefits reported from Model-Driven Development (MDD) are hard to ignore, and a number of MDD solutions are flourishing. However, not all stories from industry on MDD are successful. End-users, without having software development skills, are more likely to introduce software errors than professional programmers. In this study, we propose and encourage other DSML developers to extend the development of DSML with tool support. We believe the programming tools (e.g., debugger, testing tool, refactoring tool) are also needed for end-users to ensure the proper functioning of the products they develop. It is imperative that domain experts are provided with tools that work on the abstraction level that is familiar to them. In this paper, an industrial experience is presented for building various tools for usage in MDD. Debugger, automated testing infrastructure, refactoring, and other tools were implemented for Sequencer, a DSML. Our experience with the implementation of tool support for MDD confirms that these tools are indispensable for end-user programming in practice, and that implementing those tools might not be as costly as expected.
Bibliography:ObjectType-Article-1
SourceType-Scholarly Journals-1
ObjectType-Feature-2
content type line 14
ISSN:2076-3417
2076-3417
DOI:10.3390/app9214553