EN 
DE Manifesto for the successful application of the MDSE
Author: Andreas Foltinek, IMACS GmbH
Contribution – Embedded Software Engineering Congress 2015
1. Inventory of MDSE
Increasingly complex structures, functions, and the interplay of technical systems shape our everyday lives. The accompanying, ongoing shift of tasks from mechanical and electronic components to software is placing it ever more firmly in the spotlight of innovation, thereby increasing its importance and the associated costs. Unfortunately, this development is not always taken into account, and software—even at the management and leadership levels—is still often perceived as a necessary add-on. Furthermore, there is a general awareness of the ever-present and supposedly free availability of software updates, an understanding reinforced by users and consumers who now accept this as a given.
All these circumstances all too often lead to a certain laxity in the handling of software and the associated working methods in its development. What has been standard practice in civil engineering, mechanical engineering, and electrical engineering for over 25 years – working with models and their direct use for the "realization" of products – is often still viewed with suspicion and applied hesitantly in software development itself.
In light of currently discussed trends such as Industry 4.0, IoT, and autonomous driving, where computer systems exchange data, interact, synchronize, and steer without human intervention, the above requirements will multiply even further. Traditional programming methods will not be sufficient to meet these trends.
However, it should also be noted that MDSE experienced a surge in popularity at the end of the last millennium, and developers were indeed searching for new approaches, some even exploring them. The implementation methods generally favored at the time, however, often proved ineffective and sometimes even counterproductive in practice. As with any new methodology, reflection and reassessment based on experience were necessary. Given the current major software challenges, it is crucial to reclaim this "scorched earth" and establish model-based computing as a standard practice.
2. Intention of the joint initiative
Even after more than 15 years of Model-Driven Development in software engineering, it still falls far short of its potential. What is the reason?
To answer this, we came together and drew a conclusion. "We" refers to various stakeholders who have been extensively involved with MDSE in recent years. What's particularly significant in this context is that, after an initial period of exploration, all these well-known players in the methods and tools sector now share the same approach and principles. As is often the case in industrial evolution, this indicates that a certain level of maturity has been reached.
It should be mentioned that these protagonists not only advocate these methods abstractly, but have also successfully applied them in their own projects and products over many years. Over the years, a naturally more practice-oriented approach has developed and become established, evolving from initially very academic methods.
Unfortunately, these approaches have not yet been widely established – partly due to the negative experiences of recent years mentioned at the beginning. Why?
We asked ourselves this question and found that it does work if certain aspects are considered and implemented correctly. Unfortunately, this often doesn't happen, and expectations aren't met.
For this reason, we have established a manifesto and formulated seven theses that define the aspects that make MDSE effective. It is intended to serve as a platform for the community to exchange ideas on the topic and to further develop it.
3. Seven theses and their practical implementation
The following section presents the individual theses. Brief, practice-oriented explanations clarify the background and illustrate best practice recommendations as well as negative examples and pitfalls. They are intended to serve as inspiration, but also for reflection and evaluation of one's own previously practiced approaches and procedures.
- INTEGRATE STAKEHOLDERS – through domain-appropriate abstractions, notations, and views.
Models should be easily understandable, clear, and informative for participants and those responsible.
The use of these should increase and simplify project understanding and avoid misunderstandings and complications. - Aim for long-lasting models – through the right abstractions, separation of concerns, and appropriate style guides.
Models should evolve from the idea and requirements to the generation of outcomes (e.g., source code, tools, documentation) and be the sole determining factor.
Models or model parts should be designed in such a way (abstract, unambiguous) that reuse is possible elsewhere without modification. - CREATE VALIDABLE, TRANSFORMABLE AND EXECUTIVE MODELS – through semantically well-defined language for functional and non-functional aspects.
Models should be described in such a language that they can be unambiguously converted by machine into other forms (e.g. views, extracts, …) without changing any information.
The scope should be as comprehensive and detailed as possible in order to generate tests, directly executable code, or simulations. - FRONT-LOADING – use models for early knowledge acquisition.
Models should be used as early as possible, e.g. in the process of generating ideas and requirements.
Advantageously, these offer different perspectives, even realistic simulations. - AVOID DUPLICATION AND UNNECESSARY REPEATS – through automation and integration of models of different aspects.
Models should ideally contain all types of information, but only in one location. Duplication/mutation should occur through referencing/inheritance.
Models and their application methods (profiles) should consistently avoid redundancy of information, e.g. through visualization and thus reuse. - MAKE MODELING EASILY ACCESSIBLE – through scalable, user-friendly and easy-to-learn tools and infrastructure.
Model-based tools (editors, version control, generators) should be understandable and easy to use, as well as be able to represent other, non-model-based aspects/information.
Complicated, unsuitable (with regard to the domain), excessively extensive tools or toolchains should be avoided. - ESTABLISH A MODELING CULTURE – through education, training and integration with the development process.
Model-based development should be understood as the standard method, and its use should be favored, adequately trained, and supported by management levels.
4. Examining the relationship between developer mindset and tool
Even upon critical examination, the aforementioned theses appear quite compelling and correct, and can guarantee the successful application of MDSE. This raises the question all the more as to why traditional methods are still so prevalent. While embedded software developers enjoy creating complex things and systems from scratch, unlike their IT colleagues, they exhibit a certain conservative tendency regarding their own workflows and tool selection. The editor they've grown fond of over the years, with its project-wide, context-aware input completion, seems to be "tool enough." Switching to a newer approach is often less a matter of personal choice and more a matter of necessity (the 20% Gain – 80 % Pain rule).
Unfortunately, unlike all other engineering disciplines, the embedded software development industry lacks widely recognized standards and thus the certainty of doing "something generally accepted and correct." Many model-based tools in mechanical and electrical engineering incorporate standards at their core, enabling their easy application. These are lacking in the embedded industry, or rather, each development team often has its own standards that have evolved over years.
Because tool choices are increasingly made based on the premise "Don't make any mistakes!" rather than "What benefits us the most?", decision-makers are finding it difficult. Which model-based method should one use without risking being held accountable as a team leader if it goes wrong? "Before I make a mistake, I'd rather stick with the current way of working; it's worked reasonably well so far."„
In practical applications, model-driven approaches often only address the static aspects of a system, for example, by representing classes and their relationships. Very often, only the graphical representation is used, which is then almost always formally incorrect. These approaches might help to soothe one's conscience, but they do not help to manage complexity, because the real problems that arise from complexity (emergence, hidden links, functionality) are not addressed.
A formally correct, dynamic representation of communication, for example through sequence diagrams, a temporal representation of the relationships using timing diagrams, combined with an early simulation of the system, are much more suitable. This and other potential of MDSE is still too rarely exploited in practice. Unfortunately, this often leads to the conclusion that MDSE has not delivered the expected benefits.
Whether UML, SysML, DSL, or custom approaches: We in the field are now aware – and we all agree – that there is no single "truth" in MDSE. Each method has its strengths and advantages and can sometimes excel at solving specific requirements and tasks. Model-based development has as many facets as it does application areas. A universal toolkit doesn't exist, or rather, it would always only offer partial solutions. The topic of embedded software development is simply too complex and multifaceted for that.
5. Conclusion
Our experience shows that the problem isn't MDSE itself, but how it's implemented and used. The fact that Model-Driven Development is suitable for managing the challenges and requirements of our time, as described above, is demonstrated by the many projects where MDSE consistently delivers success.
„There is no single "best method" in MDSE. The specific use case and objective always reveal different priorities that need to be identified and addressed. However, there are "seven best approaches" for implementing and managing a model-based method.
From small cars to tractors and vans to racing cars, there is a wide variety of automobiles, each perfectly suited to its specific purpose. No one will demonize the automobile simply because they get stuck on a dirt road with a sports car or cause an accident due to incorrect or inexperienced driving. Rather, everyone will understand that the right vehicle must be used AND... that one must first learn to drive properly.
The time is ripe for MDSE! Let's also use the methods that have long been standard for machines and systems across the board in embedded software development.
6. Outlook, goals of the initiatives and further activities
The following activities will be jointly promoted as part of the MDSE initiative:
- Raising awareness of the importance of (embedded) software, even across company hierarchies.
- Building a culture of model-based (embedded) software development with corresponding principles and best practice approaches.
- Creating publications
- Organizing congresses (Mesconf) and participating in relevant events
- Promoting global, local, and industry-oriented meetings
- Animation on participation in the MDSE at different levels
We don't want to do all this alone, so we encourage everyone interested to participate, share their concerns (e.g., experiences, wishes, requests for support), and join the discussions. Challenge us to support us!
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
