Ein gutes Szenario

Inhaltsverzeichnis

Wie entwirft ein Softwarearchitekt am besten ein System? Dass es dafür kein einfaches Rezept gibt, ist der Komplexität und Heterogenität von Softwareprojekten geschuldet. Die Sache ist aber nicht hoffnungslos. Szenarien bieten für diesen Zweck ein sehr gutes Instrumentarium.

Viele Bücher über Softwarearchitekturen sagen nur die halbe Wahrheit. Suchen Sie einmal in einem Buch über Softwarearchitektur das Kapitel, das das Rezept für die konkrete Entwurfsarbeit enthält. In der Praxis sind diese Bücher zwar durchaus gute Begleiter. Eine Antwort auf die Frage, wie nun genau der Entwurf funktioniert, bleiben sie aber schuldig. Das fehlende pragmatische Vorgehen ist übrigens mit ein Punkt, warum Bücher zu Softwaremustern wegen ihres Praxisbezugs immer noch die meistverkauften Architektur-Bücher darstellen.

Wie beginnt man?

Der Softwarearchitekt soll also mit dem Entwurf beginnen und steht vor einem leeren Blatt Papier. Was nun?

Nach meiner Erfahrung in großen und mittleren Projekten ist der bislang beste Ansatz ein szenariobasiertes Vorgehen. Ein architektonischer Entwurf hat zwei wichtige Facetten, die fachliche und die technische Architektur. Für die fachliche gibt es Use Cases. Sie betrachten ein System als Black Box und definieren, welche Abläufe (= Szenarien) vorkommen. Durch ihren Systemansatz eignen sie sich hervorragend für den fachlichen Architekturentwurf.

Abgebildet sei hier nur ein einzelnes Szenario, das sogenannte Sunshine Scenario, das einen erfolgreichen Ablauf illustriert. Es geht dabei um ein Szenario in einem Onlinehop: Die Kundin möchte mit dem aktuellen Warenkorb zur Kasse gehen.

Use Case Szenario: Der Kunde geht zur Kasse.

• Vorbedingung: Einkaufskorb ist nicht leer && Kunde konnte sich erfolgreich anmelden
• Schritte:
• Kunde klickt auf "bestellen"
• Das System zeigt ihm ein Eingabeformular
• Kunde bestätigt Liefer-/Rechnungsadresse und Zahlungsmodalitäten
• System überprüft Gültigkeit der Eingaben und präsentiert Seite mit der Zusammenfassung der Bestellung
• Kunde betätigt "kaufen"
• Nachbedingung: Bestellung wurde ins Order-Management-System übermittelt

Dazu kämen in der echten Welt noch eine ganze Menge Fehlerszenarien (Rainy Day Scenarios), etwa für alle Eventualitäten und Fehlerfälle wie einen Ausfall des Bezahlungssystems.

Falls der Architekt zuvor ein Domänenmodell für seine Problemdomäne entworfen hat, kann er nun Use Cases nutzen, um das Domänenmodell um weitere funktionale Teile zu ergänzen. Ein Domänenmodell liefert die fachliche Sicht auf die Domäne. Zum einen tauchen dort typische fachliche Bausteine auf wie im Falle eines Onlineshops Einkaufswagen, Kunde, Produktkatalog, Benutzerverwaltung oder Bestellwesen. Zum anderen finden sich dort auch die Beziehungen zwischen diesen Bausteinen, etwa Vererbung (Premiumkunde als Spezialfall von Kunde) oder Interaktion (Einkaufswagen kommuniziert mit Produktkatalog). Es handelt sich also um ein Modell, das sich ohne IT-Kenntnisse verstehen lässt. Meistens wird es vom Requirements Engineer und dem Architekten zusammen mit dem Kunden entwickelt. Das Domänenmodell kann ein erster Schritt auf dem Weg zu einer DSL sein.

Use-Case-Szenarien im Domänenmodell

Der Architekt überlegt, wie sich die Use-Case-Szenarien im Domänenmodell implementieren lassen, ergänzt bei Bedarf weitere fachliche und IT-spezifische Bausteine (z.B. Factories, Iteratoren, Listen ...) und erhält eine Beschreibung über Interaktionen und Abhängigkeiten von Bausteinen sowie eine Vorstellung über die benötigten Baustein-Schnittstellen.

Für die technische Architektur lassen sich idealerweise Qualitätsattributszenarien (Quality Attribute Scenarios) nutzen. Dabei werden nichtfunktionale Eigenschaften ebenfalls durch Szenarien beschrieben. Bei Qualitätsattributszenarien initiiert eine Quelle (Source) einen Auslöser (Trigger), der sich auf einen Systemteil (Artifact) auswirkt. Es lässt sich zusätzlich eine Umgebungsbedingung (Environment) bestimmen, zum Beispiel der Normalbetrieb. Auf das ausgelöste Ereignis soll das System reagieren (Response) und dafür werden genaue Zielwerte festgelegt (Response Measure).

Im abgebildeten Beispiel geht es um Fehlertoleranz. Sobald der Produktkatalog eines Onlineshops ausfällt, soll ein Backup-Server dessen Funktion übernehmen. Das Ganze soll in maximal 60 Sekunden über die Bühne gehen. Im Gegensatz zu pauschalen Aussagen ("System muss schnell wieder verfügbar sein"), sind hier also präzise Zielwerte gefragt.

Priorisierung der Qualitätsattributszenarien

Qualitätsattributszenarien lassen sich priorisieren, indem man ihnen ein Tupel zuordnet. (H,H) bedeutet zum Beispiel, dass das Szenario hohe Geschäftsrelevanz hat (erstes H) und zudem komplex zu implementieren ist (zweites H). Im Zweifelsfall erhalten daher immer höherpriorisierte Szenarien den Vorzug.

Wie lässt sich aber das Ziel eines Qualitätsattributszenarien erreichen? Zu diesem Zweck eignen sich Designtaktikdiagramme, die Designtaktiken oder Patterns zur Umsetzung der entsprechenden Qualitätsattribute enthalten.

Für unser Beispiel gibt es folgendes Designtaktikdiagramm (nur partiell abgebildet und daher unvollständig).

Um die Anforderung zu erfüllen, muss das System schnell bemerken, sobald der Produktkatalog ausfällt. Aus dem Diagramm könnten wir die Taktik Ping/Echo wählen. Das System sendet regelmäßig Pings an den Produktkatalog, der seinerseits mit Echo antwortet. Bleibt das Echo zu lange aus – hier müsste man natürlich definieren, was "lange" bedeutet –, nimmt das System den Ausfall des entsprechenden Servers an. Wie soll das System aber auf den Ausfall reagieren? Dafür gibt es gemäß Designtaktik "Active Redundancy" einen Server im Hot-Standby-Modus, der zeitnah die Rolle des bisherigen Produktkatalog-Servers übernehmen kann.

Die architektonische Lösung könnte daher wie folgt aussehen:

Nebenbei bemerkt, hat das Adressieren nichtfunktionaler Eigenschaften sowohl Auswirkungen auf die Softwarearchitektur (z.B. Erweiterung des Produktkatalogs um ein Ping/Echo-Protokoll) als auch auf die IT-Infrastruktur (z.B. Cluster, Router, Firewalls).

Es ginge noch mehr

Natürlich ist dieses Beispiel stark vereinfacht. Für ein vollständiges Beispiel wären viele Seiten an Beschreibung notwendig. Ich habe mich auf die statische Sicht konzentriert, die dynamische Sicht nur stiefmütterlich behandelt. Ebenso bin ich weder auf technische Randbedingungen (Beispiel: bevorzugtes Nutzen von Linux und Open-Source-Produkten) noch auf nichtfachliche Randbedingungen (Beispiel: Zeit- und Budgetbeschränkungen) eingegangen. Nicht zu vergessen die Querschnittbelange wie ein Logging/Tracing-Konzept oder die Fehlerbehandlung im System. Das ist aber der Kürze eines Blog-Artikels geschuldet. Allerdings würde man bei Hinzunahme dieser Details sowieso den sprichwörtlichen Wald vor lauter Bäumen nicht mehr sehen.

Das Prinzip sollte dennoch klar geworden sein. ()