Software Engineering Klassendiagramme Assoziationen

Transkript

1 Software Engineering Klassendiagramme Assoziationen Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1

2 Lesen von Multiplizitäten (1) Multiplizitäten werden folgendermaßen gelesen: Man betrachtet ein Objekt einer bestimmten Klasse (hier das Personenobjekt) Dann schaut man im Klassendiagramm am gegenüberliegenden Ende der Assoziation nach, wie viele Objekte der anderen Klasse verbunden sein dürfen. Hier: Es dürfen beliebig viele Buchobjekte mit der Person verbunden sein. Person1 ist mit zwei Buch-Objekten verbunden, das ist also okay 2

3 Lesen von Multiplizitäten (2) Umgekehrt geht es genauso: Man betrachtet ein Objekt einer bestimmten Klasse (jetzt das Buchobjekt) Am gegenüberliegenden Ende sieht man, dass null oder ein Person- Objekte als Autor verbunden sein dürfen Buch1 ist mit einem Person-Objekt verbunden, das ist also okay 3

4 Multiplizitäten Klassen und Objekte Klassen Objekte 2 Bücher 1 Autor 1 Autor 1 Buch 1 Autor 0 Bücher Beliebig viele Bücher pro Person 0 Autoren Jedes Buch hat 0 oder 1 Autoren 4

5 Erlaubt? Klassen Objekte Dieses Buch hat zwei Autoren, es ist aber nur maximal einer erlaubt! public class Buch { private String titel; private int seitenzahl; private Person autor; Durch die Implementierung in Form eines gewöhnlichen Attributs wird dieser Fehler bereits verhindert. Man kann hier nur ein Personenobjekt zuordnen. public Buch(String titel, int seitenzahl, Person autor){ 5

6 Geändertes Klassendiagramm Nun wollen wir mehrere Autoren zulassen, allerdings keine Bücher ohne Autoren. Umgekehrt wollen wir nur noch Personen berücksichtigen, die mindestens ein Buch geschrieben haben: 6

7 Objekte zum geänderten Klassendiagramm Klassen Objekte Nach wie vor Erlaubt! 7

8 Objekte zum geänderten Klassendiagramm Jetzt ebenfalls erlaubt: Buch mit mehreren Autoren Nicht mehr erlaubt: Person ohne Buch Buch ohne Autor 8

9 Noch eine Änderung volle Freiheit Objekte Jetzt ist alles erlaubt: 9

10 Multiplizitäten Häufig verwendet: 1 genau eins 0..1 null oder eins * beliebig viele (auch null), auch die Angabe 0..* ist möglich 1..* mindestens eins Auch möglich, aber selten verwendet: andere Zahlen 2 genau zwei , 1, 2, 3 oder 4 2, 4, 6 2, 4 oder , 4, 6..* alles außer 3 und 5 10

11 Implementierung der Multiplizität * Falls man direkt von der Person zu ihren Büchern navigieren möchte: Navigierbarkeit von der Person zu ihren Büchern Da mehrere Bücher zugeordnet werden können, genügt ein gewöhnliches Attribut vom Typ Buch nicht. Lösung: Liste verwenden 12

12 Implementierung der Multiplizität * mit einer Liste (1) Import eines geeigneten Listen-Typs aus den Java Collections. Im import java.util.arraylist; Unterschied zu einem Array muss public class Person { man bei der ArrayList keine private String vorname; Maximalgröße festlegen private String nachname; private ArrayList<Buch> werke = new ArrayList<Buch>(); } Typisierte ArrayList. Sie kann nur Objekte der Klasse Buch aufnehmen. Anlegen des ArrayList-Objekts. Nicht vergessen! 13

13 Implementierung der Multiplizität * mit einer Liste (2) Jetzt kann man in der Klasse Person Bücher hinzufügen: public void addbuch(buch buch){ werke.add(buch); } Und man kann z. B. alle Bücher einer Person ausgeben lassen: public void print(){ for(buch b:werke){ b.print(); } } Das wäre extrem umständlich zu realisieren, wenn die Assoziation in die andere Richtung implementiert wäre. 14

14 Anlegen und Zuordnen von Objekten Person autor1 = new Person("George", "Orwell"); Person autor2 = new Person("Douglas", "Adams"); Buch buch1 = new Buch("Farm der Tiere", 132); Buch buch2 = new Buch("1984", 383); Buch buch3 = new Buch("Per Anhalter durch die Galaxis", 208); autor1.addbuch(buch1); autor1.addbuch(buch2); autor2.addbuch(buch3); autor1.print(); autor2.print(); 15

15 Welche Navigationsrichtung sollte man implementieren? Es sollte die Navigationsrichtung implementiert werden, in die man häufig zugreifen muss Falls Zugriff in beide Richtungen nötig, gibt es zwei Möglichkeiten: Implementierung nur einer Richtung. Wenn der Zugriff in die andere Richtung nötig ist, werden alle Objekte der anderen Klasse durchsucht, ob sie eine Beziehung zum betreffenden Objekt haben. Nachteil: Hoher Aufwand für den Zugriff. Implementierung in beide Richtungen, d. h. beide Klassen haben ein Attribut bzw. eine Liste mit Objekten der anderen Klasse. Nachteil: Hoher Aufwand beim Einfügen und Entfernen von Beziehungen, da die zugeordneten Objekte immer auf beiden Seiten ein- bzw. ausgetragen werden müssen. 16

16 Wie oft kann dasselbe Objekt an einer Assoziation teilnehmen? In vielen Fällen ist es klar Ein bestimmter Autor kann ein bestimmtes Buch geschrieben haben oder nicht Dennoch könnte man dasselbe Buch-Objekt mehrfach in die Liste werke einordnen: Einfach durch mehrfachen Aufruf der Methode addbuch : autor2.addbuch(buch3); autor2.addbuch(buch3);? 17

17 Eigenschaft {unique} Wenn ein Assoziationsende die Eigenschaft unique hat, dann kann jedes Objekt maximal einmal teilnehmen: {unique} Um diese Eigenschaft tatsächlich sicherzustellen, muss man überprüfen, ob das Objekt bereits in der Liste ist: public void addbuch(buch buch){ if(!werke.contains(buch)){ werke.add(buch); } } Alternative: Nutzung eines HashSet oder TreeSet anstelle einer ArrayList (diese erlauben keine doppelten Einträge) Normalerweise geht man davon aus, dass Assoziationen unique sind. {unique} gibt man daher nur an, wenn besonders darauf hingewiesen werden soll. 18

18 Nicht-unique Assoziation Eine Verlosung hat einen Einsatz von 1. Wenn man seine Chancen erhöhen möchte, darf man auch mehr setzen. Für jeden Euro erhält man einen weiteren Eintrag in der Liste der jeweiligen Spielrunde. {bag} Zwei Arten von nicht-uniquen Assoziationen: {bag} ungeordnet {sequence} oder {seq} geordnet Es gibt auch die Möglichkeit, explizit {non-unique} anzugeben Keine Aussage über Ordnung getroffen (entspricht also {bag}) 19

19 Eigenschaft {ordered} Oft ist es egal, in welcher Reihenfolge die Objekte in der Liste stehen: In manchen Fällen ist dies aber durchaus wichtig: {ordered} Es ist ja nicht nur wichtig, dass ein Titel in den Charts ist, sondern auch auf welchem Platz er steht. Konsequenz für die Implementierung: Beim Einfügen von Objekten muss auf die Reihenfolge geachtet werden, z. B. müssen die nachfolgenden Objekte verschoben werden. {ordered} beinhaltet zugleich {unique}, d. h. jeder Titel ist nur einmal in den Charts 20

20 Beispiel für eine {sequence} In einem Verein können sich die Mitglieder auf eine Liste als Helfer für verschiedene Aktivitäten eintragen lassen. Die Helfer kommen in der Reihenfolge der Liste zum Einsatz. Dabei ist es auch möglich, sich mehrfach auf die Liste setzen zu lassen. So könnte der erste auf der Liste sich bereits wieder hinten für einen späteren Einsatz eintragen lassen. Die Liste könnte z. B. so aussehen: Peter, Paul, Maria, John, Peter, Maria, John, Paul, Peter, Die Liste ist also geordnet und kann Mehrfacheinträge enthalten. Dies wird durch die Eigenschaft {sequence} oder {seq} ausgedrückt {sequence} 21

21 Eigenschaften von Assoziationen Zusammenfassung Geordnet Ungeordnet Keine Mehrfacheinträge Mehrfacheinträge zulässig {sequence}, {seq} 22

22 Zusätzliche Folien 24

23 Wiederholung Welches sind die häufigsten Multiplizitätsangaben und was bedeuten sie jeweils? 25

24 Wiederholung Wie kann man eine Assoziation mit der Multiplizität * implementieren? 26

25 Wiederholung Was bedeutet die Navigationsrichtung einer Assoziation? 27

26 Wiederholung Welchen Vorteil hat es, wenn eine Assoziation in beide Richtungen navigierbar ist? 28

27 Wiederholung Welchen Nachteil hat es, wenn eine Assoziation in beide Richtungen navigierbar ist? 29

28 Wiederholung Was bedeutet die Eigenschaft {unique} bei einer Assoziation? Wie stellt man diese Eigenschaft bei der Implementierung sicher? 30

29 Wiederholung Was bedeutet die Eigenschaft {ordered} bei einer Assoziation? 31

30 Wiederholung Wie stellt man diese Eigenschaft {ordered} durch die Implementierung sicher? 32