Modellierung

Model Driven Software Engineering 2.0

Seite: 3/3

Firmen zum Thema

4. Betrachtung der Beziehung Entwickler-Denkweise-Tool

Auch bei kritischer Betrachtung erscheinen die genannten Thesen durchaus griffig und richtig und können ein Garant für die erfolgreiche Anwendung der MDSE sein. Umso mehr stellt sich die Frage warum doch so oft noch klassisch gearbeitet wird. So gern embedded Softwareentwickler selbst komplexe Dinge und Systeme neu erschaffen, so herrscht doch, entgegen ihrer Kollegen aus der IT, bzgl. der eigenen Arbeitsweise und Werkzeugwahl ein gewisser konservativer Hang. Der über die Jahre liebgewonnene Editor mit projektglobaler, kontextbezogener Eingabe-Vervollständigung scheint "Tool genug" zu sein. Umgesattelt wird oft weniger aus eigenem Antrieb sondern nur, wenn es gar nicht mehr anders geht (20% Gain - 80 % Pain - Regel).

Leider fehlt es aber auch, und das im Gegensatz zu allen anderen Ingenieurswissenschaften, in der Branche der embedded Softwareentwicklung an weitläufig anerkannten Standards und damit der Gewissheit "etwas allgemein etabliert Richtiges" zu tun. Viele modellbasierte Werkzeuge im Maschinenbau und der E-Technik bilden in der Basis Standards ab und ermöglichen deren leichten Einsatz. Diese fehlen in der Embedded Branche bzw. hat jedes Entwicklerteam oft über Jahre gewachsene eigene Standards.

Da Werkzeugentscheidungen immer mehr nach der Prämisse "nur Nichts falsch machen" anstelle von "was nutzt uns am meisten" getroffen werden, haben es die Entscheider schwer. Welche modellbasierte Methode soll man denn verwenden, ohne dass man als Teamleiter bei einer Bauchlandung später zur Rechenschaft gezogen wird? "Bevor ich etwas falsch mache, bleibe ich lieber bei der aktuellen Arbeitsweise, das hat bisher auch halbwegs geklappt".

In der praktischen Anwendung werden mit modellgetriebenen Ansätzen häufig lediglich die statischen Aspekte eines Systems adressiert, z.B. durch die Darstellung von Klassen und deren Beziehungen. Sehr häufig wird auch lediglich die grafische Darstellung genutzt, die dann fast immer formal unkorrekt ist. Diese Ansätze helfen eventuell das schlechte Gewissen zu beruhigen, aber nicht Komplexität zu beherrschen, denn die wirklichen Probleme die durch Komplexität entstehen (Emergenz, Hidden Links, Funktion) werden nicht adressiert.

Eine formal korrekte, dynamische Darstellung der Kommunikation zum Beispiel durch Sequenz Diagramme, eine zeitliche Darstellung der Zusammenhänge durch Timing Diagramme verbunden mit einer frühen Simulation des Systems sind da schon eher geeignet. Dieses und weiteres Potential des MDSE wird in der Praxis noch zu selten ausgenutzt. Das führt leider häufig zu dem Schluss, dass MDSE den erwarteten Nutzen nicht geliefert hat.

Ob UML, SysML, DSL oder eigene Ansätze: Uns Akteuren ist mittlerweile bewusst – und da sind wir uns einig - dass es "die Wahrheit" in dem MDSE nicht gibt. Jede Methode hat Ihre Schwerpunkte und Vorzüge und kann die jeweiligen Anforderungen und Aufgaben mitunter exzellent lösen. Die Modellbasierung hat so viele Gesichter wie Anwendungsgebiete. Einen universellen Werkzeugkasten gibt es nicht bzw. würde dieser stets nur Halblösungen bieten. Dafür ist die Thematik der embedded Softwareentwicklung einfach zu komplex und vielschichtig.

5. Fazit

Unsere Erfahrung zeigt: Es liegt nicht am MDSE an sich, sondern daran wie es umgesetzt und eingesetzt es wird. Dass das Model Driven Development geeignet ist, die eingangs beschriebenen Herausforderungen und Anforderungen unserer Zeit zu managen zeigt sich in den vielen Projekten, in denen MDSE konsequent Erfolge bringt.

"Die beste Methode" in der MDSE gibt es nicht. Stets zeigt der entsprechende Anwendungsfall und die Zielsetzung verschiedene Schwerpunkte auf, die es zu finden und anzupacken gilt. Wohl aber gibt es "die (sieben) besten Vorgehensweisen" bei der Umsetzung einer modellbasierten Methode bzw. mit dieser umzugehen.

Vom Kleinwagen über Traktoren und Lieferwagen zu Rennboliden gibt es eine Vielzahl an Automobilen, die alle Ihren besonderen Zweck hervorragend erfüllen.

Keiner wird das Automobil verteufeln, nur weil er mit einem Sportwagen auf einem Feldweg steckenbleibt oder er durch falsche oder ungeübte Fahrweise einen Unfall verursacht. Vielmehr wird jeder einsehen das passende Fahrzeug zu verwenden UND ... zuerst richtig Fahren zu lernen.

Die Zeit ist reif für MDSE! Nutzen auch wir in der Embedded Software-Entwicklung flächendeckend die Methoden, die für Maschinen und Anlagen seit Langem zum Standard zählen.

6. Ausblick, Ziele der Initiativen und weitere Aktivitäten

Im Rahmen der MDSE-Initiative werden gemeinsam folgende Aktivitäten forciert:

  • Bewusstseinsschärfung für die Wichtigkeit von (embedded) Software auch über betriebliche Hierarchien hinweg
  • Aufbau einer Kultur der modellbasierten (embedded) Softwareentwicklung mit entsprechenden Grundsätzen und Best Practice Ansätzen
  • Erstellen von Publikationen
  • Veranstalten von Kongressen (Mesconf) und Teilnahme bei einschlägigen Events
  • Forcieren von globalen, lokalen bzw. branchenorientierten Treffen
  • Animation zur Beteiligung an der MDSE in verschiedenen Ebenen

Dies alles wollen wir nicht allein tun und fordern daher alle Interessierten dazu auf teilzunehmen und uns ihre Belange (z.B. Erfahrungen, Wünsche, Unterstützungsgesuche) mitzuteilen und sich an Diskussionen zu beteiligen. Fordern Sie uns, uns zu fördern!

* Andreas Foltinek gründete 1994 die Firma IMACS GmbH und ist seither dort als Geschäftsführer für Forschung und Entwicklung verantwortlich. Schwerpunktmäßig beschäftigt er sich aktuell mit neuen Tool-Konzepten sowie der Beratung von Kunden beim Einsatz von OOP UML, MDD, deren praktischen Umsetzung und der hardwareseitigen Integration.

(ID:44106124)