Während in England mit den "Formal Methods" eine Revolution des Software-Engineering in Gestalt einer engen und erfolgreichen Zusammenarbeit zwischen Universität und Industrie begonnen hat, ist die Kluft zwischen industrieller Praxis und den Hochschulen hierzulande größer denn je. Ein neues Qualitätsbewußtsein in der Software-Entwicklung, so Martin Weigele und Jan Peleska*, wird diese Zusammenarbeit fordern. (Teil 2)

Software-Entwicklung erfordert eine Gründlichkeit, die in dieser Form der menschlichen Alltagserfahrung eigentlich fremd ist. Der Hausfrau wird ein Kuchen nicht mißlingen, wenn sie von dem gesamten zum Backen bestimmten Liter Milch ein Gläschen verschüttet Überträgt man das Beispiel auf ein Softwaresystem, so können diese fehlenden 10 Milliliter bereits eine Katastrophe verursachen. Es ist genau dieser Aspekt, der oftmals von wenig erfahrenen Managern mißachtet wird und somit Fehlentscheidungen verursacht.

Wie weit lassen sich Teilprobleme isolieren?

Ein wichtiger Punkt, um diese Eigenschaft der Software-Entwicklung in den Griff zu bekommen, ist die Fragestellung, inwieweit sich unabhängige Teilprobleme isolieren lassen. Damit würde die Möglichkeit steigen, aus einzelnen sicheren Komponenten Nutzen zu ziehen. Diese Frage ist im klassischen Software-Engineering von gleicher Wichtigkeit wie bei der Mathematischen Modellbildung.

Eine Möglichkeit, geeignete Grundbausteine zu schaffen, sind abstrakte Datentypen, wie sie seit längerem im Design von Programmiersprachen mit strengem Typkonzept (zum Beispiel Pascal oder Modula-2) Eingang gefunden haben. Hier zeigt sich der Meister in der Selbstbeschränkung, denn diese Datentypen erlauben nur eingeschränkte, genau bestimmte und somit überschaubare Operationen auf einem Objekt beziehungsweise Objekttyp.

Das Objekt selbst oder ein Objekt eines abstrakten Typs kann nur auf genau festgelegte Weise über die zugehörigen Zugriffsfunktionen gelesen oder geschrieben werden. Damit werden "schmutzige" Operationen von vornherein ausgeschlossen. Dieses Konzept findet sich in verallgemeinerter Form auch in modernen objektorientierten Programmiersprachen wieder.

Abstrakte Datentypen als Grundbausteine oder -objekte haben jedoch bei bestimmten Problemstellungen den Nachteil, daß sie aus der Tradition der herkömmlichen, sequentiellen Programmierung entwickelt wurden. Für Parallel-Verarbeitungsprobleme ist eine Beschreibung, die Prozesse, also Folgen von Ereignissen, zum Ausgangspunkt nimmt, oftmals besser geeignet. Ein Baukasten für solche "kommunizierenden sequentiellen Prozesse" ist am Markt erhältlich.

Eine weitere interessante Variante der Teilverifikation von Systemen, wo solche Prozeßbeschreibungen ebenfalls zum Einsatz kommen können, sind fehlertolerante Systeme. Diese bestehen aus bereits (mehr oder weniger) fertiggestellten Komponenten, die eine gewisse Fehlerwahrscheinlichkeit aufweisen und zu einem Gesamtsystem zusammengefügt werden sollen. Bei dieser Betrachtungsweise werden die fertigen Komponenten nicht mehr genauer unter die Lupe genommen.

Sie sind also in der Regel nicht verifiziert worden und dürfen Hardwarefehler, unter bestimmten Voraussetzungen auch Softwarefehler, enthalten. Wenn in einem solchen fehlertoleranten System einzelne Komponenten ausfallen, muß eine Ersatzkomponente einspringen und die abgebrochene Aufgabe erfolgreich zu Ende führen.

Die Idee besteht nun darin, durch die Verifikation der Kontrollsoftware das "Einspringen" des jeweiligen Ersatzmoduls im Fehlerfalle sicher zu machen. Diese Vorgehensweise ist allerdings nur unter bestimmten Voraussetzungen sinnvoll.

Relativ kurze Einarbeitungszeit

Die mit der verifizierten Kontrollsoftware verbundenen Komponenten oder Module müssen "statistisch unabhängig" sein. Sinnlos wäre zum Beispiel, zwei Rechner im gleichen Takt dieselbe Software fahren zu lassen, um damit Softwarefehlern zu begegnen. Damit würde nur auf einen eventuellen Hardware-Ausfall reagiert. Sind die Programme auf den beiden Rechner in ihren Ausführungszuständen jedoch hinreichend unterschiedlich - zum Beispiel durch Bearbeitung mehrerer Aufgaben, die auf beide Rechner verteilt werden - so besteht, die hohe Wahrscheinlichkeit, daß unterschiedliche Zustandsfolgen durchlaufen werden und somit Softwarefehler ähnlich wie Hardwarefehler behandelt werden können.

Im Fehlerfall kann dann der zweite Rechner kurzfristig die dringenderen Aufgaben mitübernehmen, und die verifizierte Kontrollsoftware sorgt dafür, daß bei der Abwicklung keine zusätzlichen Fehler mehr auftreten können.

Eine verifizierte Verbindung solcher statistisch unabhängigen Subsysteme ist also dafür geeignet, insgesamt ein höheres Vertrauen in die Zuverlässigkeit des Gesamtsystems zu schaffen. Damit wird bereits eine Verbesserung erzielt, obwohl nicht das Gesamtsystem, sondern nur die Kontrollsoftware verifiziert wurde.

Die hier beschriebenen, sogenannten "modellbasierten" Formalen Methoden des Software-Engineering benötigen, wie die Erfahrung bei der Deutschen System Technik GmbH (DST) gezeigt hat, bei Unvoreingenommenheit eine relativ kurze Einarbeitungszeit, um einen praxistauglichen Kenntnisstand zu erreichen. In Versuchen, die zusammen mit der Christian-Albrechts-Universität Kiel durchgeführt wurden, zeigte sich, daß Studenten mit Vordiplom und solider mathematischer Grundausbildung schon nach drei Wochen in der Lage sind, bei der formalen Verifikation von Software "bugs" aufzudecken, die vorher erfahrenen Testteams verborgen blieben.

Austausch zwischen Universität und Industrie

In Großbritannien arbeiten inzwischen zahlreiche industrielle Software-Entwickler mit diesen Entwicklungsmethoden. Eine Führungsrolle, die auch von der Industrie uneingeschränkt anerkannt wird, hat dort die Universität Oxford inne. Als Ergebnis dieser Zusammenarbeit erhielt die Programming Research Group der Universität Oxford gemeinsam mit dem Transputer-Hersteller Inmos Ltd. im Jahr 1990 den Queen's Award für technologische Errungenschaften. Auch findet dort ein reger personeller Austausch zwischen Universität und Industrie statt.

All diese Dinge haben sich wohl ebenso wie der sprichwörtliche angelsächsische Pragmatismus als günstig für das Entstehen einer Schule erwiesen, die sich durch die gelungene Verbindung von Theorie und Praxis auszeichnet.

Hierzulande Domäne der Fachhochschulen

In Deutschland ist diese Verbindung von Theorie und Praxis offenbar fast ausschließlich die Domäne der Fachhochschulen, nicht jedoch der Universitäten. Damit gehen viele Möglichkeiten gegenseitiger Befruchtung verloren, was sehr zu beklagen ist, da die Universitäten Dinge zu bieten haben, die Fachhochschulen nicht leisten können.

Eines der Grundprobleme von seiten der Universität ist die Tatsache, daß dort grundsätzlich nur vollständig "originale" Forschungsarbeiten anerkannt werden. Diese Wissenschaften wie auch Künste umfassende Vorstellung war nicht immer vorherrschend.

Im Bereich der Wissenschaft führt sie inzwischen zu einigen Fehlentwicklungen. So ist es für die akademische Karriere heute oft hilfreich, das Rad zum dutzendsten Male neu zu erfinden und "rundes Dreieck" zu nennen.

Weiter scheint es dem Fortkommen dienlich, die Dinge möglichst kompliziert darzustellen, weil sich sonst leicht herausstellen könnte, daß die Eigenleistung so originell gar nicht ist, denn in Wahrheit ist die Zahl wirklich guter Ideen begrenzt. Eine verbesserte Darstellung guter aber nicht völlig neuer Ideen wird somit nicht unbedingt honoriert. Es ist wohl kein Zufall, wenn an deutschen Universitäten folgerichtig die Lehre meist eher als lästig empfunden und schlecht entlohnt wird.

Diese Haltung ist aber auch Fortschritt der Wissenschaft nicht dienlich, denn der Forschende selbst kann in entsprechenden Veröffentlichungen das "Rauschen" kaum noch von der eigentlichen Information unterscheiden. Leider werden seitens der Praxis diejenigen Wissenschaftler, die sich um eine andere Haltung bemühen, oft mit den anderen in ein- und denselben Topf geworfen.

In der Praxis werden Methoden benötigt, die möglichst klar verständlich und leicht erlernbar sind. Oft bestehen wegen des beschriebenen "Verkomplizierungseffektes" große - zum Teil auch haltlose - Vorurteile gegen alles, was von der Universität kommt. Wirklich gute Forscher haben sich stets gegen unnötige Komplizierungen gewehrt: "Tu es so einfach, wie möglich, aber nicht einfacher!" war die Maxime von Albert Einstein. Auf diese Richtlinie sollten sich beide Seiten ohne Probleme einigen können - leider stehen dem oft politische Interessen entgegen.

Das Beispiel England zeigt in beeindruckender Weise, daß eine solche Vorgehensweise zu gegenseitigem Nutzen möglich und zum weiteren Fortschritt der Informatik nötig ist. Zahlreiche Anregungen für die Fortentwicklung der Wissenschaft können aus ganz praktischen Problemen bezogen werden und den Wissenschaftlern nette, interessante Aufgaben stellen.

Umgekehrt kann auch die Industrie von diesen Lösungen eigentlich nur profitieren. Es wäre also Zeit, daß - wo noch nicht geschehen - endlich die ideologischen Scheuklappen abgelegt und selbstgerechte Positionen geräumt werden, auch um im europäischen Wettbewerb in Wissenschaft und Praxis überhaupt bestehen zu können.

Zweifellos sind mit der Einführung neuer Methoden stets auch Kosten, vor allem Anfangsinvestitionen verbunden. So ist es nötig, etwas Zeit für die Weiterbildung der Mitarbeiter aufzuwenden. Mit der oben beschriebenen, maßvollen mathematischen Vorbildung wird sich der Aufwand für die Einführung der beschriebenen formalen Entwicklungsmethoden aber in Grenzen halten lassen.

Die Testzeit wird erheblich verkürzt

Weitere Kosten schlagen bei der Entwicklung zu Buche. Die reine Entwicklungsperiode kann sich nach den Erfahrungen bei DST gegenüber der "Quick and Dirty - Lösung" bis etwa um den Faktor drei verlängern. Das aber scheint ein, Milchmädchenrechnung zu sein, weil die Gesamtkosten betrachtet werden müssen: Die Testzeit wird nämlich erheblich verkürzt, da viele Fehler von vornherein bei der Spezifikation und deren Verfeinerung erkannt werden können, bevor auch nur eine einzige Zeile Programmiert wurde.

Die Gewährleistung wird erheblich billiger. Nachbesserungen - die berüchtigten Wartungen - können oft entfallen oder reduzieren sich erheblich. Die Wahrscheinlichkeit, Vertragsstrafen auferlegt zu bekommen, läßt sich so deutlich verringern. Zum einen kann das Produkt durch die höhere Zuverlässigkeit den künftigen europäischen Produkthaftungsregeln besser gerecht werden, zum anderen entfällt der Zeitverzug, der beim späten Erkennen von Fehlern durch Testen - zum Beispiel am Tag vor der Auslieferung - auftreten kann, und der die Fertigstellung des Produkts häufig nur sehr kalkulierbar macht.

Anfänglich nötige Investitionen in eine "Spezifikationsbibliothek", aus der dann künftig neue Produkte aus korrekten Einzelbausteinen zusammengebaut werden können, dürfen längerfristig die Kosten noch weiter sinken lassen.

Insgesamt erscheint der Zeit- und Kostenaufwand beim Einsatz formaler Methoden leichter kalkulierbar. Derjenige "DV-Berater" freilich, der in schlitzohriger Manier darauf spekuliert, den Kunden mit "Wartung" über lange Jahre abhängig halten zu können, wird sich mit diesen Methoden nicht anfreunden. Freilich zeigt der Wettbewerb, daß sich solche Praktiken auf Dauer nicht auszahlen, da das Bestreben eines jeden Kunden dahin geht, sich aus solchen Zwängen zu befreien.