Übungsaufgabe UML

[HansOne]

Hallo, hab hier versucht eine Textaufgabe in ein UML-Diagramm umzuwandeln. Ich bin mir jedoch überhaupt nicht sicher in wieweit ich das richtig gemacht habe. :blink:

Würde mich über Hilfe sehr freuen!
Danke

----------------------------------------
Anhänge:
- Aufgabe
- UML-Diagramm

[essenfeger]

1) falls du korrigierst, nicht editieren sondern neu posten -> Veränderungen bleiben sichtbar

* Klassennamen sind in Einzahl. IMMER!
* statt der Kompositionen sollte man lieber Aggregationen nehmen (is aber nicht soo schlimm)
* Multiplizität bei Kategorie-Fahrzeug: ein Fahrzeug hat eine Kategorie; eine Kategorie bestimmt den Preis für mehrere Fahrzeuge. Auch ist da eine Assoziation statt einer Aggregation angebracht -> Bindung ist nicht sooo stark
* Buchung - Fahrzeug: Multiplizität: 1 - 1 + Assoziation
* Buchung - Kunde: Multiplizität 1 -1 + Assoziation
* Firma - Kunde: Aggregation -> "verwaltet" bindet doch stärker

* Methoden fehlen (einige sind grün im Text (2), mache eher umschrieben (2))

* nicht im Text beschrieben (also nicht gefordert), wäre aber möglich: Kategorien an die Station aggregieren

[HansOne]

Danke für die Antwort!

Ich habe natürlich versucht deine Ratschläge so gut ich kann zu berücksichtigen.
Es haben sich jedoch neue Fragen ergeben:

- woran erkenne ich wann es sich um welche Art von Assoziation handelt?
  Habe in diesem Zusammenhang auch gelesen, dass man lieber eine Komposition und
  Assoziationen verwenden soll statt einer Aggregation!?

- wie macht man Assoziationen, Kompositionen, Aggregationen im Java-code dann
  sichtbar? :nudelholz:

- bei den Methoden war ich mir nicht sicher welche und wie formulieren...
  das sind meine Vermutungen:
[INDENT]+ regKunde() (registrierung Kunde bei der Firma)
+ ausleihen()
+ zurueckgeben() (beide bei Fahrzeug)

weiter komme ich hier leider nicht :huh:
[/INDENT]Ich hoffe ihr könnt mir weiterhelfen.

[tiefenbass]

- wie macht man Assoziationen, Kompositionen, Aggregationen im Java-code dann
  sichtbar? :nudelholz:

Zunächst sollte man sich zwei Fakten bewusst machen:
[LIST=1]

• Agreggationen und Kompositionen lassen sich immer auf äquivalente Assoziationen umformen
• in Java sind Kompositionen nicht realisierbar (nach aussage von Herrn Kumichel selbst nicht mit inneren Klassen)

im Grunde genommen kann man es aufs Wesentliche herunterbrechen:
Wenn du weißt, dass das UML-Diagramm in einer vorgegebenen Programmiersprache umgesetzt werden soll, dann solltest du spätestens in der Entwurfsphase deren Eigenheiten mit beachten (z.b. Beachtung von entsprechenden Codestyle wie Groß-/Kleinschreibung, bei JAVA Aggregationen statt Kompositionen im Entwurfsdiagramm verwenden)

Stark vereinfacht gesagt werden Assoziationen in Klassen durch Attribute dargestellt.
ich hänge gleich noch ein Beispiel an diesen Post (muss erstmal wieder n UML-Tool rauskramen)

LG, Matthias

edit:
in der ersten PDF sieht du eine äquivalente Umschreibung von einer Aggegation zu einer Assoziation sowie die einfachste Umsetzung in JAVA-Code:
Klasse Kabine (Attribut vom Datentyp Schiff entfällt, da die Assoziation gerichtet ist):

Code: [Select]


package demo;

public class Kabine {

}
Klasse Schiff (da das Schiff eine gewisse Anzahl an Kabinen hat (also aggregiert ), muss die Klasse dementsprechend mehrere einzelne Kabinen ermöglichen):

Code: [Select]


package demo;

public class Schiff {
 
private Kabine[] kabinen;

}

in der zweiten PDF ist eine bessere Umsetzung der Aggregation von Kabine in Schiff unter Verwendung der Collection Framework. Dementsprechend sieht der Code für Schiff etwas anders aus:
Klasse Schiff:

Code: [Select]


package demo;

import java.util.List;

public class Schiff {
 
private List kabinen;

}

[essenfeger]

In der Analyse ist eine Unterscheidung von Aggregationen und Assoziationen durchaus sinnvoll. Im Entwurf ist es bei der Zielsprache Java (zumindest im erzeugten Quelltext) nicht mehr zu unterscheiden. Den oben gezeigten Vereinfachungsschritt macht der Codegenerator auch für dich, den brauchst du nicht selbst machen.

Aggregationen: dauerhafte Zugehörigkeit, starke Bindung, ... ("besteht aus", "verwaltet", ...) Bsp für starke Bindung: Die Instanz der Klasse am unteren Ende der Aggregation (im Beispiel davor die Kabine) gehört ausschließlich zu der Instanz der Klasse am oberen Ende der Aggregation. (hier Klasse und Instanz nicht verwechseln)
Folge: die Multiplizität * <>---> * sollte bei Aggreagtionen nicht vorkommen.
-> eine Kabine gehört nur zu einem Schiff, ein Schiff kann aber mehrere Kabinen haben
-> dass eine Klasse an mehrer andere Klassen aggregiert wird (Wiederverwendung einer Klasse Adresse in den Klassen Vermietungsstation und Kunde) ist eher selten
    -> auch hier gehört die Instanz nur zu einer übergeordneten Instanz -> ein Kunde hat nicht dieselbe, sondern höchstens die gleiche Adresse


Aso Methoden:
wenn die Kunden verwaltet werden, könnte man einen Kunden hinzufügen (subtil, würde sicherlich nicht gezählt)
addKunde()
weniger subtil:
registriereBuchung()
offensichtlich:
fahrzeugAusleihen()
farzeugZurueckgeben()

-> fehlen noch im UML

Aso 2tes Diagramm:
Aggregationspfeil Firma 1 <>----- * Kunde ist verkehrt herum

sonst sieht gudd aus.

[HansOne]

Vielen Dank für die hilfreichen Beiträge! Hat mir schonmal sehr geholfen.