Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 4: Die Schnittstelle einer Klasse.

Slides:



Advertisements
Ähnliche Präsentationen
Blue J.
Advertisements

Use Cases mit selbstständigen Extend-Use-Case
Strategie (Strategy / Policy) Ein objektbasiertes Verhaltensmuster Stephan Munkelt, Stefan Salzmann - 03IN.
Finale Semantik und beobachtbares Verhalten
Kapitel 4 Datenstrukturen
Spec# Proseminar Assertions im SS 2007 Uni Paderborn Andreas Martens Betreuer: Dipl. Inform. Björn Metzler.
Christos, Kornelia, Jan Christos, Kornelia, Jan Entwicklungsumgebung Versteht unseren Java Programm Code Versteht unseren Java Programm.
Christos, Kornelia, Jan Christos, Kornelia, Jan Entwicklungsumgebung Versteht unseren Java Programm Code Versteht unseren Java Programm.
Christos, Kornelia, Jan Christos, Kornelia, Jan Entwicklungsumgebung Versteht unseren Java Programm Code Versteht unseren Java Programm.
Hörsaalübung Use Cases mit selbstständigen Extend-Use-Case
On a Buzzword: Hierachical Structure David Parnas.
Java: Dynamische Datentypen
Indirekte Adressierung
Prof. Dr. T. Kudraß1 Relationenkalkül. Prof. Dr. T. Kudraß2 Relationenkalkül Zwei Ausprägungen: Tupelrelationenkalkül (TRK) und Domänenrelationenkalkül.
Datentyp  Zusammenfassung von Mengen von "Werten" mit auf
Vorlesung 9.2: Specification Universität Bielefeld – Technische Fakultät AG Rechnernetze und verteilte Systeme Peter B. Ladkin
Command Pattern Karola Schäuble,
Abstrakte Klassen, Interface
DVG Klassen und Objekte
DVG Kommentare 1 Kommentare. 2 Kommentare Es gibt zwei Arten von Kommentaren: einzeilige Kommentare // der Kommentar geht bis zum Ende der Zeile.
Klassen und Schnittstellen Klasse: Definiert Zustandsraum ihrer Instanzen vollständig (Implementierung der Struktur, soweit Voraussetzung für die Methoden-
UML Begleitdokumentation des Projekts
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
RDF MT Resource Description Framework Model Theory © 2002 by Emir Blažević
Guten Nachmittag!.
Wir haben gesehen Das Gerüst ist bei JavaKara fix vorgegeben
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lecture 13: (Container-)Datenstrukturen.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lecture 13: (Container-)Datenstrukturen.
Game Development mit LUA Integration und Kommunikation von LUA mit C++ Referat von Paul van Hemmen Seminar: Reusable Content in 3D und Simulationssystemen.
Einführung in die Programmierung Wintersemester 2008/09 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Einführung in die Programmierung Wintersemester 2009/10 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 15: Topologisches Sortieren Teil 1: Problemstellung und.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 9: Abstraktion.
Einführung in die Programmierung Prof. Dr. Bertrand Meyer
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lecture 10: Das dynamische Modell und mehr zu Referenzen.
Chair of Software Engineering Einführung in die Programierung Prof. Dr. Bertrand Meyer Lektion 8: Kontrollstrukturen.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 14: Mehrfachvererbung.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 2: Der Umgang mit Objekten I.
1. Entwicklungsumgebung 2. Kontextmenü 3. Compile 4. Objekt 5. Attribut 6. Klasse 7. Deklaration 8. Intialisierung.
OOP-Begriffe Abstraktion Modellieren Klasse Objekt Attribute Methoden
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 7: Referenzen und Zuweisungen.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Vorlesung 5: Invarianten und Logik.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 4: Die Schnittstelle einer Klasse.
Einführung in die Programmierung Prof. Dr. Bertrand Meyer
(D.h. „Hallo MausFans!“ auf Japanisch).
Einführung in die Programmierung Prof. Dr. Bertrand Meyer
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 6: Objekterzeugung.
Aufgaben Version 1: Es soll eine Wetterstation mit folgenden zwei Anzeigen implementiert werden: Aktuelle Wetterbedingungen mit Temperatur und.
1. Entwicklungsumgebung 2. Kontextmenü 3. Compile 4. Objekt 5. Attribut 6. Klasse 7. Deklaration 8. Intialisierung.
Java Programmierung.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 2: Der Umgang mit Objekten I.
Klassen und Klassenstruktur
Paul, Morten, Yannick Blue J. Entwicklungsumgebung  versteht Java Programmcode  Für die Entwicklung eigener Software  Durch die Programmierung.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 18: Mehr über Vererbung und Agenten.
Die Vereinsverwaltung unter Windows 2000 Anhand der folgenden Präsentation werden Sie mit der Verwaltung des Vereins unter Windows 2000 vertraut gemacht.
Einführung in die Programmierung Prof. Dr. Bertrand Meyer
Einführung Blue J. Inhaltsverzeichnis  Definition  Vokabeln.
Kapitel 5Strukturen Information aus der realen Welt werden in einem informationsverarbeitenden System als Daten abgelegt. Diese stellen also eine (vereinfachte)
HG13_ Herzgen, Jung & Lorkowski1 Java Programmierung BlueJ Workshop.
Java-Kurs Übung Besprechung der Hausaufgabe
Einführung in die Programmierung mit Java
IT2 – WS 2005/20061Nov 14, 2005 Visibility  public: Sichtbar in allen Paketen  protected: Sichtbar innerhalb des Pakets und in den Unterklassen  (default,
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 3: Der Umgang mit Objekten II.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 9: Abstraktion.
Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 6: Objekterzeugung.
Paul, Morten, Yannick Blue J. Entwicklungsumgebung  versteht Java Programmcode  Für die Entwicklung eigener Software  Durch die Programmierung.
Objektorientierte (OO) Programmierung
Christos, Kornelia, Jan Christos, Kornelia, Jan Entwicklungsumgebung Versteht unseren Java Programm Code Versteht unseren Java Programm.
Tutorium Software-Engineering SS14 Florian Manghofer.
Einführung in die Programmierung Prof. Dr. Bertrand Meyer
 Präsentation transkript:

Chair of Software Engineering Einführung in die Programmierung Prof. Dr. Bertrand Meyer Lektion 4: Die Schnittstelle einer Klasse

2 Kunde, Versorger (client, supplier) Definitionen Ein Kunde eines Softwaremechanismus ist ein System beliebiger Art (wie z.B. ein Softwareelement, ein nicht-Software- System oder ein menschlicher Benutzer), welches diesen nutzt Für seine Kunden ist der Mechanismus ein Versorger.

3 Darstellung der Kunde-Beziehung (Siehe Diagramm-Tool von EiffelStudio) C S Kunde

4 Informatics Europe Best Practices Awards TInformatics Europe is launching a prize: The Informatics Europe Curriculum Best Practices Award The award recognizes outstanding educational initiatives that improve the quality of informatics teaching and the attractiveness of the discipline, and can be applied and extended beyond their institutions of origin. The award will be funded through industrial sponsorship; the 2011 awards are sponsored by Intel Each edition of the award may be focused on one or more particular areas of informatics teaching. The focus of the 2011 award will include concurrency, with a prize of about EUR 30,000, and embedded systems, with a prize of about EUR 10,000 The award will be overseen by a committee appointed by the Board of Informatics Europe. Details will be published by Nov. 21.

5 Schnittstelle: Definition Eine Schnittstelle einer Menge von Softwaremechanismen ist die Beschreibung von Techniken, die es den Kunden ermöglicht, diese Mechanismen zu benutzen

6 Arten von Schnittstellen (interfaces) Benutzerschnittstelle: Kunden sind Menschen  GUI (Graphical User Interface): Graphische Benutzeroberfläche (oder: Benutzerschnittstelle)  Textschnittstellen, Befehlszeilen-Schnittstellen... Programmschnittstelle: Kunden sind andere Softwaresysteme  API (Application (oder: Abstract) Program Interface): Programmierschnittstelle Wir befassen uns jetzt mit Programmierschnittstellen

7 Eine graphische Benutzerschnittstelle (GUI)

8 Klassen Ein Objekt ist eine Softwaremaschine, die es Programmen erlaubt, auf eine Ansammlung von Daten zuzugreifen und diese zu verändern. Objekte repräsentieren z.B. (in Traffic)  Eine Stadt  Eine Tramlinie  Eine Route durch die Stadt  Ein Element des GUI’s, wie z.B ein Knopf (Button) Jedes Objekt gehört zu einer gewissen Klasse, die die anwendbaren Operationen (Features) definiert. Beispiele:  Die Klasse aller Städte  Die Klasse aller Knöpfe  etc.

9 Definition: Klasse Klasse Eine Klasse ist die Beschreibung einer Menge von möglichen Laufzeitobjekten, auf die die gleichen Features anwendbar sind. Eine Klasse repräsentiert eine Kategorie von Dingen. Ein Objekt repräsentiert eines dieser Dinge.

10 Definitionen: Klasse, Instanz, generierende Klasse Instanz, generierende Klasse Falls ein Objekt O eines der durch die Klasse C beschriebenen Objekte ist:  O ist eine Instanz von C  C ist die generierende Klasse von O Eine Klasse repräsentiert eine Kategorie von Dingen. Ein Objekt repräsentiert eines dieser Dinge.

11 Objekte vs Klassen Klassen existieren nur im Softwaretext:  Definiert durch einen Klassentext  Beschreiben Eigenschaften von assoziierten Instanzen. Objekte existieren nur zur Laufzeit:  Sichtbar im Programmtext durch Namen, die Laufzeitobjekte bezeichnen. Beispiel: Paris

12 prepend animate append Ein Objekt hat eine Schnittstelle (interface)* count stations first last *von seiner generiender Klasse definiert

13 prepend animate append count first Ein Objekt hat eine Implementation* count stations first last *von seiner generiender Klasse definiert

14 Softwarekonstruktion Passende Klassen zu finden ist ein zentraler Teil des Softwaredesigns. (Die Entwicklung der Architektur eines Programms) Die Details auszuarbeiten ist ein Teil der Implementation.

15 Eine Klassenschnittstelle Hier benutzen wir “Schnittstelle” im Sinne einer Programmierschnittstelle (nicht Benutzerschnittstelle). Wir schauen uns jetzt die Schnittstelle von SIMPLE_LINE (eine vereinfachte Version von LINE) an. Diese wird in EiffelStudio angezeigt. (Benutzen Sie den “Interface” Knopf.) Vergessen Sie nicht, das TRAFFIC_ Präfix zu allen Klassen der Traffic Bibliothek hinzuzufügen. Benutzen Sie in EiffelStudio TRAFFIC_LINE und TRAFFIC_SIMPLE_LINE.

16 Eine Abfrage: “count” Wie lange ist diese Linie? Siehe Abfrage count Kopfkommentar: beschreibt den Zweck dieses Features. “diese Linie”: Die Instanz von SIMPLE_LINE, auf die count angewendet wird. Die Form einer Abfrage-Deklaration: feature_name : RÜCKGABE_TYP INTEGER : ein Typ, der ganze Zahlen bezeichnet (z.B. -23, 0, 256) count : INTEGER -- Anzahl der Stationen auf dieser Linie. Möglicherweise mit Featurerumpf

18 Stilregel: Kopfkommentare Denken Sie nicht einmal daran, ein Feature zu schreiben, ohne sofort einen Kopfkommentar zu verfassen, der den Zweck des Features erläutert.

19 Ausdrücke und ihre Typen Zur Laufzeit hat jedes Objekt einen Typ: seine generierende Klasse Beispiele:  LINE ist der Typ des Objektes, das Line8 referenziert  INTEGER ist der Typ des Objektes, das Line8.count referenziert Im Programmtext hat jeder Ausdruck einen Typ Beispiele:  LINE ist der Typ von Line8  INTEGER ist der Typ von Line8. count

20 Eine weitere Abfrage: i_th Welche ist die i-te Station einer Linie? Feature i_th. Konsistenz durch Konvention: Die Nummerierung beginnt bei der südlichsten Station (south end) i_th (i: INTEGER): STATION -- Die Station mit Index i an dieser Linie.

21 Zwei weitere Abfragen Welches sind die Stationen am Ende einer Linie? Eigenschaften jeder Linie l :  l. south_end = l. i_th (1)  l. north_end = l. i_th (l. count) south_end : STATION -- Südliche Endstation north_end : STATION -- Nördliche Endstation

22 Beispiele: die Klasse QUERIES class QUERIES inherit TOURISM feature explore_on_click -- Abfragen auf Linien ausprobieren. do Paris. display Console. show (Line8. count) Console. show (Line8. i_th (1)) Console. show (Line8. i_th (Line8. count) end

23 Ein Befehl: remove_all_segments Wir möchten Line8 von Grund auf neu bauen. Wir beginnen damit, indem wir alle Segmente löschen: Anmerkungen:  Unsere Metrolinie hat immer mindestens eine Station, auch nach Anwendung des Befehls remove_all_segments  Falls die Linie nur eine Station hat, bezeichnet sowohl south_end als auch north_end diese Station remove_all_segments -- Alle Segmente ausser der südlichen -- Endstation entfernen.

24 Der Befehl extend Neue Stationen zu einer Linie hinzufügen: extend (s : STATION) -- s am Ende dieser Linie hinzufügen.

25 Die Klasse COMMANDS class COMMANDS inherit TOURISM feature explore_on_click -- Einen Teil der Linie 8 wiederherstellen. do Line8. remove_all_segments -- Nicht nötig, Station_Balard hinzuzufügen, da -- remove_all_segments die südl. Endstation beibehält. Line8. extend (Station_Lourmel ) Line8. extend (Station_Boucicaut ) Line8. extend (Station_Felix_Faure ) -- Keine weiteren Stationen, und Resultate anzeigen: Console. show (Line8. count ) Console. show (Line8.north_end. name ) end

26 Saubere Schnittstellen definieren Nicht jedes Feature ist mit jedem Argument auf jede Instanz anwendbar Beispiel: Line8. i_th (200 ) ist falsch! Die Klassenschnittstelle muss präzise genug sein, um daraus ihre korrekte Anwendung abzuleiten

27 Erster Versuch… Informationen zum Kopfkommentar hinzufügen: Besser, aber immer noch nicht gut genug:  Ein Kommentar ist nur eine informelle Erklärung  Obige Einschränkung sollte eine offiziellere Stellung in der Schnittstelle haben i_th (i : INTEGER): STATION -- Die i -te Station dieser Linie -- (Achtung: benutze nur mit i zwischen 1 und count, inklusive.)

28 Verträge (contracts) Ein Vertrag ist eine semantische Bedingung, die den Gebrauch einer Feature- oder Klasseneigenschaft charakterisiert Drei Hauptarten:  Vorbedingung (precondition)  Nachbedingung (postcondition)  Klasseninvariante (class invariant)

29 Eine Eigenschaft, die ein Feature von jedem Kunden erwartet i_th (i : INTEGER): STATION -- Die i-te Station dieser Linie Vorbedingung require nicht_zu_klein: i >= 1 nicht_zu_gross: i <= count Die Vorbedingung von i_th Ein Feature ohne die require Klausel ist immer anwendbar, als ob es folgende Klausel hätte: require immer_OK: True

30 Zusicherungen (assertions) nicht_zu_klein: i >= 1 Zusicherung Bedingung (condition) Zusicherungs-Etikett(*) (*) oder: „Tag“, Sprich: „tääg“

31 Das Vorbedingungsprinzip Ein Kunde, der ein Feature aufruft, ohne die Vorbedingung zu erfüllen, bezeichnet man als fehlerhafte (“buggy”) Software Ein Kunde, der ein Feature aufruft, muss sicherstellen, dass die Vorbedingung vor dem Aufruf erfüllt ist

32 Verträge Verträge erleichtern den Prozess der Fehlerbeseitigung (Debugging). Verträge sind auch nützlich als Dokumentation einer Schnittstelle.

33 remove_all_segments -- Alle Stationen ausser der südlichen Endstation entfernen ensure nur_eine_bleibt: count = 1 beide_enden_gleich: south_end = north_end Nachbedingungen Vorbedingungen: Auflagen für Kunden Nachbedingungen: Nutzen für Kunden extend (s : STATION ) -- s am Ende der Linie hinzufügen. ensure neue_station_da: i_th (count ) = s im_norden: north_end = s eine_mehr: count = old count + 1 Wert des Ausdrucks zum Zeitpunkt des Aufrufs

34 Die old Notation Nur in Nachbedingungen verwendbar Bezeichnet den Wert eines Ausdrucks, den er beim Aufruf der Routine hatte Beispiel (in einer Klasse ACCOUNT): balance : INTEGER -- Aktueller Kontostand. deposit (v : INTEGER) -- Addiere v zum Kontostand. require positiv: v > 0 do … ensure addiert: balance = old balance + v end

35 Ein Feature muss sicherstellen, dass, sofern seine Vorbedingung zu Beginn seiner Ausführung erfüllt wurde, seine Nachbedingung am Schluss erfüllt ist. Das Nachbedingungsprinzip Ein Feature, welches seine Nachbedingung nicht erfüllen kann, nennt man fehlerhafte (“buggy”) Software.

36 Was wir heute gesehen haben:  Klassen  Objekte  Den Begriff “Schnittstelle”  GUI vs API  Befehle und Abfragen  Verträge: Vor- und Nachbedingungen (Zusicherungen)  Verträge zur Fehlerbeseitigung und Dokumentation benutzen

37 Zu lesen auf nächste Woche: Kapitel 1 bis 6 Lesen Sie im Speziellen das Kapitel 5 (Logik), da wir nur kurz auf den in “Diskrete Mathematik ” behandelten Teil eingehen werden und wir uns auf die Anwendungen in der Programmierung konzentrieren