Nebenwirkungen eines modellgetriebenen Softwareprojekts Wiederverwendung mal anders

Modellgetriebene Softwareentwicklung? Das ist doch das Erzeugen von Quellcode aus Modellen! Soweit richtig, doch konsequent verfolgt, bietet dieser Ansatz viel mehr Möglichkeiten, beispielsweise den Einsatz erfolgreicher Modelle in weiteren Folgeprojekten.

Aus Modellen Quellcode und weitere Artefakte zu erzeugen, ist eine etablierte Praxis in Softwareentwicklungsprojekten. Beispiele sind das Generieren von C-Code aus Blockschaltdiagrammen oder die Erzeugung von Dokumenten aus XML. Die modellgetriebene Entwicklung (MDSD, model driven software development) lässt sich jedoch noch weiter treiben, bis zu einem Punkt, wo Systeme fast vollständig durch Modelle beschrieben und generiert werden. Die Modelle müssen nach einem erfolgreich durchgeführten solchen MDSD-Projekt nicht verstauben, sondern lassen sich in einem weiteren Projekt gewinnbringend einsetzen.

Im Rahmen eines abgeschlossenen MDSD-Projekts des Elektronikdienstleisters BMK [1] entstand die Software für eine I/O-Karte, die über ein Bussystem mit einer Leitstandsoftware kommuniziert. Diese I/O-Karte besteht aus mehreren, einzeln ansteuerbaren Komponenten (siehe Bild 1). Modelle, die zur Beschreibung dieses Umfelds dienen, bilden somit das Bus-Protokoll, die Systeme und ihre Komponenten ab (Bild 2). Bei näherer Betrachtung eignen sich die Ergebnisse der Modellierung jedoch noch für einen weiteren Anwendungsfall: Mit ihrer Hilfe lassen sich mitgehörte Nachrichten auf dem Bus in ein Format übersetzen, in dem Teile der Nachricht ihrer Bedeutung nach aufgeschlüsselt sind.

Projekt: Sniffer

Bisher war das Mithören beziehungsweise Mitschneiden auf der Datenstromebene angesiedelt, Rohdaten wurden also als Hex- Werte aufgezeichnet, die anschließend »von Hand« mit Hilfe des Spezifikationsdokuments des Busses den einzelnen Nachrichten zugeordnet werden mussten. Dieses nicht automatisierte Verfahren bringt jedoch eine Reihe von Nachteilen wie Fehleranfälligkeit und hohen Zeitaufwand mit sich. Um an dieser Stelle eine bessere Lösung zu schaffen, griffen die Entwickler auf ein Projekt aus dem gleichen technischen Umfeld zurück.

In diesem Projekt war die Abbildung der Bus-Spezifikation mit Hilfe des textuellen Modellierungsframeworks »Xtext« [2] erfolgt. Somit lässt sich das so entstandene Modell für das Erkennen der Nachrichten verwenden. Auf dieser Grundlage setzt das Folgeprojekt »Sniffer« auf, das eine Rich-Client-Anwendung auf Basis von »Eclipse RCP« [3] realisiert, die den Datenstrom für den Benutzer besser lesbar macht und die genannten Nachteile ausräumt.