PRG2. Teil II: OOP und JAVA Teil III: Datenbanken. Modul: Programmierung B-PRG Grundlagen der Programmierung II

Transkript

1 PRG2 Teil II: OOP und JAVA Teil III: Datenbanken Modul: Programmierung B-PRG Grundlagen der Programmierung II Prof. Dot.-Ing. Roberto Zicari Professur für Datenbanken und Informationssysteme (FB 12) 1

2 Organisatorisches Alles bleibt wie bisher: Übungen: Abgabe wie immer Mittwoch vor der Vorlesung Vorlesung, Begin 9.30 Uhr Behandelte Themen: Teil I: OOP, UML, Java Teil II: Datenbanken, SQL Mitarbeiter: (3 Vorlesungen) (3 Vorlesungen) Natascha Hoebel, Sascha Kaufmann Kontakt siehe Homepage 2 Grundlagen der Programmierung II

3 Übersicht: OOP und Java Vorlesung 8 Teil 1: Einführung in die Objektorientierung Teil 2: Einführung in UML (Anwendungsfalldiagramme) Teil 3: JAVA (Grundlagen, IDE, und API) Vorlesung 9 Teil 4: Einführung in UML (Klassendiagramme, Assoziationen, Zustandsdiagramme, Sequenzdiagramme) Teil 5: JAVA (Operatoren, Schlüsselwörter, Datentypen) Vorlesung 10 Teil 6: Guideline UML zu Java am Fallbeispiel Teil 7: JAVA (Vererbung, Polymorphie, Listen, Aufgaben) 3 Grundlagen der Programmierung II

4 Teil II: OOP und JAVA (Vorlesung 8) Modul: Programmierung B-PRG Grundlagen der Programmierung II Prof. Dot.-Ing. Roberto Zicari Professur für Datenbanken und Informationssysteme (FB 12)

5 Teil 1 - OOP Einführung in die Objektorientierung 5

6 Objektorientierung Das Objektmodell beschreibt die Welt als eine Menge interagierender Objekte. 6 Grundlagen der Programmierung II

7 Kurze Wiederholung von: Objekt Klasse Attribute Methoden Identität eines Objektes Lebenszeit eines Objektes Vererbung 7 Grundlagen der Programmierung II

8 Objekt Ein Objekt (Instanz) ist eine individuelle, benennbare reale oder abstrakte Einheit mit einer wohldefinierten Rolle. eine klar abgrenzbare Einheit mit Merkmalen (Zustand und Verhalten) und einer Identität. eine Ausprägung einer Klasse. eine gekapselte Datenstruktur, die zur Laufzeit des Programms Speicherplatz belegt und die nur über die Operationen der definierten Schnittstelle manipuliert werden kann. 8 Grundlagen der Programmierung II

9 Klasse Eine Klasse (Typ, Schablone) ist die Spezifikation einer Menge von Objekten mit gleicher Struktur und gleichem Verhalten ( Schablone ). eine Realisierung eines abstrakten Datentyps (ADT). ein benutzerdefinierter Typ in einer objektorientierten Programmiersprache. eine zur Compilezeit des Programms notwendige Typspezifikation. 9 Grundlagen der Programmierung II

10 Beispiele PKW Klasse Objekte (Instanzen) mein Auto dein Auto das Auto mit dem Kennzeichen F-CB 2000 usw. Geometrische Formen ein Kreis mit dem Radius 5 und Mittelpunkt (42,17) eine Pyramide mit Grundfläche 3x4 und Höhe 6 usw. DVD Mr. and Mrs. Smith -DVD King Kong -DVD 10 Grundlagen der Programmierung II

11 Attribute und Zustand Die Attribute eines Objektes legen die Eigenschaften und Zustände des Objektes fest. Der Zustand eines Objektes ist die Gesamtheit der Attribute eines Objektes plus ihre momentanen Werte. PKW DA-XY 123 F-CB 2000 Typ Farbe km/h 11 Grundlagen der Programmierung II

12 Methoden Methoden sind auf einem Objekt ausführbare Operationen. werden durch eintreffende Nachrichten ausgelöst. können den Objekt-Zustand verändern. werden innerhalb einer Klasse definiert. Es gibt mehrere Arten von Methoden: Modifikation ändert Zustand Selektion liest Zustand Iteration wiederholte Modifikation oder Selektion Konstruktion kreiert ein Objekt und initialisiert Zustand Destruktion löscht Zustand und zerstört ein Objekt 12 Grundlagen der Programmierung II

13 Verhalten eines Objektes Das Verhalten eines Objektes sind die Aktionen und Reaktionen des Objektes. wird durch die Methoden der Klasse des Objekts realisiert. wird durch den Aufruf der Methoden verursacht. F-CB 2000 PKW Typ Farbe km/h DA-XY 123 VW Rot 60 BMW Gelb 100 beschleunigen() bremsen() 13 Grundlagen der Programmierung II

14 Identität eines Objektes Objekte sind mittels Referenz eindeutig identifizierbar. Objekte haben eine Identität und meistens einen oder mehrere Namen bzw. Referenzen. Objekte belegen einen Teil des Speichers. Der Zustand eines Objektes kann sich ändern, nicht seine Identität. Gleicher Zustand (also der gleiche Wert) bedeutet nicht gleiche Identität! Dies ist besonders bei Vergleichsoperationen zu beachten. 14 Grundlagen der Programmierung II

15 Identität eines Objektes deinauto Referenz 1 keine Referenzen meinauto Referenz 2 Objekt mit zwei Namen und zwei Referenzen Objekt ohne Namen Ein Objekt ohne Namen besitzt zwar eine Identität, ist aber nicht (mehr) erreichbar Garbage Collection. 15 Grundlagen der Programmierung II

16 Lebenszeit von Objekten Die Lebenszeit eines Objektes ist die Zeit zwischen der Kreierung des Objektes und dem Löschen des Objektes (bzw. der Löschung der letzten Referenz) mit anschließender Garbage Collection. Garbage Collection Java gibt automatisch den Speicher unbenutzter Objekte frei! Hat man die Referenzen vieler Objekte auf NULL gesetzt, kann man mit System.gc() der Virtuellen Maschine den Einsatz des GarbageCollectors empfehlen. System.gc() sollte jedoch nur sehr sparsam verwendet werden! 16 Grundlagen der Programmierung II

17 Vererbung (Inheritance) in der OOP Eigenschaften der Vererbung von einer Oberklasse zu seinen Unterklassen Die Unterklasse hat alle Merkmale der Oberklasse und ist ihr damit ähnlich. Sie kann die geerbten Attribute und Methoden unverändert benutzen oder neu definieren (überschreiben). Eine Unterklasse besitzt im Allgemeinen zusätzliche Attribute und Methoden. Sie ist eine Spezialisierung, Konkretisierung und Erweiterung ihrer Oberklasse. Eine Unterklasse befindet sich auf einem niedrigeren Abstraktionsgrad als die Oberklasse. Die Vererbung ist transitiv. Eine Unterklasse kann selbst wieder Oberklasse sein. Dadurch ergibt sich eine Baumstruktur, die so genannte Vererbungsstruktur oder Klassenhierarchie. 17 Grundlagen der Programmierung II

18 Ein Beispiel für die Vererbung aus der Praxis Grundlagen der Programmierung II

19 Beispiel für eine Klassenhierarchie (1) Kraftfahrzeug Typ, Farbe, kmh beschleunigen() bremsen() Kraftfahrzeug ist eine Klasse mit den drei Attributen Typ, Farbe und kmh und den beiden Methoden beschleunigen() und bremsen(). Es gibt aber auch spezielle Kraftfahrzeuge, die ein zusätzliches, gemeinsames Merkmal haben. 19 Grundlagen der Programmierung II

20 Beispiel für eine Klassenhierarchie (2) Kraftfahrzeug Typ, Farbe, kmh beschleunigen() bremsen() LKW anhängen() LKW ist eine Unterklasse von Kraftfahrzeug. Sie erbt alle Eigenschaften von ihrer Oberklasse, hat aber die zusätzliche Methode anhängen(). Es gibt auch Kraftfahrzeuge, die keine LKWs sind. 20 Grundlagen der Programmierung II

21 Beispiel für eine Klassenhierarchie (3) Kraftfahrzeug Typ, Farbe, kmh beschleunigen() bremsen() Omnibus Stehplätze PKW LKW anhängen() Omnibus, PKW und LKW sind jeweils Unterklassen der Klasse Kraftfahrzeug. LKW hat eine zusätzliche Methode, Omnibus ein zusätzliches Attribut. Die drei Unterklassen erben alle Merkmale der Oberklasse Kraftfahrzeug. Aber es gibt es auch mehrere, verschiedene Arten von PKWs, die besondere Merkmale haben. 21 Grundlagen der Programmierung II

22 Beispiel für eine Klassenhierarchie (4) Kraftfahrzeug Typ, Farbe, kmh beschleunigen() bremsen() Omnibus Stehplätze PKW LKW anhängen() Limousine Cabriolet Verdeck öffnen() Cabriolet und Limousine können zusätzliche Methoden bzw. Attribute haben. Beide erben alle Merkmale von PKW und damit auch von Kraftfahrzeug. Eine solche Hierarchie lässt sich beliebig fortsetzen. 22 Grundlagen der Programmierung II

23 Teil 2 - UML Einführung in UML Anwendungsfalldiagramme 23

24 Was ist ein Modell? Ein Modell ist eine Vereinfachung der Realität. Wir könne ein komplexes System in seiner Gesamtheit nicht erfassen. Wir bauen deshalb Modelle, um das zu entwickelnde System besser zu verstehen. Prinzip teile und herrsche 24 Grundlagen der Programmierung II

25 Warum modellieren? Beispiel: Der Bau einer Hundehütte Man braucht nur einen Hammer, Nägel und ein paar Bretter, baut diese zusammen und der Hund ist glücklich. Kein Modellieren nötig! 25 Grundlagen der Programmierung II

26 Warum modellieren? Beispiel: Der Bau eines Hochhauses Ohne Planung und Arbeitsteilung unmöglich Viele Auflagen Sehr hohe Kosten Ansprüche der Mieter Modellieren unumgänglich! 26 Grundlagen der Programmierung II

27 Ziele der Modellierung Modelle helfen, ein System zu visualisieren, so wie es ist oder wie wir es wünschen. Modelle ermöglichen uns, die Struktur oder das Verhalten eines Systems zu spezifizieren. Modelle liefern uns eine Schablone, die uns beim Konstruieren eines Systems anleitet. Modelle dokumentieren die getroffenen Entscheidungen. UML (Unified Modeling Language) ist eine Standardsprache zum Entwerfen von Softwaremodellen. 27 Grundlagen der Programmierung II

28 Modellieren mit UML UML ermöglicht objektorientiertes Modellieren. Da UML standardisiert ist, können die Modelle von anderen Anwendern verstanden werden. UML ermöglich Forward-Engineering : Aus einem UML-Modell kann der Code einer Programmiersprache erzeugt werden (Java, C++...). UML ermöglich Reverse-Engineering : Aus dem Code einer Implementierung kann ein entsprechendes UML-Modell erzeugt werden. 28 Grundlagen der Programmierung II

29 Informationen zu UML UML wurde aus mehreren Modellierungssprachen von Grady Booch, Jim Rumbaugh und Ivar Jacobson entwickelt und ist seit dem Jahr 1997 von der OMG (Object Management Group) standardisiert. Momentan ist die Version 2.0 aktuell: Einige interessante Links zu UML: UML Resource Page: Rational: OMG Homepage: 29 Grundlagen der Programmierung II

30 Literatur zu OO und UML Heide Balzert: Lehrbuch der Objektmodellierung, Spektrum AV B. Oestereich, C. Weiss, : Objektorientierte Geschäftsprozessmodellierung mit der UML dpunkt.verlag Grady Booch, Jim Rumbaugh, Ivar Jacobson: Das UML Benutzerhandbuch, Addison-Wesley Grechenig, Zuser: SE mit UML und dem Unified Process, Pearson 30 Grundlagen der Programmierung II

31 Modell-Typen in UML Es ist sinnvoll, für die verschiedenen Sichtweisen auf ein System unterschiedliche Modelle zu verwenden. Programmierer Hier: Statiker Kunden Klassendiagramm Anwendungsfalldiagramm 31 Grundlagen der Programmierung II

32 Sichtweisen auf das System In UML können verschiedene Sichtweisen auf ein System anschaulich modelliert werden. Für den Anwender (Kunde) existiert das Anwendungsfalldiagramm. Das Klassendiagramm repräsentiert ein Model für den Code eines Systems und ist somit sehr hilfreich für den Programmierer. Aber es ist sehr technisch und deshalb nicht für alle Anwender geeignet. 32 Grundlagen der Programmierung II

33 Multiple Diagramme in UML Grundlagen der Programmierung II

34 Behandelte Diagrammtypen In der Vorlesung werden wir nur folgende Diagrammtypen exemplarisch behandeln: Anwendungsfalldiagramm (Verhalten) Klassendiagramm (Struktur) Zustandsdiagramm (Verhalten) Sequenzdiagramm (Verhalten, Interaktion) 34 Grundlagen der Programmierung II

35 Einführendes Beispiel Wir wollen ein einfaches Modell für eine Flaschen-Pfandmaschine erstellen. Die Maschine soll eine Flasche aufnehmen, die Flasche prüfen und falls diese akzeptiert wurde, den Pfand ausgeben. Beispiel für eine reale Pfandmaschine z.b. im Aldi-Supermarkt. 35 Grundlagen der Programmierung II

36 Flaschen-Pfandmaschine Grundlegende Funktionsweise: Leergut Kunde Geld oder Bon Pfandmaschine 36 Grundlagen der Programmierung II

37 Vorschau Klassendiagramm Pfandmaschine geld: int zahle(betrag: int) Flaschen-Pfandmaschine anzflaschen: int nimm_flasche() 0...* 0,1 nimmt auf Flasche groesse: float 37 Grundlagen der Programmierung II

38 Vorschau Anwendungsfalldiagramm Beispiel Pfandmaschine Pfandmaschine Kunde Technikerin 38 Grundlagen der Programmierung II

39 Vorschau Zustandsdiagramm (START) (ZUSTAND) (ÜBERGANG) (ENDE) 39 Grundlagen der Programmierung II

40 Vorschau Sequenzdiagramm Pfandmaschine Flaschenmechanik ZEIT nimmeineflasche() habeflasche() (acknowledgement) 40 Grundlagen der Programmierung II

41 Anwendungsfalldiagramm Ein Anwendungsfalldiagramm beschreibt die Beziehungen (das Zusammenwirken) zwischen den beteiligten Akteuren und Anwendungsfällen. Akteur (Actor) Beziehung (Relation) Anwendungsfall (Use Case) 41 Grundlagen der Programmierung II

42 Anwendungsfalldiagramm Ein Anwendungsfall ist die Beschreibung einer Menge aufeinander folgender Aktionen. Grafisch wird ein Anwendungsfall durch eine Ellipse, die nur den Namen enthält, dargestellt. Ein Akteur repräsentiert den Anwender, der einen Anwendungsfall (System) nutzt. Dabei kann ein Akteur eine Person oder ein anderes System sein. Grafisch wird eine Akteur durch eine Strichfigur mit dem Namen seiner Rolle darunter dargestellt (UML 2.0). Eine reale Person kann somit in mehren Rollen agieren. 42 Grundlagen der Programmierung II

43 Anwendungsfalldiagramm Beispiel: Modellierung des Systems Reservierung eines Hotel-Zimmers Die Reservierung eines Zimmers lässt sich in mehrere Teilprozesse aufteilen. Zwei davon seien Ein Tourist kommt in ein Hotel und möchte ein Zimmer reservieren. (Zimmeranfrage) Der Receptionist prüft ob das Zimmer schon gereinigt ist. Falls nicht muss die Putzkolonne das Zimmer grundreinigen. (Reinigung) 43 Grundlagen der Programmierung II

44 Anwendungsfalldiagramm Systemgrenze Systemname Zimmeranfrage Akteur Akteur Beziehungen Rolle Tourist Zimmerreservierung Anwendungsfall Hotel- Receptionist 44 Grundlagen der Programmierung II

45 Anwendungsfalldiagramm Die Include-Beziehung bezeichnet die Benutzung (das Einschließen) eines Anwendungsfalls durch einen anderen. Dadurch können Teilprozesse eines komplexeren Prozesses modelliert werden. Grafisch wird sie durch eine gestrichelte Linie mit einer offenen Spitze und der Notation «include» ausgedrückt. einschließend «include» eingeschlossen 45 Grundlagen der Programmierung II

46 Anwendungsfalldiagramm Bei einer Grundreinigung muss die Putzkolonne das Zimmer reinigen und die Minibar auffüllen. Reinigung Zimmer grundreinigen «include» «include» Minibar auffüllen Putzkolonne Zimmer reinigen 46 Grundlagen der Programmierung II

47 Anwendungsfalldiagramm Die Extend-Beziehung ermöglicht Erweiterungen von Anwendungsfällen darzustellen, die von bestimmten Bedingungen abhängen. Es handelt sich um optionale Erweiterungen. Grafisch wird diese Beziehung durch eine gestrichelte Linie mit einer offenen Spitze und der Notation «extend» dargestellt. Die Bedingung wird in eine Anmerkung an die extend-beziehung geschrieben (UML 2.0). Bedingung: {condition1} erweitert «extend» erweiternd 47 Grundlagen der Programmierung II

48 Anwendungsfalldiagramm Wird der Anwendungsfall mehrmals erweitert, so muss erkenntlich sein welcher erweiternde Anwendungsfall an welchem extension point ansetzt! UseCase2 «extend» UseCase1 extension points Punkt 1 Punkt 2 «extend» UseCase3 Condition: {condition1} extension point: Punkt 1 Condition: {condition2} extension point: Punkt 2 Ein extension point (z.b. Punkt 1) markiert die Stelle, wo der erweiternde Code eingefügt werden muss. 48 Grundlagen der Programmierung II

49 Anwendungsfalldiagramm Beispiel: Merkt der Receptionist bei der Reservierung, dass ein Zimmer noch nicht gereinigt ist, wird der Prozess um diesen Anwendungsfall erweitert. Reservierung Tourist Zimmer-Reservierung extension point: prüfe Zimmerzustand «Vorbedingung» {Zimmer ungereinigt} «extends» «include» Zimmer grundreinigen «include» Minibar auffüllen Receptionist Zimmer reinigen Putzkolonne 49 Grundlagen der Programmierung II

50 Fragen zur Modellierung Beispiel Reservierung: Was passiert wenn das Zimmer gereinigt wurde, aber der Kunde ist in der Zwischenzeit gegangen ohne zu bezahlen? Wie würden Sie die Bezahlung modellieren? Sollte nicht bei jeder Reinigung geprüft werden ob die Minibar aufgefüllt ist? Was ist wenn wir den Raum putzen möchten ohne die Minibar aufzufüllen? Wann ist ein Model fertig? Wann ist es gut? 50 Grundlagen der Programmierung II