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 die Lücke zwischen der reinen Analyse (Anwendungsfall – Was soll geschehen?) und dem Design (Sequenzdiagramm – Wie soll es geschehen?). Durch konsequente Analyse aller Anwendungsfälle wird aus dem ursprünglichen Domänenmodell ein Klassenmodell. Aus einem Klassenmodell wiederum kann mit geeigneten Werkzeugen der Rumpfcode der Anwendung automatisch generiert werden.

Bestandteile

Die Robustheitsdiagramme bestehen aus drei unterschiedlichen Objekten und dem Akteur. Die Objekte werden mit einer einfachen Linie verbunden. Zwischen den Objekten kann allerdings auch eine Aggregation vorliegen, wenn zum Beispiel das Boundary-Objekt „Ok-Schaltfläche“ Teil des 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 gibt vier grundlegende Regeln, die man bei Erstellung der 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.

Weblinks

• Agile Modeling - Robustness Diagrams
• Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML