Nebenwirkungen eines modellgetriebenen Softwareprojekts
Wiederverwendung mal anders
Fortsetzung des Artikels von Teil 1
Wiederverwendung mal anders
Wiederverwendung mal anders
Dank der formalisierten Beschreibung des Bus-Protokolls lassen sich Bitmuster erkennen und mit Hilfe der Beschreibung im Modell als Klartext darstellen. In Bild 3 liest das System zum Beispiel den Rohdatenstrom »101011010100000« ein (1) und gleicht ihn mit dem Bus-Modell ab (2), danach stellt ihn die Sniffer-Anwendung als Klartext »read data of channel 5 for slot 1« dar (3). Dadurch lässt sich nicht nur der Datenstrom leichter lesen, sondern weitere Funktionen wie beispielsweise das Filtern nach Merkmalen wie einem bestimmten Kanal oder einem Konfigurationsparameter leichter implementieren.
MDSD != direkte Wiederverwendung
Im vorliegenden Anwendungsfall ließen sich die Modelle eins zu eins wiederverwenden. Bei MDSDProjekten, in denen die Domäne erstmals modelliert wird, sollten Entwickler jedoch Folgendes bedenken: Kommt ein Generator zur Anwendung (oder ein Interpreter für das Modell), dann stellt sich die Frage, an welcher Stelle die Fachlichkeit abzubilden ist. Wenn die Fachlichkeit für den Benutzer variabel ist, sollte sie – wenn möglich – ins Modell. Bleibt sie jedoch immer gleich, bietet es sich an, sie im Generator (oder Interpreter) zu hinterlegen.
Setzt ein zweites Projekt dann auf dieses Modell auf, ist zu prüfen, ob die im Modell hinterlegten Informationen ausreichen oder das Modell zu erweitern ist. Gewonnenes Wissen ist also kein Wegwerfprodukt. Neben den Vorteilen im eigentlichen MDSDProjekt konnte es im Beispiel als Ausgangspunkt für ein neues Anwendungsfeld dienen und ließ sich in einem weiteren Projekt wiederverwenden. Die Formalisierung von Wissen hilft somit nicht nur bei der Erstellung eines Systems, sondern birgt auch neue Möglichkeiten der Verarbeitung.
Jobangebote+ passend zum Thema
- Wiederverwendung mal anders
- Wiederverwendung mal anders
