Konzeption und modellgetriebene Entwicklung eines ...

72 KAPITEL 5. ENTWURF UND IMPLEMENTIERUNG
Abbildung 5.7: Diagramm für die Anzeige der Tabelle aller Fundorte
Zustand in andere Zustände dargestellt. Soll die Aktion einen anderen Anwendungsfall
aufrufen, führen Übergänge schließlich zu einem Endzustand
mit dem Namen des aufzurufenden Anwendungsfalls. Benötigt der nächste
Anwendungsfall Daten für die Anzeige, müssen diese als Parameter bei dem
Übergang zum Endzustand übergeben werden.
Wie oben erwähnt, sind die meisten Aktionen auf genau dieses ValueObject
der Zeile, bzw. auf dessen Entität, bezogen. Deshalb muss die Zeile einer
bestimmten Entität zugeordnet werden können. Zur Identifizierung eines
ValueObjects zu einer Zeile wird ein Wert der Spalte benötigt, welcher eindeutig
für die Entität ist, die durch das ValueObject dargestellt wird. Bei
den Fundorten ist es nicht die für den Benutzer irrelevante ID, sondern die
Fundpunktnummer, die für Fundorte ebenfalls eindeutig ist. Da die ID aber
für die Anzeige der folgenden Anwendungsfälle benötigt wird, muss sie in
den Endzuständen vorgelagerten Zuständen aus der Fundpunktnummer gewonnen
werden (siehe Abb. 5.8 zum Beispiel Zustand ”Init Fundort Id”).
Da diese Zustände zur Übersetzung der ID eigentlich die gleiche Funktion
aufrufen, könnten sie zu einem Zustand gebündelt werden. Sie führen
aber in verschiedene Endzustände, daher würde ein Zusammenlegen im Endeffekt
nicht der Übersichtlichkeit oder der Effektivität der Arbeit dienen.
So müssten Fallunterscheidungen eingeführt werden, die teilweise im Modell
und teilweise manuell implementiert werden müssten. Auf die in Abb.
5.8 dargestellte Weise ist die Entscheidung über den Verlauf komplett im
Diagramm angesiedelt. Dies hat die positive Konsequenz, dass für das Hinzufügen
ähnlicher Aktionen, die lediglich in einen anderen Anwendungsfall