Quality-driven Software Architecture

Aber …

Ein kleines, unbedeutendes Wort, dieses „aber“. Unser von der Vorführung begeisterter Kunde ergänzt seine Anforderungen: „Wir wollen unser Fotomanagement weltweit ausrollen und jedem Benutzer 50 Gigabyte Speicherplatz bereitstellen. Rechnen Sie mit mehreren Millionen Benutzern. Keine Sorge, die Funktionalität bleibt identisch…“ Zwei nichtfunktionale Anforderungen, Benutzerzahl und Datenvolumen, kommen also neu auf uns zu. Interessanterweise bleibt das Domänenmodell auch in unserer erweiterten Aufgabenstellung ganz simpel: Eine einzige Domänenklasse kommt dazu, nämlich der Eigentümer (Owner) des jeweiligen Bildes (Abb. 4). Genau genommen haben wir für diese neue Klasse jetzt auch ein wenig neue Funktionalität zu implementieren, nämlich diese Owner anzulegen und zu bearbeiten. Gegenüber den einfachen funktionalen Anforderungen bekommen nun selbst hartgesottene Architekten und Entwickler plötzlich Bedenken: Millionen Benutzer und Petabyte an Daten konfrontieren ein Entwicklungsteam mit völlig neuen Aufgaben:

Abb. 4: Erweitertes Domänenmodell
  • Skalierbarkeit, um das System auch bei den geplanten Benutzerzahlen noch performant und reaktiv zu halten. Hierzu gehört Clustering und Load Balancing, um kurzfristig auf Lastspitzen reagieren zu können.
  • Speicherung großer Datenmengen (neudeutsch Big Data), was mit konventionellen Datenbanken oder Dateisystemen nicht zufriedenstellend funktioniert.
  • Verteilte Datenhaltung, weil aus Performance- und Risikogründen der gesamte Datenbestand über mehrere Standorte oder Rechenzentren verteilt sein sollte.
  • Hochverfügbarkeit, weil große Zahlen internationaler Benutzer keine langen Wartungsfenster dulden.
  • Übertragungskosten, beispielsweise für die Replikation der Bilddaten.

Ein rein domänenorientiertes Vorgehen bei Entwurf und Entwicklung unseres Foto-Beispiels hätte die wesentlichen nichtfunktionalen Anforderungen (Benutzeranzahl und Datenvolumen) außer Acht gelassen. Allgemein besteht bei zu starkem Fokus auf Funktionalität und Fachdomäne das Risiko, wichtige Qualitätsmerkmale zu übersehen oder lange Zeit zu ignorieren. Falls Sie der Meinung sind, die hier genannten Qualitätsanforderungen seien ja viel zu groß, weil Sie selbst niemals Millionen von Benutzern haben werden, wählen wir eine ganz andere, neue Anforderung: Ihr Kunde möchte für einige Dutzend Mitarbeiter Bilder speichern, jeweils nur höchstens hundert. Das ergibt insgesamt ein Datenvolumen, das sich problemlos auf einer einzigen Festplatte speichern lässt, und wenige Dutzend Benutzerkennungen können wir auch ohne Probleme managen. Allerdings sollen jetzt die gespeicherten Bilder streng geheim sein – nennen wir das mal „military grade security“. Schon haben wir es wieder mit Problemen jenseits der reinen Funktionalität zu tun: Sichere Verschlüsselungsalgorithmen, sichere Übertragung der Bilder zu den Benutzern, Key-Management oder Authentifizierung der Benutzer. Auch diese Aufgaben lassen sich nur schwer in einer bereits fertigen Software nachrüsten. Kehren wir vom Beispiel zur Frage zurück, was Qualität von Software denn insgesamt bedeutet, und wie wir sie erreichen können. Dazu möchte ich zuerst den Begriff „Qualität“ von Software genauer untersuchen.

Was ist Qualität

In der Vergangenheit haben sich viele Forscher und Organisationen mit dem Begriff beschäftigt. Dabei sind diverse Definitionen und Qualitätsmodelle entstanden. Allen gemeinsam ist der Ansatz, den komplexen Begriff „Qualität“ durch schrittweise Zerlegung zu präzisieren oder zu definieren. Qualität wird dabei in mehrere einzelne (Qualitäts-)Merkmale zerlegt, die ihrerseits wiederum verfeinert werden können. Als Beispiel dient unser Foto-Management-System aus der Einleitung: Wir beschreiben jetzt die (Qualitäts-)Anforderungen in Form eines so genannten Qualitätsbaumes (Abb. 5): Die geforderte Softwarequalität wird in Untermerkmale zerlegt, die ihrerseits bei Bedarf weiter zerlegt werden. Es entsteht eine hierarchische Struktur, die spezifische Qualitätsanforderungen an ein System beschreibt.

Abb. 5: Qualitätsbaum für das Foto-Management

Der häufig verwendete Terminus „nichtfunktionale Anforderungen“ als Bezeichnung für Qualitätsmerkmale ist etwas ungenau, weil die gängigen Qualitätsmodelle „Funktionalität“ als ein Merkmal enthalten. In Abbildung 5 steht sie ebenfalls als Qualitätsanforderung vermerkt. Wie können Sie nun diese, häufig recht umfangreiche, Menge an Qualitätsanforderungen für ein System erreichen? Wir haben bereits gesehen, dass eine Konzentration auf die funktionalen oder fachlichen Merkmale, wie im Domänenentwurf vorgeschlagen, zu Problemen mit den übrigen Qualitätsmerkmalen führen kann.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.