Ein Angebot von

Modellierung

Objektorientierung und modellbasierte Werkzeuge

| Autor / Redakteur: Dr. Andreas Wagener, Robert Stemplinger, Markus Pauls* / Martina Hafner

Anteile der Laufzeitumgebung

Innerhalb des Willert Framework werden Zustandsmaschinen und die nötige Eventbehandlung direkt nativ angeboten, d.h. aus Zustandsdiagrammen und den dazu gehörenden Events kann direkt lauffähiger Code erzeugt werden. Da die Reaktion auf jeden Event am Stück abgearbeitet wird (run to completion), können Zustandsmaschinen auch verwendet werden, um quasi gleichzeitige Ereignisse zu serialisieren, indem die Ereignisse in einer Event-Queue einer Zustandsmaschine eingestellt werden – so z.B. für die Bearbeitung von über die serielle Schnittstelle erhaltener Anfragen in Konkurrenz zu intern erzeugten asynchronen Botschaften.

Umsetzung in Rhapsody

Das Gesamtsystem wurde in eine Reihe von parallelen Rhapsody Projekten zerlegt, die je für eine Komponente die Arbeitsumgebung aus Implementierung und Testpaket beinhalteten. Damit können die Komponenten weitgehend getrennt bearbeitet werden – wichtig für die Arbeit im Team.

Die Komponenten wurden dann entsprechend den Abhängigkeiten und Schichten von Beginn an zu Integrationen zusammen gefügt (Top Down) deren Funktionsumfang dann schrittweise wachsen konnte.

Die Basis bildet ein Projekt, in dem lediglich Typ- und Stereotype-Definitionen beheimatet sind die sich aus der Programmierrichtlinie ergeben. Darauf setzten die Fachpakte auf, die je aus der zu entwickelnden Komponente und optional einem Test-Package bestehen. Über das Test-Package können aus dem Fachpaket ausführbare Testkomponenten erzeugt werden, die je nur den Umfang der betrachteten Fachkomponente nutzen. Auf oberster Ebene werden die Komponenten im Integrationsprojekt referenziert.

Integration von C-Code

Für die Integration und die zu erstellenden Binärfiles stellen die Rhapsody Projekte die Build-Umgebung dar. Der gesamte Code wird über die Projekte in ein Projekt der C-Entwicklungsumgebung (hier Keil µVision) verschoben und dort nur gebildet und debuggt. Die exportierten C-Files unterliegen damit nicht dem Konfigurationsmanagement.

Trotzdem müssen auch in C vorliegende Code-Teile wie z.B. gekaufte Kommunikations-Stacks oder die über TargetLink erzeugten Code-Anteile integriert werden. Aufgaben sind dabei, die vorhandenen Codes jeweils aktuell ins C-Projekt zu kopieren, sowie ggf. die Gestaltung von Schnittstellen, um die externen Code-Anteile im Projekt nutzen zu können.

Der erste Teil der Aufgabe gelingt über make-File Erweiterungen die innerhalb der in Rhapsody erstellten Komponenten angelegt werden können und die Kopieranweisungen aufnehmen.

Für die Integration ins Modell wurden typisch Wrapper Klassen angelegt. So kann z.B. mit TargetLink sehr gut ein Regler erstellt werden. Auch können die Parameter und Variablen in je einer klassenartigen Struktur gesammelt und auch an der Funktionsschnittstelle der eigentlichen Rechenroutine verwendet werden. Das so erzeugte C-Modul kann dann als externer Code im Projekt eingebunden werden. Für den Zugriff auf die einzelnen Parameter der Regler-Struktur werden in TargetLink aber keine zur Integration geeigneten Zugriffsmethoden bereitgestellt. Bliebe der Direktzugriff auf die Member der Struktur, oder eben ein Wrapper, der dafür die Read- und Write-Handler bereitstellt und das Wissen über die C-Struktur kapselt.

Vorteile

Das Projekt ist noch nicht abgeschlossen, eine vorläufige Bewertung lässt als Vorteile erkennen:

  • Durch die Strukturierung des Systems über die Mechanismen der OO bleibt der Grundentwurf der Architektur ständig im Blick. Abhängigkeiten werden bewusst gezogen, das Schichtenmodell konsequent eingehalten.
  • Bei sauberer Trennung zwischen den Zeit-getriebenen und den Event-getriebenen Aufgaben des Systems können die Mechanismen der in der Laufzeitumgebung hinterlegten Event-Queues voll zur Geltung kommen. Trotz einer Reihe von Nebenläufigkeiten sind die Entwickler nicht mehr mit den zur Synchronisation nötigen Mechanismen wie Semaphoren und Interrupt-Sperren befasst.
  • Die Lesbarkeit des erzeugten Codes ist grundsätzlich hoch, es bleibt aber die Aufgabe der Entwickler bzw. des Projektleiters darauf zu achten, dass die Komplexität der Methoden und Klassen beherrschbar bleibt. Das Werkzeug leistet dabei keine Unterstützung.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

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

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 44055654 / Entwurf)