„Was man nicht messen kann, kann man nicht kontrollieren!“ lautet eine alte Weisheit, die mittlerweile auch in der Softwareentwicklung Berücksichtigung findet. Auch Softwarearchitekturen müssen entwickelt, kontrolliert und bewertet werden. Aber wie soll das funktionieren? Welche Maßstäbe existieren dafür und wie sollte der Softwarearchitekt vorgehen? Der folgende Artikel gibt einen Überblick, wie Softwarearchitekturen bewertet werden können, welche Methoden dem Architekten dafür zur Verfügung stehen und wie er die Ergebnisse zur Erstellung hochwertiger Softwaresysteme nutzen kann.
Motivation
Gewöhnlich entsteht die Architektur eines Systems schon in den frühen Entwicklungsphasen. Der Architekt muss sich also von Beginn an die Frage stellen, ob die gewählten architektonischen Konzepte zum Bau eines „guten“ Softwaresystems geeignet sind.
Diese Fragestellung begleitet ihn während des gesamten Lebenszyklus eines Systems. Da sich die Anforderungen immer wieder verändern können, ist die Bewertung der Architektur in jeder Iteration dringend angeraten.
Wird die Architektur nicht frühzeitig regelmäßig bewertet und angepasst, besteht die Gefahr, dass bestimmte Ziele und Anforderungen aus den Augen verloren werden. Zu spät bemerkt, ergeben sich daraus meist erhöhte Aufwände und Kosten, denn Korrekturen an der Architektur sind meist sehr teure Maßnahmen.
Gegenstand der Bewertung
Eine Softwarearchitektur direkt zu bewerten ist ein schwieriges Unterfangen. Einfacher ist es Aspekte zu betrachten, die entweder die Architektur beeinflussen, ein Teil von ihr sind oder sich als Auswirkung der Architektur präsentieren.
Im Wesentlichen handelt es sich dabei um die Anforderungen an das zu entwickelnde System, den Quellcode, die Dokumentation und um sonstige Artefakte, wie Testberichte und Analysen zum Verhalten (z.B. Performance- oder Durchsatzanalysen).
Ergebnisse
Der Aspekt der Qualitätssicherung steht für den Architekten im Vordergrund der Architekturbewertung. Er erwartet eine Antwort auf die Frage, ob die Architektur eines Systems für die geforderten Merkmale geeignet und gut ist. Diese allgemein gefasste Frage lässt sich aber meistens nur durch die Klärung einer Reihe von spezielleren Teilaspekten beantworten.
Dazu gehört beispielsweise die Validierung der funktionalen und nicht-funktionalen Anforderungen auf Vollständigkeit und Eindeutigkeit. Werden hier Lücken aufgedeckt, kann sich eine zunächst als geeignet bewertete Architektur plötzlich als völlig ungeeignet herausstellen. Ähnliches gilt für die Identifizierung von Risiken und die Überprüfung der bisher bereits vorgenommenen Architekturentscheidungen.
Weiterhin ist auch die genaue Intention der Architekturbewertung zu beachten. Neben der oben formulierten Frage nach der Eignung der Architektur, könnte eine Variante die Bewertung eine konkrete Implementierung auf die Einhaltung von Architekturvorgaben sein. Das Spektrum der Ergebnisse ist breit und kann von einfachen Ja/Nein-Aussagen, über feinere Abstufungen bis hin zu konkreten Maßnahmenkatalogen variieren.
Qualität und Quantität
Grundsätzlich wird zwischen der quantitativen und qualitativen Bewertung einer Architektur unterschieden. Während quantitative Methoden in der Regel Kennzahlen für bestimmte Messgrößen liefern, entziehen sich die qualitativen Methoden einer solchen Bewertung und liefern andere Ergebnisse, mit denen sie die Güte und Beschaffenheit einer Architektur beschreiben.
Quantitative Bewertung und Metriken
Unter einer Metrik versteht man eine Kennzahl, die für einen bestimmten Sachverhalt repräsentativ ist. Dahinter verbirgt sich eine Vorschrift zur quantitativen, reproduzierbaren Messung einer Größe oder eines Zustandes. In der Softwareentwicklung werden diese
Metriken meist im Rahmen einer statischen Quellcode-Analyse angewandt.
Zu den wichtigsten Größen zählen:
- Abhängigkeitsmaße (Kopplung)
- Komplexitätsmaße (mögliche Ablaufpfade, zyklomatische Komplexität)
- Strukturmaße (Vererbungstiefe)
- Größenangaben (Anzahl Code-Zeilen pro Klasse/Methode, Anzahl statischer Methoden, Anzahl Kommentare je Code-Zeile)
Ein großer Vorteil von Metriken liegt in der guten Unterstützung durch die Werkzeuge und damit in der Automatisierbarkeit. Sie lassen sich sehr leicht in ein Continous-Integration-Szenario einbinden. So stehen dem Architekten und den Entwicklern nach jedem Build die aktualisierten Ergebnisse zur Verfügung. Durch die zeitliche Bildung einer Historie lassen sich so Degenerationsprozesse des Quellcodes im Laufe der Entwicklung messen und Auswirkungen auf die Architektur einschätzen (siehe Abbildung 1).
Abb. 1: Metriken (hier: Sonar für das Apache CXF Projekt).
Ein weiterer Vorteil ist die Möglichkeit der Visualisierung. Neben der Abbildung in Charts, Abhängigkeitsgraphen und anderen Formen, existieren auch eine Reihe innovativerer Darstellungen wie z.B. Codecity (siehe Abbildung 2), die dem Betrachter auf den ersten Blick Hinweise auf potentielle strukturelle Schwächen der Architektur liefern.
Abb. 2: Visualisierung von Code-Strukturen in Codecity. [5]
Klassen und Pakete werden hier als Plateaus und Gebäude dargestellt. Die Farbe, Form, Höhe und Grundfläche der Gebäude sind mit bestimmten Metriken verbunden, so dass sich z.B aus der Kombination aus Höhe und Farbe bestimmte Eigenschaften der Klassen und Hinweise auf Architektureigenschaften ableiten lassen.
Gesunder Menschenverstand
Metriken stellen aber kein Allheilmittel dar. Der Hinweis „Wer viel misst, misst viel Mist!“ hat auch hier seine Gültigkeit. Metriken benötigen zum einen immer eine Norm, die jemand definiert. Eine Messgröße ist erst dann interpretierbar, wenn sie in einen Kontext eingebettet wird. So kann in einem Projekt ein Testüberdeckungsmaß für den Quellcode von 50 % oder von 90 % gefordert werden, beides kann je nach Situation und Projekt vollkommen korrekt sein.
„Traue keiner Statistik, die du nicht selbst gefälscht hast!“ ist ein gerne zitierter Satz, der aber auch im Zusammenhang mit Metriken einen bedenkenswerten Funken Wahrheit enthält. So hat beispielsweise ein Testüberdeckungsmaß von 80 % natürlich eine ganz andere Aussagekraft, wenn überwiegend Fachlogik getestet wurde, als beispielsweise Getter- und Setter-Methoden. Wird die Entwicklung zu sehr durch Metriken getrieben, kann das kontraproduktiv sein, da Entwickler dabei oft eine erstaunliche Kreativität an den Tag legen.
Weiterhin neigen Metriken dazu, eine scheinbare Sicherheit vorzugaukeln. Der Architekt und die Entwickler müssen sich immer im Klaren sein, dass sie zwar Hinweise auf den Zustand und die Veränderung der Software geben können, aber keinerlei Aussage über die Funktionsfähigkeit und Qualität zur Laufzeit zulassen.
Wohl überlegt angewendet, sind Metriken aber ein nützliches Hilfsmittel, um Hinweise auf Architektureigenschaften zu ermitteln. Eine kritische Betrachtung der verwendeten Metriken sollte aber selbstverständlich sein. Als alleiniger Indikator zur Bewertung einer Architektur sind sie völlig unzureichend. Der gesunde Menschenverstand ist schließlich durch nichts zu ersetzen.
Qualitative Methoden
Im Gegensatz zu den quantitativen Verfahren fehlt bei den qualitativen Methoden die offensichtliche Messgröße. Für die Bewertung wird aber eine Art Referenzwert benötigt, gegen den ein Maß angelegt werden kann. Dazu bedienen sich die qualitativen Methoden den nicht-funktionalen Anforderungen. Sie überprüfen, in welchem Maß die Architektur diesen Anforderungen genügt.
Szenariobasiert
Eine Möglichkeit solche „Referenzwerte“ zu definieren, ist die Beschreibung sogenannter Szenarien. Wie bereits in einem früheren Artikel zur Architekturentwicklung beschrieben [4], sollte es ein gemeinsames Verständnis aller Stakeholder bezüglich der (fachlichen) Funktionalität des Systems und deren Priorisierung geben.
Der Architekt versucht aus den fünf bis zehn wichtigsten fachlichen Anwendungsfällen anschließend die Architekturtreiber zu ermitteln. Dazu erstellt er einen speziellen Qualitätsbaum (Utility Tree), in dem er die entsprechenden nicht-funktionalen Anforderungen ein-
trägt und in Unterkategorien aufsplittet (siehe Abbildung 3).
Abb. 3: Die ersten beiden Ebenen eines Utility Tree (nach ISO 9126).
Anschließend werden die Architekturtreiber der konkreten Szenarien, die für die Qualitäten der nicht-funktionalen Anforderungen verantwortlich sind, formuliert. Diese müssen präzise und möglichst handlungsorientiert, für alle Projektbeteiligten verständlich und einvernehmlich, beschrieben werden.
Zusätzlich findet noch eine gemeinsame Priorisierung der Szenarien nach Nutzen bzw. Wirkung (geschäftlicher Wert) und nach Risiko (technische Schwierigkeit) statt. Als Skala reicht hier eine grobe, dreistufige Einteilung (High, Medium, Low). Eine solche Priorisierung ist beispielhaft in Abbildung 4 dargestellt. Mit diesen priorisierten Szenarien steht nun der Bewertungsmaßstab für die Architektur fest.
Abb. 4: Priorisierte Szenarien.
Bewertung
Die eigentliche Bewertung besteht in der Betrachtung der einzelnen Szenarien. Begonnen wird mit den am höchsten priorisierten (H, H). Jedes Szenario wird daraufhin untersucht, ob die aktuelle Architektur den geforderten Qualitäten des Szenarios entspricht. Durch die Analyse folgender Aspekte lassen sich Aussagen zur Güte der Architektur treffen und gegebenenfalls Maßnahmen zur Anpassung der Architektur ableiten:
- Welche Architekturkonzepte liegen der Umsetzung des Szenarios zugrunde?
- Welche Begründung gibt es für die Wahl der zugrundeliegenden Architekturkonzepte?
- Welchen Einfluss hat die Wahl der Architekturkonzepte auf andere Qualitätsmerkmale?
- Welche Kompromisse oder Risiken resultieren aus der Wahl der Architekturkonzepte?
Die Beurteilung der Ergebnisse unterliegt leider keinen allgemeingültigen Regeln, hier ist die subjektive Einschätzung des Architekten und damit auch eine gehörige Portion Erfahrung gefragt.
Die Architekturbewertung wird in der Regel in enger Zusammenarbeit mit den wichtigsten Stakeholdern durchgeführt. Oft sind es externe Architekten, die zusammen mit den Architekten und Entwicklern deren Systeme begutachten und das o.g. Verfahren durchführen. Dadurch werden allen Beteiligten noch einmal die Ziele und Prioritäten verdeutlicht und die wichtigsten Architekturkonzepte und -entscheidungen herausgearbeitet. Dies ist ein nicht zu unterschätzende positiver Nebeneffekt jeder Architekturbewertung.
SAAM und ATAM
Der szenariobasierte Ansatz stammt vom Software Engineering Institute (SEI) der Carnegie Mellon University und liegt den beiden Methoden SAAM (Software Architecture Analysis Method) und ATAM (Architeckture Tradeoff Analysis Method) zugrunde.
Beide Methoden sind strenger formalisiert und stehen im Ruf etwas zu akademisch zu sein. Der generierte Aufwand für die Durchführung ist höher, als bei anderen Methoden. Der zentrale Aspekt bei ATAM (als Weiterentwicklung aus SAAM) ist das Herausstellen von Tradeoff und Sensitivity Points. Damit sollen möglichst früh Risiken identifiziert werden, die aus in Konkurrenz stehenden Qualitätsattributen resultieren.
Erfahrungsbasierte Ansätze
Ebenfalls zu den qualitativen Methoden zählen die sogenannten erfahrungsbasierten Ansätze, die ganz auf den Erfahrungsschatz des Architekten setzen. Meistens führt er eine SWOT-Analyse (Strength,
Weakness, Opportunity, Thread) durch, in der die Stärken, Schwächen, Möglichkeiten und Risiken der Architektur aus seiner subjektiven Sicht heraus dokumentiert und gegebenenfalls entsprechende Maßnahmen abgeleitet werden. Diese Ansätze sind in der Regel weniger formell und lassen sich auch mit geringerem Aufwand durchführen. Sie bedürfen aber sehr erfahrener Architekten.
Fazit
Für die Bewertung von Softwarearchitekturen gibt es eine Reihe von Methoden. Keine von ihnen bietet einen universell anwendbaren Algorithmus, der ein aussagekräftiges Ergebnis liefern kann. Die Kompetenz und Erfahrung eines Softwarearchitekten ist und bleibt weiterhin notwendig.
Vielleicht sogar wichtiger als die Frage nach der Methode, ist die Erkenntnis, dass eine Architekturbewertung zur Qualitätssicherung unabdingbar ist und nur dann ihren Zweck erfüllt, wenn sie regelmäßig über den gesamten Lebenszyklus eines Softwaresystems durchgeführt wird.