{"id":8084,"date":"2025-11-29T09:38:42","date_gmt":"2025-11-29T08:38:42","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=8084"},"modified":"2026-02-11T04:50:53","modified_gmt":"2026-02-11T03:50:53","slug":"model-driven-software-engineering-2-0","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/model-driven-software-engineering-2-0\/","title":{"rendered":"Model Driven Software Engineering 2.0"},"content":{"rendered":"

Manifesto for the successful application of the MDSE<\/h2>\n

Author: Andreas Foltinek, IMACS GmbH<\/p>\n

Contribution \u2013 Embedded Software Engineering Congress 2015<\/h3>\n

1. Inventory of MDSE<\/h2>\n

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\u2014even at the management and leadership levels\u2014is 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.<\/strong><\/p>\n

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 \u2013 working with models and their direct use for the "realization" of products \u2013 is often still viewed with suspicion and applied hesitantly in software development itself.<\/p>\n

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.<\/p>\n

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.<\/p>\n

2. Intention of the joint initiative<\/h2>\n

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?<\/p>\n

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.<\/p>\n

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.
\nUnfortunately, these approaches have not yet been widely established \u2013 partly due to the negative experiences of recent years mentioned at the beginning. Why?<\/p>\n

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.<\/p>\n

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.<\/p>\n

3. Seven theses and their practical implementation<\/h2>\n

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.<\/p>\n

    \n
  1. INTEGRATE STAKEHOLDERS \u2013 through domain-appropriate abstractions, notations, and views.
    \nModels should be easily understandable, clear, and informative for participants and those responsible.
    \nThe use of these should increase and simplify project understanding and avoid misunderstandings and complications.<\/li>\n
  2. Aim for long-lasting models \u2013 through the right abstractions, separation of concerns, and appropriate style guides.
    \nModels should evolve from the idea and requirements to the generation of outcomes (e.g., source code, tools, documentation) and be the sole determining factor.
    \nModels or model parts should be designed in such a way (abstract, unambiguous) that reuse is possible elsewhere without modification.<\/li>\n
  3. CREATE VALIDABLE, TRANSFORMABLE AND EXECUTIVE MODELS \u2013 through semantically well-defined language for functional and non-functional aspects.
    \nModels should be described in such a language that they can be unambiguously converted by machine into other forms (e.g. views, extracts, \u2026) without changing any information.
    \nThe scope should be as comprehensive and detailed as possible in order to generate tests, directly executable code, or simulations.<\/li>\n
  4. FRONT-LOADING \u2013 use models for early knowledge acquisition.
    \nModels should be used as early as possible, e.g. in the process of generating ideas and requirements.
    \nAdvantageously, these offer different perspectives, even realistic simulations.<\/li>\n
  5. AVOID DUPLICATION AND UNNECESSARY REPEATS \u2013 through automation and integration of models of different aspects.
    \nModels should ideally contain all types of information, but only in one location. Duplication\/mutation should occur through referencing\/inheritance.
    \nModels and their application methods (profiles) should consistently avoid redundancy of information, e.g. through visualization and thus reuse.<\/li>\n
  6. MAKE MODELING EASILY ACCESSIBLE \u2013 through scalable, user-friendly and easy-to-learn tools and infrastructure.
    \nModel-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.
    \nComplicated, unsuitable (with regard to the domain), excessively extensive tools or toolchains should be avoided.<\/li>\n
  7. ESTABLISH A MODELING CULTURE \u2013 through education, training and integration with the development process.
    \nModel-based development should be understood as the standard method, and its use should be favored, adequately trained, and supported by management levels.<\/li>\n<\/ol>\n

    \u00a04. Examining the relationship between developer mindset and tool<\/h2>\n

    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 \u2013 80 % Pain rule).<\/p>\n

    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.<\/p>\n

    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."\u201e<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Whether UML, SysML, DSL, or custom approaches: We in the field are now aware \u2013 and we all agree \u2013 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.<\/p>\n

    5. Conclusion<\/h2>\n

    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.<\/p>\n

    \u201eThere 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.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    6. Outlook, goals of the initiatives and further activities<\/h2>\n

    The following activities will be jointly promoted as part of the MDSE initiative:<\/p>\n