Module, Klassen, Verträge

Präsentation zum Thema: "Module, Klassen, Verträge"—  Präsentation transkript:

1 Module, Klassen, Verträge
Vorlesung Informatik I WS 98/99 Module, Klassen, Verträge Abstraktion und Spezifikation Kunden-Lieferanten-Modell Module und Schnittstellen Spezifikation durch Vertrag Klassen und Objekte Generalisierung und Spezialisierung Kapselung Copyright: Prof. H. Ketz, FH Reutlingen

2 Abstraktion und Spezifikation
Vorlesung Informatik I WS 98/99 Abstraktion und Spezifikation Ein Kaffeeautomat Kaffeeautomat eingenommener Geld- 0,30 Geld einnehmen Betrag EUR schlitz Preis EUR 0,60 Kaffee ausgeben außer Geld zurückgeben Betrieb gesammelter 31,20 initialisieren Betrag EUR Module, Klassen, Verträge Copyright: Prof. H. Ketz, FH Reutlingen

3 Abstraktion und Spezifikation
Formales Zustands-Verhaltens-Modell Aktionen: e Geld_einnehmen r Geld_zurückgeben a Kaffee_ausgeben Zustände: n neutral g geladen mit Geld Reaktionen: G Geldrückgabe K Kaffeeausgabe 0 keine Reaktion (e, 0) (a, 0) g n (e, G) (a, K) (r, 0) (r, G) 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) benutzt bietet Schnittstelle = Dienste Lieferant (Supplier) Module, Klassen, Verträge

6 Kunden-Lieferanten-Modell
Vorlesung Informatik I WS 98/99 Kunden-Lieferanten-Modell Aufrufender Aufruf Antwort Dienste sind - Abfragen Aktionen Aufgerufener Module, Klassen, Verträge Copyright: Prof. H. Ketz, FH Reutlingen

7 Module und Schnittstellen
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 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

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 Auftrag Rückmeldung Prüfung bzgl. angeforderten Dienst Invarianten, Vorbedingungen ggf. Ausführung Invarianten, Nachbedingungen Lieferant Module, Klassen, Verträge

16 Spezifikation durch Vertrag
Vorlesung Informatik I WS 98/99 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 Copyright: Prof. H. Ketz, FH Reutlingen

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 eingenommener_Betrag = 0 . . . Module, Klassen, Verträge

19 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

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) PRE NOT außer_Betrieb POST eingenommener_Betrag = OLD (eingenommener_Betrag) + Betrag Kaffee_ausgeben eingenommener_Betrag >= Preis eingenommener_Betrag = OLD (eingenommener_Betrag) - Preis gesammelter_Betrag = OLD (gesammelter_Betrag) + Preis Geld_zurückgeben eingenommener_Betrag = 0 . . . Module, Klassen, Verträge

24 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

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 Klasse Objekt
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 ist Exemplar von ist Typ von Objekt Module, Klassen, Verträge

28 Klassen und Exemplare Eine weitere Klasse CLASS Tasse QUERIES
leer : BOOLEAN voll : BOOLEAN ACTIONS leeren PRE NOT leer POST NOT voll füllen leer voll INVARIANTS 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) 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

31 Klassen und Exemplare Kaffeeautomaten und Tassen - als Klassen Kunde
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 benutzt Kaffeeautomat Tasse benutzt Module, Klassen, Verträge

32 Abstraktion und Spezifikation
Ein Warenautomat Warenautomat eingenommener Geld- ... Geld einnehmen Betrag EUR schlitz Preis EUR ... Ware ausgeben außer Geld zurückgeben Betrieb gesammelter ... initialisieren Betrag EUR 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 abstrakt Generalisieren Spezialisieren Unterbegriff konkret Module, Klassen, Verträge

34 Kapselung Trennung von Schnittstelle und Implementation Schnittstelle
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

35 Kapselung Schnittstelle und Implementation Module, Klassen, Verträge