Inhalte
In vielen technischen Produktentwicklungen ist Software mittlerweile ein essentieller Bestandteil. Die Software Architektur, das heisst die Struktur und der Aufbau der Software, entscheidet oft über Erfolg oder Misserfolg des Produktes. Die Grundlagen von Software Architektur zu verstehen, schafft Verständnis in der Projektarbeit.
In diesem Beitrag erfährst Du:
Stell Dir vor…
Du möchtest ein Haus bauen. Du hast bereits konkrete Ideen, wie viele Zimmer Du haben möchtest, wie gross diese sein sollen und wie der Eingangsbereich und die Küche aussehen sollen.
Dann beauftragst Du einen Maurer einen Maler und einen Küchenbauer – schliesslich sind das doch alles Spezialisten und die werden doch meine Vorstellungen umsetzen können – denkst Du Dir.
Am ersten Bautag treffen die Handwerker bei Dir ein. Und dann….
dann fangen die Probleme und Fragen erst an:
- der Mauer weiss nicht wo er anfangen soll – er braucht einen Plan – er muss wissen welche Wände tragend sind und welche nicht
- der Maler und auch der Küchenbauer meinen, dass sie jetzt sowieso noch nichts machen können, bevor…
- ….
Das klingt recht bescheuert? Das ist es auch! Keiner würde so Vorgehen um ein Haus zu bauen.
Du würdest natürlich zuerst einen Architekten beauftragen. Dieser würde die Architektur erstellen und daraus einen Plan ableiten. Mit diesem Plan würdest Du dann die Handwerker in der richtigen Reihenfolge zum richtigen Zeitpunkt mit den relevanten Details aufbieten.
Was hast das mit Software Architektur zu tun?
In der Softwareentwicklung gibt es oft ähnliche Situationen. Es wird Software entwickelt d.h. programmiert – ohne vorab eine Architektur und einen daraus abgeleiteten Plan erstellt zu haben.
Was ist das Problem dabei?
- Eine vernünftige Planung einer grösseren Software Entwicklung ist ohne definiere Software Architektur kaum möglich
- Um die Anforderungen effizient und effektiv entwicklen zu können, ist die richtige Software Architektur eine Grundvoraussetzung
- Für die Sicherstellung der Software Qualität ist die Architektur essentiell
- Die Zukunftsfähigkeit einer Software wird zu einem grossen Teil durch die Architektur bestimmt
Und genau das sind die Gründe, weshalb das Thema Software Architektur wichtig ist.
Was ist denn eigentlich Software Architektur?
Das ist eine gute Frage. Schauen wir uns die Definition an:
Erstaunlicherweise gibt es nicht eine einzige etablierte Definition des Software Architektur Begriffes. Hier findet sich eine Liste von Definitionen: What Is Your Definition of Software Architecture
Aus meiner Sicht ist folgende Definition basierend aus „Software Architecture in Practices (Len Bass, Rick, Kazman, Paul Clements)“ am geeignetsten das Thema Software Architektur zu erklären:
Die Software Architektur definiert die Strukturen eines Software Systems. Diese Strukturen umfassen Software-Elemente, dessen nach aussen sichtbaren Eigenschaften sowie die Beziehungen zwischen den Elementen.
Was bedeutet das nun?
In der Software Architektur ist festgelegt, wie die Struktur der Software ist. Das heisst wie die Software aus Software Elementen aufgebaut ist und wie diese in Beziehung stehen. Die „nach aussen sichtbaren Eigenschaften“ bedeutet, dass nur die Eigenschaften in der Software Architektur relevant sind, welche einen Einfluss nach aussen haben. Dabei ist zu beachten, dass dies eine rekursive Definition ist. Das heisst nach aussen sichtbaren Eigenschaften des gesamten Systems ist das was für einen Nutzer der Software erkennbar ist. Für ein internes Software Element sind das die Eigenschaften, welche für andere Teile erkennbar sind.
Die nachfolgende Visualisierung veranschaulicht diese Software Architektur Definition:
Was hilft uns die Definition von Software Architektur?
Nun, am Schluss zählen die nach aussen sichtbaren Eigenschaften eines Systems. Natürlich ist das die Funktionalität, welcher der Nutzer der Software (in vielen Fällen ein Benutzer) erfährt und für ihn sichtbar ist. Aber Achtung: Was der Nutzer sieht ist nicht nur die Funktionalität, sondern er sieht und erfährt auch weitere Eigenschaften. Zum Beispiel: eine intuitive Bedienung oder die Schnelligkeit der Ausführung oder die Stabilität der Software u.s.w.
Das bedeutet, dass die Eigenschaften eines Systems, welche gewünscht oder gefordert sind, mit der entsprechenden Architektur sichergestellt werden müssen.
Ziel sollte immer sein, die Eigenschaften vorzugeben und daraus die richtige Architektur abzuleiten – anstelle: die Software aufzubauen und sich überraschen zu lassen, wie die nach aussen sichtbaren Eigenschaften ausfallen:
Was ist eine gute Software Architektur?
Mit diesen Erkenntnissen von oben ist diese Frage einfach zu beantworten: Eine Software Architektur ist dann gut, wenn diese die gewünschten Eigenschaften eines Software Systems sicherstellt / resp. ermöglicht. Damit ist auch klar, dass es nicht Die gute Software Architektur gibt – so wie es auch nicht Die gute Architektur eines Hauses gibt.
In 5 Schritten zur guten Software Architektur
Die Erstellung einer guten oder besser – der geeigneten – Software Architektur ist ein iterativer Prozess. Jede Iteration umfasst die folgenden 5 Schritte (vereinfacht basierend auf der Attribute Driven Design (ADD) Methode):
Schritt 1: Definiere das Ziel
Wichtig ist das Ziel einer Architektur Iteration explizit zu setzten. Ein solches Ziel könnte beispielsweise heissen: „Eine erste Aufteilung der Software ist gemacht“. Oder: „Die Performanz-Anforderungen sind berücksichtigt“. Eine Iteration kann also eine Aufteilung d.h. Strukturierung der Software oder auch die Erfüllung von konkreten Eigenschaften für einzelne Software Elemente umfassen. In jedem Fall ist jedoch das Ziel klar zu definieren. Das nachfolgende Bild visualisiert beispielsweise das Ziel einer ersten Strukturierung des gesamten Software Systems:
Schritt 2: Definiere die gewünschten Eigenschaften
Wie bereits weiter oben erwähnt ist nicht nur die Funktionalität wichtig, sondern auch die Qualitätseigenschaften (häufig auch nichtfunktionale Anforderungen genannt). Es ist gar folgendermassen:
Die Erfüllung der Qualitätseigenschaften bestimmt meist mehr über Erfolg oder Misserfolg resp. Kundenzufriedenheit eines Software Systems, als die korrekte Bereitstellung der Funktionalität.
Stelle Dir nur mal vor, Du verwendest eine einfache Berechnungs-Software um 2 Zahlen zu addieren. Die Funktionalität ist erfüllt, wenn Du die Zahlen addieren kannst und das korrekte Resultat erhältst. Aber wenn die Berechnung mehrere Sekunden dauert, dann wirst Du mit der Software nicht zufrieden sein. Du hast implizit eine Vorstellung von der Schnelligkeit der Berechnung – und wenn diese nicht eingehalten ist, dann wirst Du als Nutzer unzufrieden sein. Sowas ist nicht unüblich: Die Nutzer einer Software haben implizite Vorstellungen zu den Qualitätseigenschaften. Diese gilt es explizit zu machen und deren Erfüllung mit einer geeigneten Architektur sicherzustellen.
Eine weitere wichtige Erkenntnis ist:
Die Qualitätseigenschaften beeinflussen die Software Architektur meist mehr als die geforderte Funktionalität.
Auch das ist mit dem einfachen Beispiel einer Berechnungs-Software vorstellbar. Die Funktionalität ist wie bereits erwähnt die Addition von 2 Zahlen. Wenn beispielsweise die Forderung besteht, weitere Rechenoperationen als Erweiterungen zu der Software per Konfiguration hinzufügen zu können – dann hat das auf die Struktur der Software d.h. auf die Software Architektur einen grossen Einfluss.
Die Norm ISO/IEC 25010 definiert die Qualitätseigenschaften einer Software mit dieser Struktur:
Die gewünschten Eigenschaften zu definieren bedeutet nebst den funktionalen Anforderungen auch die Qualitätseigenschaften zu definieren. Es reicht jedoch nicht hierzu z.B. „Wartbarkeit“ einzufordern. Denn auf diesem Level sind die Qualitätseigenschaften nicht genügend klar und können damit nicht überprüfbar sichergestellt werden. Stattdessen sollte ein Qualitäts-Szenarium definiert werden.
Ähnlich einem Use Case werden damit die Qualitätseigenschaften konkretisiert. Anstelle „Wartbarkeit“ wäre eine nützlichere Formulierung: Als Anwender soll das Rechenprogramm während der Laufzeit mit zusätzlichen Rechenoperationen erweitert werden können. Das soll innerhalb von 5 Minuten per Konfiguration gemacht werden können.
Ein ideales Qualitäts-Szenarium ist mit 6 Teilen definiert:
- Source (die Quelle – in unserem konkreten Fall der „Anwender„)
- Stimulus (in unserem konkreten Fall „zusätzliche Rechenoperation hinzufügen„)
- Artifact (auf was der Stimulus einwirkt – in unserem Fall auf das „Rechenprogramm„)
- Environment (in welcher Umgebung das stattfindet – in unserem Fall zur „Laufzeit„)
- Response (das gewünschte Resultat / Verhalten – in unserem Fall die „neue Operation ist verfügbar„)
- Response Measure (die Messkriterien – in unseren Fall „innerhalb von 5 Minuten durch Konfiguration„)
Die folgenden Illustration zeigt das konkrete Qualitäts-Szenarium mit allen 6 Teilen:
Eine einfache Möglichkeit um mit den verschiedenen Stakeholder die Qualitätseigenschaften zu erarbeiten findet Du in diesem Blog-Beitrag: Visuelle Erarbeitung von Software Qualities.
Schritt 3: Abstrahiere
Aus der Menge der funktionalen Anforderungen und den gewünschten Qualitätseigenschaften musst Du jetzt diejenigen auswählen resp. auf diese reduzieren, welche für die entsprechende Iteration und dem definierten Ziel (Schritt 1) relevant sind. Das bedeutet schlussendlich eine Abstrahierung auf die relevanten zu berücksichtigenden Inputs.
Das ist meist nur ein Teil aller vorhandenen Anforderungen. Und das ist wichtig zu wissen, denn das bedeutet auch, dass nicht alle Anforderungen bekannt sein müssen um eine geeignete Architektur zu erstellen.
Das ist eine wichtige Erkenntnis:
Nicht alle Anforderungen sind relevant für die Architektur-Erstellung. Das heisst auch, dass nicht alle Anforderungen definiert sein müssen um sinnvoll mit dem Design der Software Architektur starten zu können.
Dazu werden die Begriffe „architektur-relevante Anforderungen“ (engl. architectural relevant requirements ) oder Architektur Treiber (engl. architectural driver) verwendet.
Schritt 4: Erarbeite eine Lösung
Nun da das Ziel für die Iteration geklärt ist sowie die zu berücksichtigenden Anforderungen d.h. die Architektur Treiber aufgelistet sind, müssen in diesem Schritt Lösungen gefunden und ausgewählt werden, welche sämtliche Architektur Treiber berücksichtigt und erfüllt.
In diesem Schritt erarbeitest Du Lösungen – beschäftigst Dich also mit dem Lösungsraum. Alle Schritte bisher waren im Anforderungsraum.
Aus meiner Sicht ist diese Unterscheidung zentral:
Es ist essentiell bei der Software Architektur Erstellung zwischen Anforderungsraum und Lösungsraum zu unterscheiden. Stelle diese Unterscheidung für alle Beteiligten im Prozess sicher.
Aufgrund der iterativen Arbeitsweise und der vorangegangenen Abstraktion sind die möglichen Lösungen meist recht offensichtlich. Als Inspiration und Quelle von Lösungen solltest Du die folgenden Lösungs-Grundlagen berücksichtigen:
- Architektur Stile (engl. architecture styles)
- Entwurfs Muster (engl. design pattern)
- Design Taktiken (engl. design tactics)
Diese Lösungs-Grundlagen sind in der Regel sehr gut beschrieben. Sie zeigen Dir bei welchen Anforderungen welche Lösungen oder Lösungsansätze verwendet werden können. Zudem werden die benötigten Software Elemente und deren Verbindungen aufgezeigt, um einen solchen Lösungsansatz in der eigenen Software einzubinden.
Beispielsweise zeigt die folgende Visualisierung Design Taktiken zum Thema Veränderbarkeit:
Ähnliche Auflistungen sind auch zu den anderen Qualitätseigenschaften wie Benutzbarkeit, Performanz u.s.w zu finden. Hier ist meine Empfehlung auf entsprechende Literatur zurückzugreifen – oder gezielt eine Web-Recherche durchzuführen. Eine Liste von Design Taktiken zu Veränderbarkeit findest Du beispielsweise hier: Modifiability Design Tactics.
Wenn eine Lösung gefunden wurde, dann ist diese mit den entsprechenden Software Elementen, deren Eigenschaften und Verbindungen in der Software Architektur festzulegen. Damit sind diese dokumentiert und können bei der Entwicklung entsprechend berücksichtigt werden.
Das tönt recht abstrakt – zugegeben. Deshalb ein Beispiel dazu:
Angenommen Du hättest Dich entschieden basierend auf Deinen Anforderungen das Publish-Subscriber Entwurfsmuster zu verwenden. Ausschlaggebend für diese Entscheidung war die Anforderung, dass ein Software Teil von einem anderen entkoppelt werden soll, sodass diese möglichst unabhängig voneinander sind. Jedoch brauchst Du einen Mechanismus, um aufgrund von dedizierten Ereignissen in dem einen Software Teil, Aktionen in dem anderen Teil auszulösen.
Zu dem Publish-Subscriber Entwurfsmuster lässt sich die folgende Struktur finden:
Basierend auf dieser generischen Struktur und den notwendigen Verbindungen kannst Du diese in Deiner eigenen Software Architektur einbinden. Das heisst Du erstellst die notwendigen Software Elemente mit den entsprechenden Verbindungen. Die Eigenschaften des Publish-Subscriber Entwurfsmuster (nämlich die Entkopplung und Benachrichtigung) hast Du dann für die geforderten Teile Deiner Software.
In ähnlicher Art und Weise verfährst Du mit allen Architektur Treiber, bis sich die entsprechende Struktur als Software Elemente, Verbindungen und Eigenschaften etabliert hat:
Schritt 5: Überprüfe und starte die nächste Iteration
Im letzten Schritt solltest Du nochmals Bezug auf das Iterations-Ziel und die Architektur Treiber nehmen und die Erfüllung überprüfen. Gegebenenfalls musst Du nochmals zum Schritt 4 zurück und nacharbeiten.
Falls alle Architektur Treiber berücksichtig wurden, dann kann falls nötig die nächste Iteration gestartet werden.
Mit diesem Vorgehen lässt sich iterativ und gezielt eine Software Architektur erstellen, welche die gewünschten Eigenschaften erfüllt:
Siehe dazu auch den folgenden Blog-Beitrag: Systematisch die perfekte Software Architektur erstellen.
Eine Software Architektur kann beurteilt werden – das Architektur-Review
In vielen Fällen geht es nicht nur um die Neuerstellung einer Software, sondern um die Erweiterung oder Anpassung von bestehender Software. Häufig wird in diesem Zusammenhang die Software Architektur in Frage gestellt. Ist die Architektur gut – oder muss diese überarbeitet werden? Ist die Software noch zukunftsfähig – oder muss ein Neubau in Betracht gezogen werden?
Auch wenn die Software Entwicklung stockt, die Softwarefehler sich häufen, stellt sich oft die Frage: ist die Software richtig konzipiert? Wurde die richtige Architektur gewählt?
In solchen Fällen kann eine fundierte Beurteilung einer Software Architektur sinnvoll sein.
Für eine solche Beurteilung müssen natürlich die gewünschten Eigenschaften bekannt sein (siehe weiter oben – Du erinnerst Dich?). Da in vielen Fällen diese Eigenschaften jedoch nicht explizit definiert und bekannt sind, müssen diese vor einer Beurteilung ermittelt werden. Dann lohnt es sich eine formelles Architektur-Review durchzuführen.
Eine etablierte Methode dazu ist die Architecture Tradeoff Analysis (ATAM) Methode. Dabei werden die gewünschten Eigenschaften definiert und diese den gemachten Architektur-Entscheidungen gegenübergestellt. Bei dieser Methode werden als Eigenschaften in erster Linie Qualitätseigenschaften betrachtet, da davon ausgegangen wird, dass die Funktionalität berücksichtig ist – oder gar bereits implementiert ist. Die Bewertung erfolgt dann anhand verschiedener Kriterien, welche zu konkreten Hinweisen in der folgenden Form führen:
Mit einer solchen Bewertung lässt sich qualitativ aufzeigen, ob die Architektur die gewünschten Eigenschaften der Software erfüllt. Wenn die Bewertung in Bezug auf die gewünschten Eigenschaften in einem Diagramm visualisiert wird, dann könnte das so aussehen:
Weitere Informationen zu dem Architektur-Review nach der ATAM Methode findest Du hier: Software Architektur überprüfen – Qualität garantiert in 8 Schritten.
Sollte eine Software Architektur dokumentiert werden?
Das ist eine Frage, welche ich öfters höre. Gerade in agilen Software Teams kommt diese Frage immer mal wieder auf.
Meine Antwort darauf: Das hängt davon ab – nämlich von dem Kontext in dem die Software gebaut wird. Wenn eine Software alleine gebaut wird und diese nach der initialen Erstellung nicht mehr verändert wird, dann müssen wahrscheinlich keine Strukturen dokumentiert werden.
Wann lohnt sich die Dokumentation einer Software Architektur?
Dann wenn…
- Mit einem Team an einer Software gearbeitet wird
- Oder die Software über die Zeit immer wieder erweitert, ergänzt und angepasst werden soll (was wohl für die meisten Software Systeme gilt)
- Oder sichergestellt werden muss, dass gewünschte Eigenschaften wirklich auch erfüllt werden (z.B. bei sicherheitskritischen Anwendungen)
- …
Eine Software Architektur besteht wie wir bereits wissen aus Strukturen, Elemente und deren Wechselwirkungen. Diese explizit festzuhalten hilft für die Teamarbeit, die Weiterentwicklung sowie der Sicherstellung der gewünschten Eigenschaften.
Wie dokumentierst Du eine Software Architektur?
Jede Dokumentation – nicht nur eine Software Architektur Dokumentation – sollte auf die Bedürfnisse der entsprechenden Leser ausgerichtet sein.
Zusätzlich wissen wir, dass eine Software Architektur die Strukturen der Software definiert. Aber nicht alle Strukturen sind für alle Leser relevant. Zudem sind heutige Software Systeme und deren Architekturen derart komplex, dass sich diese nicht mit einer Ansicht beschreiben und erklären lassen. Aus diesem Grund werden sogenannte Architektur-Sichten definiert. Jede Sicht fokussiert sich auf einen Teilaspekt – (Struktur / Teilstruktur / Elemente / Wechselwirkungen) der Software. Alle Sichten zusammen müssen dann die Bedürfnisse an die Dokumentation erfüllen.
Zusammengefasst:
Für eine Software Architektur Dokumentation definiere die Bedürfnisse der Leser. Erstelle diejenigen Architektur-Sichten, welche die Bedürfnisse abdecken, indem jede Architektur-Sicht sich auf einen Teilaspekt der Architektur fokussiert.
Auch das in einem Bild visualisiert:
Software Architektur und Agilität – Freunde oder Feinde?
Ganz klar: Freunde!
Aber Warum?
Der hier gezeigte Prozess zur Erstellung einer Software Architektur hat bereits viele agile Aspekte in sich. Er ist iterativ und berücksichtigt die entsprechenden Anforderungen für jede Iteration. Mit dem Konzept der Architektur-Treiber werden auch nur die relevanten Inputs in jeder Iteration berücksichtigt. Es werden keine kompletten Anforderungen als Input für die Architektur-Erstellung benötigt – einer agilen d.h. iterativen und inkrementellen Software Entwicklung steht also nichts im Wege.
Aus meiner Sicht ist die Erstellung einer geeigneten Software Architektur gar essentiell für agiles Arbeiten:
Nur eine geeignete Architektur erlaubt eine Software agil das heisst iterativ und inkrementell zu bauen. Dazu sind Eigenschaften wie „Erweiterbarkeit“ und „Skalierbarkeit“ entsprechend zu definieren und in der Architektur vorzusehen.
Zusammenfassung aus Sicht von SYSTEMArt®
SYSTEMArt® DAS INGENIEURSPRINZIP
Systematik
Systematische Software Architektur Erstellung heisst:
- Definition der gewünschten (Ziel-) Eigenschaften (funktionale Anforderungen und Qualitätseigenschaften)
- Iteratives und schrittweises Vorgehen
- Definierte Iterations-Ziele
Struktur
Folgenden Strukturen sind essentiell in Bezug auf Software Architektur:
- Unterscheidung von Anforderungsraum und Lösungsraum
- Unterscheidung der Inputs in funktionale Anforderungen, Qualitätsanforderungen und Architektur Treiber
- Strukturierte Bewertung einer Software Architektur mit Risks, Non-Risks, Tradeoffs und Sensitivities
- Aufbau einer Architektur-Dokumentation aus verschiedenen Architektur-Sichten
Methodik
Die folgenden etablierten Methoden und Techniken sollten verwendet werden:
- Attribute Driven Design (ADD) Methode für das iterative Erstellen einer Architektur
- Architecture Tradeoff Analysis (ATAM) Methode für das Bewerten einer Architektur
- Qualitäts-Szenarien um Qualitätseigenschaften zu definieren
- Etablierte Lösungsgrundlagen (Architektur-Stile, Entwurfsmuster und Design-Taktiken)
- Software Architektur Dokumentation basierend auf Architektur-Sichten
Agilität
Mit diesen Massnahmen ist die Agilität sichergestellt:
- Iterative und inkrementelle Architektur Erstellung
- Reduktion auf die relevanten Anforderungen für jede Iteration
- Prüfen der Zielerreichung pro Architektur-Iteration
Du kannst mit den 5 Aspekten von SYSTEMArt® und diesen Auflistungen auch gut überprüfen, ob in Deinem Umfeld das Thema Software Architektur genügend fundiert angegangen wird.
Mehr zum Ingenieursprinzip findest Du hier: SYSTEMArt®.
Und zum Schluss….
Ich hoffe Dir damit dieses grosse Thema einfach, klar verständlich und umfassend dargestellt zu haben. Auch wenn Du kein Software Entwickler oder Software Architekt bist, dann solltest Du mit diesem Hintergrund in der Lage sein, zu Software Architektur Themen mitsprechen zu können. Ich hoffe das hilft Dir Verständnis, Klarheit und Transparenz in Deiner Projektarbeit zu erreichen.
Welche Fragen hast Du noch zum Thema Software Architektur?
Falls Du bereits konkrete Bedürfnisse zum Thema Software Architektur hast, dann schau doch hier: Geölte Softwareentwicklung
Setze Dich weiter für Klarheit ein!
Matthias
