Vorlesung Informatik II

Transkript

1 Vorlesung Informatik II Universität Augsburg Wintersemester 2011/2012 Prof. Dr. Bernhard Bauer Folien von: Prof. Dr. Robert Lorenz Lehrprofessur für Informatik 05. UML: Klassendiagramm 1

2 Klassendiagramm Im Klassendiagramm werden Klassen und ihre Beziehungen zueinander graphisch dargestellt Ein Klassendiagramm beschreibt das statische Datenmodell des Systems Ein Klassendiagramm definiert einen Namensraum für Klassennamen und Objektnamen Beziehungen können Assoziationen und Generalisierungen sein 2

3 Assoziationen Assoziationen beschreiben gleichartige Beziehungen zwischen Objekten Angestellter ist Vorgesetzter von Angestellter Professor betreut Diplomarbeit Menge besteht aus Elementen Verzeichnis ist ein Dateiobjekt 3

4 Assoziationen Assoziationen beschreiben gleichartige Beziehungen zwischen Objekten An einer Assoziation müssen mindestens zwei Objekte beteiligt sein Solche Beziehungen lassen sich in der Regel durch Verben beschreiben Werden grafisch durch Verbindungslinien zwischen den beteiligten Klassen dargestellt 4

5 Assoziationen Assoziationen weisen den beteiligten Klassen Multiplizitäten und Rollen zu können einen beschreibenden Namen besitzen können Navigierbarkeit besitzen können Einschränkungen unterliegen (Datenstruktur-Invarianten) können Eigenschaftswerte haben 5

6 Assoziationen Multiplizität Beschreibt Grenzen für die Anzahl von Objekten der anderen Klasse, die mit einem Objekt der betrachteten Klassen in Beziehung stehen können Wird an das Ende der Verbindunglinie bei der anderen Klasse in folgender Form angegeben: n..m mindestens n, höchstens m Objekte der anderen Klasse stehen mit einem Objekt der betrachteten Klasse in Beziehung Sonderfälle 0..m,n..*,1..m wie bei Attributen 6

7 Assoziationen Rolle Beschreibt die Funktion oder Aufgabe eines Objekts in einer Beziehung Rollen müssen zugewiesen werden, wenn zwischen bestimmten Klassen mehr als eine Assoziation besteht bei reflexiven Assoziationen (zwischen Objekten einer Klasse) Wird an das Ende der Verbindunglinie bei der betrachteten Klasse angegeben 7

8 Assoziationen Name Beschreibt die Art der Beziehung, in der Regel durch ein Verb. Bei binären Assoziationen: <Klassenname> <Assoziationsname> <Klassenname> sollte einen lesbaren Satz ergeben Der Name beschreibt eine Richtung der Beziehung Namen müssen zugewiesen werden, wenn zwischen bestimmten Klassen mehr als eine Assoziation besteht Wird in der Mitte der Verbindunglinie angegeben (mit Pfeil für die Lesrichtung bei binären Assoziationen) 8

9 Assoziationen Navigierbarkeit gibt an, ob Objekte einer betrachteten Klasse auf Objekte anderer an der Beziehung beteiligter Klassen zugreifen können Eine binäre Assoziation kann dabei uni-direktional sein (nur in eine Richtung navigierbar) bi-direktional sein (in beide Richtungen navigierbar) Brauchen Operationen Informationen über assoziierte Objekte? Ja: Navigierbarkeit einfügen Wird grafisch durch Pfeilspitzen in Richtung der Navigierbarkeit an Verbindungslinie angegeben 9

10 Assoziationen Navigierbarkeit In Java gibt es keine Assoziationen Stattdessen werden sog. Referenzattribute benutzt Aufbau einer Objektbeziehung: Dieses Referenzattribut wird mit einem Objekt initialisiert Auf die Daten dieses assoziierten Objekts wird über das Referenzattribut zugegriffen Achtung: Im UML-Modell tauchen diese Referenzattribute NICHT auf 10

11 Assoziationen Assoziationen: Grafische Darstellung <Klassenname> n.. m <rollenname > *.. <rollenname * > <Klassenname> <Klassenname> <assoziationsname> <Klassenname> 11

12 Assoziationen Beispiel: Angestellter ist Vorgesetzter von Angestellter Angestellter Vorgesetzter 1..1 Mitarbeiter 1..* ist Vorgesetzter von > Ein Vorgesetzter hat 1 oder mehrere Mitarbeiter Jeder Mitarbeiter hat genau einen Vorgesetzten Im System kennt der Vorgesetzte seine Mitarbeiter, aber nicht umgekehrt Muss zu fachlichen Gegebenheiten passen 12

13 Assoziationen Beispiel: Professor betreut Diplomarbeit Professor * betreut > betreuer diplomarbeiten Diplomarbeit Ein Professor betreut 0 oder mehrere Diplomarbeiten Eine Diplomarbeit hat genau einen Professor als Betreuer Der Professor kennt die von ihm betreuten Diplomarbeiten, umgekehrt nicht Muss zu fachlichen Gegebenheiten passen 13

14 Assoziationen Verwaltungsoperationen Um Objektbeziehungen herzustellen, zu löschen oder abzufragen benutzt man sog. link-, unlink- und getlink-operationen. Für jede bekannte Beziehung (Navigierbarkeit!) werden standardmäßig solche Operationen eingeführt 14

15 Assoziationen Verwaltungsoperationen: einwertige Beziehungen Eine link-operation stellt eine Beziehung zu einem existierenden Objekt her (es wird kein Objekt erzeugt!) Eine unlink-operation löst die Beziehung zu existierendem Objekt auf (es wird kein Objekt gelöscht!) Eine getlink-operation gibt das in Beziehung stehende Objekt zurück <Klasse1>... link<rolle>(in k:<klasse2>) unlink<rolle>() getlink<rolle>():<klasse2> <n..1> <rolle> <Klasse2> 15

16 Assoziationen Verwaltungsoperationen: mehrwertige Beziehungen Eine link-operation stellt eine Beziehung zu einem existierenden Objekt her (es wird kein Objekt erzeugt!) Eine unlink-operation löst Beziehung zu einem existierenden Objekt auf (es wird kein Objekt gelöscht!) Eine getlink-operation gibt ein in Beziehung stehendes Objekt zurück <Klasse1>... link<rolle>(in k:<klasse2>) unlink<rolle>(in k:<klasse2>) getlink<rolle>(in pos:integer): <Klasse2> <n..*> <rolle> <Klasse2> 16

17 Assoziationen Verwaltungsoperationen: bi-direktionale Assoziationen Entsprechende link-, unlink- und getlink-operationen werden in beide Klassen eingetragen Implementierung: Es muss jeweils auf die wechselseitig konsistente Verwaltung geachtet werden Jede link-operation sorgt für das Herstellen einer Objektbeziehung in beide Richtungen! Jede unlink-operation sorgt für das Löschen einer Objektbeziehung in beide Richtungen! 17

18 Assoziationen Beispiel: Angestellte, Mitarbeiter und Vorgesetzte Angestellter... linkmitarbeiter(in a: Angestellter) unlinkmitarbeiter(in a: Angestellter) getlinkmitarbeiter(in n:integer):angestellter Mitarbeiter 1..* Vorgesetzter 1..1 ist Vorgesetzter von 18

19 Assoziationen Ist das Modell korrekt? Es gibt nie das korrekte oder das beste Modell, sondern immer mehrere verschiedene mögliche Alternativen, einen Sachverhalt zu modellieren Oft muss eine Trade-Off zwischen verschiedenen Kriterien gefunden werden: Beispiel: Weniger Navigierbarkeit > einfacher zu implementieren, aber u.u. eingeschränkte Funktionalität Wichtig: man muss seinen Modellierungsvorschlag begründen können 19

20 Assoziationen Assoziationsklassen Sind Assoziationen mit Attributen, Operationen und Assoziationen zu anderen Klassen Assoziationsklassen können in Assoziationen und eine normale Klasse aufgelöst werden (beachte Anpassung der Multiplizitäten und Navigierbarkeiten) Grafisch wie Klassen, durch gestrichelte Linie mit Assoziationsverbindungslinie verbunden 20

21 Assoziationen Assoziationsklasse: Grafische Darstellung <Klassenname> <Klassenname> <Assklassenname> 21

22 Assoziationen Beispiel: Student leiht Buch aus Student leiht aus 0.. * Buch Ausleihe datum zeitraum Student * Ausleihe datum zeitraum Buch 22

23 Aggregationen Eine Assoziation zwischen zwei Klassen ist eine Aggregation, wenn zwischen den Objekten der beteiligten Klassen eine Rangordnung im Sinne von ist Teil von bzw. besteht aus gilt. Eine der Klassen ist das Ganze, die andere Klasse seine Teile Aggregationen dürfen keine Zyklen bilden Objekte können Teile von mehreren Ganzen sein, existieren also unabhängig vom Ganzen Navigierbarkeit: Das Ganze kennt seine Teile Grafisch dargestellt durch nicht ausgefüllte Raute am Ende der Verbindungslinie zum Ganzen 23

24 Aggregationen Verwaltungsoperationen Dienen der Verwaltung der Teile durch das Ganze Haben andere intuitivere Namen: insert-operation entspricht link-operation remove-operation entspricht unlink-operation get-operation entspricht getlink-operation 24

25 Aggregationen Aggregation: grafische Darstellung <Klassenname> ganzes besteht aus teile <Klassenname> 25

26 Aggregationen Beispiel: Menge aus Objekten einer Klasse Menge... insertelemente(in k:<klasse>) removeelemente(in k:<klasse>) getelemente(in pos:integer):<klasse> 0..* elemente <Klasse> 0..* 26

27 Kompositionen Eine Aggregation ist eine Komposition, wenn ein Objekt nur Teil eines Ganzen sein kann Wird das Ganze gelöscht, werden automatisch auch seine Teile gelöscht Grafisch dargestellt durch ausgefüllte Raute am Ende der Verbindungslinie zum Ganzen Verwaltungsoperationen haben andere intuitivere Namen: add-operation entspricht link-operation delete-operation entspricht unlink-operation get-operation entspricht getlink-operation 27

28 Kompositionen Komposition: grafische Darstellung <Klassenname> 0..1 ganzes teile <Klassenname> 28

29 Kompositionen Beispiel: Verzeichnis besteht aus Dateiobjekten Verzeichnis... addelemente(in d:<dateiobjekt>) deleteelemente(in d:<dateiobjekt>) getelemente(in p:integer):<dateiobjekt> elemente * Dateiobjekt Irgendwas passt hier aber noch nicht: Verzeichnisse sind doch auch Dateiobjekte!? Modell (noch) unvollständig/ungenau (Verbesserung später) 29

30 Mehrwertige Assoziationen Mehrwertige Assoziationen beschreiben Beziehungen zwischen Objekten von drei oder mehr verschiedenen Klassen <Klassenname> <Klassenname> Auch hier ist die Angabe von Rollen und Assoziationsnamen (ohne Richtung) möglich Navigierbarkeit und Multiplizitäten nur eingeschränkt modellierbar Braucht man selten <Klassenname> 30

31 Generalisierung Eine Assoziation zwischen zwei Klassen ist eine Generalisierung, wenn zwischen den Objekten der beteiligten Klassen eine Rangordnung im Sinne von ist ein gilt Generalisierungen dürfen keine Zyklen bilden Generalisierungen erlauben keine Angabe von Navigierbarkeit, Rollen, Multiplizitäten und Namen (diese Eigenschaften sind alle implizit klar) 31

32 Generalisierung Jedes Objekt der sog. Unterklasse ist ein Objekt der sog. Oberklasse Eine Generalisierung beschreibt die Beziehung zwischen einer (allgemeinen) Klasse (Oberklasse) und einer Spezialisierung dieser Klasse (Unterklasse) Grafisch dargestellt durch eine geschlossene, nicht ausgefüllt Pfeilspitze am Ende der Verbindungslinie zur Oberklasse 32

33 Generalisierung Jedes Objekt der sog. Unterklasse ist ein Objekt der sog. Oberklasse Ein Objekt der Unterklasse hat alle Attribute, Operationen und Assoziationen der Oberklasse und enthält zusätzliche Informationen in Form von zusätzlichen Attributen, Operationen und Assoziationen Attribute, Operationen und Assoziationen der Oberklasse werden nicht noch einmal für die Unterklasse angegeben 33

34 Generalisierung Generalisierung: grafische Darstellung <Oberklassenname> <Unterklassenname> <Unterklassenname> 34

35 Generalisierung Beispiel: Dateien und Verzeichnisse sind Dateiobjekte Dateiobjekt 0.. * Datei Verzeichnis Auch hier passt eigentlich noch was nicht: Wird man jemals ein Objekt vom Typ Dateiobjekt erzeugen, das keine Datei oder Verzeichnis ist? Nein! Modellierung als sog. Abstrakte Klasse (später) 35

36 Generalisierung Beispiel: Dateien und Verzeichnisse sind Dateiobjekte Dateiobjekt name erstelldatum 0.. * Datei groesse Verzeichnis freigabe Gemeinsame und spezielle Attribute 36

37 Generalisierung Beispiel: Dateien und Verzeichnisse sind Dateiobjekte Dateiobjekt... kopieren() 0.. * Datei... speichern() Verzeichnis... freigeben() Gemeinsame und spezielle Operationen 37

38 Generalisierung Vererbungsprinzip Die Oberklasse vererbt ihre Attribute, Operationen und Beziehungen an die Unterklasse Ein Objekt der Unterklasse besitzt alle Attribute der Oberklasse Alle Operationen der Oberklasse können über Objekte der Unterklasse aufgerufen werden Ein Objekt der Unterklasse ist an allen Assoziationen der Oberklasse beteiligt Die Objekte einer Klasse kennen alle Oberklassen (aber nicht die Unterklassen!) 38

39 Generalisierung Substitutionsprinzip Objekte von Unterklassen können jederzeit als ein Objekt einer Oberklassen verwendet werden Entspricht einer Typausweitung 39

40 Generalisierung Objekt-Verantwortlichkeitsprinzip Jede Klasse definiert einen Verantwortlichkeitsbereich. Attribute und Operationen werden entsprechend dem Verantwortlichkeitsbereich einer möglichst speziellen Klasse in einer Vererbungshierarchie zugeordnet 40

41 Generalisierung Top-Down-Entwurf einer Vererbungshierarchie: Bildung von Unterklassen durch Addition von Attributen, Operationen und Assoziationen zu einer Klasse Beispiel: Ein Tutor ist eine Spezialisierung eines Studenten 41

42 Generalisierung Bottom-Up-Entwurf einer Vererbungshierarchie: Bildung von Oberklassen durch Zusammenfassen gemeinsamer Merkmale mehrerer Klassen Oft sind das abstrakte Klassen, die nur der Modellierung gemeinsamer Informationen von spezialisierten Klassen dienen, von denen aber keine Objekte erzeugt werden 42

43 Generalisierung Prinzip abstrakter Klassen Klassen, von denen keine Objekte erzeugt werden können oder sollen, heißen abstrakte Klassen Eine abstrakte Klasse stellt gemeinsame Eigenschaften und Operationen für ihre Unterklassen zur Verfügung Darstellung wie Klassen, zusätzliche Schlüsselwort abstract 43

44 Generalisierung Prinzip abstrakter Klassen Klassen, von denen keine Objekte erzeugt werden können oder sollen, heißen abstrakte Klassen Abstrakte Klassen können konkrete Operationen enthalten Abstrakte Klassen enthalten in der Regel abstrakte Operationen, die sie nicht implementieren Unterklassen müssen abstrakte Operationen implementieren Abstrakte Operationen haben in verschiedenen Unterklassen i.d.r. unterschiedliche Implementierung 44

45 Generalisierung Prinzip abstrakter Operationen Werden in der betrachteten Klasse nicht implementiert, sondern nur vereinbart durch Angabe des Prototypen (Signatur) Durch abstrakte Operationen werden gemeinsame Signaturen für Unterklassen definiert. In der Implementierung müssen die Unterklassen die abstrakte Operation durch konkrete Operationen überschreiben Klassen mit abstrakten Operationen müssen auch abstrakt sein 45

46 Generalisierung Beispiel: Dateien und Verzeichnisse sind Dateiobjekte <<abstract>> Dateiobjekt... getname() kopieren() {abstract} 0..* Datei... kopieren() Verzeichnis... kopieren() Implementierung abstrakter Operationen in Unterklassen 46

47 Generalisierung Polymorphismus: Unterklassen können Operationen von Oberklassen überschreiben (redefinieren) und unterschiedlich implementieren Derselbe Operationsaufruf für Objekte verschiedener Klassen einer Vererbungshierarchie führt zur Ausführung unterschiedlicher Operationen (Aufruf für jedes Dateiobjekt o: o.kopieren()) Der Aufrufer muss die genaue Klasse eines Empfängerobjekts (Verzeichnis oder Datei) nicht kennen, sondern nur wissen, dass die Operation zur Verfügung steht (ist ein Dateiobjekt) 47

48 Generalisierung Spätes Binden: Beim Übersetzen des Programms muss für ein Objekt der Oberklasse noch nicht bekannt ist, zu welcher Unterklasse es gehört. Erst zur Laufzeit wird die Operation an das Objekt gebunden. Einheitlicher Aufruf für potentiell unterschiedliche Objekte Dadurch werden Mehrfachauswahlen vermieden Beispiel: for all o in list: o.kopieren() 48

49 Generalisierung Überschreiben vs. Überladen Überladen: Eine Operation kann innerhalb einer Klasse öfter mit verschiedenen Signaturen vorkommen (Operation println() der Klasse PrintStream) Überschreiben: Eine Operation einer Oberklasse kann von einer Operation einer Unterklasse mit gleicher Signatur überschrieben werden 49

50 Generalisierung Überschreiben von Attributen Unterklassen können Attribute von Oberklassen durch Namensgleichheit verbergen In diesem Fall sind beide Attribute vorhanden und das geerbte Attribut ist in der Unterklasse nicht sichtbar Programmiersprachen stellen Notationen für den Zugriff auf verborgene Attribute bereit 50

51 Generalisierung Mehrfachvererbung Grundsätzlich können Objekte von mehreren Klassen erben (mehrere Oberklassen haben) Da dies in Java nicht adäquat abgebildet werden kann, wollen wir in dieser Vorlesung darauf verzichten Vereinbarung: Jede Klasse ist Unterklasse von höchstens einer Oberklasse 51

52 Generalisierung Vorteile: Einfache Modellierung neuer spezialisierter Klassen unter Verwendung existierender Klassen Leichte Durchführbarkeit von Änderungen (Änderungen an einer Oberklasse sind auch für alle Unterklassen wirksam) Nachteile: Zur Kenntnis einer Klasse muss man auch alle ihre Oberklassen kennen Bei Hinzufügen/Änderung einer Oberklasse müssen u.u. auch alle Unterklassen verändert werden 52

53 Schnittstellen Eine Schnittstelle ist eine Sammlung von abstrakten Operationen und konstanten Klassenattributen Schnittstellen dürfen keine konkreten Operationen haben Durch abstrakte Operationen werden gemeinsame Signaturen für Klassen zur Verfügung gestellt. Angabe wie Klassen, zusätzlich mit Schlüsselwort interface Operationen werden nicht extra als abstract gekennzeichnet 53

54 Schnittstellen Klassen können Schnittstellen implementieren Dazu implementieren sie alle spezifizierten Operationen konkret und können die konstanten Klassenattribute benutzen Verschiedene Klassen können dieselbe Schnittstelle auf unterschiedliche Weise implementieren Eine Klasse kann mehrere Schnittstellen implementieren (Ersatz für Mehrfachvererbung) Zwischen Schnittstellen gibt es Generalisierungsbeziehungen Angabe durch gestrichelten Generalisierungspfeil 54

55 Schnittstellen Schnittstellen-Prinzip In der Schnittstelle spezifizierte Operationen können für jede implementierende Klasse auf dieselbe Weise aufgerufen werden (Schnittstellen können als Datentyp benutzt werden) 55

56 Schnittstellen Grafische Darstellung <<interface>> <Schnittstellenname> <Klassenname> <Klassenname> 56

57 Schnittstellen Beispiel: Durchlaufen von dynamischen Feldern (Klassenbibliothek: Iteratormuster) <<interface>> Iterable<E> iterator():iterator<e> <<interface>> Iterator<E> hasnext():boolean next():<e> remove() Vector ArrayList... 57

58 Sichtbarkeiten Für Klassen, Attribute, Operationen und Assoziationen kann man Sichtbarkeiten spezifizieren, die deren Benutzbarkeit durch andere Modellelemente einschränkt + überall sichtbar (public) - innerhalb des eigenen Namensraums sichtbar (private) # innerhalb aller Spezialisierungen des eigenen Namensraums sichtbar (protected) ~ innerhalb des eigenen Pakets sichtbar (package) Wird vor dem Namen angegeben 58

59 Sichtbarkeiten Für Klassen (In welchen anderen Klassen stehen Objekte der Klasse zur Verfügung): + überall sichtbar - innerhalb des eigenen Pakets # nicht benutzbar ~ nicht benutzbar 59

60 Sichtbarkeiten Für Attribute (Objekte welcher Klassen können auf den Attributwert ohne Operation zugreifen): + überall sichtbar - sichtbar in der Klasse # sichtbar innerhalb der Klasse und allen Unterklassen ~ sichtbar im Paket 60

61 Sichtbarkeiten Für Operationen (Objekte welcher Klassen können die Operation aufrufen): + überall sichtbar - sichtbar in der Klasse # sichtbar innerhalb der Klasse und allen Unterklassen ~ sichtbar im Paket 61

62 Sichtbarkeiten Für Assoziationen: Angabe für Rollen + überall sichtbar - sichtbar in der Klasse # sichtbar innerhalb der Klasse und allen Unterklassen ~ sichtbar im Paket 62

63 Sichtbarkeiten Geheimnisprinzip Als Sichtbarkeitsstandard für Attribute und Assoziationen sollte immer wenn möglich private gewählt werden Bei Operationen: Kann man durch Aufruf Datenstrukturinvariante zerstören? Wird die Aufrufbarkeit von außerhalb benötigt? Vorteile: Konsistenzprüfung möglich, bessere Modifizierbarkeit und Wartbarkeit, Schutz von Datenstruktur-Invarianten Nachteile: Zusätzliche Operationen 63

64 Sichtbarkeiten Beispiel: Menge von Objekten einer Klasse implementiert als einfach verkettete Liste Knoten - next start + Liste -size:integer = wert + <Klasse> 64

65 Sichtbarkeiten Beispiel: Menge von Objekten einer Klasse implementiert als einfach verkettete Liste: Geheimnisprinzip? + Knoten + Knoten() + Knoten(wert:<Klasse>) + linkwert(k:<klasse>) + unlinkwert() + getlinkwert():<klasse> + linknext(k:knoten) + unlinknext() + getlinknext():knoten - start Liste - size:integer =0 + Liste() + getsize():integer - setsize(n:integer) - linkstart(k:knoten) - unlinkstart() - getlinkstart():knoten + insert(o:<klasse>)... 65

66 Containerklassen Containerklassen werden zur Verwaltung von Objekten anderer Klassen eingesetzt Eine Containerklasse enthält nur ein Objekt, das Container genannt wird (Beispiel: Listen, dynamische Felder, ). Es enthält die zu verwaltenden Objekte. Es werden Standardoperationen zum Zugriff auf verwaltete Objekte bereitgestellt (Einfügen, Löschen, Suchen) Beziehung des Containers zu der Klasse der verwalteten Objekte ist eine Komposition 66

67 Containerklassen Containerklassen werden durch das sog. Singleton-Muster modelliert Das Singletonmuster stellt sicher, dass höchstens ein Objekt einer Klasse erzeugt werden kann: 1. Konstruktor ist private 2. Verwaltung des Objekts durch ein privates Klassenattribut (unique) [zeigt am Anfang auf null] 3. Zugriff/Erzeugung über öffentliche Klassenoperation (instance), die das Objekt zurückgibt [überprüft, ob Objekt existiert und erzeugt es, falls nicht] 67

68 Containerklassen Grafische Darstellung + <Containerklasse> - unique :<Containerklasse> =null - <Containerklasse>() + instance(): <Containerklasse> alleobjekte 0..* + <Klasse> 68

69 Containerklassen Beispiel: Professoren + ProfessorenContainer - unique :ProfessorenContainer =null - ProfessorenContainer() + instance(): ProfessorenContainer + addprofessor(in p:professor) + deleteprofessor(in p:professor) + getprofessor(in p:integer):professor - alleprofessoren * + Professor 69

70 Containerklassen Containerklassen erhalten die Klassenattribute und operationen der verwalteten Klasse als Objektattribute und -operationen <Containerklasse> <Klasse> <Attribut> <Operation>() <Attribut> <Operation> - alleobjekte <Klasse> * 70

71 Containerklassen Beispiel: Klassenattribute und operationen <Containerklasse> <Klasse> anzahl getanzahl() anzahl getanzahl() - alleobjekte <Klasse> * 71

72 Muster Muster sind generische Lösungen für wiederkehrende Entwurfsprobleme Erhöhen die Standardisierung und damit die Qualität und Wartbarkeit des Entwurfs und der Software Muster werden durch Klassendiagramme beschrieben Beispiel: Singletonmuster, falls es höchstens ein Objekt einer Klasse geben soll In der Praxis: Vielzahl von Mustern In dieser Vorlesung: 2-3 exemplarische Muster 72