Auswirkungen der Komplexität im Software Engineering, Teil 2

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Grundsätzlich möchte ich 3 Basis-Mechanismen darstellen. Es gibt weitere, aber diese halte ich für essentiell: Teile und Herrsche, Musterbildung und Abstraktion.

Ja, Sie lesen richtig, Teile und Herrsche gehört nach wie vor zu den Hilfsmitteln, um komplexe Systeme besser zu verstehen, trotz obiger Aussagen. Teile und Herrsche kann auf verschiedene Art angewandt werden. Die gebräuchlichsten sind folgende:

• Hierarchische Dekomposition: Aufteilen des Gesamtsystems in kleinere Teile, die überschaubarer sind, hilft überwiegend bei Kompliziertheit.

• Betrachtung des Systems unter verschiedenen Gesichtspunkten bzw. Ebenen (Datenfluss, Zeitverhalten, statische Aufteilung ...). Hilft auch bei Komplexität.

Erstere wird in der Regel bereits angewandt und hilft, wie wir gesehen haben, eher bei komplizierten Systemen. Bei komplexen Systemen kommt sie an ihre Grenzen. Nun greift jedoch die zweite Art Teile und Herrsche anzuwenden. In diesem Fall wird dasselbe System jeweils mit dem Fokus auf eine Ebene betrachtet. So können nacheinander die verschiedenen Gesichtspunkte (z.B. Zeitverhalten, Kommunikation, Varianten ...) betrachtet werden. Das schafft unser Gehirn sehr gut und es erhöht das Verständnis des Gesamtsystems.

Die Anwendung der UML macht genau dieses auf Basis der verschiedenen Diagramm-Typen. Sequence-Diagramme legen den Fokus auf die Kommunikation, Zustands-Diagramme eher auf das logische Verhalten, Timing-Diagramme auf die Zeit, Klassen-Diagramme auf das statische Design ...

Natürlich gibt es eine grundlegende Voraussetzung, damit dieses Prinzip funktioniert. Alle Sichtweisen müssen kongruent den selben Status des Systems darstellen. Das ist einfacher gesagt als getan. Die Aufteilung der Sichtweisen auf verschiedene Ebenen erhöht die Redundanz und diese will bei Änderungen gepflegt werden. Der Aufwand dafür wird häufig unterschätzt. Hier kommen die Werkzeuge ins Spiel. Ein gutes UML-Werkzeug bezieht die redundanten Informationen immer auf Basis eines Repositorys. Zusätzlich prüft es das Modell auf Konsistenz.

Die meisten Werkzeuge geraten beim Letzteren schnell an die Grenzen. Letztendlich hat sich die Model-Simulation oder noch besser Codegenerierung und Ausführung mit Backannotation als die beste Art des Konsistenz-Checks der Modelle herausgestellt. Und nur wenn das Modell in allen Aspekten in sich konsistent ist führt die Betrachtung aus verschiedenen Gesichtspunkten zum Ziel.

Musterbildung

Ich glaube es ist müßig zu fragen, auf Basis welcher der beiden Darbietungen in Bild 1 Sie schneller, und vor allem mit geringerer Fehlerrate, sagen können um wie viel Streichhölzer es sich handelt. Hier sehen Sie die Anwendung von Mustern. Musterbildung ist nach aktuellem Kenntnisstand der mächtigste Mechanismus der Komplexität zu begegnen.

Auch das ist nichts Neues, wird im Software Engineering seit Jahrzehnten erfolgreich angewandt und ist noch lange nicht ausgereizt. Zum Beispiel eine for() Anweisung in ANSI C, die als Muster für eine ganz bestimmte Formation an Assembler-Befehlen steht. In diesem Fall kommt ein weiterer Vorteil hinzu, je nach Microcontroller ist die Ausprägung in Assembler immer wieder unterschiedlich. Die oberste Ebene der Anwendung des Musters bleibt davon unberührt, solange das Muster exakt abgebildet werden kann.

Und es gibt noch einen Turbolader in Bezug auf die Wirkung von Mustern. Das sind Standards. ANSI C hat sich nicht durchgesetzt, weil es die bessere Hochsprache im Vergleich zu PASCAL oder PL/M war. Der Grund war die Standardisierung durch Kernighan und Richie bzw. ANSI, weil damit die Dialektbildung unterbunden wurde und das den Grad der möglichen Wiederverwendung vervielfacht hat.

Ein sehr bekanntes Muster ist Schraube und Mutter auf Basis von Gewinde. Zuerst wurde dieses Muster ohne Norm (Standardisierung) angewandt. Der Nutzen war bereits hier groß, aber erst mit der Standardisierung der metrischen Gewinde verbunden mit Schlüsselweiten hat dessen Anwendung im Maschinenbau zu einem Quantensprung geführt.

Stellen Sie sich einmal vor, jeder Automotive OEM würde noch eigene Gewindesteigungen und Schlüsselweiten nutzen. Wie stände es mit der Effizienz in Produktion und Service? Normen haben einen größeren Nutzen in Bezug zur Komplexität, als allgemein angenommen. Unser Gehirn kann Muster nur dann nutzen, wenn sie gleichförmig sind. Es muss das Muster in und auswendig kennen, mit all seinen möglichen Aspekten. Nur dann kann es in einer Kombination von Mustern schnell deren zusammenwirken assoziieren. Ist die Ausprägung der Muster immer leicht unterschiedlich, steigt die Gefahr von Fehlern exponentiell, bzw. müssen die Muster immer neu antrainiert werden.

Das ist der eigentlich aufwändige Schritt. Das Muster in all seinen Aspekten so verinnerlicht zu haben, dass unser Unterbewusstsein die Ausprägungen korrekt beurteilen kann. Wir nennen das Ergebnis auch Intuition. Unser Unterbewusstsein hilft uns Entscheidungen zu treffen. Wenn Sie mehr dazu erfahren möchten nehmen Sie sich 6 Minuten Zeit für folgendes Video auf Youtube (Wie reagieren Menschen auf wachsende Komplexität? von Peter Kruse)

Und wieder führt uns der Weg zur UML. Die UML ist nüchtern betrachtet nichts weiter als die Standardisierung im Software Engineering von betriebsbewährten Mustern, kombiniert mit Symbolik (UML der OMG, ISO/IEC 19505).

Klassen, Events, Tasks, Timer, Zustände, Signale ... alles Muster, die bereits vor dem Existieren der UML bekannt und erfolgreich eingesetzt wurden. Bis zu diesem Zeitpunkt jedoch immer in unterschiedlichen Ausprägungen. Das U in UML steht für Unified (vereinheitlicht, konsolidiert). Eine der Hauptziele der UML war die Vereinheitlichung der Definition und Anwendung von 4GL Notationen (Room, SDL, SART, ...). In der Praxis bedeutet das die Vereinheitlichung von bereits vielfach erfolgreich angewandten Mustern mit ihrer Symbolik und Ausprägung.

Übrigens ist die UML exakter spezifiziert, als viele Anwender annehmen, bzw. deren Kenntnisstand in der Anwendung ist. Was ich damit sagen will, in der Praxis wird sie meistens sehr unexakt angewandt. Dabei geht ihr Nutzen zu 80% verloren.

Abstraktion

Im Grunde ist Abstraktion lediglich die Kombination von Teile und Herrsche, bezogen auf Ebenen mit Musterbildung. Ein Schaltplan ist ein sehr gutes Beispiel für Abstraktion. Dort gibt es z.B. ein Symbol für einen integrierten Schaltkreis. Dieser integrierte Schaltkreis ist an sich bereits ein kompliziertes Muster. Eingebunden in ein System entsteht Komplexität. Diese ist genau in dem Maße von unserem Gehirn beherrschbar, wie das Gehirn den integrierten Schaltkreis (IC) verinnerlicht hat. Kennt Ihr Gehirn das IC nicht, werden Sie Probleme haben die Schaltung zu verstehen und umgekehrt.

Nichts anderes sind die UML-Notationselemente. Sie sind Muster mit spezifizierten Artefakten. Je genauer Sie die Artefakte eines Musters kennen, und je häufiger Ihr Gehirn dieses Muster angewandt hat, desto besser beherrschen Sie Komplexität. Ist das Muster leicht abgewandelt passieren Fehler. Sie können sich nicht mehr auf Ihre Intuition verlassen (siehe Youtube Video).

Sie sehen also, Normen spielen eine ebenso große Rolle, wie die Muster an sich. Aber wir sind noch nicht am Ende der Abstraktion. Es fehlt noch das bewusste Weglassen von Gesichtspunkten. Erinnern Sie sich? Ein Aspekt der Komplexität waren die multidimensionalen Auswirkungen der Schnittstellen. Die Konzentration auf einen oder wenige Gesichtspunkte des Systems, erhöht die Möglichkeit, dass unser Gehirn diesen Gesichtspunkt vollständig durchdringen kann. (Ist das nicht sinnreich, die Konzentration hilft unserem Gehirn sich zu konzentrieren.)

Natürlich steigt der Arbeitsaufwand. Nun müssen wir Dimension für Dimension betrachten, vorher reichte ein Blick auf den C-Code. Wenn der Arbeitsaufwand steigt, warum lohnt sich dieses Vorgehen trotzdem? Das erschließt sich durch den so genanten Front Loading-Effekt. Er basiert auf der Tatsache, dass Fehler, je später sie gefunden werden, ein vielfaches an Aufwand und Kosten verursachen. Es lohnt sich also in frühen Phasen mehr Aufwand zu treiben, wenn auf diese Weise Fehler früher gefunden werden. Also lieber früher gründlicher Arbeiten und damit Rückrufaktionen zu vermeiden.

Resümee

Das Wachstum der Komplexität geschieht schleichend. Kennen Sie den Versuch, bei dem Biologen einen Frosch in 50 °C heißes Wasser setzen. Der Frosch hüpft sofort wieder heraus und überlebt. Dann setzen sie einen Frosch in kaltes Wasser, was dann langsam erhitzt wird. Wenn es dem Frosch zu warm wird und er herausspringen möchte, ist seine Muskulatur bereits überhitzt und er kann die Kraft nicht mehr aufbringen. Die meisten Frösche können dann nicht mehr springen und sterben.

Es ist wissenschaftlich bewiesen: Schleichende Prozesse führen häufiger zum Exodus, als abrupte Veränderungen. Nehmen Sie die Entwicklung der Komplexität im Software Engineering ernst. In den meisten Firmen, in denen ich Einblick in die Entwicklung habe, besteht die Neigung das Wachstum der Komplexität zu unterschätzen und zu spät darauf zu reagieren. Ich hoffe es geht am Ende nicht wie mit den Fröschen aus.

In diesem Zusammenhang ist im Software Engineering ein Paradigmenwechsel von der Programmierung zur Modellierung notwendig, um der steigenden Komplexität nachhaltig zu begegnen. Solch ein Schritt ist kein Klacks. Ein Paradigmenwechsel ermöglicht nicht nur einen Quantensprung in der Bewältigung von Komplexität, er bedeutet auch einen Quantensprung an Kosten und Einarbeitung. Das ist wahrscheinlich der Hauptgrund, warum er so lange vor sich hergeschoben wird.

Wer im Unternehmen kann die Entscheidung für einen Paradigmenwechsel treffen? Oder anders gefragt, wer im Unternehmen trifft die Entscheidung SAP einzuführen? Buchhalter und kaufmännische Angestellte? Oder das gehobene Management?

Das gleiche gilt für außerordentliche Investitionen im Software Engineering. Die Ingenieure können das Management lediglich darauf hinweisen, dass die gegebenen Arbeitsmittel der Komplexität nicht mehr gewachsen sind und Empfehlungen für notwendige Schritte aussprechen (und das sollten sie auch tun). Die Entscheidung über die Freistellung der notwendigen Mittel muss das gehobene Management treffen. Es liegt in der Regel auch nicht im Verantwortungsbereich eines Projektleiters, weil sich die Investitionen nicht innerhalb eines Projektes amortisieren und damit im ROI des Projektes und dessen Budget nicht abbildbar sind.

Und: Es macht keinen Sinn Quantensprünge in Häppchen aufzuteilen. Hier gilt das Ganze ist mehr, als die Summe der Einzelteile. Ich würde es noch drastischer formulieren. Halbherzige Schritte bringen wenig Nutzen, verglichen zum Aufwand. Noch schlimmer, die Resultate von halbherzig durchgeführten Paradigmenwechsel verfälschen den Blick auf den Nutzen, und der vollständige Wechsel wird dann in Frage gestellt.

Abschließend noch ein Punkt, der mir sehr wichtig ist: die Kosten. Immer wieder höre ich "das ist aber teuer", wenn es um solide Lösungen geht. Was in Deutschland teuer ist, das sind die Personalkosten. Die Kosten für die Einführung eines neuen Vorgehen inklusive Werkzeugen, Schulung und Coaching, liege bei solider Durchführung in etwa bei den Kosten von zwei Mann-Monaten. Bei nur 20% Effizienzgewinn haben sie sich also nach einem Jahr amortisiert. Dieser Schritt sollte aber für mindestens 5 Jahre Vorteile mit sich bringen. (Ach Entschuldigung, ... ich vergaß ... meine Rechnung ist falsch, die Personalkosten werden ja vom Universum bezahlt.)

Die Entscheidung, ob etwas teuer ist oder nicht sollte von den Mitarbeitern im Unternehmen beurteilt werden, die für die Rentabilität des Gesamtunternehmens verantwortlich sind. Und diese sollten, wenn sie klug sind die Personalkosten mit einbeziehen.

In diesem Sinn wünsche ich Ihnen viel Erfolg in Ihren Projekten, und Mut. Mut von Seiten der Ingenieure das Management zum richtigen Zeitpunkt auf notwendige Maßnahmen hinzuweisen und Mut auf Seiten des Managements die Ressourcen für die erforderlichen Maßnahmen bereitzustellen. Und Klugheit, die Kosten richtig zu beurteilen. Vor allem aber wünsche ich Ihnen Spaß, Erfolg und Zufriedenheit bei Ihrer Arbeit.

Komplexität im Software Engineering, Teil 1

* Andreas Willert ist Geschäftsführer der Willert Software Tools GmbH. Mit freundlicher Genehmigung wurde dieser Beitrag dem Tagungsband Embedded Software Engineering Kongress 2014 entnommen.

(ID:43731984)