Mit Qualitätsmerkmalen gute Software schaffen

Quality-driven Software Architecture

Dr. Gernot Starke

Qualität bildet die Existenzberechtigung für Softwarearchitekten: Zuverlässig, performant, skalierbar und benutzerfreundlich sollen unsere Systeme sein, das alles kosteneffektiv und zukunftssicher. Jeder ITler weiß, dass diese Kombination von Eigenschaften harte Arbeit bedeutet. Lesen Sie hier, wie Softwarearchitekten systematisch Qualität konstruieren können.

Wollen wir die Qualität 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 Softwareentwurf 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 besteht für praktisch jeden 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 (heißt, eine nichtfunktionale Anforderung) geben wir daher nicht an.

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

Abb. 1: Beispielhafte Anforderungen an Fotomanagement

Jetzt sind Softwarearchitekten gefragt, aus diesen (zugegeben, sehr groben) Anforderungen eine Lösung zu konstruieren. Dabei hilft ein fachliches Modell im Sinne des Domain-driven Design [1], das wir aus einem exemplarischen Foto (Abb. 2) ableiten können.

Abb. 2: Foto als Grundlage für Domänenmodell

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 (Abb. 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änenentitäten implementieren, zusätzlich noch ein paar technische Aufgaben lösen, um das Fotosystem zum Leben zu erwecken:

Abb. 3: Domänenmodell für das Foto-Beispiel
  • Anzeige von jpg-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, sodass der 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“ [2]. 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.

Geschrieben von
Dr. Gernot Starke
Kommentare

Schreibe einen Kommentar

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