Vom Modell automatisiert zum Code - so geht‘s

Anbieter zum Thema

MicroConsult Academy GmbH

Heitec AG

Eurocircuits GmbH

itemis AG

Metamodell gibt Syntax und Semantik vor

Eine Voraussetzung für eine automatische computergestützte Verarbeitung von Modellen ist, dass das Modell eindeutig ist. Modelle sind wiederum nur dann eindeutig, wenn die zugrunde liegende DSL eindeutig ist. Die DSL wird mit Hilfe eines Metamodells formalisiert. Das Metamodell gibt vor, wie Modelle zu erstellen (Syntax) und zu interpretieren (Semantik) sind. An dieser Stelle soll exemplarisch ein Metamodell für Zustandsmaschinen entwickeln werden.

Eine DSL enthält die typischen Begrifflichkeiten und Konzepte der Domäne. Im Falle von Zustandsmaschinen sind dies unter anderem: Zustandsmaschinen, Zustände, Transitionen, Aktionen und Ereignisse. In der Praxis wird man diese Aufzählung um weitere Begriffe und Konzepte erweitern. Die Beziehungen zwischen den Konzepten werden in einem Metamodell eindeutig festgelegt.

Ein Metamodell für Zustandsmaschinen ist in Bild 2 zu sehen. Anhand des Metamodells wird deutlich, dass jede konkrete Zustandsmaschine beispielsweise mindestens einen Zustand besitzen muss. Die Entscheidung, ob man grafisch oder textuell modellieren möchte, hat Auswirkungen auf das Metamodell.

Validierung auf Modellebene

Da die erstellten Modelle einem formalen Metamodell zugrunde liegen, kann uns der Modelleditor bei der Erstellung der Modelle unterstützen, indem er uns sinnvolle Vorschläge für die Modellierung bietet und uns auf Fehler hinweist. Wenn die Domäne weitere Einschränkungen vorsieht, können diese ebenfalls überprüft werden. Beispielweise können Namenskonvektionen überprüft werden. Bei der Modellierung dynamischer Systeme gelten zusätzliche zeitliche Einschränkungen, welche überprüft werden müssen.

Das Modellierungstool oder das Generatorframework würde diese Tests auf dem Modell ausführen. Etwaige Fehler würden in einer Fehlerliste gelistet. Da das Modell auf einer konzeptionellen, abstrakten Ebene definiert ist, lassen sich Überprüfungen der Konzepte effizient durchführen. Der Test ob ein Zustand existiert, welcher vom Startzustand nicht erreicht werden kann, ist auf der Modellebene um ein vielfaches einfacher durchzuführen.

60 bis 80% automatisch generierter Code möglich

as Modellgetriebene Vorgehen ermöglicht die automatische Generierung von Quelltext-Artefakten. Diese geschieht mithilfe einer Modell-zu-Code genannten Transformation. Hierbei liest ein Parser das Modell ein und instantiiert es im Speicher. Die Generierung erfolgt mit Hilfe von Codeschablonen, welche auch Templates genannt werden. Die Templates werden durch Informationen aus dem instantiierten Modell angereichert.

In unserem Zustandsmaschinenbeispiel werden Implementierungsklassen für C++ generiert (siehe Listing 2). Da der LichtDimmer einen sehr einfachen Automaten beschreibt, kann in diesem Beispiel die vollständige Implementierung des Verhaltens generiert werden.

Je nach Domäne beträgt der Anteil des generieren Programmcodes 60-80%. Die generierten Anteile werden mit Hilfe von manuelle erstellten Programmcode (Gluecode) an die Hardware oder Software angebunden. Die heutigen Generatoren unterstützen die Entwickler bei dem Zusammenfügen der generierten und der manuell erstellten Anteile. Bei Änderungen des Modells werden die manuellen Anteile übernommen, so dass Änderungen des Modells kein Problem mehr darstellen.

Kaum Einschränkungen bei der Zielsprache

Für die meisten MDSD-Generatoren existieren keine Einschränkungen der Zielsprache. Heutige Generatoren behandeln die generierten Artefakte als Text. Alles was sich als Textdatei darstellen lässt, lässt sich von Generatoren generieren. Angefangen bei Assembler, C oder objektorientierten Sprachen wie C++ oder Java. Ebenfalls ist es möglich, Dokumentation oder Tests aus Modellen zu generieren.

Da das modellgetriebene Vorgehen von Technologien abstrahiert, ist es besonders einfach, die Zielplattform zu ändern. So kann beispielsweise die Zielprogrammiersprache durch Austausch der Templates erfolgen. Die Migrationen auf andere Zielplattformen wird so vereinfacht, da die Logik des Systems im Modell verbleibt und alleine die Templates für die neue Plattform angepasst werden müssen.

Modelle können mit Transformationen für verschiedene Zielsprachen oder Hardwareplattformen angepasst werden. Die Transformationen erweitern die Modelle mit Hilfe von Transformationsregeln um technische Aspekte, Implementierungsdetails oder Annahmen, die man für Elemente einer Domäne treffen kann.

Beispiel: Jeder Zustand innerhalb einer Zustandsmaschine besitzt eine Transition zu einem Zustand Error. Diese Transition wird gefeuert, wenn der empfangene Event für diesen Zustand nicht definiert ist. Die Transition kann zur Generierungszeit durch Transformationen dynamisch für jeden Zustand ergänzt werden. Etwaige Abweichungen von dieser Regel müssten dann explizit im Modell festgehalten werden.

Prinzipiell sind beliebig komplexe Transformationen denkbar. Auch mehrere Modelle können bei der Generierung berücksichtigt werden. Neben der grafischen Beschreibung des Verhaltens des LichtDimmers kann eine weitere textuelle Beschreibung des I/O-Mappings vorliegen. Mit diesen beiden Modellen lässt sich der generierte Anteil des Quellcodes des LichtDimmers weiter steigern.

(ID:263552)