Programmierkurs. 13. Vorlesung. Sven Mallach. 27. Januar Institut für Informatik - Lehrstuhl Prof. Dr. M. Jünger 1/ 69

Transkript

1 Programmierkurs 13. Vorlesung Sven Mallach Institut für Informatik - Lehrstuhl Prof. Dr. M. Jünger 27. Januar / 69

2 UML Teile der Vorlesungsfolien dieses Kapitels enthalten Grafiken und Inhalte aus dem Buch: Heide Balzert - Lehrbuch der Objektmodellierung 2. Auflage, 2005, Elsevier Verlag. 2/ 69

3 UML Was ist UML? UML bedeutet Unified Modelling Language und ist ein Standard zur graphischen Darstellung von Programmbestandteilen wie Klassen, Methoden und Attributen und der Modellierung der Beziehungen zwischen ihnen. Die aktuelle Version des UML-Standards ist die Version 2.0. Wir behandeln heute insbesondere die Diagrammformen, mit denen sich o.g. Dinge anschaulich visualisieren lassen. 3/ 69

4 UML Warum UML? Im wesentlichen 2 Gründe: Einerseits dienen UML-Diagramme der Veranschaulichung und ermöglichen es, Programmbestandteile einfach und kompakt darzustellen und unter Entwicklern auszutauschen. Andererseits werden insbesondere größe Softwareprojekte vor Schreiben der ersten Zeile Quellcode erstmal sehr ausführlich geplant. Auch dies geschieht häufig mit Modellierungswerkzeugen wie UML. Die Kenntnis dieser Konzepte bildet für Sie eine Grundlage im Umgang mit typischer Programmierer-Literatur und professionellen Entwicklern. 4/ 69

5 UML - Notation für Klassen Eine Klasse wird in UML auf folgende dreiteilige Art und Weise dargestellt: Klassenname Attribute Methoden 5/ 69

6 UML - Notation für Klassen Für Attribute und Methoden kann zusätzlich ihr Zugriffsmodifizierer modelliert werden, indem vor den Bezeichner eines der folgenden Symbole (gefolgt von einem Leerzeichen) angegeben wird. Symbol Modifizierer + public # protected - private ~ package-private 6/ 69

7 UML - Notation für Klassen Es gibt noch weitere Feinheiten in der Darstellung: Klassenattribute und -Methoden (static) werden unterstrichen. Für Attribute kann eine Multiplizität angegeben werden, die definiert, wieviele Werte ein solches Attribut speichern können soll. Dies dient insbesondere der Modellierung von Arrays und Vektoren, bzw. Listen. Attributen kann außerdem ein Startwert zugewiesen werden. Bei abstrakten Klassen wird der Klassenname kursiv gestellt 7/ 69

8 UML - Notation für Klassen Beispiele für Multiplizitäten: Attribut Bedeutung note: float [0..10] 0 bis 10 Noten sollen gespeichert werden können note: float [1..10] Höchstens 10 können, aber mindestens 1 Note muss gespeichert werden note: float [0..*] Die obere Schranke kann nicht festgelegt werden note: float [1..1] Verstärkter Ausdruck, dass es genau eine Note sein muss Außerdem möglich Startwert: note: float = 1.0 Angabe von zusätzlichen Eigenschaften mittels geschweifter Klammern, etwa: note: float {readonly} 8/ 69

9 UML - Notation für Objekte Wie wir wissen können (nicht-abstrakte) Klassen instantiiert werden, es gilt daher auch Objekte darstellen zu können. Wenn man einen Schnappschuss der Zustände eines Programms zur Laufzeit darstellen möchte, kann man Objekte konkret benennen. Für eine beispielhafte Referenzbeschreibung eines Objekts ist dies in der Regel aber nicht notwendig. 9/ 69

10 UML - Notation für Objekte Ein Objekt wird in UML auf folgende Art und Weise dargestellt: Klassenname Attribute Der Name des Objekts kann optional vor dem Doppelpunkt in der Kopfzeile angegeben werden. Auf die erneute Darstellung der Methoden der Klasse wird hier aus offensichtlichen Gründen verzichtet. 10/ 69

11 UML Zwischen Klassen oder Objekten können Beziehungen bestehen. In UML nennen wir solche Beziehungen auch Assoziationen. Zwischen konkreten Objekten besteht in der Regel eine direkte 1-zu-1-Beziehung, d.h. ein Objekt besitzt ein anderes als Attribut. Zwischen Klassen kann es auch eine 1-zu-viele-Beziehung geben, die in UML erneut mit Hilfe von Multiziplitäten ausgedrückt wird. 11/ 69

12 UML - Objektdiagramm Ein kleines Objektdiagramm mit Assoziationen: 12/ 69

13 UML - Klassendiagramm Ein sehr kleines Klassendiagramm mit Assoziationen: 13/ 69

14 UML - Klassen- und Objektdiagramme Multiziplitäten für Klassen- und Objektdiagramme: 14/ 69

15 UML - Assoziationsklassen Wenn eine Assoziation zwischen Objekten zweier Klassen eine feste Struktur hat und ebenfalls in Attributen bzw. einer Klasse ausgedrückt werden kann, so kann man zur Modellierung eine Assoziationsklasse verwenden. 15/ 69

16 UML - spezielle Assoziationen Neben der allgemeinen Assoziation, die die Art der Beziehung zwischen Objekten und Klassen noch wenig spezifiziert (aber auch durch Texte an den Linien bereichert werden darf), gibt es drei weitere spezielle Formen in der UML: Aggregation Komposition Generalisierung 16/ 69

17 UML - Aggregation Eine Aggregation drückt aus, das eine Klasse aus mehreren Teilen zusammengesetzt ist. Ihre Objekte können nicht ohne ihre Bestandteile existieren. Eine Aggregation wird mittels einer transparenten Raute an der jeweiligen Klasse ausgedrückt. Als Beispiel betrachten wir etwa ein Buch, welches aus Teilen (den Kapiteln) zusammengesetzt ist. 17/ 69

18 UML - Aggregation 18/ 69

19 UML - Komposition Eine Komposition ist eine sehr starke Aggregation. Die zusätzlichen Anforderungen sind: Jedes Objekt einer Teilklasse kann - zu einem Zeitpunkt - nur Komponente eines einzigen Objekts der Aggregat-Klasse sein. Bei der Erzeugung des Aggregat-Objekts können auch Teil-Objekte erzeugt werden. Bei Zerstörung des Aggregat-Objekts können automatisch auch Teile von ihm gelöscht werden. Eine Komposition wird mittels einer intransparenten (ausgefüllen / schwarzen) Raute an der jeweiligen Klasse ausgedrückt. Als Beispiel betrachten wir etwa ein Verzeichnis, welches aus Teilen (den enthaltenen Dateien) zusammengesetzt ist. Wird es gelöscht, werden auch alle enthaltenen Dateien gelöscht. 19/ 69

20 UML - Komposition 20/ 69

21 UML - Generalisierung Wie der Name schon andeutet, modelliert die Generalisierung exakt das Vererbungskonzept objektorientierter Programmiersprachen. Das generalisierte Objekt entspricht der Basisklasse, die Subklassen sind die Spezialisierungen. Ein Subklassen-Objekt ist ein Objekt der generalisierenden Klasse. Eine Generalisierung wird mittels ein transparentes Dreieck an der generalisierenden Klasse ausgedrückt. 21/ 69

22 UML - Generalisierung 22/ 69

23 UML - Anwendungsfälle Neben der reinen Modellierung von Programmbestandteilen und ihren Zusammenhängen, kann mit Hilfe von UML auch die Verwendung eines Programms modelliert werden. Eine typische (und intendierte) Verwendung eines Programms, nennt man einen Anwendungsfall, engl. Use Case. Ein Anwendungsfall besteht aus: einem oder mehreren Akteuren (Personen oder Systeme), die nicht Bestandteil des Programms sind, sondern von außen mit ihm interagieren und einer Sequenz von Aktionen, etwa Aufrufe von Methoden angelegter Objekte. 23/ 69

24 UML - Anwendungsfälle Ein Anwendungsfalldiagramm beschreibt nun, welche Art von Akteuren welche Interaktionen mit dem Programm ausführen (sollen). 24/ 69

25 UML - Anwendungsfälle Ähnlich wie Klassen können Anwendungsfälle auch spezialisiert werden. Die Darstellung einer Generalisierung erfolgt wie beim Klassendiagramm. 25/ 69

26 UML - Anwendungsfälle Unter Verwendung von gestrichelten Linien zwischen Anwendungsfällen und den Schlüsselworten <<include>> - Enthaltenseins-Beziehung - modelliert Aufruf einer untergeordneten Prozedur <<extends>> - Erweiterungs-Beziehung - Erweiterung einer Basisfunktionalität, ggf. unter Angabe von Bedingungen, wann die erweiterte Funktionalität zu verwenden ist. können weitere Feinheiten in Anwendungsfalldiagrammen beschrieben werden. 26/ 69

27 UML - Aktivitäten Stark mit der Idee eines Anwendungsfalls verbunden ist das Konzept der Aktivitäten. Eine Aktivität ist ein zusammengehöriger Kontrollfluss, wie er bei der Verwendung eines Programms entsteht oder entstehen soll. Aktivitäten können mit Hilfe von Aktivitätsdiagrammen modelliert werden. 27/ 69

28 UML - Aktivitätsdiagramm Startsymbol Bedingung Zusammenführung Aktion Verzweigung Endsymbol Ereignis-Sender Ereignis-Empfänger 28/ 69

29 UML - Sequenzdiagramme Eine weitere Möglichkeit Programmabläufe zu modellieren und dabei nun die Interaktion konkreter Objekte mit einzubinden, ist das Sequenzdiagramm. Sequenzdiagramme beinhalten die Lebensdauer von Objekten und zeigen, welche Informationen sie untereinander (durch Methodenaufrufe, -Parameter, und -Rückgabewerte) austauschen. 29/ 69

30 UML - Sequenzdiagramme 30/ 69

31 UML - Sequenzdiagramme - Beispiel 31/ 69

32 UML - Zustandsdiagramme 32/ 69

33 Entwurfsmuster (Design Patterns) Die Vorlesungsfolien dieses Kapitels basieren auf dem Standardwerk der Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley, / 69

34 Entwurfsmuster Was sind Entwurfsmuster? Viele Aufgaben und Probleme wiederholen sich in der Programmierung immer und immer wieder. Ob innerhalb eines Programms oder in verschiedenen Programmen, so orientiert sich beispielsweise der Aufbau einiger Klassen immer nach einem mehr oder weniger gleichen Schema. Entwurfsmuster bieten eine standardisierte, bewährte, generische und programmiertechnisch saubere Lösung für viele typische Klassenentwurfsprobleme. Kernziel sind etwa Vermeidung von redundantem Code, Erweiterbarkeit, Modularität und andere programmiertechnische Gesichtspunkte. 34/ 69

35 Mustertypen Klassifikation von Entwurfsmustern nach ihrem Anwendungsbereich: Klassenmuster beschreiben Beziehungen zwischen Klassen und bauen vorrangig Vererbungsstrukturen auf. Die Strukturen sind damit zur Übersetzungszeit festgelegt. Objektmuster nutzen vorrangig Assoziationen und Aggregationen zur Beschreibung von Beziehungen zwischen Objekten. Die durch sie beschriebenen Strukturen zwischen Objekten sind zur Laufzeit dynamisch änderbar. 35/ 69

36 Mustertypen Hinsichtlich ihrer konkreten Aufgaben wird außerdem noch eine weitere Klassifikation von Entwurfsmustern vorgenommen. Erzeugungsmuster - Helfen, ein System unabhängig davon zu machen, wie seine Objekte erzeugt, zusammengesetzt und repräsentiert werden. Strukturmuster - Erlauben den strukturierten Aufbau größerer Klassen und Objekte aus kleineren Teilen. Verhaltensmuster - Helfen, die Interaktion zwischen Objekten in den Fokus der Implementierung zu legen. 36/ 69

37 Erzegungsmuster 1. Erzeugungsmuster Hier behandelt: Factory Singleton 37/ 69

38 Erzeugungsmuster - Factory Das Klassen-Erzeugungsmuster Factory wird auch Fabrikmethode oder virtueller Konstruktor genannt (virtuelle bzw abstrakte Konstruktoren sind in direkter Form weder in C++ noch in Java erlaubt). Ein anschauliches Anwendungsszenario thematisiert ein Framework für verschiedene Anwendungen, die verschiedene Dokumenttypen bearbeiten können. Es liegt eine Aggregation derart vor, dass die Anwendung (z.b. geöffnete oder neue) Dokumente verwaltet. Man möchte gerne abstrakte Klassen Anwendung und Dokument erstellen, welche die Interaktionen bereits implementieren. D.h. die Klasse Anwendung soll beispielsweise Funktionen wie NewDocument() oder OpenDocument() bereitstellen, wie sie üblicherweise in der Menüleiste zur Verfügung stehen. 38/ 69

39 Erzeugungsmuster - Factory Problem: Die Klasse Anwendung kennt nur die abstrakte Klasse Dokument, aber keine konkreten Dokumenttypen. Folglich kann sie für NewDocument() keine Instantiierung vornehmen. 39/ 69

40 Erzeugungsmuster - Factory Das Factory-Pattern ermöglicht nun, diese Aufgabe an konkrete Anwendungsklassen zu delegieren. Anstatt eines Konstruktoraufrufs der Form new Document() definiert die Klasse Anwendung eine abstrakte Methode CreateDocument(), welche man die Fabrikmethode nennt. 40/ 69

41 Erzeugungsmuster - Factory Diese Fabrikmethode kann nun von konkreten Anwendungen für konkrete Dokumenttypen überschrieben werden. Auf Grund der Vererbungsbeziehung ist jedes konkrete Dokument ein Objekt vom Typ Document, welches die abstrakte Fabrikmethode in der Klasse Anwendung zurückliefern kann. 41/ 69

42 Erzeugungsmuster - Factory Sämtliche Funktionalität, die bereits in der abstrakten Basisklasse definiert wurde, kann entweder einfach übernommen oder in der Subklasse spezialisiert werden (dynamische Bindung). Das Erweitern um zusätzliche Anwendungen und Dokumente reduziert sich somit im Idealfall auf die Implementierung der jeweiligen CreateDocument()-Fabrikmethode und des neuen Dokumenttyps. 42/ 69

43 Erzeugungsmuster - Singleton Ein wichtiger Vertreter der Objekt-Erzeugungsmuster ist Singleton. Dieses Konzept sorgt dafür, dass zur Laufzeit des Programms immer nur eine Instanz einer bestimmten Klasse existieren kann. Singleton stellt eine saubere Alternative zu statischen globalen Variablen dar und findet Verwendung bei allen Klassen, die nur einmalig instantiiert werden sollen. Ein klassisches Beispiel für Klassen, von denen nur ein Objekt benötigt wird, sind Kontroll- und Managementklassen, wie z.b. ein Speichermanager. Ebenso sind Hauptfenster einer graphischen Oberfläche natürliche Kandidaten für Singletons. 43/ 69

44 Erzeugungsmuster - Singleton 44/ 69

45 Erzeugungsmuster - Singleton Singleton-Implementierung in Java: public class Singleton { private static Singleton instance = null; private Singleton() { } public static Singleton instance() { if (instance == null) instance = new Singleton(); } } return instance; 45/ 69

46 Strukturmuster 2. Strukturmuster Hier behandelt: Composite 46/ 69

47 Strukturmuster - Composite Der Anwendungsfall für das Kompositum (Composite) ist eine Klasse, die Objekte unterschiedlicher Subklassen einer abstrakten Basisklasse verwaltet, und selbst eine solche Subklasse ist. Es geht also um die rekursive Verschachtelung von Objekten, die entweder sich selbst oder anderweitig spezialisierte Objekte eines gleichen Basistyps beinhalten. 47/ 69

48 Strukturmuster - Composite Als anschauliches Beispiel dient eine Klasse zur Repräsentation graphischer Bausteine, wie Linien, Rechtecke und Bildern, die alle von einer abstrakten Basisklasse Graphic abgeleitet sind. 48/ 69

49 Strukturmuster - Composite In der Klasse Picture kann nun etwa ein Array von Graphic-Objekten verwaltet werden, die anschließend gezeichnet werden sollen. Dabei kann ein solches Graphic-Objekt auch eine Instanz von Picture sein, welches seinerseits wieder alle möglichen Subtypen von Graphic in einem Array beinhalten kann. 49/ 69

50 Strukturmuster - Composite Es liegt also gleichermaßen eine Aggregation sowie Generalisierungsbeziehungen vor. Diese (auch rekursiv mögliche) Verschachtelung von Objekten kann man sich in etwa folgermaßen vorstellen: 50/ 69

51 Verhaltensmuster 3. Verhaltensmuster Hier behandelt: Observer Visitor 51/ 69

52 Verhaltensmuster - Observer Das Observer-Muster kommt in der Regel zum Einsatz, wenn eine Eins-zu-viele-Beziehung mit starken Abhängigkeiten vorliegt. Die Idee ist es, die Implementierung derart anzupassen, dass wenn sich das beobachtete Objekt verändert, alle davon abhängenden Klassen automatisch über diese Veränderung benachrichtigt werden. Es handelt sich also um ein Objektmuster. 52/ 69

53 Verhaltensmuster - Observer Die Implementierung erfolgt derart, dass die beobachtete Klasse (Subject) eine Schnittstellen-Methode anbietet, über die sich alle ihre Beobachter registrieren können. Alle Klassen, deren Objekte über Änderungen informiert werden sollen, implementieren nun ein gemeinsames Observer-Interface. Anschließend können sich die Objekte selbst mittels o.g. Methode bei der Subject-Klasse als Beobachter registrieren. 53/ 69

54 Verhaltensmuster - Observer Findet nun eine Änderung des Zustands in Subject statt, ruft diese die Methode notify() auf, welche ihrerseits für alle registrierten Observer die update() auslöst. Folglich können diese Objekte nun den neuen Zustand auslesen und somit auf dem aktuellen Stand bleiben. 54/ 69

55 Model-View-Controller Das Verhaltensentwurfsmuster Model-View-Controller (MVC) ist ein Spezialfall des Observer-Modells, welches insbesondere im Zusammenhang mit graphischen Benutzeroberflächen häufig Anwendung findet. Ziele / Eigenschaften des Musters sind insbesondere: Einfache Erweiterbarkeit um neue Ansichten auf dieselben Daten Strikte Trennung von Datenzugriff und Ansicht Zentrale Bündelung der Interaktion zwischen Programm und Benutzer 55/ 69

56 Model-View-Controller - View Die View-Komponente(n) dieses Musters entsprechen in aller Regel Fenstern oder Bestandteilen von Fenstern, die eine gewisse Information graphisch darstellen / aufbereiten. Beispiel: Verschiedene Diagramme zu Wahlergebnissen, die bei Änderung der Prognose alle aktualisiert werden sollen. Es bietet sich daher an, eine Anzeige als Observer zu implementieren. Sie registriert sich als Beobachter des Datenmodells und wird folglich über Änderungen benachrichtigt, auf die sie dann reagiert. 56/ 69

57 Model-View-Controller - Model Das Modell hat in diesem Muster folgende Funktionen: Kapselung sämtlicher Daten und Datenbanken Bereitstellen von Interface-Methoden zur kontrollierten Modifikation dieser Daten Benachrichtigen der observierenden (registrierten) Objekte 57/ 69

58 Model-View-Controller - Controller Der Controller stellt die zentrale Verwaltungseinheit dieses Entwurfsmusters dar. Verursacht der Benutzer oder ein externes Ereignis Änderungen der Modelldaten, so nimmt der Controller diese entgegen und führt diese Änderungen durch Aufruf der Modell-Interfacemethoden durch. 58/ 69

59 Model-View-Controller - Controller Die Interface-Methoden des Modells, die eine Änderung der Daten nach sich ziehen, rufen nun intern die update()-funktion aller registrierten Beobachter (Views) auf. Auch der Controller kann selbst ein Beobachter sein (etwa könnte durch ein erstmaliges Eingeben von Daten eine Speicherfunktion im Menü aktiviert werden.) 59/ 69

60 Model-View-Controller - Controller Sind alle Änderungen propagiert und die Ansichten / Steuerungskomponenten aktualisiert, kann die Kontrolle an den Benutzer zurückgegeben und auf das nächste Ereignis gewartet werden. Abbildung: Model-View-Controller (aus Frank Buschmann - Pattern-orientierte Software-Architektur) 60/ 69

61 Verhaltensmuster - Visitor Zu guter letzt betrachten wir das Besucher-Modell, engl. Visitor, welches ebenfalls ein Objektmuster ist. Visitor findet Anwendung, wenn eine Klassenhierarchie aus vielen Subklassen besteht, auf deren Objekten dieselben Funktionen ausgeführt werden sollen, diese sich in ihrer Implementierung aber stark unterscheiden. 61/ 69

62 Verhaltensmuster - Visitor Natürlich kann in diesem Fall von einer abstrakten Klasse vererbt werden, jedoch muss (nahezu) jede Methode überschrieben werden. Insbesondere aber führt das Hinzufügen neuer Methoden dazu, dass alle implementierenden Klassen überarbeitet werden müssen. Visitor trennt Klassen und ihre Operationen (Methoden), indem es sie in eigens dafür vorgesehene Besucher-Klassen auslagert. 62/ 69

63 Verhaltensmuster - Visitor Anschaulich und stark abstrahiert könnte man in etwa sagen, dass Visitor aus einer nachfolgenden Klassendefinition public class Klasse { void methode() {... } } so etwas macht: public class VisitorClass implements Visitor { void methode (Klasse k) {... } } 63/ 69

64 Verhaltensmuster - Visitor Doch wie funktioniert das im großen Stil und im Zusammenspiel mit Vererbungshierarchien? Wir sagen, dass eine Klasse aus der Hierarchie ein Visitor-Objekt akzeptieren muss. Dazu implementiert diese Klasse eine Methode accept(visitor v), welche folglich für sämtliche implementierenden Klassen von Visitor verwendet werden kann. accept() macht nun nichts anders, als im Visitor die Methode aufzurufen, die sonst Teil der Klasse gewesen wäre. Für jeden Visitor, den wir accept() übergeben, wird also dessen Methode aufgerufen, die für die jeweilige Klasse gedacht ist. 64/ 69

65 Verhaltensmuster - Visitor 65/ 69

66 Verhaltensmuster - Visitor Werden nun Objekte der Klassenhierarchie erzeugt, wird diesen ein (oder mehrere) Visitor-Objekt(e) übergeben, welche(s) die für sie passende Implementierung ihrer Methoden enthält. Wird eine Operation verändert, muss dies lediglich im Rahmen der Visitor-Klasse erfolgen, alle anderen Klassen bleiben unberührt. Ähnlich ist es für das Hinzufügen neuer Methoden. In diesem Fall kann ein neue Klasse von Visitor abgeleitet und für diese bei den erzeugten Objekten die accept() Methode aufgerufen werden. 66/ 69

67 Verhaltensmuster - Visitor Zur etwas anschaulicheren Darstellung, folgt nun eine einfache Beispielimplementierung mit 2 besuchbaren Klassen und einem TestVisitor. Zunächst das Interface des Visitors: interface Visitor { void method(visitableclass1 vc1); void method(visitableclass2 vc2); } 67/ 69

68 Verhaltensmuster - Visitor Nun das Interface der besuchbaren Klassen: interface Visitable { void accept(visitor v); } und die Implementierung einer der beiden Klassen: public class VisitableClass1 implements Visitable { public VisitableClass1() { System.out.println("Visitable1-Object created"); } public void accept(visitor v) { v.method(this); } 68/ 69

69 Verhaltensmuster - Visitor Was nun noch fehlt ist der konkrete TestVisitor: public class TestVisitor implements Visitor { public void method(visitableclass1 vc1) { System.out.println("Called Visitor-Method for VisitableClass1"); } public void method(visitableclass2 vc2) { System.out.println("Called Visitor-Method for VisitableClass2"); } public static void main (String[] args) { VisitableClass1 vc1 = new VisitableClass1(); VisitableClass2 vc2 = new VisitableClass2(); TestVisitor tv = new TestVisitor(); } } vc1.accept(tv); vc2.accept(tv); 69/ 69