Jedermann weiß, daß fehlerfreie Software-Systeme praktisch nicht realisierbar sind. Wie aber ist zu erreichen, daß Software dennoch brauchbar ist? Einerseits gilt es, durch geeignete Maßnahmen die Fehlerquote zu reduzieren, andererseits müssen die Auswirkungen der unvermeidlichen Fehler möglichst klein gehalten werden. In diesem Beitrag wird ausschließlich auf den zweiten Gesichtspunkt eingegangen und eine Lösung vorgestellt, die sich seit Jahren in der Praxis bewährt hat: die selbstkritische Software.

Komplexe Softwaresysteme sind praktisch niemals fehlerfrei. Wie aber kann erreicht werden, daß wenigstens der Schaden, den diese Fehler verursachen, klein bleibt?

Die Antwort ist die "selbstkritische Software',' die eine Lösung aus Fehlerfallen und geeignetem Transaktionskonzept darstellt. Zunächst aber muß geklärt werden, was denn eigentlich ein Fehler ist. Spricht man im Zusammenhang mit DV-Systemen von Fehlern so können Bedienungsfehler, Problem-Lösungsfehler, Spezifikationsfehler oder Systemfehler gemeint sein.

Es gehört zur Aufgabe des Systems, auf Bedienungsfehler sinnvoll zu reagieren, das heißt ein Bedienungsfehler ist nur aus Benutzersicht ein Fehler, aus Systemsicht aber eine durchaus normale Situation.

Problem-Lösungsfehler liegen vor, wenn bei Erstellung des Systems seine Aufgaben teilweise falsch definiert wurden, das Problem der Anwender von den Erstellern des Systems also nicht genau erkannt wurde.

Spezifikationsfehler liegen vor, wenn die Spezifikationen des Systems unvollständig oder widersprüchlich sind. Es ist also unklar was das System genau tun soll.

Bleibt die Klasse der Systemfehler. Nur sie soll im folgenden genauer diskutiert werden.

Als Systemfehler bezeichnet man eine Situation, die nur deswegen entstanden ist, weil das System einen Auftrag wegen nicht ausreichender Betriebsmittel abbrechen mußte (Dimensionierungsfehler) oder weil der das System darstellende Programmcode im Widerspruch zur Systemspezifikation steht (Implementierungsfehler).

Die eben dargestellte Unterscheidung von Systemfehlern in Dimensionierungs- und Implementierungsfehler orientiert sich an der Ursache des Fehlers. Wichtiger noch ist eine Klassifizierung der Systemfehler hinsichtlich des Ausmaßes in dem sie Schaden anrichten.

Zu unterscheiden sind hier System-Ausfall, System-Absturz, gemeldete Systemfehler und geschehene, aber nicht entdeckte Systemfehler. Der Rest dieses Beitrags orientiert sich ausschließlich an dieser zweiten Klassifizierung.

Als Ausfall des Systems bezeichnet man einen Systemfehler, der zur Folge hat, daß das System erst nach Reparatur durch den Wartungsfachmann erneut Benutzer bedienen kann. Die Aussage "System-Ausfall kommt nicht vor" gilt als Teil der Spezifikation des Systems.

Als Absturz des Systems gilt ein Systemfehler, der das System in einen Zustand versetzt, in dem es genau einen neuen Befehl entgegennehmen und auch bearbeiten kann: den Wiederanlauf-Befehl.

Die Aussage "System-Absturz kommt nicht vor gilt als Teil der Spezifikation des Systems.

Es kann sein, daß ein System nach Absturz, und anschließendem Wiederanlauf nur teilweise wieder funktionsfähig ist: Wenn zum Beispiel ein Plattencrash passiert ist, wird es vorerst auf einige Daten nicht mehr zugreifen können. Es kann jetzt zum Beispiel auch verboten sein die einer oder andere Funktion des Systems aufzurufen.

Systemfehler selbst melden

Dieser Mischfall ist (nur aus Sicht jener Benutzer, die nun behindert sind) als partieller System-Ausfall einzustufen.

Die gemeldeten Systemfelder zählen zu der wichtigsten Systemfehlerklasse, Die Aussage "gemeldete Systemfehler treten nicht auf" sollte nicht Teil der Spezifikation des Systems sein: Einfach deswegen, weil die Praxis lehrt, daß Systemfehler mit letzter Sicherheit nicht auszuschließen sind, und weil, wenn ein solcher Fehler auftritt, er nicht Systemabsturz oder gar Systemausfall sein darf.

Letzteres heißt, daß das System das Vorliegen eines Systemfehlers selbst melden können sollte am besten unter Beigabe passender Diagnose-Information. Und es sollte auch in der Lage sein, nach dieser Meldung weitere Befehle des Benutzers entgegenzunehmen.

Daher wird definiert:

Gemeldete Systemfehler sind Systemfehler, die das System selbst erkennt und dem Benutzer meldet. Es ist anschließend in der Lage, weitere Befehle entgegenzunehmen ganz so als wäre nichts geschehen. Daß ein Systemfehler aufgetreten ist, wird nur jenen Benutzern bewußt, an die die Meldung geht - alle anderen arbeiten wie gewohnt.

Besonders wichtig ist, daß beim Auftreten eines gemeldeten Systemfehlers die betreffende Transaktion voll ungeschehen gemacht werden kann. Hierdurch wird erreicht, daß solche Fehler die vom System verwalteten Daten nicht inkonsistent machen können.

Geschehene, aber nicht entdeckte Systemfehler richten den größten Schaden an: Tritt einer von ihnen auf, so wird die betroffene Transaktion scheinbar korrekt beendet mit dem Effekt, daß die manipulierten Daten nun bleibend inkonsistent sind.

Mehr noch: Der Anwender weiß bis auf weiteres nichts von diesem Defekt. Er wird erst dann merken, wenn irgendwann in der Zukunft Folgefehler entdeckt werden.

Je später ein Systemfehler entdeckt wird desto größer ist der durch ihn angerichtete Schaden. Aus diesem Grund sollte jeder Fehler bereits durch das System selbst entdeckt werden und zwar vor Ende der Transaktion, die ihn verursacht hat. Kurz: Jeder Fehler sollte gemeldeter Systemfehler sein!

Wie aber kann man das erreichen? Es gibt nur eine Antwort: Jeder Baustein des Software-Systems muß eigenverantwortlich der sorgen, daß er alle Fehlersituationen erkennt, abfängt und an den Aufrufer weitermeldet.

Systemfehler dürfen keine Daten zerstören

Die verwendeten Fehlerfallen haben so effizient zu arbeiten, daß sie auch im realen Betrieb nicht abgeschaltet werden müssen. Sie sind ja keineswegs nur Testhilfe, sondern vor allem ein Mechanismus zum

Schutz der vom System verwalteten Daten und auch ein Mechanismus, um in der Software vorhandene Fehler so bald wie möglich zu erkennen. Man bedenke:

- Einerseits bringt jede Behebung eines Softwarefehlers bleibende Verbesserung des Systems. - Andererseits waren Softwarefehler, dort wo sie auftreten, von Anfang an vorhanden - und haben vielleicht schon wertvolle Daten verunreinigt.

Das Fehler erkennen allein aber reicht nicht! Wird ein Fehler entdeckt, so sind die Daten in aller Regeln schon inkonsistent. Dieser Zustand muß behoben werden! Das System selbst muß die Konsistenz der Daten wieder herstellen. Es kann dazu nur in der Lage sein, wenn es sich einem geeigneten Transaktionskonzept unterwirft.

"Geeignet" bedeutet, daß die Transaktion (= Befehlsfolgen, deren Wirkung unteilbar ist) hinreichend groß zu sein haben, so groß, daß man beim Entdecken eines Fehlers davon ausgehen kann, daß die Daten zu Beginn der Transaktion noch konsistent waren. Daraus ergibt sich die Mindestanforderung:

Kein Aufruf an der externen Schnittstelle des Systems darf bei seiner Abarbeitung in zwei oder mehrere Transaktionen zerfallen.

Wird dann bei Erledigung eines Aufrufs ein Fehler entdeckt, so wird das System diesen Fehler nicht nur melden - und damit Ausfall oder Absturz vermeiden - sondern daneben auch sofort jenen Zustand wieder herstellen, der vor dem Aufruf bestand. Damit ist erreicht, daß zumindest entdeckte Systemfehler keine Daten zerstören können.

Software heißt somit selbstkritisch, wenn jeder Fehler ein gemeldeter Fehler ist und das Softwaresystem nach Auftreten eines Fehlers immer wieder in einen konsistenten Zustand gebracht werden kann.

* Helmut Abbenhardt ist Gruppenleiter, Dr. Gebhard Greiter Projektleiter bei der Softlab GmbH in München.