Robustheitsdiagramm

Die Robustheitsanalyse ist ein Verfahren in der Softwaretechnik, mit dem man Use Cases auf verschiedene Aspekte untersuchen kann. Dabei wird der vorhandene Use Case Text 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 Use Cases 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 Use Case Text aufzudecken, zum Beispiel wenn ein Vorgang fehlschlägt.

Die Robustheitsanalyse schließt die Lücke zwischen der reinen Analyse (Use Case – Was soll geschehen?) und dem Design (Sequenzdiagramm – Wie soll es geschehen?). Durch konsequente Analyse aller Use Cases wird aus dem ursprünglichen Domänenmodell ein Klassenmodell. Aus einem Klassenmodell wiederum kann von geeigneten Tools der Rumpfcode der Anwendung automatisch generiert werden.

Bestandteile

Die Robustheitsdiagramme bestehen aus 3 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 Button“ Teil des Boundary Objektes „Homepage“ ist.

Boundary object

• Bilden die Schnittstelle zwischen Akteur und dem System
• Repräsentieren meistens Buttons, Eingabefelder, aber auch ganze Dialoge oder Menüs
• Sollten leicht Use Case Texten entnommen werden können
• Sind Substantive im Use Case Text

Entity object

• Repräsentieren Objekte aus dem Domänenmodell
• Oft entsprechen sie Datenbankeinträgen
• Die Information die von dem Objekt gehalten wird, überlebt den Use Case
• Sind Substantive im Use Case Text

Control object

• Werden als Steuerungsobjekte zwischen Boundary und Entity verwendet und auch Controller genannt
• Sind als Verben im Use Case Text 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 den 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 Use Cases 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 Use Case Text und dem Robustheitsdiagramm stattfinden (Lesen des Use Case Textes und gleichzeitige Nachvollziehung im Diagramm)
• Man sollte nicht zu viele Controller Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller "Sanity Check" für die Use Cases sein.
• Alternative Wege aus dem Use Case (z.B. im Fehlerfall) sollten ebenfalls dargestellt werden

Beispiel

Beispieldiagramm

Hier ein Beispiel Use Case in verkürzter Form:
Use Case Name: Anmeldung
Beschreibung: Nutzer meldet sich an Mitgliederseite an
Beteiligte Akteure: Mitglied, Webserver, Nutzerdatenbank
Ablaufschritte (normal flow):

• Der Benutzer gibt seine User ID und Passwort auf der Anmeldeseite ein und betätigt den OK Button.
• Das System vergleicht die eingegebenen Daten mit denen in der Benutzerdatenbank und liefert die Mitgliederseite.

Der Abgleich zwischen Text und Diagramm sollte parallel ablaufen. Den Text lesen und die Aktionen im Diagramm verfolgen. An dieser Stelle wird auch sichtbar, dass man keine Alternative modelliert hat, falls die Daten des Benutzers nicht korrekt eingegeben wurden.

Quellen / WebLinks

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