Die Routine r muß natürlich eine Routine <strong>der</strong>jenigen Klasse sein, zu <strong>der</strong> 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 <strong>der</strong> Benutzung ausgeschlossen sein. Bei mehrstufiger Qualifizierung gilt dies für den ganzen Weg von <strong>der</strong> aufrufenden zur definierenden Klasse. Eine entfernte Initialisierung <strong>der</strong> Art a.!!b o<strong>der</strong> 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 wi<strong>der</strong>sprechen 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 <strong>der</strong> definierenden Klasse erreichbar sind, und – bei Funktionen – die Größe Result genannt sein. 24 Da in <strong>der</strong> Routine die formalen Argumente und das (meist nicht explizit genannte) aktuelle Objekt <strong>der</strong> 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 <strong>der</strong> 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, <strong>der</strong>en 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 o<strong>der</strong> 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 wie<strong>der</strong> 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 – än<strong>der</strong>n darf, kann eine schwächere Vorbedingung nicht garantiert werden. 24 Im Idealfall lassen sich die Vor- und Nachbedingungen komplett als Zusicherungen <strong>der</strong> zugehörigen require und ensure Klausel formulieren. Zuweilen ist es jedoch nötig, diese mithilfe <strong>der</strong> vollen Prädikatenlogik etwas präziser zu formulieren, als dies mit <strong>der</strong> Zusicherungssprache von Eiffel – entsprechend <strong>der</strong> Diskussion in Abschnitt 3.7.4 – möglich ist.
Für eine korrekt implementierte Prozedur r mit formalen Argumenten yr und abstrakten Vor- und Nachbedingungen prer bzw. postr gilt { prer(Ar,entity)} entity.r(Ar) { postr(Ar,entity)} wp(entity.r(Ar) , postr(Ar,entity)) ≡ prer(Ar,entity) Bei unqualifizierten Aufrufen wird Current für entity eingesetzt und <strong>der</strong> Ausdruck vereinfacht. Abbildung 4.4: Verifikationsregeln für Prozeduraufrufe In einem Korrektheitsbeweis müssen wir nun versuchen, die Nachbedingung post eines Prozeduraufrufs entity.r(A1,...,An) zu schreiben als post ≡ postr(A1,...,An,entity). Gelingt dies, so können wir die schwächste Vorbedingung durch Einsetzen in prer(A1,...,An,entity) erstellen. Beispiel 4.3.4 (Verifikation eines Prozeduraufrufs) In <strong>der</strong> Klasse ARRAY[INTEGER] sei die Routine sort ohne formale Argumente und ohne Vorbedingung deklariert und habe als Nachbedingung ∀i:lower..upper-1 . item(i)
- Seite 1 und 2:
Grundlagen der Informatik I “Prog
- Seite 3 und 4:
Inhaltsverzeichnis 1 Einführung 1
- Seite 5 und 6:
3.7.1 Zusicherungen . . . . . . . .
- Seite 7 und 8:
Abbildungsverzeichnis 2.1 Syntax de
- Seite 9:
4.9 Verifikationsregeln und Prädik
- Seite 12 und 13:
edeutet wiederum, exakte Prognosen
- Seite 14 und 15:
Stoff betrifft, so werden Sie eine
- Seite 16 und 17:
ilden die Grundlage zum Erwerb des
- Seite 18 und 19:
Komplexität 1. A.. V. Aho, E. Hopc
- Seite 20 und 21:
ser Zweig der Informatik beschäfti
- Seite 22 und 23:
5. Kompatibilität ist ein Maß daf
- Seite 24 und 25:
∀a ∈IN. teilt(a,a) ∧ teilt(a,
- Seite 26 und 27:
durchgeführt werden, sofern man ni
- Seite 28 und 29:
1.2.2.3 Diskussion Bei der deskript
- Seite 30 und 31:
Da 1215 ist wird die erste Anweisun
- Seite 32 und 33:
Rahmen zu weit führen. Auffällig
- Seite 34 und 35:
Durch das Konzept des Übersetzers
- Seite 36 und 37:
und “örtlich” durch Zerlegung
- Seite 38 und 39:
1.3.4 Prozeduralisierung Das Beispi
- Seite 40 und 41:
Man könnte das Objektkonzept von d
- Seite 43 und 44:
Kapitel 2 Logik und formale Sprachb
- Seite 45 und 46:
2.1 Formale Sprachbeschreibungen Di
- Seite 47 und 48:
möglichen Alternativen auf der rec
- Seite 49 und 50:
Wenn wir eine Menge von Sprachen be
- Seite 51 und 52:
Da wir im folgenden den Begriff der
- Seite 53 und 54:
Für die Zuordnung zwischen der Obj
- Seite 55 und 56:
Diese Form der Definition findet ih
- Seite 57 und 58:
K1: Kommutativ-Gesetz E1 ∧E2 ≡
- Seite 59 und 60:
Axiomenschemata: L1 A ∨ ¬A L2 (A
- Seite 61 und 62:
In dem Kapitel über die Programmve
- Seite 63 und 64:
2. Es werden Quantoren eingeführt,
- Seite 65 und 66:
s (T, state) = wahr s (F, state) =
- Seite 67 und 68:
• x ist gebunden in p(t1, ..., tn
- Seite 69 und 70:
Der Wert einer Aussage mit mehreren
- Seite 71 und 72:
Wichtig ist, daß die Auswahl des W
- Seite 73 und 74:
Wir geben hier eine Funktion an, di
- Seite 75:
wichtigste formale Sprache zur Besc
- Seite 78 und 79:
Wir wollen jedoch deutlich darauf h
- Seite 80 und 81:
Buch, sondern sollten besser als ei
- Seite 82 und 83:
Viel sinnvoller ist es, bei der Bes
- Seite 84 und 85:
Entsprechend ihrer beabsichtigten B
- Seite 86 und 87:
Klassen sind rein statische Beschre
- Seite 88 und 89:
leeren Verweis (d.h. von machen Per
- Seite 90 und 91:
haben wie z.B. “(jahr:INTEGER)”
- Seite 92 und 93:
und diese erzeugten Objekte mit Ver
- Seite 94 und 95:
Bei der Erzeugung von Objekten mitt
- Seite 96 und 97:
über den Namen eines Attributs Wer
- Seite 98 und 99:
• Die Veränderung und Auswertung
- Seite 100 und 101:
3.5 Copy- und Referenz-Semantik In
- Seite 102 und 103:
3.5.2 expanded: Klassen mit Copy-Se
- Seite 104 und 105:
class LIST[X] creation new feature
- Seite 106 und 107:
Dieses Problem wird durch das Konze
- Seite 108 und 109:
3.7.1 Zusicherungen Eiffel logische
- Seite 110 und 111:
class ARRAY[X] creation make featur
- Seite 112 und 113:
class ARRAY[X] creation make featur
- Seite 114 und 115:
formulieren und zu überwachen. Eig
- Seite 116 und 117: 3.8.2 Export geerbter Features Norm
- Seite 118 und 119: Ist also p ein Personenobjekt und a
- Seite 120 und 121: Definition 3.8.5 (Konformität) Ein
- Seite 122 und 123: Um die Beschreibung des Typsystems
- Seite 124 und 125: Nachkommenklassen aber folgt entity
- Seite 126 und 127: deferred class LIST[X] feature leng
- Seite 128 und 129: class STUDENT feature universität:
- Seite 130 und 131: Das Problem ist nun, daß beide Elt
- Seite 132 und 133: Prinzipiell wäre es sogar möglich
- Seite 134 und 135: Das bedeutet also, daß die Erbenkl
- Seite 136 und 137: Die eigentliche Montage eines Syste
- Seite 138 und 139: Verständlichkeit der Module: Die L
- Seite 140 und 141: dynamische Semantik: Die dynamische
- Seite 142 und 143: Constant ::= Manifest constant | Id
- Seite 145 und 146: Kapitel 4 Systematische Entwicklung
- Seite 147 und 148: 4.1.2 Grundideen des objektorientie
- Seite 149 und 150: jedoch dringend zu empfehlen, jegli
- Seite 151 und 152: • Ausleihe - Bücher werden nach
- Seite 153 und 154: Der Anwender ist kein echter Klient
- Seite 155 und 156: Es sei an dieser Stelle angemerkt,
- Seite 157 und 158: einen Rechner überprüft werden ka
- Seite 159 und 160: Definition 4.2.3 (Korrektheit von R
- Seite 161 und 162: Programmkonstruktion keine Rolle, d
- Seite 163 und 164: Eine Wertzuweisung entity := Ausdru
- Seite 165: 4.3.2.1 Die Rolle formaler Paramete
- Seite 169 und 170: { pre} Anweisung1 { p} , { p} Anwei
- Seite 171 und 172: die alle dieselbe Variable x betref
- Seite 173 und 174: 4.3.4.4 Verifikation Die Verifikati
- Seite 175 und 176: Dieser Beweis ist in der folgenden
- Seite 177 und 178: Im allgemeinen ist es sehr schwieri
- Seite 179 und 180: from Init invariant Inv variant Var
- Seite 181 und 182: Programm Zusicherungen Prämissen n
- Seite 183 und 184: entdeckten Fehler stillschweigend h
- Seite 185 und 186: Gegenlesen nicht findet(, aber auch
- Seite 187 und 188: 4.3.10 Die Verifikation rekursiver
- Seite 189 und 190: • Die Variante einer rekursiven R
- Seite 191 und 192: Die Art der Anweisungen ist nicht a
- Seite 193 und 194: Die Formulierung von Ausdrücken mu
- Seite 195 und 196: 4.4.6 Sprachbeschreibung Die nun fo
- Seite 197 und 198: Programm nachträglich als korrekt
- Seite 199 und 200: Der vollständige Korrektheitsbewei
- Seite 201 und 202: Dies ist die Grundidee der sogenann
- Seite 203 und 204: Als Initalanweisung genügt es, i m
- Seite 205 und 206: Beispiel 4.5.15 (Vertauschen von Se
- Seite 207 und 208: Mit einer wichtigen strategischen A
- Seite 209: Seien Sie sich bewußt, daß gerade
Change language