Skip to main content

Mit dem Flugzeug zum Nachbarn, mit dem Fahrrad nach NewYork

Ja, das hört sich idiotisch an, aber nur aus einem Grund, wir kennen beide Vorgehen sehr gut und können Aufwand und Nutzen genau abschätzen.

Anders sähe es aus, wenn wir uns für den Einsatz einer Methode zur Fortbewegung entscheiden sollten, die einem Paradigmenwechsel entspricht mit dem wir keinerlei Erfahrung haben. Und damit sind wir beim eigentlichen Dilemma angelangt und dem was der Titel zum Ausdruck bringen sollte.

Dieser Frage geht diese Ausgabe des Software Engineering Reports nach.

Was macht einen Paradigmenwechsel aus? Im Wesentlichen, dass es sich nicht um eine lineare Entwicklung handelt, sondern um eine sprunghafte. Das bedeutet auch, dass unsere bisherigen Erfahrungsmuster, nach denen wir Entscheidungen treffen, nicht mehr gelten. Das wiederum erhöht die Wahrscheinlichkeit von ungünstigen Entscheidungen. Eine ungünstig getroffene Entscheidung führt in Folge zu Erfahrung. Mit dem Grad der Erfahrung verbessert sich dann wieder die Qualität der Entscheidungen in Richtung ‚günstig’ im Sinn von ‚förderlich‘ bezogen auf das Ziel, das erreicht werden soll.

Die spannende Frage ist, können wir Erfahrungen nutzen oder müssen wir sie grundsätzlich selber durchleben? 

Was unterscheidet ein Paradigmenwechsel von einer Optimierung?

Bei einem Paradigmenwechsel ändern sich die gelernten Gesetzmäßigkeiten sprunghaft. Unsere bisherigen Entscheidungsgrundlagen
greifen nicht mehr, die Anzahl tendentiell ungünstiger Entscheidungen steigt.

Was zeichnet einen Paradigmenwechsel aus, wie kann er angegangen werden und vor allem wann ist der richtige Zeitpunkt?

Gehen wir im wahrsten Sinn des Wortes noch einmal einen Schritt zurück im Paradigma, der Fortbewegung mit den Füßen. In Afrika gibt es noch sehr viele Menschen, bei denen diese Paradigma Hauptfortbewegungsmittel ist.

Nehmen wir z.B. Äthiopien oder Kenia. Aus diesen beiden Ländern kommen die besten Läufer der Welt. Sie haben das Laufen zur Perfektion entwickelt. Sie können sowohl extrem lange Distanzen überbrücken, als auch hohe Geschwindigkeiten erreichen.

Wie sind sie dazu gekommen? Es gibt dort schlicht keine anderen Fortbewegungsmittel bzw. ist deren notwendige Infrastruktur nicht finanzierbar.

Nicht selten läuft dort ein Kind jeden Tag 5 km zur Schule und wieder zurück. Wer das macht hat Laufstiel, Kondition etc. hochgradig optimiert. Stellen wir uns nun vor die Schule im Nachbardorf wird geschlossen und die nächste Schule ist 10 km entfernt. Dann würde dieses Kind wahrscheinlich seine Kondition an die neue Entfernung anpassen, früher aufstehen und später nach hause kommen und evtl. in der Schule nicht mehr ganz so aufmerksam sein. Das Kind ist begabt und soll nun eine gehobene Schule besuchen. Diese ist 15 km entfernt. Das Kind steht noch früher auf und kommt noch später nach Hause, bekommt Muskelkater der wieder vergeht, schläft evtl. in der Schule hin und wieder ein, und hat weniger Zeit für Hausaufgaben, was nicht vergeht, sondern schlechten Einfluss auf die Leistungen hat. Der Grund für Letzteres ist nicht das Laufen an sich, sondern ein latenter Zeit- und Schlafmangel.

Denken wir obiges Modell konsequent zu Ende könnte uns folgende Erkenntnis ereilen: Es kommt irgendwann der Punkt an dem die physikalische Grenze erreicht ist, spätestens, wenn die reine Laufzeit länger, als 24 Std. dauern würde, wäre keine Zeit mehr für die Teilnahme am Unterricht übrig. Aber zu diesem Punkt wird es niemals kommen, bereits vorher kollabiert das System in Folge von divergenten Symptomen, die offensichtlich erst einmal wenig mit dem Laufen in Zusammenhang stehen. Es ist also ein schleichender Prozess der Verschlimmerung. 

Es gibt also nur sich häufende latente, unspezifische Symptome, die das Gesamtsystem ineffizient machen. Sie
stehen jedoch selten mit dem Vorgehen in direktem Zusammenhang. Das wäre evtl. eine Sehnenscheiden-Entzündung durch Überlastung.

∨ mehr Text anzeigen

Vergleichen wir obiges Paradigma mit dem Paradigma Fahrradfahren, dann wird ersichtlich, wir können das Paradigma zu Fuß gehen, noch so optimieren, wir erreichen niemals die Leistungsfähigkeit des Fahrradfahrens.

Im Triathlon lassen sich die Paradigmen sehr gut vergleichen. Wir können davon ausgehen, das beide Paradigmen innerhalb eines Triathlons von der selben Person gleichwertig optimiert angewandt werden.

Hier stehen, bei vergleichbaren Bedingungen, 42 km laufen mit einer Zeit von ca. 2:30 Std dem Radfahren 180 km mit Zeiten von 4:00 Std gegenüber. Das entspricht eine Vervierfachung der Distanz bei gleichzeitiger Verdopplung der Geschwindigkeit. Erkennen Sie den Unterschied zur Optimierung einer Methode? Da sprechen wir von einer prozentualen Verbesserung. Ein Paradigmenwechsel liefert Faktoren. In der Regel liegt das Potential eines Paradigmenwechsels Faktor 10 über dem einer Optimierung. Manchmal werden auch Paradigmen übersprungen, (von zu Fuss gehen direkt zur Nutzung eines KFZ‘s) dann sind schnell auch Sprünge um Faktor 100 möglich.

Leider stehen dem Effizienzgewinn von Faktor 10 in der Regel auch Faktor 10 höhere Investitionen zur Einführungdes Paradigmas und der notwendigen Infrastruktur gegenüber. Erschwerend kommt hinzu, dass basierend auf unseren bisherigen Erfahrungen und Vorstellungen die Investitionen wie eine Schallmauer erscheinen. Bisher wurde eine Entscheidung dieser Dimension noch nicht getroffen, wir begeben uns komplett auf Neuland.

Diese Dimension der Investitionen sind der häufigste Grund, warum der Schritt zu einem neuen Paradigma nicht zum optimalen Zeitpunkt gemacht wird. Es fehlen Erfahrungen, das Risiko ungünstige Entscheidungen zu treffen ist groß und damit auch das Risiko als Auswirkung ein ganzes Projekt zu gefährden und im Zweifel hängt daran sogar noch der Arbeitsplatz. Daraus resultiert die verständliche Neigung das Risiko zu minimieren und den großen Schritt in kleinere Schritte zu teilen.

Noch größer wird der Unterschied, wenn wir das Paradigma Autofahren nehmen. Es muss ein Führerschein gemacht werden, Versicherungen und Steuer bezahlt, ein PKW angeschafft werden, ganz abgesehen von der allgemeinen Infrastruktur, Straßen, Energieversorgung ...

Das gleiche gilt im Softwareengineering. Die Basis-Kosten für die Einführung einer MDSE Umgebung liegen um ein vielfaches über den Kosten einer Umgebung zur prozeduralen Programmierung mit einer Hochsprache bezüglich Infrastruktur und Kenntnissen und Erfahrungen in der praktischen Anwendung.

Zurück zum Schulkind, würde ein rechtzeitiger Umstieg auf das Paradigma Fahrradfahren den doppelten Schulweg sogar hyperkompensieren. Unter Umständen käme es sogar zu positiven Begleiteffekten, z.B. weil das Kind mehr Zeit für Hausaufgaben hätte.

Aber leider gibt es da auch noch die Kehrseite der Medaille. Die Basis Investitionen für den erfolgreichen Einsatz eines leistungsfähigeren Paradigmas liegen erheblich über denen des vorherigen. Laufschuhe (150,- €) stehen einem Fahrrad (1.500,- €) gegenüber oder gar einem KFZ (15.000,- €). Und natürlich würde ein Läufer auf einem Fahrrad nicht sofort Spitzenleistungen vollbringen. Er müsste andere Muskeln trainieren evtl. erst einmal fahrradfahren lernen … Eventuell müsste überhaupt eine geeignete Infrastruktur verfügbar sein, z.B. mit dem Fahrrad befahrbare Wege, mit dem KFZ befahrbare Straßen, Führerschein, Versicherung Treibstoffversorgung .…

Paradigmenwechsel bedingen deutlich höhere Aufwendungen zur Einführung und zum Erhalt der notwendigen Infrastruktur.

 Interessant erscheint jedoch, so groß die anfänglichen Vorbehalte sind, niemand, der beide Paradigmen beherrscht, käme auf die Idee aus diesem Grund bei Distanzen über 200 km die Sinnhaftigkeit eines PKW‘s gegenüber Laufen in Frage zu stellen. Auf der anderen Seite kämen wir auch nicht auf die Idee das Auto zu nutzen, wenn wir zum Nachbarn möchten. 

Das neue Paradigma ersetzt das alte niemals vollständig. Es ergänzt es in den Situationen, in denen das vorherige an seine Grenzen stößt. Maximal überlappen sich die Anwendung der Paradigmen in Grenzsituationen.

Stellen wir uns noch einmal den Wechsel zum Beispiel vom Fahrrad auf das Paradigma Auto vor. Wenn Sie den Beweis haben möchten, ob das Paradigma größere Distanzen in kürzerer Zeit zu überbrücken wirklich funktioniert und erst einmal eine Karosserie, um Ihren Pedalantrieb anschaffen bevor Sie in einen teuren Motor investieren, werden Sie den zweiten Schritt wahrscheinlich niemals tun und den Versuch als gescheitert abbrechen. Denn mit großer Sicherheit sind Sie mit obiger Apparatur langsamer, als mit dem Fahrrad an sich. Auch umgekehrt in Ihr Fahrrad einen Ottomotor zu bauen wird nur eingeschränkte Erfolge zeigen. Wenn nicht gleichzeitig Rahmen, Bremsen … angepasst werden kann das sogar tödlich enden.

Paradigmenwechsel sind Sprünge, sie verlaufen nicht linear, und lassen sich nicht in kleine Schritte aufteilen. Das ist aber was sehr häufig versucht wird, um das Risiko einer Fehlinvestition zu minimieren. Erst einmal lediglich die UML nehmen, um die Software bildhaft darzustellen. Sein wir doch einmal ehrlich, bildhaft darstellen, das machen wir doch schon lange. Immer wenn wir über Software sprechen zeichnen wir Grafiken an Flipcharts oder Diagramme in Visio. Was sollte sich ändern, wenn wir das selbe nun in UML tun? Das Hauptproblem bei diesem Vorgehen ist doch, dass Doku und Code auseinander laufen und daran ändert sich nichts.

Oder die Anschaffung eines grafischen UML Editors ohne die Möglichkeit der Modell Simulation. Das ist wie ein Auto ohne Motor. Ja sie werden nun nicht mehr nass, wenn es regnet (auch ein Vorteil), aber das eigentliche Ziel schneller, weitere Distanzen zu überwinden, werden Sie nicht validieren können, weil sie es auf diese Art niemals erreichen werden. 

Warum lässt sich ein Paradigmenwechsel schlecht in kleine Schritte aufteilen?

Paradigmenwechsel in kleine Schritte aufzuteilen funktioniert nur sehr begrenzt. In der Praxis ist es in der Regel hinaus geschmissenes Geld, weil die damit verbundenen Aufwändungen nicht amortisiert werden. Evtl. ist es sogar gefährlich, weil eine Fehlbeurteilung des möglichen Nutzen stattfindet und der Paradigmenwechsel abgebrochen wird und damit eine notwendige Entwicklung nicht stattfinden kann.

Und nun die positive und negative Nachricht zugleich. MDSE ist ein Paradigmenwechsel. Ja, er ermöglicht Effizienzsteigerung um Faktoren, und ja und die notwendige Infrastruktur ist nicht für wenige 100,- € zu haben, und genau so wenig wie es ausreichend war ein ANSI C Handbuch zu lesen, um danach ein erfahrener effizienter C-Programmierer zu sein, reicht es nicht, ein 3-tägiges UML Seminar zu besuchen, um danach ein erfahrener, effizienter Modellierer zu sein.

Aber die Investitionen lohnen sich dennoch, wie dutzende Projekte zeigen, in denen unsere Kunden in den letzten Jahren den Einstieg in MDSE konsequent gewagt haben.

Was sind die konkreten Vorteile von MDSE (z.B. in der Notation UML) verglichen mit der Programmierung in ‚C‘?

Werfen wir dazu noch einmal einen kurzen Blick auf die zu bewältigende Herausforderungen. Es gilt die steigende Komplexität zu
bewältigen. Dabei sind Hidden Links, Emergenz und Disfunktion die Hauptmerkmale, mit denen sich Komplexität in seiner negativen Form zeigt. Sie führen uns durch folgende Betrachtungen, in denen ich auszugsweise vier Aspekte darstelle. 

Include-Beziehungen und Component-Based Design

Teile und herrsche ist der meist eingesetzte Engineering-Schritt Komplexität zu begegnen. In C wird dem mit Modulen und Funktionen begegnet. Jedes Mal, wenn ein System in kleinere Komponenten geteilt wird verringert sich die Komplexität in den Komponenten, aber im Gegenzug entstehen Schnittstellen. Ein Teil der Komplexität wird dabei auf die Beziehungsebene verschoben. (siehe auch Engineering Report Nr. 33)

In ANSI C wird die Struktur der Beziehungen durch Include-Beziehungen repräsentiert. Diese Struktur ist jedoch nicht explizit zu sehen und lästig zu managen, was dazu führt, dass in den meisten Projekten über eine globale Include-Struktur alles mit allem in Beziehung steht. Das führt dazu, dass auch alles mit allem kommunizieren kann, was zu sogenannten ‚Hidden Links‘ führt. Diese Hidden Links erhöhen bei Änderungen das Risiko für Emergenz (Systeme kommen in nicht gewollte Zustände), die in Folge das Risiko für Fehlverhalten erhöhen.

In UML können Beziehungsstrukturen ganz gezielt grafisch modelliert werden. Daraus werden eindeutige Include-Beziehungen in C generiert. Wenn ein Programmierer nicht dieser InterfaceStruktur folgt wird spätestens der Linker die Arbeit versagen.

Das ist eine sehr effiziente Hilfe Hidden Links vorzubeugen.

Durch grafische Visualisierung und daraus erzeugten Include-Beziehungen lassen sich sehr effektiv Hidden Links vermeiden, was bei steigender Komplexität weniger häufig zu Emergenz und Disfunktion führt.

Spezifikation und Test Automatisierung

Die Notation UML besitzt, im Gegensatz zu herkömmlichen Hochsprachen, wie ANSI C oder C++, Notationselemente, die die Spezifikation von Systemen adressieren (UML Diagramme zur Spezifikation sind UseCase-, Sequenz- und Timing-Diagramme; natürlich können auch andere UML Diagramme zur Spezifikation genutzt werden, aber das ist nicht ihr ursprünglicher Sinn).

Die Mächtigkeit dieser Diagramme wird häufig unterschätzt. Das liegt auch daran, dass dem Anforderungsmanagement im Allgemeinen nicht besonders viel Aufmerksamkeit geschenkt wird, sondern lieber direkt implementiert wird. Aber spätestens beim Testen werden dann doch die eigentlichen Anforderungen benötigt. Gegen was soll denn bitte schön die Implementation getestet werden?

Also in jedem Projekt wird im eigentlichen Sinn Anforderungsmanagement betrieben. Entweder zum günstigen Zeitpunkt am Anfang des Projektes oder zum weniger günstigen Zeitpunkt am Ende des Projektes, spätestens, wenn die Tests spezifiziert werden (vorausgesetzt, dass überhaupt halbwegs ordentlich getestet wird).

Wenn nun die Spezifikation die Quelle der Tests ist, was läge näher, als die Tests als erstes zu spezifizieren. Genau das ist z.B. auf Basis von Sequenz-Diagrammen möglich. Zum Beginn eines Projektes dienen sie dazu. sich klar zu machen, auf welche Stimuli das System zu reagieren hat, welche Situationen (Zustände) dabei auftreten können und welche Funktionen dann ausgeführt werden müssen. Diese Diagramme können in Folge dann sehr einfach dazu dienen die ersten Implementierungen zu testen. Das Ganze kann, mit geeigneten Werkzeugen, sogar automatisiert in der Nacht geschehen (Nightly Tests).

Das Vorgehen kann auch als TDD (Test Driven Development) angesehen werden, was nachweislich Qualität von Software erhöht. Dieses Vorgehen ist auf Basis von UML und geeigneten Werkzeugen sehr viel einfacher möglich, als auf Basis von Hochsprachen, da die UML bereits über Notationselemente verfügt, die genau diesem Zweck dienen. Hochsprachen vermissen diese Notationselemente im Allgemeinen.

Auf Basis von standardisierten Notationselementen zur Spezifikation von Systemen lassen sich mit geringem
Aufwand automatisierte Tests erstellen. Dieses ist die ideale Voraussetzung für Nightly Tests und Test Driven Design als eine der mächtigsten Instrumente zur Qualitätsabsicherung.

Abstraktion und Muster - Contract Based Design

Zustandsmaschinen repräsentieren die Kombination von Mustern und darauf basierender Abstraktion. Die Visualisierung einer simplen Zustandsmaschine mit zwei Zuständen und zwei Zustandsübergängen auf Basis eines Zustands-Diagramms enthält 5 Symbole (zwei Zustände + einen für den formal notwendigen Default State). Ein korrespondierender Code mit allen notwendigen Implementierungen würde im simpelsten Fall ca. 200 Zeilen lang sein.

Zum Beispiel stellt das Event Handling mit Event Queue ein Muster dar, das genauen Regeln folgt, welche in der Zustandsmaschine
implizit enthalten bzw. berücksichtigt sind. Das Verhalten der Zustandsmaschine lässt sich sehr exakt verstehen, ohne das
Kenntnisse über die genauen Implementationen vorhanden sein müssen. Sehr viel wichtiger sind genaue Kenntnisse über die Regeln (Contract) denen dieses Muster folgt.

Z.B. gibt es die Regel, dass Events, auf die zum aktuellen Zeitpunkt kein Zustand wartet, weggeschmissen werden. Ansonsten würden sie die Queue blockieren. Das macht durchaus Sinn. Wenn die Regel jedoch nicht bekannt ist und beim Design der Zustandsmaschine nicht berücksichtigt wird kann es zu Fehlern führen. Umgekehrt ist es genau so, verhält sich die Implementation des Musters nicht so, wie definiert, führt auch das zu Fehlverhalten.

Leider wird die Notwendigkeit die Spezifikation der Muster sehr gut zu kennen häufig nicht ernst genug genommen und Muster werden nicht derart verwendet, wie sie ursprünglich gedacht waren. Wie mächtig Muster sind kann sehr deutlich erkannt werden, wenn man den generierten Code aus folgenden beiden Zustandsmaschinen betrachtet. Hier ist nicht nur Code hinzugekommen, sondern es bleibt im wahrsten Sinn des Wortes keine Zeile Code mehr auf der anderen. Würde man dieselbe Änderung auf Code-Ebene durchführen würden wahrscheinlich aus Bequemlichkeit die Zustände ‚fast‘ und ‚slow' so genannte Rucksäcke bekommen. Im C-Code würde das auf den ersten Blick naheliegend erscheinen, weil mit geringerem Aufwand verbunden.

Bei einem möglichen zweiten etwas tieferen Blick würde dann festgestellt, dass sich diese Art der Änderung nachteilig, sowohl auf Codegröße, Laufzeit und Verstehbarkeit auswirken und die Komplexität unnötig erhöht. Einem Codegenerator ist der Aufwand der Änderung egal. Er erzeugt in Sekunden-Bruchteilen wieder neuen optimierten und strukturierten Code.

Auf Basis von Abstraktion und Mustern lässt sich Software sehr viel einfacher und vergleichsweise sicherer verstehen, ändern und erweitern, als auf Basis von C-Code. Darüber hinaus lässt sich die inhärente Qualität bei Änderungen und Erweiterungen hoch halten.

Automatisierung ist notwendig, wenn Code Errosion, verursacht durch vermeintlich schnelle händische Änderungen, vorgebeugt werden soll.

Frühe Simulation - Frontloading

Bleiben wir gleich bei der vorherigen Zustandsmaschine. Sehr häufig wird Genauigkeit (Exaktheit) mit Detailliertheit verwechselt. Immer wieder höre ich, dass eine frühe Simulation auf Basis von UML nicht möglich ist, da ja erst simuliert werden kann, wenn das Modell mit ausreichend Details angereichert wurde.

Das ist schlicht falsch. Das Verhalten obiger Zustandsmaschine kann genau in diesem Grad der Detaillierung bereits simuliert werden. Lediglich die Namen der Events müssen derart definiert werden, dass sie kompilierbar sind (Den gültigen Symbol-Definitionen der zukünftigen Action Language folgen).

Dann kann die Logik der Zustandsmaschine simuliert werden. Aber es geht noch weiter, erinnern Sie sich an Spezifikation auf Basis von Sequenz-Diagrammen. Schon zu diesem Zeitpunkt kann getestet werden, ob die Logik der Zustandsmaschine der Definition der Sequenzen entspricht und diese einhält. Das mag bei obigen Zustandsmaschinen banal erscheinen. Aber in der Realität erreichen Zustandsmaschinen schnell eine Komplexität, die von unserem Gehirn nicht mehr vollständig erkannt werden können. Schnell gibt es dutzende möglicher Pfade (Sequenzen) durch eine Zustandsmaschine. Ob diese nach einer Änderung immer noch alle richtig abgebildet werden lässt sich auf Basis von Sequenzdiagrammen sehr schnell und effizient testen.

Alles zusammen ist mehr, als die Summer der Einzelteile

Es ließen sich noch unzählige weitere Vorteile aufzählen, aber es ist nicht notwendig, um aufzuzeigen, dass in
jedem einzelnen Punkt mehrere Elemente des Paradigmenwechsels zusammen wirken. Erst in diesem Zusammenwirken
entfaltet sich das Potential.

Im Wesentlichen sind es folgende Elemente, die immer wieder auftreten

  • Die korrekte Anwendung der Muster in genau dem Sinn, wie sie definiert sind (Contract Based). Ist das nicht gegeben, ist die Anwendung von Mustern eher kontraproduktiv.
  • Abstraktion auf Basis von grafischen Repräsentationen, um die Verstehbarkeit zu erhöhen.
  • Exakte Transformation der Modelle in verschiedene Abstraktionsräume. Datenfluss in Zeitverhalten, Klassen-Struktur in Include-Beziehungen etc.
  • Code Generierung für Simulation und Produktion
  • Backannotation von Laufzeitinformationen, um Debugging auf dem Grad der Abstraktion zu ermöglichen, auf der die Implementation stattfindet und Tests automatisiert werden.

Um nur einige der wichtigsten Wirkmechanismen zu nennen.

Resümee

Der ganz normale Wahnsinn

Stellen Sie sich vor, Sie haben eine Zustandsmaschine in einem grafischen UML Editor gezeichnet. Aus statischer Sicht der grafischen Repräsentanz sind Sie sich sicher, dass diese Zustandsmaschine das tut, was sie soll.

Nun codieren Sie die Zustandsmaschine, compilieren, linken, laden Sie in den Debugger und lassen sie laufen. Auf den ersten Blick scheint alles richtig zu sein.

Aber evtl. sollte doch noch etwas vollständiger getestet werden. Sie arbeiten strukturiert und erstellen sofort die entsprechende Testspezifikation. Aber was musste die Zustandsmaschine noch einmal alles tun können, auf welche Stimuli wie reagieren? Keine Sorge, Sie finden es halbwegs heraus und nach einiger Zeit laufen die ersten Tests und ergeben, dass doch tatsächlich die Reaktion auf einen Stimuli in zwei Zuständen nicht berücksichtigt wurde.

Nun gehen Sie zurück in den grafischen Editor, um die Zustandsmaschine entsprechend anzupassen? Nein ich befürchte das tun Sie nicht, da Sie ja gerade in Ihrer geliebten C-Umgebung sind ist der Code schnell geändert, und wenn die Änderung dann alle Tests passed, dann wird das Diagramm entsprechen nachgezogen.

Als Sie endlich alles am Laufen haben zeigt die Uhr 19:30 und um 20:00 beginnt das Theater‚ im wahrsten Sinn des Wortes mit Ihrer Frau, wenn Sie nicht sofort alles stehen und liegen lassen und Feierabend machen. Nächsten Tag wieder im Büro warten so viele Dinge auf Sie, dass Sie an alles andere denken, als die Zustandsmaschine nachzuziehen.

Es könnte auch so aussehen.

Sie werfen einen Blick auf die bereits spezifizierten Szenarien, die die Zustandsmaschine repräsentieren muss. Überlegen auf welche Stimuli Ihre Zustandsmaschine geändert reagieren muss, und spezifizieren Ihre Überlegungen sofort wieder in den Sequenz-Diagrammen.

Wenn Sie der Meinung sind, dass die neuen Stimuli in allen Sequenzen entsprechend berücksichtigt sind, fangen Sie an die Zustandsmaschine zu ändern (Selbstverständlich in der grafischen Repräsentanz eines Zustands-Diagrammes). Wenn Sie der Meinung sind, dass die Zustandsmaschine alle Sequenzen erfüllt drücken Sie auf einen Knopf, generieren den entsprechenden Code, laden sie in den UML Target Debugger und spielen ein paar Szenarien durch, die Implementation scheint gelungen. Die Uhr zeigt 18:00 früh genug, um Ihre Frau zu überraschen und noch vor dem Theater zum Essen einzuladen.

Am nächsten Morgen haben Sie die Ergebnisse der Nightly Tests in Ihrem Postfach. Sie wurden auf Basis der Sequenzdiagramme automatisch durchlaufen. Die Zustandsmaschine hat in zwei Zuständen auf ein Event nicht reagiert. Ihnen ist sofort klar was Sie übersehen haben. Sie korrigieren die Zustandsmaschine schnell auf DiagrammEbene, generieren Code. Das war es! (Vorausgesetzt Sie haben mit den Änderungen nicht noch einmal einen neuen Fehler eingebaut, aber das würden Sie spätestens morgen früh nach dem nächsten Nightly Test wissen). Spezifikation, Testdefinition, Code … alles ist in sich konsistent - ja und … Sie werden es nicht glauben auch die Dokumentation ;-)

Keine Utopie, das machen unsere Kunden so. Lesen Sie zum Beispiel, wie die Firma Marquardt diesen Schritt durchgeführt hat.

Referenzstudie: Umschalten macht's möglich - Marquardt GmbH

Die Marquardt GmbH als führender Hersteller von elektromechanischen und elektronischen Schaltern und Schaltsystemen optimiert Time-to-Market durch die Einführung von Model Driven Development Methoden und Tools in der Softwareentwicklung.

zur vollständigen Referenzstudie: Umschalten macht's möglich - Marquardt GmbH (PDF)
 

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.