Paradigmenwechsel

Wann lohnt der Technologieumstieg – und wie hilft MBSE dabei?

Seite: 3/3

Anbieter zum Thema

Alles zusammen ist mehr als die Summe der Einzelteile

Es ließen sich noch unzählige weitere Vorteile aufzählen, aber es ist nicht notwendig, um aufzuzeigen, dass in jedem einzelnen Punkt mehrere Elemente des Paradigmenwechsels zusammen wirken. Erst in diesem Zusammenwirken entfaltet sich das Potential. Im Wesentlichen sind es folgende Elemente, die immer wieder auftreten, um nur einige der wichtigsten Wirkmechanismen zu nennen:

  • Die korrekte Anwendung der Muster in genau dem Sinn, wie sie definiert sind (Contract based). Ist das nicht gegeben ist die Anwendung von Mustern eher kontraproduktiv.
  • Abstraktion auf Basis von grafischen Repräsentationen, um die Verstehbarkeit zu erhöhen.
  • Exakte Transformation der Modelle in verschiedene Abstraktionsräume. Datenfluss in Zeitverhalten, Klassen-Struktur in Include-Beziehungen etc.
  • Code Generierung für Simulation und Produktion
  • Backannotation von Laufzeitinformationen, um Debugging auf dem Grad der Abstraktion zu ermöglichen, auf der die Implementation stattfindet und Tests zu automatisieren.

Fazit:

Der ganz normale Wahnsinn

Stellen Sie sich vor, sie haben eine Zustandsmaschine in einem grafischen UML Editor gezeichnet. Aus statischer Sicht der grafischen Repräsentanz sind Sie sich sicher, dass diese Zustandsmaschine das tut, was sie soll. Nun codieren Sie die Zustandsmaschine, compilieren, linken, laden Sie in den Debugger und lassen sie laufen. Auf den ersten Blick scheint alles richtig zu sein. Aber eventuell sollte doch noch etwas vollständiger getestet werden. Sie arbeiten strukturiert und erstellen sofort die entsprechende Testspezifikation. Aber was musste die Zustandsmaschine noch einmal alles tun können, auf welche Stimuli wie reagieren?

Keine Sorge, sie finden es nachträglich wieder heraus und nach einiger Zeit laufen die ersten Tests und ergeben, dass doch tatsächlich die Reaktion auf einen Stimuli in zwei Zuständen nicht berücksichtigt wurde. Nun gehen Sie zurück in den grafischen Editor, um die Zustandsmaschine entsprechend anzupassen? Nein ich befürchte das tun sie nicht, da sie ja gerade in Ihrer geliebten C-Umgebung sind, ist der Code ja schnell geändert, und wenn die Änderung dann alle Tests passed, dann wird das Diagramm entsprechen nachgezogen. Aber als Sie dann endlich alles am Laufen haben, zeigt die Uhr 19:30 und um 20:00 beginnt das Theater‚ im wahrsten Sinn des Wortes mit Ihrer Frau, wenn sie nicht sofort losfahren.

Am nächsten Tag warten im Büro wieder so viele Dinge auf Sie, dass Sie an alles andere denken, aber nicht daran, die Zustandsmaschine nachzuziehen.

Es könnte auch so aussehen

Sie überlegen, auf welche Stimuli Ihre Zustandsmaschine wie reagieren muss, und spezifizieren Ihre Überlegungen sofort in Form von Sequenz-Diagrammen. Wenn Sie der Meinung sind, dass alle wichtigen Stimuli entsprechend berücksichtigt sind, fangen Sie an, die Zustandsmaschine grafisch zu modellieren.

Wenn Sie der Meinung sind, dass die Zustandsmaschine alle Sequenzen erfüllt, drücken Sie auf einen Knopf, generieren den entsprechenden Code, laden Sie in den UML Target Debugger und spielen ein paar Szenarien durch, die Implementation scheint gelungen. Die Uhr zeigt 18:00, genau früh genug, um Ihre Frau zu überraschen und noch vor dem Theater zum Essen einzuladen.

Am nächsten Morgen haben Sie die Ergebnisse der Nightly Tests in Ihrem Postfach. Sie wurden auf Basis der Sequenzdiagramme automatisch erstellt. Die Zustandsmaschine hat in zwei Zuständen auf ein Event nicht reagiert. Sie korrigieren die Zustandsmaschine schnell auf Diagramm-Ebene, generieren Code. Das war es! (Vorausgesetzt Sie haben mit den Änderungen nicht noch einmal einen neuen Fehler eingebaut, aber das würden Sie spätestens morgen früh nach dem nächsten Nightly Test merken).

Spezifikation, Testdefinition, Code … alles ist in sich konsistent - ja und Sie werden es nicht glauben - auch die Dokumentation.

(Dieser Beitrag wurde mit freundlicher Genehmigung der Autoren dem Tagungsband Embedded Software Engineering Kongress 2015 entnommen)

* Walter van der Heiden hat praktische Erfahrung im Bereich Embedded Softwareentwicklung und technisches Coaching in Embedded SW Projekten. Derzeit ist er CTO von Willert Software Tools.

* Andreas Willert beschäftigt sich seit 10 Jahren mit MDD, Requirement Engineering und Qualitätssicherung im Umfeld von Embedded Systemen. Neben der Tätigkeit als Geschäftsführer der Firma Willert Software Tools GmbH gibt er seine Erfahrungen in diesem Umfeld als Autor, Trainer und Referent weiter.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Artikelfiles und Artikellinks

(ID:44117894)