UML @ Work - Von der Analyse zur Realisierung

5 Analyse (S. 247-248)

Mit dem im vorhergehenden Kapitel erstellten Anforderungsmodell verfügen wir über eine genaue Spezifikation der gewünschten Systemfunktionalität. Wir gehen nun davon aus, dass über das Anforderungsmodell mit dem Kunden Einvernehmen hergestellt wurde und widmen uns den ersten Realisierungsschritten auf dem Weg zur eigentlichen Systementwicklung. Das Ziel der Analysephase ist die Verteilung der Verantwortlichkeiten für die einzelnen Systemoperationen innerhalb einer robusten logischen Systemstruktur, die noch nicht von der Implementierungsumgebung beeinflusst ist. Dabei bedeutet »robust«, dass die Struktur sowohl Erweiterungen als auch Änderungen der definierten Funktionalität insofern unterstützt, als die damit verbundenen Wartungsmaßnahmen von möglichst »lokalem« Charakter sein sollen, d.h., dass sich die Änderungen und Erweiterungen auf wohlabgegrenzte Bereiche des Systems beziehen. Um eine derartige Änderungslokalität zu erreichen, folgen wir den Vorschlägen von Jacobson et al. und organisieren die geforderte Systemfunktionalität nach den Dimensionen Information, Darstellung und Verhalten ([Jaco92]).

Wir ordnen den jeweiligen Teilaspekten der Funktionalität drei Kategorien von Objekten zu, deren Wirkungsbereich sich möglichst gut, wenn auch nicht vollständig, auf jeweils eine dieser Dimensionen konzentriert: Informationsobjekte auf die Informationsdimension, Schnittstellenobjekte auf die Darstellungsdimension und Steuerungsobjekte auf die Verhaltensdimension. Wenn man nun die von Jacobson et al. vertretene Hypothese akzeptiert, dass sich die einer Applikation zugrunde liegende Objektstruktur relativ selten ändert, während Funktionalität und Schnittstellenaspekte einer schnelleren Evolution unterworfen sind, so kann man folgern, dass unter dem angestrebten Strukturkonzept

- Änderungen der Schnittstelle nur (einige wenige) Schnittstellenobjekte betreffen,

- Änderungen der Funktionalität, soweit es sich um informationsobjektinhärentes Verhalten handelt, sich eben nur auf Informationsobjekte auswirken (im CALENDARIUM etwa die Aufnahme eines bestimmten »Zeitpolsters« in die Untersuchung, ob zwei Termine miteinander kollidieren) und

- Änderungen von Verhalten, an dem mehrere Klassen von Informationsobjekten beteiligt sind, lediglich in den entsprechenden Steuerungsobjekten zu erfolgen haben.

Somit kann insgesamt erwartet werden, dass Änderungen im Allgemeinen überschaubare Auswirkungen aufweisen werden. Man beachte jedoch, dass es sich bei dieser Argumentation um ein Wahrscheinlichkeitskalkül handelt, das nicht ausschließt, dass irgendwann neue Informationsobjekte samt Benutzerschnittstellen benötigt werden, die sich in das Verhalten von etlichen Steuerungsobjekten einbringen. Dennoch nehmen wir an, dass solche Entwicklungen eher rar sein werden. Im Zuge dieser Strukturierung, die in Unterkapitel 5.1 näher erläutert wird, werden relevante Problembereichsklassen in das Strukturmodell übernommen, das den statischen Teil des Analysemodells darstellt.

Dazu kommen Schnittstellenklassen, die im Wesentlichen die im Anforderungsmodell beschriebenen Schnittstellen repräsentieren, sowie zusätzliche Klassen, die aus der vertiefenden analytischen Auseinandersetzung mit der Aufgabenstellung resultieren. Insgesamt wird sich das Strukturmodell relativ stark vom Problembereichsmodell unterscheiden. Anhänger der naiven objektorientierten Philosophie, dass sich alle Implementierungsklassen mehr oder weniger automatisch aus der Problembereichsanalyse ergeben, mag dieser Umstand betrüben, er folgt aber zwingend aus den eben beschriebenen Analyseschritten.

Um die Lesbarkeit der Darstellung zu verbessern, kann das Strukturmodell in überschaubare Unterstrukturen partitioniert werden. Diese so genannten Pakete sollten in logischer Hinsicht kohäsiv sein, d.h., dass die Elemente jedes Pakets in einem engen Zusammenhang zueinander stehen sollten. Um die Übersichtlichkeit und damit die Verständlichkeit zu erhöhen, sollte gleichzeitig danach getrachtet werden, die Kopplung, d.h. die wechselseitigen Abhängigkeiten zwischen diesen Paketen, so gering wie möglich zu halten. Nach dieser in Unterkapitel 5.2 durchgeführten Tätigkeit sind wir in der Lage, das Strukturmodell, das nun (möglichst) alle wesentlichen logischen Bausteine des zu entwickelnden Systems enthalten sollte, vollständig wiederzugeben. Man kann nun daran gehen, das für die im Anwendungsfallmodell postulierte Funktionalität notwendige Verhalten auf die einzelnen Klassen des Strukturmodells zu verteilen.