Einfachheit der Struktur - Architekturkomplexität

Bei meinem bisherigen Betrachtungen zur Einfachheit von Strukturen habe ich praktische Erwägungen noch weitgehend ausgeklammert. Ich habe Strukturen allgemein als eine Menge von Elementen und Relationen zwischen diesen Elementen aufgefasst, wobei die Elemente wiederum aus Subelementen bestehen, die ihrerseits durch Relationen verbunden sind usw. Diese Betrachtungsweise ist eng an die Mathematik angelehnt, so dass die Bewertung von Strukturen u. a. auf Konzepte aus der Mengenlehre und der Graphentheorie zurückgreifen kann. 

Nun spielt sich die Konstruktion von Software-Systemen nicht im sterilen Betrachtungsraum der Mathematik ab, sondern wird stark von praktischen Aspekten beeinflusst. Dies gilt insbesondere auch für die Architektur von Software-Systemen. Aus rein struktureller Sicht können wir die Architektur eines Software-Systems als seine höchste Struktur-Ebene auffassen, also als die Ebene der Subsysteme. Die bereits behandelten Konzepte der Größe, Kohäsion und Kopplung sind auf diese Subsystem-Ebene direkt anwendbar. In praktischer Hinsicht sind jedoch eine Reihe weiterer Kriterien für die Bewertung von Software-Architekturen relevant. Neben den Aspekten individueller Kognition gehören hierzu auch Fragen der arbeitsteiligen Beherrschung von Software-Systemen sowie die Auswahl und Kombination von Technologien zur Realisierung des Systems.

In diesem Artikel stelle ich ein Komplexitätsmodell vor, das speziell für die Ebene der Software-Architektur entwickelt wurde und das diese praktischen Fragen berücksichtigt. Ausgehend von der Arbeit "Komplexität von Softwarearchitekturen" von Carola Lilienthal [Lilienthal2008] wurde dieses Modell in [Lilienthal2010] unter der Bezeichnung Software Architecture Complexity Model (SACM) weiterentwickelt und stellt nach meiner Kenntnis das derzeit umfassendste Modell dieser Art dar. 

1. Kognitive Grundlagen

In [Lilienthal2008] werden die kognitiven Grundlagen des Modells beschrieben. Es werden drei elementare kognitive Prozesse unterschieden, die der Mensch zur Bewältigung von Komplexität einsetzt:

• Chunking: das Zusammenfassen von Informationen zu höherwertigen Einheiten
• Bildung von Hierarchien: die Nutzung hierarchischer Strukturen  (z. B. in Form von Kategoriensystemen, Teile-Ganzes-Beziehungen oder Vererbungsbeziehungen) zur Erleichterung des Verstehens, des Lernens und des Abrufens von Information
• Aufbau von Schemata: der Einsatz von Wissenseinheiten, die sowohl abstrahiertes Wissen (Festlegung typischer Zusammenhänge und Eigenschaften) als auch konkretes Wissen (die Beschreibung prototypischer Exemplare) umfassen

Für Lilienthal ergibt sich nach der Untersuchung dieser Prozesse

"(...) die Erkenntnis, dass der Mensch mit Chunking, der Bildung von Hierarchien und dem Aufbau von Schemata auf komplexe Strukturen reagiert. Ein Softwaresystem, das von seiner Architektur her diese Prozesse unterstützt, hat geringe Architekturkomplexität." [Lilienthal2008]

Sie ordnet daher den drei Prozesstypen Faktoren zu, die sich in einer gegebenen Software-Architektur wiederfinden müssen, damit diese Architektur kognitiv beherrschbar bleibt. Es handelt sich um die folgenden Faktoren (Hervorhebung von mir):

• "Modularität: prüft, ob die implementierte Architektur in kohäsive Einheiten zerlegt ist, die ihr Verhalten kapseln und kohäsive Schnittstellen anbieten.
• Geordnetheit: prüft, ob die Beziehungen zwischen den Elementen der implementierten Architektur einen gerichteten azyklischen Graphen bilden.
• Mustertreue: prüft, ob das Muster der beabsichtigten Architektur und der eingesetzten Technologie in der implementierten Architektur wiedergefunden werden kann, und ob ihre Regeln eingehalten wurden." [Lilienthal2010]

Gemeinsam werden diese Faktoren als "persönliche Faktoren" bezeichnet.

2. Umgebungsfaktoren

Während sich die persönlichen Faktoren unmittelbar aus kognitiven Prozessen ableiten, die der Beherrschung von Komplexität dienen, leiten sich zwei weitere Faktoren aus dem Kontext der arbeitsteiligen Beherrschung von Software-Systemen ab.

Diese Faktoren waren im ursprünglichen Modell aus [Lilienthal2008] noch nicht enthalten und wurden später insbesondere in Zusammenarbeit mit Eric Bouwers und Kollegen hinzugefügt. Ausgangspunkt für diese Erweiterung war die empirische Untersuchung [Bouwers2009], in welcher ein Katalog aus fünfzehn Systemeigenschaften erarbeitet wurde, welche die Wartbarkeit einer Software-Architektur stark beeinflussen. In [Lilienthal2010] wird argumentiert, dass sich diese Ergebnisse auch auf die Komplexität einer Architektur übertragen lassen, da eine Systemeigenschaft zunächst verstanden werden muss, bevor sie gewartet werden kann ("Since a system attribute has to be understood bevor it can be maintained (...)" [Lilienthal2010]).

Wie sich zeigte, decken die oben beschriebenen persönlichen Faktoren lediglich einen Teil der von Bouwers und Kollegen gefundenen Attribute ab. Insbesondere werden solche Attribute nicht erfasst, die in der Praxis dazu führen, dass ein Individuum die notwendige Arbeit nicht alleine bewältigen kann, so dass sich zu den individuellen kognitiven Prozessen zusätzliche Organisationsaufwände zwischen verschiedenen Individuen gesellen. Bezogen auf die Information, die erforderlich ist, um die Architektur des Systems zu verstehen, werden die folgenden Faktoren ergänzt:

• Umfang der Information: Mit dem Umfang der Information steigt die Wahrscheinlichkeit, dass es zur Verteilung kognitiver Arbeit auf unterschiedliche Individuen kommt.
• Zugänglichkeit der Information: Damit die architekturbezogene Information effektiv verarbeitet werden kann, muss sie für das bearbeitende Entwicklerteam gut zugänglich sein. Zugänglichkeit (engl. availability) wird hier in einem sehr weiten Sinn verstanden: Beispielsweise spielt die Repräsenationsform der Architektur ebenso eine Rolle wie das Alter oder die Zusammensetzung der eingesetzten Technologien.

3. Gesamtbild

Die fünf Faktoren werden nun um Kriterien zu einem Factor-Criteria-Metrics-Modell ergänzt, das auf höchster Ebene ein festgelegtes Ziel aufweist und in welchem die auf unterster Ebene zu definierenden Metriken noch fehlen. 

Als Ziel vermerken Lilienthal und Kollegen in [Lilienthal2010] zwar "Complexity", sie notieren jedoch im Text: "(...) this goal is named 'complexity', although strictly speaking the goal of SACM is to evaluate and reduce complexity." Ich habe mir daher erlaubt, den positiven Begriff der "Einfachheit" in das Modell einzusetzen. Es ergibt sich das folgende Gesamtbild:

Die Beschreibung der insgesamt 18 Einzelkriterien möchte ich mir an dieser Stelle sparen. Eine gute Übersicht wird in [Lilienthal2010] gegeben. Statt dessen möchte ich einige allgemeine Anmerkungen machen. 

Am leichtesten fällt uns die Einordnung der Kriterien zur Modularität und Geordnetheit:

• Die Kriterien der Modularität basieren größtenteils auf Prinzipien, die ich bereits ausführlich in früheren Artikeln behandelt habe, darunter hohe Kohäsion, lose Kopplung, Geheimnisprinzip und Vermeidung von Redundanz. Dem Aspekt der Ausgewogenheit sind wir bereits im Komplexitätsmodell von Roger Sessions begegnet, der die Komplexität einzelner Elemente mit der Anzahl ihrer Funktionen exponentiell steigen lässt, was zu einer großen Ausgewogenheit beim Erzeugen einer Partitionierungs-Lösung führt.
• Die Kriterien der Geordnetheit basieren allesamt auf dem Acyclic-Dependencies Prinzip, zu dem ich eine ausführliche Artikelserie veröffentlicht habe.

Die Kriterien zur Mustertreue zielen im Wesentlichen auf die Frage ab, ob sich Architekturvorgaben im realisierten System wiederfinden lassen. Im Rahmen meines allgemeinen Modells für Software-Systeme lässt sich dieser Faktor also in das Konzept der Repräsentation einordnen, das ich wie folgt veranschaulicht habe:

Da sich Architekturvorgaben (wie z. B. Schichtenmodelle, größere Subsysteme usw.) häufig nicht unmittelbar in der Syntax der verwendeten Programmiersprache ausdrücken lassen, thematisiert Lilienthal die Übereinstimmung von Spezifikation/Dokumentation mit der eigentlichen Realisierung des Systems. Verstößt die ausführbare Systembeschreibung gegen Spezifikation oder Dokumentation, so wird dies als Komplexitäts-erhöhend bewertet. Diesem Thema werde ich mich in einem späteren Artikel zum Konzept der Repräsentation noch etwas eingehender widmen.

Bleiben schließlich noch die Umgebungsfaktoren. Hier wird die pragmatische Ausrichtung von SACM am deutlichsten:

• Die Kriterien zum Umfang zielen keineswegs lediglich auf die Repräsentation des Systems selbst ab (entweder als Spezifikation/Dokumentation oder als ausführbare Systembeschreibung), sondern auch auf die Lernkurve hinsichtlich der Verwendung von Technologien, Bibliotheken und Mustern.
• Die Kriterien zur Zugänglichkeit thematisieren die Art der Bereitstellung von architekturbezogener Information, das Alter dieser Information sowie die Geläufigkeit der Kombination eingesetzter Technologien. Auch dies ist sehr pragmatisch gedacht. Komplexität wird hier nahezu gleichgesetzt mit dem Aufwand des Kennenlernens eines Systems.

4. Grenzen von SACM

4.1. Konzeptionelle Grenzen

SACM setzt die beiden vieldimensionalen Konzepte "Architektur" und "Komplexität" in einem Zusammenhang. Die Gefahr eines solchen Modells besteht darin, einen Bewertungsraum zu schaffen, der in seiner Vieldimensionalität kaum mehr als Einheit wahrgenommen werden kann. SACM löst dieses Problem, indem die Bedeutung der beiden Begriffe eingeschränkt wird. 

So wird mit Komplexität in den meisten Fällen Verstehenskomplexität gemäß der Darstellung in [Lilienthal2008] bezeichnet:

Verstehenskomplexität in der Software-Entwicklung [Lilienthal2008:Verstehenskomplexität]

Auch die durch Brouwers eingebrachten Attribute, die aus einer Studie bezogen wurden, welche die Wartbarkeit von Architekturen untersucht hat, werden mit dem Argument in das Modell aufgenommen, dass einer Wartungstätigkeit zunächst das Verstehen vorausgehen muss. (Diesem Argument muss man nicht ohne Einschränkung zustimmen.)

Der Architekturbegriff, der dem Modell zu Grunde liegt, erscheint hingegen weitaus unschärfer. Im realisierten System werden insbesondere die Ebenen der Subsysteme und Klassen als das Wesentliche der Architektur angesehen. Durch die Berücksichtigung von Spezifikation/Dokumentation im Rahmen des Faktors Mustertreue wird diese Sicht jedoch über das realisierte System hinaus ausgedehnt. Schließlich verschwimmen diese Grenzen durch die Berücksichtigung der Arbeit von Bouwers und Kollegen vollends, indem zur Architektur praktisch jede Information gehört, die erforderlich ist, um die implementierte Architektur zu verstehen (" (...) information needed to understand the implemented architecture" [Lilienthal2010]). Auf diese Weise kommen Elemente ins Spiel, die über eine rein strukturelle Betrachtung aus Elementen und Relationen weit hinausgehen (z. B. Technologien oder Medien).

4.2. Grenzen beim Einsatz im Software-Lebenszyklus

Die SACM-Kriterien zerfallen in zwei Gruppen, nämlich in

• solche Kriterien, die bereits als Entscheidungshilfe in frühen Entwurfs- und Entwicklungsphasen geeignet sind 
• und solche, die sich lediglich zur Evaluation bereits realisierter Systeme eignen

Zur ersten Gruppe gehören die Kriterien der Faktoren Modularität, Geordnetheit und Umfang der Information, zur letzteren die Kriterien des Faktors Mustertreue. Von den Kriterien des Faktors Zugänglichkeit der Information eignet sich allenfalls "Informations-Medium" bereits in frühen Phasen des Lebenszyklus, während "Alter" und "Technologie-Kombination" erst in späteren Phasen relevant werden.

5. Fazit

Insgesamt ist das Modell vergleichsweise umfassend. Von den vier Grundkonzepten eines Software-Systems (Funktion, Struktur, Hierarchie und Repräsentation, siehe System-Modell) wird das Struktur-Konzept am besten abgedeckt, das Hierarchie-Konzept zumindest ansatzweise (Vermeidung von Zyklen) und das Repräsentations-Konzept in einer eher pragmatischen Weise. Das funktionale Konzept spielt allerdings eine untergeordnete Rolle, obwohl einige funktionale Aspekte (die Berücksichtigung der Daten und der verhaltensbezogenen Eigenschaften) sicherlich auch für die Architekturkomplexität relevant sind. 

Das Modell ist eine gute Orientierungshilfe, wenn man sich dem Zusammenhang von Software-Architektur und Komplexität annähern möchte. Während die weitgehende Gleichsetzung von Komplexität mit "Verstehenskomplexität" noch eine akzeptable Vereinfachung darstellt, die von vielen anderen Autoren geteilt wird, scheint der Architekturbegriff des Modells (insbesondere auch ggü. seiner ursprünglichen Fassung in [Lilienthal2008]) jedoch etwas zu unscharf geraten zu sein. Diese Unschärfe ist andererseits dem Anspruch geschuldet, ein Modell zur Verfügung zu stellen, das alle praxisrelevanten Aspekte der "Architekturkomplexität" abdeckt.

6. Quellen

[Bouwers2009] - Criteria for the evaluation of implemented architectures, Eric Bouwers, Joost Visser, Arie van Deursen (2009)

[Lilienthal2008] - Komplexität von Softwarearchitekturen. Stile und Strategien, Carola Lilienthal (2008) 

[Lilienthal2008:Verstehenskomplexität] - Abbildung aus [Lilienthal2008], S. 13, mit freundlicher Genehmigung von Carola Lilienthal

[Lilienthal2010] - A Cognitive Model for Software Architecture Complexity, Eric Bouwers, Carola Lilienthal, Joost Visser, Arie van Deursen, Delf University of Technology (2010)