Ein Angebot von

Modellbasiertes System-Engineering, Teil 3: Ein Modell sagt mehr, als 1000 Bilder

| Autor / Redakteur: Andreas Willert / Sebastian Gerstl

Bild 5a: Automatische Transformation und Verifikation von Modellartefakten (Model Check) auf Basis von Metastruktur.
Bild 5a: Automatische Transformation und Verifikation von Modellartefakten (Model Check) auf Basis von Metastruktur. (Bild: Andreas Willert)

Grafische Repräsentanzen alleine machen noch kein Modell aus. Effizient angewandtes MDSE ist in der Lage, künftige Entwicklungen im Model vorauszuahnen und vorausschauend abzubilden. Wie geht das?

Wie wir im zweiten Teil unserer Beitragsreihe zu modellbasiertem System-Engineering bereits festgestellt haben, stellen grafische Repräsentanzen noch kein Modell dar – ein Modell im Sinne von MDSE geht über Grafische Repräsentanzen hinaus. Es besteht eher aus Artefakten und deren Korrelation, die in Summe ein System mit seinen Zusammenhängen repräsentieren und u.a. auch graphisch dargestellt werden können. Wichtig ist, dass die Definition der Artefakte auf einer Metastrukturen basiert. Nur dadurch wird eine automatisierte Verarbeitung, Korrelation, Verifikation etc. der Artefakte und deren Zusammenhänge ermöglicht. Das macht erst ein Modell aus.

Wir wollen das einmal an einem Beispiel exemplarisch aufzeigen. Stellen wir uns vor, es gäbe ein Modellelement ‚Dreieck’. Dieses wird in Form einer Notation (Notationselemente im Sinn eines Muster auf Basis von Regeln und Gesetzmäßigkeiten und einer Metastruktur) abgebildet. Die Metastruktur der Notation würde nicht nur Seitenlängen und Winkel kennen, sondern auch Gesetzmäßigkeiten, wie ‚rechtwinkliges‘ oder ‚gleichschenkliges‘ Dreieck oder so etwas wie den ‚Satz des Pythagoras‘. Und natürlich gäbe es ein Werkzeug, das diese Metastruktur versteht und anwenden kann. Die grafische Repräsentanzen sind nun nur Sichten auf das Model. Diese visualisieren Artefakte und deren Zusammenhänge.

Legen wir z.B. die zwei Seitenlängen ‚a’ ‚b’ und einen Winkel auf Basis eines Editors in einem Datensatz ab, kann ein Werkzeug auf Basis dieser Daten in Kombination mit den Metadaten das Modell um die zwei anderen Winkel und die Länge der 3. Seite automatisch erweitern. (Siehe Bilder 5a und 5b).

Ein gutes Werkzeug erlaubt die Eingabe der Daten in Form der grafischen Repräsentanz und ermittelt automatisch die technischen Artefakte. Bessere Modellierungs-Werkzeuge ermöglichen auch die Eingabe der technischen Artefakte und können daraus verschiedene grafische Sichten automatisch erzeugen. Diese automatisierte Transformation in grafische Sichten verringert den Aufwand für die händische Pflege der Sichten und ist eine elementare Voraussetzung für die konsistente Aussagekraft von Modellen über den gesamten Lebenszyklus des Systems.

Aber es geht noch einen wesentlichen Schritt weiter. Ändern wir nun den Winkel ‚A‘ wird aus dem rechtwinkligen Dreieck evtl. ein gleichseitiges Dreieck. Sollte definiert sein, dass es sich in dieser speziellen Instanz eines Dreiecks um ein rechtwinkliges Dreieck handelt, kann das Modell die Daten gegeneinander korrelieren und uns eine Warnung generieren, dass nun Daten (evtl. Spezifikation und Implementation) in Konflikt stehen. Hier streifen wir bereits einen Aspekt des CBD (Contract Based Design).

Wir sehen also, ein Modell geht weit über die grafische Repräsentanz hinaus und ermöglicht eine weitaus mächtigere automatisierte Korrelation von Artefakten und deren Gesetzmäßigkeiten. Aber um das zu ermöglichen gibt es zwei Grundvorraussetzungen.

  • 1. Modelle basieren auf einer Metastruktur (die Notationen UML und SysML bilden in diesem Sinn eine Metastruktur)
  • 2. Deren präzise Anwendung

Letzteres ist selten der Fall. Was dann passiert sehen Sie, wenn Sie noch einmal einen genaueren Blick auf die Abbildung 3b werfen. Haben Sie dort 28 Streichhölzer gezählt? Das rechte obere Muster wurde nicht präzise angewandt, es stellt 6 Streichhölzer dar. Sie sehen, sobald die Präzision fehlt, ist unser Modell nicht mehr wirklich hilfreich.

Anwendungsfälle gehen mit bestimmtem Vorgehen einher

Modellgetriebenes Engineering geht weit über die Erstellung grafischer Darstellungen von Systemsichten hinaus wenn es das Engineering auf eine neue Ebene bringen soll. Und nur dann kann sie der steigenden Komplexität erfolgreich begegnen.

Dieser Artikel konnte nur einige Aspekte des modellgetriebenen Engineerings oberflächlich beleuchten. Es gibt viele Experten, die sich mit Fragestellungen und Lösungen zur Modellierung von Embedded Systemen auseinandersetzen. Erfahrungen und Erkenntnisse sind zum Beispiel im ‚Manifest Modeling of Embedded Systems‘ dokumentiert und online auf http://www.mdsemanifest.org abrufbar.

Zudem werden die Erkenntniss alljährlich in offenen ‚Open Space‘ Formaten auf der Fachveranstaltung MESCONF (Modelling of Embedded Systems Conference, 7.-8. Juni 2018, München; https://mesconf.de) vorgestellt und diskutiert.

Modellbasiertes System-Engineering, Teil 1: Evolution der Abstraktion

Modellbasiertes System-Engineering, Teil 1: Evolution der Abstraktion

17.04.18 - Software und Systeme werden zunehmend schwieriger versteh- und beherrschbar. Infolgedessen wenden sich immer mehr Entwickler modellgetriebenem Engineering zu. Was gibt es dabei zu beachten? Teil 1 einer dreiteiligen Reihe zu MDSE. lesen

Modellbasiertes System-Engineering, Teil 2: Ausweg aus dem Komplexitäts-Dilemma

Modellbasiertes System-Engineering, Teil 2: Ausweg aus dem Komplexitäts-Dilemma

23.04.18 - Im Laufe der Entwicklung nimmt die Komplexität eines Systems – und damit die Zahl interner Verlinkungen – quasi exponentiell zu. Wie kann mittels Modellierung sinnvoll ein Überblick behalten werden? lesen

* Andreas Willert ist Gründer und CEO der Willert Software Tools GmbH.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45252387 / Software Engineering)