Bevor das Programmieren der Software beginnt, sollten einige Schritte durchlaufen werden, in der die zukünftige Software als Konzept beziehungsweise als Modell geplant und entworfen wird. Der erste Schritt lautet Objektorientierte Analyse und hat als Ergebnis ein Anwendungsfallmodell, eine Beschreibung der sonstigen Anforderungen und einen Testplan für Systemtests. Da der Großteil in UML (Unified Modelling Language) einer für diesen Zweck entwickelten Modellierungssprache entwickelt wurde, zeigen wir euch in diesem Artikel die gängigsten Varianten.

Schritt 1 – Auftraggeber

Der Auftraggeber der Software hat für die Software einige Wünsche und Anforderungen, die nicht immer richtig verstanden werden. In Gesprächen mit Systemanalytikern werden die Anforderungen und Wünsche ermittelt, analysiert und in ein konsistentes, vollständiges, eindeutiges und realisierbares Modell gebracht. Das Pflichtenheft, welches hierbei entsteht ist durchaus relevant, soll aber nicht blind erfüllt werden. Es soll ein nützliches System gebaut werden, welches der Kunde gut benutzen kann. Daher ist dieser Teil der Systemanalyse besonders schwer, da sich Prioritäten und Anforderungen des Auftraggebers oft verändern und wiedersprechen.

Schritt 2 – Anforderungen

Es gibt 2 Arten von Anforderungen. Die funktionalen Anforderungen und die nicht-funktionalen Anforderungen.
Die funktionalen Anforderungen, die 90 % aller Anforderungen an das zu erstellende System geben, beschreibt alle nach außen sichtbare Systemverhalten fest. Diese Anforderungen werden auch Anwendungsfälle (Use-Case) genannt. Ein Anwendungsfall ist ein typischer Einsatz des Systems. Alle Anwendungsfälle zeigen das System in seiner gesamten Funktionalität. Die Beschreibung der funktionalen Anforderungen erfolgt in UML.
Nicht-Funktionale Anforderungen werden schriftlich erfasst. Sie legen Rahmenbedingungen der Software fest. Beispiele für nicht-funktionale Anforderungen sind die Festlegung auf Oberflächenstandards, Performance, Ausfallsicherheit und welche Plattformen unterstützt werden sollen.

Schritt 3 – Anwendungsfallmodell

In unserem Anwendungsfallmodell wollen wir Elemente aus der echten Welt in abstrakte Modellelemente überführen. In der objektorientierten Analyse gibt es dafür Anwendungsfalldiagramme, die Anwendungsfälle und Akteure beschreiben. Oft werden diese Modelle dem Arbeitgeber als Prototyp vorgestellt um Missverständnisse zu vermeiden. Die Elemente eines Anwendungsfallmodells sind Akteur, Anwendungsfall und Interaktionsbeziehungen.
Ein Akteur arbeitet direkt mit der zu erstellenden Software zusammen. Dabei kann er als Nutzer direkt Informationen in das System eingeben oder passiv Informationen empfangen. Aus der Definition geht hervor, dass ein Akteur nicht nur ein Mensch sein kann, sondern auch eine andere Software sein kann. Ein ist daher etwas abstraktes außerhalb des Systems. In dem Anwendungsfallmodell wird er entweder als Strichmensch oder Stereotype <<actor>> dargestellt:

In einem Verwaltungssystem wären die typischen Akteure ein Sekretariat, Administratoren, ein Verteiler an die, die Verwaltet werden, Nutzergruppen usw.
Am besten werden Akteure über bisherige Rollen aus der Realität und Fragen über Nutzer des Systems gefunden. Beispiele für solche Fragen sind:

  • Wer benutzt das System?
  • Was macht ein Anwender in meinem System?
  • Was für Aufgaben hat ein Anwender in dem System?
  • Was könnte auf den Anwender zukommen?
  • Wie lauten die Schnittstellen zu anderen Systemen?
  • Wer wartet mein System?
  • Welche Akteure werden für folgende Anwendungsfälle benötigt?

Aber was ist ein Anwendungsfall? Ein Anwendungsfall oder Use Case beschreibt mehrere zusammenhängende Aufgaben, die ein Akteur ausgeführt werden. Diese Durchführung führt zu einer Veränderung um ein gewisses Ziel zu erreichen. Daher sollten sie aussagekräftig mit einem Nomen und Verb beschrieben werden. Jeder Anwendungsfall wird von einem Akteur gestartet und endet bei einem Akteur. Dabei wird ausschließlich das äußere Verhalten zwischen dem Akteur und dem System beschrieben. Ein gesamtes System hat circa 10 bis 100 Anwendungsfälle. Die 4 entscheidenderen Merkmale eines Anwendungsfall sind:

  1. Ein Akteur kann an mehreren Anwendungsfällen beteiligt sein
  2. Mehrere Akteure können von einem Anwendungsfall betroffen sein.
  3. Interaktionsbeziehungen geben an, wer wen anstößt
  4. Externe Abläufe werden nicht modelliert.

Die 4 Punkte beschreiben ganz gut Anwendungsfälle und Interaktionsbeziehungen. Im UML Diagramm sehen sie folgendermaßen aus:

Welche Anwendungsfälle modelliert werden findet man am Besten durch Diskussionen mit Anwendern und Fachliteratur heraus. Aber auch Fragen können weiterhelfen:

  • Welche Funktionen gibt es bereits?
  • Was braucht das neue System?
  • Wie wird das System gewartet?
  • Wann ist das System vollständig?
  • Wie werden Dinge in dem System erzeugt, gespeichert, aufgerufen, verändert und gelöscht?
  • Hat jeder Akteur einen Anwendungsfall?
  • Wie wird auf äußere Ereignisse reagiert?
  • Informiert das System den Benutzer über innere Ereignisse?

Bei einigen Anwendungsfällen wird es passieren, dass es verschiedene Ausgänge möglich sind. Das führt zu einem Szenario. Ein Szenario beschreibt eine mögliche Variante eines Anwendungsfalls. Dabei wird zwischen primären (normale, häufige Abläufe) und sekundären (Fehlerfälle) Szenarios unterschieden. Alle Szenarios (ca. 5 bis 15) zusammen ergeben dann den Anwendungsfall. Die Anwendungsfälle werden in der OOA noch textuell beschrieben. Später bei dem objektorientierten Entwurf gibt es ein Interaktionsdiagramm. In der textuellen Beschreibung sollte der Name des Anwendungsfalls, eine Kurzbeschreibung, die Voraussetzungen, die beteiligten Akteure und der Ablauf beschrieben werden.

Fortgeschrittene Konzepte

Auch wenn die folgenden Punkte dazu verleiten das Problem aus der Entwicklersicht zu beschreiben, muss immer die Anwendersicht verwendet werden. Die Anwendungsfallmodelle können mit Benutzt-Beziehungen, Erweiterungsbeziehungen und Generalisierungen verfeinert werden. Das sollte aber mit Vorsicht eingesetzt werden, da die Modelle dadurch schwerer zu verstehen sind und wir die Modelle eigentlich für den Anwender machen.
Die Benutzt Beziehung macht es möglich gemeinsame Funktionalität mehrerer Anwendungsfälle, durch einen eigene Anwendungsfall beschrieben werden. Dadurch werden unnötige Dopplungen eingespart. Häufige Fälle werden das An- und Abmelden in dem System sein. Die Interaktionslinie wird dann gestrichelt gezeichnet und mit dem Stereotyp << include >> markiert. Wichtig ist es dabei auf die Pfeilrichtung zu achten!

Falls wir Sonderfälle haben – zum Beispiel verschiedene Finanzierungsarten wie Direktkauf und Leasing – können diese einem Normalfall erweitern. Dafür wird der Stereotyp << extend >> verwendet. Der Normalfall muss dann über das Schlüsselwort „Extension Point“ erweitert werden und einem Wort welches den Teil, um den erweitert wird beschreibt. Folgendes Beispiel verdeutlicht:

Die Generalisierung fasst ähnliche Funktionalitäten (anmelden mit Passwort und anmelden mit Fingerabdruck) oder Akteureigenschaften (Privatkunde, Geschäftskunde) zusammen. Das Untergeordnete Element zeigt auf das übergeordnete Element und erhält dadurch all seine Eigenschaften.