Dynamic Symbolic Execution for Semantic Difference Analysis of Component and Connector Architectures

Diese Arbeit untersucht die Anwendung der dynamischen symbolischen Ausführung zur semantischen Differenzanalyse von MontiArc-Architekturen, stellt dabei ein Framework zur Bewertung verschiedener Ausführungsstrategien vor und identifiziert Skalierbarkeit als zentrale Herausforderung für den Einsatz in größeren Systemen.

Johanna Grahl, Bernhard Rumpe, Max Stachon, Sebastian Stüber

Veröffentlicht 2026-03-10
📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

Each language version is independently generated for its own context, not a direct translation.

Stellen Sie sich vor, Sie sind ein Architekt, der zwei fast identische Pläne für ein riesiges, komplexes Gebäude entworfen hat. Der eine Plan ist der alte, der andere der neue. Beide sehen auf den ersten Blick gleich aus, aber im Inneren gibt es winzige Unterschiede. Vielleicht reagiert ein Aufzug im neuen Plan anders, wenn jemand einen bestimmten Knopf drückt, oder eine Tür öffnet sich nur unter bestimmten Bedingungen.

Die Frage ist: Wie finden wir heraus, wo genau sich das Verhalten der beiden Gebäude unterscheidet, ohne jeden einzelnen Stein und jeden Gang einzeln zu prüfen?

Genau dieses Problem lösen die Autoren dieses Papers. Sie haben eine Methode entwickelt, die wie ein super-intelligenter, unermüdlicher Detektiv funktioniert. Hier ist die Erklärung in einfachen Worten:

1. Das Problem: Der "Geister-Test"

In der Softwareentwicklung (besonders bei komplexen Systemen wie in der Luftfahrt oder Robotik) ändern sich Modelle ständig. Manchmal führt eine kleine Änderung dazu, dass das System sich plötzlich völlig anders verhält.
Stellen Sie sich vor, Sie testen zwei Versionen eines Videospieles. In Version A springt der Held, wenn Sie die Leertaste drücken. In Version B springt er auch, aber nur, wenn er vorher nicht im Wasser war. Wenn Sie das Spiel nur zufällig spielen, finden Sie diesen Unterschied vielleicht nie. Sie brauchen einen Test, der alle Möglichkeiten durchspielt.

2. Die Lösung: Der "Zauber-Detektiv" (DSE)

Die Autoren nutzen eine Technik namens Dynamische Symbolische Ausführung (DSE). Das klingt kompliziert, ist aber im Grunde wie ein Detektiv, der zwei Dinge gleichzeitig tut:

  • Der konkrete Spieler: Er spielt das Spiel mit echten Werten (z. B. "Drücke Leertaste jetzt").
  • Der Zauberer: Er hält gleichzeitig einen "Zauberstab" (symbolische Werte) in der Hand. Statt zu sagen "Drücke jetzt", sagt er: "Was passiert, wenn ich irgendeinen Wert drücke?"

Der Detektiv läuft durch das Gebäude (das Computermodell) und notiert sich jeden Weg, den er nimmt. Wenn er an einer Gabelung steht (z. B. "Ist die Zahl größer als 10?"), fragt er seinen Zauberstab: "Kann ich hier auch den anderen Weg gehen?"
Wenn ja, berechnet er genau, welche Zahl er eingeben müsste, um diesen anderen Weg zu erzwingen. Er probiert diese Zahl aus und läuft den neuen Weg ab.

3. Der Vergleich: Der "Differenz-Wächter"

Das Ziel ist nicht nur, das Gebäude zu erkunden, sondern zwei Gebäude zu vergleichen.

  1. Der Detektiv läuft durch das alte Gebäude und merkt sich: "Bei Eingabe X passiert Y."
  2. Dann läuft er mit dem exakt gleichen Eingabe-Signal durch das neue Gebäude.
  3. Der Clou: Wenn das neue Gebäude bei derselben Eingabe ein anderes Ergebnis liefert (z. B. Y statt Z), hat der Detektiv einen "Beweis" (Diff-Witness) gefunden!

Dieser Beweis ist wie ein kleiner Zettel, auf dem steht: "Wenn du genau diesen Knopf drückst, passiert im neuen Plan etwas, das im alten Plan unmöglich war." Das ist extrem wertvoll für Entwickler, um Fehler zu finden oder sicherzustellen, dass Änderungen nicht versehentlich etwas kaputt machen.

4. Die Herausforderung: Der "Labyrinth-Effekt"

Das Problem bei dieser Methode ist die Komplexität.
Stellen Sie sich vor, das Gebäude hat 100 Gänge, und an jedem Gang gibt es 2 Möglichkeiten. Die Anzahl der Wege wächst exponentiell (2 x 2 x 2...).

  • Bei kleinen Gebäuden (kleine Modelle) ist das kein Problem.
  • Bei riesigen Gebäuden (große Systeme) explodiert die Anzahl der Wege. Der Detektiv würde ewig brauchen, um jeden Weg zu prüfen. Das ist wie der Versuch, jeden einzelnen Sandkorn auf einem Strand zu zählen.

Die Autoren haben festgestellt: Ihre Methode funktioniert super für kleine bis mittlere Systeme und findet Unterschiede sehr genau. Aber bei sehr großen Systemen wird sie langsam, weil der Computer zu viel Zeit damit verbringt, alle möglichen Kombinationen durchzurechnen.

5. Die Zukunft: Bessere Strategien

Um das Problem der Langsamkeit zu lösen, schlagen die Autoren vor, den Detektiv schlauer zu machen:

  • Zeitlimit: Wenn der Detektiv bei einer Gabelung zu lange nachdenkt, sagt man ihm: "Okay, dieser Weg ist wahrscheinlich zu kompliziert, lass uns weitermachen."
  • Kombinierte Taktik: Man lässt den Detektiv erst ein paar Wege zufällig ablaufen (wie ein Tourist) und nutzt dann die Zauber-Technik nur für die interessanten Stellen.
  • Parallelarbeit: Statt eines Detektivs könnte man ein ganzes Team von Detektiven schicken, die gleichzeitig verschiedene Flüge des Gebäudes erkunden.

Zusammenfassung

Die Autoren haben ein Werkzeug gebaut, das wie ein automatisierter, allwissender Testläufer funktioniert. Er durchsucht Software-Modelle, findet winzige Unterschiede im Verhalten und sagt uns genau, welche Eingabe diesen Unterschied auslöst.
Es ist wie ein Sicherheitsnetz, das sicherstellt, dass wenn man ein komplexes System umbaut, nichts Wichtiges kaputtgeht oder sich ungewollt verändert. Der einzige Haken ist, dass es bei sehr großen Systemen noch etwas Zeit braucht, um alle Ecken abzuchecken – aber für viele Anwendungen ist es bereits ein mächtiges Werkzeug.