1 Module, Klassen, Verträge l Abstraktion und Spezifikation l Kunden-Lieferanten-Modell l Module und Schnittstellen l Spezifikation durch Vertrag l Klassen

1

Module, Klassen, Verträge

Abstraktion und SpezifikationKunden-Lieferanten-ModellModule und SchnittstellenSpezifikation durch VertragKlassen und ObjekteGeneralisierung und SpezialisierungKapselung

Module, Klassen, Verträge 2

Abstraktion und Spezifikation

Ein Kaffeeautomat

Kaffeeautomat

0,30

Kaffee ausgebenPreis EUR

eingenommener

gesammelter

außer

initialisieren

Geld einnehmen

Geld zurückgeben

0,60

31,20

Betrag EUR

Betrieb

Betrag EUR

Geld-schlitz



Formales Zustands-Verhaltens-Modell

Aktionen: e Geld_einnehmenr Geld_zurückgebena Kaffee_ausgeben

Zustände: n neutralg geladen mit Geld

Reaktionen: G GeldrückgabeK Kaffeeausgabe0 keine Reaktion

(e, 0)

(r, G)

(e, G)

(a, 0)

(r, 0)

(a, K)gg nn



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


Kunden-Lieferanten-Modell

Kunde (Client)

Schnittstelle = Dienste

Lieferant (Supplier)

benutzt bietet


Kunden-Lieferanten-Modell

Aufrufender

Dienste sind- Abfragen - Aktionen

Aufgerufener

Aufruf Antwort


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).



Nutzung von Diensten durch Kunden

• Qualifizierung von NamenModulname.Dienstname (aktuelle Parameter)

• Beispiele zur Nutzung:

Kaffeeautomat.Preis Kaffeeautomat.Kaffee_ausgebenKaffeeautomat.Geld_einnehmen (120) Kaffeeautomat.Kaffee_ausgeben (5 Tassen)

IF Kaffeeautomat.außer_Betrieb THEN anderen Automaten suchen END

Kaffeepreis := Kaffeeautomat.Preis



Signatur eines Dienstes

• Name des Dienstes• Anzahl, Namen und Typen der Parameter; ggf. Ergebnistyp


QUERIES



Preis : INTEGER



ACTIONS


Kaffee_ausgeben

Geld_zurückgeben

ACTIONS FOR Betriebspersonal

initialisieren (IN neuer_Preis : INTEGER)

END Kaffeeautomat



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.



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


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: Kaffeeautomat.Geld_einnehmen (-1000)

Vorbedingung: Betrag >= 0



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



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.



Kunden-Lieferanten-Modell mit Bedingungen

Kunde

Prüfung bzgl. angeforderten Dienst

Invarianten, Vorbedingungenggf. Ausführung

Invarianten, Nachbedingungen

Lieferant

Auftrag Rückmeldung



Schnittstellenspezifikation mit Bedingungen


QUERIES



Preis : INTEGER



. . .




ACTIONS


PRE

NOT außer_Betrieb

Betrag >= 0

POST


. . .




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

. . .




ACTIONS FOR Betriebspersonalinitialisieren (IN neuer_Preis : INTEGER)PREneuer_Preis >= 0POSTNOT außer_Betriebeingenommener_Betrag = 0Preis = neuer_Preisgesammelter_Betrag = 0

INVARIANTSeingenommener_Betrag >= 0Preis >= 0gesammelter_Betrag >= 0

END Kaffeeautomat



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?



Auswirkungen des Typs NATURAL


QUERIES


eingenommener_Betrag : NATURAL

Preis : NATURAL


gesammelter_Betrag : NATURAL

. . .




ACTIONS

Geld_einnehmen (IN Betrag : NATURAL)

PRE

NOT außer_Betrieb

POST


. . .




ACTIONS Geld_einnehmen (IN Betrag : NATURAL)PRENOT außer_BetriebPOSTeingenommener_Betrag = OLD (eingenommener_Betrag) + Betrag

Kaffee_ausgebenPRENOT außer_Betriebeingenommener_Betrag >= PreisPOSTeingenommener_Betrag = OLD (eingenommener_Betrag) - Preisgesammelter_Betrag = OLD (gesammelter_Betrag) + Preis

Geld_zurückgebenPOST eingenommener_Betrag = 0

. . .




ACTIONS FOR Betriebspersonalinitialisieren (IN neuer_Preis: NATURAL)

PREneuer_Preis > 0

POSTNOT außer_Betriebeingenommener_Betrag = 0Preis = neuer_Preisgesammelter_Betrag = 0

INVARIANTSPreis > 0gesammelter_Betrag MOD Preis = 0

END Kaffeeautomat

Neue, nichttriviale Invariante


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



Spezifikation einer Klasse

CLASS Kaffeeautomat

QUERIES


eingenommener_Betrag : NATURAL

Preis : NATURAL


gesammelter_Betrag : NATURAL

. . .

. . .

END Kaffeeautomat



Objekte und Module

• Erzeugen von Objekten durch Deklaration:

KA1, KA2 : Kaffeeautomat

• Aufruf von Objekten als Lieferanten:

KA1.Geld_einnehmen (120)

KA2.Kaffee_ausgeben

• 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.

Klasse

Objekt

istTypvon

istExemplar

von



Eine weitere Klasse

CLASS TasseQUERIES

leer : BOOLEANvoll : BOOLEAN

ACTIONS leeren

PRENOT leer

POSTNOT voll

füllenPRE

leerPOST

vollINVARIANTS

NOT (leer AND voll)END Tasse



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?



Ergänzung der Aktion Kaffee_ausgeben

Kaffee_ausgeben (INOUT Pott: Tasse)

PRENOT außer_Betriebeingenommener_Betrag >= PreisPott.leer

POSTeingenommener_Betrag = OLD (eingenommener_Betrag) -

Preisgesammelter_Betrag = OLD (gesammelter_Betrag) + PreisPott.voll



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

Kaffeeautomat

benutztbenutzt

Tassebenutzt



Ein Warenautomat

Warenautomat

...

Ware ausgebenPreis EUR

eingenommener

gesammelter

außer

initialisieren

Geld einnehmen

Geld zurückgeben

...

...

Betrag EUR

Betrieb

Betrag EUR

Geld-schlitz


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.

Oberbegriff

Unterbegriff

SpezialisierenGeneralisieren

abstrakt

konkret


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.

Implementation

Schnittstelle


Kapselung

Schnittstelle und Implementation

Schnittstelle Implementation

Verhalten Struktur

WAS wird gemacht? WIE wird es gemacht?

Spezifikation Realisation

öffentlich privat

extern intern

zugreifbar verborgen

Documents

1 Module, Klassen, Verträge l Abstraktion und Spezifikation l Kunden-Lieferanten-Modell l Module und Schnittstellen l Spezifikation durch Vertrag l Klassen