Beitrag erstellt am: 09.01.19
Im ersten Teil zum Thema habe ich gezeigt, wie Software-Kategorien
helfen, die Komponenten unsere Systeme nach klaren Regeln zu ordnen und damit die strukturelle Qualität unserer Lösungen zu verbessern.
Wir erinnern uns: Software-Kategorien erlauben es, die Software-Komponenten eines Systems in Wissensgebiete einzuteilen.
Im vorliegenden Beitrag gehe ich näher auf die erlaubten und unerwünschten Abhängigkeiten ein zwischen Komponenten der verschiedenen Kategorien von ART-0.
Wir erinnern uns: Software-Kategorien erlauben es, die Software-Komponenten eines Systems in Wissensgebiete einzuteilen.
Im vorliegenden Beitrag gehe ich näher auf die erlaubten und unerwünschten Abhängigkeiten ein zwischen Komponenten der verschiedenen Kategorien von ART-0.
ART-0
Kategorien sind teilgeordnet: Jede Kategorie kann eine oder mehrere andere Kategorien verfeinern.
Für Software einer hohen Kategorie ist Software einer verfeinerten Kategorie sichtbar; das heisst Kategorie-0 ist für alle sichtbar. Damit sollte auch klar sein, dass die Idee der Kategorien nicht mit dem gängigen Schichtenkonzept verwechselt werden darf, da es gerade das Wesen der Schicht ist, die ihr unterliegenden Schichten vor ihren Verwendern zu verbergen!
Für je zwei Kategorien X und Y gibt es im Kategoriegraphen mindestens eine erste gemeinsame Vorfahrenkategorie; dies ist die höchste Ebene der Kommunikation und die speziellste Kategorie, via derer sich X und Y verständigen können. Das heisst, Komponenten können miteinander kommunizieren, sobald sie eine Schnittstelle der passenden Kategorie besitzen, die beide verstehen.
Für Software einer hohen Kategorie ist Software einer verfeinerten Kategorie sichtbar; das heisst Kategorie-0 ist für alle sichtbar. Damit sollte auch klar sein, dass die Idee der Kategorien nicht mit dem gängigen Schichtenkonzept verwechselt werden darf, da es gerade das Wesen der Schicht ist, die ihr unterliegenden Schichten vor ihren Verwendern zu verbergen!
Für je zwei Kategorien X und Y gibt es im Kategoriegraphen mindestens eine erste gemeinsame Vorfahrenkategorie; dies ist die höchste Ebene der Kommunikation und die speziellste Kategorie, via derer sich X und Y verständigen können. Das heisst, Komponenten können miteinander kommunizieren, sobald sie eine Schnittstelle der passenden Kategorie besitzen, die beide verstehen.
Kategorie-0 ist stets die Wurzelkategorie
In der Kategorie-0 befindet sich das allgemeine Grundwissen, das überall verwendet werden kann und keine unerwünschten
Abhängigkeiten erzeugt. Die Wurzelkategorie jeder weiteren Kategorie ist stets die Kategorie 0.
Reine und unreine Kategorien
Eine Software-Kategorie wird als rein bezeichnet, wenn es im Kategoriegraphen von ihr zur Kategorie 0 genau einen Weg
gibt, im anderen Fall wird sie unrein genannt. Unreine Kategorien vermengen zwei oder mehr Kategorien.
Möglichst reine Komponenten
Das Ziel ist es, möglichst reine Software-Komponenten zu erhalten. Gerade für Komponenten innerhalb der Kategorie A wird
sich dieses Ziel nicht immer erreichen lassen, da sich sonst kein sinnvolles System bauen liesse. Doch zumindest kann aufgrund der vorgenannten Kategorien darauf geachtet werden,
dass A-Software nicht schleichend mit T- oder R-Software verunreinigt wird.
Das Umgekehrte gilt dabei auch. Kleine Software-Komponenten (Siedersleben nennt sie auch Module) sollten möglichst nur zu einer Kategorie gehören, sich also nur um ein Problem kümmern.
Eine Softwarekomponente, die zu mehr als einer Kategorie gehört, z.B. Datenhaltung und GUI, sollte vermieden werden.
Das Umgekehrte gilt dabei auch. Kleine Software-Komponenten (Siedersleben nennt sie auch Module) sollten möglichst nur zu einer Kategorie gehören, sich also nur um ein Problem kümmern.
Eine Softwarekomponente, die zu mehr als einer Kategorie gehört, z.B. Datenhaltung und GUI, sollte vermieden werden.
Warum sind Software-Kategorien wichtig?
Wie bereits erwähnt, besteht eine der grössten Herausforderungen beim Bau komplexer Software-Systeme darin, die
Abhängigkeiten zwischen den einzelnen Elementen überschau- und kontrollierbar zu halten.
Die viel beschworene Trennung der Verantwortlichkeiten fehlt in keiner zeitgemässen Architekturbeschreibung; wie diese aber zu erreichen ist und vor allem auch wie Änderungen oder Erweiterungen bezüglich ihrer Auswirkungen auf die Architektur und die im Systementwurf festgelegten Abhängigkeiten bewertet werden können, bleibt dabei meist unklar.
Genau hier helfen uns die Software-Kategorien: Indem wir jedes Anforderungsszenario und die dazu nötigen Software-Komponenten einer Kategorie zuordnen, sind wir gezwungen, uns bezüglich der Abhängigkeiten und der möglichen Vermischung von Komponenten unterschiedlicher Kategorien Rechenschaft zu geben. Eine wichtige Grundlage für solide Architekturentscheidungen.
Die viel beschworene Trennung der Verantwortlichkeiten fehlt in keiner zeitgemässen Architekturbeschreibung; wie diese aber zu erreichen ist und vor allem auch wie Änderungen oder Erweiterungen bezüglich ihrer Auswirkungen auf die Architektur und die im Systementwurf festgelegten Abhängigkeiten bewertet werden können, bleibt dabei meist unklar.
Genau hier helfen uns die Software-Kategorien: Indem wir jedes Anforderungsszenario und die dazu nötigen Software-Komponenten einer Kategorie zuordnen, sind wir gezwungen, uns bezüglich der Abhängigkeiten und der möglichen Vermischung von Komponenten unterschiedlicher Kategorien Rechenschaft zu geben. Eine wichtige Grundlage für solide Architekturentscheidungen.