Grundlagen der Informatik I “Programmierung”

Die Routine r muß natürlich eine Routine derjenigen Klasse sein, zu der das durch den qualifizierenden
Ausdruck beschriebene Objekt gehört, und für die aufrufende Klasse überhaupt verfügbar sein, also nicht
durch selektiven Export von der Benutzung ausgeschlossen sein. Bei mehrstufiger Qualifizierung gilt dies für
den ganzen Weg von der aufrufenden zur definierenden Klasse.
Eine entfernte Initialisierung der Art a.!!b oder a.!!b.init(Ausdruck1,...,Ausdruckn) ist übrigens
nicht erlaubt. Die Initialisierung von Komponentenobjekte eines Objektes ist – wie die Zuweisung von Werten
– ein Privileg, dessen allgemeine Freigabe dem Geheimnisprinzip widersprechen würde. Die Klasse, welche ein
feature b von einem Klassentyp bereitstellt, sollte auch explizit eine Routine init b bereitstellen, wenn die
Initialisierung von b durch Kundenklassen erlaubt werden soll.
4.3.2.3 Verifikation von Routinenaufrufen
Die Verifikation von Prozeduraufrufen ist über das Kontraktmodell bereits weitgehend vorbereitet. Wir haben
in Definition 4.2.3 auf Seite 141 festgelegt, daß wir eine Routine r als korrekt ansehen, wenn ihr Anweisungsteil
Br die vereinbarten Vor- und Nachbedingungen einhält, also wenn für alle gültigen Argumente xr gilt
{ prer(xr)} Br { postr(xr)}
In den Vor- und Nachbedingungen dürfen außer den formalen Argumenten nur noch Funktionen, die von der
definierenden Klasse erreichbar sind, und – bei Funktionen – die Größe Result genannt sein. 24 Da in der
Routine die formalen Argumente und das (meist nicht explizit genannte) aktuelle Objekt der definierenden
Klasse aber nur Platzhalter für die aktuellen Argumente und das tatsächlich zu bearbeitende Objekt sind,
dienen diese in dem Kontrakt ebenso als Platzhalter. Bei der Verifikation eines Aufrufs müssen also nur die
formalen Argumente gegen die aktuellen Argumente und das aktuelle Objekt gegen das im Aufruf angegebene
Objekt ausgetauscht werden, um einen gültigen Satz über diesen Aufruf zu erhalten.
Um dies präzise auszudrücken, müssen wir die Vor- und Nachbedingungen durch Prädikate beschreiben, deren
freie Variablen Platzhalter für die formalen Argumente und das aktuelle Objekt sind. Ist die Prozedur r durch
r(y1:T1,...,yn:Tn) is do ... end
deklariert, so beschreiben wir ihre Vorbedingungen durch
prer(y1,...,yn, actual)
und ihre Nachbedingungen durch
postr(y1,...,yn, actual),
wobei actual die Rolle von Current übernimmt, also implizit vor jedem Prozeduraufruf innerhalb des Anweisungsteils
von r steht, um das Objekt zu kennzeichnen, auf dem gerade gearbeitet wird. Für lokale oder
entfernte Aufrufe von r gelten dann folgende Sätze:
• { prer(A1,...,An,Current)} r(A1,...,An) { postr(A1,...,An,Current)}
Dabei kann Current durch Vereinfachungen wieder entfernt werden.
• { prer(A1,...,An,entity)} entity.r(A1,...,An) { postr(A1,...,An,entity)}
Der Prädikatentransformer ergibt sich entsprechend: kann bei einem Routinenaufruf entity.r(A1,...,An)
die Nachbedingung als postr(A1,...,An,entity) ausgedrückt werden, so ist prer(A1,...,An,entity) die
zugehörige schwächste Vorbedingung. Je nach Implementierung von r wäre prinzipiell eine noch schwächere
Vorbedingung möglich. Da diese aber im Kontrakt nicht enthalten ist und sich die Implementierung von r–
unter Einhaltung des Kontraktes – ändern darf, kann eine schwächere Vorbedingung nicht garantiert werden.
24 Im Idealfall lassen sich die Vor- und Nachbedingungen komplett als Zusicherungen der zugehörigen require und ensure Klausel
formulieren. Zuweilen ist es jedoch nötig, diese mithilfe der vollen Prädikatenlogik etwas präziser zu formulieren, als dies mit der
Zusicherungssprache von Eiffel – entsprechend der Diskussion in Abschnitt 3.7.4 – möglich ist.