Klassendiagramm UML

[Kovanlik07]

Guten Morgen Zusammen!

Ich bin in dem Bereich Klassendiagramme noch nicht so geübt drin und würde mich freuen, wenn jemand mir hierbei weiterhelfen könnte.

Es geht um die folgende Aufgabe:

Es soll ein Fahrtenbuch in Form eines Klassendiagramms mit folgenden Funktionen realisiert werden:

1. Die LKWs sollen mit Bezeichnung, Baujahr, und Anschaffungspreis gespeichert werden.
2. Eine Verwaltung der LKW-Nutzer mit Name, Geburtsdatum und Geschlecht soll möglich sein.
3. Die LKW-Nutzer sollen ihre einzelnen Fahrten im System erfassen können.
4. Die jährliche Kilometerzahl sowohl der LKWs als auch der LKW-Nutzer soll vom System berechnet werden.
5. Das System soll eine Liste aller Einzelfahrten pro Mitarbeiter drucken.

 

[JStein52]

1. Schritt: Klassen identifizieren ! Hast du eine Idee was hier Klassen sein könnten

 

[Kovanlik07]

Klassen können folgende sein:

1. LKW
2. LKW-Nutzer

 

[JStein52]

noch mehr ?!

 

[JStein52]

Was ist z.B. mit den Fahrten ?

 

[Kovanlik07]

Ja habe gesagt, dass ich noch nicht so geübt drin bin.

Weißt du denn, wie ein Klassendiagramm dazu aussehen sollte?

 

[JStein52]

In einem Klassendiagramm malt man die einzelnen Klassen in Kästchen, mit Attributen und Methoden und den Beziheungen der Klassen untereinander per Pfeilen. Beziehungen können entweder Vererbungen sein (Klasse ist ein ....) bzw. Aggregationen (Klasse enthält ein ....) Google mal nach UML Klassendiagramm und schaue es dir noch mal an und versuche es für deine Klassen LKW, Fahrer, Fahrten umzusetzen.
Und irgendwie fehlt dir noch eine Kontrollerklasse die die Businesslogig enthält.

 

[Bitfehler]

@JStein52 :
Wäre "Klasse enthält ein ..." nicht eher ein Kompositionsmuster?
Ok, es ist ein Spezialfall der Aggregation. Aber eine Aggregation setzt nicht zwingend eine Multiplizität von eins voraus.

@TE:
Je nach Quelle werden Beziehungen auch als Assoziation bezeichnet. Nicht verwirren lassen.

 

[JStein52]

Wäre "Klasse enthält ein ..." nicht eher ein Kompositionsmuster?

Ja klar. Da hast du recht.

 

[Jardcore]

Ich würde noch eine Klasse für Geschlecht einführen... siehe Facebook, die haben 60 Geschlechter, alles andere ist ja nicht mehr Zeitgemäß (Total Recall lässt grüßen)

Klassen:
Lkw
- String bezeichnung
- String baujahr
- double anschaffungspreis

LkwNutzer (Fahrer)
- String name
- String geburtsdatum
- Geschlecht geschlecht

Fahrt
- LkwNutzer fahrer
- Lkw lkw
- double kilomenter

Zu einer Fahrt gehört genau 1 Fahrer und ein Lkw

LkwSystem
- List<Fahrt> fahrten

Das System hat eine Liste alle Fahrten (n) man kann anhand der Liste die gewünschten Operationen ausführen. Die Liste ist nicht performant. Aber wie genau die Fahrten gespeichert werden war nicht gefordert. Man sollte hier vielleicht eine bessere Lösung wählen.

Geschlecht (Enum)
- MAENNLICH
- WEIBLICH


Das Drucken der Fahrten geschieht dann indem man einfach die Liste der Fahrten durchiteriert.
Für diese Aufgabe hätte das System wahrscheinlich 3 methoden:
druckeFahrten();
getKilometerDesLkws(Lkw lkw);
getKilomenterDesFahrers(Fahrer fahrer);

Verbesserung wäre hierbei jedoch extra Listen für Fahrer und Lkw bereit zu halten.

Die Aufgabe erinnert ein wenig an Datenbankaufgaben, bei denen durch joins die gewünschten Abfragen gemacht werden können.

 

[JStein52]

Verbesserung wäre hierbei jedoch extra Listen für Fahrer und Lkw bereit zu halten.

Sind das nicht die Punkte 1.) und 2.) der Aufgabenstellung. Und wenn man keine Listen hat sondern das alles nur über die Fahrten (mit)verwaltet muss man bei Eingabe einer neuen Fahrt immer den LKW und den Fahrer mit eingeben ?! Und wenn du einen neuen LKW hast der erst mal nur rumsteht taucht der im System zunächst nicht auf.

An den TE:
Zum Klassendiagramm gehören jetzt natürlich noch die Methoden ....

 

[Jardcore]

Ja ein Lkw kann ja einfach nur rumstehen, es wird für das Unternehmen erst interessant, wenn der Lkw sich bewegt. Also wenn man new Lkw() macht und den nicht benutzt steht er quasi nur rum^^

Ich würde zu meinem Beitrag noch etwas hinzufügen, ich weiß nur nicht wie weit die Java-Kenntnisse des TE sind.
Man könnte ein Interface hinzufügen.
ZaehltKilometer
anhand des Interfaces würde die Systemklasse weniger Abfragen machen müssen.
Zusätzlich könnte man dann die schon oben erwähnte schwäche des System verbessern indem man Maps benutzt.

private Map<ZaehltKilomenter, List<Fahrt>> fahrtenDerFahrer = new HashMap<ZaehlKilomenter, List<Fahrt>>();
private Map<ZaehltKilomenter, List<Fahrt>> fahrtenDerLkws = new HashMap<ZaehlKilomenter, List<Fahrt>>();

Nur im LkwSystem gibt es mehr als nur Getter und Setter Methoden. Es kommt immer drauf an wie genau ein Professor/Lehrer/Auftraggeber die Methodendeklaration haben möchte. Einige lassen Getter und Setter auch weg.

Edit:
Das LkwSystem hätte (zumindestens in meinem Kopf) jetzt 4 public Methoden:
> addFahrt(Fahrt fahrt);
> getGefahreneKilometer(LkwNutzer nutzer);
> getGefahreneKilometer(Lkw lkw);
> druckeFahrten(LkwNutzer nutzer);

Und dann noch (wenn man Interfaces benutzt) 4 private Methoden:
> addFahrtZuDenFahrtenDesFahrers(Fahrt fahrt);
> addFahrtZuDenFahrtenDesLkws(Fahrt fahrt);
> addFahrtZurListeFahrten(Map<ZaehltKilomenter, List<Fahrt>> map, ZaehlKilomenter object, Fahrt fahrt);
> getGefahreneKilometer(List<Fahrt> fahrten);

Alle Angaben ohne Gewähr^^ Die Namen könnte man wahrscheinlich auch noch besser wählen. "ZaehltKilometer object" ist jetzt nicht so geil^^

 

[JStein52]

ich weiß nur nicht wie weit die Java-Kenntnisse des TE sind.

Nur der Vollständigkeit halber: die Klassendiagramme sind ja zunächst mal unabhängig von einer Programmiersprache, ayuch wenn wir hier im Java-Forum sind. Und im Idealfall wird der Code ja aus dem Klassendiagramm generiert.