Fachkonzeptmodelle

Die Fachkonzeptschicht stellt – wie bereits erklärt – diejenige Architektur-Schicht in einer Drei-Schichten-Architektur dar, die die fachliche Anwendung und die Zugriffe auf die Datenhaltungsschicht modelliert. Das fertige OOA-Modell bildet die erste Version der Fachkonzeptschicht und ist für die spätere Funktionstüchtigkeit der Software von großer Bedeutung.

1 Modellierung der funktionalen Anforderungsbeschreibung

Die verbal formulierten Anforderungen an das neue Softwaresystem sollten nun allgemein verständlich und daher in symbolischer Form fixiert werden. Die Fixierung erfolgt im Rahmen eines sog. Use-Case-Diagramms (ucd). Es soll festgelegt werden, was mit der fertigen Software erfolgen soll:

Versuchen Sie, bevor Sie weiterlesen, nun, in Anlehnung an die Symbolik des ucd, für unsere Schuldatenbank ein Use Case Diagramm zu erstellen.

Wenn wir uns nun die einzelnen Aufgaben und Anforderungen an die Schuldatenbank betrachten, so bestehen diese aus einer Vielfalt an Anwendungsfällen – sog. Use Cases. Aus dieser Tatsache ergibt es sich, dass der/die Akteur(e) auf die Schuldatenbank in verschiedenster Weise Einfluss nehmen.

Für den späteren Erfolg der Planung ausschlaggebend ist es, bei der Erstellung des UCDs nicht den Überblick zu verlieren. In diesem Zusammenhang ist es von entscheidender Bedeutung, dass das Diagramm auf einem hohen Abstraktionsgrad erstellt wird, wobei man sich nicht in später noch genauer zu betrachtenden Details verlieren sollte.

Um nun solch ein komplexes Gefüge grafisch darzustellen, könnten wir uns in MS Word oder einem anderen Textverarbeitungsprogramm die Symbole zurechtlegen, um sie dann entsprechend einzufügen. Einen einfacheren Weg bieten hier spezielle Programme, mit deren Hilfe sich diese grafische Darstellung relativ einfach generieren lässt.

1.1 Akteur

Die Rolle des Akteurs ist, mit dem System zu interagieren, indem er Abläufe anstößt. Er steht immer außerhalb des Systems und interagiert mit diesem. Hierbei ist festzuhalten, dass der Akteur eine natürliche Person sein kann, aber auch ein anderes System, welches im zu erstellenden System eine Aktion auslöst. Die Darstellungsform ist die eines Strichmännchens. Die Rolle wird mit einem möglichst markanten Begriff unter das Symbol geschrieben. Die Verbindung, welche die Kommunikation zwischen dem Akteur und einem Use Case des Systems symbolisiert, wird mit einer Linie – der Assoziation – dargestellt.

1.2 Use Case

Den Anwendungsfall, welcher durch den Akteur ausgelöst wird, stellt man durch eine Ellipse dar. Hierbei kann ein Use Case für eine Menge von Aktionen stehen: der Use Case „Datei speichern“ beinhaltet z.B. mehrere Aktionen, wie das Auswählen des Zielverzeichnisses, das Auswählen eines Dateinamens und ggf. auch das Melden eines Fehlers, wenn das Speichermedium keinen Speicherplatz mehr bietet.

Zum Schuljahresbeginn sollen die Klassen für das neue Schuljahr eingeteilt werden. Diese Aufgabe wird von einem Mitarbeiter in der Schulverwaltung mit Hilfe der Software erledigt. Hieraus ergibt sich folgendes einfaches UCD:

Einfaches UCD „Schuldatenbank“

Als weiteres Beispiel für ein UCD soll die Software für einen Versandhandel dienen:

Einfaches UCD „Versand“

Nachdem der Mitarbeiter der Schulverwaltung nicht alle Aufgaben wahrnehmen kann, die mit der Pflege der Schuldatenbank zusammenhängen, muss dies eine andere Person – die Sekretärin – übernehmen. Sie ist z.B. für die Erfassung der einzelnen Schüler zuständig. Unser UCD wird dadurch um einen weiteren Akteur und um einen Use Case erweitert:

UCD „Schuldatenbank“ mit zwei Akteuren

Erweitern wir die Software des Schreibwarenversandhandels um den Akteur der Hilfskraft, welche die Aufgabe der Artikelerfassung hat.

UCD „Versand“ mit zwei Akteuren

1.3 Include Beziehung

Gehen wir davon aus, dass die Bildung einer Schulklasse das Auffinden der Schüler voraussetzt, welche der Klasse zugeteilt werden sollen, so ergibt sich folgendes Bild:

UCD „Schuldatenbank“ mit include-Beziehung

Der Pfeil der Beziehung zwischen den beiden Use Cases geht von demjenigen Use Case aus, welcher den anderen voraussetzt. Der Use Case „Klassen einteilen“ beinhaltet den Use Case „Schüler finden“, setzt diesen zwingend voraus. Beide werden daher mit einer sog. include-Beziehung verbunden.

Erweitern wir das UCD Schreibwarenartikelversandhandel analog um den zweiten Use Case und verbinden Sie die beiden Use Cases mit der include-Beziehung.

UCD „Versand“ mit include-Beziehung

1.4 Extend Beziehung

Bei der Klassenbildung müssen wir davon ausgehen, dass noch nicht alle Schüler in der Datenbank erfasst sind, wenn die Klasseneinteilung erfolgen soll. So melden sich z.B. einige Schüler erst verspätet endgültig an. Auch für diesen Fall muss die Software die entsprechende funktionale Möglichkeit bieten:

UCD „Schuldatenbank“ mit extend-Beziehung

Befinden sich zwei Use Cases in einer Beziehung, die es erlaubt, dass der eine Use Case um den Ablauf des anderen erweitert werden kann, jedoch nicht muss, so symbolisiert man das durch einen sog. Extension Point, welcher mit der optionalen Erweiterung durch eine extend-Beziehung verbunden wird. „Schüler finden“ setzt „Schüler erfassen“ nicht zwingend voraus, jedoch ist die Möglichkeit, wie bereits erläutert, sinnvoll.

Erweitern wir die Software für den Schreibwarenversandhandel um die Möglichkeit, fehlende Artikel durch den Kundensachbearbeiter vom Hersteller bestellen zu können.

UCD „Versand“ mit extend-Beziehung