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

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

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

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

Kunden-Lieferanten-Modell Kunde (Client) benutzt bietet Schnittstelle = Dienste Lieferant (Supplier) Module, Klassen, Verträge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kapselung Schnittstelle und Implementation Module, Klassen, Verträge