Formale Methoden in der Praxis - Institute of Software Technology

Formale Methoden in der Praxis
1. Österreichischer ISA-EUNET Workshop, Wien
Bernhard K. Aichernig und Peter Lucas
Ordinariat für Softwaretechnologie, TU-Graz,
e-mail: {aichernig | lucas}@ist.tu-graz.ac.at
28.4.1999
1 Vorbemerkungen
Im folgenden wird der Versuch unternommen, eine kurze Einführung in jene Softwaretechniken zu
geben, die heute unter dem Begriff formale Methoden subsummiert werden. Es geht, grob gesprochen,
um den Einsatz mathematischer Methoden in der Softwareentwicklung. Hierbei konzentrieren
wir uns auf jene Techniken, die eine Reife erlangt haben, um in der Industrie angewandt zu werden.
Beispiele industrieller Projekte sollen die verschiedenen Anwendungsmöglichkeiten illustrieren.
Die Idee, mathematische Methoden im Software Engineering einzusetzen, ist weder neu noch
besonders erstaunlich. Alle Ingenieursdisziplinen bauen wesentlich auf mathematischen Methoden
auf, man denke nur an die uns naheliegende Elektrotechnik, im weiteren auch Maschinenbau,
Baustatik, usw. Der Term Software Engineering taucht erstmals 1968 als Titel einer NATO-
Konferenz auf und signalisiert den Wunsch, die Softwareentwicklung als Ingenieursdisziplin zu
sehen und auf eine systematische Basis zu stellen [31] (siehe auch [8]).
Der Ort der Präsentation gibt Anlaß zu einer geschichtlichen Anmerkung, versehen mit einem
lokal-patriotischen Kolorit. Wesentliche Grundlagen, die sich heute in vielen formalen Methoden
wiederfinden, wurden in den späten 60-er Jahren im IBM Labor in Wien erarbeitet. Die entstandene
Methode wurde unter dem Namen VDM (Vienna Development Method) bekannt. Das ist aber
lange her. Die Methode hat einige Verbreitung gefunden und wurde insbesondere an der Manchester
University in England und an der Technischen Universität Dänemark weiterentwickelt. Eine
recht starke Gruppe ist derzeit auch am Trinity College in Irland tätig. Vor einigen Jahren haben
wir das Thema auch an der TU Graz aufgegriffen und so die Technologie wieder nach Österreich
zurückimportiert.
Bevor wir auf die Praxis eingehen, ist es jedoch notwendig, einen Überblick über die einzelnen
Techniken zu erlangen.
2 Formale Methoden
2.1 Problem der Spezifikation
Ein sehr häufig verwendetes Klischee, das sich praktisch durch die gesamte Literatur des Software
Engineering zieht, lautet: Die Spezifikation sagt, was die Software tun soll, wie die Funktionalität
erreicht wird, ist Aufgabe der Implementierung.
Das entsprechende Zitat aus ESA Standard ist:
“The SR phase is the analysis phase of a software project. A vital part of the analysis activity
is the construction of a model describing what the software has to do, and not how to do it.” (SR
steht für “Software Requirement” Phase.)
1

Aber wie macht man das? Wie beschreibt man die Funktionsweise, ohne gleichzeitig zu sagen,
wie diese realisiert wird? Das ist keine leichte Aufgabe. Die Methoden müssen gelernt und geübt
werden. Viele Softwarespezialisten sind dieser Aufgabe nicht gewachsen.
Episoden: “Wie kann man etwas beschreiben, das man noch nicht hat.”
Dieser Problematik muß man sich stellen, unabhängig davon, ob man formale Methoden
benützt oder nicht. Aber die mathematischen Grundlagen helfen, die Alternativen zu sehen, um
die Aufgabe zu lösen.
2.2 Spezifikationsmethoden
Es gibt mehr als eine Möglichkeit, ein Programm zu spezifizieren, ohne die Details einer Implementierung
preiszugeben.
Für die Zwecke dieser Einführung werden vier Methoden unterschieden.
1. Spezifikation mittels Vor- und Nachbedingungen.
2. Algebraische Spezifikation.
3. Explizite Spezifikationen.
4. Kontrakte.
Vor- und Nachbedingungen sagen, welche Programme als Lösung akzeptabel sind.
Mit algebraischen Spezifikationen werden abstrakte Datentypen oder Objektklassen spezifiziert,
indem die Relation der Funktionen bzw. Methoden untereinander festgelegt werden.
Explizite Spezifikationen definieren Funktionen oder Methoden direkt mittels gegebener, aber
möglichst abstrakter Datentypen.
Kontrakte spezifizieren die wechselseitigen Anforderungen paralleler Prozesse, sowie deren Verhalten.
Wird der Benützer als ein Prozeß gesehen, so kann man auch Spezifikationen mit Vor- und
Nachbedingungen als Kontrakte bezeichnen.
Die folgenden Beispiele illustrieren der Reihe nach die erwähnten Methoden.
2.2.1 Definition durch Vor- und Nachbedingungen
Beispiel: Quadratwurzel
Es soll ein Programm sqrt spezifiziert werden, das die Quadratwurzel einer gegebenen reellen Zahl
x liefert. Wir erleichtern uns die Aufgabe, indem wir die Ein- und Ausgabebereiche festlegen, und
dem Resultat einen Namen geben.
sqrt (x : R) s : R
Die Aufgabe besteht nun darin, s in Relation zu x ausreichend festzulegen. Die Charakterisierung
des Resultats soll möglichst einfach und einleuchtend sein. Es ist nicht der Algorithmus
gefragt, sondern nur ein Kriterium, das entscheidet, ob ein angebotenes s eine Lösung ist.
Aus dem elementaren Mathematikunterricht erinnern wir uns an die “Probe”, die nach gewissen
Rechenoperationen zu machen war. Als Probe zur Berechnung der Quadratwurzel wird das
Resultat quadriert, das, wenn richtig gerechnet wurde, gleich dem Argument sein muß. Damit
haben wir das gesuchte Kriterium für die Lösung. Weil diese Bedingung nach der Ausführung des
Programms gelten soll, nennt man sie Nachbedingung (post-condition). Man schreibt:
sqrt (x : R) s : R
post s × s = x
Die Annahmen, die man bezüglich der Inputs zu einem Programm trifft, nennt man Vorbedingung
(pre-condition). Falls das Resultat im Bereich der reellen Zahlen liegen soll, muß die
Vorbedingung den Argumentbereich auf die positiven reellen Zahlen einschränken.
2

sqrt (x : R) s : R
pre x ≥ 0
post s × s = x
Diese Spezifikation läßt jeweils zwei Lösungen zu, eine positive und eine negative. Wie vorhin
ausgeführt ist dies nicht von vorneherein abzulehnen. Im Falle der Quadratwurzel soll aber doch
eine bestimmte Lösung ausgewählt werden, und zwar die positive Lösung. Die Nachbedingung ist
also zu ergänzen:
sqrt (x : R) s : R
pre x ≥ 0
post s × s = x ∧ s ≥ 0
Die Spezifikation sollte realistisch sein. Im Computer stehen uns die reellen Zahlen nur näherungsweise
zur Verfügung. Die Probe wird also nicht exakt aufgehen. Es ist daher notwendig die
Genauigkeit der gewünschten Lösung zu charakterisieren.
sqrt (x : R) s : R
pre x ≥ 0
post abs (x-s × s) < ɛ × x ∧ s ≥ 0
Damit erscheint die Funktion des Programms sqrt ausreichend spezifiziert. Die verwendete Notation
ist VDM-SL, die ISO-standardisierte Spezifikationssprache von VDM [26, 28]. Eine ähnliche
Notation verwenden die Methoden Z [34] und B [1].
2.2.2 Algebraische Spezifikationen
In den vorherigen Beispielen hatten wir es mit sehr konkreten Bereichen zu tun, nämlich den
reellen bzw. den ganzen Zahlen. Gewisse Operationen, z.B. die Addition und Multiplikation waren
als bekannt vorausgesetzt und in der Spezifikation verwendet.
Algebraische Spezifikationen werden nach dem Muster einer abstrakten Algebra gebildet, deshalb
auch der Name. Algebraische Spezifikationen postulieren einen oder mehrere Grundbereiche
auch Sorten genannt (sorts), sowie ein oder mehrere Funktionsnamen und deren “Typ”, in der üblichen
Terminologie der Programmierung. Man nennt dies auch die Signatur. Das bedeutet im Einzelnen:
für jeden Funktionsnamen wird die Anzahl der Argumente (arity) festgelegt und Argumentund
Funktionsbereich definiert. Die Bedeutung der Funktionsnamen wird durch Gleichungen charakterisiert,
die die Beziehung der Funktionen untereinander festlegen. Diese Gleichungen nennt
man auch Axiome.
Eine algebraische Spezifikation besteht also aus drei Teilen.
1. Sorten (Grundbereiche)
2. Signatur (Funktionsnamen und deren Typen)
3. Axiome
Als Beispiel wird ein Objektbereich (Stacks) betrachtet, der nicht in dem Maße vertraut ist
wie die Zahlenbereiche.
Beispiel: Stack
Anforderungen, informale Spezifikation
Es wird eine Menge von Elementen, Elem, angenommen, aus denen Stacks aufgebaut werden.
Ein Stack ist eine Sammlung von Elementen. Wird der Begriff Stack im herkömmlichen technischen
Sinn interpretiert, sind folgende Eigenschaften wesentlich:
3

1. Das oberste Element eines Stacks muß zugreifbar sein.
2. Es muß möglich sein, ein neues Element als oberstes Element hinzuzufügen.
3. Es muß möglich sein, das oberste Element zu entfernen.
Wir präzisieren nun die informale Beschreibung mit Hilfe einer algebraischen Spezifikation.
Wie in der informalen Beschreibung werden zwei Grundbereiche postuliert.
Grundbereiche: Elem, Stack
Aus der Beschreibung sind auch die gewünschten Operationen relativ leicht abzulesen. Für
jede der Operationen erfinden wir einen Funktionsnamen.
Funktionsname
top
push
pop
Bedeutung, informal
Zugriff auf das oberste Element.
Hinzufügen eines Elementes.
Entfernen des obersten Elementes.
Diese drei Operationen reichen nicht ganz. Sie setzen alle voraus, daß schon ein Stack vorhanden
ist. Es ist also nötig, wenigstens einen Stack einzuführen, mit dem man beginnen kann. Das
ist der leere Stack: empty.
Dieser eine Stack hat kein oberstes Element. Es wird daher im folgenden zu beachten sein, daß
weder die Funktion top noch die Funktion pop auf empty anwendbar sind.
Mit dieser Analyse der Situation kann nun die Signatur des Objektbereiches festgelegt werden.
Konstante im allgemeinen und empty im besonderen können als parameterlose Funktionen
betrachtet werden.
Signatur:
empty : Stack
top : Stack ˜→ Elem,
push : Stack × Elem → Stack,
pop : Stack ˜→ Stack
Die Funktionen top und pop sind partielle Funktionen, dies ist in der Notation durch eine Tilde
über dem Pfeil angedeutet. Partielle Funktionen sind Funktionen, die nicht für alle Elemente des
Argumentbereiches definiert sind. Im konkreten Fall sind top und pop nicht für den leeren Stack
definiert.
Die Funktion push ist für alle Argumente definiert.
Die Beziehungen der Funktionen sind nun durch folgende einfache Gleichungen (Axiome) definiert.
Axiome:
top(push(s, e)) = e,
pop(push(s, e)) = s
Anmerkung 1: die Funktion push ist eine Generatorfunktion. Ausgehend von empty können
durch wiederholte Anwendung der Funktion push alle Stacks erzeugt werden.
P(empty), P(s) ⊢ P(push(s, e))
P(s)
Anmerkung 2: Stacks können als Zustände einer abstrakten Maschine interpretiert werden, oder
auch als innere Zustände eines Objekts (d.h. als Werte einer privaten Variablen des Objekts). Die
Funktionen push und pop sind dann als Zustandstransformationen zu verstehen.
Ein prominenter Vertreter algebraischer Methoden ist Larch [20].
4

2.2.3 Explizite Definitionen
Im Gegensatz zu den algebraischen Spezifikationen setzen wir hier gewisse Datentypen als bekannt
voraus. Die neu zu definierenden Bereiche werden nun unter Benutzung der gegebenen Datentypen
definiert. Die neu zu definierenden Funktionen werden explizit auf Grund der gegebenen Funktionen
definiert. Man gibt, wenn man so will, eine mögliche Implementierung des neuen Bereiches
an.
Wir bleiben bei der Dreiteilung der Spezifikation. Die explizite Definition von Stacks läßt sich
wie folgt formulieren. Als den gegebenen und bekannt vorausgesetzten Datentyp werden Listen
verwendet.
Die Listen über einen gegebenen Bereich D werden mit D ∗ bezeichnet. Die für Listen definierten
und im folgenden gebrauchten Funktionen sind:
Funktionsname Bedeutung, informal
[] leere Liste
hd hd[x 1 , x 2 , . . . , x n ] = x 1 ]
tl
tl[x 1 , x 2 , . . . , x n ] = [x 2 , . . . , x n ]
[x 1 , x 2 , . . . , x n ] [y 1 , 2 y, . . . , y m ] = [x 1 , . . . , x n , y 1 , . . . , y m ]
Im Gegensatz zur algebraischen Formulierung, wird der Grundbereich Stack durch Listen definiert,
deren Elemente aus Elem sind. Elem ist vom Typ Token, welcher nicht näher spezifizierte,
aber unterscheidbare Werte repräsentiert.
Grundbereiche:
Stack = Elem ∗ ;
Elem = token
Die Signatur bleibt wie in der algebraischen Formulierung. Die auf Stacks anwendbaren Funktionen
werden aber explizit durch Listenfunktionen ausgedrückt.
top : Stack → Elem
top (s) △ hd s
pre s ≠ [] ;
pop : Stack → Stack
pop (s) △ tl s
pre s ≠ [] ;
push : Stack × Elem → Stack
push (s, e) △ [e] s
Im Rahmen einer Dissertation am Ordinariat wurde gezeigt, daß eine Unterklasse von Spezifikationen
mittels Vor- und Nachbedingung automatisch in eine explizite transformiert werden
können [18].
Diskussion
Es gibt nun zwei Definitionen von Stack. Eine implizite, algebraische Definition und eine Implementierung
mit Listen. Sind diese beiden Definitionen äquivalent? Was was bedeutet äquivalent
5

in dieser Situation? Grob gesprochen ist die Implementierung korrekt, wenn die in der Implementierung
definierten Funktionen die Axiome der algebraischen Spezifikation erfüllen. Das ist eine
Richtung der Äquivalenz.
Ist die Implementierung im gegebenen Fall spezifischer als die algebraische Spezifikation, d.h.
lassen sich aus der Implementierung Eigenschaften ableiten, die aus der algebraischen Definition
nicht ableitbar sind? Im allgemeinen ist dies bei Implementierungen der Fall, weswegen diese als
Definition normalerweise nicht geeignet sind. In unserem speziellen Fall kann aber gezeigt werden,
daß die Definition auf Grund von Listen keine zusätzlichen Eigenschaften impliziert, d.h. die beiden
Definitionen von Stacks sind äquivalent. Welche man wählt ist Geschmacksache.
Listen wurden als bekannt vorausgesetzt. Wie aber sind nun Listen definiert? Um mit den
expliziten Definitionen der Stackfunktionen zu manipulieren, braucht man algebraische Eigenschaften
der Listenfunktionen. Eine Möglichkeit ist nun, die Listenfunktionen selbst algebraisch
zu definieren. Das ist eine recht ökonomische Strategie. Listen und eine Handvoll von anderen Bereichen
haben sich als wichtige Grundlage für Spezifikationen herausgestellt. Ökonomisch deshalb,
weil die algebraischen Eigenschaften dieser grundlegenden Bereiche in vielen auf diesen Bereichen
aufbauenden Spezifikationen verwendet werden können.
Die Bereiche, die sich für Spezifikationen als grundlegend herausgestellt haben, sind:
• Mengen
• Listen
• Maps (finite Abbildungen)
• Produkte (Tupel)
• Zusammengesetzte Objekte (Records)
Dieser modell-orientierte Ansatz hat den Vorteil gegenüber algebraischer Methoden, daß die resultierenden
Theorien widerspruchsfrei sind. Daher kombinierte man in RAISE [19] beide Ansätze.
In [6] wird gezeigt, daß dies auch in VDM möglich ist.
2.2.4 Kontrakte
Eine Spezifikation von kommunizierenden Prozessen kann als Kontrakt zwischen den Prozessen
aufgefaßt werden. Der Kontrakt definiert die Aufgaben der ’Partner’ sowie deren Synchronisation.
In der Prozeßalgebra CSP (Communication Sequential Processes) [21] werden die einzelnen
Prozesse durch die Ereignisse, auf welche sie reagieren (können), und den Reaktionen selbst definiert.
Aus den formalen Definitionen der einzelnen Prozesse, ist es möglich das Gesamtverhalten
des Systems abzuleiten.
Beispiel: Automat
Ein einfacher Kaffeeautomat kann in CSP wie folgt definiert werden:
Automat = µX .fünfer → (kaffee → X | tee → X )
Der Automat kann nach dem Einwurf einer 5-Schilling-Münze Kaffee oder Tee ausgeben. Danach
wartet er wieder auf das Ereignis eines Münzeinwurfs.
Nun kann der Benutzer selbst als Prozeß modelliert werden. So ist z.B. das Verhalten eines
gierigen Benutzers, dadurch definiert, daß er auch einen Kaffee oder Tee, ohne ihn zu bezahlen,
annehmen würde. Wirft er jedoch einen Fünfer ein, so besteht er auf einen Kaffee:
Benutzer = (kaffee → Benutzer
| tee → Benutzer
| fünfer → kaffee → Benutzer)
6

Wird dieser Benutzer mit dem Automaten zusammengebracht, so wird seine Gier nicht befriedigt,
da der Automat nur auf den Einwurf eines Fünfers reagiert. Hier gibt der Automat auch nie
einen Tee aus, da der Benutzer nur Kaffee will:
(Benutzer || Automat) = µX .(fünfer → kaffee → X )
Das Beispiel zeigt, wie ein System als Komposition zweier paralleler Prozesse auch als ein einzelner
Prozeß dargestellt werden kann.
Diesen ereignisbasierten Spezifikationsstil kann man nun dazu benutzen, Prozesse deren Interfacefunktionen
mit den vorher besprochenen Methoden definiert wurden, zu spezifizieren. Hier
gibt es zwei Möglichkeiten:
1. Methodenaufrufe werden als Ereignisse interpretiert. Dieser Ansatz wurde in VDM++, der
objekt-orientierten Erweiterung von VDM gewählt [32].
2. Für jede Methode werden Lese- und Schreibkanäle definiert, wobei die Semantik von Kanälen
bereits in CSP definiert ist. In RAISE werden so parallele Architekturen spezifiziert [19].
2.3 Spezifikationen sind der Weg, nicht das Ziel
Spezifikationen sind nur der erste Schritt zum fertigen Produkt. Je nach Größe und Schwierigkeit
der Software muß die Spezifikation in mehr oder weniger großen Schritten in den exekutierbaren
und verifizierten Code umgesetzt werden.
Formale Spezifikationen, eben weil sie formal sind, lassen gewisse automatisierte, interne Konsistenzprüfungen
zu. Ein Beispiel ist die automatische Typenüberprüfung.
Eine Hauptfrage ist natürlich, ob eine auf Grund einer formalen Spezifikation entwickelte Implementierung
diese Spezifikation tatsächliche erfüllt. Idealerweise wäre eine solche Frage durch
einen mathematischen Beweis zu erledigen. Dieser Weg kann aber aus praktischen Gründen derzeit
nur selten begangen werden.
Die Verifikation erfolgt daher meist durch Testen. Aber auch zum systematischen Testen kann
die formale Spezifikation herangezogen werden [4, 5, 10].
Ist das spezifizierte System so geartet, daß es nur endlich viele Zustände annehmen kann, ist
das sogenannte “model checking” eine Möglichkeit. Model-checking ist ein automatischer Prozeß,
der ein System vollständig testet, indem alle möglichen Zustände in Betracht gezogen werden.
Ob model checking angewandt werden kann, hängt von der Anzahl der möglichen Zustände des
Systems ab.
Ist model-checking nicht sinnvoll, muß man auf einen vollständigen Test verzichten. Man kann
aber wenigstens versuchen auf der Basis der formalen Spezifikation für jede Fallunterscheidung,
jeden Fall mit wenigsten einem Testbeispiel abzudecken.
Die IFAD VDM-SL Toolbox bietet noch eine weitere Möglichkeit, die sogenannte Animation.
Wenn in der Spezifikation gewisse implizite Formen der Definition vermieden werden, kann eine
Spezifikation direkt interpretiert und “getestet” werden. Manchmal spricht man auch von “rapid
prototyping”. Damit kann mit dem System experimentiert werden oder es kann (dem Kunden)
demonstriert werden, bevor die eigentliche Implementierung erstellt ist.
Werkzeuge:
Einer der Gründe warum die Akzeptanz von Formalen Methoden in den letzten Jahren stieg, ist
die Verfügbarkeit von Werkzeugen.
Folgende Werkzeuge werden von uns verwendet:
• IFAD VDMTools [24, 14]
• Theorem Prover
– PVS [35]
– Isabelle [37]
• FDR Model-Checker [36]
7

3 Industrielle Anwendung
Wo werden formale Methoden heute angewandt?
Formale Methoden werden in Spezialgebieten angewandt, die entweder sicherheitskritisch sind
oder besonders schwierige Probleme stellen oder wenn sehr viel Geld am Spiel steht. Hier sind
einige Beispiele solcher Spezialgebiete:
• Sicherheitskritische Systeme: Flugwesen, Raumfahrt, Eisenbahnwesen, ...
• Protokolldefinition
• Sprachdefinition
• Echtzeitanwendungen
• Hardwareverifikation
3.1 Projekte des Ordinariats
Eine Auswahl von uns durchgeführter Projekte soll einen Einblick in die Anwendungsmöglichkeiten
und Vorteile formaler Methoden geben. Die Aufzählung soll auch ein weit verbreitetes Mißverständnis
beseitigen, nämlich daß formale Methoden gleichbedeutend mit formalen Beweisen
sind.
3.1.1 IFAD
Der dänische Toolprovider IFAD verwendet VDM um seine eigenen VDM-Werkzeuge zu entwickeln.
Drei Projekte, welche die Weiterentwicklung der Entwicklungswerkzeuge zum Ziel hatten,
wurden bis jetzt mit IFAD durchgeführt.
• Die Implementierung von Dynamik-Link Modulen, um VDM-SL Spezifikationen mit C++
Sourcecode zu verbinden [17].
• Die Entwicklung eines formalen Prototypen eines Beweisverpflichtungs-Generators zum Auffinden
von Konsistenzfehlern in VDM-Spezifikationen [7].
• Die Erweiterung des VDM++-nach-Java Code-Generators um parallele Konstrukte [32].
3.1.2 Siemens
Mit der Firma Siemens PSE Graz wurde ein Projekt zur formalen Spezifikation des HBCI Homebanking
Protokolls durchgeführt. Die VDM-Formalisierung des informalen Standards brachte
mehr als 25 Mehrdeutigkeiten und mögliche Fehler im Protokoll zutage [38].
Zur Zeit ist eine Folgearbeit ausgeschrieben, welche die Implementierung einer neuen Version
des HBCI-Standards zur Aufgabe hat. Dabei soll auch untersucht werden, wie eine formale
Methode die durch Versionsänderung bedingten Modifikationen unterstützt.
3.1.3 Frequentis
Mit der Wiener Firma Frequentis Nachrichten GmbH wurde ein Projekt zur Spezifikation ihres
Sprachvermittlungssystems VCS 3020S, ein Kommunikationssystem für die Flugverkehrskontrolle,
durchgeführt. Es wurde ein ’leichter Ansatz’ gewählt [27], indem eine explizite VDM++ Spezifikation
des sicherheitskritischen Teils erstellt wurde.
Während der Spezifikation wurden 64 Mehrdeutigkeiten, Widersprüche, Unklarheiten und Fehler
in den informalen Dokumenten aufgezeigt und so die Qualität dieser informalen Spezifikation
verbessert. Abbildung 1 zeigt eine Statistik der gefundenen Punkte.
Im nächsten Schritt wurde die Qualität der Systemintegrationstests evaluiert. Dazu wurde die
explizite Spezifikation mit Hilfe der IFAD VDM++ Toolbox interpretiert und die Testabdeckung
8

25
20
2
Ambiguous, contradictiory or unclear issues
Erroneous issues
15
Issues
10
5
0
20
Reading
5
8
Reading with systemknowledge
17
12
0 0
Specification of
configuration
Specification of
functionality
Abbildung 1: Statistik der gefundenen ’Fehler’.
der Systemtests gemessen. Das Ergebnis war, daß nur ca. 80% der Funktionalität des Systems durch
die Testfälle abgedeckt war. Anhand der formalen Spezifikation erweiterte man die Testfälle, um
eine 100% Abdeckung zu erzielen. Tabelle 1 zeigt die Abdeckungsstatistik, wie sie von der IFAD
Toolbox erzeugt wird.
Class Name Number of Methods Coverage
OP 31 91%
RIF 11 70%
SWITCH 35 79%
average – 83%
Tabelle 1: Zusammenfassung der Testabdeckung.
Als letzte Aktivität wurde die formale Spezifikation anhand einer Änderungsanfrage (Change
Request) modifiziert, um die Vorteile einer formalen Spezifikation gegenüber herkömmlichen Dokumenten
zu verdeutlichen. Durch das formale Modell konnte die Änderung sowie die erforderlichen
neuen Testfälle systematisch designed werden.
Die Aufwände der einzelnen Arbeitsschritte sind in Abbildung 2 zusammengefaßt [23, 22].
Read FRQ Documents
1,2
Read FM Literature
2,3
Formal Specification
Test Coverage Analysis
Modification
Meetings, Presentations
1,1
1,2
3,0
3,5
Working times are given in
40 hour units (approx. 1 week)
Abbildung 2: Aufwand des Projekts mit Frequentis.
Zur Zeit läuft eine Folgearbeit, die VDM in einem laufenden Projekt anwendet. Das Ziel ist
die Spezifikation eines Netzwerkknotens für ein Kommunikationsnetz, welches die österreichischen
Flugüberwachungseinrichtungen verbinden soll. Weiters sollen aus dem formalen Modell systematisch
Testfälle abgeleitet werden.
3.1.4 Ferk Informatik
Mit der Grazer Firma Ferk Informatik wird zur Zeit ein Datenbanksystem zur Materialverfolgung
und Produktionsplanung entwickelt. Das Besondere an diesem Projekt ist, daß klassische Techniken
9

aus der Datenbankwelt mit formalen Methoden verknüpft werden.
Hierbei wird das relationale Datenmodell, welches mittels Erwin designed wurde, automatisch
in ein entsprechendes VDM-SL Modell übersetzt. Weiters lassen sich die SQL-Abfragen in
VDM-SL spezifizieren. Es folgt dann eine Erweiterung der Spezifikation um logische Bedingungen,
wie Dateninvarianten und Vorbedingungen. Diese Bedingungen können dann im Datenbankserver
implementiert werden und zur Konsistenzüberprüfung von Datenbanktransaktionen dienen. Das
Ergebnis ist eine konsistente Datenbank [33]. Abbildung 3 zeigt das informal-formale Vorgehensmodell.
Requirements
Document
Early design
Entity-Relationship
Diagram
Database Definition
in VDM
Additional Database
Constraints in VDM
Detailed design
Formal Model
Code
Database Constraints
via PL/SQL Triggers
Implementation
Arrows mean "Derived From / Using"
Abbildung 3: Überblick des integrierten DB-Entwicklungsmodells.
3.1.5 Forschungszentrum Seibersdorf
Ein zweijähriges Dissertationsprojekt in Kooperation mit dem Forschungszentrum Seibersdorf
beschäftigt sich mit der formalen Entwicklung eines Systems zur Überwachung von Wächterrouten.
Ziel des Projektes ist es die komplexen Requirements zu formalisieren und diese Spezifikation
zu einer lauffähigen Implementierung hin zu verfeinern.
In der ersten Phase (6 Monate) wurde aus den 60 Anforderungen eine VDM-SL Spezifikation
von 35 A4-Seiten entwickelt. Teile der Anforderungen sind auf einem niederen Abstraktionslevel
und geben einen Algorithmus vor. Die Konsequenz ist, daß durch viele Details die Spezifikation
schwierig zu verstehen ist.
Durch eine erste Validierung per Interpretation konnten Fehler in den Anforderungen aufgezeigt
werden. Außerdem stellten sich die Anforderungen als zu ungenau heraus. Daher wurde die Spezifikation
mit Hilfe des Theorem Provers PVS formal analysiert. Dabei wurden Fragen gestellt wie
z.B: Ist es möglich, daß ein Wächter seine Route nicht beenden kann, da Türen versperrt bleiben?
Das Ergebnis zeigte, daß die Unvollständigkeit der Anforderungen nur den Beweis eingeschränkter
Eigenschaften zuläßt. Weiters läßt sich sagen, daß die formale Analyse mittels eines Beweisers
sehr zum Verstehen des Problems beigetragen hat. So konnte auch ein Ansatz zur systematischen
Testfallgenerierung für das Zielsystem gefunden werden [12, 13, 11].
In diesem Projekt wird auch geprüft, ob der C++ Code-Generator der IFAD-Tools für diese
Aufgabe geeignet ist.
10

3.2 Internationale Projekte
International gibt es eine Reihe von Firmen und Institutionen, welche formale Methoden mit Erfolg
angewandt haben. In der Datenbank der FME (Formal Methods Europe) finden sich eine Reihe
von industriellen Projekten mit detailierten Beschreibungen [16].
Es folgt eine Auswahl bekannter Unternehmen, die formale Methoden einsetzen.
• NASA [30, 2, 3]
• British Aerospace, Aerospatiale
• Dänische Staatsbahnen, Chinesische Eisenbahn, Japanische Eisenbahn
• GAO
• Matra
• Intel
• BMW
• CAP Gemini
3.3 Fallstudie bei British Aerospace
Abschließend sei noch eine vergleichende Fallstudie bei British Aerospace zu nennen. In dieser Studie
wurde demonstriert, daß formale Methoden nicht unbedingt mehr Aufwand bedeuten müssen.
In zwei parallelen Projekten wurde das gleiche System, ein sicherheitskritisches Nachrichtengateway
entwickelt. Die eine Gruppe verwendete VDM, die andere die konventionelle informale
Methode der Firma.
Die folgende Tabelle zeigt das überaschende Ergebnis: Die formale Entwicklungsmethode war
schneller.
Phase Allocated Conventional Formal Excess
Time Method Method F over C
System Design 40 30 35 + 17%
SW-Design 40 40 33 - 17%
Implementation 20 17 13 - 24%
Totals 100 87 81 -7%
In der zweiten Tabelle ist die Verteilung der Aufwände nach Projektphasen aufgeschlüsselt.
Phase Conventional Formal
Method Method Ratio
% Project % Project (C/F)
System Design 34 43 0.77
SW-Design 46 41 1.15
Implementation 20 16 1.25
Totals 100 100
Eine genauere Beschreibung des Experimentes findet sich in [9].
4 Abschließende Bemerkungen
Daß diese Methoden derzeit vorwiegend in Spezialgebieten eingesetzt werden, ist vermutlich nur
ein Übergangsstadium. Die verbreitete Meinung scheint zu sein, daß formale Methoden einen
11

zusätzlichen Aufwand bedeuten und daher nur dort eingsetzt werden können, wo man sich diesen
Aufwand leisten kann.
Man kann aber auch der Meinung sein, daß sich der Aufwand auch in nicht kritischen Anwendungen
letztlich bezahlt macht. Hier ist unter anderem UML zu erwähnen, die neue “Universal
Modelling Language” die von den führenden Vertretern des objektorientierten Entwurfs kreiert
wurde. UML kommt mit einem Zusatz, der sogenannten Object Constraint Language (OCL), die
es erlaubt, Dateninvarianten und Methoden von Objektklassen mathematisch zu spezifizieren.
Wo ist mehr Information über die Anwendung formaler Methoden zu finden? Viele Anwendungen
sind in den Proceedings der FME Konferenzen zu finden. Die nächste Konferenz FM’99 findet
vom 20.–24. September in Toulouse statt [15]. Neben der schon erwähnten Datenbank der FME
[16], gibt es noch die Virtual Library zum diesem Thema [29]. Alle hier zitierten Publikationen
des Ordinariats für Softwaretechnologie sind auch als PostScript-Files auf unserem WWW-Server
verfügbar [25].
Literatur
[1] J.-R. Abrial. The B-Book, Assigning programs to meanings. Number ISBN 0521 49619
5(hardback). Cambridge University Press, 1996.
[2] Sten Agerholm and Peter Gorm Larsen. Modeling and validating SAFER in VDM-SL. In Michael
Holloway, editor, Fourth NASA Langley Formal Methods Workshop. NASA, September
1997. Available from http://atb-www.larc.nasa.gov/Lfm97/proceedings/.
[3] Sten Agerholm and Peter Gorm Larsen. SAFER specification in VDM-SL.
Technical report, IFAD, Odense, Denmark, September 1997. Available from
http://www.ifad.dk/examples/examples.html.
[4] Bernhard K. Aichernig. Automated requirements testing with abstract oracles. In ISSRE’98:
The Ninth International Symposium on Software Reliability Engineering, Paderborn, Germany,
pages 21–22, IBM Thomas J.Watson Research Center, P.O.Box 218, Route 134, Yorktown
Heights, NY, USA, November 1998. Ram Chillarege. ISBN 3-00-003410-2.
[5] Bernhard K. Aichernig. Automated black-box testing with abstract vdm oracles. In Proceedings
of SAFECOMP’99: The 18th International Conference on Computer Safety, Reliability
and Security, Toulouse, Lecture Notes in Computer Science. Springer, September 1999.
[6] Bernhard K. Aichernig and Andreas Kerschbaumer. Property orientation in the model oriented
vienna development method (vdm). Technical Report IST-TEC-99-02, Institute for
Software Technology, TU-Graz, Austria, February 1999. Submitted to FM’99, Toulouse,
France, September 20–24.
[7] Bernhard K. Aichernig and Peter Gorm Larsen. A proof obligation generator for VDM-SL.
In J. Fitzgerald, C.B. Jones, and P. Lucas, editors, FME’97: Industrial Applications and
Strengthened Foundations of Formal Methods, volume 1313 of Lecture Notes in Computer
Science, 1997.
[8] Bernhard K. Aichernig and Peter Lucas. Softwareentwicklung — eine Ingenieursdisziplin!(?).
Telematik, Zeitschrift des Telematik-Ingenieur-Verbandes (TIV), 4(2):2–8, 1998. ISSN 1028-
5068.
[9] T.M. Brooks, J.S. Fitzgerald, and P.G. Larsen. Formal and informal specifications of a secure
system component: Final results in a comparative study. In Marie-Claude Gaudel and James
Woodcock, editors, FME’96: Industrial Benefit and Advances in Formal Methods, volume
1051 of Lecture Notes in Computer Science, 1996.
12

[10] Jeremy Dick and Alain Faivre. Automating the generation and sequencing of test cases
from model-based specifications. In J.C.P. Woodcock and P.G. Larsen, editors, FME’93:
Industrial-Strength Formal Methods. Springer-Verlag, April 1993.
[11] Georg Droschl. Design and application of a test case generator for vdm-sl (extended abstract).
Technical report, IST, TU-Graz, Austria, 1999. Submitted to Workshop VDM in practice at
FM’99, Toulouse, France, September 20–21.
[12] Georg Droschl. Formal specification and analysis of an access control using IFAD’s VDMtools.
Technical report, Institute for Software Technology, TU-Graz, Austria, January 1999.
Submitted to Computer Communications Journal, Special Issue: Formal Description Techniques
in Practice.
[13] Georg Droschl. Using PVS for requirements analysis of an access control. Technical Report
IST-TEC-99-05, Institute for Software Technology, TU-Graz, Austria, February 1999.
Submitted to FM’99, Toulouse, France, September 20–24.
[14] John Fitzgerald and Peter Gorm Larsen. Modelling Sytems, Practical Tools and Techniques.
Cambridge University Press, 1998.
[15] FME. FM’99 World Congress on Formal Methods in Development of Computing Systems.
http://www.cert.fr/fm99/.
[16] FME. Formal Methods Europe Hub. http://www.cs.tcd.ie/FME/.
[17] Brigitte Froehlich and Peter Gorm Larsen. Combining VDM-SL specifications with C++
code. In James Woodcock Marie-Claude Gaudel, editor, FME’96: Industrial Benefit and
Advances in Formal Methods, volume 1051 of LNCS, pages 179–194. Springer, March 1996.
[18] Brigitte Fröhlich. Program Generation Based on Implicit Definitions in a VDM-like Language.
PhD thesis, Institute for Software Technology, TU-Graz, Austria, December 1998. Supervisor:
Peter Lucas.
[19] Chris George et al. The Raise Development Method. The BCS Practitioner Series. Prentice
Hall, 1995.
[20] John V. Guttag, James Horning, and otheres. Larch, Languages and Tools for Formal Specification.
Texts and Monographs in Comuter Science. Springer Verlag, 1993.
[21] C.A.R. Hoare. Communicating Sequential Processes. Series in Computer Science. Prentice-
Hall, 1998.
[22] Johann Hörl. Formal specification for a voice communication system in air traffic control. Master’s
thesis, Institute for Software Technology, TU-Graz, Austria, January 1999. Supervisor:
Bernhard K. Aichernig and Peter Lucas.
[23] Johann Hörl and Bernhard K. Aichernig. Formal specification of a voice communication
system used in air traffic control, an industrial application of light-weight formal methods
using vdm++. Technical Report IST-TEC-99-03, Institute for Software Technology, TU-
Graz, Austria, February 1999. Submitted to FM’99, Toulouse, France, September 20–24.
[24] IFAD. IFAD’s products. URL: http://www.ifad.dk/Products/products.htm.
[25] IST. Homepage des Ordinariats für Softwaretechnologie. http://www.ist.tu-graz.ac.at/.
[26] Cliff B. Jones. Systematic Software Development Using VDM. Prentice-Hall International,
Englewood Cliffs, New Jersey, second edition, 1990.
[27] Cliff B. Jones. Formal methods light: A rigorous approach to formal methods. IEEE Computer,
29(4):20–21, April 1996.
13

[28] P. G. Larsen, B. S. Hansen, H. Bruun, N. Plat, H. Toetenel, D. J. Andrews, J. Dawes,
G. Parkin, et al. Information technology — Programming languages, their environments and
system software interfaces — Vienna Development Method — Specification Language — Part
1: Base language, December 1996. International Standard ISO/IEC 13817-1.
[29] Virtual Library. Formal methods. http://www.comlab.ox.ac.uk/archive/formalmethods.html.
[30] NASA. Formal methods, specification and verification guidebook for software and
computer systems, volume II: A practitioner’s companion. Technical Report NASA-
GB-001-97, NASA, Washington, DC 20546, USA, May 1997. Available from
http://eis.jpl.nasa.gov/quality/Formal Methods/.
[31] Peter Naur and Brian Randell. SOFTWARE ENGINEERING. NATO Science Committee,
January 1969.
[32] Oliver Oppitz. Concurrency extensions for the vdm++ to java code generator of the ifad
vdm++ toolbox. Master’s thesis, Institute for Software Technology, TU-Graz, Austria, May
1999. Supervisor: Peter Gorm Larsen and Peter Lucas.
[33] Rudi Schlatte and Bernhard K. Aichernig. Database development of a work-flow planning
and tracking system using VDM-SL. Technical Report IST-TEC-99-04, Institute for Software
Technology, TU-Graz, Austria, February 1999. Submitted to FM’99, Toulouse, France,
September 20–24.
[34] J. M. Spivey. The Z Notation. Series in Computer Science. Prentice-Hall, 1989.
[35] SRI. The PVS Specification and Verification System. http://pvs.csl.sri.com/.
[36] Formal Systems. FDR2 model-checker. http://www.formal.demon.co.uk/FDR2.html.
[37] Cambridge University and TU-München. Isabelle Generic Theorem Prover.
http://www.cl.cam.ac.uk/Research/HVG/Isabelle/.
[38] Simon J. Zwölfer. A formal specification of the HBCI homebanking protocol. Master’s
thesis, Institute for Software Technology, TU-Graz, Austria, August 1998. Supervisor: Brigitte
Fröhlich and Peter Lucas.
14