Formale Methoden in der Praxis - Institute of Software Technology

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