ModuleKlassenVertrÃ

Module, Klassen, Verträge
Abstraktion
und Spezifikation
Kunden-Lieferanten-Modell
Module und Schnittstellen
Spezifikation durch Vertrag
Klassen und Objekte
Generalisierung und Spezialisierung
Kapselung
1
Abstraktion und Spezifikation
Ein Kaffeeautomat
Kaffeeautomat
eingenommener
Betrag EUR
0,30
Geld einnehmen
Preis EUR
0,60
Kaffee ausgeben
außer
Betrieb
gesammelter
Betrag EUR
Geldschlitz
Geld zurückgeben
31,20
initialisieren
Module, Klassen, Verträge
2
Abstraktion und Spezifikation
Formales Zustands-Verhaltens-Modell
Aktionen:
e
r
a
Geld_einnehmen
Geld_zurückgeben
Kaffee_ausgeben
Zustände:
n
g
neutral
geladen mit Geld
Reaktionen:
G
K
0
Geldrückgabe
Kaffeeausgabe
keine Reaktion
(e, 0)
(e, G)
g
(a, K)
(r, G)
(a, 0)
n
(r, 0)
Module, Klassen, Verträge
3
Abstraktion und Spezifikation
Textuelles Softwaremodell: Schnittstellenspezifikation
MODULE Kaffeeautomat
QUERIES
außer_Betrieb :
BOOLEAN
eingenommener_Betrag : INTEGER
Preis :
INTEGER
QUERIES FOR Betriebspersonal
gesammelter_Betrag :
INTEGER
ACTIONS
Geld_einnehmen (IN Betrag : INTEGER)
Kaffee_ausgeben
Geld_zurückgeben
ACTIONS FOR Betriebspersonal
initialisieren (IN neuer_Preis : INTEGER)
END Kaffeeautomat
Module, Klassen, Verträge
4
Kunden-Lieferanten-Modell
Kunde (Client)
bietet
benutzt
Schnittstelle = Dienste
Lieferant (Supplier)
Module, Klassen, Verträge
5
Kunden-Lieferanten-Modell
Aufrufender
Aufruf
Antwort
Dienste sind
- Abfragen
- Aktionen
Aufgerufener
Module, Klassen, Verträge
6
Module und Schnittstellen
Module
• Eine Schnittstelle legt fest, was
+ ein Lieferant bereitstellt und
+ ein Kunde erhalten kann.
• Dienste haben einen Namen und ggf. Parameter.
• Parameter müssen vom Kunden versorgt werden.
• Abfragen (QUERIES) geben Auskunft über den Zustand eines Moduls,
verändern ihn aber nicht.
Sie liefern als Ergebnis einen Wert.
• Aktionen (ACTIONS) verändern den Zustand eines Moduls,
liefern aber kein Ergebnis.
• Rechte regeln, welche Kunden welche Dienste nutzen dürfen (FOR-Klausel).
Module, Klassen, Verträge
7
Module und Schnittstellen
Nutzung von Diensten durch Kunden
• Qualifizierung von Namen
Modulname.Dienstname (aktuelle Parameter)
• Beispiele zur Nutzung:
Kaffeeautomat.Preis
Kaffeeautomat.Kaffee_ausgeben
Kaffeeautomat.Geld_einnehmen (120)
Kaffeeautomat.Kaffee_ausgeben (5 Tassen)
IF Kaffeeautomat.außer_Betrieb THEN
anderen Automaten suchen
END
Kaffeepreis := Kaffeeautomat.Preis
Module, Klassen, Verträge
8
Module und Schnittstellen
Signatur eines Dienstes
• Name des Dienstes
• Anzahl, Namen und Typen der Parameter; ggf. Ergebnistyp
MODULE Kaffeeautomat
QUERIES
außer_Betrieb :
BOOLEAN
eingenommener_Betrag : INTEGER
Preis :
INTEGER
QUERIES FOR Betriebspersonal
gesammelter_Betrag :
INTEGER
ACTIONS
Geld_einnehmen (IN Betrag : INTEGER)
Kaffee_ausgeben
Geld_zurückgeben
ACTIONS FOR Betriebspersonal
initialisieren (IN neuer_Preis : INTEGER)
END Kaffeeautomat
Module, Klassen, Verträge
9
Module und Schnittstellen
Statische Semantik
• Festlegung der Zugriffskontrolle
mein_Geldbeutel := Kaffeeautomat.gesammelter_Betrag
Kaffeeautomat.eingenommener_Betrag := 240
• Typbindung: Abfragen, Parameter, Variablen sind an Typen gebunden.
durstig : BOOLEAN
...
durstig := Kaffeeautomat.Preis
• Prüfung der statischen Semantik ist ohne Ausführung möglich.
Module, Klassen, Verträge 10
Module und Schnittstellen
Dynamische Semantik
• Die bisherige Schnittstellenspezifikation
+ erlaubt logisch falsche Parameter,
+ sagt nichts über die Reihenfolge der Aufrufe.
• Prüfung der dynamischen Semantik ist erst während der Ausführung möglich.
• Mittel zur Spezifikation der dynamischen Semantik: Verträge aus
+ Vor- und Nachbedingungen
+ Invarianten
Module, Klassen, Verträge 11
Spezifikation durch Vertrag
Vor- und Nachbedingungen
• Vorbedingungen des Auftragnehmers in Hinblick auf die Vertragsannahme
• Der Kunde ist verantwortlich für die Einhaltung der Vorbedingungen.
• Der Auftragnehmer kann Aufträge, die die Vorbedingungen verletzen, zurückweisen.
• Beispiel:
Kunde:
Vorbedingung:
Kaffeeautomat.Geld_einnehmen (-1000)
Betrag >= 0
Module, Klassen, Verträge 12
Spezifikation durch Vertrag
Vor- und Nachbedingungen
• Nachbedingungen, die der Lieferant dem Kunden garantiert
• Der Lieferant ist verantwortlich für die Erfüllung der Nachbedingungen.
• Der Kunde verlässt sich darauf, dass der Lieferant die Nachbedingungen erfüllt.
• Beispiel:
Nachbedingung für Geld_einnehmen:
eingenommener_Betrag = OLD (eingenommener_Betrag) + Betrag
Module, Klassen, Verträge 13
Spezifikation durch Vertrag
Invarianten
• Nicht alle Zustände eines Moduls, die syntaktisch erlaubt sind, sind semantisch sinnvoll.
• Beispiel:
Kaffeeautomat.Preis = -100
Invariante: Preis >= 0
• Invarianten können während der Ausführung eines Dienstes kurzzeitig verletzt werden.
• Invarianten gelten vor und nach jedem Aufruf des Moduls.
Module, Klassen, Verträge 14
Spezifikation durch Vertrag
Kunden-Lieferanten-Modell mit Bedingungen
Kunde
Auftrag
Rückmeldung
Prüfung bzgl. angeforderten Dienst
Invarianten, Vorbedingungen
ggf. Ausführung
Invarianten, Nachbedingungen
Lieferant
Module, Klassen, Verträge 15
Spezifikation durch Vertrag
Schnittstellenspezifikation mit Bedingungen
MODULE Kaffeeautomat
QUERIES
außer_Betrieb :
eingenommener_Betrag :
Preis :
BOOLEAN
INTEGER
INTEGER
QUERIES FOR Betriebspersonal
gesammelter_Betrag :
INTEGER
. . .
Module, Klassen, Verträge 16
Spezifikation durch Vertrag
Schnittstellenspezifikation mit Bedingungen
ACTIONS
Geld_einnehmen (IN Betrag : INTEGER)
PRE
NOT außer_Betrieb
Betrag >= 0
POST
eingenommener_Betrag = OLD (eingenommener_Betrag) + Betrag
. . .
Module, Klassen, Verträge 17
Spezifikation durch Vertrag
Schnittstellenspezifikation mit Bedingungen
Kaffee_ausgeben
PRE
NOT außer_Betrieb
eingenommener_Betrag >= Preis
POST
eingenommener_Betrag = OLD (eingenommener_Betrag) - Preis
gesammelter_Betrag = OLD (gesammelter_Betrag) + Preis
Geld_zurückgeben
PRE
NOT außer_Betrieb
POST
eingenommener_Betrag = 0
. . .
Module, Klassen, Verträge 18
Spezifikation durch Vertrag
Schnittstellenspezifikation mit Bedingungen
ACTIONS FOR Betriebspersonal
initialisieren (IN neuer_Preis : INTEGER)
PRE
neuer_Preis >= 0
POST
NOT außer_Betrieb
eingenommener_Betrag = 0
Preis = neuer_Preis
gesammelter_Betrag = 0
INVARIANTS
eingenommener_Betrag >= 0
Preis >= 0
gesammelter_Betrag >= 0
END Kaffeeautomat
Module, Klassen, Verträge 19
Spezifikation durch Vertrag
Verhältnis statische und dynamische Semantik
• Typ INTEGER umfasst Werte: . . ., -2, -1, 0, 1, 2, . . .
• Typ NATURAL umfasst Werte: 0, 1, 2, . . .
• Die Grenze zwischen statischer und dynamischer Semantik ist unscharf.
Transformationen von Semantiken sind u.U. möglich.
• Welche Auswirkung hat die Einführung des Typs NATURAL auf die
Schnittstellenspezifikation?
• Was bedeutet die Verwendung des Typs NATURAL für die dynamische Semantik?
Module, Klassen, Verträge 20
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
MODULE Kaffeeautomat
QUERIES
außer_Betrieb :
eingenommener_Betrag :
Preis :
BOOLEAN
NATURAL
NATURAL
QUERIES FOR Betriebspersonal
gesammelter_Betrag :
NATURAL
. . .
Module, Klassen, Verträge 21
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
ACTIONS
Geld_einnehmen (IN Betrag : NATURAL)
PRE
NOT außer_Betrieb
POST
eingenommener_Betrag = OLD (eingenommener_Betrag) + Betrag
. . .
Module, Klassen, Verträge 22
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
ACTIONS
Geld_einnehmen (IN Betrag : NATURAL)
PRE
NOT außer_Betrieb
POST
eingenommener_Betrag = OLD (eingenommener_Betrag) + Betrag
Kaffee_ausgeben
PRE
NOT außer_Betrieb
eingenommener_Betrag >= Preis
POST
eingenommener_Betrag = OLD (eingenommener_Betrag) - Preis
gesammelter_Betrag = OLD (gesammelter_Betrag) + Preis
Geld_zurückgeben
POST
eingenommener_Betrag = 0
. . .
Module, Klassen, Verträge 23
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
ACTIONS FOR Betriebspersonal
initialisieren (IN neuer_Preis: NATURAL)
PRE
neuer_Preis > 0
POST
NOT außer_Betrieb
eingenommener_Betrag = 0
Preis = neuer_Preis
gesammelter_Betrag = 0
INVARIANTS
Preis > 0
gesammelter_Betrag MOD Preis = 0
END Kaffeeautomat
Neue, nichttriviale Invariante
Module, Klassen, Verträge 24
Klassen und Exemplare
Kaffeeautomaten gleicher Bauart
• Unterscheidung:
Beschreibung des Baumusters gegenüber der Beschreibung eines Exemplars
• Automaten gleicher Bauart gehören zu einer Klasse,
der ein Baumuster (Blaupause, Schablone,... ) zugrunde liegt.
• Ein konkreter Automat ist ein Objekt einer Klasse baugleicher Automaten.
• Ersetzen des Schlüsselworts MODULE durch CLASS
Module, Klassen, Verträge 25
Klassen und Exemplare
Spezifikation einer Klasse
CLASS Kaffeeautomat
QUERIES
außer_Betrieb :
eingenommener_Betrag :
Preis :
BOOLEAN
NATURAL
NATURAL
QUERIES FOR Betriebspersonal
gesammelter_Betrag :
NATURAL
. . .
. . .
END Kaffeeautomat
Module, Klassen, Verträge 26
Klassen und Exemplare
Objekte und Module
Klasse
• Erzeugen von Objekten durch Deklaration:
KA1, KA2 : Kaffeeautomat
• Aufruf von Objekten als Lieferanten:
KA1.Geld_einnehmen (120)
KA2.Kaffee_ausgeben
ist
Exemplar
von
ist
Typ
von
Objekt
• Die Klasse legt alle möglichen Zustände und das Verhalten für jedes Objekt fest.
• Jedes Objekt nimmt zu einem Zeitpunkt einen eigenen Zustand ein.
• Ein Modul ist ein einzelnes Objekt, der keine Klasse zugrundeliegt.
Module, Klassen, Verträge 27
Klassen und Exemplare
Eine weitere Klasse
CLASS Tasse
QUERIES
leer : BOOLEAN
voll : BOOLEAN
ACTIONS
leeren
PRE
NOT leer
POST
NOT voll
füllen
PRE
leer
POST
voll
INVARIANTS
NOT (leer AND voll)
END Tasse
Module, Klassen, Verträge 28
Klassen und Exemplare
Tassen
• Tasse kann teilweise gefüllt sein:
teilvoll = (NOT leer AND NOT voll)
• Wie sieht auf Basis der Klassenspezifikation ein Zustandsdiagramm aus?
+ Zustände: leer, voll, teilvoll
+ In welchem Verhältnis stehen Vorzustände der Übergänge zu Vorbedingungen und
Nachzustände zu Nachbedingungen?
+ Lässt sich Ihre Tasse “ex” leeren?
Module, Klassen, Verträge 29
Klassen und Exemplare
Ergänzung der Aktion Kaffee_ausgeben
Kaffee_ausgeben (INOUT Pott: Tasse)
PRE
NOT außer_Betrieb
eingenommener_Betrag >= Preis
Pott.leer
POST
eingenommener_Betrag = OLD (eingenommener_Betrag) - Preis
gesammelter_Betrag = OLD (gesammelter_Betrag) + Preis
Pott.voll
Module, Klassen, Verträge 30
Klassen und Exemplare
Kaffeeautomaten und Tassen - als Klassen
• Erzeugen einer Tasse als Objekt:
mein_Kump : Tasse
• Tasse am Automat KA1 füllen:
KA1.Kaffee_ausgeben (mein_Kump)
• Trinken:
mein_Kump.leeren
• Benutztstruktur der Klassen:
Kunde
benutzt
Kaffeeautomat
benutzt
benutzt
Tasse
Module, Klassen, Verträge 31
Abstraktion und Spezifikation
Ein Warenautomat
Warenautomat
eingenommener
Betrag EUR
...
Geld einnehmen
Preis EUR
...
Ware ausgeben
außer
Betrieb
gesammelter
Betrag EUR
Geldschlitz
Geld zurückgeben
...
initialisieren
Module, Klassen, Verträge 32
Generalisierung und Spezialisierung
Automaten
• Kaffeeautomaten, Fahrkartenautomaten sind spezielle Ausprägungen von
Warenautomaten.
• Der Oberbegriff ist allgemeiner, abstrakter als seine Unterbegriffe.
• Ein Unterbegriff ist spezieller, konkreter als seine Oberbegriffe.
abstrakt
Oberbegriff
Generalisieren
Spezialisieren
Unterbegriff
konkret
Module, Klassen, Verträge 33
Kapselung
Trennung von Schnittstelle und Implementation
• Schnittstelle umfasst alle Informationen, die
+ ein Kunde zur Auftragsvergabe an den Lieferanten wissen muss,
+ der Lieferant für die Implementation benötigt.
• Der Kunde kann die Schnittstelle benutzen, ohne die dahinter verborgene
Implementation zu kennen (information hiding).
• Die Implementation kann ohne Auswirkung auf den Kunden geändert werden.
Schnittstelle
Implementation
Module, Klassen, Verträge 34
Kapselung
Schnittstelle und Implementation
Schnittstelle
Implementation
Verhalten
Struktur
WAS wird gemacht?
WIE wird es gemacht?
Spezifikation
Realisation
öffentlich
privat
extern
intern
zugreifbar
verborgen
Module, Klassen, Verträge 35