Was ist Softwarearchitektur? – Teil 1

Was ist eigentlich Softwarearchitektur? Dazu kann man natürlich eine Menge lesen. Aber bisher hatte ich deshalb noch kein so richtiges Gefühl dafür. Wissen (im Kopf) und “Gefühlsgewissheit” sind eben nicht dasselbe.

Nun hat sich das aber geändert. Jetzt fühle ich, was ich bisher vielleicht schon wusste. Oder ich habe das Gewusste nun so verändert, mir gemäß angepasst, dass ich auch wirklich dahinter stehen kann.

Also, was ist Softwarearchitektur? Bei Wikipedia steht: Softwarearchitektur ist…

[…] eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen. […] Dabei enthält eine Beschreibung der Software-Architektur nicht nur Informationen über die Struktur […] eines Software-Systems, sondern auch Informationen über die Kommunikation zwischen Komponenten, sowie deren Abbildung auf Hardware- oder Software-Ressourcen (Verteilung und Deployment). […] Sie wird wesentlich durch Softwarequalitätskriterien, also nicht-funktionale Eigenschaften wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance bestimmt (siehe beispielsweise FURPS). Eine einmal eingerichtete Softwarearchitektur ist später nur mit hohem Aufwand abänderbar. Die Entscheidung über ihr Design ist somit eine der kritischsten und wichtigsten Punkte im Entwicklungsprozess einer Software.

Hilft das weiter? Bis vor wenigen Tagen hätte ich gesagt, “Hm… vielleicht” ;-) Aber heute kann ich sagen: “Ja, das ist es!” Allerdings braucht es noch etwas mehr, als diese Worte. Die finde ich nun zwar richtig, doch sehr abstrakt. Die Abstraktheit war es bisher, die mir für eine “Gefühlsgewissheit” im Wege stand.

Damit es Ihnen nicht so geht wie mir, will ich im Folgenden versuchen, die Definition für Sie konkreter zu machen. Dafür stelle ich sie in einen Kontext, grenze ich sie ab und konkretisiere sie für .NET.

Vorher allerdings eine verkürzte Definition zum leichteren Erinnern:

Softwarearchitektur kümmert sich um die nicht-funktionalen Anforderungen an Software

Kontext

Software entsteht nicht einfach so, nachdem Sie Anforderungen verstanden haben. Sie setzen sich danach nicht sofort an die Tastatur und klimpern los. Naja, zumindest sollten Sie das nicht tun ;-) Softwareentwicklung besteht daher mindestens aus zwei Phasen: einer Planung und einer Ausführung. Die Ausführung nenne ich Implementierung.

Die Planung baut natürlich auf dem Verständnis der Anforderungen auf. Aber die lasse ich mal heute außen vor.

Unter Planung verstehe ich das Nachdenken darüber, wie das, was am Ende implementiert werden soll, aussehen soll, und wie man dieses Ziel am besten erreicht. Das ist natürlich eine ganze Menge. Also zerfällt die Planung nochmal in die Planung von Strukturen und die Planung der Herstellung der Strukturen. Ersteres nenne ich Entwurf, letzteres (Arbeits)Organisation.

Und wann kommt endlich die Softwarearchitektur ins Spiel? Jetzt. Sie ist einer der beiden Teile des Entwurfs. Softwarearchitektur entwirft die Strukturen einer Software soweit, dass sichergestellt ist, dass die nicht-funktionalen Anforderungen erfüllt werden. Um die funktionalen Anforderungen kümmert sich dann die Modellierung.

Es ergibt sich also das “Gleichungssystem”:

• Softwareentwicklung = Planung + Implementierung
• Planung = Entwurf + Arbeitsorganisation
• Entwurf = Architektur + Modellierung

Das ist meine Verortung von Softwarearchitektur im Kontext der Softwareentwicklung. Sie hat sich bisher als pragmatisch-praktisch erwiesen. Ich strebe damit keine vollständigumfassendalleinseligmachende Definition an, sondern nur eine, die alltagstauglich ist, die ich leicht vermitteln kann.

Vor allem bekomme ich damit ein paar Begriffe unter einen Hut. Architektur/architecture und Entwurf/design waren für mich bisher nämlich nur unscharf gegeneinander abgegrenzt. Jetzt ist mir ihr Verhältnis klar. Entwurf/design ist der umfassendere Begriff; Architektur/architecture ist nur ein Teil des Entwurfs/design.

Oder Modellierung/modelling und Architektur/architecture: Nun kann ich sie klar unterscheiden, da Architektur/architecture sich um die nicht-funktionalen Anforderungen kümmert und Modellierung/modelling um die funktionalen. Natürlich bewegt sich  Modellierung/modelling dabei im von der Architektur/architecture vorgegebenen Rahmen. Denn Architektur/architecture entwirft das Softwaresystem auf einer grundlegenden Ebene; die entstehenden Strukturen sind vergleichsweise schwer zu ändern.

Wer sich einmal entscheidet, ein kleines Wochenendhaus am Hang eines Berges zu bauen, der kann daraus später nicht einen Wolkenkratzer machen. Und wer einen Sportwagen entwirft, der entwirft andere Strukturen, als würde er einen Trecker planen. In beiden Fällen stellen die nicht-funktionalen Anforderungen (z.B. Hanglage oder hohe Geschwindigkeit) Weichen, die den Entwurf der Strukturen zur Erfüllung der funktionalen Anforderungen auf gewisse Bahnen lenkt.

Daraus ergibt sich für die Anforderungserhebung: Die vornehmste Aufgabe eines Anforderungsanalysten ist es, die nicht-funktionalen Anforderungen zu erheben. Sie müssen möglichst früh und möglichst vollständig vorliegen. Aus ihnen leitet der Softwarearchitektur dann möglichst zügig und vor weiterer Planung die fundamentale Struktur des Softwaresystems ab.

Dazu mehr im nächsten Teil dieser kleinen Serien…