Vorsicht vor dem Anwendungsbereichsmodell oder Der kritische Blick auf Entity Klassen in der Analyse-Phase

Die objektorientierte Analyse dient dazu, eine fachliche Lösung zu entwickeln, ohne auf technische Details (z.B. einer Plattform oder Programmiersprache einzugehen). Ein wichtiges Ergebnis dieser Phase sind u.a. die Entity Klassen und deren Modellierung in Klassendiagrammen.

Vor der objektorientierten Analyse findet eine Anforderungsanalyse statt, in deren Rahmen u.a. ein Anwendungsbereichsmodell erstellt wurde (synonym Domain Object Model, Domain Model). Dieses Anwendungsbereichsmodell ist ein einfaches Klassendiagramm. Es stellt die zentralen Konzepte des Anwendungsbereichs dar. Man kann es auch als grafische Form eines Glossars ansehen, denn schließlich finden sich dort wichtige Begriffe der Fachsprache und deren Beziehungen untereinander wieder. Merkmal dieser Diagramme ist, dass Sie während der Anforderungsanalyse wachsen und die Sachverhalte und Zusammenhänge dokumentieren, über die mit dem Kunden bzw. Endanwender in dessen Sprache gesprochen wird. Deshalb verwendet man im Anwendungsbereichsmodell nur ganz elementare Elemente aus dem UML-Sprachumfang: Klassen und Assoziationen mit Namen und ggf. Multiplizitäten (Kardinalitäten). Klasse dokumentieren zentrale Begriffe oder Konzepte aus dem Anwendungsbereich und bekommen einen Namen. Die Zusammenhänge zwischen ihnen werden durch Assoziationen ausgedrückt, die ebenfalls einen Namen bekommen. Das war’s schon. Es wird bewusst auf alle UML-Element verzichtet, die erklärungsbedürftig sind oder weiteres Hintergrundwissen aus der Modellierung erfordern. Also verzichtet man auf Aggregation, Komposition, Generalisierung/Spezialisierung (Vererbung) und auch auf Navigierbarkeit von Assoziationen (Pfeilspitzen). Attribute sollte man nur dann dokumentieren, wenn dadurch ein Konzept oder Begriff deutlicher wird. Gibt es beispielsweise ähnliche Begriffe wie Versicherter und Patient, dann kann durch Attribute ausgedrückt werden, dass bei Patienten die Blutgruppe eine Rolle spielt und beim Versicherten die Nummer seiner Versichertenkarte. Weitergehende Beschreibungen der Klassen in einer Tabelle oder einem Glossar sind natürlich zusätzlich notwendig.

anwendungsbereichsmodell

Ein Beispiel aus einer Gruppenarbeit sieht man in der Abbildung. Es stellt dar, worüber die Gruppe mit ihrem Auftraggeber gesprochen hat, der sich eine einfache Inventarverwaltung wünscht, die bei der Ausleihe von Notebooks, Mäusen, Beamern usw. helfen soll. Die Anwendung soll von Mitarbeitern in der IT-Abteilung genutzt und auch zur Verwaltung von Mitarbeitern und Artikeln genutzt werden. Das wird durch das Diagramm sofort ersichtlich. Ich würde sagen, das ist ein gutes Anwendungsbereichsmodell. (Man müsste die falsche 1:1-Multiplizität an den verwaltet-Beziehungen korrigieren und sollte auf die Navigierbarkeit von Assoziationen verzichten.)

Im Anschluss an die Anforderungsanalyse findet die objektorientierte Analyse statt. Auch hier werden wieder Klassen in Klassendiagrammen modelliert. Jetzt ist der Zweck der Klassendiagramme aber ein anderer. Es geht nun darum die fachliche Lösung zu dokumentieren. Dazu verwendet die Analyse Konzepte wie Aggregation, Komposition, Generalisierung/Spezialisierung, Multiplizitäten usw. Ziel ist es darzustellen, wie das zu entwickelnde System aus fachlicher Sicht funktionieren könnte.

Der spontane Ansatz ist häufig, dass der Inhalt des Anwendungsbereichsmodells in das Klassendiagramm der Analyse kopiert wird. Aber Vorsicht! Bleiben wir beim Beispiel oben: Ist es wirklich so, dass zu jedem IT-Mitarbeiter gespeichert werden soll, welche Mitarbeiter er verwaltet hat bzw. welche Artikel er mal im System erfasst hat? Wenn nicht, dann darf es in den Klassendiagrammen der objektorientierte Analyse diese Beziehung nicht mehr geben. Stattdessen fällt vielleicht auf, dass Mitarbeiter in einem bestimmten Zeitraum Artikel ausleihen. Dann braucht man vielleicht noch eine neue Klasse für den Zeitraum von Beginn der Ausleihe bis zu deren Ende.

oberflaechenentwurf

Beziehungen im Anwendungsbereichsmodell die „verwaltet“, „sucht“ oder „legt an“ heißen, werden wahrscheinlich nicht gebraucht. Wenn man unsicher ist, ob eine Beziehung gebraucht wird oder nicht, hilft oft schon der Blick auf die Oberflächenentwürfe im Modell der Benutzeroberfläche. Wenn es kein Fenster und keinen Dialog gibt, der den Zusammenhang anzeigt oder nutzt, der durch die Beziehung dargestellt wird, dann könnte die Beziehung entfallen. Man muss dann aber auf jeden Fall auch in den Anwendungsfallbeschreibungen nachlesen, ob dort der Zusammenhang für die Verarbeitung gebraucht wird (z.B. um etwas an der richtigen Stelle speichern zu können), ohne dass es auf der Oberfläche sichtbar werden würde. Wenn auch dort die Beziehung nicht verwendet wird, kann sie im Klassendiagramm der Analyse entfallen. 

Deshalb sieht man in dem Klassendiagramm aus der objektorientierten Analyse der Inventarverwaltung auch keine Beziehung des IT-Mitarbeiters (jetzt als Klasse „Benutzer“) zu den Mitarbeitern oder zu den Artikeln bzw. zur Ausleihe.

ooa-modell

Zusammenfassend ist wichtig, dass man das Anwendungsbereichsmodell nicht direkt in Entity Klassen der Analyse übernehmen kann. Man muss jede Klasse, jede Beziehung und jedes Attribut in der Analyse daraufhin prüfen ob und wie es Teil der späteren Lösung sein kann. Wenn es nicht gebraucht wird, fliegt es raus.

Quellenangabe: Oberflächenentwürfe und Anwendungsbereichsmodell: anonyme Autoren, Gruppenarbeit, WS16/17.

Schreibe einen Kommentar