obj2 - Informatik

Fortgeschrittene Aspekte 

objektorientierter Programmierung 

Prof. Dr. Arnd Poetzsch-Heffter — AG Softwaretechnik 

Wintersemester 02/03

Inhalt

1. Einleitung 

Inhalt 

2. Grundlagen objektorientierter Sprachen 

3. Techniken zum Prüfen objektorientierter Programme 

4. Spezifikation objektorientierter Programme 

5. Verifikation spezifizierter Eigenschaften 

6. Ausblicke 

A. Poetzsch-Heffter: FASOOP Wintersemester 02/03 

3

1. Einleitung

1.1 Überblick 

1. Einleitung 

1.2 Formale und notationelle Grundlagen 


5

1.1 Überblick 6 


1.1 Überblick


Ausgangspunkt: 

• Kenntnis objektorientierter Programmierung (z.B. Java) 

Lernziele: 

• technische Vertiefung in: 

◦ Semantik 

◦ Typisierung 

⊲ bessere Parametrisierung 

⊲ Ausdruck weiterer Eigenschaften 

◦ Spezifikation von Programmeigenschaften 

◦ Prüfen und Verifikation 

A. Poetzsch-Heffter: FASOOP Wintersemester 02/03


• konzeptionelle Vertiefung in: 

◦ objektorientierter Programmierung 

◦ objektorientierter Modellierung 

• Werkzeugentwicklung in diesem Bereich 



Semantik 

Zwei zentrale Aspekte: 

• Spezifikation von Programmeigenschaften 

• Spezifikation der Programmiersprache 

Beispiel(Semantik für Programmeigenschaften): 

public class List { 

int length; 

ListElems le; 

//@ invariant length == le.leng(); 

... 

} 



Beispiel(Programmiersprachensemantik): 

class IntPair { 

private int a; 

private int b; 

IntPair( int ai, int bi ){ a = ai; b = bi; } 

int sum(){ return this.add(); } 

private int add(){ return a+b; } 

} 

class IntTriple extends IntPair { 


IntTriple( int ai,int bi,int ci ){ super(ai,bi); a = ci; } 

int sum(){ return this.add(); } 

private int add(){ return super.sum() + a; } 

} 



public class PrivateTest { 

public static void main( String[] arg ) { 

IntPair ip = new IntPair(3,9); 

IntTriple it = new IntTriple(1,2,27); 

System.out.println( ""+ip.sum()+" "+it.sum() ); 

} 

} 



Typisierung: 

Typisierung 

Beschreibung von einfachen Eigenschaften 

• im Rahmen der Programmiersprachen 

• mit automatischer Prüfung durch den Übersetzer 



Beispiel(Parametrischer Polymorphismus): 

class LinkedList { 

Entry header = new Entry(null, null, null); 

int size = 0; 

} 

LinkedList() { ... } 

ET getLast() { ... } 

ET removeLast() { ... } 

void addLast(ET e) { ... } 

int size() { return size; } 



class Entry { 

ET element; 

Entry next; 

Entry previous; 

} 

Entry(ET element, Entry next, Entry previous) { 

this.element = element; 

this.next = next; 

this.previous = previous; 

} 



class Test { 

public static void main( String[] args ) { 

LinkedList ls = new LinkedList(); 

ls.addLast("erstes Element"); 

ls.addLast("letztes Element"); 

ls.getLast().indexOf("Elem"); // liefert 8 

} 

LinkedList lo = new LinkedList(); 

lo.addLast( new Object() ); 

lo.addLast( new Object() ); 

lo.getLast().indexOf("Elem"); // Programmierfehler, 

} // der vom Uebersetzer automatisch entdeckt wird 



Spezifikation von Programmeigenschaften 

Spezifikation: 

• Beschreibung aussagekräftiger Eigenschaften 

◦ von Programmteilen oder -Schnittstellen 

◦ mit zusätzlichen Sprachmitteln 

• Prüfung mit unterschiedlichen Techniken 



Beispiel(Methodenspezifikation): 

public class IntMathOps { 

/*@ public normal_behavior 

@ requires y >= 0 

@ modifiable \nothing 

@ ensures \result * \result


Prüfen und Verifikation 

Aufgabe: 

Nachweis, dass beschriebenen Eigenschaften von 

Implementierung erfüllt werden. 

Techniken: 

• vollautomatisch vs. halbautomatisch/interaktiv 

• vollständig vs. teilweise 

• statisch vs. dynamisch 



Beispiel(Korrektheit): 

Aufgabe: 

Beweise, dass folgende Implementierung der Methode isqrt 

obige Spezifikation erfüllt. 

public static int isqrt( int y ){ 

int count = 0, sum = 1; 

while (sum


Formale Techniken auf der Entwurfsebene 

Exemplarisch betrachten wir UML-Klassendiagramme 

annotiert mit OCL-Bedingungen (Object-constraint 

language) 

Beispiel(Annotiertes Klassendiagramm): 



Statisches Modell mit Bedingungen 



1. Einleitung 

◦ Überblick 

Aufbau, Inhalt, Literatur 

◦ formale und notationelle Grundlagen 


◦ Spracheigenschaften 

◦ Semantik objektorientierter Sprachen 

◦ Eigenschaften objektorientierter Programme 

◦ Modularität und Kapselung 

3. Techniken zum Prüfen objektorientierter Programme 

◦ Einführung in die Bedeutung von Typsystemen 



◦ Typinformation und ihre statische und dynamische Prüfung 

◦ Typsicherheit 

◦ parametrische Typsysteme 

◦ virtuelle Klassen 

◦ erweiterte Typsysteme 


◦ Grundlagen, Abstraktion, Kapselung 

◦ Spezifikation funktionaler Eigenschaften 

◦ Konformität von Subklassen (behavioral subtyping) 

◦ Spezifikation von Umgebungseigenschaften 

◦ Klassen- und Modulinvarianten 

◦ Modularitätsproblematik 



◦ Verfeinerung von Spezifikation 


◦ erweitertes dynamisches Prüfen 

◦ erweitertes statisches Prüfen 

◦ Programmverifikation 

◦ Strategien zur interaktiven Verifikation 

◦ Generierung schwächster Vorbedingungen 

6. Ausblicke 



Literatur: 

• kein Buch, das gesamten Stoff abdeckt 

• Bücher über Vorlesungsteile 

• wissenschaftliche Artikel 

• Sprachspezifikationen 

Literatur wird kapitel-/abschnittsweise angegeben. 


1.2 Formale und notationelle Grundlagen 26 

1.2 Formale und notationelle Grundlagen 



• Die Sprache der (sortierten) Prädikatenlogik : 

◦ Signaturen 

◦ Terme 

◦ Formeln 

• Algebraische Datentypen 

• Abschließende Bemerkungen 



Die Sprache der Prädikatenlogik 

Definition(Signatur): 

Eine Signatur Σ = (S, F ) besteht aus 

• einer Menge S von Sorten (Namen für Datentypen) 

• einer Menge F von Funktionssymbolen (Namen für 

Funktionen) 

so dass jede f ∈ F eine Funktionalität 

f : s1 × . . . × sn → s hat mit s1, . . . , sn, s ∈ S (n ≥ 0) 

Nullstellige Funktionen werden Konstanten genannt. 



Beispiel(Signatur): 

1. Signatur der ganzen Zahlen: 

S = {Integer} 

F = {0 : → Integer 

succ : Integer → Integer 

pred : Integer → Integer 

+ : Integer × Integer → Integer 

− : Integer × Integer → Integer 

. . .} 

ΣINTEGER = (S, F ) 



2. Signatur für Keller mit Elementen aus der Sorte Elem 

S = {Elem, Stack} 

F = {emptyStack : → Stack 

push : Stack × Elem → Stack 

pop : Stack → Stack 

top : Stack → Elem} 

ΣSTACK = (S, F ) 



Bemerkung: 

• Im Folgenden gehen wir davon aus, dass 

◦ jede Signatur die Sorte Bool enthält und 

◦ für jede Sorte S eine Gleichheitsfunktion 

=S: S × S → Bool 

existiert. 

• Sorten spielen auf Spezifikationsebene die gleiche Rolle wie 

Typen in der Programmierung. Die terminologische 

Unterscheidung erleichtert im Folgenden die Trennung 

zwischen 

◦ der Sprache, die beschrieben wird, und 

◦ der Sprache, die zur Beschreibung verwendet wird. 



Definition(Terme): 

Jede Signatur Σ = (S, F ) und S-sortierte Menge VAR von 

(logischen) Variablen erzeugt eine Menge T (Σ, VAR) von 

Termen, die aus Funktionssymbolen aus F und Variablen aus 

VAR (entsprechend der Funktionalitäten der 

Funktionssymbole und der Sorten der Variablen) bestehen. 



Beispiel(Terme): 

• Sei VARSTACK = {e : Elem, s : Stack}, 

push(s, e), pop(push(s, e)), top(pop(push(s, e))), 

top(push(emptyStack, e)) sind Terme aus 

T (ΣSTACK, VARSTACK) 

• succ(0), succ(0) + succ(succ(0)) ∈ T (ΣINT EGER, ∅) 



Definition(Formeln): 

Sei Σ = (S, F ) eine Signatur, VAR eine S-sortierte Menge 

logischer Variablen und sei die Menge der Σ–Terme der 

Sorte s, bezeichnet als T (Σ, VAR)s. Die Menge der 

Σ–Formeln F (Σ) ist die kleinste Menge, die die folgenden 

Eigenschaften erfüllt: 

• jeder Term der Sorte Bool ist in F (Σ); 

• wenn G, H ∈ F (Σ), dann sind 

¬G, (G ∧ H), (G ∨ H), (G ⇒ H) und (G ⇔ H) in F (Σ); 

• wenn Xs ∈ VARs und G ∈ F (Σ), dann 

(∀Xs : G), (∃Xs : G) ∈ F (Σ). 



Bemerkung: 

• Um Klammern zu vermeiden, benutzen wir die folgenden 

Präzedenzen (von starke zu schwache Bindung): 

¬, ∧, ∨, ⇒, ⇔, ∀, ∃. 

• Prädikatenlogik wird im Folgenden hauptsächlich als 

Spezifikationssprache verwendet. 



Algebraische Datentypen 

Beispiel(algebraische Datentypen): 

Sei Elem eine bereits definierte Sorte. 

Dann definiert 

data type 

ElemList = emptyElemList () 

| app( first:Elem, rest:ElemList ) 

end 

die Signatur (S,F): 



S = {ElemList} 

F = {emptyElemList : → ElemList 

app : Elem × ElemList → ElemList 

first : ElemList → Elem 

rest : ElemList → ElemList 

isemptyElemList : ElemList → Bool 

isapp : ElemList → Bool}, 

wobei die Sorten und Funktionen die übliche Bedeutung 

haben. emptyElemList und app heißen die 

Konstruktorfunktionen (Konstruktoren) von (S,F). 



Abkürzend läßt sich der Datentyp ElemList auch so 

definieren: 

data type 

ElemList = list of Elem 

end 



Definition(Syntax algebraischer Datentypen): 

Deklarationen algebraischer Datentypen haben die Form: 

data type 

+ 

end 

wobei 

::= 

| 

::= "list of" 

::= 

( "|" )* 

::= 

"(" [ Komponentendekl ("," Komponentendekl)* ] ")" 

Komponentendekl ::= [ ":"] 



Zur Semantik algebraischer Datentypen: 

• unterschiedliche Konstruktorterme repräsentieren 

unterschiedliche Werte 

• alle Werte der Sorten sind erzeugt 

• Beweisprinzip: Induktion über den Aufbau der Terme 



Bemerkung: 

• Algebraische Datentypdeklarationen finden sich in den 

meisten funktionalen Programmiersprachen und sehr vielen 

Spezifikationssprachen. 

• Wichtiges Anwendungsgebiet ist die Spezifikation der 

abstrakten Syntax von Programmiersprachen. 



Abschließende Bemerkungen 

• Weitere Spezifikationstechniken werden im Zusammenhang 

mit ihrer Anwendung erläutert. 

• Rekursive Prädikatspezifikationen werden für operationelle 

Semantik und Typeigenschaften benötigt. 

• Ziel ist hier: eine klare Sprachebene, um Eigenschaften von 

Programmiersprachen und von Programmen ausdrücken zu 

können. 

• Ziel ist hier nicht: Formalisierung in allen Details. 


2. Grundlagen 

objektorientierter Sprachen


2.1 Konzepte objektorientierter Programmierung 

2.2 Semantik objektorientierter Sprachen 

2.3 Eigenschaften objektorientierter Programme 

2.4 Modularität und Kapselung 


44

2.1 Konzepte objektorientierter Programmierung 45 

2.1 Konzepte objektorientierter 


Programmierung


2.1.1 Grundkonzepte : 

• Objektkonzept 

• Klassifikation und Subtyping 

2.1.2 Sprachliche Konzepte : 

• Beschreibung von Objekten 

• Vererbungskonzept 

• dynamische Methodenauswahl 

• Zusammenwirken der Konzepte 



2.1.3 Pragmatische Aspekte : 

• Vererbung versus Subtyping 

• Objektorientierte Sicht auf Prozeduren und Klassen 

Ziel: 

• Wiederholung auf abstrakterem Niveau 

• Zusammenhang von Konzepten und Sprachmitteln 




2.1.1 Grundkonzepte


Objektkonzept 

,,The basic philosophy underlying object-oriented programming is to 

make the programs as far as possible reflect that part of the reality they 

are going to treat. It is then often easier to understand and to get an 

overview of what is described in programs. The reason is that human 

beings from the outset are used to and trained in the perception of what 

is going on in the real world. The closer it is possible to use this way of 

thinking in programming, the easier it is to write and understand 

programs.“ 

aus: Object-oriented Programming in the BETA Programming Language 



Objektorientiertes Paradigma: 

Betrachte ein Softwaresystem als eine Menge kooperierender 

Objekte. 

a1: 

a2: 

obj1 

m(p1,p2) {..} 

m1() {..} 

m2( p ) {..} 

obj2 


. m( 1814, "SS1999") 

a: 

obj2 

m(p1,p2) {..} 

n( p,r ) {..}


Objekte sind eigenständige Ausführungseinheiten mit: 

• Zustand 

• Identität 

• Lebensdauer 

• Aufenthaltsort 

• Verhalten 

Im Vergleich zur prozeduralen Programmierung: 

• andere Programmstruktur 

• anderes Ausführungsmodell 



Konsequenz des Objektkonzepts: 

• saubere Schnittstellenbildung 

◦ öffentlich zugängliche Methoden 

◦ öffentlich zugängliche Attribute 

• Schnittstelle verbirgt Implementierung (Information 

Hiding) 

• Schnittstelle ist Basis für Verhaltensbeschreibung 



Klassifikation: 

Klassifikation und Subtyping 

Klassifizieren ist eine allgemeine Technik, um Wissen über 

Begriffe, Dinge und deren Eigenschaften hierarchisch zu 

strukturieren. Das Ergebnis nennen wir eine Klassifikation. 



Beispiel(Klassifikation der Rechtsgebiete): 

Öffentliches 

Recht 

Bürgerliches 

Recht 


Recht 

Privatrecht Kirchenrecht 

Handelsrecht Urheberrecht


Beispiel(Klassifikation der Wirbeltiere): 

Wirbeltiere 

Fische Lurche Reptilien Säugetiere Vögel 


Wale Primaten Paarhufer


Beispiel(Klassifikation der Figuren): 

Ellipse 

Kreis 

Figur 

Vieleck 

Viereck Dreieck 

Parallelogramm 

Raute Rechteck 

Quadrat 


Der Pfeil ↗ 

repräsentiert die 

ist-ein-Beziehung. 

Ziel: Anwendung der 

Klassifikationstechnik 

auf Software-Objekte


Beobachtungen zu Klassifikationen: 

• Sie können sich auf Objekte oder Gebiete beziehen. 

• Sie können baumartig oder DAG-artig sein. 

• Objektklassifikationen begründen ist-ein-Beziehungen. 

• abstrakte Klassen vs. nicht abstrakte Klassen 

Prinzip der Substitution: 

Überall, wo Oberklassenobjekte erwartet werden, lassen sich 

auch Unterklassenobjekte verwenden. 



In der Softwaretechnik: 

1. Klassifikation syntaktisch: 

Unterklassenobjekte haben größere Schnittstellen als 

Oberklassenobjekte (Auswirkung auf 

Programmiersprache). 

2. Klassifikation semantisch: 

Unterklassenobjekte bieten mindestens das Verhalten, 

welches Oberklassenobjekte haben. 



Abstraktion: 

... das Heraussondern des unter einem bestimmten 

Gesichtspunkt Wesentlichen vom Unwesentlichen. 

[Meyers großes Taschenlexikon] 



Mittels Abstraktion: 

• ausgehend von unterschiedlichen Objekten oder Typen mit 

gemeinsamen Eigenschaften 

• Ausarbeitung eines abstrakteren Typs, der die 

gemeinsamen Eigenschaften zusammenfasst 

• entspricht dem Verkleinern der Schnittstelle 

• Programme, die sich nur auf diese gemeinsamen 

Eigenschaften stützen, arbeiten dann für alle Objekte des 

abstrakteren Typs. 



Beispiel(Abstraktion): 

class Student { 

String name; 

int matNr; 

... 

void drucken() { 

System.out. 

println( name ); 

System.out. 

println( matNr ); 

} 

} 


class Professor { 

String name; 

int telNr; 

... 


System.out. 

println( name ); 

System.out. 

println( telNr ); 

} 

}


Abstraktion: 

• Typ Person mit 

Methode drucken 

• Algorithmus auf 

Basis von Person 

Anwendungsbeispiele: 

• Ein/Ausgabe-Schnittstellen 

• Fenstersysteme 

• ... 


Person[] p = new Person[4]; 

p[0] = new Student(...); 

p[1] = new Professor(...); 

... 

for(i=1; i


interface Person { 

void drucken(); 

} 

class Student implements Person { 

... 

} 

class Professor implements Person { 

... 

} 



Spezialisierung: 

... das Hinzufügen speziellerer Eigenschaften zu einem 

Gegenstand oder das Verfeinern eines Begriffs durch 

Einführen weiterer Merkmale. 

(z.B. berufliche Spezialisierung) 



Mittels Spezialisierung: 

• ausgehend von allgemeinen Objekten bzw. Typen 

• Erweiterung dieser Objekte und ihrer Implementierung 

• entspricht dem Hinzufügen von zusätzlichen und 

spezielleren Eigenschaften 

• Voraussetzung: spezialisierte Objekte verhalten sich 

konform zu den allgemeineren Objekten 

• Programme, die auf den allgemeineren Objekten arbeiten, 

arbeiten dann auch korrekt auf den spezielleren Objekten. 

• Vererben von Implementierungsteilen,Wiederverwendung 



Beispiel(Spezialisierung): 

Spezialisierung: 

• Entwickle 

Implementierung zu 

Typ Person. 

• Spezialisiere sie. 


class Person { 

String name; 

... 

void drucken(){ 

System.out.println(name); 

} 

}


Vererbt werden: 

• Attribute 

• Methoden 

Methoden können in 

Subklassen 

überschrieben werden 


class Student extends Person { 

int matNr; 

... 


super.drucken(); 

System.out.println(matNr); 

} 

} 

class Professor extends Person { 

int telNr; 

... 



System.out.println(telNr); 

} 

}



2.1.2 Sprachliche Konzepte


• Klassenkonzept 

• Prototypkonzept 

Beschreibung von Objekten 



Klassenkonzept: 

• Der Programmierer beschreibt nicht einzelne Objekte, 

sondern deklariert Klassen. 

• Klasse = Beschreibung der Eigenschaften, die die Objekte 

dieser Klasse haben sollen 

• Während der Programmausführung werden Objekte zu 

deklarierten Klassen erzeugt (Instanzieren). 

• Klassen können zur Ausführungszeit nicht verändert werden. 

• Klassendeklaration entspricht der Deklaration von 

Verbundtypen imperativer Sprachen. 



Prototypkonzept: 

• Der Programmierer beschreibt direkt einzelne Objekte. 

• Neue Objekte werden durch Klonen existierender Objekte 

und Verändern ihrer Eigenschaften zur Ausführungszeit 

erzeugt. 

• Klonen eines Objekts obj = Erzeugen eines neuen Objekts, 

das die gleichen Eigenschaften wie obj besitzt. 

• Verändern = dem Objekt werden weitere Attribute 

hinzugefügt oder Methoden werden durch andere ersetzt. 

• Umgesetzt beispielsweise in der Sprache Self. 



Vererbung: 

Vererbungskonzept 

Sprachlich unterstützte Wiederverwendungsmöglichkeit der 

Eigenschaften/des Codes einer anderen Klasse: 

• meist mit Subtyping gekoppelt 

• ergänzt um Spezialisierungsmöglichkeiten: 

◦ Hinzufügen von Attributen, Methoden, etc. 

◦ Überschreiben von Methoden 

◦ Verwenden überschriebener Methoden 



Ziele: 

• fehlerträchtiges Kopieren von Code vermeiden 

• Reduktion der Programmgröße 

• Spezialisierung von Schnittstellen, bei denen Kopieren 

bzw. Modifizieren nicht möglich ist 



Beispiel(Vererbung): 

class Person { 

String name; 

int geburtsdatum; /* in der Form JJJJMMTT */ 


System.out.println("Name: "+ this.name); 

System.out.println("Geburtsdatum: "+ geburtsdatum); 

} 

boolean hat_geburtstag ( int datum ) { 

return (geburtsdatum % 10000) == (datum % 10000); 

} 

Person( String n, int gd ) { 

name = n; 

geburtsdatum = gd; 

} 

} 



class Student extends Person { 

int matNr; 

int semester; 



System.out.println( "Matrikelnr: " + matNr ); 

System.out.println( "Semesterzahl: " + semester ); 

} 

Student( String n, int gd, int mnr, int sem ) { 

super( n, gd ); 

matNr = mnr; 

semester = sem; 

} 

} 



Dynamische Methodenauswahl 

Methodenauswahl: 

• statisch: 

Zur Übersetzungszeit wird jeder Aufrufstelle die 

auszuführende Methode zugeordnet. 

• dynamisch: 

Zur Laufzeit wird an der Aufrufstelle das Zielobjekt 

berechnet und in Abhängigkeit vom Zielobjekt die 

auszuführende Methode ausgewählt. 



Bemerkung: 

Dynamische Methodenauswahl ist Voraussetzung: 

• für Spezialisierung 

• für das Arbeiten mit abstrakten Klassen und Schnittstellen 



Zusammenwirken der Konzepte 

Beispiel(Abstract Window Toolkit): 

1. Die Elemente der Bedienoberfläche werden als Objekte 

modelliert. 

2. Oberflächenelemente werden klassifiziert: 



Canvas 

Label 

Button 

List 

Choice 

CheckBox 

Scrollbar 

Object 

Component 

TextComponent 

TextArea TextField 


Container 

ScrollPane Window Panel 

Frame 

Dialog 

FileDialog 

Applet


3. Gemeinsame Programmteile werden in der abstrakten 

Klasse Component zusammengefasst und von dort vererbt 

(über 100 Methoden). 

4. Viele Klassen benutzen die Klasse Component als 

Abstraktion. 



Beispiel(Verwendung von Abstraktion): 

public class Container extends Component { 

... 

public Component getComponent(int n) { ... } 

public Component[] getComponents() { ... } 

public Component add(Component comp) { ... } 

public Component add(Component comp, int index) { ... } 

... 

public void remove(Component comp) { ... } 

... 

public Component getComponentAt(int x, int y) { ... } 

... 

} 



5. Dynamische Methodenauswahl ist Vorausssetzung für das 

Funktionieren der Komponentenhierarchie und für die 

Anbindung der zu steuernden Anwendungen über die 

Listener-Schnittstellen. 




2.1.3 Pragmatische Aspekte


Vererbung versus Subtyping 

1. Subtyping ohne Vererbung: 

Objektorientierte Programmierung kann auf Vererbung 

verzichten, aber nicht auf Subtyping und dynamische 

Methodenauswahl 

Beispiel(Delegation statt Vererbung): 

interface Person { 

String getName(); 

int getGeburtsdatum(); 

void drucken(); 

boolean hat_geburtstag( int datum ); 

} 



public class PersonCl implements Person { 

String name; 

int geburtsdatum; /* in der Form JJJJMMTT */ 

} 

public PersonCl( String n, int gd ) { 

name = n; 

geburtsdatum = gd; 

} 

public String getName() { return name; } 

public int getGeburtsdatum() { return geburtsdatum; } 

public void drucken() { 

System.out.println("Name: "+ this.name); 

System.out.println("Geburtsdatum: "+ this.geburtsdatum); 

} 

public boolean hat_geburtstag ( int datum ) { 

return (this.geburtsdatum%10000) == (datum%10000); 

} 



interface Student extends Person { 

public int getMatNr(); 

public int getSemester(); 

} 

public class StudentCl implements Student { 

Person personPart; 

int matNr; 

int semester; 

StudentCl( String n, int gd, int mnr, int sem ) { 

personPart = new PersonCl( n, gd ); 

matNr = mnr; 

semester = sem; 

} 

public String getName() { return personPart.getName(); } 

public int getGeburtsdatum() { return personPart.getGeburtsdatum(); } 

public void drucken() { 

personPart.drucken(); 

System.out.println( "Matrikelnr: " + matNr ); 

System.out.println( "Semesterzahl: " + semester ); 

} 



} 

public boolean hat_geburtstag( int datum ) { 

return personPart.hat_geburtstag( datum ); 

} 

public int getMatNr() { return matNr; } 

public int getSemester() { return semester; } 

public class Test { 

public static void main( String[] argv ) { 

int i; 

Person[] pf = new Person[3]; 

pf[0] = new PersonCl( "Meyer", 19631007 ); 

pf[1] = new StudentCl( "Schmidt", 19641223, 6758475, 5 ); 

pf[2] = new StudentCl( "Planck", 18580423, 3454545, 47 ); 

} 

} 

for( i = 0; i


2. Vererbung ohne Subtyping: 

Vererbung wird teilweise zur Codewiederverwendung 

benutzt, ohne eine ist-ein-Beziehung zwischen Subklassenund 

Superklassenobjekt zu etablieren (problematisches 

Vorgehen). 

Beispiel(Vererbung ohne Subtyping): 

public class List { 

public boolean contains( int i ) { return true; } 

public int getFirst( ) { return 0;} 

public void addFirst( int i ) { } 

public void removeFirst() { } 

public void remove( int i ) { } 

} 



public class Set extends List { 

public int getSome() { return getFirst(); } 

public void add( int i ) { 

addFirst(i); 

} 

public void addFirst( int i ) { 

if( !contains(i) ) super.addFirst(i); 

} 

public void removeFirst() { 

System.out.println("Should not be used!!"); 

} 

} 



Objektorientierte Sicht auf Prozeduren und 

Klassen 

1. Zeiger auf Prozeduren lassen sich über Objekte realisieren: 

◦ definiere Schnittstellentyp mit einer Methode, deren Signatur der 

Prozedursignatur entspricht 

◦ für jede Prozedur p implementiere den Schnittstellentyp durch 

Klasse KP. 

◦ statt dem Zeiger auf die Prozedur p übergebe KP-Objekt op 

◦ Aufruf: op.p(...) 



Beispiel(Zeiger auf Prozeduren): 

Call-back-Prozeduren werden im AWT durch sogenannte 

Listener-Objekte realisiert, die eine Listener-Schnittstelle 

implementieren. Besitzt diese Schnittstelle genau eine 

Methode, ergibt sich ein Verhalten wie bei 

Prozedurzeigern. 

public interface ActionListener extends EventListener { 

/** 

* Invoked when an action occurs. 

*/ 

public void actionPerformed(ActionEvent e); 

} 



2. Analogie zwischen Prozeduren und Klassen: 

◦ beides sind statische Programmelemente, von denen zur Laufzeit 

Instanzen gebildet werden (Prozedurinkarnationen, Objekte) 

◦ Prozedurinkarnationen und Objekte besitzen Identität, Zustand und 

Lebensdauer. 

◦ Besitzt ein Objekt einen eigenen Thread und kann es sein Ende selbst 

bestimmen (aktives Objekt), verhält es sich wie eine 

Prozedurinkarnation, die während der Laufzeit von ”außen” 

angesprochen werden kann. 

BETA nutzt diese Analogie und vereinheitlicht Klassen und 

Methoden zu sogenannten Pattern. 



3. Klassen als Objekte: 

Betrachtet man eine Klasse als Objekt, muss sie für ihre 

Aufgaben Methoden bereitstellen: 

◦ Erzeugen von Objekten 

◦ Auskunft über ihre Eigenschaften geben 

◦ Konstruktion neuer Klassen ermöglichen 

Beispiel(Introspektion in Java): 

import java.lang.reflect.*; 

public class Inspektor { 

public static void main(String[] ss) { 

try{ 



} 

} 

Class klasse = Class.forName( ss[0] ); 

Method[] methoden = klasse.getMethods(); 

for( int i = 0; i < methoden.length; i++ ){ 

Method m = methoden[i]; 

Class retType = m.getReturnType(); 

String methName = m.getName(); 

Class[] parTypes = m.getParameterTypes(); 

System.out.print(retType.getName()+" "+methName+"("); 

for( int j = 0; j < parTypes.length; j++ ){ 

if( j > 0 ) System.out.print(", "); 

System.out.print( parTypes[j].getName() ); 

} 

System.out.println( ");" ); 

} 

} catch( ClassNotFoundException e ) { 

System.out.println("Klasse "+ss[0]+" nicht gefunden"); 

} 


2.2 Semantik objektorientierter Sprachen 95 

2.2 Semantik objektorientierter Sprachen 


2.2.1 Einführung


Anwendungen von Semantikspezifikationen: 

• Sprachspezifikation 

• Hilfe beim Sprachentwurf 

• Grundlage zum Beweis von Spracheigenschaften 

• Grundlage zum Beweis von Programmeigenschaften 

• Klärung bei der Programmierung 



Beispiel(Binden von Attributen): 

class A { 

int i=1; 

int m() { return i*100; } 

int n() { return i+m(); } 

} 

class B extends A { 

int i=10; 

int m() { return i*1000; } 

int p() { return n(); } 

} 



public class Bindung { 

int m() { 

A[] ar = { new A(), new B() }; 

return ar[0].i + ar[0].m() + ar[1].i + ar[1].m(); 

} 

} 

public static void main(String[] argv) { 

A a = new B(); 

System.out.println(new A().m()); /* 1 */ 

System.out.println(a.m()); /* 2 */ 

System.out.println(a.i); /* 3 */ 

System.out.println(new B().p()); /* 4 */ 

System.out.println(new Bindung().m()); /* 5 */ 

} 



Beispiel(Binden von super-Aufrufen): 

class C1 { 

void m(){ 

System.out.println("in C1"); 

} 

} 

class C2 extends C1 { 

void m(){ 


super.m(); 

} 

} 



class C3 extends C2 { } 

class C4 extends C3 { 

void m(){ 


super.m(); 

} 

} 

public class Super { 

public static void main( String argv[] ){ 

C1 c1 = new C4(); 

c1.m(); 

} 

} 



2.2.2 Operationelle Semantik einer Untersprache von 

Java 



Abstrakte Syntax von Java-KE 

Package = pack(PackId ImportList TypeDeclList) 

ImportList = list of PackId 

TypeDeclList = list of TypeDecl 

TypeDecl = ClassDecl(CTypeId CTypeId ITypeIdList ClassBody) 

| InterfaceDecl(ITypeId ITypeIdList InterfaceBody) 

ClassBody = list of MemberDecl 

MemberDecl = FieldDecl(Type FieldId) 

| MethodDecl(MethodSig Statement) 

InterfaceBody = list of MethodSig 

MethodSig = Sig(Type MethodId Type) 

Type = booleanT () | intT () | nullT () | ct(CTypeId) | it(ITypeId) 



Statement = block(Type VarId Statement) 

| fread(VarId VarId FieldId) 

| fwrite(VarId FieldId VarId) 

| cassign(VarId Type Exp) 

| new(VarId CTypeId) 

| seq(Statement Statement) 

| if (Exp Statement Statement) 

| while(Exp Statement) 

| catch(Statement CTypeId VarId Statement) 

//try − body CTypeId = NullPExc or CastExc 

| invoc(VarId VarId MethodId Exp) 

| call(VarId CTypeId MethodId Exp) 

Exp = ic(Int) | bc(Bool) | null() | id(VarId) 

| unary(UnOp Exp) | binary(Exp BinOp Exp) 

PackId, FieldId, MethodId, CTypeId, ITypeId und VarId sind einfache 

Sorten. 



Kontextabhängige Syntax von Java-KE 

Kontextbedingungen: 

1. Kontextbedingungen wie in Java. Ausnahme: Die 

Methode main zum Starten eines Programmes hat genau 

einen Parameter des Typs int und liefert einen Wert des 

Typs int. 

2. Programme haben eine Klasse Object mit mindestens 

einer Methode (in diesem Fall ist der zweite Parameter von 

ClassDecl auch Object, ohne dass dies den Schluss 

erlaube, Object sei ein echter Subtyp von sich selbst). 



3. Programme haben die Klassen CastExc und NullPExc. 

4. Der CTypeId in einer call Anweisung muss die 

Superklasse bezeichnen, in der die Supermethode definiert 

ist. 

5. Deklarierte Variablen dürfen nicht res oder exc genannt 

werden. res ist implizit deklariert und sichtbar in jeder 

Anweisung, wie auch par und this. 

exc darf in Anweisungen nicht verwendet werden. 



6. FieldIds sind eindeutig, d.h. Attribute in verschiedenen 

Klassen müssen unterschiedlich benannt werden (z.B. 

durch Voranstellung des CTypeId der enthaltenden 

Klasse). 

7. Typnamen müssen eindeutig sein (zum Beispiel darf ein 

Paket P nur Pakete importieren, deren Typnamen sich von 

denen, die in P deklariert sind, unterscheiden). 



Definition(Programmbereich in Java-KE): 

Jedes Paket P definiert einen Programmbereich, der 

• P enthält sowie 

• alle direkt oder indirekt von P importierten Pakete. 

Bemerkung: 

Für jedes Programmelement (Deklaration, Anweisung) gibt 

es einen minimalen Programmbereich, in dem es enthalten 

ist. 



Statische Semantik 

Die statische Semantik liefert die Begriffe, um die 

Ausführungszustände von Programmen zu beschreiben. 



: T ype × T ype → Bool // Subtyprelation 

≺ : T ype × T ype → Bool // echte Subtyprelation 

ObjId : eine passende Menge von Objektbezeichnern 

InstVar : eine passende Menge von typisierten Instanzvariablen 

DeclMethId : eindeutige Namen für die implementierten Methoden 

VirtMethId : eindeutige Namen für die virtuellen Methoden 

ProgPart : DeclMethId | VirtMethId | Statement@ 

wobei Statement@ die Menge der Anweisungsknoten des 

kleinsten umgebenden Programmbereichs bezeichnet. 



Bemerkungen: 

• Eine implementierte Methode ist eine Methode, deren 

Rumpf in einer Klasse deklariert ist. 

• Eine virtuelle Methode ist eine Methode, die in einem Typ 

deklariert ist. 



Die Funktion vis : ProgPart → POW (VarId) liefert für 

jeden Programmteil pp die Menge der sichtbaren VarIds. 

Für Anweisungen c gilt: vis(c) enthält res, exc, this, par 

und die deklarierten lokalen Variablen. 

Für Methodenabstraktionen m gilt: 

vis(m) = {this, par, exc} 

Die Funktion typs : PackId → POW (Type) liefert für jedes 

Paket M die Menge der Typen, die in M bekannt sind. 



Werte und Abkürzungen von Java-KE 

Value = b(Bool) 

| i(Int) 

| null() 

| ref (CTypeId ObjId) 

typ : Value → Type // Typ eines Wertes 

rtyp : ProgPart → Type 

// Ergebnistyp einer Methode oder Typ von res 

styp : InstVar → Type //Typ einer Instanzvariablen 



styp : VarId × ProgPart → Type 

// deklarierter Typ einer Variablen sichtbar in ProgPart; 

// styp(exc,pp)=ct(Object); ansonsten nicht determiniert 

impl : T ype × MethodId → DeclMethId 

// impl(T,m) ist nicht determiniert, wenn T keine 

// Implementierung einer Methode m enthält. 

vm : T ype × MethodId → V irtMethId 

// vm(T,m) ist nicht determiniert, wenn m nicht in T ist 

body : DeclMethId → Statement 

vmid : V irtMethId → MethodId 

. : V alue × F ieldId → InstV ar 

//v.f liefert die Instanzvariable f des Objektes v; 

//ansonsten nicht determiniert 



Modellierung des Objektspeichers 

〈 := 〉 : Store × InstVar × Value → Store 

〈 〉 : Store × CTypeId → Store 

( ) : Store × InstVar → Value 

new : Store × CTypeId → Value 

alive : Store × Value → Value 

IV1 = IV2 ⇒ OS〈IV1 := X 〉(IV2 ) = OS(IV2 ) 

OS〈T 〉(IV ) = OS(IV ) 

alive(OS〈IV := Y 〉, X ) ⇔ alive(OS, X ) 

alive(OS〈T 〉, X ) ⇔ alive(OS, X ) ∨ X = new(OS, T ) 

alive(OS, OS(IV )) 

typ(new(OS, T )) = ct(T ) 



Zustände von Variablen und Objektspeicher 

State : (VarId → Value) × ({$} → Store) 

Zustände werden üblicherweise mit S, SQ, SR bezeichnet. 

Die Anwendung eines Zustandes auf ein VarId v wird mit 

S(v) bezeichnet, auf die Speichervariable $ mit S($). 

Eine Änderung von S in v oder $ wird mit S[v := E] bzw. 

S[$ := E] bezeichnet. 

Sei e ein Programmausdruck der Sorte Exp. Dann 

bezeichnet e[S] die Auswertung von e in S. 



Für jeden Typ wird ein initialer Wert vorausgesetzt: 

init : T ype → V alue 

typ(init(T )) T 

T kann ein Schnittstellentyp oder ein Basistyp sein. 

init(T ) kann gleich null() sein. 



Dynamische Semantik 

Wir beschreiben die dynamische Semantik operationell. 

Um nicht auf statische Methoden zurückgreifen zu müssen, 

wird die Programmausführung dadurch gestartet, dass ein 

Objekt der Startklasse Main erzeugt wird. Die Klasse Main 

muss eine Methode main haben, die beim Start mit dem 

Eingabeargument aufgerufen wird (siehe unten). Folgende 

Anweisungen erläutern, was beim Programmstart passiert: 

int input, output; 

Main mainvar; 

mainvar = new Main(); 

output = mainvar. main( input ); 



Die Semantik wird durch Relationen mit folgender Signatur 

ausgedrückt: 

psem : State × P rogram × int × int × State 

ssem : State × Statement@ × State 

Die Relationen werden induktiv durch Regeln (s.u.) definiert. 

In den Regeln schreiben wir 

SP : c → SQ anstatt ssem(SP, c, SQ) 

SP :: p(i) → r, SQ anstatt psem(SP, p, i, r, SQ) 



ssem(SP, c, SQ) bedeutet, dass die Ausführung von c mit 

Vorzustand SP terminiert und in den Nachzustand SQ führt. 

SQ(exc) = null bedeutet, dass die Ausführung von c normal 

beendet wurde. Andernfalls endete die Ausführung abrupt 

mit einer Ausnahme. 

Bemerkung: 

Die Definition von ssem setzt keine Wohltypisiertheit der 

Zustände voraus. Solche Eigenschaften werden ausgehend 

von der Definition von ssem untersucht werden. 



S[this := new(S($), Main), par := IN , exc := null, res = init(int), $ := S($)〈Main〉] 

: body(Main@main) → SQ 

S :: prog(IN ) → SQ(res), SQ 

S(y) = null 

S : x = y.a; → S[x := S($)(S(y).a)] 

Bemerkung: 

Der Gebrauch dieser Regel setzt voraus, dass S(exc) = null 

im Vorzustand, ansonsten würde eine Ausnahme, die nicht 

vorgekommen ist, im Nachzustand sichtbar sein. 



S(y) = null 

S : x = y.a; → S[$ := S($)〈NullPExc〉, exc := new(S($), NullPExc)] 

S(x) = null 

S : x.a = e; → S[$ := S($)〈S(x).a := e[S]〉] 

S(x) = null 

S : x.a = e; → S[$ := S($)〈NullPExc〉, exc := new(S($), NullPExc)] 



typ(e[S]) T 

S : x = (T )e; → S[x := e[S]] 

typ(e[S]) T 

S : x = (T )e; → S[$ := S($)〈CastExc〉, exc := new(S($), CastExc)] 

true 

S : x = newT (); → S[x := new(S($), T ), $ := S($)〈T 〉] 




S : s1 → SQ, SQ(exc) = null, SQ : s2 → SR 

S : s1 s2 → SR 

S : s1 → SQ, SQ(exc) = null 

S : s1 s2 → SQ 

e[S], S : s1 → SQ 

S : if (e){s1 }else{s2 } → SQ



¬e[S], S : s2 → SQ 

S : if (e){s1 }else{s2 } → SQ 

¬e[S] 

S : while(e){s} → S 

e[S], S : s → SQ, SQ(exc) = null 

S : while(e){s} → SQ


e[S], S : s → SQ, SQ(exc) = null, SQ : while(e){s} → SR 

S : while(e){s} → SR 

S : s0 → SQ, SQ(exc) = null 

S : try{s0 }catch(T e){s1 } → SQ 

S : s0 → SQ, SQ(exc) = null, typ(SQ(exc)) T 


S : try{s0 }catch(T e){s1 } → SQ


S : s0 → SQ, SQ(exc) = null, typ(SQ(exc)) T , 

SQ[e := SQ(exc), exc := null] : s1 → SR 

S : try{s0 }catch(T e){s1 } → SR 

S[v := init(T )] : s → SQ 

S : {T v; s} → SQ 

S(y) = null, typ(S(y)) styp(y ′ , x = y.m(e); ), DMI = impl(typ(S(y)), m), 

S[this := S(y), par := e[S], res := init(rtyp(DMI ))] : body(DMI ) → SQ 

S : x = y.m(e); → S[x := SQ(res), $ := SQ($), exc := SQ(exc)] 



S(y) = null 

S : x = y.m(e); → S[$ := S($)〈NullPExc〉, exc := new(S($), NullPExc)] 

S[par := e[S], res := init(rtyp(impl(T , m))] : body(impl(T , m)) → SQ 

S : x = superT.m(e); → S[x := SQ(res), $ := SQ($), exc := SQ(exc)] 



Ausführung mit wohltypisierten Zuständen 

Argumente, warum ssem nicht von vornherein für 

wohltypisierte Zustände definiert wurde: 

• Ein Zustand ist nur im Kontext einer Anweisung 

wohltypisiert; deswegen wird die Quantifikation über 

Zustände problematisch, wenn versucht wird, Zustände 

typkorrekt zu machen. 

• Regeln auf einfache Art formulieren und dann 

Eigenschaften über sie beweisen 

• Typsicherheit als Eigenschaft beweisbar 



wts : Store → Bool 

wts(OS) ⇔ ALL InstVar IV : typ(OS(IV )) styp(IV ) 

wt, wtp, wtr : State × ProgPart → Bool 

wt(S, pp) ⇔ S(this) = null ∧ wts(S($))∧ 

∧ ALL VarId V : V ∈ vis(pp) ⇒ typ(S(V )) styp(V , pp) 

wtp(S, pp) ⇔ wt(S, pp) ∧ S(exc) = null 

wtr(S, pp) ⇔ wt(S, pp) ∧ typ(S(res)) rtyp(pp) 

wtr wird nur für den Nachzustand von Methoden benötigt. 

Für eine Anweisung gilt: wtr(S, c) ⇔ wt(S, c). 



Ausgehend von ssem wird eine semantische Relation 

definiert, die auch für Methodenabstraktionen gilt: 

sem : State × ProgPart × State 

sem(S, c, SQ) ⇔ wtp(S, c) ∧ ssem(S, c, SQ) 

sem(S, T @m, SQ) ⇔ wtp(S, T @m)∧ 

∧ sem(S[res := init(rtyp(T @m))], body(T @m), SQ) 

sem(S, T : m, SQ) ⇔ wtp(S, T : m)∧ 

∧ sem(S, impl(typ(S(this)), m), SQ) 



2.2.3 Zur Theorie strukturell operationeller 

Semantikdefinitionen 



Definition(big step SOS): 

Eine Semantikdefinition der oben demonstrierten Art nennt 

man 

• großschrittig, weil zu einer Regelanwendung im Allg. viele 

Ausführungsschritte gehören; 

• strukturell, weil sie der syntaktischen Programmstruktur 

folgt; 

• operationell, weil sie die Ausführung des Programms 

modelliert. 

(big step structural operational semantics, big step SOS) 



Es gibt zwei Arten, eine SOS-Spezifikation zu lesen: 

1. Liste von Inferenzregeln zur Ausführung von Programmen: 

sem(S, pp, SQ) gilt genau dann, wenn es eine endliche 

Herleitung für sem(S, pp, SQ) mit den Regeln gibt. 

2. Notationelle Kurzform für eine rekursive 

Prädikatdefinition: Spezifikation eines Prädikats als 

schwächsten Fixpunkt. 



Beispiel(rekursive Prädikatdefinition): 

typ(e[S]) T 

ssem(S, x = (T )e; , S[x := e[S]]) 

ssem(S, s1 , SQ), SQ(exc) = null, ssem(SQ, s2 , SR) 

ssem(S, s1 s2 , SR) 

ssem(S, c, SR) ⇔ 

... 

∨ ((c hat die Form x = (T )e; ) ∧ typ(e[S]) T ∧ SR = S[x := e[S]] ) 

... 

∨ ((c hat die Form s1 s2 )∧ 

∃SQ : ssem(S, s1 , SQ) ∧ SQ(exc) = null ∧ ssem(SQ, s2 , SR) 

) 



Lemma: 

Java-KE ist deterministisch, d.h. ssem definiert eine partielle 

Funktion, und es gilt für alle Zustände S, SQ, SR, pp: 

ssem(S, pp, SQ) und ssem(S, pp, SR) impliziert SQ = SR 

Beweisskizze: 

Wir zeigen per Induktion nach n: 

Sind zwei Herleitungsbäume HQ, HR mit ssem(S, pp, SQ) 

bzw. ssem(S, pp, SR) als Wurzeln gegeben, tiefe(HQ) ≤ n 

und tiefe(HR) ≤ n, dann gilt HQ = HR und insbesondere 

SQ = SR. 



Induktionsanfang n = 1: 

Bei gegebenem S und pp gibt es genau eine Instanz der 

Regeln ohne Vorkommen von sem in dem Antecedent. 

Induktionsschritt n → n + 1: 

Seien HQ und HR zwei Herleitungsbäume mit 

ssem(S, pp, SQ) bzw. ssem(S, pp, SR) als Wurzeln und 

o.E.d.A. tiefe(HQ) = n + 1 und tiefe(HR) ≤ n + 1 . 



Fall 1: 

S und pp bestimmen die letzte angewendete Regel r in HR 

und HQ. 

1.1: Der Antecedent von r enthält maximal ein rekursives 

Vorkommen von ssem. Dann bestimmen S und pp den 

Vorzustand S0 und den Programmteil pp0 für dieses 

Vorkommen (in allen Regeln nur funktionale 

Abhängigkeiten). 

Nach Induktionsvoraussetzung muss dann der Nachzustand 

des zugehörigen Astes der beiden Herleitungen gleich sein. 

Damit ist aber auch SQ = SR. 



1.2: Der Antecedent von r enthält zwei rekursive 

Vorkommen von ssem. Dann bestimmen S und pp den 

Vorzustand S0 und den Programmteil pp0 für das erste 

Vorkommen (in allen Regeln nur funktionale 

Abhängigkeiten). 

Nach Induktionsvoraussetzung muss dann der Nachzustand 

des zugehörigen Astes der beiden Herleitungen gleich sein. 

Damit ist der Vorzustand für das zweite rekursive 

Vorkommen gleich. Die Induktionsvoraussetzung liefert 

wieder, dass die Nachzustände gleich sind und damit auch 

SQ = SR. Entsprechend für weitere rekursive Vorkommen. 



Fall 2: 

Gemäß S und pp kommen zwei oder drei Regeln als letzte 

Regeln in HR und HQ in Frage. In allen diesen Regeln ist der 

erste Antecedent gleich und – wie unter Fall 1 erläutert – 

ergibt sich gemäß Induktionsvoraussetzung ein gleicher 

Nachzustand zum ersten Antecedenten. Entsprechend 

angewendet auf die weiteren Antecedenten ergibt sich, dass 

die letzten Regeln in HR und HQ gleich sein müssen und 

SR=SQ. 



Bemerkung: 

Der Beweis des obigen Lemmas benutzt die 

Inferenzregel-Interpretation der Semantik. Bei der 

Fixpunktinterpretation müsste eine andere Beweistechnik 

verwendet werden. 


2.3 Eigenschaften objektorientierter Programme 141 

2.3 Eigenschaften objektorientierter 


Programme


Übersicht 

Dieser Abschnitt gibt eine kurze 

Programmeigenschaften. 

Wir unterscheiden: 

• Zusicherungen 

• Anweisungsspezifikationen 

• Ablaufeigenschaften 

• Schnittstelleneigenschaften 

• weitere Eigenschaften 


Übersicht über relevante


Definition(Programmvariable): 

Eine Programmvariable ist ein lokale Variable, ein 

Parameter, eine Instanzvariable oder eine Klassenvariable. 

Programmvariablen speichern Werte. 




2.3.1 Zusicherungen


Sei S eine Programmstelle in einem Programm P. 

Eine Zusicherung an der Stelle S ist eine Eigenschaft, die 

immer gelten soll, wenn die Ausführung S erreicht. 

Zusicherungen lassen sich mittels eines Ausdrucks oder einer 

Formel über den an S sichtbaren Größen spezifizieren. 



Beispiel(Zusicherungen): 

1. Einfache Eigenschaft: 

... 

C cobj = new C(...); 

assert cobj.x != null ; 



2. Schleifeninvariante: 

public static int isqrt( int x ){ 

int count = 0, sum = 1; 

while (sum


3. Komplexere Eigenschaft im Kontext vom AWT: 

... 

Container c; 

Button b; 

... 

c.remove(b); 

assert !EX Container cex: !EX int i: 

cex.getComponents()[i] == b; 

... 



Bemerkung: 

• Zusicherungen können Aussagen über den Zustand von 

Programmvariablen machen. 

• Werden Java-Ausdrücke zur Spezifikation verwendet, 

sollten diese seiteneffektfrei sein. 

• Zusicherungen können verwendet werden, um 

Vorbedingungen von Methoden zu beschreiben. 



2.3.2 Anweisungsspezifikationen 



Anweisungsspezifikationen beschreiben das Verhalten einer 

Anweisung, Prozedur oder Methode (im Folgenden nur für 

Anweisungen formuliert). 


• Vor- und Nachbedingungsspezifikationen 

• Ereignisspezifikation 

• Spezifikation von Terminierung 



Vor- und Nachbedingungsspezifikationen 

Im Unterschied zu Zusicherungen beziehen sich Vor- und 

Nachbedingungsspezifikationen auf zwei Zustände. 

Beispiel(Vor- und Nachbedingungsspezifikationen): 

1. Ohne Verwendung der Variablenwerte des Vorzustands 

pre x>=0 && count==0 && sum == 1 

while (sum


2. Mit Verwendung der Variablenwerte des Vorzustands 

pre a == X 

post a == X + n; 

void incrA ( int n ) { 

a += n; 

} 

Alternativ: 

pre true 

post a == \old(a) + n; 

void incrA ( int n ) { 

a += n; 

} 



Ereignisspezifikationen 

Ereignisspezifikationen machen Aussagen über Ereignisse, die 

bei der Ausführung von Anweisungen auftreten oder nicht 

auftreten dürfen. 

Typische Ereignisse beziehen sich auf: 

• Auftreten von Ausnahmen 

• Aufrufe von Methoden 

• Modifikation von Variablen 



Beispiel(Ereignisspezifikationen): 

modifiable this.width, this.height ; 

public void resize(int width, int height) { 

... 

} 

Bedeutung: 

Aufrufe von resize haben nur die Erlaubnis, die 

Instanzvariablen width, height des Zielobjektes zu ändern. 

Andere Instanzvariablen dürfen nicht modifiziert werden. 



Bemerkung: 

Bei Abschwächung der Bedeutung lassen sich 

Ereignisspezifikationen durch Vor- und 

Nachbedingungsspezifikationen ersetzen: 

pre $(IV) = X ; 

post $(IV) = X \/ IV = this.width \/ IV = this.height ; 

public void resize(int width, int height) { 

... 

} 



Spezifikation von Terminierung 

Terminierung wird meist implizit im Zusammenhang mit 

Vorbedingungen spezifiziert. Eine Spezifikation 

pre 

post 

 

bedeutet dann, wenn die Vorbedingung erfüllt ist, terminiert 

die Anweisung. 




2.3.3 Ablaufeigenschaften


Die Sequenz der Zustände, die sich bei der Ausführung eines 

Programms ergeben, nennen wir einen Ablauf. Dabei können 

die Schritte von Zustand zu Zustand mehr oder weniger 

umfangreich sein. 

Ggf. kann ein Ablauf auch mit zusätzlicher Information 

versehen sein (z.B. Aufruf und Verlassen von Methode). 

Eigenschaften, die sich auf Abläufe beziehen, nennen wir 

Ablaufeigenschaften. 




• Invarianten 

• zustandsübergreifende Eigenschaften 

• temporale Eigenschaften 



Invarianten 

Invarianten sind Eigenschaften, die grundsätzlich in allen 

Zuständen gelten sollen. 

Beispiel(Invarianten): 

1. Typinvarianten : 

Das Typsystem garantiert üblicherweise, dass in allen 

Zuständen gilt: 

Speichert eine Programmvariable V einen Wert W, dann ist 

der Typ von W ein Subtyp des (statischen) Typs von V. 



2. Klasseninvarianten : 

Klassen können mit Klasseninvarianten annotiert werden. 

Die spezifizierte Eigenschaft sollte im Wesentlichen in allen 

Ausführungszuständen gelten, in denen das betreffende 

Objekt lebt. (Mögliche Ausnahmen sind z.B. Zustände 

innerhalb der Ausführungszustände privater Methoden.) 

Beispiel(Klasseninvarianten): 

class C { 

//@ invariant myobject != null; 

SomeObject myobject; 

... 

} 



3. Klassenübergreifende Invarianten : 

• zur Beschreibung von Objektstrukturen, die aus Objekten 

mehrerer Klassen bestehen 

• Kapselungseigenschaften, z.B. die Garantie, dass 

bestimmte Objekte nur von Objekten des eigenen Pakets 

referenziert werden 



Zustandsübergreifende Eigenschaften 

Eine zustandsübergreifende Eigenschaft (engl. history 

property) bezieht sich auf mehrere Zustände. Wir 

konzentrieren uns hier auf zustandsübergreifende 

Eigenschaften, die sich auf zwei Zustände beziehen (binäre 

Eigenschaft). 

Eine binäre Eigenschaft E gilt in einem Ablauf A, wenn E für 

alle Paare (Z1, Z2) von (sichtbaren) Zuständen aus A gilt. 

Zustandsübergreifende Eigenschaften sind die einfachste 

Form, um die Entwicklungen in Abläufen zu beschreiben. 



Beispiel(Zustandsübergreifende Eigenschaften): 

1. Eine Variable x verändert nicht ihren Wert: 

constraint x == \old(x) ; 

oder 

constraint if \old(x)!= null then x == \old(x) ; 

2. Der Wert einer ganzzahligen Variablen nimmt nicht ab: 

constraint \old(x)


Temporale Eigenschaften 

Temporale Eigenschaften können sich auf beliebig viele 

Zustände beziehen und schließen Existenzaussagen sowie 

Aussagen über Teile des Ablaufs ein. 

Insbesondere umfassen sie: Lebendigkeitseigenschaften 

(etwas Gutes wird in der Zukunft passieren) 

Sie stellen eine Verallgemeinerung von Invarianz und 

zustandsübergreifenden Aussagen dar. 



Beispiel(Temporale Eigenschaften): 

1. Zustandsbezogene temporale Eigenschaften 

sometimes x != null 

x == 0 until a == 8 

2. Ereignisbezogene temporale Eigenschaften 

call(m) sometimes call(n) 

Bemerkung: 

Temporale Eigenschaften sind insbesondere im 

Zusammenhang mit parallelen Programmen wichtig. 



2.3.4 Schnittstelleneigenschaften 



Schnittstelleneigenschaften unterscheiden sich von anderen 

Programmeigenschaften dadurch, dass sie sich nicht oder 

nur teilweise auf die Implementierung beziehen dürfen. 

Schnittstelleneigenschaften benötigen Abstraktion. 

Beispiel(Schnittstelleneigenschaften): 

package org.jmlspecs.samples.stacks; 

//@ model import org.jmlspecs.models.*; 

public abstract class UnboundedStack { 

/*@ public model JMLObjectSequence theStack 

@ initially theStack != null && theStack.isEmpty(); 

@*/ 

//@ public invariant theStack != null; 




@ requires !theStack.isEmpty(); 

@ modifies theStack; 

@ ensures theStack.equals(\old(theStack.trailer())); 

@*/ 

public abstract void pop( ); 


@ modifies theStack; 

@ ensures theStack.equals(\old(theStack.insertFront(x))); 

@*/ 

public abstract void push(Object x); 



@ ensures \result == theStack.first(); 

@*/ 

public abstract Object top( ); 

} 



Bemerkung: Techniken zur Spezifikation der abstrakten 

Datenstruktur, die der Schnittstellenspezifikation zugrunde 

liegt: 

• seiteneffektfreies, auf Verständnis optimiertes 

Java-Programm 

• mathematische Modellierung 

• algebraische oder logische Theorie 




2.3.5 Weitere Eigenschaften


• nicht funktionale Eigenschaften: 

◦ Effizienz 

◦ Portabilität 

◦ Skalierbarkeit 

◦ ... 

• Kapselungseigenschaften: 

◦ Kapselungsbereiche 

◦ Sicherheitsgarantien 


2.4 Modularität und Kapselung 174 

2.4 Modularität und Kapselung 



2.4.1 Modularität und modulare Spezifikation 

2.4.2 Kapselung und Schnittstellenbildung 

2.4.3 Realisieren von Kapselung 



2.4.1 Modularität und modulare Spezifikation 



Definition(Modulare Programmierung): 

Modulare Programmierung bedeutet: 

1. Ergebnis der Programmierung sind Programmmodule, 

nicht notwendig vollständige Programme. 

2. Die Implementierung eines Moduls kann andere Module 

benutzen: Deren Implementierung muss nicht notwendig 

bekannt sein. 

3. Der Anwendungskontext eines Moduls ist zur 

Entwicklungszeit im Allg. nicht bekannt. 



Definition(Modulare Spezifikation): 

Eine Spezifikationstechnik für modulare Programme heißt 

modular, wenn sie folgende Eigenschaften besitzt: 

1. Sie ermöglicht es, Modulschnittstellen zu spezifizieren. 

2. Die Spezifikation S(M) eines Moduls M reicht aus, um M 

benutzen zu können, d.h.: 

◦ S(M) beschreibt die relevanten Eigenschaften von M. 

◦ S(M) reicht aus, um die Korrektheit von Modulen zu zeigen, die M 

benutzen. 



3. Die Korrektheit einer Modulspezifikation S(M) lässt sich 

ohne Kenntnis möglicher Anwendungskontexte von M 

zeigen, d.h. mit Kenntnis: 

◦ der Spezifikationen verwendeter Module 

◦ der Implementierung von M. 

4. Die Korrektheit einer Modulspezifikation S(M) bleibt in 

jedem zulässigen Anwendungskontext erhalten. 



Beispiel(Problematik modularer Spezifikationen): 

package somepack; 

public class C { 

protected int a = 7; 

//@ ensures \result >= 7; 

public int getA() { return a; } 

} 

Betrachte ein Modul M, das Objekte der Klasse C als 

Parameter bekommt: 

• Der Spezifikation entsprechend kann man davon ausgehen, 

dass getA immer eine Zahl größer oder gleich 7 liefert. 

• Diese Eigenschaft kann bewiesen und in Beweisen 

verwendet werden. 



Erweiterung von C: 

package someotherpack; 

import somepack.* 

public class D extends C { 

public void decrA() { a--; } 

} 

Nun kann es passieren, dass Modul M statt eines C-Objekts 

ein D-Objekt erhält. Für D-Objekte gilt aber nicht die 

Eigenschaft von getA, und die Beweise, die sich auf die 

Korrektheit von M abgestützt haben, werden ungültig. 



Lösungsansatz: 

• klare Schnittstellenbildung und Kapselung 

• Spezifikation der relevanten Eigenschaften 

• Subtypen müssen Spezifikation der Supertypen erfüllen 



2.4.2 Kapselung und Schnittstellenbildung 



Information Hiding und Kapselung (engl. encapsulation) 

werden häufig synonym bebraucht. In unserer Begriffsbildung 

ist Kapselung schärfer gefasst als Information Hiding. 



Definition(Information Hiding): 

Information Hiding ist eine Technik, um die Abhängigkeiten 

zwischen Klassen und Paketen zu reduzieren: 

• Der Anbieter stellt nur die Information (öffentlich) zur 

Verfügung, die für die Benutzung notwendig ist. 

• Der Benutzer nutzt nur die öffentliche Information. 

Dementsprechend bezieht sich Information Hiding vorrangig 

auf Software, also statische Aspekte. 



Bemerkung: 

• In der OO-Programmierung gibt es zwei Arten von 

Benutzung: 

◦ Vererbungsnutzung 

◦ Anwendungsnutzung 

• Information Hiding ermöglicht: 

◦ konsistente Namensänderungen in versteckten Programmteilen 

(unkritisch); 

◦ Veränderungen an versteckten Implementierungsteilen, soweit sie 

keine Auswirkungen auf die öffentliche Funktionalität haben 

(kritisch). 



Beispiel(Information Hiding): 

public class MyList { 

private int leng; 

private LinkedList theList; 

} 

public int length() { return leng; } 

... 



Definition(Kapselung): 

Kapselung ist eine Technik zur Strukturierung des 

Zustandsraumes ablaufender Programme. 

Ziel ist es, durch Bildung von Kapseln mit klar definierten 

Zugriffsschnittstellen die Daten- und Strukturkonsistenz zu 

gewährleisten. 



Kapseln können sein: 

• einzelne Objekte 

• zusammenhängende Objekte 

• eine Klasse (mit allen ihren Objekten) 

• alle Klassen in einer Vererbungshierarchie 

• Pakete (mit allen Klassen und deren Objekten) 

• mehrere Pakete 

Kapselung setzt eine Festlegung der Kapselgrenzen und der 

Schnittstellen an den Kapselgrenzen voraus. 

Kapselung bezieht sich vorrangig auf dynamische Aspekte. 



Bemerkung: 

• Kapselung spielt vor allem eine wichtige Rolle im 

Zusammenhang mit Verteilung und Parallelität. 

• Kapselung wird mit Mitteln des Information Hiding 

erreicht. 



Beispiel(Kapseln und Schnittstellen): 

1. Beschränkung auf privaten Zugriff garantiert keine 

Kapselung von Objekten: 

public class Privat { 


private Privat nachbar; 

} 

public void incrA(){ 

a++; 

nachbar.a++; 

} 



2. Die Java-Klasse LinkedList realisiert Kapseln mit einem 

LinkedList-Objekt und ggf. mehreren ListIterator-Objekten 

an der Schnittstelle: 



LinkedList 

Entry 

ListIterator 

Entry Entry Entry 

Object 

Object 


3 

0 

Object 

ListIterator 

2


public class LinkedList extends AbstractSequentialList 

implements List, Cloneable, java.io.Serializable 

{ 

public LinkedList(); 

public LinkedList(Collection c); 

public Object getFirst(); public Object getLast(); 

public Object removeFirst(); public Object removeLast(); 

public void addFirst(Object o); public void addLast(Object o); 

public boolean contains(Object o); public int size(); 

... 

public ListIterator listIterator(int index); 

... } 

public interface ListIterator extends Iterator { 

boolean hasNext(); Object next(); 

boolean hasPrevious(); Object previous(); 

int nextIndex(); int previousIndex(); 

void remove(); 

void set(Object o); void add(Object o); } 



3. Sicherheitslücke in Java 1.1.1: 

public final class Class ... { 

... 

private Identity[] signers; 

... 

public Identity[] getSigners() { 

return signers; 

} 

} 



2.4.3 Realisieren von Kapselung 



Programmiersprachen stellen Sprachkonstrukte fürs 

Information Hiding bereit; z.B. in Java: 

• Zugriffsrechte: public, default, protected, private 

• Einschränkung der Vererbung: final 

• Innere Klassen 

Damit lässt sich Kapselung realisieren. Eine direkte 

Unterstützung von Kapselung durch Sprachen gibt es nicht. 



Beispiel(Kapselung): 

Die Klasse LinkedList implementiert Kapseln (s.o.) und 

schließt darin die Repräsentationsobjekte vom Typ Entry ein. 

Sie garantiert die folgenden Eigenschaften: 

a) Zugriff ist nur über LinkedList- und ListIterator-Objekte 

möglich. 

b) Benutzer besitzen keine Referenz auf Entry-Objekte. 

c) Zwei Kapseln haben keine Objekte gemeinsam. 

d) Die Eigenschaften bleiben bei Vererbung erhalten. 



Realisierung: 

• Klasse Entry und Attribute mit Entry-Referenzen sind nur 

privat zugreifbar. 

• Klasse, die die Listeniteratoren implementiert, ist privat; 

deshalb lassen sich Iteratoren von außen nur über eine 

Methode von LinkedList-Objekten erzeugen. 

• Methoden der Schnittstellenobjekte geben keine 

Referenzen auf Repräsentationsobjekte heraus. 

Repräsentationsobjekte können nicht von außen 

eingeschleust werden. 



Diskussion anhand der Implementierung: 

public class LinkedList ... 

{ 

private ... Entry header = new Entry(null, null, null); 

private ... int size = 0; 

public LinkedList() { ... } 

... // public methods 

private Entry entry(int index) { ... } 

public ListIterator listIterator(int index) { 

return new ListItr(index); 

} 


} 


private class ListItr implements ListIterator { 

private Entry lastReturned = header; 

private Entry next; 

private int nextIndex; 

... 

} 

private static class Entry { 

Object element; 

Entry next; 

Entry previous; 

... 

} 

private Entry addBefore(Object o, Entry e) { ... } 

private void remove(Entry e) { ... } 



Lesen Sie zu 2.4: 

A. Poetzsch-Heffter: 

Konzepte objektorientierter Programmierung, 

Springer-Verlag, 2000; 

Abschnitt 3.3, S. 157-171. 


3. Techniken zum Prüfen 

objektorientierter Programme

3. Techniken zum Prüfen objektorientierter 

3.1 Einführung 

Programme 

3.1.1 Typinformation und ihre statische und dynamische 

Prüfung 

3.1.2 Typsicherheit 

3.2 Parametrische Typsysteme und Virtuelle Klassen 

3.3 Typsysteme zur Strukturierung von Objektgeflechten 

3.4 Erweiterte statische Prüfung 


204

3.1 Einführung 205 


3.1 Einführung


Ein Typ beschreibt Eigenschaften von Werten bzw. Objekten 

(Beispiele: int, Object, LinkedList〈A〉). 

Typisierung bedeutet die Annotierung von 

Programmelementen mit Typen: 

• Ausdrücke: Jede Auswertung liefert einen Wert vom Typ 

des Ausdrucks. 

• Prozeduren/Methoden: Wenn die aktuellen Parameter den 

richtigen Typ haben, ist das Ergebnis vom Ergebnistyp. 

• Variablen: Eine Variable enthält nur Werte von ihrem Typ. 



Typisierung ist eine der erfolgreichsten Anwendungen 

formaler Techniken. 

Definition(Typsystem): 

Das Typsystem einer Sprache S beschreibt, 

• welche Typen es in S gibt, 

• wie Programme von S typisiert werden, 

• welche Bedingungen typisierte Programme erfüllen müssen 

(Typisierungsbedingungen). 

Ein Programm, das die Typisierungsbedingungen erfüllt, 

heißt typkorrekt. 



Definition(Typfehler): 

Ein Typfehler tritt auf, wenn 

• einer Variablen ein Wert von einem falschen Typ 

zugewiesen wird; 

• eine Operation mit aktuellen Parametern aufgerufen wird, 

für die sie nicht definiert ist. 

Ein Typisierungsfehler tritt auf, wenn ein Programm nicht 

typkorrekt ist. 



Definition(typsicher): 

Eine Sprache heißt typsicher (engl. type-safe), wenn bei 

Ausführung ihrer (typkorrekten) Programme keine Typfehler 

auftreten. 

Ein Typsystem heißt sicher (engl. sound), wenn es 

Typsicherheit garantiert. 



Bemerkung: 

• Es gibt Programme, die nicht typkorrekt sind, aber 

trotzdem nicht zu Typfehlern führen. 

• Bei einem sicheren Typsystem folgt Typsicherheit also aus 

Typkorrektheit. 

Literatur zur Typisierung: 

Kim B. Bruce: Foundations of Object-Oriented Languages. 

Types and Semantics. MIT Press, 2002. 



3.1.1 Typinformation und ihre statische und 

dynamische Prüfung 



Bei Objekten liefert der Typ insbesondere die Information, 

welche Nachrichten ein Objekt versteht. Damit kann in 

einem typkorrekten Programm gewährleistet werden, dass zu 

jedem Methodenaufruf eine Methodenimplementierung 

existiert. 

Ziele der Typisierung in der OO-Programmierung: 

• Vermeidung von Typfehlern 

• Optimierung 

• Dokumentation 

• Abstraktion 



Definition(Typprüfung): 

Die Typprüfung besteht aus der (statischen) Prüfung der 

Typisierungsbedingungen und der Prüfung von 

Typeigenschaften zur Laufzeit (dynamische Typprüfung). 

Eine typsichere Sprache heißt statisch typisiert, wenn sie 

keine dynamische Typprüfung vorsieht. 



Beispiel(statisch typisiert): 

Java ist nicht statisch typisiert, sondern verlangt dynamische 

Typprüfung bei: 

• der Typkonvertierung (casts): 

Object obj = "Ich neues String-Objekt"; 

String str = (String) obj; 

... 

• Feldzugriffen: 

String[] strfeld = new String[2]; 

Object[] objfeld = strfeld; 

objfeld[0] = new Object(); 

int strl = strfeld[0].length(); 



Typisierungsproblematik in OO-Sprachen 

Damit ein Subtyp-Objekt an allen Stellen vorkommen kann, 

an denen ein Supertyp-Objekt erwartet wird, muss garantiert 

sein, dass 

• ein Subtyp-Objekt alle Attribute seiner Supertypen hat; 

• ein Subtyp-Objekt alle Methoden der Supertypen hat; 

• die Attribute und Methoden im Subtyp zu denen in den 

Supertypen typmäßig passen. 



Definition(Ko-/Kontravarianz): 

Sei S ein Subtyp von T. 

Sei TV ein Typvorkommen in T (Attribut-, Parameter-, 

Ergebnistyp) und SV das entsprechende Typvorkommen in S. 

Wir sagen: 

• SV und TV sind kovariant, wenn SV ein Subtyp von TV 

ist. 

• SV und TV sind kontravariant, wenn TV ein Subtyp von 

SV ist. 



Fakt: 

OO-Sprachen lassen sich nur dann statisch typisieren, wenn: 

• Attributtypen ko- und kontravariant, d.h. invariant sind. 

• Parametertypen kontravariant sind. 

• Ergebnistypen kovariant sind. 

Beispiel(Ko-/Kontravarianz): 

interface C1 { String a; ... } 

class D1 implements C1 { Object a; ... } 

... 

C1 cvar = new D1(); // initialisiert a 

String svar = cvar.a; 

// Typfehler: Kovarianz nicht gegeben 



interface C2 { Object a; ... } 

class D2 implements C2 { String a; ... } 

... 

C2 cvar = new D2(); 

cvar.a = new Object(); 

// Typfehler: Kontravarianz nicht gegeben 

interface C3 { String m(); ... } 

class D3 implements C3 { Object m(){...} ...} 

... 


String svar = cvar.m(); 

// Typfehler: Kovarianz nicht gegeben 



interface C4 { int m(Object p); ... } 

class D4 implements C4 { 

int m(String s){ 

s.length();... 

} 

... 

} 

... 


cvar.m( new Object() ); 

// Typfehler bei Ausfuehrung von m: 

// Kontravarianz nicht gegeben 

Entsprechendes gilt für die Typen der erlaubten Ausnahmen 

einer Methode. 



Bemerkung: 

• Die Ko- und Kontravarianz sind grundlegend für das 

Verständnis von Typsystemen und konformer 

Subtypbildung in OO-Sprachen. 

• Java bietet ein recht inflexibles Typsystem: 

◦ keine echt kontravarianten Parametertypen 

◦ keine echt kovarianten Ergebnistypen 

◦ Kovarianz nur bei den erlaubten Ausnahmen 




3.1.2 Typsicherheit


Wir diskutieren Typsicherheit am Beispiel von Java-KE. 

Typsystem von Java-KE: 

• Typen: boolean, int, Null und ein Typ für jede deklarierte 

Klasse und Schnittstelle. 

• Subtypbeziehung wie in Java: 

◦ Alle Referenztypen sind Subtyp von Object 

◦ Jede Typdeklaration für T legt die direkten Supertypen von T fest. 

◦ Null ist Subtyp aller Referenztypen 

◦ keine Subtypbeziehung zwischen Basisdatentypen und zwischen 

Basisdaten- und Referenztypen. 



• Typisierung von Java-KE: 

◦ Deklarationen sind typisiert; 

◦ Ausdrücke gemäß Signatur der Operatoren, der Variablendeklaration 

bzw. Konstanten (null bekommt den Typ Null); 

◦ Anweisungsteile gemäß den Deklarationen. 



• Typisierungsbedingungen von Java-KE: 

◦ Eine überschreibende Methode hat die gleichen Parameter- und 

Ergebnistypen wie die überschriebene Methode. 

◦ Ausdrücke in if- und while-Anweisungen müssen vom Typ boolean sein 

◦ Der Zieltyp C bei einer Typkonvertierung, x=(C) e, muss ein Subtyp 

vom Typ von e sein. 

◦ Der Typ der linken Seite einer Zuweisung, x = e, muss ein Supertyp 

vom Typ von e sein. 



Lemma: 

Das Typsystem von Java-KE ist sicher. Für jede Anweisung 

pp und Zustände S, SQ gilt: 

wt(S, pp) ∧ ssem(S, pp, SQ) ⇒ wt(SQ, pp) 

wobei wt wie auf Folie 129 definiert ist. 

Beweisskizze: 

Seien S und pp beliebig. Der syntaktischen Interpretation 

der SOS von Java-KE zu Folge, gibt es einen Herleitungsbaum 

HQ von endlicher Tiefe für ssem(S, pp, SQ). 



Induktion nach der Herleitungstiefe n von HQ: 

Induktionsanfang n=1: 

Fallunterscheidung über die nicht-rekursiven Regeln. Wir 

betrachten hier exemplarisch die 1. Regel für die Zuweisung 

mit Typkonvertierung. Z.z.: 



wt(S[x := e[S]], pp) mit pp = (x = (T )e) 

⇔ // wg. Definition von wt 

S[x := e[S]](this) = null ∧ wts(S[x := e[S]]($)) 

∧ ∀VarId V : V ∈ vis(pp) 

⇒ typ(S[x := e[S]](V )) styp(V , pp) 

⇐ // wg. x = this 



⇐ // wg. x = this 

S(this) = null ∧ wts(S($)) ∧ typ(e[S]) styp(x, pp)∧ 

∀ VarId V : V ∈ vis(pp) ⇒ typ(S(V )) styp(V , pp) 

⇐ // wg. typ(e[S]) T aus Antecedent der Regel, 

// und T styp(x, pp) aus Typisierungsbedingungen 

wt(S, pp) 

Entsprechend müssen alle anderen nicht-rekursiven 

Inferenzregeln untersucht werden. 



Induktionsschritt n→n+1: 

Fallunterscheidung über die Regeln mit ssem im Antecedent. 

Wir betrachten hier exemplarisch die Regel für if-then-else 

und nehmen e[S] an. Z.z.: 

wt(SQ, pp) mit pp = if (e){s1 }else{s2 } 

⇔ // wg. Definition von wt 

wt(SQ, s1 ) 

Und das folgt wegen ssem(S, s1 , SQ) und wt(S, s1 ) aus der 

Induktionsvoraussetzung. Entsprechend müssen alle anderen 

rekursiven Inferenzregeln untersucht werden. 



Literatur zu Typsicherheit von OO-Sprachen: 

S. Drossopoulou, S. Eisenbach: Java is Type Safe — Probably. 

European Conference on Object-Oriented 

Programming, 1997 (LNCS 1241). 

T. Nipkow, D. v. Oheimb: Java light is Type-Safe — Definitely. 

Principles of Programming Languages, 1998. 

A. Igarashi, B. Pierce, P. Wadler: 

Featherweight Java: A Minimal Core Calculus for Java and GJ 

Object-Oriented Programming, Systems, Languages, and Applications, 

1999. 


3.2 Parametrische Typsysteme und virtuelle Klassen 231 

3.2 Parametrische Typsysteme und virtuelle 


Klassen


Reine Subtyp-Polymorphie bietet bei bestimmten wichtigen 

Anwendungssituationen keine ausreichende Unterstützung: 

• Parametrisierung von Typen 

• Spezialisieren verwendeter Typen in Subklassen 

Dieser Abschnitt erläutert Lösungen für diese Probleme. 



3.2.1 Parametrische Typsysteme 



Parametrisierung von Softwarekomponenten ist ein 

entscheidender Weg zur Wiederverwendung. 

Subtyp-Polymorphie leistet dazu eine wichtigen Beitrag. 

Nachteile: 

• Spezialisierung nur entlang der Subtyp-Ordnung 

• Keine Parametrisierung bzgl. verwendeter Typen 

• Keine Einschränkung der Polymorphie 

Moderne OO-Sprachen kombinieren Subtyp- und 

parametrische Polymorphie. 



Wir betrachten hier GJ als Beispiel einer OO-Sprache mit 

parametrischem Polymorphismus. 

Literatur: 

G. Bracha, M. Odersky, D. Stoutamire, P. Wadler: 

Making the future safe for the past: Adding Genericity to 

the Java Programming Language. 

Object-Oriented Programming, Systems, Languages, and 

Applications, 1998. 



Parametrische/generische Typen 

Idee: Erlaube an Anwendungsstellen von Typen Typvariablen 

anstelle von Typen. 

Dadurch ergeben sich parametrisierte Klassen- und 

Schnittstellendeklarationen. Die Typvariablen müssen beim 

deklarierten Typ vereinbart werden. 

Beispiel(Typvariablen): 

class Pair { 

A fst; 

B snd; 

Pair(A f,B s){ ... } 

... 

} 



Pair〈A,B〉 heißt ein parametrisierter Typ. 

Pair heißt Typkonstruktor. 

Typparameter werden bei der Objekterzeugung instanziert: 

Pair paarvar = 

new Pair ( 

new String(), new Integer() ); 

Ein Typ wird in GJ dargestellt durch: 

• einen (parameterloser) Typbezeichner, 

• eine Typvariable, 

• einen Typkonstruktor angewandt auf Typen. 



Beispiele: 

• String 

• A, wobei A eine deklarierte Typvariable ist. 

• Pair〈String, Object〉 

• Pair〈Pair〈A,A〉, String〉 

Wichtigste Anwendung parametrisierter Typen sind 

Kollektionstypen und frei erzeugte Typen. 



interface Collection { 

public void add (A x); 

public Iterator iterator (); 

} 

interface Iterator { 

public A next (); 

public boolean hasNext (); 

} 

class NoSuchElementException extends RuntimeException {} 



class LinkedList implements Collection { 

protected class Node { 

A elt; 

Node next = null; 

Node (A elt) { this.elt = elt; } 

} 

protected Node head = null, tail = null; 

public LinkedList () {} 

public void add (A elt) { 

if (head == null) { 

head = new Node(elt); 

tail = head; 

} else { 

tail.next = new Node(elt); 

tail = tail.next; 

} 

} 


} 


public Iterator iterator () { 

return new Iterator () { 

protected Node ptr = head; 

public boolean hasNext () { 

return ptr != null; 

} 

public A next () { 

if (ptr != null) { 

A elt = ptr.elt; 

ptr = ptr.next; 

return elt; 

} else { 

throw new 

NoSuchElementException (); 

} 

} 

}; 

} 



class Test { 

public static void main (String[] a) { 

LinkedList ys = new LinkedList(); 

ys.add("zero"); 

ys.add("one"); 

String y = ys.iterator().next(); 

} 

} 



Parametrische/generische Methoden 

Analog zu Typdeklarationen lassen sich auch 

Methodendeklarationen parametrisieren. 

Beispiel(Parametrische Methoden): 

interface SomeCollection extends Collection { 

public A some(); 

} 

class Collections { 

public static 

Pair somepair(SomeCollection xa, 

SomeCollection xb ) { 

return new Pair(xa.some(),xb.some()); 

} 

} 



Einschränkung von Typvariablen 

Manchmal möchte man die Instanzierung von Typvariablen 

auf bestimmte Typen einschränken. In GJ lassen sich solche 

Einschränkungen (engl. bounds) bei der Deklaration der 

Typvariablen angeben: 

〈A implements T〉 

〈B extends T〉 



Beispiel(Einschränkung von Typvariablen): 

interface Comparable { 

public int compareTo (A that); 

} 

class Byte implements Comparable { 

private byte value; 

public Byte (byte value) { 

this.value = value; 

} 

public byte byteValue () { return value; } 

public int compareTo (Byte that) { 

return this.value - that.value; 

} 

} 




public static 

A max (Collection xs) { 

Iterator xi = xs.iterator(); 

A w = xi.next(); 

while (xi.hasNext()) { 

A x = xi.next(); 

if (w.compareTo(x) < 0) w = x; 

} 

return w; 

} 

} 



Bemerkung: 

• Trotz der relativ einfachen Erweiterung des Typsystems 

ergeben sich bereits recht umfangreiche Typisierungsregeln. 

• Generische Typen und Methoden sind kanonische Beispiele 

für parametrische Softwarekomponenten. 



Subtyping zwischen parametrischen Typen 

Auch für parametrische Typen gilt: 

Ein Typ ist nur dann ein Subtyp eines anderen, wenn die 

Subtypbeziehung explizit aus den Deklarationen oder 

Einschränkungen ersichtlich ist: 

LinkedList implements Collection 

SomeCollection extends Collection 

Byte implements Comparable 

 



Die Subtypbeziehung zwischen Typparametern überträgt sich 

nicht auf parametrische Typen: 

LinkedList LinkedList 

Es wird Invarianz bei den Parametern verlangt. 



Beispiel(Subtypbeziehung): 

Folgendes Beispiel zeigt, warum Gleichheit bei aktuellen 

Typparametern verlangt wird: 

class Loophole { 

public static String loophole (Byte y) { 

LinkedList xs = new LinkedList(); 

LinkedList ys = xs; 

// Uebersetzungsfehler 

ys.add(y); 

return xs.iterator().next(); 

} 

} 

Anders als bei Feldern ist der Typ des Parameters zur 

Laufzeit nicht verfügbar. Deshalb ist eine dynamische 

Prüfung wie bei Feldern nicht möglich. 



Typinferenz 

GJ benutzt einen Typinferenzalgorithmus, der 

• lokal ist, d.h. der Typ eines Ausdrucks ergibt sich nur aus 

den Typen der Teilausdrücke; 

• Ausdrücke von beliebigem Referenztyp bewältigen kann 

(null, leere Listen); 

• Subsumption beherrscht, d.h. der Typ T eines Ausdrucks 

kann zu jedem beliebigen Supertyp verallgemeinert werden. 



Beispiel(Typinferenz): 

class ListFactory { 

public LinkedList empty () { 

return new LinkedList(); 

} 

public LinkedList singleton (A x) { 


xs.add(x); 

return xs; 

} 

public LinkedList doublet (A x, A y) { 


xs.add(x); 

xs.add(y); 

return xs; 

} 

} 



class Test { 

static ListFactory f = new ListFactory(); 

public static void main (String[ ] args) { 

LinkedList zs = f.doublet(new Integer(1), new Float(1.0)); 

LinkedList ys = f.singleton(null); 

LinkedList xs = f.empty(); 

LinkedList err = f.doublet("abc", new Integer(1)); 

// compile-time error 

} 

} 



Lösungsidee: 

Erweitere die Typausdrücke um den Typ ’*’, der Subtyp aller 

Referenztypen ist. Für ’*’ wird kovariantes Subtyping auf 

Parameterposition akzeptiert, d.h. z.B.: 

LinkedList ist Subtyp von LinkedList 

Pair ist Subtyp von Pair 

Für Typsicherheit ist folgende Linearitätseinschränkung 

erforderlich: 

Eine Typvariable, die mehrfach als Ergebnistyp einer 

Methode vorkommt, darf nicht durch ’*’ instanziert werden. 



Beispiel(Typinferenz): 

class Cell { 

public A value; 

public Cell (A v) { value = v; } 

public static Cell make (A x) { 

return new Cell(x); 

} 

} 

class Pair { 

public B fst; 

public C snd; 

public Pair (B x, C y) { fst = x; snd = y; } 

public static Pair duplicate (D x) { 

return new Pair(x,x); 

} 

} 



class Loophole { 

public static String loophole (Byte y) { 

Pair p = 

Pair.duplicate(Cell.make(null)); 

// compile-time error 

p.snd.value = y; 

return p.fst.value; 

} 

public static String permitted (String x) { 

Pair p = 

Pair.duplicate(Cell.make((String)null)); 

p.fst.value = x; 

return p.snd.value; 

} 

} 

Nach Inferenz der Typen ist die Typprüfung einfach. 



Realisierung von Generic Java 

Im Wesentlichen läßt sich GJ direkt nach Java übersetzen. 

Die Implementierung parametrischer Typen basiert auf: 

• Parameterlöschung: 

◦ Löschen der Typparameter 

◦ Verwenden von Object anstelle von Typvariablen 

◦ Einsetzen geeigneter Typkonvertierungen (casts) 

• Brückenmethoden 

◦ Wenn eine Subklasse eine Typvariable einer Superklasse instanziert, 

sind ggf. zusätzliche Methoden mit geeigneter Signatur 

hinzuzufügen. 



Beispiel(Parameterlöschung und Brückenmethoden): 

Durch Parameterlöschung und Einführen von 

Brückenmethoden erhält man zu obigem Beispiel: 

interface Comparable { 

public int compareTo (Object that); 

} 

class Byte implements Comparable { 

private byte value; 

public Byte (byte value) { this.value = value; } 

public byte byteValue () { return value; } 

public int compareTo (Byte that) { 

return this.value - that.value; 

} 

public int compareTo (Object that) { 

return this.compareTo((Byte)that); 

} 

} 




public static Comparable max (Collection xs) { 

Iterator xi = xs.iterator(); 

Comparable w = (Comparable)xi.next(); 

while (xi.hasNext()) { 

Comparable x = (Comparable)xi.next(); 

if (w.compareTo(x) < 0) w = x; 

} 

return w; 

} 

} 



Probleme mit der erläuterten Technik treten auf, wenn 

Typparameter nur in Rückgabetypen vorkommen: 

class Interval implements Iterator { 

private int i, n; 

public Interval (int l, int u) { i=l; n=u; } 

public boolean hasNext () { return (i


Parameterlöschung und Einführen von Brückenmethoden 

liefert: 

class Interval implements Iterator { 

private int i, n; 

public Interval (int l, int u) { i = l; n = u; } 

public boolean hasNext () { return (i



3.2.2 Virtuelle Typen


Statt Parametrisierung von Typen kann Spezialisierung 

verwendet werden. Dies ergibt eine andere Art Generizität: 

class Vector { 

typedef ElemType as Object; 

void addElement( ElemType e ) { ... } 

ElemType elementAt( int index ) { ... } 

} 

class PointVector extends Vector{ 

typedef ElemType as Point; 

} 

Man nennt ElemType hier einen virtuellen Typ. Virtuelle 

Typen können in Subklassen mit Subtypen überschrieben 

werden. 



Im Folgenden betrachten wir eine Erweiterung von Java um 

virtuelle Typen. 

Literatur: 

Kresten Krab Thorup: 

Genericity in Java with Virtual Types. 

European Conference on Object-Oriented Programming, 

1997. 



Aspekte virtueller Typen 

1. Unterscheidung zwischen parametrischen Typen und 

,,normalen“ Typen ist nicht nötig: 

interface IteratorOfObject { 

typedef A as Object; 

public A next (); 

public boolean hasNext (); 

} 

interface CollectionOfObject { 

typedef A as Object; 

typedef IteratorOfA as IteratorOfObject; 

public void add (A x); 

public IteratorOfA iterator (); 

} 

class NoSuchElementException extends RuntimeException {} 



class LinkedListOfObject implements CollectionOfObject { 

// erbt die virtuellen Typen A und IteratorOfA 

protected class Node { 

A elt; 

Node next = null; 

Node (A elt) { this.elt = elt; } 

} 

protected Node head = null, tail = null; 

} 

public LinkedListOfObject () {} 

public void add (A elt) { ... /* wie auf Folie 240 */ } 

public IteratorOfA iterator () { 

return new IteratorOfA () {... /* wie auf Folie 241 */ }; 

} 



interface IteratorOfString extends IteratorOfObject { 

typedef A as String; 

} 

class LinkedListOfString extends LinkedListOfObject { 

typedef A as String; 

typedef IteratorOfA as IteratorOfString; 

} 

class Test { 

public static void main (String[] a) { 

LinkedListOfString ys = new LinkedListOfString(); 

ys.add("zero"); 

ys.add("one"); 

String y = ys.iterator().next(); 

} 

} 

Jede Instanzierung benötigt eigene Typdeklaration. 



2. Subtypbeziehungen zwischen generischen Typen können 

deklariert werden: 

LinkedListOfString ist Subtyp von 

LinkedListOfObject; also ist folgendes Fragment 

typkorrekt: 

LinkedListOfString strl = new LinkedListOfString(); 

LinkedListOfObject objl = strl; 

objl.add( new Object() ); // VirtualTypeCastException 

Die durch virtuelle Typen entstehende Kovarianz bei 

Methodenparametern wird durch dynamische Typprüfung 

abgefangen. 



3. Rekursive Typen und Zusammenhang mit Vererbung 

lassen sich besser realisieren. 

a) Verschränkte Rekursion am Beispiel des 

Observer-Musters: 

interface Observer { 

typedef SType as Subject; 

typedef EventType as Object; 

void notify (SType subj, EventType e); 

} 

class Subject { 

typedef OType as Observer; 

typedef EventType as Object; 

OType observers[]; 


} 


notifyObservers (EventType e) { 

int len = observers.length; 

for (int i=0; i


b) Rekursives Vorkommen des deklarierten Typs: 

Der deklarierte Typ K kann im Rumpf seiner Deklaration mit 

,,This“ bezeichnet werden. Dann werden in einer Subklasse 

SUBK alle diese Vorkommen als Vorkommen von SUBK 

interpretiert und entsprechend in weiteren Subtypen: 



class SLinkedList { 

This tail; 

public This getTail() { return tail; } 

} 

class SLinkedListOfObject extends SLinkedList { 

typedef Elem as Object; 

Elem head; 

public Elem getHead() { return head; } 

} 

class SLinkedListOfString extends SLinkedListObject { 

typedef Elem as String; 

// SLinkedListOfString.getTail liefert SLinkedListOfString 

} 



Diskussion virtueller Typen 

• Vorteile: 

◦ keine neue Beziehung zwischen Typen (nur ,,ist Subtyp von“, nicht 

,,ist Typinstanz von“) 

◦ Subtypbeziehung zwischen ,,parametrischem“ und ,,instanziertem“ 

Typ möglich 

◦ Rekursive Abhängigkeiten lassen sich flexibler behandeln 



• Nachteile: 

◦ Zusätzliche dynamische Typprüfung sind nötig (vor allem wegen 

kovarianten Methodenparametern): 

⊲ Verlust an statischer Typprüfbarkeit 

⊲ Verlust an Effizienz 

◦ rekursive Instanzierung (Beispiel Byte, Folie 245 ) nicht unterstützt. 



• Anmerkungen: 

◦ Der Vorschlag von Thorup erlaubt es, virtuelle Typen als Subtypen 

mehrerer Typen zu deklarieren und dabei einen Klassentypen für die 

Erzeugung von Objekten auszuzeichnen. 

◦ Es gibt mittlerweile mehrere Arbeiten, die eine Integration von 

parametrischen und virtuellen Typen vorschlagen, z.B.: 

K. Bruce, M. Odersky, P. Wadler: 

A statically safe alternative to virtual types. 

European Conference on Object-Oriented Programming, 1998. 



Realisierung virtueller Typen 

Typsicherheit wird in der Realisierung der vorgestellten 

Variante durch Einführen dynamischer Prüfungen erzielt. 

Wir unterscheiden primäre und überschreibende 

Deklarationen virtueller Typen. 



Wesentliche Ideen: 

• Benutze für die Umsetzung eines virtuellen Typs T den 

Typ aus der primären Deklaration von T. 

• Definiere für jede primäre Deklaration eines virtuellen 

Typen T eine Cast-Methode. Diese Cast-Methode wird in 

Subtypen mit überschreibenden Deklarationen für T 

überschrieben. 

• Benutze die Cast-Methode zur Prüfung aktueller Parameter. 

• Um Typkorrektheit in den resultierenden Java-Programmen 

zu erreichen, füge weitere Typkonvertierungen ein (Casts). 



Beispiel(Realisierung virtueller Typen): 


typedef ElemType as Object; 

void addElement( ElemType e ) { ... } 

... 

} 

class PointVector extends Vector { 

typedef ElemType as Point; 

void addElement( ElemType e ) { 

... 

e.getX() 

... 

} 

} 

PointVector pv; 

Point pnt; 

... 

pv.addElement(pnt); 



wird umgesetzt in 


Object cast$T(Object o) { return o; } 

void check$addElement( Object o ) { 

this.addElement( this.cast$T(o) ); 

} 

void addElement( Object e ) { ... } 

... 

} 



class PointVector extends Vector { 

Object cast$T(Object o) { 

try { 

return (Point)o; 

} catch( ClassCastException c ) { 

throw new VirtualTypeCastException (...); 

} 

} 

void addElement( Object e$0 ) { 

Point e = (Point)e$0; 

... 

e.getX() 

... 

} 

} 

PointVector pv; 

Point pnt; 

... 

pv.check$addElement(pnt); 


3.3 Typsysteme zur Strukturierung von Objektgeflechten 281 

3.3 Typsysteme zur Strukturierung von 


Objektgeflechten


Typisierungstechniken kann man nicht nur zur Vermeidung 

(klassischer) Typfehlern nutzen, sondern auch zur 

Sicherstellung anderer Invarianten. 

Wir betrachten hier die Sicherstellung von Kapselungseigenschaften 

(vgl. 2.4.2 ): 

3.3.1 Kapselung auf Paketebene: Confined Types 

3.3.2 Andere Strukturierungsanätze 



3.3.1 Kapselung auf Paketebene: Confined Types 



Ziel: 

Garantiere, dass Objekte bestimmter Typen nur vom 

Programmcode eines Packages manipuliert werden. 



Grundideen: 

1. Betrachte jedes Paket P als Kapsel; d.h. alle Objekte (der 

Klassen) von P liegen in der gleichen Kapsel. Kapseln sind 

also disjunkt. 

2. Markiere Typen, deren Objekte gekapselt werden sollen, 

als ,,confined“. Die Objekte dieser Typen nennen wir 

gekapselt. 

3. Lege Regeln fest, die garantieren, dass Referenzen auf 

gekapselte Objekte eines Pakets P nur in Instanzvariablen, 

Parametern und lokalen Variablen von Objekten von P 

gehalten werden können. 



outside 

ungekapselt 


ungekapselt 

inside 

gekapselt


Zusammenhang zu Typsystemen 

• Jede Variable bekommt als erweiterte Typinformation: 

◦ das Paket, zu dem sie gehört (implizit) 

• Jedes Objekt bekommt als erweiterte Typinformation: 

◦ das Paket, zu dem es gehört (implizit) 

◦ die Information, ob gekapselt oder nicht 

• Kapselungsverletzung (Typfehler) passiert, wenn eine 

Variable von Paket P ein gekapseltes Objekt eines anderen 

Pakets Q referenziert. 

• Es gibt statisch prüfbare Regeln, die Kapselungsverletzungen 

zur Laufzeit ausschließen. 



Im Folgenden betrachten wir eine Erweiterung von Java um 

gekapselte Typen im obigen Sinne. 

Literatur: 

B. Bokowski, J. Vitek: 

Confined Types. 

OOPSLA, 1999. 

Bemerkung: 

Das Studium der Kapselungsregelungen ist auch für die 

Entwicklung von OO-Programmen im Allg. hilfreich. 



Szenarien für Export von Referenzen 

package inside; 

public class C extends outside.B { 

void putReferences() { 

C c = new C(); 

/*r1*/ outside.B.c1 = c; 

/*r2*/ outside.B.storeReference(c); 

/*r3*/ outside.B.c3s = new C[] {c}; 

/*r4*/ calledByConfined(); 

/*r5*/ implementedInSubclass(); 

/*r6*/ throw new E(); 

} 

void implementedInSubclass() { } 

/*r7*/ static C f = new C(); 

/*r8*/ static C m() { 

return new C(); 

} 

/*r9*/ static C[] fs = new C[]{new C()}; 

/*r10*/ public C() { } } 

public class E extends RuntimeException { } 



Szenarien für Import von Referenzen 

package outside; 

public class B { 

/*r1*/ static inside.C c1; 

/*r2*/ static void storeReference(inside.C c2) { // store c2 } 

/*r3*/ static inside.C[] c3s; 

/*r4*/ void calledByConfined() { // store this } 

static void getReferences() { 

/*r7*/ inside.C c7 = inside.C.; 

/*r8*/ inside.C c8 = inside.C.m(); 

/*r9*/ inside.C[] c9s = inside.C.fs; 

/*r10*/ inside.C c10 = new inside.C(); 

D d = new D(); 

try { d.putReferences(); 

/*r6*/ } catch (inside.E ex) { // store ex } 

} 

} 

class D extends inside.C { 

/*r5*/ void implementedInSubclass() { // store this } 

} 



Statische Kapselungsregeln 

Folgende Regeln garantieren die Kapselungsinvariante (dabei 

müssen Felder mit gekapseltem Elementtyp wie gekapselte 

Typen behandelt werden): 

C1: Gekapselte Typen dürfen weder public noch protected 

sein und nicht zum unbenannten globalen Paket gehören. 

C2: Subtypen von gekapselten Typen müssen auch gekapselt 

sein und zum gleichen Paket wie ihr Supertyp gehören. 

C3: Typerweiterung von gekapselten zu ungekapselten Typen 

ist unzulässig in Zuweisungen, Methodenaufrufen, 

Rückgabeanweisungen und Casts. 



Die folgenden beiden Regeln benutzen den Begriff ,,anonyme 

Methode“ bzw. ,,anonyme Konstruktoren“, den wir weiter 

unten erläutern: 

C4: Methoden, die auf gekapselten Objekten aufgerufen 

werden, müssen entweder in gekapselten Klassen deklariert 

oder anonyme Methoden sein. 

C5: Konstruktoren, die von Konstruktoren gekapselten 

Klassen aufgerufen werden, müssen entweder in gekapselten 

Klassen deklariert oder anonyme Methoden sein. 



C6: Subtypen von java.lang.Throwable und java.lang.Thread 

dürfen nicht als gekapselt deklariert werden. 

C7: Der Typ von öffentlichen und geschützten Attributen 

darf nicht gekapselt sein. 

C8: Der Ergebnistyp von öffentlichen und geschützten 

Methoden darf nicht gekapselt sein. 



Definition(Anonyme Menge von Methoden): 

Eine Menge von Methoden kann als anonym deklariert 

werden, wenn sie die folgenden Bedingungen erfüllt: 

A1: Der implizite Parameter this wird nur benutzt, um auf 

Instanzvariablen zuzugreifen oder anonyme Methoden auf 

dem aktuellen Objekt aufzurufen. 

A2: Anonyme Methoden dürfen nur durch anonyme 

Methoden überschrieben werden. 



A3: Native Methoden dürfen nicht anonym sein. 

Eine Menge von Konstruktoren kann als anonym deklariert 

werden, wenn jeder Konstruktor der Menge nur anonyme 

Konstruktoren aufruft. 

Bemerkung: 

• Das Verhalten anonymer Methoden wird nur von den 

aktuellen Parametern und den Werten der Instanzvariablen 

bestimmt. 

• Anonyme Methoden führen nicht zu neuen Aliasen für 

ihren impliziten Parameter. 



3.3.2 Andere Strukturierungsansätze 



In der Literatur werden weitere Strukturierungsansätze 

diskutiert. Wir betrachten hier: 

• Ballontypen: 

◦ P. S. Almeida: Balloon Types: Controlling Sharing of State in Data 

Types. ECOOP ’97. 

• Besitzrelation: 

◦ D. G. Clarke, J. M. Potter, J. Noble: Ownership Types for Flexible 

Alias Protection. OOPSLA ’98. 

◦ Simple Ownership Types for Object Containment. ECOOP ’01. 

◦ P. Müller, A. Poetzsch-Heffter: A Type System for Controlling Representation 

Exposure in Java. Formal Techniques for Java Programs ’00. 



Verwandte Themen sind: 

• Vermeidung von Aliasing 

• Realisierung von Schreibschutz 



Ballontypen 

Ein Typ kann als Ballontyp markiert werden. 

Objekte von Ballontypen heißen Ballonobjekte. 





Definition(Cluster): 

Sei G der Graph mit Objekten als Knoten und mit den 

Referenzen zwischen Nicht-Ballonobjekten und von 

Ballonobjekten zu Nicht-Ballonobjekten als Kanten. Ein 

Cluster ist ein maximaler zusammenhängender Untergraph 

von G. 



Definition(Interne Objekte): 

Ein Objekt O ist intern zu einem Ballonobjekt B genau 

dann, wenn gilt: 

• O ist ein Nicht-Ballonobjekt im gleichen Cluster wie B, oder 

• O ist ein Ballonobjekt, das von B oder einem Objekt im 

gleichen Cluster wie B referenziert wird, oder 

• es gibt ein zu B internes Ballonobjekt B’, zu dem O intern 

ist. 



Definition(Externe Objekte): 

Ein Objekt O ist extern zu einem Ballonobjekt B genau 

dann, wenn es ungleich B ist und nicht intern zu B ist. 



Balloninvariante: 

Für alle Ballonobjekte B gilt: 

• B wird von höchstens einer Instanzvariable referenziert. 

• Wenn es eine solche gespeicherte Referenz auf B gibt, 

kommt sie von einem zu B externen Objekt. 

• Kein internes Objekt zu B wird von einem Objekt 

referenziert, das extern zu B ist. 



Bemerkung: 

• Die Invariante erlaubt es, dass lokale Variablen Objekte 

innerhalb eines Ballons referenzieren. 

Deshalb kann man einen Ballon auch nicht als die Menge 

der von einem Ballon erreichbaren Objekte definieren. 

• Um die Balloninvariante zu garantieren, benutzt Almeida 

folgende Techniken: 

◦ Zuweisung von Referenzen auf Ballonobjekte an Instanzvariablen ist 

im Allg. nicht erlaubt. 

◦ Datenflussanalyse 



Idee: 

Besitzrelation 

• Führe eine Besitzrelation zwischen Objekten ein: 

Objekt X gehört Objekt Y. 

• Benutze die Besitzrelation, um Kapselung zu realisieren: 

Nur der Besitzer darf auf die Objekte zugreifen, die ihm 

gehören. 

• Deklariere die Besitzrelation mittels erweiterter 

Typinformation. 



Beispiel(Besitzrelation): 

class Engine { 

void start() { ... } 

void stop() { ... } 

} 

class Driver { ... } 

class Car { 

rep Engine engine; //Teil der Representation 

Driver driver; // kein Teil d.Representation 

Car() { 

engine = new rep Engine(); 

driver = null; 

} 

rep Engine getEngine() { return engine; } 

void setEngine( rep Engine e){ engine=e; } 

void go () { 

if(driver!=null) engine.start(); 

} 

} 



class Main { 

void main() { 

Driver bob = new Driver(); 

// kein Besitzer 

Car car = new Car(); // kein Besitzer 

car.driver = bob; 

car.go(); 

car.engine.stop(); // unzulaessig 

car.getEngine().stop(); // unzulaessig 

rep Engine e = new rep Engine(); 

car.setEngine(e); // unzulaessig 

} 

} 



Die Besitzrelation ist eine binäre Relation zwischen 

Objekten. Bei der Erzeugung eines Objektes X wird 

festgelegt, wer Besitzer von X ist. 

Bei der einfachsten Variante gilt: Ein Objekt X ist 

• entweder global (hat also keinen Besitzer) oder 

• hat genau einen Besitzer. 

Besitzerinvariante: 

Alle Referenzpfade von einem globalen Objekt zu einem 

Objekt mit Besitzer B führen durch B. 



Bemerkung: 

• Die Besitzerinvariante ist tendenziell allgemeiner als die 

Balloninvariante. Sie erlaubt Referenzen, die den Besitzbereich 

verlassen. Andererseits sind bei ihr temporäre 

Referenzen von außen in den Besitzbereich unzulässig. 

• In der beschriebenen Form bringt die Besitzrelation 

deutliche Restriktionen mit sich. 

• Es gibt unterschiedliche Umsetzungen und Verfeinerungen 

der Besitzrelation. 


3.4 Erweiterte statische Prüfung 311 

3.4 Erweiterte statische Prüfung 



Abschnitte 3.2 und 3.3 haben Erweiterungen von 

Typsystemen untersucht, die die Spezifikation und Prüfung 

von Eigenschaften erlauben, die sich mit klassischen 

Typsystem nicht ausdrücken lassen. 

Hier betrachten wir die Prüfung von Eigenschaften, die 

keiner gesonderten Spezifikation bedürfen, aber von der 

klassischen Typprüfung nicht erfasst werden. 



Beispiel(Eigenschaften für ESP): 

Prüfe zur Übersetzungszeit, dass folgende Fehler nicht 

auftreten: 

• Dereferenzierung der Null-Referenz. 

• Feldzugriff mit unzulässigem Index. 

Während klassische und erweiterte Typsysteme meistens 

entscheidbar sind, zielt die erweiterte statische Prüfung auf 

Eigenschaften, die 

• in vielen Fällen entscheidbar, 

• aber im Allg. unentscheidbar sind. 



3.4.1 Allgemeine Aspekte der ESP 



ESP ist eine junge Technik. Grundansatz: 

1. Bestimme die Eigenschaften, die analysiert werden sollen. 

2. Annotiere Programme soweit, dass die Prüfung 

automatisch durchgeführt werden kann: 

◦ Schnittstelleninformation 

◦ Beweisunterstützung 

3. Falls die Prüfung nicht gelingt, erweitere bzw. korrigiere 

die Annotationen oder korrigiere das Programm und setze 

mit 2. fort. 



Beispiel(Programm mit Annotationen): 

1. In folgendem Programm kann es zu 

NullPointer-Ausnahmen kommen: 

class Scumble { 

int a; 

int m( Scumble s ){ 

return s.a; 

} 

} 

Die Methode m braucht s!= null als Vorbedingung. 



2. In folgendem Programm kann das Prüfwerkzeug 

möglicherweise nicht ableiten, dass i nach der Schleife 

gleich 8 ist: 

class MyClass { 

int[] a; 

MyClass() { 

int i = 1; 

while( i


3.4.2 Das Werkzeug ESC/Java 



In den letzten Jahren sind mehrere Werkzeuge für das 

erweiterte statische Prüfen entwickelt worden. Wir 

betrachten hier den Extended Static Checker for Java 

(ESC/Java). 

ESC/Java prüft (annotierte) Java-Programme auf 

• Abwesenheit von Laufzeitfehlern/Ausnahmen, 

• Konsistenz von Annotationen und Programm. 



Beispiel(Konsistenz): 

class Consistency { 

static int x; 

//@ ensures x == 7 ; 

static void initX() { x = 10; } 

} 

Prüfung liefert folgendes Ergebnis: 

Consistency: initX() ... 

------------------------------------------- 

Consistency.java:5: Warning: Postcondition 

possibly not established (Post) 

static void initX() { x = 10; } 

Associated declaration is "Consistency.java", 

line 4, col 6: 

//@ ensures x == 7 ; 

^ 



Technische Aspekte von ESC/Java 

ESC/Java basiert auf: 

• Spezifikationssprache JML 

• precondition transformation 

• automatischen Theorembeweisen 

ESC/Java ist 

• logisch nicht korrekt, d.h. es liefert möglicherweise 

unberechtigte Warnungen; 

• logisch nicht vollständig, d.h. es gibt Eigenschaften, die 

gelten, aber nicht gezeigt werden können. 



Die Inkorrektheit vereinfacht das Schließen, in dem nicht alle 

Möglichkeiten in Betracht gezogen werden. 

Der verwendete automatische Theorembeweiser unterstützt 

die Konstruktion von Gegenbeispielen. 

Vorführung: (ESC/Java) 

Siehe Vorlesung. 


4. Spezifikation 

objektorientierter Programme


4.1 Spezifikation von Typen 

4.2 Konformität von Subtypen 

4.3 Module und Modularität 


324

Zentrale Aspekte der Objektorientierung: 

• Information Hiding & Kapselung: 

◦ Wie verhält sich ein Objekt intern? 

◦ Wie wirkt ein Objekt auf die Umgebung? 

• Subtypbeziehung: 

◦ Wann kann ich ein Objekt anstelle eines anderen verwenden? 

• Zusammenfassend: 

◦ Was ist die Bedeutung/Semantik eines Objekts? 


325

Beispiele: 

1. Beschreibung von Verhalten bei privaten Attributen: 

public class WieWerdeIchBeschrieben { 

private int a = 0; 

public void set( int p ) { a = p; } 

public int get() { return a; } 

} 

Private Klassenkomponenten sollten nicht in einer 

öffentlichen Schnittstelle erscheinen. 


326

2. Nachrichten nach außen können die Umgebung ändern: 

public class Umweltverschmutzung { 

public void nurlokal( Object mo ) { 

do_something_good(); 

if( mo instanceof Atmosphere ) 

((Atmosphere) mo).pollute(); 

} 

} 

Wie beschreibt man die Auswirkungen auf die Umgebung? 

Insbesondere auch die Invarianten der Umgebung. 


327

3. Für konformes Verhalten reicht Typkorrektheit nicht aus: 

public class Superklasse 

{ public int a = 0; 

public void dincrA() { a++; } 

} 

public class Subklasse extends Superklasse 

{ public void dincrA() { a--; } 

} 

Macht es Sinn, ein Subklasse-Objekt anstelle eines 

Superklasse-Objekts zu verwenden? 


328

Lernziele: 

• Spezifikationstechniken 

• Beschreibung von Programmbausteinen 


329

4.1 Spezifikation von Typen 330 

4.1 Spezifikation von Typen 



Ziel: 

Spezifikation der Eigenschaften eines Typs unabhängig von 

seiner/seinen Implementierungen. 

Problematik: 

• Vokabular/Framework zur Formulierung der Eigenschaften 

• Information Hiding: private und geschützte 

Implementierungsteile können nicht in öffentlicher 

Spezifikation benutzt werden. 

• Zusammenspiel zwischen deklarativer Spezifikation und 

objektorientierter Implementierung 



Ansätze: 

• Spezifikation mit programmiersprachlichen Mitteln 

• Spezifikation mit erweiterten programmiersprachlichen 

Mitteln unter Einhaltung der Ausführbarkeit 

• Spezifikation mit abstrakteren Sprachmitteln 



Vorgehen: 

• Leichte Spezifikationen 

• Spezifikation einzelner Objekte 

◦ Invarianten 

◦ Verhalten von Methoden 

◦ Umgebungseigenschaften 

• Spezifikation mit abstrakten Variablen 

◦ abstrakte Variablen 

◦ Abstraktionsfunktionen 

◦ abstrakte Spezifikation von Umgebungseigenschaften 

• Spezifikation zusammenhängender Objekte 



Dabei betrachten wir als Sprachmittel ausführbare 

Spezifikationen in JML , der Java Modelling Language. 




4.1.1 Leichte Spezifikationen


Definition(leichte Spezifikation): 

Eine leichte Spezifikation beschreibt wichtige Eigenschaften 

von Objekten und Methoden, die ohne großen Aufwand 

beschrieben werden können. 

Leichte Spezifikationen streben nicht die vollständige 

Beschreibung relevanten Verhaltens an. 



Beispiel(leichte Spezifikation): 

public class Bag { 

//@ requires input != null; 

public Bag(int[] input) { 

n = input.length; 

a = new int[n]; 

System.arraycopy(input, 0, a, 0, n); 

} ... 

} 

Leichte Spezifikationen sind insbesondere ein präzises 

Dokumentationsmittel. 



Bemerkung: 

Leichte Spezifikationen können auch zur Annotation privater 

Programmelemente verwendet werden, um die Lesbarkeit 

oder Prüfbarkeit von Programmen zu verbessern. 



Beispiel(leichte Spezifikation): 

public final 

class String implements ... { 

/** Used for character storage. */ 

//@ private invariant value != null ; 

private char value[]; 

/** First index of the storage used. */ 

//@ private invariant offset >= 0 

private int offset; 

/** Number of characters in the String */ 

//@ private invariant count >= 0 ; 

private int count; 

/*@ private invariant 

@ offset + count


4.1.2 Spezifikation einzelner Objekte 



Vereinfachende Annahmen: 

• Spezifikationen hängen nur von dem Zustand jeweils eines 

Objekts ab. 

• Relevante Attribute sind dem Anwender bekannt. 

• Methoden ändern nur das Objekt, auf dem sie aufgerufen 

wurden. 

• Kein Subtyping, keine Vererbung. 



Spezifiziere: 

• die möglichen Zustände der Objekte durch Invarianten 

über den Attributwerten; 

• das Verhalten von Methoden durch die von ihnen 

vorgenommenen Änderungen der Attributwerte; 

• Umgebungseigenschaften durch Angabe, welche 

Attributwerte von Methoden nicht verändert werden. 

Beispiel: 

public class Point { 

/** Koordinaten */ 

/*@ spec_public @*/ private float x, y; 

private float dist; 

} 



Invarianten 

Invarianten spezifizieren die Bereichseinschränkungen für die 

Attributwerte und die Beziehungen zwischen Attributwerten. 

Beispiel(Invarianten): 


... 

//@ public invariant x >= 0.0 && y >= 0.0 ; 

} 

/*@ private invariant 

@ dist == Math.sqrt(x*x+y*y) ; 

@*/ 

... 



Verhalten von Konstruktoren und Methoden 

Konstruktoren müssen die Invarianten etablieren. 

Methoden müssen die Invarianten erhalten. 

Die Vorbedingung für ihre Anwendung und ihr Einfluss auf 

die Attributwerte ihres Zielobjektes und ihr Ergebnis werden 

mit Vor- und Nachbedingungen spezifiziert. 



Beispiel(Verhalten von Konstruktoren und Methoden): 


... 

/** Erzeugen eines Punktes */ 


@ requires x >= 0.0 && y >= 0.0 ; 

@ ensures this.x == x && this.y == y; 

@ also 

@ public exceptional_behavior 

@ requires x < 0.0 || y < 0.0 ; 

@ signals (IllegalArgumentException) 

@*/ 

public Point ( float x, float y ) { ... } 


@ ensures \result == this.x ; 

@*/ 

public float getX() { ... } 

... 


} 


/** Entfernung vom Ursprung */ 


@ ensures \result == Math.sqrt(x*x+y*y); 

@*/ 

public float distance() { ... } 

/** Verschieben dieses Punktes */ 


@ requires x+dx >= 0.0 && y+dy >= 0.0 ; 

@ ensures x == \old(x)+dx && y == \old(y)+dy ; 

@ also 


@ requires x+dx < 0.0 || y+dy < 0.0 ; 


@*/ 

public void move( float dx, float dy ){ ...} 



Bemerkung: 

• Vor- und Nachbedingungsspezifikationen liefern keine 

vollständige Aussage darüber, was sich verändert (z.B. 

bzgl. Attribut dist bei Ausführung von move). 

• Sie liefern keine Aussage darüber, was sich nicht verändert. 

• Obiges Beispiel ist keine zulässige JML-Spezifikation (s.u.). 



Spezifikation von Umgebungseigenschaften 

Veränderungsspezifikationen beschreiben, welche Variablen 

ihren Wert bei Ausführung einer Methode nicht verändern, 

indem sie die Variablen spezifizieren, die sich ändern dürfen. 

Grund für indirektes Vorgehen: 

• Es gibt weniger Variablen, die sich ändern. 

• Im Allg. sind nicht alle Variablen des Programms bekannt. 

Damit ist insbesondere spezifiziert, welche Eigenschaften der 

Umgebung (engl. frame properties) erhalten bleiben. 



Spezifikationsmittel: 

Veränderungsklausel (modifies, assignable clause): 

assignable 〈Liste bedingter Variablenausdrücke〉 

Bespiele: 

assignable x, this.a, p.a.b 

assignable x, this.a if(this==p) 

Bemerkung: 

Schlüsselwort modifies ist gleichbedeutend mit 

assignable. 



Bedeutung: 

Eine Methode bzw. ein Konstruktor darf nur an Instanzoder 

Klassenvariable zuweisen, die 

• in der Veränderungsklausel genannt ist und deren 

zugehörige Bedingung im Vorzustand erfüllt ist oder 

• die erst während der Methodenausführung allokiert werden. 

Fehlt eine Veränderungsklausel, hat es die gleiche Bedeutung 

wie eine Veränderungsklausel mit leerer Liste. 



Beispiel(Spezifikationsmittel): 


... 


@ requires x >= 0.0 && y >= 0.0 ; 

@ assignable this.x, this.y ; 


@ also 

@ private normal_behavior 

@ requires x >= 0.0 && y >= 0.0 ; 

@ assignable dist ; 

@ also 


@ requires x < 0.0 || y < 0.0 ; 


@*/ 

public Point ( float x, float y ) { ...} 

... 


} 




@*/ 


... 


@ requires x+dx >= 0.0 && y+dy >= 0.0; 

@ assignable x, y ; 


@ private normal_behavior 


@ assignable dist ; 

@ also 




@*/ 




Bemerkung: 

Private Veränderungsklauseln sind unwichtig für die 

Dokumentation der öffentlichen Schnittstelle, aber nötig für 

das Prüfwerkzeug. 



4.1.3 Spezifikation mit abstrakten Variablen 



Abstrakte Variablen/Attribute werden zur Spezifikation 

benötigt, wenn 

• konkrete Attribute nicht deklariert sind oder 

• die Zugreifbarkeitsregeln die Verwendung konkreter 

Attribute in Spezifikationen nicht gestatten oder 

• Austauschbarkeit der Implementierung erreicht werden soll. 

Syntax: Abstrakte Variablen/Attribute werden in JML wie 

Attribute, allerdings mit dem zusätzlichen Schlüsselwort 

model als Modifikator vereinbart. In JML haben abstrakte 

Attribute einen Java-Typ. 



Bedeutung: 

Abstrakte Attribute hängen von konkreten Attributen oder 

anderen abstrakten Attributen ab. 

Die Abhängigkeit muss in einer Abhängigkeitsklausel 

spezifiziert werden. 

Der Wert von einem abstrakten Attribut a eines Objekts 

ergibt sich aus den Werten der Attribute, von denen a 

abhängt. Wie er sich berechnet, wird in einer Repräsentationsklausel 

festgelegt. 



Beispiel(Abstrakte Attribute): 


/** Koordinaten */ 

//@ public model float x, y; 

//@ public invariant x >= 0.0 && y >= 0.0; 

private double dist, angle ; 

/*@ private invariant dist >= 0.0 

@ && 0.0


Abstrakte Variablen und 

Umgebungseigenschaften 

Das Recht, eine abstrakte Variable a verändern zu dürfen, 

impliziert das Recht, alle konkreten Variablen zu ändern, von 

denen a abhängt. 

Beispiel(Abstrakte Variablen und Umgebungseigenschaften 

Der Konstruktor Point darf dist und angle verändern: 





@ requires x >= 0.0 && y >= 0.0 ; 

@ assignable this.x, this.y ; 


@ also 


@ requires x < 0.0 || y < 0.0 ; 


@*/ 

public Point ( float x, float y ) { ...} 



@*/ 


} 





@ assignable x, y ; 


@ also 




@*/ 




Bemerkung: 

• Die Spezifikation der Veränderung von dist ist nicht mehr 

nötig, da x und y von dist abhängen. 

• Die Gleichheit in den Zusicherungsklauseln ist 

problematisch. 

Mit dem folgendem Beispiel demonstrieren wir die Spezifikation 

eines Typs, für den keine Attribute deklariert sind. 

Die Spezifikation benutzt einen komplexeren, in JML 

vordefinierten seiteneffektfreien Typ JMLObjectSequence: 



Beispiel(abstrakte Variablen): 

//@ model import org.jmlspecs.models.*; 

public abstract class UnboundedStack { 

/*@ public model JMLObjectSequence theStack 

@ initially theStack != null && theStack.isEmpty(); 

@*/ 

//@ public invariant theStack != null; 



@ assignable theStack; 

@ ensures theStack.equals( \old(theStack.trailer())); 

@*/ 

public abstract void pop( ); 


} 



@ assignable theStack; 

@ ensures theStack.equals( \old(theStack.insertFront(x))); 

@*/ 

public abstract void push(Object x); 



@ ensures \result == theStack.first(); 

@*/ 

public abstract Object top( ); 



package org.jmlspecs.models; 

public /*@ pure @*/ class JMLObjectSequence 

implements JMLCollection 

{ 

public /*@ pure @*/ 

boolean equals(Object obj) { ... } 


boolean isEmpty() { ... } 


Object first() 

throws JMLSequenceException { ... } 


/*@ non_null @*/ JMLObjectSequence 

insertFront(Object item) 

throws IllegalStateException { ... } 

... 

} 



Methoden sind pure, wenn sie keine Seiteneffekte haben 

(assignable \nothing). 

Konstruktoren sind pure, wenn sie nur Objektattribute 

verändern und ansonsten keine Seiteneffekte haben. 

Klassen- und Schnittstellentypen, die als pure deklariert sind, 

dürfen nur pure Methoden und Konstruktoren haben. 



4.1.4 Spezifikation zusammenhängender Objekte 



Objekte erbringen ihre Funktionalität meist im Zusammenwirken 

mit anderen Objekten. Wir betrachten hier die Fälle: 

• Aggregation 

• Komposition 

• Rekursive Objektbeziehungen 

Aggregation: 

Aggregation modelliert eine hat-ein-Beziehung zwischen 

einem Objekt X und Teilen von X. Teilobjekte sind 

üblicherweise außerhalb von X bekannt und zugreifbar; 

sie können auch Teil anderer Objekte sein. 



Bemerkung: 

Die Zugreifbarkeit von außen ist problematisch, da 

Invarianten des aggregierenden Objekts verletzt werden 

können. 

Beispiel(Aggregation): 

public class Line { 

public /*@ non_null @*/ Point left,right; 

//@ public invariant left != right ; 

//@ public invariant left.x

} 



@ requires p1 != null && p2 != null && 

@ p1 != p2; 

@ assignable left, right; 

@ ensures ((left == p1 && right == p2) 

@ || (left == p2 && right == p1)) 

@ && linebreadth == 1 && ... ; 

@*/ 

public Line( Point p1, Point p2 ) { ...} 

... 


@ ensures \result == left ; 

@*/ 

public Point getLeft() { ... } 


@ ensures \result == ... ; 

@*/ 

public float length() { ... } 



Beachte: 

• Ein Punkt kann zu mehreren Linien gehören. 

• Die zweite Invariante kann durch Verschieben eines der 

Endpunkte verletzt werden. Deshalb besser: 



public class Line { 

public /*@ non_null @*/ Point from,to; 

//@ public invariant from != to ; 

public /*@ non_null @*/ Color linecolor; 

public int linebreadth ; 


@ requires p1! = null && p2 != null && 

@ p1 != p2 

@ assignable from, to; 

@ ensures form == p1 && to == p2 

@ && linebreadth == 1 && ... 

@ ... 

@*/ 

public Line( Point p1, Point p2 ) { ...} 

... 


@ ensures \result == 

@ from.x


Komposition: 

Komposition modelliert eine exklusive Besitzerbeziehung 

zwischen einem Objekt X und seinen Teilen. 

Teilobjekte sind üblicherweise außerhalb von X bekannt und 

eingeschränkt zugreifbar; sie dürfen nicht direkter Teil 

mehrerer Objekte sein. 



Beispiel(Komposition): 

Wir betrachten eine Klasse für Streckenzüge, die aus Linien 

zusammengesetzt sind. 

Die Streckenzüge lassen sich von außen durch Verschieben 

der Punkte verändern. 

Line 

from: 

to: 


Polyline 

Line 

from: 

to: 

Point Point Point


Um zu verhindern, dass ein Line-Objekt Teil zweier 

Polylinien wird, kann man: 

• die Linien kapseln; 

• den Einbau von Linien kontrollieren. 



Rekursive Objektbeziehungen: 

Die Eigenschaften und Invarianten rekursiver Klassen 

erstrecken sich oft über eine unbegrenzte Anzahl von 

Objekten. 

Für ihre Spezifikation benötigt man meist Hilfsfunktionen. 

Beispiel(rekursive Klasse): 

public class IntList { 

private int elem; 

private IntList next; 

//@ private invariant !this.reach(next) ; 

/*@ pure @*/ boolean reach( IntList il ){ 

// aber wie beschreibe ich reach 

} 

} 



Bemerkung: 

Obiges Beispiel zeigt: 

• Schranken der Ausdruckskraft der demonstrierten 

Spezifikationstechnik; 

• Problematik der Verwendung partieller Prädikate. 

• Eine allgemeine Spezifikationsmethode für rekursive 

Klassen fehlt noch. 


4.2 Konformität von Subtypen 377 

4.2 Konformität von Subtypen 



Die Subtypbeziehung wird in Programmiersprachen meist 

rein syntaktisch verstanden: 

Was muss ein Subtypobjekt für Eigenschaften haben, damit 

an Stellen, an denen Supertypobjekte erwartet werden, 

• keine Typfehlern auftreten und 

• zu Methodenaufrufen immer geeignete Methodenimplementierungen 

existieren. 

Was bedeutet es semantisch, ein Subtyp zu sein? 



Probleme: 

Der Subtyp soll eine Spezialisierung des Supertyps sein. Auf 

Basis der operationellen Semantik lässt sich Spezialisierung 

nur schwer definieren: 

• Spezialisierung von abstrakten Typen 

• Erweiterung des Zustandsraums 



Ansatz: 

Definiere die Subtypbeziehungen auf Basis der 

Spezifikationen: 

• Jedes Subtypobjekt muss die Spezifikationen der 

Supertypen erfüllen. 

• Für Vor- und Nachbedingungsspezifikationen: 

◦ pre[Supertyp] => pre[Subtyp] 

◦ post[Subtyp] => post[Supertyp] 



Vorgehen: 

• Vor- und Nachbedingungsspezifikation ohne abstrakte 

Variablen und Abstraktion 

• Vor- und Nachbedingungsspezifikation mit abstrakten 

Variablen und Abstraktion 

• Behandlung von Invarianten 

• Umgebungseigenschaften 

• Zusammenwirken der Techniken 



Konkrete Pre-Post-Spezifikationen 

Jede Vor- bzw. Nachbedingung einer Methode im Supertyp 

kann als Vor- bzw. Nachbedingung der entsprechenden 

Methode des Subtyps interpretiert werden: 

• Vererben der Spezifikation 



Subtypen ohne zusätzliche Attribute: 

• Ererbte Methode: 

◦ Spezifikation wird geerbt und nicht erweitert. 

• 

Überschreibende Methode: 

◦ Vorbedingung wird geerbt und nicht erweitert. 

◦ Nachbedingung wird geerbt und ggf. um Konjunkte erweitert, d.h. 

verstärkt. 



Beispiel(Konkrete Pre-Post-Spezifikationen): 

class C { 


@ requires P 

@ ensures Q ; 

@*/ 

C m(){ ... } 

} 

class D extends C { 

/*@ also 

@ public normal_behavior 

@ requires P 

@ ensures \result instanceof D ; 

@*/ 

C m(){ ... } 

} 



Zusätzliche Methode: 

• keine Einschränkungen an Verhalten. 

Bemerkung: 

Entsprechende Spezifikationsverfeinerungen, wie hier fürs 

normale Verhalten gelten fürs Ausnahmeverhalten. 

Subtypen mit zusätzlichen Attributen: 

Ist der Zustandsraum im Subtyp erweitert, kann neben den 

oben erläuterten Spezifikationsverfeinerungen eine 

Ergänzung der Vorbedingung bei überschreibenden 

Methoden sinnvoll sein. 



Es reicht zu verlangen, dass: 

• pre[Supertyp] && this instanceof Subtyp ⇒pre[Subtyp] 

• post[Subtyp] && this instanceof Subtyp ⇒ post[Supertyp] 

Bemerkung: 

• Diese Abschwächung setzt normalerweise voraus, dass ein 

Supertyp seine Subtypen kennt. 

• Die Problematik des erweiterten Zustandsraums ist ein 

wichtiges Argument für die Verwendung von Abstraktion. 



Abstrakte Pre-Post-Spezifikationen 

Die Repräsentation der abstrakten Attribute durch die 

konkreten kann von Subtyp zu Subtyp verschieden sein. 

Die abstrakt formulierten Bedingungen werden dementsprechend 

unterschiedlich konkretisiert. 



Beispiel(Abstrakte Pre-Post-Spezifikationen): 

class C { 

//@ public model boolean valid; 

//@ public model AS state; 


@ requires valid && r(state) 

@ ensures q(state) ; 

@*/ 

void m(){ ... } 

} 


private BD d; 

//@ private depends valid


class E extends C { 

private BE e; 

//@ private depends valid


Bemerkung: 

• Häufig geht man auch von einer expliziten 

Abstraktionsfunktion aus, die den Zustandsraum des 

Subtyps in den des Supertyps abstrahiert. 

• Die abstrakten Variablen ermöglichen zwei Arten der 

,,Zustandserweiterung“: 

◦ Überschreiben der Repräsentationsfunktion 

◦ zusätzliche abstrakte Variablen 

• Die Variationen in den Subtypen können von der 

Repräsentationsfunktion aufgefangen werden. 



Behandlung von Invarianten 

Im Prinzip lassen sich Invarianten durch Vor- und 

Nachbedingungen ausdrücken. 

Spezifikationstechnisch sind sie aber wichtig, da sie es 

ermöglichen, in Supertypen das Verhalten zusätzlicher 

Subtypmethoden einzuschränken: 

• Invarianten von Supertypen müssen auch von zusätzlichen 

Subtypmethoden erfüllt werden. 



Beispiel(Behandlung von Invarianten): 

class C { 

public int a = 0; 

//@ public invariant a >= 0; 

... 

// keine Deklaration von m 

} 


... 

void m(){ a = -1; } // verletzt Invariante 

... 

} 



Ansatz: 

• Invarianten des Supertyps müssen auch von den Subtypen 

erfüllt werden: 

inv[Subtyp]⇒ inv[Supertyp] 

• Vorgehen: 

Vererbe Invarianten an Subtypen und bilde die Konjunktion 

mit den in den Subtypen angegebenen Invarianten. 



Problematik: 

Die Invarianten gelten normalerweise nicht in jedem 

Zustand. Was ist ihre präzise Bedeutung? Was muss im 

Vorzustand eines Methodenaufrufs gelten? 

Für die Bedeutung von Invarianten in Spezifikationssprachen 

gibt es bisher keine einheitliche Lösung. 



Semantische Varianten: 

1. Invariante über eingeschränkte Zustandsmenge: 

JML: ,,Invariants have to hold in each state outside of a 

public method’s execution and at the beginning and end of 

such execution.“ 

2. Transformation in Vor- und Nachbedingungen: 

Verifikationsansätze: Invarianten müssen im Nachzustand 

von Konstruktoraufrufen gelten. Wenn sie im Vorzustand 

von Methoden gelten, müssen sie auch im Nachzustand 

gelten. 



Für die Verifikation bringen beide Varianten ein Problem mit 

sich: 

Sei S ein Subtyp von T, m eine Methode in T und x eine 

Variable vom Typ T: 

... x.m(...) ... 

In der Verifikation wird man inv[T] als Vorbedingung 

voraussetzen. Als Vorbedingung der Methoden von S 

benötigt man aber im Allg. inv[S]. 

Ziel ist aber die Verifikation ohne Kenntnis aller Subtypen. 



Beispiel(Behandlung von Invarianten): 

class C { 


//@ public invariant a => 0; 

... 

void m(){ 

... // erhaelt die Invariante 

} 

} 

class Foo { 

void mfoo() { 

... x.m() ... 

} 

} 




public int b = 0; 

//@ public invariant a > 1; 

//@ public invariant b => 0; 

... 

void m(){ 

b = 4 / a ; 

... // erhaelt beide Invarianten 

} 

} 

Problem: 

Lege die Vorbedingung für den Aufruf von x.m() fest. 




Betrachte als Invariante eines Typs T die folgende Formel 

INV[T]: 

∀ Typen S: S ≤ T ⇒ ( typ(this)=S ⇒ inv[S] ) 

wobei inv[S] bei gegebenem S die Invariante der 

Implementierung von S bezeichnet. Dann gilt für einen 

Subtyp U von T: 

typ(this) = U ⇒ ( inv[U] ⇔ INV[T] ) 



Bemerkung: 

Darüber hinaus muss man im Allg. auch zeigen, dass eine 

Methode von T die Invarianten aller anderen Typen 

unverändert lässt. 



Umgebungseigenschaften 

Die Spezifikation von Umgebungseigenschaften ist mit zwei 

Problemen konfrontiert: 

• Information Hiding: nicht alle veränderbaren Variablen 

können in der Spezifikation genannt werden. 

• Zustandserweiterung: Die Supertypspezifikation sollte 

unabhängig von den Implementierungen der Subtypen sein. 



Beispiel(Umgebungseigenschaften): 

class C { 


private int b = 0; 

public static int c = 123; 

... 


@ assignable a; 

@*/ 

public void m(){ a++; b++; } 

} 

class Foo { 

void mfoo() { 

... x.m() ... 

} 

} 



public int d = 0; 

... 

public void m(){ 

super.m(); 

d = 87; 

C.c = 4 ; 

... 

} 

}


Ansatz: 

• Verwende abstrakte Attribute/Variablen, Abhängigkeitsund 

Repräsentationsklauseln. 

• Information Hiding: Abstrakte Attribute können von nicht 

zugreifbaren Attributen abhängen. 

• Zustandserweiterung: Die Abhängigkeiten abstrakter 

Attribute können in Subtypen erweitert werden. 

(Beispiel dazu im folgenden Unterabschnitt) 



Zusammenwirken der Techniken 

Spezifikationstechniken für objektorientierte Programme 

verfolgen zwei Ziele: 

• Spezifikation von Eigenschaften durch Annotation von 

Programmen. 

• Vollständige Spezifikation von Typen und damit auch 

Grundlage für das Verständnis der Verhaltenskonformität 

bei Subtypen. 



Vorgehen: 

• Zusammenwirken der Techniken mit Schwerpunkt 

abstrakte Spezifikation an einem Beispiel 

• Verhaltenskonformität bei Subtypen 

Beispiel(Zusammenwirken der Techniken): 

Das behandelte Beispiel ist eine Java-Adaption des zentralen 

Beispiels aus: 

K. R. M. Leino, G. Nelson: Data abstraction and 

information hiding, Transactions on Programming Languages 

and Systems 24(5): 491-553 (2002). 



Reader 


BuffReader BlankReader 

BlankReaderImpl


Das Beispiel demonstriert vor allem die Behandlung von 

Zustandserweiterungen in Subtypen. 

public interface Reader { 

//@ public model instance boolean valid; 

//@ public model instance Object state; 


@ requires valid; 

@ assignable state; 

@ ensures -1


public abstract class BuffReader implements Reader { 

protected /*@ spec_public @*/ int lo, cur, hi; 

protected /*@ spec_public @*/ char[] buff; 

//@ public model boolean svalid; 

/*@ public represents valid

} 



@ requires valid; 

@ assignable state; 

@ ensures cur == \old(cur) ; 

@*/ 

public abstract void refill(); 

//@ depends valid


Eine triviale Anwendung von BlankReader und 

BlankReaderImpl (s. nächste Seite): 

public class ReaderTest { 

public static void main( String[] args ) { 

BlankReader br = new BlankReaderImpl(); 

br.init(1000000); 

} 

} 

int count = 0; 

int chr; 

do { 

chr = br.getChar(); 

count++; 

} while( chr != -1 ); 

br.close(); 

System.out.println(count); 



public class BlankReaderImpl 

extends BuffReader 

implements BlankReader 

{ 

private int num; 

//@ private represents svalid

} 


public void refill() { 

lo = cur; 

hi = Math.min( lo+buff.length, num ); 

} 

public void close() {} 

//@ private depends state


Verhaltenskonformität bei Subtypen 

Bisher: 

• Spezifikationstechniken 

• Spezifikationsprobleme 

Weitergehendes Thema: 

• Was bedeutet es genau, dass sich ein Typ semantisch 

konform zu einem anderen verhält? 



Definition(konforme Subtypen): 

Ein Typ S ist ein (verhaltens-) konformer Subtyp von einem 

Typ T, wenn S-Objekte an allen wesentlichen Programmkontexten, 

an denen T-Objekten zulässig sind, die relevanten 

Eigenschaften von T-Objekten haben. 



Problematik: 

• Was sind die wesentlichen Programmkontexte: 

x instanceof S 

• Was sind die relevanten Eigenschaften, wie sind sie 

formuliert: 

Information Hiding, Abstraktion, Effizienz 




• Betrachte nur die Methodenschnittstelle, d.h. keine 

Konstruktoren, keine Information über den 

Implementierungstyp. 

• Gehe vom spezifizierten Verhalten aus, wobei bestimmte 

Ausführungsmodelle und Spezifikationstechniken zugrunde 

gelegt werden. 



Literatur: 

B. H. Liskov, J. M. Wing: A Behavioral Notion of 

Subtyping. Transactions on Programming Languages and 

Systems 16(6): 1811-1841 (1994). 

Bemerkung: 

• Das allgemeine Problem zur präzisen Spezifikation 

konformer Subtypbildung bzgl. Ausführungsmodellen wie 

in Java ist nicht gelöst. 

• Konforme Subtypbildung ist auch und gerade für die 

Komponentenprogrammierung von zentraler Bedeutung. 


4.3 Module und Modularität 418 

4.3 Module und Modularität 



Bisher haben wir Spezifikation auf Objekt- bzw. Klassenebene 

betrachtet. Hier werden zwei Aspekte angesprochen 

die über diese Ebene hinausgehen: 

4.3.1 Eigenschaften auf Modulebene 

4.3.2 modulare Spezifikation (vgl. Folie 178 ) 



4.3.1 Eigenschaften auf Modulebene 



Ein objektorientiertes Modul besteht aus mehreren Klassen. 

Häufig gibt es Eigenschaften, die über Klassengrenzen 

hinausgehen. 

Modulinvarianten beschreiben Eigenschaften von 

Assoziationen, an denen Objekte mehrerer Klassen eines 

Moduls beteiligt sind. 



Beispiel: 

Die Typen Component, Container, Window, etc. des Pakets 

java.awt erfüllen viele Invarianten, z.B.: 

• Ein Window-Objekt gehört zu keinem Container. 

• Ein Component-Objekt c gehört genau zu dem Container 

c.parent und zu keinem anderen Container. 

Bemerkung: 

Sprachkonstrukte und Techniken zur Spezifikation von 

Moduleigenschaften sind nur ansatzweise untersucht. 




4.3.2 Modulare Spezifikation


Die Entwicklung modularer Spezifikations- und 

Verifikationstechniken ist von fundamentaler Bedeutung, da 

solche Techniken die Voraussetzung für Skalierbarkeit sind. 

Die Entwicklung modularer Techniken für die objektorientierte 

Programmierung steht noch am Anfang. 



Modularität von Umgebungseigenschaften: 

Spezifikation durch Angabe der Variablen, die sich ändern 

dürfen. 

Problematik: 

• Sei m eine Methode in Modul P, die die Variable x ändern 

darf. 

• Sei y eine Variable in einem Modul Q, das P benutzt, so 

dass y in P nicht sichtbar ist, aber von x abhängig ist. 

Dann führt eine Änderung von x auch zu einer Änderung 

von y. Diese ist aber in P nicht erkennbar. 



Beispiel(Modularität von Umgebungseigenschaften:): 

Wir benutzen eine Listenklasse, um eine Klasse für Mengen 

zu implementieren, d.h. wir stützen eine Abstraktionsebene 

auf eine andere ab: 

public abstract class List { 

/*@ public model non_null 

@ JMLObjectSequence listValue; 

@*/ 

protected Node first, last; 

/*@ protected depends listValue

} 



@ requires o != null; 

@ modifies listValue; 

@ ensures listValue.equals(old(listValue.insertBack(o))); 

@*/ 

public void append( Object o) { 

if (last==null) { 

first = new Node(null, null, o); 

last = first; 

} else { 

last.next = new Node(null, last, o); 

last = last.next; 

} 

} 

/* ... */ 



public class Node { 


@ JMLObjectSequence values; 

@*/ 

public Node next, prev; 

public Object val; 

/*@ public depends values


public abstract class Set { 


@ JMLObjectSet setValue; @*/ 

protected /*@ non_null @*/ List theList; 

/*@ protected depends setValue


Abschließende Bemerkungen zu Kapitel 4: 

• Verschiedene Techniken zur Spezifikation von Programmund 

Schnittstelleneigenschaften 

• Problematik im Zusammenhang mit Subtypen 

• Testfälle können auch zur Spezifikation eingesetzt werden 

(JML erlaubt die Einbettung von Testfällen in 

Spezifikationen). 

• Am Ende des Entwicklungsprozesses bilden Spezifikation 

und Programm zwei Systembeschreibungen. 

• Verfeinerung von Spezifikation wurden nicht behandelt. 


5. Verifikation spezifizierter 

Eigenschaften


5.1 Techniken zur Verifikation 

5.2 Verifikation durch Beweis 


432

Definition(Verifikation): 

Verifikation bedeutet den Nachweis, dass Software 

bestimmte, explizit beschriebene Eigenschaften besitzt. 

Beschreibung kann erfolgen durch: 

• Testfälle 

• Spezifikation der Funktionalität (Invarianten, Vor- und 

Nachbedingungen, ... ) 

• Spezifikationen nicht-funktionaler Eigenschaften, z.B. 

Antwortzeiten, Codegröße, ... . 

Verifikation prüft also die Übereinstimmung von zwei 

expliziten Beschreibungen. 


433

5.1 Techniken zur Verifikation 434 

5.1 Techniken zur Verifikation 



Grundlegende Techniken zur Verifikation: 

• Testen mit Testfällen 

• Testen durch dynamisches Prüfen 

• erweitertes statisches Prüfen 

• Verifikation durch Beweis 



Testen mit Testfällen 

• Beschreibe das ,,Soll-Verhalten“ der Software durch eine 

(endliche) Menge von Eingabe-Ausgabe-Paaren bzw. von 

Paaren aus Eingaben und Zustandssequenzen. 

• Prüfe, ob die Software zu den Eingaben der Testfälle die 

entsprechenden Ausgaben liefert / Zustände durchläuft. 



Vorteile: 

• Testfälle sind einfach zu verstehen; weitergehende 

Spezifikation ist nicht erforderlich. 

• Durchführung von Tests ist einfach. 

Nachteile: 

• Spezifikation ist immer unvollständig. 

• Problematik in der OO-Programmierung: Bestimmung der 

relevanten Objektgeflechte. 



Testen durch dynamisches Prüfen 

• Beschreibe das ,,Soll-Verhalten“ der Software durch 

ausführbare Programmspezifikation. 

• Prüfe zur Laufzeit, ob die Spezifikation erfüllt ist. 

Dazu können beliebige Eingaben verwendet werden. 

Anders als beim Testen mit Testfällen wird also das 

Verhalten des Programms an bestimmten Stellen 

automatisch während der Auswertung geprüft. 



Vorteile: 

• Fehlermeldung kann automatisiert und komfortabel 

gestaltet werden. 

• Gegenüber Testen mit Testfällen: Angabe des 

Ausgabeverhaltens ist nicht notwendig. 

• Gegenüber statischen Verfahren: Einfacher zu handhaben. 

Nachteile: 

• Gegenüber Testfällen: Spezifikation muss vorhanden sein 

und ist fehleranfälliger als Testfälle. 

• Gegenüber Verifikation durch Beweis: Unvollständigkeit 

und schwächere Spezifikationen. 



Erweitertes statisches Prüfen 

• Beschreibe das ,,Soll-Verhalten“ der Software durch 

Programmspezifikation. 

• Nutze alle automatische Prüftechniken zur statischen 

Analyse der Konsistenz von Programm und Spezifikation. 



Vorteile: 

• Gegenüber Testen: Vollständigere Abdeckung des 

Verhaltens; mächtigere Spezifikationen möglich. 

• Gegenüber Verifikation durch Beweis: Einfacher zu 

handhaben, weil vollautomatisch. 

Nachteile: 

• Gegenüber Testen: Spezifikation muss höheren 

Ansprüchen genügen, insbesondere reichen isolierte 

Eigenschaften im Allg. nicht aus. 

• Gegenüber Verifikation durch Beweis: Unvollständigkeit 

und schwächere Spezifikationen. 



Erweitertes statisches Prüfen basiert auf recht unterschiedlichen 

Techniken: 

• statischer Daten- und Kontrollflussanalyse 

• Modellprüfung endl. Zustandsräume (model checking) 

• Automatisierung klassischer Programmbeweistechniken 



• siehe nächsten Abschnitt 

Verifikation durch Beweis 

Bemerkung: 

Die unterschiedlichen Verifikationstechniken ergänzen sich 

und können kombiniert werden. 


5.2 Verifikation durch Beweis 444 

5.2 Verifikation durch Beweis 



Verifikation im engeren Sinne bedeutet den Beweis 

spezifizierter Eigenschaften mit logischen Mitteln. 

Im Gegensatz zum Testen erlaubt Verifikation durch Beweis, 

die Korrektheit zu zeigen, d.h. insbesondere die Abwesenheit 

von Fehlern. 



Prinzipieller Ansatz 

• Grundlage für die Beweise ist ein mathematisches oder 

formal-logisches Spezifikations- und 

Verifikationsframework. 

• 

Übersetze Spezifikationen und Programme in die Formeln 

des Framework. 

• Beweise die resultierenden Beweisverpflichtungen. 

Wir erläutern den Ansatz anhand eines Frameworks auf der 

Basis einer Hoare-Logikerweiterung. 



Spezifikations- und Verifikationsframework 

Als logische Grundlage betrachten wir eine sortierte 

Prädikatenlogik mit algebraischen Datentypen (vgl. 

Abschnitt 1.2 ). 

Die statische Semantik der betrachteten Programmiersprache 

wird damit spezifiziert (vgl. Abschn. 2.2.2 ). 

Auf dieser Basis lassen sich Eigenschaften über Programmzustände 

formulieren. 



Programmspezifikationen: 

• Invariante zum Typ T ( inv[T] ) 

• Vor- und Nachbedingungsspezifikation zur Methode m in 

Typ T ( req[T:m], ens[T:m] ) 

• Veränderungsklauseln ( mod[T:m] ) 



Programmlogik: 

• Hoare-Logik für partielle Korrektheit mit zusätzlichen 

Regeln für OO-Konstrukte 

• Formeln sind Tripel { P } c { Q }, wobei 

◦ P, Q Formeln der Prädikatenlogik sind; 

◦ c eine Anweisung, virtuelle Methode oder Methodenimplementierung 

ist. 



Definition(Methodenimplementierung): 

Eine Methodenimplementierung K@m ist eine Deklaration 

einer Methode mit Rumpf in Klasse K. 

Definition(virtuelle Methode): 

Zu jeder dynamisch zu bindenden Methode m, die ein Typ T 

selbst deklariert oder erbt, führen wir eine virtuelle Methode 

T:m ein, die das Verhalten aller Methoden m in Subtypen 

von T zusammenfasst. 



Umsetzung von Programmspezifikationen 

Die Spezifikation eines vollständigen Programms Π wird 

umgesetzt in eine Menge von Tripeln. Seien: 

• S0 ein Typ, 

• m eine Methode in S0 und 

• S1, ..., Sk die Supertypen von S0, in denen m existiert, 

mit Si < Si+1 

• T = { T | T ist Typ in Π } 

• INV ⇔ 

T ∈T inv[T] 



Für S0:m ist zu zeigen: 

{ INV ∧ 

0≤i≤k req[Si:m] } S0:m { INV } 

{ INV ∧ 

0≤i≤k req[Si:m] } S0:m { 

0≤i≤k ens[Si:m] } 

sowie 

down(mod[Si:m]) ⊆ down(mod[Si+1:m]) 

{ INV ∧ 

0≤i≤k req[Si:m] ∧ v /∈ down(mod[Sk:m]) ∧ v = Z } 

S0:m { v = Z } 

wobei down( vl: set of VAR ) die Menge aller Variablen 

bezeichnet, die abhängige Variablen in vl besitzen. 



Bemerkung: 

Details der Umsetzung hängen sowohl von der 

Spezifikationssprache als auch von der verwendeten 

Programmlogik ab. 



Hoare-Logik für objektorientierte Programme 

Zusätzlich zu den Eigenschaften für klassische prozedurale 

Programme muss eine Logik für moderne objektorientierte 

Programme mit Folgendem umgehen können: 

• dynamisch allozierte Objekte 

• Subtyping 

• dynamische Bindung 

• Ausnahmebehandlung 

Wir illustrieren diese Aspekte an ausgewählten Regeln für 

eine Teilsprache von Java. 



Axiom für Leseanweisung: 

{(y = null ∧ P [$(y.a)/x]) ∨ 

(y = null ∧ P [$〈NullP Exc〉/$, new($, NullP Exc)/exc])} 

x = y.a; {P } 

Regel für Sequenzanweisung: 

{P} s1 {(exc = null ∧ Q) ∨ (exc = null ∧ R)} 

{R} s2 {Q} 


{P} s1 s2 {Q}


Regeln für Methodenaufruf: 

{P} vm(styp(y, x = y.m(e); ), m) {Q[res/x]} 

{(y = null ∧ P[y/this, e/par])∨ 

(y = null ∧ Q[$〈NullPExc〉/$, new($, NullPExc)/exc])} 

x = y.m(e); {Q} 

{P } x = y.m(e); {Q} 

{P [w/Z]} x = y.m(e); {Q[w/Z]} 

wobei w eine Programmvariable ungleich x ist und Z eine 

logische Variable. 



Bemerkung: 

• Obige Regeln sollen wichtige Ideen demonstrieren. Auf 

Details und die Behandlung rekursiver Methoden muss hier 

verzichtet werden. 

• Die Korrektheit der Logik kann bzgl. der operationalen 

Semantik gezeigt werden. 


6. Ausblicke

• Die Entwicklung der vorgestellten Techniken ist noch im 

Gange: 

◦ Integration 

◦ Modulebene 

◦ Modularität 

• Wichtige zukünftige Aspekte sind außerdem: 

◦ Zusammenwirken mit Entwicklungsmethode 

◦ Integration mit Entwurfstechniken 

◦ Werkzeug- und weitere Sprachunterstützung 

MMISS: Kurztitel September 15, 2003 

459

obj2 - Informatik

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?