Use-Cases

[banshee]

Hallo,

nur eine kleine Frage dazu: Ich sehe es doch richtig, dass es bei Use-Cases nur auf die Interaktion zwischen Nutzer und System ankommt?!

D.h. selbst wenn ich z.B. das System einer Bowlingbahn sehr ausführlich mit Punktestand, Frames, Würfen, Spielern, Wurfsensoren, Mechanik für die Pins und Monitoren für Animationen modelliere, dann belaufen sich trotzdem noch alle Use-Cases auf die Eingabe von Spielernamen und einen Ballwurf? Ich sehe jedenfalls keine weitere Möglichkeit, wie jemand anders auf das System einwirken könnte...

 

[SlaterB]

kann ich so in etwa bestätigen,
als ich im Studium Use-Cases machen sollte waren die auch eher sehr kurz

Bibliotheksverwaltung:
- Mann geht in die Bibliotek
- Mann gibt Buch ab
fertig

 

[banshee]

Okay, vielleicht noch eine designtechnische Frage dazu. Angenommen ich habe eine schöne Hierarchie so in der Form:

Wurf <- Frame <- Punktekarte <- Spieler <- Spiel -> Bahn -> Monitor

...und möchte auf dem Monitor Animationen nach Würfen und die Punktestände anzeigen, wie mache ich das dann genau? Ich habe da eben das Problem, dass man am besten aus einem Wurf-Objekt eine Animation erstellt (weil man da erst weiß, welche Pins gefallen sind) und die dann irgendwie zum Monitor muss. Ich sehe da derzeit nur 3 sehr unschöne Lösungen.

1) Eine statische Klasse Monitor, die aber schon hinfällig wird, wenn man mehrere Monitore pro Bahn hat.
2) Eine endlose Kette von Referenzen, wobei jede Unterklasse eine Referenz auf ihre Oberklasse speichert
3) Einen eventbasierten Ansatz, wobei ich das nicht weiß, wie man das in einem Klassendiagramm zeichnet bzw. ob es nicht einfacher geht.

evtl. 4) Designänderung

 

[SlaterB]

hängt allles von der Steuerung ab, wer wofür zuständig ist,
ich kann mir eine Controller-Klasse vorstellen mit Code wie

Wurf w = WurfGenerenator.getRandomWurf(); // jaja, deutsch/ englisch
spieler.notiereWurf(w)
monitor.show(w);

wenn Controller Referenzen auf Spieler + Monitor hat,

dass man irgendwann einmal

spiel.getSpieler();
+
spiel.getBahn().getMonitor();

aufrufen muss, ist ja nicht ganz tragisch

 

[bygones]

warum schon vorher alles versuchen zu planen und zu verdrahten ohne dass du weisst, ob es ueberhaupt sinnvoll ist bzw kommen wird ?

sorry kann ich nicht verstehen warum man sich das antuen will - v.a. ist es schon sicher dass der urspruengliche Plan den man sich in muehsamen ueberlegen ausgedacht hat wieder umworfen wird, geandert wird etc

du hast ein wunderbares Szenario bei dem du weisst was fuer inhalte es gibt - es ist wahrlich prädestiniert fuer TestDriven...

das Design bildet sich dann heraus - auch dann wird sich zeigen wo welche Funktionalitaet wie untergebracht werden sollte - v.a. dadurch dass du zuerst die Verwender schreibst.

*schuettel* - warum noch immer alles vorher planen wollen ? treffe entscheidungen dann wenn sie anstehen (oder faehrst du auf der Autobahn auch mit 30 weil ja in der naechsten Ortschaft n 30er schild kommen koennte ?)

 

[banshee]

Erklär das den Veranstaltern meiner Software Design Vorlesung