Einfachheit und Reduktion

Reduktion ist die naheliegendste Möglichkeit, ein Software-System einfacher zu gestalten. Wir können zwei Arten der Reduktion unterscheiden:

• die Reduktion des Systems selbst (Reduktion des Aktualen)
• die Reduktion der Möglichkeiten (Reduktion des Potentiellen)

Diese beiden Bereiche lassen sich auf der Basis des vorgestellten allgemeinen Modells für Software-Systeme wie folgt veranschaulichen:

Für Software-Systeme ist es typisch, dass der Lösungsraum um ein Vielfaches größer ist als die tatsächlich gewählte Lösung. Das Verhältnis von Systemgröße zur Größe des Lösungsraums, das in der obigen Abbildung gewählt wurde, kann dies nicht annähernd widerspiegeln. Es ist erwähnenswert, dass aktuelle Untersuchungen zur Komplexität von Software-Systemen sich in der Regel auf die Komplexität des aktualen Systems konzentrieren und den Lösungsraum außer Acht lassen.

Reduktion des Systems selbst

Das oben minimiert abgebildete allgemeine Modell für Software-Systeme kann zur Untersuchung systemartiger Zusammenhänge im Bereich der Softwaretechnik verwendet werden kann. Es unterscheidet die Konzepte Funktion, Struktur, Hierarchie und Repräsentation, um zu einem umfassenden Gesamtbild von Software-Systemen zu gelangen, das zugleich frei von technologischen Details ist. Wenn wir uns nun fragen, worauf die Reduktion des Systems selbst abzielt, so können wir dies an Hand der einzelnen System-Konzepte beantworten:

• Reduktion der Funktion: Weniger Funktion hat in jedem Fall ein einfacheres System zur Folge. Hinter dieser Abwägung steckt letztlich eine Kosten/Nutzen-Kalkulation, die in jedem Einzelfall anders aussieht. Es ist selbstverständlich, dass im Bereich der Funktion der eigentliche Existenzgrund des Systems liegt und dass dieser Bereich nicht beliebig beschnitten werden darf. Andererseits bringen unterschiedliche Funktionen unterschiedlich viel Nutzen. Besonderes Augenmerk sollte daher auf Funktionen gelegt werden, deren Nutzen nur potentiell entsteht oder der nur sehr gering ist. "You Ain't Gonna Need It" (YAGNI) ist ein Prinzip, das auf diese Form der Reduktion abzielt.
• Reduktion der Struktur: Je weniger Elemente eine Struktur bei gleichbleibender Zahl der Relationen aufweist, desto einfacher ist die Struktur. Je weniger Relationen eine Struktur bei gleichbleibender Zahl der Elemente aufweist, desto einfacher ist die Struktur. Zu beachten ist, dass eine Strukturbetrachtung i. d. R. nur auf einer konkreten Hierarchie-Ebene stattfindet, dass aber zur Beurteilung der Komplexität des Gesamtsystems alle Ebenen berücksichtigt werden müssen. Es hilft also nicht, die strukturelle Komplexität von einer Ebene zur anderen zu verschieben. Beispielsweise würde die Realisierung eines Systems in einer einzigen großen Klasse die strukturelle Komplexität auf Typ-Ebene stark reduzieren. Im Gegenzug würde jedoch die strukturelle Komplexität auf der darunterliegenden prozeduralen Ebene stark ansteigen.
• Reduktion der Hierarchie: Je weniger tief eine Hierarchie ist, desto einfacher ist sie. Andererseits ist zu berücksichtigen, dass eine neue Hierarchie-Ebene oftmals eine Abstraktion der darunterliegenden Ebenen darstellt und daher auch eine Vereinfachung herbeiführen kann. Dies gilt insbesondere dann, wenn die Interaktion mit dem System in der Folge überwiegend auf der neuen Abstraktions-Ebene erfolgen kann, die für sich genommen einfacher strukturiert ist als die darunterliegenden Ebenen.
• Reduktion der Repräsentation: Je weniger umfangreich die Repräsentation eines Systems ist, desto einfacher ist das System. Auch hier ist jedoch davor zu warnen, dass Komplexität einseitig aus der Repräsentation in andere Konzepte verschoben wird. Beispielsweise basieren zahlreiche "Convention over Configuration"-Ansätze darauf, den Umfang der Repräsentation zu reduzieren. Diese Komplexität geht jedoch nicht vollständig verloren, sondern wird in die Konvention verlagert, welche fortan von jedem menschlichen Bearbeiter gelernt und berücksichtigt werden muss.

Die voranstehenden Betrachtungen haben gezeigt, dass mit der Reduktion des Systems oftmals Abwägungen verbunden sind. Das einseitige Verschieben von Komplexität von einem System-Bereich in einen anderen kann sinnlos oder gar kontraproduktiv sein. Wo immer Systemteile ersatzlos entfernt werden können, darf jedoch davon ausgegangen, dass eine Reduktion des Systems auch eine Vereinfachung des Systems bewirkt.

Reduktion der Möglichkeiten

Gegenüber der Reduktion des Systems selbst, die in vielen Fällen eine triviale Operation ist, liegt die Reduktion der Möglichkeiten meist viel weniger nahe. Und dies obwohl es sich dabei um eine Vorgehensweise handelt, die jeder Software-Entwickler und jeder Software-Architekt nahezu jeden Tag anwendet, ohne sich dessen bewusst zu sein. Der Grundgedanke besteht darin, dass jede Interaktion mit einem System umso aufwändiger ist, je mehr Möglichkeiten bestehen, um das Ziel der Interaktion zu erreichen. 

Soll beispielsweise eine neue Funktion in das System integriert werden, so gestaltet sich die Lösung für den Entwickler vergleichsweise einfach, wenn es für diese Art von Funktion genau eine verantwortliche Komponente gibt, in der die Funktion umgesetzt werden kann. Kommen hingegen mehrere Komponenten in Betracht, so muss der Entwickler eine Entscheidung treffen und dabei idealerweise alle fraglichen Komponenten zunächst untersuchen. 

Weitere Beispiele sind Typsysteme, welche die Zahl der möglichen Zuweisungen auf Variablen-Ebene limitieren, die Beschränkung der Zugriffs-Möglichkeiten auf interne Realisierungsdetails von Modulen, wie sie durch Modifizierer wie private oder protected erreicht werden können, oder Architekturvorgaben wie z. B. Schichtenmodelle, welche die Kommunikations-Möglichkeiten innerhalb des Systems auf globaler Ebene beschränken. Die Reduktion des Potentiellen ist in allen Bereichen der System-Konstruktion ein bedeutsames Mittel der Komplexitätsreduktion.

• Reduktion der funktionalen Möglichkeiten: Je offener ein System für künftige Funktionen bleiben soll, desto mehr Vorkehrung muss für diese Offenheit im System getroffen werden. Die meisten dieser Vorkehrungen gehen auf Kosten der Einfachheit. Es kann daher von Vorteil sein, ein System ganz bewusst auf bestimmte Funktionsbereiche zu reduzieren.
• Reduktion der strukturellen Möglichkeiten: Zahlreiche Vorgaben oder Technologien können eingesetzt werden, um den strukturellen Lösungsraum zu reduzieren. Auf globaler Ebene sind dies beispielsweise System-Architekturen, Komponenten-Modelle oder die Vorgabe von Entwurfsmustern für bestimmte Problemstellungen. Auf technologischer Ebene kann die Verwendung von Bibliotheken und Frameworks für bestimmte Problemstellungen die strukturelle Lösung weitgehend determinieren. Grundsätzlich gilt, dass die Reduktion umso wirksamer ist, je maschineller sie sichergestellt werden kann.
• Reduktion der hierarchischen Möglichkeiten: Hier gelten ähnliche Erwägungen wie für das Struktur-Konzept.
• Reduktion der repräsentationalen Möglichkeiten: Zu diesem Bereich gehört zum einen die Festlegung auf bestimmte Repräsentationsformen (z. B. Programmiersprachen oder Modellierungswerkzeuge), aber auch Regeln zur Verwendung dieser Repräsentationsformen (z. B. Entwicklungs-Richtlinien).