Skip to main content

MDSE in der Praxis. Eine Standortbestimmung.

Die Google-Suche nach ,Model Driven Software Engineering‘ liefert über 9 Millionen Treffer.

,Model Driven Development‘ liefert über 63 Millionen Treffer. Die Suche nach ,Programmierung‘ liefert 14 Millionen Treffer, und nach ,C Programmiersprache‘ 15 Millionen Treffer.

Ich deute das als einen Hinweis, dass das Interesse zum Thema modellgetriebenes Engineering aktuell groß ist.

Folgt man dem obersten Eintrag des Suchergebnisses nach ,Model Driven Development‘ zu Wikipedia, dann kann dort unter anderem folgendes nachgelesen werden:

,Da sich die Metamodelle, und damit die Modelle, in der Regel auf Teilaspekte der abzubildenden Wirklichkeit beschränken, wird oft nur ein Rahmen (Datenstrukturen, Schnittstellen, Funktionsrümpfe, etc.) erzeugt, welcher noch von Hand um die tatsächliche Funktion ergänzt werden muss. Dies führt dazu, dass der tatsächliche Projektaufwand deutlich unterschätzt werden kann.‘

Dieses ist ein Beispiel von vielen weiteren Aussagen im Internet, die mir zeigen, dass der Grundgedanke von MDD bzw. MDSD in vielen Fällen nicht wirklich verinnerlicht wurde. In diesem Embedded Software Engineering Report schreibe ich meine Gedanken zu diesem aktuellen Thema.

Was sind Modelle?

Modelle kennt sicherlich jeder, zum Beispiel in Form von Spielzeug aus seiner Kindheit. In meiner Generation waren es erst Matchbox und später Wiking Autos. Matchbox Autos waren eher zum Spielen für Kinder gedacht, Wiking zum Sammeln für ausgewachsene Kinder. Dementsprechend waren die Unterschiede. Matchbox robust aus Metall aufgebaut und nicht ganz so detailgetreu. Wiking sehr detailgetreu aus Kunstoff, zerbrechlich und zum Spielen ungeeignet, eigentlich nur für die Vitrine gedacht, oder für die Modelleisenbahn. Und da sind wir schon beim nächsten Modell.

Als Modell wird in der Regel das vereinfachte Abbild eines Objektes aus der Realität verstanden. Es stellt das reale Objekt unter einem bestimmten Gesichtspunkt dar. In diesem kommt es ihm so nahe wie möglich. Andere Gesichtspunkte werden bewusst vereinfacht oder gar nicht repräsentiert.

Spielzeug Modelle sind zum Spielen gedacht und haben verschiedene Ausprägungen. In erster Instanz sind sie wesentlich kleiner und preiswerter als die Originale. Einfache Modelle bilden nur die Form ab, sie haben keine eigenständige Funktion. Andere Modelle haben auch Funktion. So muss z.B. ein Matchbox Auto zum Spielen geschoben werden. Demgegenüber gib es auch ferngesteuerte Schiffsmodelle, die dem Original inclusive Funktion und Sound so nahe wie möglich kommen. Als einziger Unterschied erscheint bei diesen Modellen beinahe nur noch die Größe.

Im Zeitalter von elektronischen Datenverarbeitungs Maschinen gibt es eine weitere Art von Modellen. Software Modelle, die eine sehr komplexe Abbildungen der Realität ermöglichen. Mit ihnen können komplexe Vorgänge in Zeitraffer simuliert oder in Crashtests simuliert werden, ohne dabei teure Hardware zu zerstören.

Auf der anderen Seite können Modelle auch ganz simpel sein, z.B. Papierflugzeuge. Heute werden auch grafische Darstellungen als Modell angesehen, zum Beispiel, wenn sie einen Aspekt veranschaulichen, der dadurch besser verstehbar wird, indem andere Aspekte bewusst weggelassen werden.

Was mit Spielzeug-Modellen bezweckt werden soll ist klar, aber warum Modelle im Engineering?

Definitionen

Model Driven Development

Grundsätzlich gibt es eine sehr große und dadurch verwirrende Begrifflichkeit.
Der wohl ursprünglichste Begriff war MDD (Model Driven Development)

Heute verwendete Begriffe, die sich zum Teil in ihrer Bedeutung überschneiden und zum Teil andere Engineering Domänen ansprechen:

MDSE (Model Driven Software Engineering)

MDSE (Model Driven Systems Engineering)

MDSD (Model Driven Software Development)

MDE (Model Driven Engineering)

MBSE (Modell Based Software Engineering)

MDD (Modell Driven Development)

Wozu dienen Modelle

Modelle werden im Engineering seit Jahrzehnten sehr erfolgreich genutzt, um ein besseres Verständnis über bestimmte Aspekte der Realität zu bekommen.

Zum Beispiel wird der Aspekt der Stromlinienform und des Windwiderstandes auf Basis eines Modells in einem Windkanal gewonnen, das nur die äußere Form repräsentiert, die für den Windwiderstand wesentlich verantwortlich ist. Ein Modell kann sehr viel günstiger und mit erheblich weniger Aufwand erstellt und verändert werden, als das originale Objekt. In Versuchen können dann Erfahrungen gesammelt oder die Korrektheit von Annahmen bestätigt werden.

Auf Basis von Modellen ist die Absicherung von Theorien nicht nur sehr viel preiswerter, sondern auch sehr viel früher im Entwicklungsprozess möglich. Das verringert neben den Kosten vor allem auch das Risiko von Entwicklungen und verkürzt die Entwicklungszeit.

In der klassischen Produktentwicklung auf Basis von Hardware werden die Modelle ausschließlich bis zur Serienreife genutzt. Danach werden sie nicht mehr benötigt und haben ausgedient. In diesem Sinn wird in ein Modell nur das investiert was notwendig ist, um das Ziel, die Erkenntnis, zu erreichen. Danach wird das Modell in der Regel nicht weiter genutzt.

Im Software Engineering ist die Situation etwas anders. Es fehlt die eigentliche Produktion. Daraus ergibt sich auch in Bezug auf die Verwendung eines Modells ein elementarer Unterschied. Bezogen auf Software Engineering ergeben sich folgende geänderte Voraussetzungen zur Erstellung und Verwendung von Modellen.

  • Es entstehen keine Materialkosten. Aus diesem Grund ist das Modell nicht aus einem billigerem Material, als die zu produzierende Software.
  • Software unterliegt keinem Verschleiß und keiner Abnutzung.
  • Software wird bei Versuchen nicht zerstört, wie z.B. Materie bei einem Crashtest.

Das legt nahe, dass Modelle (oder Teile davon) im Software Engineering, für die Entwicklung der Seriensoftware, weiter genutzt werden. Natürlich gibt es im übertragenen Sinn auch bei Software Kostenunterschiede zwischen Modell und Serienprodukt, ähnlich der Qualität des Materials, z.B. in Form von Software Qualitätsattributen wie Wartbarkeit, Robustheit, Architektur ...

Die Wiederverwendung setzt voraus, dass die Qualitätsattribute des Modells dem SerienCode entsprechen. Auf Grund obiger Eigenschaften von Software lohnt es sich trotzdem den Aufwand zu treiben die Modelle gleich in der entsprechenden Qualität zu entwickeln und dann weiter zu verwenden. Dieses setzt jedoch ein anderes Vorgehen voraus, auf das ich später zu sprechen komme.

Kommen wir zurück auf den eigentlichen Sinn von Modellen im Engineering, die frühzeitige Absicherung einer technischen Realisierbarkeit. Hieraus ergeben sich Anforderungen an die Modelle.

Anforderungen an Modelle im Sinn von MDSE

Gerade im Software Engineering erlebe ich immer häufiger, dass MDSE auf Basis von nicht ausführbaren UML Modellen praktiziert wird. Ich bin der Meinung, dass hier viel Potential verschenkt wird.

Natürlich können Sachverhalte allein mit grafischen Darstellungen, z.B. in Form von Zustandsmaschinen anstelle von Code, verstehbarer werden und dieses Vorgehen hat Vorteile. Aber in der Praxis zeigt sich, dass die meisten Irrtümer erst bei der dynamischen Ausführung oder zumindest der Simulation erkannt werden. Hierzu möchte ich ein einfaches Beispiel heranziehen.

Stellen Sie sich vor, sie sollen eine Stoppuhr designen. Das Produkt Marketing hat folgende Anforderungen zur Bedienung vorgegeben:

Die Stoppuhr hat einen Taster mit dem sie gestartet, gestoppt und resettet werden kann. Kurzes Drücken des Tasters startet bzw. stoppt die Uhr. Drücken länger als 2 Sekunden setzt die Uhr auf 00:00 zurück.

In den Sequenz-Diagrammen (Abbild. 1) ist das Starten / Stoppen und das Resetten zur Bedienung der Uhr dargestellt. Bevor sie weiter lesen werfen Sie einmal einen Blick darauf. Ist die Funktion der Uhr so korrekt?

Schauen Sie ruhig noch einmal genau hin!

Diese Frage habe ich in Workshops und Präsentationen sicher schon einigen tausend Teilnehmern und Zuhörern gestellt. Lediglich zwei Personen ist bisher aufgefallen, dass in diesem Design die Stoppuhr erst beim Loslassen des Tasters startet, da erst gemessen wird ob die Taste lange oder kurz gedrückt ist. In der Realität startet eine Stoppur aber für gewöhnlich sofort beim Drücken. Wenn jemand ein Modell der Uhr real bedienen kann fällt es über 50% der Bediener auf.

Was verdeutlicht dieses Beispiel?

∨ mehr Text anzeigen

  • Zum einen, dass die Spezifikation der Stoppuhr unvollständig war. Es gibt keine Aussage darüber, wann exakt bei der Bedienung die Uhr gestartet werden muss.
  • Diese Spezifikations-Lücke fällt auch bei einer grafischen Repräsentanz nur sehr wenigen Beteiligten auf.
  • Erst bei der Ausführung des Verhaltens erhöht sich die Erkenntnis signifikant.

Sogar bei derart einfachen logischen Abläufen gibt es potential für Spezifikationslücken, die nicht sofort erkannt werden, auch nicht in einer erweiterten grafischen Darstellung. Wie ist es da erst bei komplexeren Systemen? Ein großer Anteil der Spezifikationslücken wird erst in der Simulation von Modellen erkannt bzw. zu erweiterten Erkenntnissen führen.

Frühes Erkennen von Fehlannahmen auf Basis von Modellen ist eines der Haupt-Ziele von MDSE. Aus meiner Erfahrung ist die frühe Ausführung (Simulation) der Modelle ein wichtiges Hilfsmittel diese Ziele zu erreichen.

MDSE, der Prozessanteil

Im Grunde ist das Vorgehen des MDSE (auf Grund dessen, dass Modelle wiederverwendet und inkrementell weiter entwickelt werden) geprägt vom Spiralmodell und einer kontinuierlichen Weiterentwicklung der Modelle bis zur Serienreife. Dieses geschieht häufig aus der Sicht folgender Herangehensweisen:

  • Validierung der Architektur: Das Modell beschränkt sich auf Komponenten, deren Schnittstellen und evtl. noch das grobe logische Verhalten. In Spiralen werden die Komponenten um immer mehr DetailImplementationen verfeinert. Hier wird vom ganzen System als Grobdesign ausgegangen und in Richtung Feindesign weiterentwickelt.
  • Validierung einer speziellen Technologie: Das Modell beinhaltet zuerst implementierte Teilfunktionen. In Spiralen wird es um weitere Funktionen ergänzt. Hier wird von kritischen Teilen des Systems im Feindesign ausgegangen und dann um immer weitere Komponenten ergänzt.

Das Modell wird im Software Engineering nicht mehr wie in der Mechanik im Sinn eines Versuchsaufbaus verstanden, der am Ende der Entwicklung ausgedient hat, sondern das Modell wird schrittweise zum Prototypen weiter entwickelt und bildet am Ende das Serienprodukt. Das macht einen wesentlichen Unterschied des MDD im Software Engineering gegenüber anderen Disziplinen aus. Hierfür ist eine elementare Voraussetzung, dass die Qualitätsattribute des Modells denen des Serien Code entsprechen. Auf der anderen Seite wollen wir ja früher Erkenntnisse sammeln, also gar nicht viel Aufwand in qualitativ hochwertigen Code stecken. Ist das nicht ein Widerspruch? Mit den alten Produktivmitteln (z.B. der Programmierung in einer Hochsprache) ist das tatsächlich ein Widerspruch. Ende der 80er Jahre hat es schon einmal einen ähnlichen Ansatz gegeben, das ,Rapide Prototyping‘.

Dieser Ansatz hat sich aus zwei Gründen nicht durchsetzen können.

  • Basis für das Vorgehen war die Codierung in einer Hochsprache und selbst die Quick 'n Dirty Programmierung eines aussagekräftigen Prototypen verursachte oft mehr Aufwand als geplant bis die wesentlichen Aspekte umgesetzt waren.
  • Ist dann am Ende mehr Aufwand, als ursprünglich geplant in einen Prototypen geflossen, wurde dieser nicht weggeschmissen, sondern für die Realsoftware weiterverwendet. Er entsprach dann aber nicht der geforderten Qualität. Die nachträgliche Verbesserung der Qualität wiederum war aufwändiger als erwartet bzw. wird nie erreicht.

Nach einem anfänglichen Boom hat sich dieses Vorgehen nicht durchsetzen können.

Heute sind wir einen Schritt weiter. Mit 4G oder DSL Notationen (4GL - fourth generation language, bzw. DSL - domain specific language, z.B. UML, SDL) können aussagekräftige Modelle mit sehr viel weniger Aufwand erstellt werden, als auf Basis von 3GL Notationen (third generation languages z.B. ANSI-C, Pascal). Diese Modelle können heute mit Codegeneratoren automatisch in 3GL Notationen transformiert werden. Der generierte Code entspricht bei guten Codegeneratoren ohne Mehraufwand sofort der Produktions-Qualität.

Auf Basis von 4GL Notationen lassen sich also die scheinbar paradoxen Anforderungen, Erstellung von Modellen mit geringerem Aufwand und der geforderten Produktionsqualität vereinbaren.

Das eröffnet eine neue Dimension des Engineering und hat die Tür zum MDSE geöffnet.

Definitionen

4GL

Als fourth generation language oder kurz 4GL bezeichnet man Programmiersprachen bzw. Programmierumgebungen der vierten Generation. Diese sind darauf ausgerichtet, rasch – mit möglichst wenigen Codezeilen – für einen bestimmten Anwendungsbereich Funktionen oder komplette Anwendungen schreiben zu können.

Der Begriff 4GL ist nicht exakt definiert und wird vor allem für Marketingzwecke eingesetzt. Gemeinsames Hauptziel aller 4GL ist es jedoch, im Vergleich mit Sprachen der dritten Generation dieselbe Funktionalität mit weniger Code zu erreichen. Der Begriff wurde in den 1980er Jahren häufig verwendet, wobei oft auf eine bestimmte Thematik festgelegte, anwendungsspezifische Skriptsprachen als 4GL Sprachen bezeichnet wurden. Später wurde der Begriff Rapid Application Development (RAD) mit überlappender Semantik angewandt. Inzwischen zeigt sich immer mehr, dass anwendungsspezifische Skriptsprachen nur der Input für eine 4GL Sprache sind. Das heißt, die eigentliche 4GL Sprache wird dazu verwendet, ein System zu spezifizieren, das seinerseits eine spezifische Skriptsprache interpretieren kann. Sogenannte Parser-Generatoren, wie zum Beispiel X2X erlauben es für jeden Zweck eine eigene Skriptsprache zu definieren und die damit erstellten Skripte in den Sourcecode einer Hochsprache der dritten Generation zu transformieren. Da eine anwendungsspezifische Skriptsprache im Wesentlichen immer zur Festlegung eines spezifisches Modells einer bestimmten Thematik dient, spricht man hier in letzter Zeit vermehrt auch von der modellbasierten Softwareentwicklung bzw. von "modellgetriebener Softwareentwicklung".

Bei den ersten Sprachen der dritten Generation (z.B.: Fortran, Pascal und C) stand die Einführung von standardisierten Kontrollstrukturen im Vordergrund. Dem folgte das Erstellen umfangreicher Programmbibliotheken mit zusätzlichen Bausteinen, wie sie häufig in spezialisierten Anwendungen vorkommen. Die nachfolgenden objektorientierten Programmiersprachen wie beispielsweise C++ und Java brachten große Fortschritte in der verbesserten Softwarestrukturierung mit sich. Parallel dazu entstanden immer mehr grafische Editoren, die in ihrer Semantik für bestimmte Anwendungsbereiche optimiert wurden, um den Zugriff auf die zugehörigen Programmbibliotheken zu vereinfachen. In besonders gelungenen Fällen entstand dabei eine sogenannte visuelle Sprache. Da diese nicht mehr eindeutig den Hochspachen der dritten Generation zugeordnet werden konnten, wurden diese oft bereits als 4GL Sprache bezeichnet, wobei zwischen der eigentlichen "Sprache" und dem System, das eine solche Sprache interpretieren kann, nicht unterschieden wurde.

Die Bezeichnung 4GL wurde stark von James Martin propagiert. Er benutzte sie zuerst 1982 in seinem Buch Application Development Without Programmers („Anwendungsentwicklung ohne Programmierer“). Diese Deutung kommt aber erst in neuerer Zeit mit der modellbasierten Softwareentwicklung wirklich zum Tragen.

Quelle: Wikipedia

Das allgemeine Vorgehen des MDSE entspricht also folgenden Schritten:

  1. Ermitteln der Anteile der Software, die ein hohes technisches Risiko beinhalten bzw. in denen die Beseitigung von Spezifikationslücken im weiteren Verlauf des Projektes besonders hohen Aufwand verursachen.
  2. Abbildung dieser Softwareanteile auf Basis eines Modells
  3. Test des Modells
  4. Gegebenenfalls Anpassung oder Optimierung des Modells
  5. Production-Code-Generierung

Dieser Zyklus wiederholt sich nun, bis die vollständige Funktionalität der Software implementiert ist. Besonderes Augenmerk ist dabei dem 1. Schritt zu widmen. Die spannende Frage ist: Was sind die risikoreichen Anteile der Software?

Mögliche Bereiche sind:

  • Technisch komplexe Algorithmen.
  • Algorithmen, die neue Techniken beinhalten, zu denen noch keine Erfahrungen existieren.
  • Die Architektur der Applikation (Änderungen in der Architektur sind später im Projekt nur mit hohem Aufwand möglich)
  • User Interfaces (Benutzerfreundlich z.B. kann nur schwierig spezifiziert werden.)

Je nach dem in welchem Bereich das Risiko einer Applikation liegt ist das Vorgehen anders. Ist z.B. eine Steuerung zu entwickeln, die einen Regler beinhaltet, der mit hoch komplexen Umweltfunktionen konfrontiert ist, wird ein Modell des Reglers und seiner Strecke hilfreich sein das Risiko zu senken. Ist es ein komplexes verteiltes System, wird ein Modell der Architektur incl. Schnittstellen hilfreich sein, um das Risiko zu senken.

MDSE Werkzeuge & Notationen

Zur Erstellung eines Modells sind Werkzeuge sehr hilfreich. Die Anforderungen an ein Modell sind sehr Domänen-spezifisch was sich auch in den Werkzeugen ausdrückt. Bleiben wir bei obigen Beispielen, dann unterscheidet sich die Anforderung an ein Werkzeug in Bezug auf die Entwicklung eines Reglers oder die Architektur Validierung grundlegend. Fest verbunden mit Werkzeugen sind in der Regel Notationen. Ein Pascal  Compiler ist wenig hilfreich, wenn Sie die Notation ANSI-C einsetzen möchten. Notationen wiederum sollten im Idealfall standardisiert sein, um zu große Abhängigkeiten zu einem spezifischen Werkzeug und seinem Lieferanten zu verhindern.

Ein sehr weit verbreitetes Werkzeug für MDSE ist Matlab. Dieses zielt genau auf die Entwicklung von Reglern. Wie wir ja schon festgestellt haben liegt einer der großen Vorteile von MDSE darin, Erfahrungen so früh, wie möglich zu machen. Ebenso haben wir festgestellt, dass die Ausführung des Modells z.B. durch eine Simulation dabei grundsätzlich hilfreich ist.

Um einen Regler auszuführen benötigt er eine Strecke, gegen die er regeln kann. Der Entwurf einer Strecke als Modell kann komplexer sein, als der Regler selber. Was hilft mir nun ein Modell, dessen Erstellung komplexer ist als die Entwicklung der Software?

∨ mehr Text anzeigen

Hier ist die Erfolgsschiene von Matlab begründet. Für Matlab existieren bereits sehr viele Modelle zur Abbildung von verschiedenen in der Praxis genutzten Strecken. Ebenso existieren bereits Modelle von verschiedenen technischen Realisierungen von Reglern, die im Wesentlichen nur noch für einen speziellen Einsatzbereich parametriert werden müssen. Die Entwicklung beschränkt sich im Idealfall also auf die Parametrierung von Standard Pattern für einen spezifischen Einsatzbereich. Ein Matlab Modell hilft durch die Simulation die optimalen Parameter schneller zu finden.

Im Fall der Regelungstechnik ist das möglich, da die technischen Elemente dort relativ begrenzt sind. Hier können mit Werkzeugen wie Matlab oder Labview sehr schnell Modelle erstellt werden, die eine Validierung zu einem sehr frühen Status ermöglichen. Seit einigen Jahren gibt es speziell zu Matlab auch Codegeneratoren, die Zielsystem-spezifischen Code generieren, der auch den Qualitätskriterien des so genannten Production-Code‘ entsprechen. Z.B. ,TargetLink‘ von der Firma dSPACE oder der ,Embedded Coder‘ von der Firma MathWorks.

Aber wie verhält sich die Erstellung eines Modells in anderen Fällen? Soll das Design einer Software erstellt werden, dann ist das sehr Applikations-spezifisch. Und auch hier lassen sich auf Basis einer geeigneten Notation sehr effizient Modelle entwickeln. Als Design versteht man überwiegend die statische Aufteilung des Systems in einzelne Komponenten mit der Definition deren Schnittstellen zueinander. Statische Sichtweisen lassen sich nicht dynamisch ausführen. Häufig zeigt sich aber der größere Anteil an Fehlern erst bei der dynamischen Ausführung. Da ist die Frage berechtigt, wie groß der Vorteil ist. Er wird erst im weiteren Verlauf des Prozesses ersichtlich.

Das Design-Modell kann als Kontext der Testumgebung genutzt werden, auf dessen Basis die Verhaltensbeschreibung der einzelnen Komponenten sehr effizient getestet werden kann. Werden die Schnittstellen der Module zum Beispiel auf Basis von Sequenz-Diagrammen spezifiziert, dann bilden diese etwas ähnliches wie die Strecke zu einem Regler. Die Implementation des Verhaltens einer Komponente kann gegen die Sequenzdiagramme getestet werden auch wenn das Verhalten anderer Komponenten noch nicht implementiert ist.

Es kann also der Integrationstest gegen das Modell durchgeführt werden und damit früher stattfinden. Auch hier fungiert das Modell als eine Art Strecke, in dessen Kontext das bereits implementierte Verhalten getestet werden kann. Es gibt also auch hier Vorteile, sie zeigen sich nur etwas später im Prozess.

Auch hierfür bedarf es geeigneter Werkzeuge und auch hier ist es hilfreich, wenn die Transformation der Modelle in eine Simulationsumgebung bzw. zu einem späteren Zeitpunkt in Production-Code nicht von Hand gemacht werden muss, sondern automatisch auf Basis von Codegeneratoren geschieht.

Des weiteren benötigen Werkzeuge die Möglichkeit Verhalten gegen die Spezifikation (Strecke), z.B. auf Basis von Sequenz-Diagrammen, zu testen ohne dafür eigene Testsequenzen zu definieren.

Im Bereich System Design und System Architektur sind Werkzeuge wie Matlab oder Labview denkbar ungeeignet.

Sehr viel geeigneter sind an dieser Stelle UML basierende Modellierungs-Werkzeug wie ,IBM Rational Rhapsody‘ in Kombination mit dem ,TestConductor‘ der Firma BTC und dem ,Embedded UML-RXF‘ Framework der Firma Willert Software Tools. Sie ermöglichen auf Basis der Notation UML auch hier Effizienzgewinn durch MDSE.

Einmal mehr spielt neben den Werkzeugen die Notation eine wesentliche Rolle. Nur wenn geeignete Sprachkonstrukte zur Verfügung stehen, die es ermöglichen ein Design zu spezifizieren, können entsprechende Modelle effizient erstellt werden. Unter diesem Aspekt sind z.B. Sequenz-Diagramme zu sehen. Ein Äquivalent fehlt in allen 3GL Sprachen wie C oder C++, was diese für den Einsatz zur Beschreibung von Modellen im Sinn von MDSE nicht geeignet erscheinen lässt.

Hier sind noch einmal die wichtigsten Anforderungen, die eine Kombination von Notation und Werkzeug im Sinn von MDSE erfüllen muss:

  • Möglichkeit einen Aspekt der Applikation so zu beschreiben, dass er validiert werden kann ohne dass alle Aspekte dargestellt werden müssen. (Vereinfachte Darstellung von Gesichtspunkten der Applikation) Hierfür sind in der Regel 4GL Notationen notwendig.
  • Interpretation der Notation, um eine Validation zu ermöglichen. Das geschieht in der Regel auf Basis der Simulation, allgemeiner ausgedrückt der dynamischen Ausführung des Modells.
  • Ermöglichung neben der eigentlichen Applikation auch die Umwelt (Strecke) effizient zu beschreiben.
  • Unterstützung von Standards, um Modelle auch in einem anderen Kontext nutzen zu können, z.B. zur Automatisierung von Tests.
  • Automatische Transformation der Modelle in Serien Code. Wenn diese Anforderungen erfüllt sind liefern die Werkzeuge in Kombination mit der Notation gute Voraussetzungen beim Einsatz im Kontext von MDSE.

Resümee

Der Einsatz von Modellen im Sinn von MDSE hat sich in den meisten Projekten als zielführend erwiesen, wenn Entwicklungs-Kosten und Entwicklungs-Zeit reduziert werden sollen.

Es ergeben sich jedoch Voraussetzungen an den eingesetzten Prozess, Notation und Werkzeuge.

Das wohl aktuell am häufigsten eingesetzte Vorgehen ist die rein grafische Darstellung von Gesichtspunkten. Dieses hilft auch in der Regel bezüglich dieser Gesichtspunkte frühere Erkenntnisse zu erlangen, darf aber nicht überschätzt werden. Vor allem in späteren Prozessschritten nimmt der Nutzen rapide ab. Vor allem werden die Dokumente schnell inkonsistent zur Realität und werden nicht mehr weiter genutzt.

Sehr viel größeren Nutzen liefern Modelle, die schon frühzeitig dynamisch ausgeführt werden können und dann erst zum Prototypen und danach zum Seriencode weiter entwickelt werden können. Im Idealfall liefern sie auch die Strecken zum Automatisieren von Tests. Hier liegt das eigentliche Potential zur Effizienz- und Qualitätssteigerung durch MDSE. Existentiell sind in diesem Fall der Einsatz geeigneter Notationen und Werkzeuge.

Einen weiteren Aspekt möchte ich abschließend anführen. MDSE verlagert Entwicklungsaufwand in frühere Phasen des Engineerings. Dafür wird in späteren Phasen ein vielfaches dieses Aufwandes eingespart.

Bei der Einführung von MDSE muss diese Hürde genommen werden. Häufig führt die Erwartung von schnellen Erfolgen dazu, das MDSE nicht konsequent eingeführt wird und es wird zum alten Vorgehen zurück gegangen. Hier ist auch die 100% Unterstützung der Firmenleitung eine wichtige Voraussetzung. Nur aus der Entwicklung, ohne Commitment der Unternehmensleitung ist es schwierig MDSE einzuführen.

Wie wir gesehen haben ist der Wechsel von der Programmierung zur Modellierung von Software ebenfalls eine wesentliche Voraussetzung zur vollen Entfaltung des Potentials von MDSE: Darüber mehr in der nächsten Ausgabe des Embedded Software Engineering Reports.

Bis dahin wünsche ich Ihnen viel Erfolg in Ihren Projekten mit und ohne MDSE

Autor:

Andreas Willert
Haben Sie noch Fragen oder Anregungen zum Thema? Dann freue ich mich über eine E-Mail: awillert@willert.de

Herausgeber:

WILLERT SOFTWARE TOOLS GMBH
Hannoversche Straße 21
31675 Bückeburg
E-Mail: info@willert.de
Tel.: +49 5722 9678 - 60

Alle ESE-Reports im Überblick

Aktuelles Know-how und neueste Entwicklungen und Trends rund um das Thema Emedded Software Engineering

> zu den ESE-Reports

Hinweis: Unsere Webseite nutzt Cookies. Wenn Sie fortfahren, nehmen wir an, dass wir Ihre Erlaubnis haben Cookies zu setzen. Informationen zum Einsatz von Cookies sowie unsere Datenschutzbestimmungen finden Sie in unserer Datenschutzerklärung und über unser Impressum.