[<] [globale Übersicht] [Kapitelübersicht] [Stichwortsuche] [>]
Ein Softwarefehler tritt dann auf, wenn ein Softwareprodukt etwas anderes leistet, als der Benützer erwartet.
Für typische Aufgabenstellungen der nicht-numerischen Datenverarbeitung ist es im allgemeinen problemlos möglich, zu entscheiden, ob ein geliefertes Resultat den Anfordeurngen entspricht oder nicht; so kann man z.B. bei einem Sortierprogramm sehr leicht überprüfen ob der Programm-Output tatsächlich dem geforderten Sortierkriterium genügt.
Im Fall numerischer Software ist die Frage, ob ein Programmfehler vorliegt, oft nicht einfach und manchmal überhaupt unmöglich zu beantworten. Diese Schwierigkeit ist nicht oder nur teilweise auf mangelhafte Dokumentation, sondern auf verwendete Heuristiken zurückzuführen.
Heuristik bezeichnet hier Teile von Algorithmen, die nicht auf mathematisch-naturwissenschaftlichen Analysen und Prinzipien beruhen, sondern vom Programmierer eher intuitiv hinzugefügt wurden. Numerische Software enthält fast immer heuristische Abschnitte.
| Beispiel (Numerische Integration) : Viele Programme des Integrationspakets QUADPACK enthalten heuristische Programmteile, um "verrauschte" Integrandenfunktionen (d.h. Integrandenfunktionen, die von stochahistischen Störeinflüssen überlagert sind) ohne großen Rechenaufwand zu erkennen und die Berechnung zu stoppen, sobald keine Genauigkeitsverbesserung durch den iterativen Algorithmus mehr möglich ist. In Spezialfällen -etwa bei extrem stark oszillierenden Integranden- kann es vorkommen, daß ein völlig "ungestörter" Integrand von diesem Programmabschnitt als "gestört"eingestuft wird. Die numerische Integrationsprogramme beruhen alle auf dem Prinzip der punktweisen Abtastung (sampling) der Intergrandenfunktion; auf Grund dieses Abtastvorgangs ist es unmöglich, mit vertretbarem Aufwand stochachistisch gestörte von stark oszillierenden Funktionen zu unterscheiden. Weil jedoch ein noise detector ein praktisch nicht verzichtbarer Algorithmusteil ist, muß hier zu Heuristiken gegriffen werden. |
Die Funktionsüberprüfung numerischer Software durch Tests und Verifikation bereitet besondere Schwierigkeiten.
Im mathematisch-analytischen Sinn hat bei vielen Problemstellungen die Datenmenge eine sehr große Mächtigkeit, wenn man z.B. an die Integrationsprobleme denkt, bei denen die Datenmenge alle integrierbaren Funktionen (auf einem bestimmten Bereich) umfaßt.
Das Testen, das sich auf eine endliche (und im allgemeinen sehr kleine) Stichprobe beschränken muß, kann nicht einmal in einem statischen Sinn Aussagen über die Qualität von Algorithmen oder Programmen liefern.
|
Für die Software-Verifikation müssen folgende Grundannahmen erfüllt sein: |
| 1. Es gibt eine formale (mathematische) Spezifikation dessen, was das zu untersuchende Programm leisten soll, d.h., eine genaue Beschreibung des Programm-Outputs als Funktion des Programm-Inputs ist erforleich. |
| 2. Es gibt analytische Mechanismen, mit denen man die Korrektheit von Anweisungen verifizieren kann, die eine Transformation der Eingabewerte in die gewünschten Ausgabewerte vornehmen. |
Die erste Annahme ist bei Programen, die Heuristiken verwenden, im allgemeinen nicht erfült. Man kann natürlich für heuristische Programmabschnitte nachträglich eine formale Spezifikation liefern, die davon ausgeht, was dieser Abschnitt tatsächlich leistet. Auf diese Weise erhält man aber natürlich keine Information über die Brauchbarkeit dieses Programmteils.
| Beispiel (Numerische Integration) : Der noise detector eines numerischen Integrationsprogramms beruht stets auf heuristischen Überlegungen, d.h. es wird noch vor der eigentlichen Programmierung ein Teilalgorithmus festgelegt, der folgende Aufgabe erfüllen soll: Stochachistisch gestörte Integrandenfunktionen sollen rechtzeitig entdeckt werden. Die Verifikation kann nun nicht das erwartungsgemäße Funktionieren dieses Programmabschnitts hinsichtlich der Aufgabenstellung gewährleisten, sondern kann allenfalls die korrekte Implementierung des in der Spezifikation enthaltenen Algorithmus feststellen. |
Die erste Voraussetzung ist auch in allen Fällen nicht erfüllt, in denen eine präzise mathematische Beschreibung des Problembereichs, den ein Softwareprodukt abdecken soll, nicht möglich ist.
| Beispiel (Numerische Integration) : Im Programmpaket QUADPACK gibt es z.B. das nicht-adaptive Programm QUADPACK/qng, das für "glatte" Funktionen (ohne Singularitäten, Oszillationen etc.) gedacht ist. Eine präzise Spezifikation der Menge der Integrandenfunktionen F für die dieses Programm zuverlässig und effizient funktioniert, ist jedoch unmöglich. |
Die zweite Voraussetzung ist im allgemeinen auf Grund der Größe und Komplexität numerischer programme nicht erfüllt. Auch für automatische Verifikationssysteme sind numerische Programme in den meisten Fällen viel zu komplex. Weitere Hindernisse beim Einsatz solcher Verifikationssysteme ergeben sich z.B. durch Rundungsfehlereffekte oder durch die Berücksichtigung spezieller mathematischer Eigenschaften der gesuchten Lösungen (z.B. die geforderte Orthogonalität einer Lösungsmatrix)