Formale Methoden im Software Engineering. Planung. Spezifikation. Formale Spezifikationen

Transkript

1 Formale Methoden im Software Engineering Formalen Methoden in der Informatik: Anwendung der Mathematik, insbesondere der theoretischen Informatik. In anderen Ingenieurwissenschaften ist der Einsatz mathematischer Methoden selbstverständlich, ja sogar unentbehrlich geworden. Verglichen mit anderen Ingenieurwissenschaften ist die Softwaretechnologie eine junge Disziplin. Die Fähigkeiten Geschick und Erfahrung herrschen immer noch vor, und mathematische Methoden finden wenig Einsatz. Planung Problemstellungen: Welche Anforderungen bestehen an ein neues System? Besteht ein Bedürfnis? Wäre es wirtschaftlich? Mit Ausnahme von Wirtschaftlichkeitsrechnungen ist eine Formalisierung weder möglich noch sinnvoll. Es ist nur eine Frage der Zeit, bis die Mathematik auch in der Softwaretechnologie unentbehrlich wird, und formale Methoden zum Rüstzeug jedes Informatikers gehören. In welchen Stadien des Softwareentwicklungsprozesses können formale Methoden eingesetzt werden? Formale Methoden in der Softwareentwicklung 1 Formale Methoden in der Softwareentwicklung 2 Spezifikation Anforderungen aus der Planungsphase werden zu einer genauen Beschreibung der zu entwickelnden Software präzisiert. Die Spezifikation soll genau festlegen, was die Software tun soll, nicht aber, wie sie es tun soll. Spezifikationen bilden oft die Grundlage des Vertrags zwischen Kunde und Programmierer. Man unterscheidet grundsätzlich zwischen nicht formalen Spezifikationen, z.b. solchen in natürlicher Sprache, und formalen Spezifikationen. Formale Spezifikationen Formale Spezifikationen sind in einer formalen Sprache geschrieben. Eine formale Sprache ist eine Sprache, deren äussere Form (die Syntax) und deren Bedeutung (die Semantik) mathematisch definiert sind. Der Begriff der formalen Spezifikation wird manchmal in dem Sinne missverstanden, dass Spezifikationen in der Form von Diagrammen als formal angesehen werden. Dies ist jedoch nur dann der Fall, wenn die Bedeutung der verschiedenen Kästchen und Verbindungen genau definiert ist. Formale Methoden in der Softwareentwicklung 3 Formale Methoden in der Softwareentwicklung 4

2 Warum formale Spezifikationen? Formale Spezifikationen vermeiden eine Reihe von Problemen, die bei nicht formalen Spezifikationen auftauchen. Nicht formale Spezifikationen enthalten oft Unklarheiten und Uneindeutigkeiten. Man kann auch nicht mit ihnen rechnen und hat deshalb grosse Schwierigkeiten, Unklarheiten und Uneindeutigkeiten zu finden. Formale Spezifikationen sind dagegen per Definition eindeutig, da sie eine wohldefinierte Syntax und Semantik haben. Sie sind manipulierbar, da Eigenschaften von Spezifikationen berechnet bzw. bewiesen werden können. Die Vorteile formaler Spezifikationen Sie bilden eine eindeutige Grundlage für den Vertrag zwischen Kunde und Programmierer. Sie bilden einen klaren Massstab für den Programmierer, was das Programm zu tun hat. Sie sind besser überprüfbar, da ihre Eigenschaften berechenbar sind. Eigenschaften, die jede Spezifikation erfüllen sollte, sind zum Beispiel Konsistenz und Machbarkeit Konsistenz bedeutet, dass die Spezifikation keine Widersprüche enthält. Machbarkeit bedeutet, dass für jeden möglichen Input auch ein Output existiert. Formale Methoden in der Softwareentwicklung 5 Formale Methoden in der Softwareentwicklung 6 Anforderungen an formale Spezifikationssprachen Formale Spezifikationssprachen müssen: auch für Nichtmathematiker gut zu lesen und zu schreiben sein ausdrucksfähig sein ein hohes Abstraktionsniveau haben Ausführbare Spezifikationen Vorteil ausführbarer Spezifikationen: die Spezifikation bildet bereits einen Prototyp, den man bei der Validierung der Spezifikation durch den Kunden testen lassen kann. Damit die Spezifikation ausführbar bleibt, muss man allerdings die Mächtigkeit und damit die Ausdrucksfähigkeit der Spezifikationssprache einschränken. Es bleibt im Einzelfall abzuwägen, ob eine ausführbare Spezifikation oder eine ausdrucksfähigere Spezifikationssprache wichtiger ist. Formale Methoden in der Softwareentwicklung 7 Formale Methoden in der Softwareentwicklung 8

3 Entwurf und Kodierung Aufgaben: das Programm strukturieren, die Algorithmen und Datenstrukturen des Programms bestimmen und sie kodieren. Eine formale Spezifikation bildet einen genauen Massstab, an dem man das Programm messen kann. Zwei Varianten: 1. Programm zuerst entwerfen und kodieren, und dann in einem zweiten, unabhängigen Schritt beweisen, dass es die Spezifikation erfüllt. 2. Die Spezifikation schrittweise verfeinern, bis man ein ausführbares Programm hat. Wenn man beweist, dass jede weitere Verfeinerung die vorhergehende Verfeinerung erfüllt, so ist das Programm korrekt. Vorteile des schrittweisen Vorgehens Anstelle eines grossen, hochkomplexen Beweises hat man viele kleinere, einfachere Beweise. Man hat einen dokumentierten Pfad der Programmentwicklung. Dieser Pfad kann z.b. dann von Interesse sein, wenn die Spezifikation geändert wird und das Programm angepasst werden muss. Ansätze: 1. Der Spezifikationssprache wird eine Bedeutung in der Programmiersprache gegeben. Beispiel: das Refinement Calculus von Carroll Morgan [Morgan 1990] 2. Der Programmiersprache wird eine Bedeutung in der Spezifikationssprache gegeben. Beispiel: Predicative Programming von Eric Hehner [Hehner 1993] 3. Spezifikationssprache und Programmiersprache haben dieselbe Semantik. Wenn die Spezifikation nicht ausführbar ist, spricht man von Programmsynthese, wenn sie ausführbar ist, von Programmtransformation. Formale Methoden in der Softwareentwicklung 9 Formale Methoden in der Softwareentwicklung 10 Test und Betrieb Mit Hilfe formaler Methoden wurde eine formale Spezifikation in ein korrektes Programm übergeführt. Die Korrektheit des Programms bezüglich der Spezifikation wurde mathematisch bewiesen: das Programm wurde verifiziert. Deshalb kann es keine Fehler enthalten, und das Testen und die Wartung im engeren Sinne entfallen. Wenn man sagt, dass das Programm keine Fehler enthält, so ist das nur bezüglich der formalen Spezifikation gemeint und vorbehaltlich Fehler in den Beweisen oder Methoden. Wenn die Spezifikation bereits Fehler enthält, so wird das Programm ebenfalls fehlerhaft sein. Daher kann auf das Testen nicht verzichtet werden. Formale Methoden in der Praxis Die Praxis steht den formalen Methoden noch recht skeptisch gegenüber. Die Gründe, die gegen deren Anwendung sprechen, sind: 1. formale Methoden sind zu teuer 2. formale Methoden sind zu schwierig, weil sie nicht genügend entwickelt sind sie nicht automatisiert sind die Programmierer sie nicht beherrschen (Problem des Technologie-Transfers) Formale Methoden in der Softwareentwicklung 11 Formale Methoden in der Softwareentwicklung 12

4 Formale Methoden sind zu teuer? hat auch damit zu tun, dass sie noch zu schwierig sind langfristig ist zu erwarten, dass die zusätzlichen Kosten, die durch die Anwendung formaler Methoden anfallen, wettgemacht werden durch Einsparungen beim Test und bei der Wartung. heute werden formale Methoden recht häufig dort eingesetzt, wo ein Fehler nicht auftreten darf in sicherheitskritischen System. Der Softwarelebenszyklus der Zukunft Die Geschichte der Programmierung ist eine Geschichte wachsender Abstraktion Für die ersten Rechner hatte man keine Werkzeuge, also wurden sie direkt in Maschinensprache (d.h. binär oder oktal) programmiert. Es brauchte nicht lange, bis Programmierer eine symbolische Sprache entwickelten. Dialekte dieser Sprache existieren noch für alle Rechner unter dem Begriff Assembler. In den späten 50er und frühen 60er Jahre kamen die Programmiersprachen der dritten Generation (Fortran, Cobol, Pascal, Ada, C, usw.). Für die verschiedensten Anwendungsgebiete wurden abstraktere Programmiersprachen entwickelt. Die Geschwindigkeit, Kapazität und Vernetzung der Rechner sind weiterhin in rasantem Tempo gewachsen, und wir stossen an die obersten Grenzen der Fähigkeiten dieser Sprachen. Formale Methoden in der Softwareentwicklung 13 Formale Methoden in der Softwareentwicklung 14 Der Softwarelebenszyklus der Zukunft In den 80er Jahren kamen die Programmiersprachen der vierten Generation. Diese waren vor allem entweder anwendungsspezifisch (z.b. die Macrosprache einer Applikation) oder nur Teillösungen des Problems (z.b. Hilfsmittel für die Entwicklung graphischer Oberflächen). Sie boten keine generelle Verbesserung der Softwaretechnologie an. Mit den formalen Methoden stehen wir nun an der Schwelle einer nächsten Generation. Aber ein grundsätzliches Problem bleibt die Umsetzung der nicht formalen Anforderungen in die formale Spezifikation der Übergang von der nicht formalen zur formalen Welt wird immer die Schwachstelle bleiben, denn man wird nie beweisen können, dass die Spezifikation richtig ist, sondern sich nur durch rigoroses Testen und ausgiebiges Prototyping davon überzeugen können. 1. Formale Spezifikationssprachen stellen eine höhere Abstraktionsebene dar und werden damit komplexere Systeme ermöglichen. 2. Sie werden eine neue Generation von Programmiersprachen und Programmierwerkzeugen einleiten. 3. Als Folge der formalen Methoden wird der Schwerpunkt des Softwarelebenszyklus nach vorne verlagert, nämlich in die Spezifikationsphase. 4. Die Bedeutung des Entwurfs, der Kodierung und des Testens werden abnehmen. Formale Methoden in der Softwareentwicklung 15 Formale Methoden in der Softwareentwicklung 16

5 Fallstudie: Darlington Nuclear Generating Station Fallstudie: Darlington Nuclear Generating Station Zum ersten Mal sollte die 2 Shutdown Systeme für den Reaktor softwaremässig gesteuert werden fingen die Arbeiten an. Die erste Version wurde von Ingenieuren entwickelt, die spezialisiert auf sicherheitskritische Kontrollsysteme waren, aber keine Ausbildung im Software Engineering hatten. Für die zweite Version wurden Software Ingenieure beigezogen, die aber keinen Hintergrund in der Nukleartechnik hatten wurde die zweite Version von der Atomic Energy Control Board of Canada geprüft, und es wurden Diskrepanzen gefunden. Das AECB war nicht überzeugt, dass die Software die Anforderungen erfüllte. Für die dritte Version wurde David Parnas zugezogen. Er schlug vor und bekam im Mai 1989 grünes Licht, formale Methoden einzusetzen: 1. Informelle Anforderungen wurden formalisiert in Spezifikationstabellen 2. Für existierenden Code wurden Programm- Funktionstabellen erstellt 3. Es wurde gezeigt, dass der Code die Spezifikation erfüllt. Es arbeiteten bis zu 30 Personen an der Verifikation. Alle Beweise wurden manuell gemacht, für die Tabellen wurde Excel verwendet Die Arbeiten für das erste Shutdown-System wurden November 1989 abgeschlossen, die Arbeiten für das zweite im Februar Die Betriebsbewilligung wurde im Februar 1990 erteilt. Umfang: 6000 Zeilen Assembler, 7000 Zeilen Fortran, Zeilen Pascal. Spezifikation, Code und Beweise füllen 25 Bundesordner. Formale Methoden in der Softwareentwicklung 17 Formale Methoden in der Softwareentwicklung 18 Fallstudie: Paris Metro Signalisierung Frequenz der Pariser Metro erhöhen: Abstand zwischen Zügen um 30 Sek auf zwei Minuten senken Varianten: 1. Neue Zuglinie 2. Bessere Signalisationssoftware Im Fall einer Softwarelösung wurde ein Prototyp sowie eine Verifikation verlangt. Aufteilung des Arbeitsaufwands: Personenstunden für die Implementation des Prototyps Personenstunden für die Implementation der Endversion für die formalen Methoden Aufteilung des Arbeitsaufwands Test/formalen Methoden 1. Formale Beweise 32.4% 2. Modultest 20.1% 3. Funktionstest 25.9% 4. Neuspezifikation 21.6% Schlussbemerkungen zur Studie von Gerhart, Craigen, Ralston Amerikanische und europäische Behörden überdenken die Zertifizierungsanforderungen für sicherheitskritische Systeme. z.t. werden formale Methoden explizit verlangt, z.t. werden best practices verlangt, wozu die formalen Methoden rasch gehören könnten Formale Methoden wurden angewendet, um: 1. eine grössere Sicherheit und Zuverlässigkeit zu erreichen (assurance) 2. das Anwendungsgebiet besser zu verstehen (domain analysis) 3. die Kommunikation zu verbessern 4. sicherzustellen, dass best practices angewendet wurden. 5. das Reengineering bestehender Software zu erleichtern Formale Methoden in der Softwareentwicklung 19 Formale Methoden in der Softwareentwicklung 20

6 Referenzen C. Morgan, Programming from Specifications, Prentice Hall, 1990, ist ein Lehr- und Nachschlagewerk für das Refinement Calculus. E. Hehner, A Practical Theory of Programming, Springer Verlag, 1993, ist ein Lehrbuch und Nachschlagewerk für Predicative Programming. S. Gerhart, D. Craigen, T. Ralston, Experience with Formal Methods in Critical Systems, IEEE Software, January 1984, enthält die Fallstudien. Formale Methoden in der Softwareentwicklung 21