Einfachheit der Struktur - ein allzu einfaches Modell

In seinem 2008 erschienenen Buch "Simple Architectures for Complex Enterprises" [Sessions2008] sowie in seinem White Paper "The Mathematics of IT Simplification" [Sessions2011] stellt Roger Sessions ein Komplexitätsmodell vor, das eine mathematisch fundierte Bewertung der Komplexität von Strukturen verspricht. Wie sich herausstellen wird, ist dieser Anspruch etwas zu hoch gegriffen. Ich werde den Bewertungsansatz hier dennoch etwas ausführlicher vorstellen, um die allgemeinen Probleme, die mit einem solchen Gesamtmodell verbunden sind, an einem Beispiel verdeutlichen zu können.

1. Funktionen und Partitionen

Sessions bezeichnet das fundamentale Element, das es zu strukturieren gilt, in [Sessions2011] als "Funktion" (engl. function). In seinem White Paper weicht er terminologisch ggü. seinem umfassenderen Buch [Sessions2008] leicht ab, was sich ggf. dadurch begründen lässt, dass im Buch das Thema "Enterprise Architecture" zur Diskussion steht und daher Business-Prozesse und IT-Systeme gemeinsam betrachtet werden, während das White Paper den Schwerpunkt auf die IT-Systeme legt. Ich übernehme hier die Terminologie des White Papers. 

Der Ausgangspunkt der Betrachtung besteht also in einer unpartitionierten Menge an Funktionen. Dies ist grundsätzlich konform zu meinem allgemeinen Modell für Software-Systeme, das sich auf unterster Ebene (ausgenommen die Repräsentation) aus Funktionen und Daten-Objekten konsitutiert. (Siehe hierzu auch Einfachheit der Struktur - Grundlagen, dort den Abschnitt "3. Funktionen und Daten als Ursprung aller Relationen").

Sessions geht davon aus, dass die Komplexität, die sich durch eine unstrukturierte Menge von Funktionen in einem modernen Software-System ergibt, bei weitem zu groß ist, um noch handhabbar zu sein. Die einzige Möglichkeit, diese Komplexität zu bändigen, besteht in der Partitionierung der Funktionen: ihrer Aufteilung in kleinere, noch handhabbare Einheiten. Da Sessions von der Mengenlehre ausgeht, bezeichnet er eine solche Einheit als "Untermenge" (engl. subset). Die Aufteilung aller Funktionen in Untermengen, so dass jede Funktion genau einer Untermenge angehört, bezeichnet er als "Partition" (engl. partition). Eine Partition ist also eine Menge von Untermengen aus Funktionen.

Man könnte den Begriff "Partition" misverstehen und damit eine der Untermengen einer bestimmten Partitionierungs-Lösung meinen. Um hier jegliche Probleme zu vermeiden, werde ich statt von "Partition" immer von "Partitionierungs-Lösung" sprechen, wenn eine konkret gebildete Menge von Untermengen gemeint ist. Den Vorgang der Erzeugung einer solchen Partitionierungs-Lösung bezeichne ich als "Partitionierung" (engl. partitioning oder driving the partition).

2. Die Anzahl möglicher Partitionierungs-Lösungen: Bellsche Zahl

Die Abbildung unten zeigt die möglichen Partitionierungs-Lösungen für fünf Elemente - es handelt sich um 52 Möglichkeiten. Wieviele Lösungen sind allgemein für n Elemente möglich? Diese Größe wird durch eine Folge beschrieben, die als Bellsche Zahl bekannt ist. Die Folge beginnt (für n >= 1) wie folgt: 1, 2, 5, 15, 52, 203, 877, 4140, 21147, 115975, 678570, …

Quelle: Wikipedia Commons, 
siehe [Bild1]

Der Beginn dieser Folge zeigt, dass es bereits ab einer kleinen Zahl der zu partitionierenden Elemente praktisch unmöglich ist, alle möglichen Lösungen einzeln zu betrachten und zu evaluieren. Doch selbst wenn es möglich wäre, eine solche Evaluation für eine ausgewählte Zahl möglicher Lösungen durchzuführen: Worauf sollte sie basieren? Welche Eigenschaften sind es konkret, die eine Lösung "einfacher" als eine andere sein lassen?

3. Die Bewertung einer Lösung

Roger Sessions unterscheidet zwei Eigenschaften einer Lösung, die er als functional complexity und coordination complexity bezeichnet:

• Functional complexity bezeichnet die Komplexität einer einzelnen Untermenge innerhalb der Partionierungs-Lösung.
• Coodination complexity bezeichnet die Komplexität, die sich aus den Relationen zwischen den Untermengen einer Partitionierungs-Lösung ergibt. 

Er präsentiert eine Möglichkeit zur Evaluation dieser beiden Eigenschaften, die auf den mathematischen Eigenschaften der Partitionierungs-Lösung basiert. Durch additive Verknüpfung der beiden Eigenschaften kommt er zu einer Gesamtbewertung, die ihm schließlich den Vergleich zweier Lösungen erlaubt. Wir werden uns nun den Gedankengang näher anschauen, auf dem die mathematische Bewertung beruht.

4. Die Bewertung der functional complexity

Enthält eine Untermenge nur eine Funktion F₁, so kann auch nur eine Funktion für ein Problem verantwortlich sein. Enthält eine Untermenge zwei Funktionen F₁ und F₂, so entstehen drei mögliche Konstellationen: Entweder ist die Funktion F₁ oder die Funktion F₂ oder das Zusammenspiel von F₁ und F₂ für das Problem verantwortlich. Es lässt sich leicht erkennen, dass die Zahl möglicher Konstellationen mit der Zahl der Funktionen exponentiell anwächst. Andererseits existieren zahlreiche völlig abwegige Partitionierungs-Lösungen, deren Betrachtung einem halbwegs erfahrenen Experten nichteinmal einfallen würde. Sessions betrachtet den exponentiellen Zusammenhang dennoch als nachgewiesen und macht einen Vorschlag zur Wahl des Exponenten.

Dabei orientiert er sich an einer Aussage von Robert Glass aus dessen Buch "Facts and Fallacies of Software Engineering" [Glass2002], nach der eine Erweiterung der System-Funktionen um 25% zu einer Verdoppelung der Komplexität führt. Nach einiger Umrechnung führt dies zu einem Exponenten von 3,11. Setzt man die Komplexität einer einzelnen Funktion gleich 1 und verwendet diese als Maßeinheit namens SCU (Single Complexity Unit), so ergibt sich für eine Anzahl n von Funktionen:

SCU(n) = n^3,11

Was lässt sich über diesen Gedankengang sagen? Einerseits steht die Annahme eines exponentiellen Wachstums in Einklang mit den Annahmen anderer Autoren wie z. B. [Wang2007], der als Komplexität eines Systems aus n Subsystemen den Wert n * (n - 1) annimmt. Andererseits gibt es doch auch einige Bedenken:

1. Der Gedankengang ignoriert die tatsächliche Zahl der inneren Relationen einer Partition. 
2. Der Gedankengang ignoriert auch die Form, die sich aus den konkreten inneren Relationen einer Partition ergibt.
3. Aus (1) und (2) ergibt sich, dass das Konzept der Kohäsion weitgehend ignoriert wird.
4. Der Gedankengang ignoriert mögliche Unterschiede in der Komplexität der einzelnen Funktionen innerhalb der Untermenge.
5. Nicht jede Tätigkeit am System ist eine "Problemlösung" in der hier angenommenen Form.

Aus dem Gesagten ergibt sich, dass es einige Gründe gibt, den behaupteten mathematischen Zusammenhang anzuzweifeln. Andererseits ist es unbestritten, dass die Komplexität einer Einheit im Durchschnitt stärker ansteigt als ihre Größe. Dies hatten wir auch bereits im Artikel über die Zusammenhänge zwischen Größe, Kohäsion und Kopplung festgestellt. Diese Zusammenhänge sind jedoch wesentlich unklarer als es von Roger Sessions suggeriert wird. Um eine derart konkrete Modellierung zu untermauern, müsste sowohl empirisch als auch theoretisch (z. B. mengentheoretisch oder graphentheoretisch) wesentlich präziser argumentiert werden.

5. Die Bewertung der coordination complexity

Für die Bewertung der coordination complexity einer konkreten Untermenge nimmt Sessions trivialerweise an, dass

"... the amount of complexity added by increasing the dependencies by one is roughly equal to the amount of complexity added by increasing the number of functions by one" [Sessions2011],

wobei unter dependencies alle Abhängigkeiten der betrachteten Untermenge von anderen Untermengen, also nur die ausgehenden Abhängigkeiten gewertet werden. Die Begründung des exponentiellen Anstiegs der Komplexität erscheint hier jedoch äußerst dürftig. Warum sollte der Beitrag einer Abhängigkeit zur Gesamtkomplexität gleich hoch sein wie der Beitrag einer Funktion?

6. Gesamtbild der Bewertungsmethode

Die Gesamtkomplexität ergibt sich in Sessions Modell aus der Addition der functional complexity mit der coordination complexity. Die noch stärkere Multiplikation zieht Sessions ebenfalls in Betracht, wählt aber in dieser Hinsicht den konservativeren Ansatz. Somit gelangt er zu einer Gesamtformel der strukturellen Komplexität je gebildeter Untermenge, die er selbst als "Total Complexity" bezeichnet. Gehen wir von einer Untermenge U mit n Elementen und m ausgehenden Abhängigkeiten aus, so ergibt sich

SCU(U) = n^3,11 + m^3,11

Die Komplexität des Gesamtsystems ergibt sich dann einfach aus der Addition der SCU-Werte aller Untermengen. Was lässt sich auf der Grundlage dieser Modellbildung über den entstehenden Charakter einer "optimalen" Partitionierungs-Lösung sagen? 

Die functional complexity steigt mit wachsender Zahl der Elemente einer Untermenge exponentiell, die coordination complexity steigt mit wachsender Zahl der ausgehenden Abhängigkeiten einer Untermenge exponentiell. Daraus folgt, dass Ausreißer hinsichtlich der Größe oder der Anzahl ausgehender Abhängigkeiten "bestraft" werden. Der exponentielle Komplexitätsanstieg dieser Ausreißer würde die Gesamtkomplexität des Systems stark ansteigen lassen.
 
Die Anwendung des Bewertungsmodells muss also zu einer großen Ausgewogenheit hinsichtlich der Größe einzelner Untermengen sowie zu einem gleichmäßigen Grad der Eigenständigkeit der Untermengen führen. Übermäßig große oder übermäßig unselbständig arbeitende Partionen werden sanktioniert. 

Während diese Erwägungen nicht unplausibel erscheinen, will doch nicht ganz einleuchten, warum es nicht doch einzelne Elemente mit einer größeren Zahl von Subelementen geben soll, wenn diese Subelemente beispielsweise in einer sehr engen kohäsiven Beziehung stehen, wie wir es im Artikel zur Kohäsion bereits an folgendem Beispiel verdeutlicht haben:

Es fällt auf, dass das Konzept der Kohäsion überhaupt nicht in das Bewertungsmodell einfließt. Zwar schlägt Sessions ein Konzept vor, das mit Kohäsion eng verwandt ist (er nennt es Synergie) und das dabei helfen soll, eine Partitionierungs-Lösung zu erzeugen, doch dieses Konzept fließt nicht in den Bewertungs-Mechanismus ein.

6. Fazit

Das Modell von Roger Sessions ist auf den ersten Blick aus mehreren Gründen attraktiv:

• Es basiert auf einer nachvollziehbaren mengentheoretischen Grundlage.
• Es führt die Komplexität gebildeter Struktur-Elemente und die Komplexität der Abhängigkeiten dieser Elemente zu einer Gesamtkomplexität zusammen.
• Es liefert vergleichbare Bewertungen unterschiedlicher Lösungen.

Bedauerlicherweise ist Sessions dabei jedoch die mathematische Präzision auf halbem Wege verlorengegangen. An dem Bewertungsmodell lassen sich mindestens die folgenden Kritikpunkte anbringen:

• Der behauptete exponentielle Komplexitätsanstieg durch das Hinzufügen von Funktionen basiert lediglich auf einer intuitiv geführten Argumentation und wird keineswegs mengentheoretisch nachgewiesen (wie es an einigen Stellen suggeriert wird).
• Der behauptete exponentielle Komplexitätsanstieg durch das Hinzufügen weiterer Abhängigkeiten wird noch schwächer begründet.
• Das wichtige Konzept der Kohäsion bleibt bei der Bewertungsfunktion völlig unberücksichtigt.

Es war mir dennoch wichtig, das Modell an dieser Stelle etwas detaillierter vorzustellen, da es zeigt, dass auch in der jüngsten Literatur noch kein fundierter Ansatz existiert, der uns eine zuverlässige Bewertung der strukturellen Komplexität einer gegebenen Struktur-Ebene ermöglicht. Zudem werden die Probleme bei der Bildung eines solchen Gesamtmodells sichtbar: Es ist keineswegs klar, wie sich z. B. der Aspekt der Kohäsion in das Modell einfügen könnte. Auch über den Beitrag der Größe im Verhältnis zum Ausmaß der Kopplungen werden hier bestenfalls triviale Annahmen gemacht, die einem zweiten Blick nicht standhalten. 

Nach mehr als einem halben Jahrhundert der Praxis und Theoriebildung im Software Engineering ist es ernüchternd, wie rudimentär unser Verständnis elementarer Konzepte noch ist.

7. Quellen

[Bild1] -  "Set partitions 5; circles" by mate2code - Own work. Licensed under CC BY 3.0 via Wikimedia Commons.

[Glass2002] - Facts and Fallacies of Software Engineering, Robert Glass (2002)

[Sessions2008] - Simple Architectures for Complex Enterprises, Roger Sessions (2008)

[Sessions2011] - The Mathematics of IT Simplication, Roger Sessions (2011), siehe http://dl.dropboxusercontent.com/u/97323460/WebDocuments/WhitePapers/MathOfITSimplification-103.pdf

[Wang2007] - Software Engineering Foundations - A Software Science Perspective, Wang, Yingxu (2007)