Author: Andreas Willert, Willert Software Tools<\/p>\n
Model-driven development has recently experienced a surge in interest. The 3GLs (Three Key Models) are still frequently used in software engineering.\u00a0(third generation language, also high-level programming language), w<\/em>The ANSI C standard seems to be increasingly less able to cope with the rising complexity.<\/p>\n The primary driving force is the hope of increasing comprehensibility through graphical representations. Accordingly, pictures are diligently drawn and system components are graphically depicted. And indeed, these graphical representations do help to better understand the systems. However, if this is pursued for some time, another problem comes back like a boomerang.<\/p>\n How can the continuously increasing number of graphical representations, which now exist redundantly to the code, be maintained and kept consistent with the code? The necessary workload exceeds daily capacity.<\/p>\n This article aims to demonstrate that model-driven engineering is far more than just a graphical representation. It also aims to show that simply creating a graphical representation leads to a dead end. While it increases comprehensibility, it comes at the cost of increased redundancy and, consequently, increased maintenance effort. This, in turn, reduces work efficiency.<\/p>\n Only when redundant components are automatically adjusted by tools, changes to a component are automatically correlated with the overall system, tests are automated and code is generated... in other words, when processes and work steps are automated wherever possible, can model-driven development be successful in the long term.<\/p>\n Increasing complexity is the primary reason why our current approach no longer yields the desired results. To understand why and how new methods and principles address this, and how they work, it's helpful to understand how complexity arises and manifests itself. Therefore, I'd like to begin by examining complexity in more detail.<\/p>\n If one believes current theories on complexity, then the main problem lies in the chain of effects:\u00a0Hidden Links -> Emergence -> Dysfunction<\/em>.<\/p>\n This means that hidden dependencies lead to so-called emergent states in relation to other aspects of the system when one aspect of the system changes. The connection between these two aspects is not obvious and forms a hidden link. This, in turn, can lead to malfunctions.<\/p>\n Let's take a step back: how are hidden links created?<\/p>\n A basic mechanism that has been used in engineering for decades to cope with increasing complexity is\u00a0\u201e"Divide and conquer";\u00a0<\/em>in engineering, among other things, also in the form of\u00a0\u201ehierarchical decomposition\u201c<\/em>\u00a0This is applied. Each division of a unit into two subunits potentially creates new interfaces. As shown in the following figure, the number of new interfaces grows polynomially with the number of individual elements as the division increases.<\/p>\n The application of\u00a0\u201e"Divide and conquer"\u201c\u00a0<\/em>This reduces the complexity of a single part, but at the same time increases the complexity of the interfaces between the parts.<\/p>\n So far, we have only considered interfaces on one level and therefore only speak of complexity. In the reality of today's embedded applications, however, this network of relationships exists not only on one level, but in parallel on several levels. To make matters worse, the boundaries between two components, with respect to different levels and\/or perspectives, are not necessarily the same. For example, logical components do not correspond exactly to physical components \u2013 a very good analogy can be seen in the representation of subway networks. The graphical representation of the timetable only very loosely corresponds to the actual route of the subway, but serves to improve understanding (see the accompanying figure).,\u00a0PDF<\/a>).<\/p>\n If we consider software engineering as an example, we are generally dealing with at least the following levels:<\/p>\n From an application perspective, further layers are typically added, for example, in the form of superimposed control flows, such as emergency stop, software update, or service and diagnostic mode. At each layer, interfaces between individual aspects arise, and very few of these are documented in today's systems. Knowledge of these interfaces usually resides in the minds of the developers. If we have frequently enough divided our system into components, and dependencies now crisscross across several of the above layers, we have arrived at complex systems. Then the question arises as to how the change of a single line of code potentially affects the entire system in terms of variants, versions, operating modes, timing, and so on. One of the many consequences in this context: testing efforts seem to explode \u2013 and yet the feeling remains that we haven't tested sufficiently. Thus, we experience the full extent of complexity today in a wide variety of ways.<\/p>\n It is often forgotten that every hierarchical decomposition must be followed by the step of aggregation (combining individual components into a complete system). At this point, at the latest, all interfaces and, above all, their effects within the overall system must once again be homogeneously aligned. If a relationship is overlooked, this marks the beginning of a chain of problems.\u00a0Hidden Links -> Emergence -> Dysfunction.<\/em><\/p>\n To prevent a certain line of thought from arising in the first place:\u00a0\u201e"Divide and conquer"\u201c<\/em>\u00a0is still an indispensable foundation for managing complication and complexity. But for the latter, we also need mechanisms to manage the increased complexity of interfaces.<\/p>\n Neurobiology states that our brain, at a conscious level, can only perceive (comprehend) approximately 7 +\/- 2 artifacts and\/or relationships at any given moment. Compared to the number of potential artifacts and interfaces of complex systems, this isn't very many. Imagine you have 7 artifacts at your fingertips and have logically considered their connections, then an 8th artifact occurs to you. At the same instant, one of the previous artifacts, like a shift in a register, slips out of your focus. And this happens without our conscious awareness. We usually don't realize that we've forgotten something in that moment. Instead, we're under the mistaken impression that we've considered everything. If there happens to be a logical connection between the 8th new artifact and the one that just slipped out, we have a potential situation for the emergence of a\u00a0Hidden Link<\/em>.<\/p>\n When we consider that today's complex systems have thousands of artifacts that can potentially be related across significantly more than 7 levels, it is obvious that it is a fallacy to believe that our brain is capable of fully grasping the possible effects of changes purely through thought.<\/p>\n Furthermore, our memory already fails when it has to spontaneously list the possible connections between a limited selection of artifacts. And now imagine the development of a complex system based on many brains, in which none of the brains knows the entire system with all its potential connections, but only ever parts of the system.<\/p>\n So, if a single brain no longer knows all the connections, the exciting question remains: Which other brains in the team should it consult to be absolutely sure that all dependencies are identified?<\/p>\n Neurobiology reveals something else. Our subconscious would likely be able to help us out of this dilemma, as it appears to closely resemble an optimal memory. However, humanity is not yet able to work deterministically with the subconscious, and until then, we must pursue other avenues if we want to develop complex systems that ultimately behave deterministically.\u00a0(In a\u00a05-minute video on YouTube<\/a>\u00a0Professor Kruse explains very impressively how complexity can be dealt with in the future.<\/em>)<\/em><\/p>\n To efficiently address increasing complexity, the following measures have proven to be fundamentally helpful:<\/p>\n The first measure is based on keeping the network of relationships simple and understandable through appropriate design of the interfaces. We will not pursue this aspect further at this point.<\/p>\n The second measure, Contract-Based Design (CBD), is an excellent way to restrict the possible variations of interfaces and\/or to automatically test them. Although initial approaches were introduced as early as 1985 in the "Eiffel" programming language by Bertrand Meyer, CBD has not yet achieved widespread adoption. Notations such as UML in conjunction with stereotypes offer very good prerequisites for applying Contract-Based Design and thus provide the basis for its wider dissemination. We will not pursue this approach directly here, but will touch upon it in one way or another.<\/p>\n Model-driven development based on 4GL notations also provides a good foundation for the third measure: traceability-based analyses. For example, the UML\/SysML notation recognizes link relationships between notation elements. These link relationships allow for the declaration of connections and, consequently, the generation of meaningful traceability analyses. To store link relationships, the elements to be linked require unique identifiers (UUIDs). 3GL notations, such as C or C++, lack any metastructure elements that can represent these relationships. The editors on which these notations are based also do not offer a solution in this regard.<\/p>\n So how can, for example, a requirement be explicitly linked to a C statement? (Note: The common practice of linking to commit statements of a configuration management system or other dynamic artifacts is not a real solution here \u2013 but that's a completely different topic that would go beyond the scope of this discussion).<\/p>\n This possible measure will also not be part of the following considerations (see accompanying figure).,\u00a0PDF<\/a>).<\/p>\n In the following, we will focus primarily on the 4th measure: abstraction through pattern formation and metastructure through notations such as UML.<\/p>\n Unfortunately, we've reached the 10,000 character limit. As is often the case in these conference proceedings, there isn't enough space to include the full content of my presentation as a paper. If you'd like to read more, you can find the entire paper below.\u00a0link\u00a0<\/a>load.<\/em><\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of modeling\/embedded and real-time software development.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in modeling\/embedded and real-time software development is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\ncomplexity<\/h2>\n
\n
Our brain as a bottleneck<\/h2>\n
A way out of the dilemma<\/h2>\n
\n
\nModeling \u2013 MicroConsult Training & Coaching<\/h2>\n
\nModeling \u2013 Expertise<\/h2>\n