HILFE! UML-Moddelierung. Ich check es nit!

[skleineboes]

Hallo alle zusammen.
Leider raffe ich diese ganze Moddelierungsgeschichte noch nicht so wirklich, da mir einfach das Hintergrundwissen fehlt.
Konkret geht es um eine Aufgabe wo Tankstellen Bestellungen für Kraftstoff aufgeben können.
Am Ende eines Tages sollen automatisch Lieferpläne ermittelt werden. Dabei soll zunächst jeweils das Bestelldatum aus den Bestellungen ausgelesen werden (Bestimmung wer am längsten wartet). Anschließend wird eine Router berechnet und gedruckt. Offene Bestellungen sollen zu erledigten Bestellungen werden.
Das war die Kurzbeschreibung mit den mir wichtigen Inhalten.
Ich habe einmal versucht diesen Sachverhalt zu moddelieren und bin mir ZIEMLICH sicer dass das so gar nicht das ware ist. Daher meine Frage. Was muss ich ändern um den Sachverhalt vernüftig darzustellen?
Die Grafik gibt es hier zur Einsicht.
Vorab vielen Dank für eure Hilfe!

 

[merxleben]

Hallo,

soweit ich mir das angeschaut habe, sieht das erstmal nicht so schlecht aus. Aber trotzdem ein paar kleine HInweise. Der Name LieferplanErmitteln ist kein guter Klassenname. Ich hatte irgendwo mal gelesen, dass Klassennamen nur Gegenstände (im weitesten Sinne) bezeichnen sollten. Richtiger wäre, so denke ich jedenfalls, wenn du diese Klasse einfach Lieferplan nennen würdest und ihr eine Methode #routeberechnen verpasst.

Außerdem würde ich dir vielleicht noch die Verwendung von Use Cases nahelegen, weil man so auch relativ schnell einen Überblick über das zu modellierende System bekommen kann. Das betrifft speziell die benötigten Methoden der einzelnen Objekte/Klassen.

Nochmal eine Detailfrage, hängt die Route vom Bestelldatum oder von den Tankstellen ab. Oder anders gefragt, wie wird die berechnete Route beschrieben. Ich glaube, dass es sinnvoller ist, die Route anhand der Bestellung zu berechnen, aber in Form der Tankstellen zu beschreiben.

Um dich zu berühigen, ich kann mir nicht vorstellen, dass ein erster Modellentwurf schon perfekt sein kann. Das ganze ist immer ein iterativer Prozess.

Martin

 

[skleineboes]

Hi!
Vielen Dank für deine Antwort!
Wie meinst du das mit den UseCAses? Sollte ich den Sinn der Klassen anhand eines konreten Beispiels beschreiben?
Habe einmal versuch einen Bestellvorgang anhand eines Sequenzdiagramms zu beschreiben.
Die Klasse Lieferplan ermitteltn zunächst das Alter der Bestellungen aus den gleichnamigen Klasse. Es wird eine erste Reihenfolge erstellt, wobei ältere Bestellungen priorisiert werden. Anschließend wird anhand einer Entfernungstabelle zu den jeweiligen Tankstellen die kürzeste Route berechnet. ISt der optimale Weg berechnet, wird die ganze Geschichte zum Drucker geschickt.
Somit wird ersichtlich, dass die Route sowohl vom Bestelldatum, als auch von der Entfernungstabelle abhängt. Kann es dann jedoch sein dass ich noch ein Objekt "Entfernungstabelle" brauche.
Das ganze Problem bei der Sache ist einfach nur, dass ich bisher nur die Programmierung im kleinen kenne und mir das somit alles gar nicht konkret vorstellen kann. Wie ist das z.B. mit Bestellung? Handelt es sich zunächst um eine abstrakte Klasse, welche erst bei offeneBestellungen wirklich umgesetzt wird? Wie kann eine offeneBestellung zu erledigteBestellung werden?
Wie darf ich bitte folgende Frage verstehen:
"Ich glaube, dass es sinnvoller ist, die Route anhand der Bestellung zu berechnen, aber in Form der Tankstellen zu beschreiben. "
Habe nicht so ganz verstanden wir du das meinst. Ich soll das ERgebnis nun quasi unter Tankstelle abspeichern?
Grüße!

 

[merxleben]

Hallo,

schön, wenn ich dir ein wenig helfen konnte. Mit Use Cases sind ganz allgemein Anwendungsszenarien gemeint.

Wie darf ich bitte folgende Frage verstehen:
"Ich glaube, dass es sinnvoller ist, die Route anhand der Bestellung zu berechnen, aber in Form der Tankstellen zu beschreiben. "

Damit meine ich, dass die Methode zur Berechnung der Route die Bestellungen als Parameter benutzt, du aber zur internen Darstellung der Route die Tankstellen benutzt. Sprich anstelle der Assoziation zwischen Route und Bestellung sollte eine Assoziation zwischen Route und Tankstelle bestehen. Um die Abhängigkeit der Route von den Bestellungen dazustellen hast du das Mittel der Dependency.

Man könnte das ganze auch ein wenig anders aufdröseln, indem man eine Klasse Routenplaner entwickelt. Dieser Routenplaner würde sozusagen als Factory fungieren und anhand von Bestellungen Routenobjekte erzeugen. Das hat zwei Vorteile, der erste ist, dass die Route selber eigentlich nicht wirklich wissen muß wie sie berechnet wurde. Zweitens hättest du die Möglichkeit die Entfernungstabelle im Routenplaner zu kapseln und außerdem kannst du so unterschiedlichste Planungsmethoden implementieren und austauschen. Die Route selber sollte nur aus Routenpunkten (Tankstellen bestehen).

Vielleicht kannst du damit etwas anfangen.

Martin

 

[Tobias]

Handelt es sich zunächst um eine abstrakte Klasse, welche erst bei offeneBestellungen wirklich umgesetzt wird? Wie kann eine offeneBestellung zu erledigteBestellung werden?

Google mal zu State-Pattern.

mpG
Tobias