Grundlagen der Informatik I

Grundlagen der Informatik I
Wintersemester 1993/94
Christoph Kreitz
FG Intellektik, Gebäude 23, Raum 117, Telephon 16-2863
Kostas Tzeras
Gebäude 25, Raum 3, Telephon 16-3253
1. Lehrziele
2. Veranstaltungsangebot
3. Prüfungsanforderungen
4. Organisatorisches
LEHRZIELE – Forderungen des Gesetzgebers
Selbständigkeit
Verantwortungsbewußtsein
Berufsqualifikation
Qualifikation zur wissenschaftlichen Arbeit
Unser zusätzliches Ziel:
Besser als wir !
Informatik I, Wintersemester 1993/94
1
Einführungsveranstaltung
UNTERSCHIEDE ZUR SCHULE
Neue Denkweisen
Grundlagenorientiert
Steilerer Anstieg, höheres Niveau
Angebote – kein Zwang, keine Anwesenheitspflicht
Eigenverantwortung und Selbstdisziplin erforderlich
Informatik I, Wintersemester 1993/94
2
Einführungsveranstaltung
LEHRINHALTE
Algorithmen, Programme und Rechner
• Umgang mit formalen Systemen
– Logik, Funktionen, abstrakte Maschinen, Programmiersprachen
• Entwurf von Systemen bescheidenen Umfangs
Realisierung in problemorientierter Sprache (Eiffel)
• Analyse der Qualität
– des Entwurfs (Strukturierung)
– der Realisierung (Zuverlässigkeit, Effizienz)
• sozialorientierte Gütekriterien
– Benutzerfreundlichkeit, Datenschutz, Computerethik, usw.
Informatik I, Wintersemester 1993/94
3
Einführungsveranstaltung
VERANSTALTUNGSANGEBOT
• Vorlesung
– Vorstellung der wichtigsten Grundlagen der Programmierung
– Folien der Vorlesung und Skript als Kopiervorlage im LZI (23/31)
• Übung
– selbständiger Entwurf und Diskussion von Systemen in Kleingruppen
– kleine Teilaufgaben und Projekt “Flugverkehrverwaltung”
• Praktikumsvorlesung und Praktikum (RBG!)
– Vorstellung der Programmiersprache Eiffel
– Realisierung von Systemen auf dem Rechner
• Studentischer Arbeitsraum (25/9)
– Treffpunkt für gemeinsames Lernen und Beratung durch Tutoren
– Sprechstunden der Veranstalter
• Prüfungen – Bescheinigung des Lernerfolgs durch Semestralklausur
Informatik I, Wintersemester 1993/94
4
Einführungsveranstaltung
Prüfungsanforderungen – Informatik A
1. Entwurf
15%
– Spezifikation von Datentypen und Schnittstellen
– Strukturierungskonzepte (Parametrisierte Datentypen & Vererbung)
2. Realisierung
50%
Umsetzung der Spezifikation in Funktionen und Prozeduren
– Algorithmusentwurf auf der Basis von Vor- und Nachbedingungen
– Realisierung in höheren und maschinennahen Programmiersprachen
3. Analyse der Zuverlässigkeit
15%
– Korrektheits- und Terminierungsbeweise
– Testen
4. Analyse der Effizienz
10%
– Komplexitätsabschätzungen
5. Modelle von Programmiersprachen,
Informatik I, Wintersemester 1993/94
5
10%
Einführungsveranstaltung
Themen der nächsten Stunde
• Kriterien für Softwarequalität
• Übersicht über formale Systeme
– logische, funktionale, imperative, maschinennahe Programmierung
• Einführung in Programmierung und Strukturierung
– Phasenkonzept der Systementwicklung
– Schrittweise Verfeinerung
– Prozeduralisierung
– Modularisierung und Klassifizierung
Informatik I, Wintersemester 1993/94
6
Einführungsveranstaltung
Grundlagen der Informatik I
Inhalte des Grundstudiums Informatik — ein Überblick
1. Kriterien für Softwarequalität
2. Theoretisch-formale Schwerpunkte
– (Konstruktive) Kaküle der Informatik
3. Methodisch-Technische Schwerpunkte
– Programmentwurf und Strukturierung
SOFTWAREQUALITÄT – externe Merkmale
Korrektheit
Robustheit
– Programm erfüllt exakt seine Aufgaben
– funktioniert auch unter außergewöhnlichen Bedingungen
Erweiterbarkeit
– anpaßbar an geänderte Anforderungen
Wiederverwendbarkeit
Kompatibilität
Effizienz
Portabilität
Verifizierbarkeit
– für neue Anwendungen
– verbindbar mit anderen Programmen
– ökonomische Nutzung von Platz und Zeit
– leicht übertragbar auf verschiedene Umgebungen
– Fehler während der Betriebsphase erkennbar
Integrität
Benutzerfreundlichkeit
Informatik I, Wintersemester 1993/94
– gegen unberechtigten Zugriff
– leichter Umgang für ungeübte Benutzer
8
Inhaltliche Einführung
Theoretisch-formale Schwerpunkte des
Grundstudiums
• Formale Systeme (Kalküle der Informatik)
– Logik als Beschreibungssprache (für Spezifikationen)
– deklarative Programmiersprachen (Prolog)
– funktionale Programmiersprachen (Lisp, ML)
– imperative Programmiersprachen
(Pascal, C, Modula, Ada, Fortran, Cobol, Eiffel ...)
– maschinennahe Programmiersprachen (Assembler, C)
– Schaltungen
• Mathematische Modelle (Informatik IV)
– Grenzen der Anwendbarkeit formaler Systeme
Informatik I, Wintersemester 1993/94
9
Theoretisch-formale Schwerpunkte
GGT – logische Beschreibung
teiler: teilt:IN×IN→IB mit
∀ ∈ IN. teilt(a,a) ∧ teilt(a,a*b)
Größter gemeinsamer Teiler: ggt:IN×IN→IN mit
∀m,n ∈ IN. teilt(ggt(m,n),m) ∧ teilt(ggt(m,n),n)
∧ (∀t ∈ IN. teilt(t,m) ∧ teilt(t,n) ⇒ t≤ggt(m,n))
Zahlentheoretische Erkenntnisse:
teilt(t,m) ∧ teilt(t,n) ⇒ (m>n ⇒ teilt(t,m-n))
teilt(t,m) ∧ teilt(t,n) ⇒ (m<n ⇒ teilt(t,n-m))
m=n ⇒ ggt(m,n) = m
Informatik I, Wintersemester 1993/94
10
Theoretisch-formale Schwerpunkte
GGT - Deklaratives Programm
Konstruktive, rekursive Regeln für Prädikat GGT(m,n,t)
m>n ⇒ ( GGT(m,n,t) ⇔ GGT(m-n,n,t) )
(1)
m<n ⇒ ( GGT(m,n,t) ⇔ GGT(m,n-m,t) )
(2)
m=n ⇒ ( GGT(m,n,t) ⇔ (t=m) )
(3)
Abarbeitung: Suche anwendbare Regeln und ersetze
Nach (2) gilt GGT(12, 15 ,t) ⇔ GGT(12, 3, t)
(1)
GGT(12, 3, t)
⇔ GGT(9, 3, t)
(1)
GGT(9, 3, t)
⇔ GGT(6, 3, t)
(1)
GGT(6, 3, t)
⇔ GGT(3, 3, t)
(3)
GGT(3, 3, t)
⇔ (t=3)
Auch GGT(m,4,2) lösbar
Elegant, aber wenig effizient
Informatik I, Wintersemester 1993/94
11
Theoretisch-formale Schwerpunkte
GGT - Funktionales Programm
Beschreibe Verhalten durch Funktionsdefinition
ggt(m,n) = if m>n
then ggt(m-n,n)
else if m<n
then ggt(m,n-m)
else m
Abarbeitung: Setze Argumente ein und werte
ggt(12,15) = ggt(12,15-12)
= ggt(12-3,3)
= ggt(9-3,3)
= ggt(6-3,3)
= 3
aus
= ggt(12,3)
= ggt(9,3)
= ggt(6,3)
= ggt(3,3)
Konzeptionell einfach, mittelmäßig effizient
Informatik I, Wintersemester 1993/94
12
Theoretisch-formale Schwerpunkte
GGT – imperatives Programm
Maschinenmodell mit Speicher und Befehlen
1
2
3
4
5
6
7
while m<>n do
if m>n
then m:=m-n
else if m<n
then n:=n-m
else ;
t:=m
Abarbeitung: Verändere Speicher und Befehlszähler
1 2 4 5 1 2 3 1 2 3 1 2 3 1 2 4 6 7
nächster Befehl:
Speicher
m 12 12 12 12 12 12 12 9 9 9 6 6 6 3 3 3 3 3 3
n 15 15 15 15 3
3
3
3 3 3 3 3 3 3 3 3 3 3 3
t ?
?
?
? ? ? ? ? ? ? ? ? ? ? 3
?
?
Informatik I, Wintersemester 1993/94
?
?
13
Theoretisch-formale Schwerpunkte
GGT – Assembler Programm
Effizienteste Ausnutzung eines Rechners, mühsam
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Anfang:
Marke1:
Marke2:
Ende:
Informatik I, Wintersemester 1993/94
r:=m;
cc:=r=n;
if cc then goto Ende;
r:=m;
cc:=r>n;
if cc then goto Marke1;
r:= m;
cc:=r<n;
if cc then goto Marke2;
goto Anfang;
r:=n
r:=r-m;
goto Anfang
r:=m;
r:=r-n;
goto Anfang;
t:=m;
14
Theoretisch-formale Schwerpunkte
Zusammenhang der Ebenen
Je tiefer die Ebene, desto effizienter
Programmieraufwand und Fehlerwahrscheinlichkeit wachsen
Methodische Programmentwicklung nötig
– Synthese oder nachträgliche Verifikation
– Intuition steuert systematisch-automatisches Vorgehen
beim Übergang zur nächtsttieferen Ebene
Informatik I, Wintersemester 1993/94
15
Theoretisch-formale Schwerpunkte
Methodisch-Technische Schwerpunkte des
Grundstudiums
• Techniken und Methoden zum Einsatz formaler Systeme
Verwendung der Grundkonzepte zur Beschreibung technischer Systeme
– Beschreibung von Anforderungen in Logik
– Objektorientierter Entwurf in Realisierung in Eiffel
– Maschinennahe Programmierung (Informatik II)
Verlangt Kenntnis der Konzepte und vor allem Training
• Strukturierungsmethoden für formale Systeme
– Organisation des Entwicklungsprozesses
– Strukturierung des zu entwickelnden Systems
– Qualitätsüberprüfung (Testen und Beweisen)
Informatik I, Wintersemester 1993/94
16
Methodisch-Technische Schwerpunkte
Entwicklungsprozeß für große Softwaresysteme
Aufteilung in getrennt zu bearbeitende Teilprobleme
Evolutionäre Entwicklung von Software (Phasenkonzept)
Software Life Cycle
• Systemanalyse
→ Pflichtenheft
• Deskriptive Formulierung
• Entwurf
• Implementierung
→ formale Spezifikation
→ Grobstruktur des Systems
→ Realisierung in Programmiersprache
• Tests, Dokumentation
→ Abnahme durch Benutzer
• Vorschläge für erweiterte, verbesserte neue Version
Informatik I, Wintersemester 1993/94
17
Strukturierungsmethoden
Zerlegungskonzepte für Systeme
• Verfeinerung
– Zerlegung in Teilschritte
– Behandlung von Alternativen
– Wiederholung von Arbeitsvorgängen
• Prozeduralisierung
– Namen geben und (mehrfach) verwenden
– Parameter
– Rekursion
• Modularisierung
• Klassifizierung – Strukturierung der Daten
– Generizität
– Vererbung
Informatik I, Wintersemester 1993/94
18
Strukturierungsmethoden
“Burger”-Herstellung – Teilschritte
Erste Verfeinerung der Herstellung:
Burger-Herstellung:
Brötchen vorbereiten;
Brötchen füllen;
Brötchen verpacken
Zweite Verfeinerung der Herstellung:
Brötchen vorbereiten: Brötchen nehmen;
Brötchen halbieren;
Brötchen füllen:
heißes Hacksteack auf die untere Hälfte legen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;;
alles unter KetchUp verstecken;
obere Brötchenhälfte daraufpappen
Informatik I, Wintersemester 1993/94
19
Strukturierungsmethoden
“Burger”-Herstellung – Alternativen
Brötchen vorbereiten;
if Doppel-Burger verlangt
then heißes Hacksteack hineinlegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;
heißes Hacksteack hineinlegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;;
else heißes Hacksteack hineinlegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;;
alles unter KetchUp verstecken;
obere Brötchenhälfte daraufpappen;
Brötchen verpacken
Informatik I, Wintersemester 1993/94
20
Strukturierungsmethoden
“Burger”-Herstellung – Wiederholungen
while im Fach Platz ist do
Brötchen nehmen; Brötchen halbieren;
if Doppel-Burger verlangt
then heißes Hacksteack hineinlegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;
heißes Hacksteack darauflegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;
else heißes Hacksteack hineinlegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;
alles unter KetchUp verstecken;
obere Brötchenhälfte daraufpappen;
Brötchen verpacken
Informatik I, Wintersemester 1993/94
21
Strukturierungsmethoden
“Burger”-Herstellung – Prozeduralisierung
Namen geben:
Schicht einlegen: heißes Hacksteack darauflegen;
Salatblatt darauflegen;
Tomatenscheiben darauflegen;
Essiggurkenscheiben darauflegen;
Namen verwenden:
while im Fach Platz ist do
Brötchen nehmen; Brötchen halbieren;
if Vierfach-Burger verlangt
then Schicht einlegen; Schicht einlegen;
Schicht einlegen; Schicht einlegen
else if Dreifach-Burger verlangt
then Schicht einlegen; Schicht einlegen; Schicht einlegen
else if Doppel-Burger verlangt
then Schicht einlegen; Schicht einlegen
else Schicht einlegen;
alles unter KetchUp verstecken;
obere Brötchenhälfte daraufpappen;
Brötchen verpacken
Informatik I, Wintersemester 1993/94
22
Strukturierungsmethoden
“Burger”-Herstellung – Parameter
Namen geben:
Schicht(i): while i>0 do
Schicht einlegen;
Zähle i um 1 herunter
Namen verwenden:
while im Fach Platz ist do
Brötchen nehmen;
Brötchen halbieren;
if Vierfach-Burger verlangt
then Schicht (4);
else if Dreifach-Burger verlangt
then Schicht (3);
else if Doppel-Burger verlangt
then Schicht (2);
else Schicht (1);
alles unter KetchUp verstecken;
obere Brötchenhälfte daraufpappen;
Brötchen verpacken
Informatik I, Wintersemester 1993/94
23
Strukturierungsmethoden
“Burger”-Herstellung – Rekursion
Namen geben:
Schicht(i): if i>1
then Schicht einlegen;
Schicht (i-1)
else Schicht einlegen
Informatik I, Wintersemester 1993/94
24
Strukturierungsmethoden
“Burger”-Betrieb – Modularisierung
• Aufteilung in Komponenten
– Lager, Küche, Kasse, Reinigung, Buchhaltung
• Dezentrale Organisation – jeder Teil ist unabhängig
“objektorientiert”
• Alleinige Eigenverantwortlichkeit der Komponenten
“Geheimnisprinzip / Datenkapselung”
Informatik I, Wintersemester 1993/94
25
Strukturierungsmethoden
Fast-Food-Betrieb – Klassifizierung
• Klassifizierung:
Mehrere Komponenten arbeiten nach dem gleichen Prinzip
– Eine Küche, mehrere Kassen
Klassen beschreiben Gemeinsamkeiten der Komponenten
• Generizität:
Identisches Verhalten bis auf eine Komponente
– gleiche Organisation von
Burger Betrieb, Kentucky Fried Chicken, Pizza Hut,
• Vererbung:
Individuelle Ergänzung einer Grundklasse
– Fast-Food-Betrieb wird ergänzt um regionale Zusatzangebote
Handkäs, Weißwurst, Reibekuchen, Fischbrötchen
Informatik I, Wintersemester 1993/94
26
Strukturierungsmethoden
Themen der Vorlesung Informatik I
1. Übersicht
2. Formale Sprachbeschreibungen
3. Objekte und Klassen
4. Systematischer Entwurf
– Verifikation
– Konventionelle Programmierkonstrukte
5. Vererbung
Informatik I, Wintersemester 1993/94
27
Übersicht
Nächste Stunde
• Formale Sprachbeschreibungen
• Syntax: Grammatiken, BNF und Syntaxdiagramme
• Aussagenlogik
• Semantische Wahrheit und syntaktische Ableitbarkeit
Informatik I, Wintersemester 1993/94
28
Übersicht
Notwendigkeit formaler Sprachen
• Programmierung modelliert Ausschnitte der realen Welt
• Modellbildung liefert Arbeitsanweisungen für Rechner
• Natürliche Sprache ist mehrdeutig und kontextabhängig
– Rechner verstehen keine natürliche Sprache
– Sprache muß eindeutig interpretierbar sein
• Formale Logik ist die beste Beschreibungssprache
– Aussagenlogik
– Prädikatenlogik
Informatik I, Wintersemester 1993/94
29
Formale Sprachen
Beschreibung formaler Sprachen
• Syntax: Beschreibung der korrekt geformten Sätze
• Semantik: Beschreibung der Bedeutung
• Ableitungssystem: Regeln zur Erzeugung syntaktisch
korrekter Sätze aus anderen korrekten Sätze
Informatik I, Wintersemester 1993/94
30
Formale Sprachen
Syntax der arithmetischen Ausdrücke
Startsymbol:
Formel
Alphabet:
Grundmengen
Konstante, Name
Sonstige Symbole
+ − ∗/()
Regeln:
Formel ::=
Term
::=
Faktor ::=
Informatik I, Wintersemester 1993/94
31
Term
[1]
| Formel + Term
[2]
| Formel - Term
[3]
Faktor
[4]
| Term ∗ Faktor
[5]
| Term / Faktor
[6]
Konstante
[7]
| Name
[8]
| ( Formel )
[9]
Formale Sprachen
Grammatik – Mittel zur Syntaxbeschreibung
• Alphabet (‘Terminalsymbole’):
– Menge der erlaubten Symbole
– besteht aus Grundmengen und sonstigen Symbolen
• Variablen (‘Non-Terminalsymbole’):
– Hilfsbegriffe zur Beschreibung syntaktischer Einheiten
• Regeln der Form X ::= x1..xk
– ‘Das Non-Terminalsymbol X kann durch x1..xk ersetzt werden’
• Startsymbol:
– Non-Terminalsymbol, von dem jede Ableitung ausgeht
Darstellung als Backus-Naur-Form oder Syntaxdiagramm
Informatik I, Wintersemester 1993/94
32
Formale Sprachen
Ableitung
• Regelanwendung: Wenn X ::= x1..xk eine Regel ist, so kann in einer
Zeichenkette a1...X...an das Symbol X durch x1..xk ersetzt werden.
– Schreibweise: a1...X...an −→ a1...x1..xk ...an
• Ableitung: Folge von Regelanwendungen, beginnend mit dem Startsymbol (endend
in einer Zeichenkette ohne Non-Terminalsymbole)
• Ableitungsbaum: graphische Darstellung einer Ableitung
• Linksableitung: Ableitung, bei in jedem Schritt das am weitesten links stehende
Non-Terminalsymbol ersetzt wird.
– Zu jedem Ableitungsbaum gibt es genau eine Linksableitung
• Eindeutigkeit: jedes korrekte Wort hat nur einen Ableitungsbaum
Informatik I, Wintersemester 1993/94
33
Formale Sprachen
Ableitung und Ableitungsbaum für a ∗ b + c
Formel −→ Formel + Term
Formel
[2]
−→ Term + Term
[1]
−→ Term ∗ Faktor + Term
[5]
Formel
Term
−→ Faktor ∗ Faktor + Term [4]
−→ a ∗ Faktor + Term
[8]
−→ a ∗ b + Term
[8]
−→ a ∗ b + Faktor
[4]
−→ a ∗ b + c
[8]
Informatik I, Wintersemester 1993/94
+
Term
Faktor
Faktor
∗ Faktor
b
a
34
Term
Formale Sprachen
c
Arithmetischen Ausdrücke – mehrdeutige Grammatik
Startsymbol:
Formel
Alphabet:
Grundmengen
Konstante, Name
Sonstige Symbole
+ − ∗/()
Regeln:
Formel ::=
Faktor
| Formel + Formel
[2]
| Formel - Formel
[3]
| Formel ∗ Formel
[4]
| Formel / Formel
[5]
Faktor ::=
Informatik I, Wintersemester 1993/94
[1]
Konstante
[6]
| Name
[7]
| ( Formel )
[8]
35
Formale Sprachen
Zwei Ableitungsbäume für a ∗ b + c
Formel
Formel
Formel
+
Formel ∗ Formel
Formel
Faktor
Faktor
b
Formel
Formel
Faktor
Faktor
c
a
*
Formel
Formel + Formel
Faktor
Faktor
b
c
a
Informatik I, Wintersemester 1993/94
36
Formale Sprachen
Arithmetischen Ausdrücke – Prefix-Form
Startsymbol:
Formel2
Alphabet:
Grundmengen
Name, Konstante, Operator
Sonstige Symbole ( ) ,
Regeln:
Formel2
::= Konstante
[1]
| Name
[2]
| Funktionsanwendung
[3]
Funktionsanwendung ::= Operator(Operanden Liste) [4]
Operanden Liste
::= Operand
[5]
| Operand, Operanden Liste [6]
Operand
::= Formel2
[7]
Kontextbedingungen: Genau dann, wenn t1, t2, ..., tn Operanden sind und f ein
n-stelliges Element aus Operator ist, ist auch f (t1, t2, ..., tn) eine
Funktionsanwendung.
Informatik I, Wintersemester 1993/94
37
Formale Sprachen
Syntaxdiagramme für arithmetische Ausdrück
Formel
Term
Formel + Term
Formel - Term
Term
Faktor
Term ∗ Faktor
usw.
Term / Faktor
Informatik I, Wintersemester 1993/94
38
Formale Sprachen
Formale Logik
• Formale Sprache für “logische Schlüsse”
• Symbole für Verknüpfung von Aussagen:
Junktoren
¬
Negation
∧
Konjunktion ‘und’
∨
Disjunktion ‘oder’
Quantoren
‘nicht’
∀ ‘für alle’
∃ ‘es gibt’
⇒ Implikation ‘daraus folgt’
⇔ Äquivalenz
‘genau dann, wenn’
• Aussagenlogik: einfache Verknüpfungen ohne Quantoren
• Prädikatenlogik: komplexe Verknüpfungen
Informatik I, Wintersemester 1993/94
39
Formale Sprachen
Syntax der Aussagenlogik (mit Klammerung)
Startsymbol:
Aussage
Alphabet:
Grundmengen
Bezeichner
Sonstige Symbole
¬
Syntax:
∧ ∨
Aussage
⇒ ⇔ ()T F
::=
Atomaraussage
| (¬ Aussage)
| (Aussage
∧
Aussage)
| (Aussage
∨
Aussage)
| (Aussage ⇒ Aussage)
| (Aussage ⇔ Aussage)
Atomaraussage ::=
Informatik I, Wintersemester 1993/94
40
T | F | Bezeichner
Formale Sprachen
Syntax der Aussagenlogik (ohne Klammerung)
Startsymbol:
Aussage
Alphabet:
Grundmengen
Bezeichner
Sonstige Symbole
¬
Syntax:
∧ ∨
⇒ ⇔ ()T F
Aussage
::=
Imp-Ausdruck
| Aussage ⇔ Imp-Ausdruck
Imp-Ausdruck ::=
Ausdruck
| Imp-Ausdruck ⇒ Ausdruck
Ausdruck
::=
Term
| Ausdruck
Term
::=
Term
Faktor
| Term
Faktor
∨
∧
Faktor
¬ Faktor | ( Aussage )
::=
| T | F | Bezeichner
Wertigkeiten: ¬ >
Informatik I, Wintersemester 1993/94
∧ > ∨ >
41
⇒
>
⇔
Formale Sprachen
Ableitungsbaum für
¬a ∧ b ∨ c ⇒ d ⇔ e
Aussage
⇔ Imp-Ausdruck
Aussage
Imp-Ausdruck
⇒ Ausdruck
Imp-Ausdruck
Ausdruck
Ausdruck
∨
Term
Term
∧
Faktor
¬
Ausdruck
Term
Term
Faktor
Faktor
Faktor
Term
Faktor
e
d
c
b
Faktor
a
Informatik I, Wintersemester 1993/94
42
Formale Sprachen
(Denotationale) Semantik
Beschreibung der Bedeutung von Ausdrücken einer Quellsprache
in einer bekannten Zielsprache
• Ziel Wahrheitswerte = { wahr, falsch}
Ziel Operatoren = { und, oder, nicht, impl, gleich }
• Bedeutung der Ziel Operatoren
b
c
falsch
falsch
wahr
wahr
falsch
wahr
falsch
wahr
(nicht b) (b und c) (b oder c) ( b impl c) (b gleich c)
wahr
wahr
falsch
falsch
falsch
falsch
falsch
wahr
falsch
wahr
wahr
wahr
wahr
wahr
falsch
wahr
wahr
falsch
falsch
wahr
• Zustand: Funktion ‘state’ : Bezeichner → Ziel Wahrheitswert
– Festgelegt durch Wertetabelle: z.B.[a 7→ wahr, bc 7→ falsch]
• Interpretationsfunktion:
s : Syntaktische Aussage × Zustand → Ziel Wahrheitswerte
– Festgelegt durch Zustand und Definitionsgleichungen auf Junktoren
Informatik I, Wintersemester 1993/94
43
Formale Sprachen
Semantik aussagenlogischer Formeln
s (Bezeichner, state) = state(Bezeichner)
s (T , state)
= wahr
s (F , state)
= falsch
s ((Aussage), state) = s (Aussage, state)
s (¬ Faktor, state) = (nicht s (Faktor, state))
s (Term ∧ Faktor, state)
= (s (Term, state) und s (Faktor, state))
s (Ausdruck
∨
Term, state)
= (s (Ausdruck, state) oder s (Term, state))
s (Imp-Ausdruck ⇒ Ausdruck, state)
= (s (Imp-Ausdruck, state) impl s (Ausdruck, state))
s (Aussage ⇔ Imp-Ausdruck, state)
= (s (Aussage, state) gleich s (Imp-Ausdruck, state))
Informatik I, Wintersemester 1993/94
44
Formale Sprachen
Semantikberechnung
state = [a 7→ wahr, b 7→ falsch, c 7→ wahr, d 7→ falsch, e 7→ wahr]
=
=
=
=
=
=
=
=
=
=
s(¬a ∧ b ∨ c ⇒ d ⇔ e, state)
s(¬a ∧ b ∨ c ⇒ d, state) gleich s(e, state)
s(¬a ∧ b ∨ c ⇒ d, state) gleich wahr
(s(¬a ∧ b ∨ c, state) impl s(d, state)) gleich wahr
(s(¬a ∧ b ∨ c, state) impl falsch) gleich wahr
((s(¬a ∧ b, state) oder s(c, state)) impl falsch) gleich wahr
((s(¬a ∧ b, state) oder wahr) impl falsch) gleich wahr
(((s(¬ a) und s(b, state)) oder wahr) impl falsch) gleich wahr
(((s(¬ a) und falsch) oder wahr) impl falsch) gleich wahr
((((nicht s(a), state) und falsch) oder wahr) impl falsch) gleich wahr
((((nicht wahr) und falsch) oder wahr) impl falsch) gleich wahr
Reduktion unter Anwendung der Wahrheitstafel ergibt:
(((falsch und falsch) oder wahr) impl falsch) gleich wahr
= ((falsch oder wahr) impl falsch) gleich wahr
= (wahr impl falsch) gleich wahr
= falsch gleich wahr
= falsch
Informatik I, Wintersemester 1993/94
45
Formale Sprachen
Konversion
Konversionsregel ‘A ≡ B’ gilt genau dann, wenn
s (A, state) = s (B, state) für alle Zustände gilt
K1 E1 ∧ E2 ≡ E2 ∧ E1
K8
E1 ∨ E 2 ≡ E 2 ∨ E 1
E1 ⇔ E 2 ≡ E 2 ⇔ E 1
K2 E1 ∧ (E2 ∧ E3) ≡ (E1 ∧ E2) ∧ E3
E1 ∨ (E2 ∨ E3) ≡ (E1 ∨ E2) ∨ E3
K3 E1 ∨ (E2 ∧ E3) ≡ (E1 ∨ E2) ∧ (E1 ∨ E3)
E1 ∧ (E2 ∨ E3) ≡ (E1 ∧ E2) ∨ (E1 ∧ E3)
K4 ¬(E1 ∧ E2) ≡ ¬E1 ∨ ¬E2
¬(E1 ∨ E2) ≡ ¬E1 ∧ ¬E2
E1 ⇒ E2 ≡ ¬E1 ∨ E2
T ⇒ E 2 ≡ E2
K9
E1 ⇔ E2 ≡ (E1 ⇒ E2) ∧ (E2 ⇒ E1)
K10 E1 ∨ E1 ≡ E1
E1 ∨ T ≡ T
E1 ∨ F ≡ E 1
E1 ∨ (E1 ∧ E2) ≡ E1
K11 E1 ∧ E1 ≡ E1
E1 ∧ T ≡ E 1
K5 ¬(¬E1) ≡ E1
E1 ∧ F ≡ F
K6 ¬E1 ∨ E1 ≡ T
E1 ∧ (E1 ∨ E2) ≡ E1
K7 ¬E1 ∧ E1 ≡ F
Informatik I, Wintersemester 1993/94
K12 E1 ≡ E1
46
Formale Sprachen
Ableitungssysteme (Kalküle)
Syntaktische Manipulation ersetzt Semantik
• Kalkül: (Formale Sprache +) Axiome + Regeln
• Axiom: als gültig vereinbarte Grundaussage
– Angegeben als Axiomenschema mit freien Aussagenvariablen
• Regel: Prämissen + Konklusion
P1 , . . . , P n
K
– A `R B: Anwendung von Regel R auf A liefert B
– Angegeben als Regelschema
• B ist aus A ableitbar genau dann wenn gilt
A1 ` R 1 B 1 , . . . , A j ` R j B j , . . . , A n ` R n B
(Aj enthält Axiome, die Formeln aus A und die Bl mit 1 ≤ l < k)
• B ist ableitbar gdw. B aus den Axiomen ableitbar ist.
• Tautologie: Aussagen mit s (Aussage, state)=wahr für alle Zustände
Informatik I, Wintersemester 1993/94
47
Formale Sprachen
Kalkül für die Aussagenlogik
Axiomenschemata:
L1
A ∨ ¬A
L2
(A ∧ ¬A) ⇒ B
L3
(A ⇒ (B ∧ ¬B)) ⇒ ¬A
Ableitungsregeln:
⇒ -E
⇒ -I
∧ -I
∧ -E
∨ -I
∨ -E
⇔ -I
⇔ -E
Subst
Informatik I, Wintersemester 1993/94
E1 , E 1 ⇒ E 2
E2
[E1]E2
E1 ⇒ E 2
E1, ..., En
E1 ∧ ... ∧ En
E1 ∧ ... ∧ En
Ei
Ei
E1 ∨ ... ∨ En
E1 ∨ ... ∨ En, E1 ⇒ E, ..., En ⇒ E
E
E1 ⇒ E2, E2 ⇒ E1
E1 ⇔ E 2
E1 ⇔ E 2
E1 ⇒ E2, E2 ⇒ E1
E1 ⇔ E 2
E(E1) ⇔ E(E2), E(E2) ⇔ E(E1)
48
Formale Sprachen
Zusatzaxiome, die ‘ ⇒ -I’ ersetzen
L4
A⇒A
L5
A ⇒ (B ⇒ A)
L6
((A ⇒ (B ⇒ C)) ∧ (A ⇒ B)) ⇒ (A ⇒ C)
L7
((A ⇒ B) ∧ (B ⇒ C)) ⇒ (A ⇔ C)
L8
(A ⇒ B) ⇒ (¬B ⇒ ¬A)
L9
(¬(¬A)) ⇔ A
L10 ((A ∨ B) ∧ (¬A ∨ C)) ⇒ B ∨ C
Informatik I, Wintersemester 1993/94
49
Formale Sprachen
Zusammenhang zwischen
Syntax, Semantik und Ableitungssystem
syntaktische Ableitung
syntaktische Aussage
Rechnen im syntaktischen Modell
syntaktische Aussage
-
H
HH
HH
InterHH
HH
Interpretation (s)
preHH
HH
HH
taHH
H
tion
HH
HH
HH
(s)
HH
H
j
H
?
semantische Ergebnisse
Informatik I, Wintersemester 1993/94
50
Formale Sprachen
Nächste Stunde – Kapitel 2.2
• Umsetzung natürlichsprachlicher Aussagen
in solche der Logik
• Prädikatenlogik
– Syntax
– Semantik
– Ableitungskalkül
• Dreiwertige Logik
Informatik I, Wintersemester 1993/94
51
Formale Sprachen
Syntax der Prädikatenlogik I
Startsymbol:
Alphabet:
Grundmengen:
Sonstige Symbole
Satz
Prädikat Symbol, Konstantes Prädikat,
Funktions Symbol, Konstante, Variable, Bereich
∧ ∨
⇒ ⇔ ∀∃ . T F ) ( = ,
::=
Atomaraussage
¬ Satz | ( Satz ∧ Satz ) | ( Satz ∨ Satz )
( Satz ⇒ Satz ) | ( Satz ⇔ Satz )
( ∀ Variable : Bereich . Satz )
( ∃ Variable : Bereich . Satz )
Regeln:
Satz
|
|
|
|
Atomaraussage
::=
Termlist
::=
Term
::=
Informatik I, Wintersemester 1993/94
T | F | ( Term = Term )
| Konstantes Prädikat
| Prädikat Symbol ( Termlist )
Term | Term , Termlist
Konstante | Variable
| Funktions Symbol ( Termlist )
52
Prädikatenlogik
Syntax der Prädikatenlogik II
Kontextbedingungen:
Genau dann, wenn t1, t2, ..., tn Terme sind und p ein n-stelliges Element aus
Prädikat Symbol ist, ist auch p(t1, t2, ..., tn) ein Satz.
Genau dann wenn t1, t2, ..., tn Terme sind und f ein n-stelliges Element aus
Funktions Symbol ist, ist auch f (t1, t2, ..., tn) ein Term.
Bereich ist eine Menge, deren Elemente die Variable als Werte annehmen kann. Kein
Element aus Variable darf als Name in Bereich vorkommen.
Operator Priorität
¬, ∃, ∀ 4 (höchste Priorität)
Prioritäten der Operatoren:
∧
3
∨
2
⇒, ⇔ 1
Informatik I, Wintersemester 1993/94
53
Prädikatenlogik
Bibliothekenbeispiel – Formalisierung I
• Herr Tzeras ist Entleiher der LHB und der Informatik-Bibliothek
Entleiher(LHB,Tzeras) ∧ Entleiher(Inf-Bib,Tzeras)
• Ein Buch kann entleihbar, ausgeliehen, Präsenzexemplar oder
Semesterapparat sein.
∀b : Bücher . (status(b)=‘entleihbar’
∨ status(b)=‘ausgeliehen’
∨ status(b)=‘Präsenzexemplar’
∨ status(b)=‘Semesterapparat’)
oder
∀b : Bücher . (entleihbar(b) ∨ ausgeliehen(b)
∨ Präsenzexemplar(b) ∨ Semesterapparat(b) )
Informatik I, Wintersemester 1993/94
54
Prädikatenlogik
Bibliothekenbeispiel – Formalisierung II
• Die Leihfrist eines Buches beträgt 4 Wochen
∀b : Bücher . ausgeliehen(b) ⇒
Tagesdifferenz(Ausleihdatum(b),Ausleihfrist(b)) ≤ 28
• Hochschullehrer dürfen maximal ein Semester ausleihen
∀b : Bücher . ∀p : Personen .
ausgeliehen(b) ∧ entliehen durch(p,b) ⇒
(Hochschullehrer(p) ⇒
Tagesdifferenz(Ausleihdatum(b),Ausleihfrist(b)) ≤ 183)
∧ (¬Hochschullehrer(p) ⇒
Tagesdifferenz(Ausleihdatum(b),Ausleihfrist(b)) ≤ 28)
Informatik I, Wintersemester 1993/94
55
Prädikatenlogik
Semantik der Prädikatenlogik I
Zustand :
Variable → Grundmenge
B
Prädikat Symbol → Ziel Prädikat
:
| Konstantes Prädikat → Ziel Wahrheitswert
| Funktions Symbol → Ziel Funktion
| Konstante → Ziel Konstante
s (T, state)
= wahr
s (F, state)
= falsch
s (Prädikat Symbol (termlist), state) = B(Prädikat Symbol) (slist (termlist, state))
s (Konstantes Prädikat, state)
= B(Konstantes Prädikat)
s (Term1 = Term2, state)
= if s (Term1, state) = s (Term2, state)
then wahr else falsch
s ((¬ Satz), state)
= (nicht s (Satz, state))
s ((Satz1
∧
Satz), state)
= (s (Satz1, state) und s (Satz2, state))
s ((Satz1
∨
Satz), state)
= (s (Satz1, state) oder s (Satz2, state))
s ((Satz1 ⇒ Satz), state)
= (s (Satz1, state) impl s (Satz2, state))
s ((Satz1 ⇔ Satz), state)
= (s (Satz1, state) gleich s (Satz2, state))
Informatik I, Wintersemester 1993/94
56
Prädikatenlogik
Semantik der Prädikatenlogik II
s ((∀ Variable : Bereich . Satz), state) = if Bereich = {} then wahr
else let x
∈
Bereich in
s (Satz, state + [Variable 7→ x]) und
s ((∀ Variable : Bereich-{x} . Satz), state)
s ((∃ Variable : Bereich . Satz ), state) = if Bereich = {} then falsch
else let x
∈
Bereich in
s (Satz, state + [Variable 7→ x]) oder
s ((∃ Variable : Bereich-{x} . Satz), state)
s (Variable, state)
= state(Variable)
s (Konstante, state)
= B(Konstante)
s Funktions Symbol (termlist), state)
= B(Funktions Symbol) (slist (termlist, state))
slist (termlist, state)
= if einelementig(termlist)
then s (termlist, state)
else s (head(termlist), state) cons
slist (tail(termlist), state))
Informatik I, Wintersemester 1993/94
57
Prädikatenlogik
Freies Vorkommen von Variablen in Ausdrücken
• jedes Vorkommen von x in einer Atomaraussage ist frei
• x ist frei in f(x1, ..., xn), wenn f entweder ein Funktionssymbol ohne
Bereichsangabe ist, oder x in der Bereichbeschreibung nicht entsprechend
verwendet wird
• x ist frei in f(t1, ..., tn), falls x in mindestens einem ti frei ist
• x ist frei in p(t1, ..., tn) oder t1 = t2, falls x in mindestens einem ti frei ist
• x ist frei in ¬ A, wenn x in A frei ist
• x ist frei in A op B, wenn x in A oder in B frei ist (op aus
∧, ∨,
⇒, ⇔)
• x ist frei in ∃y : Bereich . A bzw. ∀y : Bereich . A, wenn x in A frei
vorkommt und x verschieden y ist
Px1,...,xn : P ist ein Prädikat mit freien Variablen x1, ..., xn
A
"
t
x
#
: alle freien Vorkommen von x in A werden durch t ersetzt
Informatik I, Wintersemester 1993/94
58
Prädikatenlogik
Gebundenes Vorkommen von Variablen in Ausdrücken
• kein Vorkommen von x in einer Atomaraussage ist gebunden
• x ist gebunden in f(x1, ..., xn), wenn f ein Funktionssymbol mit
Bereichsangabe ist und x in der Bereichbeschreibung entsprechend verwendet
wird
• x ist gebunden in f(t1, ..., tn), falls x in mindestens einem ti gebunden ist
• x ist gebunden in p(t1, ..., tn) oder t1 = t2, falls x in mindestens einem ti
gebunden ist
• x ist gebunden in ¬ A, wenn x in A gebunden ist
• x ist gebunden in A op B, wenn x in A oder in B gebunden ist
(op aus
∧, ∨,
⇒, ⇔)
• x ist gebunden in ∃y : Bereich . A bzw. ∀y : Bereich . A, wenn x in A
gebunden vorkommt oder x identisch mit y ist
Informatik I, Wintersemester 1993/94
59
Prädikatenlogik
Ableitungskalkül für die Prädikatenlogik
Axiomenschemata
A1
A ∨ ¬A
A2
(A ∧ ¬A) ⇒ B
A3
(A ⇒ (B ∧ ¬B)) ⇒ ¬A
A4
((...(x1 = y1) ∧ ...)...) ∧ (xn = yn) ⇒ (p(x1 , ..., xn) ⇔ p(y1, ..., yn))
für alle n-stelligen Prädikat Symbole p (n ≥ 1)
A5
((...(x1 = y1) ∧ ...)...) ∧ (xn = yn) ⇒ (f (x1, ..., xn)=f (y1, ..., yn))
für alle n-stelligen Funktions Symbole f (n ≥ 1)
Informatik I, Wintersemester 1993/94
60
Prädikatenlogik
Ableitungskalkül für die Prädikatenlogik
Ableitungsregeln
Regeln ⇒ -E, ⇒ -I,
R1–R9
∧ -I, ∧ -E, ∨ -I, ∨ -E,
⇔ -I, ⇔ -E, Subst der Aussagenlogik
R10
∃-I
R11
∃x :
∃-E ∃x :
R12
∀-I
R13
R14
R15
R16
R17
R18–R19
∀x :
∀-E ∀x :
w
x
A
Bereich . A
Bereich . A1, A1 ⇒ A2
A2
A
Bereich . A
Bereich
.A
w
A x
(∃x : Bereich−{w} . A) ∨ ((x
∃x : Bereich . A
∃x : Bereich . A
(∃x : Bereich−{w} . A) ∨ ((x
(∀x : Bereich−{w} . A) ∧ ((x
∀x : Bereich . A
∀x : Bereich . A
(∀x : Bereich−{w} . A) ∧ ((x
w
x
A
(x = w) ⇒ A
falls w ∈ Bereich
falls x in A2 nicht frei vorkommt
= w) ⇒ A)
= w) ⇒ A)
= w) ⇒ A)
= w) ⇒ A)
falls w ∈ Bereich
falls w ∈ Bereich
falls w ∈ Bereich
falls w ∈ Bereich
(x = w)
⇒A
w
A x
Informatik I, Wintersemester 1993/94
61
Prädikatenlogik
Syntax der dreiwertigen Logik
Startsymbol:
Aussage
Alphabet:
Grundmengen
Bezeichner
Sonstige Symbole ¬
∧
∨
∨
∧
⇒ ⇔ ( ) T F U
Syntax:
Aussage
::=
Imp-Ausdruck | Aussage ⇔ Imp-Ausdruck
Imp-Ausdruck
::=
Ausdruck | Imp-Ausdruck ⇒ Ausdruck
Ausdruck
::=
Term | Ausdruck
∨
Term
::=
Faktor | Term
Faktor | Term
Faktor
::=
¬ Faktor | ( Aussage )
∧
Term | Ausdruck
∧
∨
Faktor
| T | F | U | Bezeichner
Informatik I, Wintersemester 1993/94
62
Term
Prädikatenlogik
Wahrheitstafel für die dreiwertige Logik
b
c
(nicht b) (b und c) (b oder c) (b impl c) (b gleich c)
falsch falsch
wahr
falsch
falsch
wahr
wahr
falsch wahr
wahr
falsch
wahr
wahr
falsch
falsch undef
wahr
falsch
undef
wahr
undef
wahr falsch
falsch
falsch
wahr
falsch
falsch
wahr wahr
falsch
wahr
wahr
wahr
wahr
wahr undef
falsch
undef
wahr
undef
undef
undef wahr
undef
undef
undef
undef
undef
undef falsch
undef
undef
undef
undef
undef
undef undef
undef
undef
undef
undef
undef
Informatik I, Wintersemester 1993/94
63
Prädikatenlogik
Semantik der dreiwertigen Logik
s (Bezeichner, state)
= state(Bezeichner)
s (T, state)
= wahr
s (F, state)
= falsch
s (U, state)
= undef
s ((Aussage), state)
= s (Aussage, state)
s (¬ Faktor, state)
= (nicht s (Faktor, state))
s (Term
∧
Faktor, state)
= (s (Term, state) und s (Faktor, state))
s (Term
∧
Faktor, state)
= let x = s (Term, state) in
(if x then s (Faktor, state)
else (if x = falsch then falsch else undef))
s (Ausdruck
∨
Term, state)
= (s (Ausdruck, state) oder s (Term, state))
s (Ausdruck
∨
Term, state)
= let x = s (Ausdruck, state) in
(if x = undef then undef
else (if x = falsch then s (Term, state)
else wahr ))
s (Imp-Ausdruck ⇒ Ausdruck, state) = (s (Imp-Ausdruck, state) impl s (Ausdruck, state))
s (Aussage ⇔ Imp-Ausdruck, state)
Informatik I, Wintersemester 1993/94
= (s (Aussage, state) gleich s (Imp-Ausdruck, state))
64
Prädikatenlogik
Metasprache für Programmiersprachen
Struktur von Funktionen
f:A→B
Typdeklaration
lambdax. ausdruck
Funktionsdefinition
f(x)
Funktionsanwendung
if..then..else
Fallunterscheidung
let x = Teilausdruck in Ausdruck
determinierte Abkürzung
Ausdruck where x = Teilausdruck
von Teilausdrücken
let x
∈
Bereich in Ausdruck
Ausdruck where x
∈
indeterminierte Abkürzung
von Teilausdrücken
Bereich
Für f:A→B heißt A Definitionsbereich von f, B Wertebereich von f
f ist total, wenn f auf allen Werten von A definiert ist, sonst partiell.
Der Domain von f ist die Menge der Argumente auf denen f definiert ist
Informatik I, Wintersemester 1993/94
65
Metasprache
Metasprache – Datentypen und Operationen
{}
Leere Menge
{arg1,...,argn}
Explizite Mengenangabe
M1∪M2, M1∩M2
Vereinigung, Durchschnitt
M1-M2
Mengendifferenz
x ∈M
Elementrelation (boolesche Funktion)
[]
Leere Tabelle (endliche Funktion)
[arg17→wert1, ...,argn7→wertn ] Explizite Tabellenangabe
domain(tab)
Domain der endlichen Funktion tab
tab1+tab2
Verschmelzung zweier Tabellen
tab / {arg1,...,argn}
Entfernen von Tabelleneinträgen
A∗
Menge aller Listen über Elementen aus A
<>
Leere Liste
<a1,...,an>
Explizite Listenangabe
head(l)
Erstes Element von l
tail(l)
Rest von l
l1 & l 2
Informatik I, Wintersemester 1993/94
Verkettung
zweier Listen
66
Metasprache
Nächste Stunden
• Objekte
• abstrakte Datentypen
• Klassen in Eiffel
– Features (Attribute und Routinen)
– Standardroutinen für alle Klassen
– Generizität
– Verträge
Informatik I, Wintersemester 1993/94
67
Metasprache
Systematischer Systementwurf
1. Strukturierung der Daten
– Zerlegung in Klassen
– Beziehung der Klassen (Vererbung, Benutzung)
– Beschreibung der Dienstleistungen (Kontrakt)
2. Implementierung der Dienstleistungen
– Schrittweise Verfeinerung
– Prozeduralisierung
3. Ein- und Ausgabeformate
Informatik I, Wintersemester 1993/94
68
Klassen und Objekte
Strukturierung der Daten
• Strukturierungskonzepte von Eiffel
– Objekte
– Referenz-Semantik
– Klassen
– Generizität
– Routinen
– Kontrakte
– Datenkapselung
– Vererbung
• Benutzung der Strukturierungskonzepte
– Arbeiten mit der Eiffel-Umgebung
– Genaue Sprachbeschreibung: Syntax und Semantik
Informatik I, Wintersemester 1993/94
69
Klassen und Objekte
Leitbeispiel – Bibliothekenverwaltung
• Bibliotheken:
– z.B. Informatik, Mathematik, E-Technik, LHB, ...
• Bücher:
– Autor, Titel, Kennung, Entleihstatus, Leihfrist ....
• Benutzer:
– Entleiher, Universitätsangestellte, Professoren
– Bibliotheksmitarbeiter
• Transaktionen:
– Ausleihen, Verlängerung, Rückgabe
– Entnahme, Neubeschaffung, Status ändern
• Dienstleistungen:
– Verwaltung, Mahnung, Informationssystem
Informatik I, Wintersemester 1993/94
70
Klassen und Objekte
Objekte
• extern: Bestandteil der realen Welt
• intern: Laufzeitelemente eines Softwaresystems
– strukturierte Repräsentation externer Objekte
– abstrahiert auf verarbeitungsrelevante Komponenten
• Einfaches Beispiel
‘‘Bertrand Meyer’’
‘‘Objektorientierte Software-entwicklung’’
1990
‘‘Hanser’’
547
‘‘D4.1 Mey 8267’’
4 Zeichenketten, 2 ganze Zahlen
Möglicherweise Repräsentation eines Buches
Informatik I, Wintersemester 1993/94
71
Klassen und Objekte
Objekt in einem Objekt
‘‘Meyer’’
‘‘Bertrand’’
1946
????
Frankreich
‘‘Objektorientierte Software-entwicklung’’
1990
‘‘Hanser’’
547
‘‘D4.1 Mey 8267’’
Darstellungsform nicht empfehlenswert (Konsistenzprobleme)
Informatik I, Wintersemester 1993/94
72
Klassen und Objekte
Verweise
PP
PP
PP
‘‘Eiffel -- the PLanguage’’
PP
P
1992
PP
‘‘Prentice Hall’’
PP
PP
PP
PP
PP
PP
595
PP
PP
PP
PP
PP
PP
‘‘Meyer’’
PP
q
P
‘‘D4.1 Mey 8935’’
‘‘Bertrand’’
1946
-
‘‘Objektorientierte Software-entwicklung’’
1990
????
Frankreich
‘‘Hanser’’
547
‘‘D4.1 Mey 8267’’
Informatik I, Wintersemester 1993/94
73
Klassen und Objekte
Feste Datenstrukturbeschreibung
Darstellung von Personen ==
– 20 Zeichen Name,
– 25 Zeichen Vornamen,
– je 4 Stellen Geburts- und Todesjahr,
– 15 Stellen Nationalität
Meyer
Bertrand
1946????Frankreich
....................................................................
Kreitz
Christoph Sebastian Maxim1957????Deutschland
unflexibel + überspezifiziert
Informatik I, Wintersemester 1993/94
74
Klassen und Objekte
Abstrakte Datentypen
Vollständige, genaue und eindeutige Beschreibung
einer Datenstruktur ohne Überspezifikation
• Welche Typen werden eingeführt?
• Welche Funktionen (Dienstleistungen) werden eingeführt?
• Was sind die Vorbedingungen für die Anwendbarkeit der
Funktionen?
• Welche Axiome (Eigenschaften) erfüllen die Funktionen?
Objektorientierter Entwurf ist
Entwicklung von Softwaresystemen als strukturierte Sammlung von
Implementierungen abstrakter Datentypen
Informatik I, Wintersemester 1993/94
75
Klassen und Objekte
Abstrakter Datentyp Liste
TYPES:
List[X]
FUNCTIONS:
empty: List[X] → BOOLEAN
new: → List[X]
cons: X×List[X] → List[X]
head: List[X] 6→ X
tail: List[X] → List[X]
PRECONDITIONS: pre head(L:List[X]) = (not empty(L))
AXIOMS:
∀x:X . ∀L:List[X] .
empty(new())
not empty(cons(x,L))
head(cons(x,L)) = x
tail(cons(x,L)) = L
tail(new()) = new()
Informatik I, Wintersemester 1993/94
76
Klassen und Objekte
Klassen in Eiffel
Statische Beschreibung einer Menge möglicher Objekte
– Attribute: Struktur der Objekte
– Routinen: erlaubte Operationen auf Objekten
→ Features der Klasse
Einfaches Beispiel
class PERSON feature
name, vornamen: STRING;
geburtsjahr, todesjahr: INTEGER;
nationalität: STRING
end -- class PERSON
– Schlüsselworte class, feature, end
– Trennzeichen “;”
– Kommentaranfang “--”
Informatik I, Wintersemester 1993/94
77
Klassen und Objekte
Klassendefinition mit implizitem Verweis
class BUCH feature
autor: PERSON;
titel: STRING
erscheinungsdatum: INTEGER;
verlag: STRING;
anzahl seiten, kennung: INTEGER
end -- class BUCH
Attribute, deren Typ kein einfacher Datentyp ist,
beschreiben Verweise auf Objekte dieses Typs
einfache Typen: INTEGER, BOOLEAN, CHARACTER, REAL, DOUBLE
Informatik I, Wintersemester 1993/94
78
Klassen und Objekte
Kunden und Lieferanten
• Eine Klasse A heißt Kunde der Klasse B,
wenn A eine Deklaration der Form entity:B enthält.
B heißt in diesem Fall Lieferant von A
• Selbstreferenz ist möglich
class PERSON feature
name, vornamen: STRING;
geburtsjahr, todesjahr: INTEGER;
nationalität: STRING;
vater, mutter: PERSON
end -- class PERSON
• Zyklische Objektstrukturen sind erlaubt
Informatik I, Wintersemester 1993/94
79
Klassen und Objekte
Routinen
Wesentliche Dienstleistungen einer
Klasse
• Prozeduren können durch Ausführung einer Aktion
den Zustand eines Objektes ändern
• Funktionen berechnen Werte, die sich aus dem Zustand
der Objekte ergeben.
Informatik I, Wintersemester 1993/94
80
Klassen und Objekte
Aufruf von Routinen
Aufrufe von Funktionen, Prozeduren und Komponentenzugriffen
auf ein Objekt werden einheitlich in der
Punktnotation entity.operation(argumente) ausgedr ückt
Sei p Objekt der Klasse PERSON
• Komponentenzugriff: p.vornamen
= Komponente von p, die dem Attribut vornamen entspricht
• Funktion: p.anzahl vornamen
= berechnete Anzahl der Vornamen des Objektes p
• Funktion: p.alter(1993)
= berechnetes Alter der mit p bezeichneten Person im Jahre 1993
• Prozedur: p.setze todesjahr(1993)
Veränderung des Zustandes von p: die Komponente, welche dem Attribut
todesjahr entspricht wird auf 1993 gesetzt
Informatik I, Wintersemester 1993/94
81
Klassen und Objekte
Definition von Routinen
class PERSON feature
name, vornamen, nationalität: STRING;
geburtsjahr, todesjahr: INTEGER;
vater, mutter: PERSON;
anzahl vornamen: INTEGER is -- Anzahl der Vornamen bestimmen
do Result := Anzahl der Vornamen in vornamen
end; -- anzahl vornamen
alter(jahr:INTEGER): INTEGER is -- Alter im gegebenen Jahr bestimmen
do Result := jahr - geburtsjahr
end; -- alter
setze todesjahr(jahr:INTEGER) is -- todesjahr auf jahr setzen
do todesjahr := jahr
end -- setze todesjahr
end -- class PERSON
– Schlüsselwortfolge is...do...end
– Formale Argumente in Klammern: Namen:Typ
– Funktionen haben Ergebnistyp – Ergebnis in Result
– Rumpf: do anweisung1; anweisung2; ...;anweisungn end
Informatik I, Wintersemester 1993/94
82
Klassen und Objekte
Lokale Variablen
anzahl vornamen: INTEGER is
-- Anzahl der Vornamen bestimmen
local vornamen liste : ARRAY[STRING]
do vornamen liste := einzelne Vornamen aus vornamen
Result := Länge der Liste vornamen liste
end; -- anzahl vornamen
optionales Schlüsselwort local im Routinenrumpf
Nur bekannt innerhalb der Routine
Informatik I, Wintersemester 1993/94
83
Klassen und Objekte
Entities / Größen
Bezeichner für Objekte, die folgende Formen annehmen können
• ein Klassenattribut
• eine lokale Variable einer Routine
• ein formales Argument einer Routine
• Result – vordefinierte Größe für Funktionsergebnisse
Informatik I, Wintersemester 1993/94
84
Klassen und Objekte
Vordefinierte Operationen
!!entity
Standard-Erzeugung von Objekten
!!entity.init(argumente)
Nicht-Standard-Erzeugung von Objekten
entity := Ausdruck
Zuweisung (limitiert)
entity.attribut
(Komponenten)Zugriff (limitiert)
entity := Void
Auflösen eines Verweises
entity = Void
Überprüfung des Verweiszustandes
entity := clone(entity 1)
(Flache) Duplizierung von Objekten
entity := deep clone(entity 1) Tiefe Duplizierung von Objekten
entity.copy(entity 1)
(Flache) Kopie von Objektinhalten
entity.deep copy(entity 1)
Tiefe Kopie von Objektinhalten
entity 1 = entity 2
Vergleich von Objekten
equal(entity 1,entity 2)
(Flacher) Vergleich von Objektinhalten
deep equal(entity 1,entity 2)
Tiefer Vergleich von Objekten
Current
Verweis auf das aktuelle Objekt
Informatik I, Wintersemester 1993/94
85
Routinen
Vorkommen von Attributen
• Ist entity ein Attribut mit Klassentyp K, a ein Attribut
von K, dann bezeichnet entity.a die Komponente a des
Objektes, das zur Laufzeit mit entity verbunden ist
entity.a heißt qualifiziertes Vorkommen von a
• Unqualifiziertes Vorkommen von Attributen beschreibt
das aktuelle Exemplar der Klasse
• Wertzuweisungen nur an aktuelles Exemplar
• Externe (qualifizierte) Zugriffe nur über Dienstleistungen
• Selbstreferenz über die Funktion Current
Informatik I, Wintersemester 1993/94
86
Routinen
Klassendefinition mit Initialisierungsprozedur
class PERSON
creation
init mit namen
feature
.
.
init mit namen(n,v:STRING) is
-- Initialisiere Person
-- mit Vornamen und Namen
do
name := n;
vornamen := v
end; -- init mit namen
.
.
end -- class PERSON
Informatik I, Wintersemester 1993/94
87
Routinen
Geheimnisprinzip
• Interne Darstellung der Daten nach außen unsichtbar
• Direktes Lesen und Schreiben von Daten nicht erlaubt
Veränderung und Auswertung nur über prozedurale Schnittstellen
⇒ qualifizierte Vorkommen von Attributen sind Funktionen
⇒ Zuweisungen nur innerhalb der deklarierenden Klasse
⇒ nicht alle Attribute nach außen hin zugänglich
selektiver Export von Features möglich
– Angabe in geschweiften Klammern hinter feature
feature {Klasse1,...,Klassen} featurelist
Informatik I, Wintersemester 1993/94
88
Geheimnisprinzip
Klassendefinition mit Datenkapselung
class PERSON
creation init mit namen
feature{}
vornamen liste: STRING;
feature
init mit namen(n,v:STRING) is ... do ... end;
name: STRING;
vornamen: STRING is ... do ... end;
anzahl vornamen: INTEGER is ... do ... end;
geburtsjahr, todesjahr: INTEGER;
alter(jahr:INTEGER): INTEGER is ... do ... end;
setze todesjahr(jahr:INTEGER) is ... do ... end;
vater, mutter: PERSON;
geschwister: ARRAY[PERSON] is ... do ... end;
großeltern: ARRAY[PERSON] is ... do ... end;
nationalität: STRING
end -- class PERSON
Informatik I, Wintersemester 1993/94
89
Geheimnisprinzip
Selektiver Export von Features
class PERSON
creation init mit namen
feature
init mit namen(n,v:STRING) is ... do ... end;
name: STRING;
vornamen: STRING is ... do ... end;
anzahl vornamen: INTEGER is ... do ... end;
feature{EINWOHNERMELDEAMT}
geburtsjahr, todesjahr: INTEGER;
alter(jahr:INTEGER): INTEGER is ... do ... end;
vater, mutter: PERSON;
nationalität: STRING
feature{STANDESAMT}
setze todesjahr(jahr:INTEGER) is ... do ... end;
feature{EINWOHNERMELDEAMT, PERSON}
geschwister: ARRAY[PERSON] is ... do ... end;
feature{PERSON}
großeltern: ARRAY[PERSON] is ... do ... end;
feature{}
vornamen liste: STRING;
end -- class PERSON
Informatik I, Wintersemester 1993/94
90
Geheimnisprinzip
Referenz-Semantik von Eiffel
• a:=b ist Wertzuweisung, wenn a und b von einfachem Typ
• a:=b ist Verweiszuweisung – keine Objektzuweisung –
wenn a und b von Klassentyp
• a=b ist Wertevergleich zwischen Größen einfacher Typen
• a=b ist Vergleich der Verweise zwischen Größen von
Klassentypen.
⇒ Einfache Typen haben Copy-Semantik
⇒ Klassentypen haben Referenz-Semantik
Klassentypen können mit Copy-Semantik vereinbart werden
Informatik I, Wintersemester 1993/94
91
Copy- und Referenz-Semantik
Klassen mit Copy-Semantik
• Klassendefinition mit expanded
expanded class INTPAIR
feature
left, right: INTEGER
end -- class INTPAIR
• Attributdeklaration mit expanded
y: expanded PERSON
• Konvertierungsregeln für Zuweisungen und Vergleiche
zwischen Versionen expanded und nicht-expanded nötig
Informatik I, Wintersemester 1993/94
92
Copy- und Referenz-Semantik
Listenklassen
class INTLIST
creation new
feature
empty: BOOLEAN is -- Liste leer ?
do...end;
new is -- Erzeuge leere Liste
do...end;
cons(n:INTEGER) is -- Hänge n an
do...end;
head: INTEGER is -- Erstes Element
do...end;
tail is -- Entferne erstes
do...end
end -- class INTLIST
Informatik I, Wintersemester 1993/94
class REALLIST
creation new
feature
empty: BOOLEAN is -- Liste leer ?
do...end;
new is -- Erzeuge leere Liste
do...end;
cons(r:REAL) is -- Hänge n an
do...end;
head: REAL is -- Erstes Element
do...end;
tail is -- Entferne erstes
do...end
end -- class REALLIST
93
Generizität
Generische Klassendefinition
class LIST[X]
creation new
feature
empty: BOOLEAN is -- Ist die Liste leer ?
do...end;
new is -- Erzeuge leere Liste
do...end;
cons(r:X) is -- Hänge r vor die Liste
do...end;
head: X is -- Erstes Element
do...end;
tail is -- Entferne erstes Element
do...end
end -- class LIST[X]
• formale generische Parameter in eckigen Klammern
mehrere generische Parameter möglich
• Konkrete Deklaration von Attributen:
il: LIST[INTEGER]
personenlisten: LIST[LIST[PERSON]]
Informatik I, Wintersemester 1993/94
94
Generizität
Regeln für formale generische Parameter
Ist in einer Klassendeklaration X ein formaler generischer Parameter und x vom Typ
X, dann darf x nur benutzt werden
• als linke Seite einer Zuweisung x:=Ausdruck, wobei der Ausdruck der rechten
Seite ebenfalls vom Typ X sein muß
• als rechte Seite einer Zuweisung y:=x, wobei die Größe auf der linken Seite ebenfalls vom Typ X sein muß
• als aktuelle Argument im Aufruf einer Routine f(..,x,..), welches einem formalen Argument vom Typ X entspricht
(nur, wenn f innerhalb der gleichen Klasse wie x deklariert)
• in einem Booleschen Ausdruck der Form x=y oder x/=y (bzw. y=x oder y/=x),
wobei y vom Typ X sein muß
Informatik I, Wintersemester 1993/94
95
Generizität
Generische Klasse Felder (mit infix Deklaration)
class ARRAY[X]
creation make
feature
lower, upper, count: INTEGER;
make(min,max:INTEGER) is -- Erzeuge Feld mit Grenzen min und max
do...end;
item, infix "@" (i:INTEGER):X is -- Element mit Index i
do...end;
put(val:X,i:INTEGER) is -- Weise dem Element mit Index i
-- den Wert val zu
do...end;
.
.
end -- class ARRAY[X]
Infix-Bezeichner in ‘ ’ hinter Schlüsselwort infix nach Funktionsnamen
– erlaubt p := p array@17 statt p := p array.item(17)
Informatik I, Wintersemester 1993/94
96
Generizität
Verträge für Software-Zuverlässigkeit
• Sicherstellung von Korrektheit und Robustheit
– Garantien des Lieferanten für Benutzer einer Klasse
– Festlegung von Bedürfnissen und Verantwortlichkeiten
• Spezifikationselemente in der Implementierung sinnvoll
– Eiffel Gegenstück zu Axiomen in abstrakten Datentypen
⇒ Zusicherungen (assertions)
– Ausdruck über Zweck von Klassen, Routinen, oder Anweisungen
– während der Laufzeit überwachbar
– Dokumentation, Strukturierungs- und Verifikationshilfe
Informatik I, Wintersemester 1993/94
97
Assertions
Bestandteile der Zusicherungssprache
• Erreichbare Funktionen und Attribute, formale Argumente, Result, Kommentare
(keine Prozeduren, keine lokalen Variablen)
• Boolesche Ausdrücke (einschließlich Arithmetik)
Eiffel
logischer Operator
and
or
and then
or else
not
xor
implies
Konjunktion ∧
Disjunktion ∨
Sequentielle Konjunktion ∧
Sequentielle Disjunktion ∨
Negation ¬
Exklusive Disjunktion ∨˙
Implikation ⇒
• Semikolon zur Trennung nicht zusammengehöriger Bestandteile
n>0 ; not x=Void
• Namen für zusammengehörige Bestandteile
Positiv: n>0 ; Nichtleer: not x=Void
• old: Wert bei Eintritt in eine Routine (nur in Nachbedingungen)
Informatik I, Wintersemester 1993/94
98
Assertions
Vor- und Nachbedingungen
Beschreibung semantischer Eigenschaften von Routinen
• Vorbedingung: was muß beim Aufruf der Routine gelten?
– muß bei jedem Aufruf erfüllt sein
Schlüsselwort require vor der Anweisungsfolge
• Nachbedingung: was gilt nach Beendigung der Routine?
– Garantie im Falle eines korrekten Aufrufs
Schlüsselwort ensure direkt vor dem end
Informatik I, Wintersemester 1993/94
99
Assertions
Klassendefinition mit Vor- und Nachbedingungen
class ARRAY[X]
creation make
feature
lower, upper, count: INTEGER;
make(min,max:INTEGER) is -- Erzeuge Feld mit Grenzen min und max
do...
ensure max<min implies count = 0;
max >= min implies lower = min and upper = max;
max >= min implies count = max - min + 1
end; -- make
item, infix "@" (i:INTEGER):X is -- Element mit Index i
require lower <=i; i <= upper
do...end; -- item
put(val:X,i:INTEGER) is -- Weise val dem Element mit Index i zu
require lower <=i; i <= upper
do...
ensure item(i)=val
end; -- put
.
.
end -- class ARRAY[X]
Informatik I, Wintersemester 1993/94
100
Assertions
Nachbedingung mit old
Ist a ein Attribut, dann bezeichnet in Nachbedingungen old a den Wert der entsprechenden Objektkomponente beim Aufruf und jedes andere Vorkommen von a den Wert
bei Beendigung der Routine
resize(min,max:INTEGER) is
-- Erweitere Feld auf Grenzen min und max
do...
ensure
upper >= old upper;
lower <= old lower
end; -- resize
Informatik I, Wintersemester 1993/94
101
Assertions
Vor- und Nachbedingungen als Vertrag
require und ensure beschreiben Rechte und Pflichten
• Vorbedingung bindet den Kunden:
– die Routine wird nur in erlaubten Fällen benutzt
– andernfalls ist der Lieferant zu nichts verpflichtet
• Nachbedingung bindet Lieferantenklasse
– Kunde kann sich auf versprochene Leistung verlassen
(falls die Vorbedingung eingehalten wurde)
– macht Verifikation von Routinen notwendig
• Vertrag erspart überflüssige Kontrollen
– Genauigkeit abhängig von Vertrauen
und Vielfalt der Anwendungsgebiete
Informatik I, Wintersemester 1993/94
102
Assertions
Klasseninvarianten
Beschreibung globaler Eigenschaften von Objekten
Invariante: unveränderliche Eigenschaft der Klasse selbst
– muß in jedem “stabilen” Zustand erfüllt sein
Schlüsselwort invariant am Ende der Klassendeklaration
Zusicherung I ist genau dann eine korrekte Klasseninvariante einer Klasse C, wenn
eine der beiden folgenden Bedinungen erfüllt ist
• I gilt nach jedem Aufruf einer Erzeugungsprozedur von C mit Argumenten,
welche die Vorbedingungen erfüllen.
• I gilt nach jedem Aufruf einer exportierten Routine mit Argumenten, welche die
Vorbedingungen erfüllen, die auf Objekte angewandt wurde, welche I erfüllen.
Informatik I, Wintersemester 1993/94
103
Assertions
class ARRAY[X]
creation make
feature
lower, upper, count: INTEGER;
make(min,max:INTEGER) is -- Erzeuge Feld mit Grenzen min und max
do...
ensure max<min implies count = 0;
max >= min implies lower = min and upper = max
end; -- make
item, infix "@" (i:INTEGER):X is -- Element mit Index i
require lower <=i; i <= upper
do...end; -- item
put(val:X,i:INTEGER) is -- Weise val dem Element mit Index i zu
require lower <=i; i <= upper
do...
ensure
item(i)=value
end; -- put
resize(min,max:INTEGER) is -- Erweitere Feld auf min und max
do...
ensure
upper >= old upper; lower <= old lower
end; -- resize
.
.
invariant
nonnegative size: count >= 0;
consistent size: count = upper - lower + 1
end -- class ARRAY[X]
Informatik I, Wintersemester 1993/94
104
Assertions
Unvollständige Zusicherungen
class LIST[X]
creation new
feature
empty: BOOLEAN is -- Ist die Liste leer ?
do...end;
new is -- Erzeuge leere Liste
do...
ensure empty
end; -- new
cons(r:X) is -- Hänge r vor die Liste
do...
ensure not empty; head = r
-- tail würde jetzt old liefern
end; -- cons
head: X is -- Erstes Element
require not empty
do...end; -- head
tail is -- Entferne erstes Element
do...
ensure old empty implies empty
end -- tail
end -- class LIST[X]
Informatik I, Wintersemester 1993/94
105
Assertions
VERERBUNG
• Konzeptionelle Beziehung zwischen Klassen:
– Spezialisierung eines Konzepts (Erben)
– Generalisierung eines Konzepts (Vorfahren)
– Kombination von Konzepten (Mehrfachvererbung)
• Nachkommen erben Rechte und Pflichten der Eltern
– Unqualifizierter Aufruf geerbter features
– Modifikation geerbter features möglich
– Kontrakte der Vorfahren sind einzuhalten
• Vererbung ist transitiv
Steigert Erweiterbarkeit und Wiederverwendbarkeit
Informatik I, Wintersemester 1993/94
106
Vererbung
Vererbung: Modifikation geerbter features
• Änderung des Export-Status
• Redefinition
• Umbenennung
• Vervielfältigung und Selektion bei wiederholtem Erben
• Erweiterung von Zusicherungen
Informatik I, Wintersemester 1993/94
107
Vererbung
Vererbung: Neue Möglichkeiten
• Polymorphismus
• Dynamisches Binden
• Deklaration durch Assoziation
• Deferred Classes
• Kombination von Klassen
Informatik I, Wintersemester 1993/94
108
Vererbung
Klassendefinition mit Vererbung
class ENTLEIHER
inherit PERSON
feature
straße, hausnummer, stadt: STRING;
postleitzahl : INTEGER;
ausweisnummer: INTEGER
end -- class ENTLEIHER
----------------------------------------------------------• ENTLEIHER ist Erbe (Nachkomme) von PERSON
PERSON ist Vorfahr von ENTLEIHER
• Elternklassen nach Schlüsselwort inherit
• Features der Elternklasse automatisch verfügbar
Spezifische features werden ergänzt
• Initialisierungsprozedur muß neu vereinbart werden
Informatik I, Wintersemester 1993/94
109
Vererbung
Vererbung als Diagramm
'
$
PERSON
$
'
*
&
Y
H
H %
HH
HH
HH
ENTLEIHER
&
'
H
H
$
ARBEITNEHMER
%
&
%
ENTLEIHER und ARBEITNEHMER erben von PERSON
Informatik I, Wintersemester 1993/94
110
Vererbung
Export geerbter features
class ENTLEIHER
inherit PERSON
export
name, vornamen, geburtsdatum
end -- feature-Anpassung von PERSON
feature
straße, hausnummer, stadt: STRING;
postleitzahl : INTEGER;
ausweisnummer: INTEGER
end -- class ENTLEIHER
-----------------------------------------------------------
• Schlüsselwort export
• Schlüsselwort end beendet Modifikationen geerbter features
• Ohne export-Klausel gilt alter Export-Status
Informatik I, Wintersemester 1993/94
111
Vererbung
Selektiver Export geerbter features
class ARBEITNEHMER
inherit PERSON
export
{ARBEITGEBER} name, vornamen, geburtsjahr;
{FINANZAMT} all
end -- feature-Anpassung von PERSON
feature
adresse: ADRESSEN;
gehaltsklasse: STRING;
gehalt: REAL is -- Gehalt berechnen
do Result := Gehalt aus Tabelle nach gehaltsklasse end
end -- class ARBEITNEHMER
-------------------------------------------------------------Syntax ähnlich wie bei feature-Klausel
export
{ Klassenliste1} featurelist 1;
.
.
{ Klassenlisten} featurelist n
Informatik I, Wintersemester 1993/94
112
Vererbung
Vererbungsregeln I
• Regel der Featureanwendung:
Ist eine Größe entity vom Klassentyp K, so ist die Anwendung entity.f eines
feature f nur dann zulässig, wenn f in einem Vorfahren von K definiert wurde.
• Regel des selektiven Exports:
Ein an eine Klasse K selektiv exportiertes feature f darf in allen Nachkommen
von K benutzt werden.
Informatik I, Wintersemester 1993/94
113
Vererbung
Vererbung mit Redefinition
class UNI-ANGESTELLTE
inherit ARBEITNEHMER
redefine
gehalt
export
{ARBEITGEBER} name, vorname, geburtsjahr, adresse, gehaltsklasse;
{FINANZAMT} all
end -- feature-Anpassung von ARBEITNEHMER
feature
universität: STRING;
fachbereich, raum, telephon: INTEGER;
gehalt: REAL is -- Gehalt berechnen
do Result := Gehalt nach Alter und gehaltsklasse end
end -- class UNI-ANGESTELLTE
--------------------------------------------------------------------• Schlüsselwort redefine benennt neudefinierte features
• Schlüsselwort all zur Abkürzung
• Typdeklarationen und Zusicherungen beachten!
Informatik I, Wintersemester 1993/94
114
Vererbung
Vererbungsregeln II
Regel der Redefinition:
Ein Attribut, Funktionsergebnis oder formales Routinenargument darf in einer
Erbenklasse mit einem neuen Typ redeklariert werden, wenn der neue Typ
konform zum ursprünglichen ist.
Das Attribut oder die zugehörige Routine gilt als redefiniert.
Der Rumpf einer Routine kann redefiniert werden, solange die obige
Typeinschränkung nicht verletzt wird. Parameterlose Funktionen dürfen als
Attribute redefiniert werden.
Redefinierte features, die nicht ursprünglich deferred waren, müssen in einer
entsprechenden redefine Klausel aufgeführt werden.
Informatik I, Wintersemester 1993/94
115
Vererbung
Konformität
B ist konform zu A, wenn eine der folgenden Bedingungen erfüllt ist
1. A und B sind identisch,
2. A ist von der Form expanded B oder B ist von der Form expanded A,
3. A ist REAL oder DOUBLE und B ist INTEGER oder REAL,
4. A ist eine Klasse ohne generische Parameter und B ist eine Klasse, die A in der
inherit-Klausel aufführt,
5. A hat die Form G[A1, ..An] und B hat die Form G[B1, ..Bn], wobei G eine generische Klasse ist und jedes der Bi zu Ai konform ist,
6. B hat die Form like anchor und der Typ von anchor ist konform zu A,
7. Es gibt einen Typen C mit der Eigenschaft, daß A konform ist zu C und C konform
zu B.
Informatik I, Wintersemester 1993/94
116
Vererbung
Polymorphismus
Fähigkeit, verschiedene Formen anzunehmen
Professorenobjekt
k
Q
Q
Q
Q
Studentenobjekt
K
A
A
Q
Q
benutzerliste
Q
Q
Q
Q
Q
Q
Q
Q
Q
Q
Q
A
A
A
A
Q
A
A
A
A
A
A
Mitarbeiterobjekt
Professorenobjekt
-
Keine Konvertierung nötig
Informatik I, Wintersemester 1993/94
117
Vererbung
3
Vererbungsregeln III
• Regel der Typverträglichkeit:
Eine Zuweisung der Form x:=y, wobei x vom Typ A und y vom Typ B ist, ist
nur dann zulässig, wenn B konform zu A ist.
Gleiches gilt für den Aufruf einer Routine mit formalem Parameter x und
aktuellem Parameter y, wobei x vom Typ A und y vom Typ B ist. Der Aufruf ist
nur dann zulässig, wenn B konform zu A ist.
• Regel des Dynamischen Bindens:
Ist x vom Klassentyp A und r eine in A deklarierte Routine, dann wird ein
Routinenaufruf der Form x.r an die Implementierung gebunden, welche
innerhalb der Klasse definiert wurde, zu der das mit x zur Laufzeit verbundene
Objekt gehört.
Informatik I, Wintersemester 1993/94
118
Vererbung
Deklaration durch Assoziation
class ARRAY[X]
.
.
put(val:like item,i:INTEGER)
is -- Weise val dem Element mit Index i zu
require lower <= i; i <= upper
do...
ensure
item(i)=val
end; -- put
.
.
end -- class ARRAY[X]
----------------------------------------------------------------
• Binde Typ einer Größe an den einer anderen (Anker)
• Syntax der Deklaration: entity: like anchor
• Möglichkeiten für anchor:
– Attribut, Funktion, formales Routinenargument, Current
Informatik I, Wintersemester 1993/94
119
Vererbung
Aufgeschobene (deferred) Klassen
• Klassen mit (evtl. geerbten) nichtausführbaren Routinen
– Routinendeklaration enthält Schlüsselwort deferred
anstelle des Anweisungsteils
– Klasse muß als deferred class deklariert werden
• Eiffel-Gegenstück zum abstrakten Datentyp
– Leistungen werden spezifiziert, aber nicht implementiert
– Spezielle Implementierung in Erbenklassen
• Anwendungen:
– Abstrakter Entwurf und Verfeinerung in Eiffel
– partielle Implementierungen
– Ersatz für Prozedurparameter in Routinen
– Oberklasse für Klassen mit konzeptionellen Gemeinsamkeiten
polymorphe Anwendung gleichartiger Routinen
Informatik I, Wintersemester 1993/94
120
Vererbung
Aufgeschobene Klasse von Listen
deferred class LIST[X]
feature
length: INTEGER;
empty: BOOLEAN is -- Ist die Liste leer ?
do length=0 end;
new is -- Erzeuge leere Liste
deferred
ensure empty
end; -- new
cons(r:X) is -- Hänge r vor die Liste
deferred
ensure not empty; head = r -- tail würde old liefern
end; -- cons
head: X is -- Erstes Element
require not empty
deferred end; -- head
tail is -- Entferne erstes Element
deferred
ensure old empty implies empty
end -- tail
invariant nonnegative size: size >= 0
end -- class
LIST[X]
Informatik I, Wintersemester 1993/94
121
Vererbung
Vererbungsregeln IV
• Regel der Nicht-Erzeugung aufgeschobener Klassen:
Auf Größen, deren Typ eine aufgeschobene Klasse ist, darf keine
Initialisierungsprozedur angewandt werden.
• Regel der Feature-Umbenennung:
Features, die in einer rename-Unterklausel umbenannt wurden, können in
export- und redefine-Klauseln nur unter ihrem neuen Namen angesprochen
werden.
Informatik I, Wintersemester 1993/94
122
Vererbung
Mehrfachvererbung: Realisierung einer deferred class
class FIXED LIST[X]
inherit LIST[X];
ARRAY[X] export {} all
creation new
feature
-- Bereits effektiv deklariert: length: INTEGER;
-empty: BOOLEAN
new is -- Erzeuge leere Liste
do make(1,0); length:=0
end; -- new
cons(r:X) is -- Hänge r vor die Liste
do if length = upper then resize(1,length+1) end;
length := length+1;
put(r,length)
end; -- cons
head: X is -- Erstes Element
do Result := item(length)
end; -- head
tail is -- Entferne erstes Element
do if length/=0 then length:=length-1 end
end -- tail
end -- Informatik
classI, LIST[X]
Wintersemester 1993/94
123
Vererbung
Namenskonflikt
class STUDENT
feature
universität: STRING;
fachbereich: INTEGER;
matrikelnummer: INTEGER
end -- class STUDENT
class HILFSKRAFT
inherit
UNI-ANGESTELLTE
.
.
end; -- feature-Anpassung von UNI-ANGESTELLTE
STUDENT
.
.
end; -- feature-Anpassung von STUDENT
feature
.
.
end -- class HILFSKRAFT
– Feature fachbereich erscheint doppelt
– Mehrfachvererbungen mit Namenskonflikten sind verboten
⇒ Umbenennung nötig
Informatik I, Wintersemester 1993/94
124
Vererbung
Umbenennung
class HILFSKRAFT
inherit
UNI-ANGESTELLTE
redefine
gehalt
export
name, vornamen, adresse, gehalt
end; -- feature-Anpassung von UNI-ANGESTELLTE
STUDENT
rename
fachbereich as studienfachbereich
export
universität, studienfachbereich
end -- feature-Anpassung von STUDENT
feature
monatsstunden: INTEGER;
gehalt: REAL is -- Gehalt berechnen
do Result := Festgehalt nach monatsstunden end
end -- class HILFSKRAFT
Informatik I, Wintersemester 1993/94
125
Vererbung
Vererbungsregeln V
• Regel des wiederholten Erbens:
Bei wiederholtem Erben wird jedes feature des gemeinsamen Vorfahren als
gemeinsam genutzt (shared) angesehen, wenn es auf dem gesamten
Vererbungspfad nicht umbenannt wurde.
Features, die auf mindestens einem Wege umbenannt wurden, werden als
vervielfältigt (replicated) angesehen.
• Regel der Generizität bei wiederholtem Erben:
Bei wiederholtem Erben darf der Typ eines gemeinsam genutzten features in der
Elternklasse kein generischer Parameter sein.
Eine gemeinsam genutzte Routine darf in der Elternklasse keine formalen
Argumente enthalten, deren Typ ein generischer Parameter ist.
Informatik I, Wintersemester 1993/94
126
Vererbung
Vererbungsregeln VI
• Regel der Umbenennung:
In einer Klasse K tritt ein Namenskonflikt auf, wenn zwei Eltern E1 und E2
von K ein feature mit demselben Namen f enthalten.
Ein Namenskonflikt ist erlaubt, wenn f in einem gemeinsamen Vorfahren V von
E1 und E2 erstmalig definiert wurde, auf keinem Vererbungspfad von V nach
E1 und nach E2 umbenannt wurde und in seiner Typdeklaration nicht an
generische Parameter von V gebunden ist.
Nicht erlaubte Namenskonflikte müssen durch Umbenennung aufgelöst werden.
Informatik I, Wintersemester 1993/94
127
Vererbung
Vererbungsregeln VII
• Regel der Elterninvarianten:
Die Invarianten aller Eltern einer Klasse gelten für die Klasse selbst.
• Regel der Zusicherungsredefinition:
Ist r eine Routine der Klasse K und s eine Redefinition von r in einem Nachkommen
von K, so müssen die Vorbedingungen von s schwächer sein als die von r und die
Nachbedingungen stärker.
– Fehlt in einer redefinierten Routine Vor- oder Nachbedingung, so wird die Vorbzw. Nachbedingung der ursprünglichen Version übernommen.
– Vorbedingungen können nur durch eine require else-Klausel abgeschwächt werden.
– Nachbedingungen können nur durch eine ensure then-Klausel verstärkt werden.
Informatik I, Wintersemester 1993/94
128
Vererbung
Kriterien für gute Entwurfsmethoden
Zerlegbarkeit in Module
Zusammensetzbarkeit aus Modulen
Verständlichkeit der Module
Stetigkeit der Module
Modularer Schutz
Eiffel unterstützt diese Kriterien
Informatik I, Wintersemester 1993/94
129
Entwurfsmethodik
Entwurfsprinzipien
Moduln müssen Klassen entsprechen
– fördert Verständlichkeit und Kombinierbarkeit
Minimale Kommunikation zwischen Moduln
– fördert Stetigkeit
Schmale Schnittstellen
– fördert Stetigkeit und modularen Schutz
Vollständige Beschreibung der Schnittstellen
– fördert Zerlegbarkeit, Kombinierbarkeit, Verständlichkeit, Stetigkeit
Geheimnisprinzip
– fördert Stetigkeit und modularen Schutz
Informatik I, Wintersemester 1993/94
130
Entwurfsmethodik
Analyse und Gestaltung
Entwurf von Softwaresystemen
= Gesetzmäßigkeiten des Umfelds entdecken
+ Modell eines Ausschnitts der Realität gestalten
Entwurfsphasen
– Grobspezifikation
Analyse der nach außen sichtbaren Leistungen
– Feinspezifikation
Zerlegung des Systems in unabhängige interne Komponenten
Einfallsreichtum, Erfahrung, Training erforderlich
Informatik I, Wintersemester 1993/94
131
Entwurfsmethodik
Grundideen des objektorientierten Entwurfs
dezentrale Architektur
überschaubare, unabhängige, gleichberechtigte Einheiten
• Klassen sind der einzige Strukturierungsmechanismus
– keine Schachtelung von Klassen
– Unabhängigkeit (nur Benutzung und Vererbung)
• Dienstleistungen werden gleichermaßen bereitgestellt
– keine Operationen mit höherer oder niedriger Bedeutung
– keine Vorschriften über Reihenfolge des Aufrufs
• Keine Beschränkung der Anzahl der Dienstleistungen
• Bottom-up Entwurf sinnvoll
– Aktivierung fertiger Programmteile anstreben
– Neue Klassen allgemein genug gestalten
• Zentralistisches Denken ablegen
Informatik I, Wintersemester 1993/94
132
Entwurfsmethodik
Wie sinnvolle Klassen identifizieren?
• Lerne, vorhandene Entwürfe zu analysieren
– Stärken und Schwächen beurteilen
– Erfahrungen für eigene Entwürfe sammeln
– Teamarbeit: Brainstorming und Kritik
– Selbst Vorschläge machen und kritisieren lassen
• Für Routineprobleme Eiffel-Bibliotheken durchforsten
• Klassen an externen Objekten orientieren
– Daten, die sich nicht ändern, sind keine Objekte
– Unnötige Klassen vermeiden
Informatik I, Wintersemester 1993/94
133
Entwurfsmethodik
Schnittstellentechniken
• Strikte Trennung von Prozeduren und Funktionen
– Funktionen sollen nur Werte berechnen
– Seiteneffekte in Funktionen vermeiden
• Datenbehälter aktiv gestalten
– mehr als nur Sammlungen von Information
– selbständig arbeitender Betrieb (z.B. durch einen Cursor)
• Eine Schnittstelle für mehrere Implementierungen
– Schnittstelle im Oberbegriff
– spezielle Implementierungen in Erbenklassen
• Mehrere Schnittstellen für eine Implementierung
– Implementierung im (geheimen) Oberbegriff
– Verschiedene Schnittstellen für verschiedene Sichten
Informatik I, Wintersemester 1993/94
134
Entwurfsmethodik
Vererbungstechniken
Vererbung gezielt einsetzen
• Vererbung beschreibt Spezialfälle der Elternklasse
– In anderen Fällen Benutzung über Schnittstellen verwenden
– Ausnahmen von dieser Regel können sinnvoll sein
• Verallgemeinerungen erzeugen
– von Hand durch Editieren des Spezialfalls
– in spezielleren Klassen Erbklausel mit Redefinition einfügen
• Redefinition
– falls für Erbenklasse effizientere Implementierung verfügbar
– Redefinition von Funktionen als Attribute sorgfältig abwägen
– Semantik der redefinierten Routine muß erhalten bleiben
Informatik I, Wintersemester 1993/94
135
Entwurfsmethodik
Bibliothekenverwaltung: Analyse I
• Bücher
– haben Autor, Titel, Themengebiet und Kennung
– sind entleihbar, Präsenzexemplar, Semesterapparat oder ausgeliehen
– Ausleihdaten: letztes Ausleihdatum, Ausleihfrist, Rückgabedatum
– Ein Buch gehört zu genau einer Bibliothek
– Eine Bibliothek kann mehrere Exemplare eines Buchs
(mit verschiedenen Kennungen) haben
..
– Mehrere Bibliotheken können das gleiche Buch enthalten.
• Entleiher
– können entleihbare Bücher aus einer Bibliothek entnehmen,
deren Bibliotheksausweis sie besitzen
– können Bücher zu einer Bibliothek zurückbringen
Informatik I, Wintersemester 1993/94
136
Entwurfsmethodik
Bibliothekenverwaltung: Analyse II
• Ausleihe
– Bücher werden nach Autor und Titel ausgeliehen
– Bücher können an Entleiher ausgeliehen werden, wenn
∗ der Entleiher eine Bibliotheksausweis der Bibliothek besitzt
∗ die Bibliothek ein ausleihbares Exemplar besitzt
– Bücher können an Universitätsangestellte ausgeliehen werden, wenn
∗ der Universitätsangestellte Zugang hat
∗ die Bibliothek ein ausleihbares Exemplar oder ein Präsenzexemplar besitzt.
– Ausleihdatum und die Ausleihfrist werden vermerkt
– Leihfrist: 4 Wochen nach Entleihdatum
..
..
..
– Leihfrist für Hochschullehrer: ein Semester nach Entleihdatum
Informatik I, Wintersemester 1993/94
137
Entwurfsmethodik
Bibliothekenverwaltung: Klassen des Systems
• Selbständig agierenden Objekte der realen Welt
– Bibliotheken, Bücher, Entleiher,
– Mitarbeiter, Universitätsangestellte, Hochschullehrer
• Vorgesehene Erweiterung
– Autoren
• Wurzelklasse
– Verwaltung
• Transaktionen müssen eigenständige Klassen sein
– Ausleihe, Verlängern, Rückgabe, Entnahme, Hinzufügen
Informatik I, Wintersemester 1993/94
138
Entwurfsmethodik
Bibliothekenverwaltung: Verarbeitungsstruktur
Start: Informationen über bekannte Objekte werden geladen
• Anwender wählt Transaktion im Menü der Verwaltung
• Verwaltung bildet Transaktionsobjekt der entsprechenden Klasse, wobei
Entleiher interaktiv bestimmt wird
• Transaktionsobjekt veranlaßt Entleiher, Transaktion bei Bibliothek zu
beantragen
• Entleiher beantragt Transaktion zu der er berechtigt ist
• Bibliothek bestimmt Transaktionsdaten und löst im konkreten Buch Eintragen
der Daten aus
• Wiederholung bis Anwender beendet
Ende: Informationen werden gesichert
Informatik I, Wintersemester 1993/94
139
Entwurfsmethodik
Bibliothekenverwaltung:
Leistungen von BIB VERWALT
Dienstleistung
Kunde
bestehende Objekte laden
Start
Datum anpassen
Start
Ständige Benutzerinteraktion initiieren
Start
Bibliothek auswählen
Anwender
Transaktion auswählen und auslösen
Anwender
Datum verändern
Anwender
bestehende Objekte sichern
Ende
Datum mitteilen
BIBLIOTHEK
Informatik I, Wintersemester 1993/94
140
Entwurfsmethodik
Bibliothekenverwaltung:
Leistungen von TRANSAKTION und Erben
Klasse
Dienstleistung
Kunde
TRANSAKTION
Transaktion durchführen (deferred)
BIB VERWALT
Entleihername eingeben
Anwender
AUSLEIHE
Transaktion erzeugen mit Bibliothek
BIB VERWALT
Erbe
Transaktion durchführen
BIB VERWALT
VERLÄNGERN
Transaktion erzeugen mit Bibliothek
BIB VERWALT
Erbe
Transaktion durchführen
BIB VERWALT
RÜCKGABE
Transaktion erzeugen mit Bibliothek
BIB VERWALT
Erbe
Transaktion durchführen
BIB VERWALT
ENTNAHME
Transaktion erzeugen mit Bibliothek
BIB VERWALT
Erbe
Transaktion durchführen
BIB VERWALT
HINZUFÜGEN
Transaktion erzeugen mit Bibliothek
BIB VERWALT
Erbe
Transaktion durchführen
BIB VERWALT
Informatik I, Wintersemester 1993/94
141
Entwurfsmethodik
Bibliothekenverwaltung:
Leistungen von BIBLIOTHEK
Dienstleistung
Kunde
Entleihbares Buch ausleihen
ENTLEIHER
Entleihbares Buch oder Präsenzexemplar ausleihen
UNI ANG
Entleihbares Buch oder Präsenzexemplar an Professoren ausleihen
PROFESSOR
Leihfrist verlängern
ENTLEIHER
Leihfrist für Professoren verlängern
PROFESSOR
Buch zurücknehmen
RÜCKGABE
Buch entnehmen
MITARBEITER
Buch hinzufügen
MITARBEITER
Autorname, Titel, Themengebiet oder Kennung eingeben
Anwender
Entleiher nach Namen bestimmen
TRANSAKTION
(und Erben)
Informatik I, Wintersemester 1993/94
142
Entwurfsmethodik
Implementierung zuverlässiger Programme
• Verträge erlauben bei Implementierung lokale Sicht
– nur Vor- und Nachbedingungen und Invarianten zu beachten
• Verträge müssen eingehalten werden
– ansonsten keine Aufteilung der Verantwortung möglich
⇒ Wie zuverlässige Routinen implementieren?
– Programmkonstrukte kennen und verstehen
– Zuweisung, Fallunterscheidung, Schleifen, Prozeduren ...
– elementare Ausdrücke kennen
– Konstrukte einsetzen und Korrektheit beweisen lernen
Die Korrektheit von Programmen
kann nicht mit Programmabläufen geprüft werden
Informatik I, Wintersemester 1993/94
143
Verifikation
Korrektheit von Routinen und Klassen
Ergänze Implementierung um logische Bestandteile
.
.
is -require pre
do
Anweisung1;
Anweisung2;
.
.
Anweisungn
ensure post
end
Informatik I, Wintersemester 1993/94
{ pre}}
{ Aussage1}
{ Aussage2}
{ post}}
144
Verifikation
{ pre}} instruction { post}}
Satz des Hoare-Kalküls für Programmbeweise
– für pre und post sind Ausdrücke der Prädikatenlogik
erlaubt, ergänzt um die Zusicherungssprache von Eiffel.
instruction muß eine korrekte Eiffel Anweisung sein
– ist wahr genau dann, wenn pre eine Vorbedingung dafür
ist, daß instruction terminiert und danach post gilt.
(totale Korrektheit)
Informatik I, Wintersemester 1993/94
145
Verifikation
Korrektheit von Routinen
Eine Routine r heißt genau dann (total) korrekt,
wenn für alle gültigen Argumente xr der Satz
{ prer (xr )}} Br { postr (xr )}}
ein wahrer Satz des Kalküls für Programmbeweise ist.
prer : Vorbedingung von r
postr : Nachbedingung von r
Br : Anweisungsteil (Body) von r
gültige Argumente von r: Werte, die für formale Argumente unter Einhaltung
der Typbedingungen eingesetzt werden dürfen
Informatik I, Wintersemester 1993/94
146
Verifikation
Korrektheit von Klassen
Klasse K mit Invariante INV heißt korrekt, wenn
1. Für jede exportierte Routine r von K
und alle gültigen Argumente xr ist
{ INV
∧
prer (xr )}} Bi { INV
∧
postr (xr )}}
ein wahrer Satz des Kalküls für Programmbeweise.
2. für jede Initialisierungsprozedur i von K
und alle gültigen Argumente xi gilt
{ DefaultK
∧
prei(xi)}} Br { INV
∧
posti(xi)}}
DefaultK : Zusicherung, daß alle Attribute von K
die Initialwerte ihrer Typen tragen
Informatik I, Wintersemester 1993/94
147
Verifikation
Kalkül für Verifikation
• Beweisführung = Anwendung syntaktischer Regeln
• ermöglicht neutrale Prüfung der Korrektheit (Software-TÜV)
• Schrittweise Argumentation über Einzelanweisungen
– Suche “schwache” Vorbedingung zu Nachbedingung und Anweisung
• Prädikatentransformation wp (weakest precondition)
∧
{ wp(instruction,post)}} instruction { post}}
{ pre}} instruction { post}} ⇒ (pre ⇒ wp(instruction,post))
– Manchmal unhandlich wegen Quantoren (liefert aber Vorschlag)
• Bisher nur für Copy-Semantik
Informatik I, Wintersemester 1993/94
148
Verifikation
Einfache Regeln für Programmbeweise
Verstärkung der Vorbedingung (VV)
pre ⇒ pre’, { pre’}} instruction { post}}
{ pre}} instruction { post}}
Abschwächung der Nachbedingung (AN)
{ pre}} instruction { post’}} , post’ ⇒ post
{ pre}} instruction { post}}
Kombination der Vorbedingungen
{ pre}} instruction { post}} , { pre’}} instruction { post}}
{ pre ∨ pre’}} instruction { post}}
Kombination der Nachbedingungen
{ pre}} instruction { post}} , { pre}} instruction { post’}}
{ pre}} instruction { post ∧ post’}}
Informatik I, Wintersemester 1993/94
149
Verifikation
Strukturierung von Routinen
• Zuweisung
• Routinenaufruf (qualified call)
• Zusammengesetzte Anweisungen
• Bedingte Anweisung und Fallunterscheidung (if, inspect)
• Schleife (loop)
• Überprüfung während eines Programmablaufs (check)
• Ausnahmebehandlung (rescue und retry)
• Zusätzliche Anweisungen für DEBUG (debug)
Informatik I, Wintersemester 1993/94
150
Verifikation
Wertzuweisung:
Verifikationsregel und Prädikatentransformer
{ P(Ausdruck}}
entity := Ausdruck
{ P(entity)}}
wp(entity := Ausdruck , P(entity) ) ≡ P(Ausdruck)
Informatik I, Wintersemester 1993/94
151
Verifikation
Geschützte formale Argumente von Routinen
Formalen Argumente einer Routine dürfen innerhalb des
Anweisungsteils nicht direkt verändert werden
direkte Veränderung von yi:
• Wertzuweisung der Form yi:=Ausdruck
• Veränderung des in yi enthaltenen Verweises
durch Aufruf von Initialisierungsprozeduren
Informatik I, Wintersemester 1993/94
152
Verifikation
Lokale und entfernte Routinenaufrufe
• Ein lokaler Aufruf bezieht sich auf das aktuelle Exemplar:
(ohne Argumente)
r
(mit Argumenten).
r(A1,...,An)
• Ein entfernter Aufruf wird auf ein Objekt angewandt, das
durch einen beliebigen Ausdruck dargestellt werden darf:
(einfach, ohne Argumente)
entity.r
(durch Funktion, ohne Argumente)
f(a).r
g(f(a)).h(b,x).z.r(A1 ,...,An)
(mehrstufig geschachtelt mit Argumenten).
Mehrstufig qualifizierter Aufruf u.v.r ist Abkürzung für x:=u.v ; x.r
Informatik I, Wintersemester 1993/94
153
Verifikation
Verifikationsregeln für Prozeduraufrufe
Für eine korrekte Prozedur r mit formalen Argumenten yr und
abstrakten Vor- und Nachbedingungen prer bzw. postr gilt
{ prer (Ar ,entity)}} entity.r(Ar ) { postr (Ar ,entity)}}
wp(entity.r(Ar ), postr (Ar ,entity)) ≡ prer (Ar ,entity)
Bei unqualifizierten Aufrufen wird Current für entity eingesetzt und der Ausdruck vereinfacht.
Prozedur r(y1:T1,...,yn:Tn) is do ... end hat
– abstrakte Vorbedingungen prer (y1,...,yn, actual)
– abstrakte Nachbedingungen postr (y1,...,yn, actual)
Informatik I, Wintersemester 1993/94
154
Verifikation
Verifikationsregel für Funktionsaufrufe
Für eine korrekte Funktion f mit formalen Argumenten yf
und abstrakten Vor- und Nachbedingungen pref bzw. postf
gilt
pref (Af , entity) ⇒ postf (Af , entity, entity.f(Af ))
Bei unqualifizierten Aufrufen wird Current für entity eingesetzt und der Ausdruck
vereinfacht.
Informatik I, Wintersemester 1993/94
155
Verifikation
Verifikationsregel für zusammengesetzte
Anweisungen
Anweisung1 ;...; Anweisungn
{ pre}} Anweisung1 { p}} , { p}} Anweisung1 { post}}
{ pre}} Anweisung1 ; Anweisung2 { post}}
wp(Anweisung1 ;Anweisung2 , post)
≡
wp(Anweisung1 , p(Anweisung2 , post))
Informatik I, Wintersemester 1993/94
156
Verifikation
Bedingte Anweisung – Grundform
.
.
abstand(x,y:REAL):REAL -- Abstand der Zahlen x und y
is
if x<y then Result := y-x
else Result := x-y
end
end
if Bedingung then Anweisung1 else Anweisung2 end
oder
if Bedingung then Anweisung1 end
Informatik I, Wintersemester 1993/94
157
Verifikation
Mehrere Alternativen
signum(x:REAL):REAL -- Signumfunktion
is
if x>0 then Result := 1
else if x<0 then Result := -1
else Result := 0
end
end
end
besser
signum(x:REAL):REAL -- Signumfunktion
is
if x>0 then Result := 1
elseif x<0 then Result := -1
else Result := 0
end
end
Informatik I, Wintersemester 1993/94
158
Verifikation
Bedingte Anweisung – allgemein
if Bedingung1 then Anweisung1
elseif Bedingung2 then Anweisung2
elseif Bedingung3 then Anweisung3
.
.
else Anweisungelse
end
Bedeutung:
if Bedingung1 then Anweisung1
else if Bedingung2 then Anweisung2
else if Bedingung3 then Anweisung3
.
.
else Anweisungelse
end
.
.
end
end
end
Informatik I, Wintersemester 1993/94
159
Verifikation
Komplexere Fallunterscheidung
-- DEKLARATIONEN
-- t:TRANSAKTION
(Void)
-- home bib:BIBLIOTHEK (bereits bestimmt)
-- Ausleihe, Verlängern, Rückgabe, Entnahme, Hinzufügen: CHARACTER
-- transaktion:CHARACTER (interaktiv erfragt)
-- sitzung beenden:BOOLEAN (false)
.
.
if
transaktion = Ausleihe
then !AUSLEIHE!t.init(home bib)
elseif transaktion = Verlängern then !VERLÄNGERN!t.init(home bib)
elseif transaktion = Rückgabe
then !RÜCKGABE!t.init(home bib)
elseif transaktion = Entnahme
then !ENTNAHME!t.init(home bib)
elseif transaktion = Hinzufügen then !HINZUF ÜGEN!t.init(home bib)
else sitzung beenden := true
end
Unnötig aufwendig
Informatik I, Wintersemester 1993/94
160
Verifikation
Fallunterscheidung mit inspect
.
.
inspect transaktion
when Ausleihe
then !AUSLEIHE!t.init(home bib)
when Verlängern then !VERLÄNGERN!t.init(home bib)
when Rückgabe
then !RÜCKGABE!t.init(home bib)
when Entnahme
then !ENTNAHME!t.init(home bib)
when Hinzufügen then !HINZUFÜGEN!t.init(home bib)
else sitzung beenden := true
end
Informatik I, Wintersemester 1993/94
161
Verifikation
Fallunterscheidung – Syntax
inspect Ausdruck
when Auswahl1 then Anweisung1
when Auswahl2 then Anweisung2
when Auswahl3 then Anweisung3
.
.
else Anweisungelse
end
Ausdruck vom Typ INTEGER oder CHARACTER
Auswahli: Liste von Konstanten oder Intervallen,
ohne Überlappung und vom Typ des Ausdrucks.
Ausdruck wird ausgewertet und mit Auswahlmöglichkeiten verglichen
Ausnahmesituation, wenn keine Auswahlmöglichkeit zutrifft
und else-Fall fehlt
Informatik I, Wintersemester 1993/94
162
Verifikation
Verifikationsregeln für bedingte Anweisungen
{ pre ∧ Bedingung}} Anweisung1 { post}} ,
{ pre ∧ ¬Bedingung}} Anweisung2 { post}}
{ pre}} if Bedingung then Anweisung1 else Anweisung2 end { post}}
{ pre ∧ Bedingung}} Anweisung1 { post}} ,
pre ∧ ¬Bedingung ⇒ post
{ pre}} if Bedingung then Anweisung1 end { post}}
wp(Bedingung then Anweisung1 else Anweisung2 end, post)
≡ Bedingung ⇒ wp(Anweisung1, post)
∧
¬Bedingung ⇒ wp(Anweisung2, post)
wp(Bedingung then Anweisung1 end, post)
≡ Bedingung ⇒ wp(Anweisung1, post)
Informatik I, Wintersemester 1993/94
∧
163
¬Bedingung ⇒ post
Verifikation
Verifikationsregeln für Fallunterscheidung
{ pre ∧ Bedingung1} Anweisung1 { post}} ,
{ pre ∧ ¬Bedingung1 ∧ Bedingung2} Anweisung2 { post}} ,
.
.
{ pre ∧ ¬Bedingung1 ∧ ... ∧ ¬Bedingungn} Anweisungelse { post}}
{ pre}} if Bedingung1 then Anweisung1 elseif ... else Anweisungelse end { post}}
Informatik I, Wintersemester 1993/94
164
Verifikation
Fakultätsprogramm – äußerer Rahmen
Programm
Zusicherungen
fakultät(arg:INTEGER):INTEGER
is -- Berechnung von arg!
if arg > 0
then
{ arg>0}}
fakultäts-berechnung
{ Result=arg!}}
korrekt:=true
else
korrekt:=false
end
end
{ korrekt ⇒ Result=arg!}}
Informatik I, Wintersemester 1993/94
165
Verifikation
Fakultätsprogramm – Verifikation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Programm
Zusicherungen
fakultät(arg:INTEGER):INTEGER
is -- Berechnung von arg!
{ true}}
if arg > 0
then
{ true ∧ arg>0}}
{ arg>0}}
fakultäts-berechnung
{ Result=arg!}}
{ false ∨ Result=arg!}}
{ ¬true ∨ Result=arg!}}
{ true ⇒ Result=arg!}}
korrekt:=true
{ korrekt ⇒ Result=arg!}}
else
{ true ∧ ¬(arg>0)}}
{ true}}
{ true ∨ Result=arg!}}
{ ¬false ∨ Result=arg!}}
{ false ⇒ Result=arg!}}
Prämissen
pre
pre ∧ Bedingung
K1,K11
Spezifikation
K10,K1
K8
Wertzuweisung
post
pre ∧ ¬Bedingung
∧ -E
K10,K1
K8
korrekt:=false
Wertzuweisung
post
{ korrekt ⇒ Result=arg!}}
end
end
{ korrekt ⇒ Result=arg!}
}
166
Informatik I, Wintersemester 1993/94
Verifikation
post
Wiederholung
from sitzung beenden := false
until sitzung beenden = true
loop -- Interaktionsmenü verarbeiten
inspect benutzerantwort im interaktionsmenü
when Ausleihe
then !AUSLEIHE!t.init(home bib)
when Verlängern then !VERLÄNGERN!t.init(home bib)
when Rückgabe
then !RÜCKGABE!t.init(home bib)
when Entnahme
then !ENTNAHME!t.init(home bib)
when Hinzufügen then !HINZUFÜGEN!t.init(home bib)
else sitzung beenden := true
end
end
from Initialanweisung
until Abbruchbedingung loop Schleifenanweisung
end
Informatik I, Wintersemester 1993/94
167
Verifikation
Fakultäts-berechnung
from Result := 1 ; n := 1
until n>=arg
loop
n := n+1;
Result := Result*n
end
Invariante: was bleibt stabil bei jedem Durchlauf? (partielle Korrektheit)
Variante: Wird etwas kleiner bei der Berechnung? (Terminierung)
from Result := 1 ; n := 1
invariant n<=arg
-- und Result=n!
variant arg-n
until n>=arg
loop
n := n+1;
Result := Result*n
end
Informatik I, Wintersemester 1993/94
168
Verifikation
Verifikationsregel für Schleifen
{ pre}} Init { Inv
∧
Var≥0}} ,
{ Inv
∧
Var≥0
∧
¬Abbruch
Anweisung { Inv
∧
∧
Var≥0
Var=n}}
∧
Var<n}}
{ pre}} from Init until Abbruch loop Anweisung end { Inv
∧
Abbruch}}
wp(from Init until Abbruch loop Anweisung end , post )
≡
wp(Init, ∃n:IN . Hn(Anweisung, Abbruch, post))
wobei
H0(Anweisung, Abbruch, post) ≡ Abbruch
∧
post
Hn+1(Anweisung, Abbruch, post)
≡ ¬Abbruch
∧
wp(Anweisung, Hn(Anweisung, Abbruch, post))
Informatik I, Wintersemester 1993/94
169
Verifikation
from
{ arg>0}}
{ arg>0}}
{ 1=1! ∧ 1≤arg
arg>0 ⇒ 1≤arg
∧
∧
arg-1≥0
∧
pre
1=1!
arg-1≥0}}
Result:= 1 ;
{ Result=1!
1≤arg
∧
arg-1≥0}}
{ Result=n! ∧ n≤arg
invariant n<=arg -- und Result=n!
variant arg-n
until n>=arg
loop
{ Result=n! ∧ n≤arg
∧
arg-n≥0}}
Inv ∧ Var≥0
¬(n≥arg)
Inv ∧ ¬Abbruch ∧ Var≥0 ∧ Var=x
arg-n=x}}
n≤arg ∧ ¬(n≥arg) ⇒ n<arg
∧
n:= 1
{ Result=n!
∧
n<arg
∧
∧
arg-n>0
{ Result*(n+1)=(n+1)!
∧
∧
∧
arg-n>0
∧
arg-n=x}}
n+1≤arg
∧
arg-n=x ⇒ arg-n≤x ⇒ arg-(n+1)<x
arg-n>0 ⇒ arg-(n+1)≥0
n<arg ⇒ n+1≤arg
Result=n! ⇒ Result*(n+1)=(n+1)!
arg-(n+1)≥0 ∧ arg-(n+1)<x}}
n:= n+1;
{ Result*n=n! ∧ n≤arg ∧ arg-n≥0 ∧ arg-n<x}}
Result:= Result*n
{ Result=n! ∧ n≤arg ∧ arg-n≥0 ∧ arg-n<x}}
end
{ Result=n! ∧ n≤arg ∧ n≥arg}}
{ Result=n! ∧ n=arg}}
{ Result=arg!}}
Informatik I, Wintersemester 1993/94
170
Inv ∧ Var≥0 ∧ Var<x
Inv ∧ Abbruch
n≤arg ∧ n≥arg ⇒ n=arg
Result=n! ∧ n=arg ⇒ Result=arg!
Verifikation
Rekursive Routinen: Fakultätsberechnung
fak berechnung(n:INTEGER):INTEGER is
require n>0
do
if n=1 then Result := 1
else Result := n * fak berechnung(n-1)
end
end
Mathematisch eleganter als Schleifen aber weniger effizient
Informatik I, Wintersemester 1993/94
171
Verifikation
Rekursive Routinen: Fibonaccizahlen
fib(1) = fig(2) = 1, fib(n+2) = fib(n+1)+fib(n)
fib(n:INTEGER):INTEGER is
require n>0
do
if n<3 then Result := 1
else Result := fib(n-1)+fib(n-2)
end
ensure fib(1)=1; fig(2)=1; fib(n+2)=fib(n+1)+fib(n)
end
mit Schleifen
fib(n:INTEGER):INTEGER is
require n>0
local i, fib 1, fib 2 : INTEGER
do if n<3 then Result := 1
else from fib 1 := 1; fib 2 := 1; Result := fib 1+fib 2; i := 3
until
i = n
invariant Result=fib(i); fib 1=fib(i-1); fib 2=fib(i-2)
variant n-i
loop i:= i+1; fib 2:= fib 1; fib 1:= Result; Result:= fib 1+fib 2
end
end
ensure fib(1)=1; fig(2)=1; fib(n+2)=fib(n+1)+fib(n)
end
Informatik I, Wintersemester 1993/94
172
Verifikation
Rekursive Routinen: Verifikation
• Partielle Korrektheit: Ist die Implementierung
korrekt, wenn jeder Aufruf korrekt ist?
Invariante entspricht dem Vertrag der rekursiven
Routine, den sie auch mit sich selbst schließt.
• Terminierung: liefern alle Aufrufe irgendwann ein
Ergebnis ohne einen weiteren rekursiven Aufruf ?
Variante hängt nur von äußeren Eigenschaften
(formale Parameter und aktuelles Objekt) ab und
muß bei jedem rekursiven Aufruf kleiner werden.
Informatik I, Wintersemester 1993/94
173
Verifikation
Fakultätsberechnung: Partielle Korrektheit
fak berechnung(n:INTEGER):INTEGER is
pre
do
{ n>0}}
if n=1
n>0 ∧ n=1 ⇒ 1=n!
then
{ n>0 ∧ n=1}}
{ 1=n!}}
Result := 1
{ Result=n!}}
else
{ n>0 ∧ n6=1}}
n>0 ∧ n6=1 ⇒ n-1>0 ∧ n*(n-1)!=n!
{ n-1>0 ∧ n*(n-1)!=n!}}
n-1>0 ⇒ fak berechnung(n-1)=(n-1)!
{ n*fak berechnung(n-1)=n!}}
Result := n * fak berechnung(n-1)
{ Result=n!}}
post
end
{ Result=n!}}
end
Variante ist der Parameter n
Informatik I, Wintersemester 1993/94
174
Verifikation
Verifikationsregel für rekursive Routinen
r habe Argumente yr , Vor- und Nachbedingungen prer bzw. postr .
Br enthalte rekursive Aufrufe der Form entityi.r(Ai(yr )) .
Bedi(yr ) sei die Bedingung für den i-ten rekursiven Aufruf.
r ist genau dann total korrekt, wenn gilt
Partielle Korrektheit: wenn alle rekursiven Aufrufe korrekt sind, gilt
{ prer (yr )}} Br { postr (yr )}}
Terminierung: Es gibt einen Integer-Ausdruck Var mit
prer (yr ) ⇒ Var(yr ,Current)≥0
und für jeden rekursiven Aufruf entityi.r(Ai(yr ))
prer (yr )
∧
Bedi(yr ) ⇒ prer (Ai(yr ))
Informatik I, Wintersemester 1993/94
∧
Var(Ai(yr ),entityi)<Var(yr ,Current)
175
Verifikation
Disziplinierte Ausnahmen
Fehler müssen zu einem definierten Verhalten führen
• Wiederaufnahme: versuche Ausnahmesituation durch
Korrekturmaßnahmen zu beseitigen und starte neu.
⇒ Kontrakt der Routine wird eingehalten
• Organisierte Panik: geordneter Abbruch mit Fehler
⇒ Klasseninvariante wird erfüllt, Nachbedingung nicht
⇒ Kunde muß selbst Fehler behandelt
!!! Nicht akzeptabel ist stillschweigendes Aufhören !!!
Eine Routine muß ihren Vertrag erfüllen oder scheitern
Informatik I, Wintersemester 1993/94
176
Verifikation
Disziplinierte Ausnahmen in Eiffel
• rescue-Klausel behandelt Fehler außerhalb des Rumpfes
• retry-Anweisung startet Anweisungsteil der Routine erneut
• Routine scheitert, wenn Ende der rescue-Klausel erreicht
• Implizite rescue-Klausel wird automatisch ergänzt
Innerhalb einer Klasse K mit Invariante INV heißt r genau dann
Ausnahme-korrekt, wenn für alle gültigen Argumente xr und jeden Zweig b
ihres rescue-Blocks gilt
• { true}} b { INV
∧
prer (xr )}} , falls b mit retry endet
• { true}} b { INV}} , falls b ohne retry endet
Informatik I, Wintersemester 1993/94
177
Verifikation
Ein- und Ausgabe
• Keine vordefinierten Befehle von Eiffel
• Dienstleistung der Klassen FILE und STANDARD FILES
– Keine vordefinierten Befehle von Eiffel
– vordefiniertes feature io:STANDARD FILES
⇒ qualifizierter Aufruf io.putint(43)
(oder erben)
• Einlesen getrennt in Einleseprozedur und Funktionsaufruf
– io.readint; n := io.lastint
Einlesen ist eine Doppeloperation
• Strenge Typisierung (readint, readreal, readchar,...)
Σ: Sehr gewöhnungsbedürftig
– erst bei komplexen Benutzeroberflächen von Vorteil
Informatik I, Wintersemester 1993/94
178
Verifikation
Allgemeine Entwurfsprinzipien
• Programmentwicklung durch Beweisführung
• Eigenschaften zu manipulierender Objekte klären
• Formalismus und gesunder Menschenverstand
• Bewußtes Anwenden von Prinzipien
• Entwicklung am angestrebten Resultat orientieren
• Problemstellung einfach und präzise beschreiben
• Programmiere nicht innerhalb einer Programmiersprache
sondern in die Sprache hinein.
Informatik I, Wintersemester 1993/94
179
Systematik
Maximale Segmentsumme
• Gegeben eine Folge a1, a2, . . . , an ganzer Zahlen
q
Bestimme die Summe Pi=p ai eines Segmentes, die maximal
im Bezug auf alle möglichen Summen von Segmenten ist
q
Mn ≡ max({Pi=p ai | 1≤p≤q≤n})
• Direkte Lösung leicht zu finden, aber ineffizient
• Induktive Betrachtung liefert
M 1 = a1 ,
Mn+1 = max(Mn,Ln+1)
wobei Ln ≡ max({Pn
i=p ai | 1≤p≤n})
L1 = a 1 ,
Ln+1 = max(Ln+an+1,an+1) )
→ eleganterer und effizienterer Algorithmus
Informatik I, Wintersemester 1993/94
180
Systematik
Maximale Segmentsumme – direkte Lösung
maxseg:INTEGER is
local p, q, i, sum :INTEGER
do
from p := lower
-- variiere untere Grenze p
Result := item(lower); -- Initialwert zum Vergleich
until p >= upper
loop
from q := p
-- variiere obere Grenze q
until q > upper
loop
from i := p ;
-- Berechne Pqi=p ai
sum := item(i) -- Initialwert der Summe
until i = q
loop
i := i+1;
sum := sum+item(i)
Pq
end -- sum = i=p ai
if sum > Result then Result := sum end
q := q+1
end;
p := p+1
end
end
Informatik I, Wintersemester 1993/94
181
Systematik
Maximale Segmentsumme: systematische Lösung
maxseg:INTEGER
is
local n, L n :INTEGER
do
from n := lower;
Result := item(n);
L n := item(n)
until n >= upper
invariant
-- Result = Mn ∧
variant upper - n
loop
if L n > 0
then L n := L n + item(n)
else L n := item(n)
end;
-- L n = Ln+1
if L n > Result
then Result := L n
end;
-- Result = Mn+1
n := n+1
end
end
Informatik I, Wintersemester 1993/94
182
L n = Ln
Systematik
Strategie zur Erzeugung bedingter Anweisungen
Ein Programmstück sei spezifiziert durch pre und post.
1. Suche eine Instruktion Anweisung, deren Ausführung die
Nachbedingung in einigen Fällen erfüllt.
2. Bestimme eine Bedingung B für die gilt
{ pre ∧ B}} Anweisung { post}} .
3. Erzeuge if B then Anweisung else ?? end
bzw. Anweisung, wenn B den Wert true hat
4. Für ?? setze pre’ ≡ pre ∧ ¬B und wiederhole die
Strategie, bis die in (2) gefundene Bedingung true wird.
Informatik I, Wintersemester 1993/94
183
Systematik
Strategie zur Erzeugung von Schleifen
Ein Programmstück sei spezifiziert durch pre und post.
1. Ausgehend von der Beweisidee lege Inv und Var fest.
2. Bestimme Initialanweisung Init, welche Inv erfüllt.
3. Wähle eine Abbruchbedingung Abbruch, für die gilt
Inv ∧ Abbruch ⇒ post.
4. Bestimme eine Anweisung, welche die Variante verringert und die Invariante erhält.
Verfolge die Verringerung der als erstes verfolgt
5. Erzeuge das Programm
from Init until Abbruch loop Anweisung end
Informatik I, Wintersemester 1993/94
184
Systematik
Invarianten und Varianten
• Eine Invariante kann durch Abschwächung der
Nachbedingung auf folgende Arten erzeugt werden.
– Entfernen eines Konjunktionsgliedes
– Ersetzen einer Konstanten durch eine Variable
– Erweiterung des Wertebereichs einer Variablen
– Erweiterung durch Disjunktion
• Die Variante sollte zunächst informal als eine
Eigenschaft, die sich aus der Invariante und der
Spezifikation ergibt, beschrieben und anschließend als
Integer-Ausdruck formalisiert werden.
Informatik I, Wintersemester 1993/94
185
Systematik
Sinnvoller Einsatz von Rekursion
• Entwurf durch Reduktion auf leichtere Probleme:
Versuche, ein Problem so aufzuspalten, daß zunächst die Lösung eines bekannten
einfacheren Problems angewandt werden kann und der Rest eine Variante des
ursprünglichen Problems beschreibt.
• Divide&Conquer Strategie:
Teile das Problem in zwei “gleiche” Hälften auf und behandle jede Hälfte mit dem
gleichen Verfahren, bis die Teile klein genug sind, um eine direkte Lösung zu
erlauben.
• Ersetze Rekursion durch Schleifen,
wann immer dies einfach durchzuführen ist
Informatik I, Wintersemester 1993/94
186
Systematik
Ethik und Verantwortung
Der Verantwortung gerechtwerden – privat und im Beruf
• Versuchung zum Mißbrauch eigener Fähigkeiten widerstehen
• Informatik hat massive Auswirkungen auf die Allgemeinheit
→ Konsequenzen eigener Arbeit abschätzen
→ Fach- und Sachkompetenz erwerben
→ Gesprächsbereit sein
• Grenzen der eigenen Kompetenz realistisch einschätzen
→ Keine überzogene Versprechungen machen
→ Fehler rechtzeitig eingestehen
• In Konfliktsituationen Zivilcourage aufbringen
Informatik I, Wintersemester 1993/94
187
Systematik

Zugehörige Unterlagen

ABKÜRZUNGSVERZEICHNIS • Allgemeine Abkürzungen ABWL

Grundlagen der Informatik I

Zugehörige Unterlagen

Produkte

Unterstützung

Grundlagen der Informatik I

Zugehörige Unterlagen

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können