1 module, klassen, verträge l abstraktion und spezifikation l kunden-lieferanten-modell l module...
Post on 05-Apr-2015
106 Views
Preview:
TRANSCRIPT
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
Module, Klassen, Verträge 3
Abstraktion und Spezifikation
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
Module, Klassen, Verträge 4
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 5
Kunden-Lieferanten-Modell
Kunde (Client)
Schnittstelle = Dienste
Lieferant (Supplier)
benutzt bietet
Module, Klassen, Verträge 6
Kunden-Lieferanten-Modell
Aufrufender
Dienste sind- Abfragen - Aktionen
Aufgerufener
Aufruf Antwort
Module, Klassen, Verträge 7
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 8
Module und Schnittstellen
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
Module, Klassen, Verträge 9
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 10
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 11
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 12
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
Module, Klassen, Verträge 13
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 14
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 15
Spezifikation durch Vertrag
Kunden-Lieferanten-Modell mit Bedingungen
Kunde
Prüfung bzgl. angeforderten Dienst
Invarianten, Vorbedingungenggf. Ausführung
Invarianten, Nachbedingungen
Lieferant
Auftrag Rückmeldung
Module, Klassen, Verträge 16
Spezifikation durch Vertrag
Schnittstellenspezifikation mit Bedingungen
MODULE Kaffeeautomat
QUERIES
außer_Betrieb : BOOLEAN
eingenommener_Betrag : INTEGER
Preis : INTEGER
QUERIES FOR Betriebspersonal
gesammelter_Betrag : INTEGER
. . .
Module, Klassen, Verträge 17
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 18
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 19
Spezifikation durch Vertrag
Schnittstellenspezifikation mit Bedingungen
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
Module, Klassen, Verträge 20
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 21
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
MODULE Kaffeeautomat
QUERIES
außer_Betrieb : BOOLEAN
eingenommener_Betrag : NATURAL
Preis : NATURAL
QUERIES FOR Betriebspersonal
gesammelter_Betrag : NATURAL
. . .
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
. . .
Module, Klassen, Verträge 23
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
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
. . .
Module, Klassen, Verträge 24
Spezifikation durch Vertrag
Auswirkungen des Typs NATURAL
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
Module, Klassen, Verträge 25
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 26
Klassen und Exemplare
Spezifikation einer Klasse
CLASS Kaffeeautomat
QUERIES
außer_Betrieb : BOOLEAN
eingenommener_Betrag : NATURAL
Preis : NATURAL
QUERIES FOR Betriebspersonal
gesammelter_Betrag : NATURAL
. . .
. . .
END Kaffeeautomat
Module, Klassen, Verträge 27
Klassen und Exemplare
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
Module, Klassen, Verträge 28
Klassen und Exemplare
Eine weitere Klasse
CLASS TasseQUERIES
leer : BOOLEANvoll : BOOLEAN
ACTIONS leeren
PRENOT leer
POSTNOT voll
füllenPRE
leerPOST
vollINVARIANTS
NOT (leer AND voll)END Tasse
Module, Klassen, Verträge 29
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 30
Klassen und Exemplare
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
Module, Klassen, Verträge 31
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
Kaffeeautomat
benutztbenutzt
Tassebenutzt
Module, Klassen, Verträge 32
Abstraktion und Spezifikation
Ein Warenautomat
Warenautomat
...
Ware ausgebenPreis EUR
eingenommener
gesammelter
außer
initialisieren
Geld einnehmen
Geld zurückgeben
...
...
Betrag EUR
Betrieb
Betrag EUR
Geld-schlitz
Module, Klassen, Verträge 33
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
Module, Klassen, Verträge 34
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
Module, Klassen, Verträge 35
Kapselung
Schnittstelle und Implementation
Schnittstelle Implementation
Verhalten Struktur
WAS wird gemacht? WIE wird es gemacht?
Spezifikation Realisation
öffentlich privat
extern intern
zugreifbar verborgen
top related