Model-based engineering in the embedded systems domain: an industrial survey on the state-of-practice

Liebel, Grischa; Marko, Nadja Christiane; Tichy, Matthias; Leitner, Andrea; Hansson, Jörgen

doi:10.1007/s10270-016-0523-3

Cited by 104 publications

(89 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This is in line with what we found in our study. Other authors have also reported significant gains in productivity and maintenance when adopting MDD (e.g., [38], [49], [53]).…”

Section: How Do Mdd Approaches Adopted By Companies Support Nfrs? (Rq2)mentioning

confidence: 92%

“…This fact is aligned to what we found in the literature (e.g., "MDD can shorten the development of complex solutions" [41], "applying MDE increases productivity and shorten development time" [51]). Liebel et al [49] found out that 68% of the participants who took part in their study stated that their companies adopted Model-Based Engineering (MBE) approaches because they needed shorter development time and to improve reusability. This is in tune with our observations leading to Finding 2.…”

Section: What Benefits Can the Management Of Nfrs Bring To Companiesmentioning

confidence: 99%

See 1 more Smart Citation

Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

Ameller

Franch

Gómez

et al. 2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Managing Non-Functional Requirements (NFRs) in software projects is challenging, and projects that adopt Model-Driven Development (MDD) are no exception. Although several methods and techniques have been proposed to face this challenge, there is still little evidence on how NFRs are handled in MDD by practitioners. Knowing more about the state of the practice may help researchers to steer their research and practitioners to improve their daily work. Objective: In this paper, we present our findings from an interview-based survey conducted with practitioners working in 18 different companies from 6 European countries. From a practitioner's point of view, the paper shows what barriers and benefits the management of NFRs as part of the MDD process can bring to companies, how NFRs are supported by MDD approaches, and which strategies are followed when (some) types of NFRs are not supported by MDD approaches. Results: Our study shows that practitioners perceive MDD adoption as a complex process with little to no tool support for NFRs, reporting productivity and maintainability as the types of NFRs expected to be supported when MDD is adopted. But in general, companies adapt MDD to deal with NFRs. When NFRs are not supported, the generated code is sometimes changed manually, thus compromising the maintainability of the software developed. However, the interviewed practitioners claim that the benefits of using MDD outweight the extra effort required by these manual adaptations. Conclusion: Overall, the results indicate that it is important for practitioners to handle NFRs in MDD, but further research is necessary in order to lower the barrier for supporting a broad spectrum of NFRs with MDD. Still, much conceptual and tool implementation work seems to be necessary to lower the barrier of integrating the broad spectrum of NFRs in practice.

show abstract

“…This is in line with what we found in our study. Other authors have also reported significant gains in productivity and maintenance when adopting MDD (e.g., [38], [49], [53]).…”

Section: How Do Mdd Approaches Adopted By Companies Support Nfrs? (Rq2)mentioning

confidence: 92%

Section: What Benefits Can the Management Of Nfrs Bring To Companiesmentioning

confidence: 99%

Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

Ameller

Franch

Gómez

et al. 2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…Industrial practice implies collaboration on these models by multiple engineers, possibly from multiple domains. Empirical results show improved productivity of development in industrial settings when that includes using models in this way [2]- [5].…”

Section: Introductionmentioning

confidence: 95%

“…In addition to these technical issues, Hutchinson, Whittle, and Rouncefield [15], also using semi-structured interviews, find organizational (process and business-caused) factors important to the success or failure of their introduction. Recently, an evaluation of industrial MBD practice shows its potential benefits but also highlights the difficulties in its adoption, particularly tool interoperability and a steep learning curve of the method itself and tools used for it [5].…”

Section: Related Workmentioning

confidence: 99%

Impediments to Introducing Continuous Integration for Model-Based Development in Industry

Jongeling

Carlson

Cicchetti

2019

2019 45th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)

View full text Add to dashboard Cite

Model-based development and continuous integration each separately are methods to improve the productivity of development of complex modern software systems. We investigate industrial adoption of these two phenomena in combination, i.e., applying continuous integration practices in model-based development projects. Through semi-structured interviews, eleven engineers at three companies with different modelling practices share their views on perceived and experienced impediments to this adoption. We find some cases in which this introduction is undesired and expected to not be beneficial. For other cases, we find and categorize several impediments and discuss how they are dealt with in industrial practice. Model synchronization and tool interoperability are found the most challenging to overcome and the ways in which they are circumvented in practice are detrimental for introducing continuous integration.

show abstract

“…In model-centric development in embedded software practice (e.g. based on UML or SysML), drawbacks can be significant if methods and tools are not well integrated or trained personnel are missing [119]. Likely, Broy's criticism remains in contemporary automatic vehicle engineering and assurance practice.…”

Section: The Desire For Early Removal Of Severe Errorsmentioning

confidence: 99%

New Opportunities for Integrated Formal Methods

2019

View full text Add to dashboard Cite

Formal methods have provided approaches for investigating software engineering fundamentals and also have high potential to improve current practices in dependability assurance. In this article, we summarise known strengths and weaknesses of formal methods. From the perspective of the assurance of robots and autonomous systems (RAS), we highlight new opportunities for integrated formal methods and identify threats to the adoption of such methods. Based on these opportunities and threats, we develop an agenda for fundamental and empirical research on integrated formal methods and for successful transfer of validated research to RAS assurance. Furthermore, we outline our expectations on useful outcomes of such an agenda. AcronymsAI artificial intelligence ASIL automotive safety integrity level DA dependability assurance DAL design assurance level DSE dependable systems engineering DSL domain-specific language FDA Food and Drug Administration FI formal inspection FM formal method HCI human-computer interaction iFM integrated formal method IT information technology MBD model-based development MDE model-driven engineering ML machine learning RAS robots and autonomous systems RCA root cause analysis RE requirements engineering SACM Structured Assurance Case Meta-model SC systematic capability SIL safety integrity level SMT Satisfiability Modulo Theory SWOT strengths, weaknesses, opportunities, and threats SysML Systems Modelling Language UML Unified Modelling Language UTP Unifying Theories of ProgrammingWe view robots and autonomous systems as both dependable systems and highly automated machines capable of achieving a variety of complex tasks in support of humans. We can consider such systems by looking at four layers: the plant or process composed of the operational environment and the machine; the machine itself; the machine's controller, and the software embedded into this controller. Based on these layers, we treat "embedded system" and "embedded software" as synonyms. Machine, controller, and software can all be distributed.By dependable systems engineering, we refer to error-avoidance and error-detection activities in control system and embedded software development (e.g. according to the V-model). Avizienis et al.[7] devised a comprehensive terminology and an overview of the assessment and handling of a variety of faults, errors, and failures. For critical systems, such activities are expected to be explicit (e.g. traceable, documented), to employ best practices (e.g. design patterns), and to be driven by reasonably qualified personnel (e.g. well-trained and experienced engineers or programmers).The need for dependability often arises from the embedding of software into a cyber-physical context (i.e., an electronic execution platform, a physical process to be controlled, and other systems or human users to interact with). Dependability assurance (DA), or assurance for short, encompasses the usually cross-disciplinary task of providing evidence for an assurance case (e.g. safety, security, reliability) for a sys...

show abstract

Model-based engineering in the embedded systems domain: an industrial survey on the state-of-practice

Cited by 104 publications

References 25 publications

Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

Impediments to Introducing Continuous Integration for Model-Based Development in Industry

New Opportunities for Integrated Formal Methods

Contact Info

Product

Resources

About