© jd8/Shutterstock.com
Grundlagen einer erfolgreichen Architektur

Softwarearchitektur: Worauf es ankommt


Die Architektur definiert die Struktur eines Softwaresystems und ist zentral für den Erfolg eines Projekts. Deswegen ist Softwarearchitektur so wichtig. Aber in Wirklichkeit ist Softwarearchitektur noch viel mehr, und eine erfolgreiche Softwarearchitektur erfordert viele, teilweise überraschende Maßnahmen.

Wenn man die wesentlichen Aspekte von Softwarearchitektur beschreiben soll, muss man zunächst den Begriff Softwarearchitektur an sich klären. Wikipedia und der Standard ISO/IEC 42010 definieren Softwarearchitektur als die grobgranulare Strukturierung eines Softwaresystems. Dazu passt der Begriff „Architektur“: Die Architektur eines Gebäudes gibt die groben Strukturen vor. Die meisten Architekturentwürfe zeigen dementsprechend die Aufteilung des Systems in größere Komponenten.

Ein Gedankenexperiment zeigt, inwieweit diese Definition ausreichend ist: Eine Software geht nicht in Produktion – ein Sicherheitsproblem und ein Problem mit der Compliance wurden entdeckt. Einen solchen Fehlschlag kann man wohl kaum als erfolgreiche Architektur bezeichnen. Aber das Sicherheitsproblem ist wahrscheinlich nicht auf der Ebene der Strukturierung des Systems zu erkennen. Es kann ein einfacher Programmierfehler oder eine unsichere Technologie sein, die zu dem Problem geführt hat. Also muss Softwarearchitektur etwas anderes umfassen als nur die Struktur des Systems, denn offensichtlich können auch andere Faktoren zu einem Architekturfehlschlag führen.

Martin Fowler als anerkannter Experte sieht Softwarearchitektur als die Menge aller wichtigen und schwer änderbaren Entscheidungen [1]. Das passt besser zu dem Gedankenexperiment: Offensichtlich waren die Entscheidungen im Sicherheitsbereich wichtig, denn sie haben verhindert, dass das System in Produktion ging. Und sie sind nicht einfach zu ändern, sonst wäre das Problem schnell gelöst worden. Also ist diese Definition eigentlich ganz gut. Genau genommen kann man vorab nicht wissen, welche Entscheidungen schwer zu ändern sind. Wie schwierig das ist, findet man nur dann heraus, wenn man die Entscheidung tatsächlich revidiert.

Eine andere Möglichkeit, Softwarearchitektur zu definieren, ist relativ simpel: Softwarearchitektur bedeutet, dass man eine technische Softwarelösung für das jeweilige Problem entwirft. Diese Definition ist nicht sonderlich spezifisch. Sie passt zu allen Arten von technischen Ingenieursdisziplinen. Aber sie zeigt, wie wichtig es ist, das Problem zu kennen, das gelöst werden muss. Der Hinweis auf das zu lösende Problem mag trivial erscheinen. Allerdings enthalten Architekturdokumentationen zwar fast immer eine Darstellung der grobgranularen Struktur des Systems, aber fast nie Informationen darüber, welches Problem das System eigentlich überhaupt lösen soll. So ist es schwierig, die konkreten Entscheidungen nachzuvollziehen oder zu bewerten.

Qualitätsbaum

Für die Darstellung einer Architektur haben sich mittlerweile viele unterschiedliche Wege etabliert, die weithin genutzt werden. Es gibt auch Werkzeuge, um das Problem besser verstehen und darstellen zu können. Die sind aber bei weitem nicht so bekannt. ISO 25010 definiert dafür den Qualitätsbaum. Auch Standards für die Architekturdokumentation wie arc42 [2] beinhalten solche Aspekte. Abbildung 1 zeigt einen Ausschnitt aus dem Qualitätsbaum, in dem verschiedene Qualitätsmerkmale wie Sicherheit oder Zuverlässigkeit aufgelistet sind.

Für jedes Qualitätsmerkmal gibt es eine Liste von Teilmerkmalen, die es einfacher machen, ein Qualitätsmerkmal wirklich vollständig zu betrachten. Bei Zuverlässigkeit geht die Diskussion oft schnell in die Richtung Verfügbarkeit. Ein Blick in den Qualitätsbaum zeigt weitere Teilmerkmale wie Fehlertoleranz, was bedeutet, dass ein System trotz des Ausfalls einiger Komponenten weiter funktionieren muss. Ein weiteres Teilmerkmal ist die Wiederherstellbarkeit: Es kann wichtig sein, dass ein System nach kurzer Zeit wieder zur Verfügung steht. Bei Sicherheit ist in der Abbildung nur ein beispielhaftes Teilmerkmal aufgelistet: die Nachweisbarkeit. Es kann sein, dass Benutzerinteraktionen beispielsweise vor Gericht nachgewiesen werden müssen. Durch den Qualitätsbaum wird offensichtlich, welche Merkmale Software überhaupt erfüllen kann. Architekten können mit dem Qualitätsbaum überprüfen, ob wirklich alle wesentlichen Qualitätsmerkmale der Software betrachtet worden sind.

wolff_softwarearchitektur_1.tif_fmt1.jpgAbb. 1: Ausschnitt aus dem Qualitätsbaum

Qualitätsszenarien

Aber der Qualitätsbaum reicht nicht aus: Die Einhaltung der Qualitätsmerkmale können nur schlecht verifiziert werden. Doch auch dafür gibt es ein geeignetes Softwarearchitekturwerkzeug: Das Qualitätsszenario (Abb. 2). Ein Qualitätsszenario beschreibt ein Ereignis, das auf das System einwirkt, und eine Metrik, um das gewünschte Verhalten des Systems zu definieren. Diese Metrik sorgt dafür, dass das Qualitätsszenario konkret und leicht zu verifizieren ist. Es gibt verschiedene Arten von Szenarien, die im Folgenden dargestellt werden.

Bei Benutzungsszenarien geht es um Anforderungen, die sich aus der Benutzung ergeben. Ein Beispiel: „Wenn sich ein Benutzer registriert, soll nur einer von 1 000 Benutzern die Hotline anrufen.“ Das Ereignis ist die Registrierung. Die Metrik ist die Anzahl der Anrufe bei der Hotline. Das Szenario beschreibt das Qualitätsmerkmal der Benutzbarkeit. Durch die Metrik ist sichergestellt, was mit einem „einfach zu benutzenden System“ gemeint ist. Um dieses Qualitätsszenario zu erfüllen, kann man beispielsweise UX-Experten zum Projekt hinzuziehen oder Ben...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang