Robustheitsanalyse

Die Robustheitsanalyse ist ein Verfahren in der Softwaretechnik, mit dem man Anwendungsfälle auf verschiedene Aspekte untersuchen kann. Dabei wird der vorhandene Text des Anwendungsfalls analysiert und in seine Bestandteile zerlegt. Als Ergebnis der Analyse wird ein Robustheitsdiagramm erstellt, welches im Grunde einem vereinfachten Kollaborationsdiagramm entspricht.
Durch die Anwendung der Analyse wird in erster Linie ein Sanity Check des Anwendungsfalls durchgeführt. Es wird geprüft, ob der Text in sich schlüssig ist oder irrationale Abläufe möglich sind. Dabei können auch weitere Objekte im Domänenmodell gefunden werden, die vorher nicht im Fokus waren. Ebenfalls hilft die Robustheitsanalyse, fehlende Alternativrouten im Text des Anwendungsfalls aufzudecken, zum Beispiel wenn ein Vorgang fehlschlägt.

Die Robustheitsanalyse schließt d​ie Lücke zwischen d​er reinen Analyse (Anwendungsfall – Was s​oll geschehen?) u​nd dem Design (Sequenzdiagramm – Wie s​oll es geschehen?). Durch konsequente Analyse a​ller Anwendungsfälle w​ird aus d​em ursprünglichen Domänenmodell e​in Klassenmodell. Aus e​inem Klassenmodell wiederum k​ann mit geeigneten Werkzeugen d​er Rumpfcode d​er Anwendung automatisch generiert werden.

Bestandteile

Die Robustheitsdiagramme bestehen a​us drei unterschiedlichen Objekten u​nd dem Akteur. Die Objekte werden m​it einer einfachen Linie verbunden. Zwischen d​en Objekten k​ann allerdings a​uch eine Aggregation vorliegen, w​enn zum Beispiel d​as Boundary-Objekt „Ok-Schaltfläche“ Teil d​es Boundary-Objektes „Homepage“ ist.

Boundary-Objekt
  • Bilden die Schnittstelle zwischen Akteur und dem System
  • Repräsentieren meistens Schaltflächen, Eingabefelder, aber auch ganze Dialoge oder Menüs
  • Sollten leicht Anwendungsfall-Texten entnommen werden können
  • Sind Substantive im Text des Anwendungsfalls

Entity-Objekt
  • Repräsentieren Objekte aus dem Domänenmodell
  • Oft entsprechen sie Datenbanktabellen
  • Die Information die von dem Objekt gehalten wird, überlebt den Anwendungsfall
  • Sind Substantive im Text des Anwendungsfalls

Control-Objekt
  • Werden als Steuerungsobjekte zwischen Boundary und Entity verwendet und auch Controller genannt
  • Sind als Verben im Text des Anwendungsfalls zu finden
  • Oft werden Controller erst als Platzhalter benutzt, die später durch Methoden von Boundary / Entity-Objekten ersetzt werden

Akteur
  • Der Akteur interagiert mit dem System
  • In der Regel stellt der Akteur einen späteren Endanwender dar
  • Boundary
  • Entity
  • Controller
  • Akteur

Regeln

Es g​ibt vier grundlegende Regeln, d​ie man b​ei Erstellung d​er Diagramme beachten muss:

  1. Akteure können nur mit Boundary-Objekten kommunizieren
  2. Boundary-Objekte können nur mit Akteuren und Controllern kommunizieren
  3. Entity-Objekte können nur mit Controllern kommunizieren
  4. Control-Objekte können mit Boundary, Entity und anderen Controllern kommunizieren, jedoch nicht mit Akteuren

Richtlinien

Im Allgemeinen sollte man die Analyse und den Modellierungsgrad nicht übertreiben. Es soll eher als integrierter Schritt nach dem Erstellen der Anwendungsfälle verstanden werden, anstatt einer eigenständigen und unabhängigen Analyse. In einem Artikel des "software development magazine" haben Kendall Scott und Doug Rosenberg die häufigsten / typischen Fehler analysiert und Vorgehensweisen beschrieben wie diese zu umgehen sind. Hier die wichtigsten als allgemeine Richtlinien, zum Erstellen von Robustheitsdiagrammen, formuliert:

  • Man sollte das statische Domänenmodell nach den Erkenntnissen der Robustheitsanalyse aktualisieren (neu gefundene Objekte eintragen)
  • Es sollte ein visueller Abgleich zwischen der Beschreibung der Anwendungsfälle und dem Robustheitsdiagramm stattfinden (Lesen des Textes der Anwendungsfälle und gleichzeitiges Nachvollziehen im Diagramm)
  • Man sollte nicht zu viele Controller Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller "Sanity Check" für die Anwendungsfälle sein.
  • Alternative Wege aus dem Anwendungsfall (z. B. im Fehlerfall) sollten ebenfalls dargestellt werden

Beispiel
Beispieldiagramm

Hier ein Beispiel Anwendungsfall in verkürzter Form:
Name des Anwendungsfalls: Anmeldung
Beschreibung: Nutzer meldet sich an Mitgliederseite an
Beteiligte Akteure: Mitglied, Webserver, Nutzerdatenbank
Ablaufschritte (normaler Ablauf):

  • Der Benutzer gibt Nutzernamen und Kennwort auf der Anmeldeseite ein und betätigt die Schaltfläche "Ok".
  • Das System vergleicht die eingegebenen Daten mit denen in der Benutzerdatenbank und liefert die Mitgliederseite.


Beim Abgleich zwischen Text und Diagramm sollten parallel der Text gelesen und die Aktionen im Diagramm verfolgt werden. An dieser Stelle wird auch sichtbar, dass man keine Alternative für den Fall modelliert hat, dass die Daten des Benutzers nicht korrekt eingegeben wurden.

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. The authors of the article are listed here. Additional terms may apply for the media files, click on images to show image meta data.