Quality Driven Software Architecture

Dr. Gernot Starke

Tee mit Zucker?

Wie trinken Sie denn Ihren morgendlichen Tee – mit Zucker oder lieber natur? Mit einem Tropfen Milch und etwas Honig? Lieber mit Zitrone? Oder bevorzugen Sie am Ende gar Kaffee? Sie merken schon – die Anforderungen an Frühstücksgetränke, genau wie die an Software, hängen stark vom jeweiligen Betrachter ab. Wollen wir die Qualität eines Getränkes (oder allgemein eines Systems) prüfen, so müssen wir vorher die spezifischen Qualitätsanforderungen der maßgeblichen Stakeholder kennen – allgemeine Anforderungen helfen uns nur bedingt weiter.

Auftraggeber und Anwender erwarten von Software heutzutage eine Vielzahl von Qualitätsmerkmalen, von denen die „korrekte Funktion“ nur eines unter vielen ist. Im klassischen Software-Entwurf wird allerdings gerade die Funktionalität häufig ins Zentrum der Entwurfs- und Implementierungstätigkeiten gestellt – mit möglicherweise fatalen Folgen. Lassen Sie uns das anhand eines kleinen Beispiels nachvollziehen.

Funktion allein genügt nicht

Seit dem Siegeszug digitaler Kleinkameras hat praktisch jeder von uns die Notwendigkeit, die vielen einzelnen Bilder am Computer irgendwie zu organisieren. Verwenden wir dies als Beispiel einer Anforderungsbeschreibung für ein Softwaresystem: Digitalfotos verwalten. Versetzen Sie sich in die Rolle eines Softwarearchitekten, der von einem Kunden die Anforderungen erklärt bekommt:

„Wir möchten Fotos in Ordnern organisieren und mit Schlüsselworten versehen. Später müssen wir nach verschiedenen Suchkriterien (etwa: Datum, Schlüsselwort etc.) Bilder suchen und anzeigen können. In unserer privaten Sammlung kommen wir mit einigen tausend Fotos aus, ein gesondertes Mengengerüst (= nichtfunktionale Anforderung) geben wir daher nicht an.“

Ganz einfach könnte unser gedachter Kunde diese Anforderung anhand der Abbildung 1 erklären: „So etwas wie dort abgebildet hätten wir gerne.“

Jetzt sind Softwarearchitekten gefragt, aus diesen (zugegeben, sehr groben) Anforderungen eine Lösung zu konstruieren. Dazu hilft ein fachliches Modell im Sinne des Domain Driven Design [1], was wir aus einem exemplarischen Foto (Abbildung 2) ableiten können. Ein Foto verfügt lediglich über eine Handvoll Attribute (Datum, Ort, Datei etc.). Die Schlüsselworte bilden wir als Liste ab, damit jedes Foto mehrere haben kann.

Das Domänenmodell mutet in unserem Beispiel nahezu trivial an (siehe Abbildung 3). Nur zwei kleine Entitäten genügen, um die gewünschte Funktionalität aus einer rein fachlichen Perspektive abzubilden. Ort, Datum, Ordner und Dateiname bilden wir über Key-Value Paare in der Klasse Metadata ab, die damit gleichzeitig noch die Liste der Schlüsselworte enthält. Einfacher geht’s kaum.

Softwarearchitekten und Entwickler können auf Basis eines solchen fachlichen Modells ruhig schlafen, weil DDD-Modelle häufig handhabbare Abstraktionen einer Fachlichkeit darstellen. Auf Basis solcher Modelle können wir oftmals Softwaresysteme sauber strukturieren und entwickeln. In unserem Beispiel müssten wir die klassischen CRUD-Aufgaben (create, read, update, delete) für unsere beiden Domänen-Entitäten implementieren, zusätzlich noch ein paar technische Aufgaben lösen, um das Foto-System zum Leben zu erwecken:

• Anzeige von jpeg-Dateien
• Layout und Implementierung einer grafischen Oberfläche

Für alle diese Aufgaben bieten die Standardbibliotheken der bekannten Programmiersprachen (Java, C#, Python etc.) bewährte Konstrukte an, so dass für die Implementierung unseres Beispielsystems keine großen Risiken drohen. Geschickte Entwickler können dieses System in kurzer Zeit realisieren. In unserem Beispiel würden Sie als Softwarearchitekt möglicherweise vorschlagen, ein fertiges Werkzeug einzusetzen, also „buy“ statt „make“ [1]. Nehmen wir an, dass Sie unserem hypothetischen Kunden eine dieser fertigen Lösungen präsentieren. Sie erfüllt sämtliche Funktionen, sieht dazu noch ansprechend aus. Der Kunde zeigt sich begeistert.

Aber…

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 50Gbyte 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. 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 von Benutzern und Petabyte an Daten konfrontieren ein Entwicklungsteam mit völlig neuen Aufgaben:

• Skalierbarkeit, um das System auch bei den geplanten Benutzerzahlen noch perfomant und reaktiv zu halten. Hierzu gehört Clusterung und Lastbalancierung, 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, dass 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 schwerlich 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 Qualität 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 Quailitätsbaumes: Die geforderte Software-Qualität wird in Untermerkmale zerlegt, welche ihrerseits bei Bedarf weiter zerlegt werden. Es entsteht eine hierarchische Struktur, die spezifische Qualitätsanforderungen an ein System beschreibt.

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.

Qualität systematisch konstruieren

Als Softwarearchitekt müssen Sie bei der Konstruktion und Implementierung Ihrer Systeme also von Beginn an großen Wert auf die Erreichung der wichtigen Qualitätsmerkmale legen. Zum Glück ist das in der Praxis mit ein bisschen Systematik auch ohne neue Werkzeuge gut machbar. Sie sollten erst mal Qualität zu Ihrem wichtigsten Entwurfsziel erheben und ihr dementsprechend Augenmerk widmen. Folgen Sie dann einem klassischen Planen-Handeln-Prüfen Zyklus (analog dem PDCA aus [2]) mit den folgenden Schritten:

1. Aim, zielen: Konkretisieren und priorisieren Sie die notwendigen Qualitätsanforderungen.
2. Plan, Maßnahmen planen: Definieren Sie (gemeinsam mit Ihrem Team) Maßnahmenpakete für die jeweiligen Qualitätsanforderungen. Priorisieren Sie auf Basis fachlicher und technischer Gegebenheiten.
3. Build, bauen: Setzen Sie die hoch priorisierten Maßnahmen um. Dies bedeutet meistens, Teile des Systems zu implementieren.
4. Check, prüfen: Überprüfen Sie die Wirksamkeit Ihrer Maßnahmen. Hierzu müssen Sie möglichst nah am laufenden System oder Teilen davon messen und testen. Bei Bedarf können Sie nun nachsteuern. Fahren Sie dazu bei Schritt 1 fort. Dieses zyklische oder iterative Vorgehen erhebt die systematische Überprüfung der Zielerreichung zum System [3]. Es stellt sicher, dass hoch priorisierte Qualitätsanforderungen rechtzeitig in der Konstruktion und Entwicklung berücksichtigt werden.

Die Build- und Check-Aktivitäten sind ganz normales Architektur- beziehungsweise Projektgeschäft – hingegen bedürfen Aim und Plan der Erläuterung.

Aim: Qualitätsziele konkretisieren

In der idealen Welt bekommen Sie als Softwarearchitekt aus dem Requirements-Engineering bereits konkrete und spezifische Qualitätsanforderungen als Vorgabe. Allerdings habe ich in langen Jahren in der IT-Branche selten ideale Zustände angetroffen – regelmäßig musste ich die Qualitätsanforderungen an Systeme nacharbeiten. Das hat den einfachen Grund, dass die Funktionen und Abläufe eines Systems sich meist recht einfach beschreiben lassen, sich Auftraggeber und andere Stakeholder jedoch mit der konkreten, präzisen Beschreibung von Wartbarkeit, Flexibilität, Robustheit, Ergonomie und Effizienz meist sehr schwer tun.

Dabei gibt es doch seit langer Zeit Abhilfe gegen dieses Problem: Methoden wie Qualitäts-Szenarien ([4], eine deutsche Kurzfassung in [5]) oder Planguage [6] helfen, Qualitätsanforderungen und –ziele pragmatisch und operationalisiert zu beschreiben. Ich möchte Ihnen die Szenarien, genauer gesagt Qualitätsszenarien, als nützliches Hilfsmittel vorstellen.

Weiter oben haben wir den Oberbegriff Qualität bereits in Form eines Qualitätsbaums verfeinert. Nun widmen wir uns den Blättern dieses Baumes. Wir konkretisieren diese Blätter mit Szenarien, um genauer zu beschreiben, was die jeweiligen Stakeholder mit diesem Begriff meinen. Dabei können sich durchaus mehrere unterschiedliche Szenarien auf ein einzelnes Qualitätsmerkmal beziehen. Wiederum sollen einige Beispiele (in Tabelle 1) statt grauer Theorie Ihnen diesen Ansatz erläutern. Allgemein beschreiben Szenarien die Reaktion eines Systems auf Ereignisse. Viele Qualitätsmerkmale lassen sich mit Hilfe von Szenarien konkretisieren, insbesondere Effizienz, Performance, Flexibilität, Erweiterbareit, Zuverlässigkeit.

Ich selbst habe gute Erfahrung damit gemacht, die Szenarien in Form einer Mindmap statt eines Baumes zu gruppieren, weil die Zuordnung eines Szenarios zu einem Qualitätsmerkmal oftmals mehrdeutig ist. Mindmaps bieten ein paar zusätzliche Strukturierungs- und Layoutmöglichkeiten und eignen sich hervorragend für interaktive Brainstorming-Workshops, in denen Qualitätsziele mit verschiedenen Stakeholdern erarbeitet werden. Letztlich ist die Anordnung reine Geschmackssache.

Bitte beachten Sie in Tabelle 1 die Spalte „Priorität“: Damit bringen wir die Qualitätsanforderungen in eine aus fachlicher Sicht angemessene Reihenfolge. Das fertige System wird sämtliche Qualitätsziele erreichen, die Priorität hilft während für Architektur und Entwicklung bei Entwurfs- und Implementierungsentscheidungen.

Nun haben wir die Qualitätsziele und –anforderungen geklärt und konkretisiert – jetzt geht es an den nächsten Schritt, Strategie und Taktik zur Erreichung dieser Ziele.

Plan: Qualitätsmaßnahmen definieren

„Dem Ingeniör ist nichts zu schwör“ – das gilt für Daniel Düsentrieb und im Falle der jetzt konkretisierten Qualitätsziele auch für Softwarearchitekten: Kennen wir erst das Ziel, definieren wir spezifische Maßnahmen, Konzepte und Technologie zu seiner Erreichung. Dabei können wir uns neben den Best Practices des Software-Engineering auch auf gängige Strategien und Taktiken (Len Bass hat in [4] dafür den Begriff Quality-Tactics eingeführt) für einzelne Qualitätsmerkmale stützen – brauchen also keinesfalls immer gleich Räder neu zu erfinden.

Bis dato fehlt zwar eine geschlossene Sammlung solcher Qualitäts-Taktiken, dennoch liefert Ihnen die gängige Literatur einen großen Fundus: Die seit einigen Jahren so verbreiteten Patterns helfen beispielsweise für die Qualitätsmerkmale Flexibilität, Robustheit, Performance und Sicherheit [7] etc. schon gut weiter – sofern Sie selbige mit dem Fokus auf qualitätssteigernde Maßnahmen betrachten. [8] hat den Anspruch, passende Qualitätsmaßnahmen, -taktiken und –strategien systematisch zu sammeln – steckt momentan allerdings noch in den Anfängen.

Die Methode QDSA verwendet die vorher definierten Qualitätsziele, um für jedes bekannte Qualitätsszenario oder –merkmal eine Menge möglicher Maßnahmen zu deren Erreichung zu sammeln. Sammeln Sie diese Maßnahmen mit Ihrem Team und schreiben Sie sie auf. Eine einfache Tabelle oder ein Flipchart genügt – sie brauchen keine besonderen Werkzeuge dafür.

Kommen wir ein letztes Mal auf unser Foto-Management Beispiel zurück und widmen uns auf diese Weise unserem anspruchsvollen Qualitätsziel „Hohe Benutzerzahl und große Datenmenge“: Folgende Vorschläge könnten positiv auf dieses Ziel hinwirken: NoSQL-Datenbank mit Auto-Replikation, Cluster-Hardware, frühzeitige Lasttests, Caching, Nutzung von Content-Delivery-Networks, Hardware-Loadbalancer, und und und… Kein Grund also, vor den Millionen Benutzern zu kapitulieren. Manche dieser Vorschläge sind teuer, andere schwierig umzusetzen. Aber wenn Ihr Kunde hohe Anforderungen hat, müssen Sie manchmal große Sprünge wagen, um diese Ziele zu erreichen! Das Brainstorming, Sammeln und systematische Analysieren von Maßnahmenvorschlägen ist der Kern der Quality-Driven Software Architecture (QDSA).

In diesem zentralen Schritt gilt es allerdings, an einer Stelle Vorsicht walten zu lassen: Einzelne Maßnahmen können leicht auf mehrere Qualitätsmerkmale Einfluss nehmen. Eine positive Auswirkung auf ein Merkmal, etwa Performance, kann leicht negative Auswirkungen auf andere Merkmale haben, etwa Speicherbedarf, Robustheit oder Einfachheit. Sie sollten vorab eine Konsequenzanalyse durchführen, ehe Sie mit der Umsetzung Ihrer Qualitätsmaßnahmen beginnen. Es hat sich nach meiner Erfahrung bewährt, solche potentiellen oder bekannten Konsequenzen direkt mit den Qualitätsmaßnahmen zu den jeweiligen Szenarien oder Qualitätszielen zu dokumentieren, das heißt sie auf jeden Fall schriftlich festzuhalten.

Was jetzt noch fehlt ist klassisches Projektgeschäft, nämlich die Maßnahmen im Projektalltag einzuplanen und anschließend umzusetzen. Ob Sie nun nach Scrum, dem V-Modell, RUP oder anderen Vorgehensmodellen arbeiten, bezüglich QDSA gibt es hier keinerlei Besonderheiten gegenüber normalem Vorgehen.

Qualität hat Wert

Qualität auf diese Weise systematisch zu konstruieren schafft für Ihre Stakeholder Werte: Softwaresysteme, die spezifische Qualitätsziele erreichen. Wie oben bereits erwähnt sind viele qualitätssteigernde Maßnahmen anfänglich teuer, aufwändig oder sogar riskant hinsichtlich anderer Ziele. Langfristig hingegen zahlt sich solche Investition in die Erreichung von Qualitätszielen praktisch immer aus. Bei reinen Kurzfrist-Managern ist solche Qualitätsorientierung daher oftmals unbeliebt, weil manche Investitionen sich eben nicht unmittelbar, sondern erst mit etwas Verzögerung amortisieren. Denken Sie daran, dass Qualität die Existenzberechtigung von Softwarearchitekten ist, insbesondere die nicht-funktionalen Merkmale lassen sich ohne systematische Konstruktion (=Architektur) kaum erreichen. Und wenn Software-Engineering einfach wäre, dann würden es schon lange die Maschinen für uns erledigen.

Referenzen

Evans: Domain Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003. Der ausführliche Klassiker zum Thema.