4. Bausteinsicht
Inhalt
Statische Zerlegung des Systems in Bausteine (Module, Komponenten, Subsysteme, Teilsysteme, Klassen, Interfaces, Pakete, Bibliotheken, Frameworks, Schichten, Partitionen, Tiers, Funktionen, Makros, Operationen, Datenstrukturen…) sowie deren Beziehungen.
Siehe auch die zugehörige Erläuterung.
Motivation
Dies ist die wichtigste Sicht, die in jeder Architekturdokumentation vorhanden sein muss. Wenn Sie es mit dem Hausbau vergleichen ist das der Grundrissplan.
Form
Die Bausteinsicht ist eine hierarchische Sammlung von Blackbox- und Whitebox- Beschreibungen (siehe Abbildung unten):
Abbildung 1 Hierarchie von Blackbox- und
Whitebox-Beschreibungen
- Ebene 1 ist die White-Box-Beschreibung des Gesamtsystems (System under Development / SUD) mit den Blackbox- Beschreibungen der Bausteine des Gesamtsystems.
- Ebene 2 zoomt dann in die Bausteine der Ebene 1 hinein und ist somit die Sammlung aller White-Box- Beschreibungen der Bausteine der Ebene 1 zusammen mit den Black-Box-Beschreibungen der Bausteine der Ebene 2.
- Ebene 3 zoomt in die alle Bausteine der Ebene 2 hinein, u.s.w.
In diesem Kapitel verfeinern jeweils Whiteboxen die im Level zuvor beschriebenen Blackboxen. Betrachten Sie dazu folgende Abbildung, die genau diese hierarchische Verfeinerung (in Anlehnung an obige Abbildung 1) nochmals aufzeigt:
Abbildung 1 Hierarchie von Blackbox- und
Whitebox-Beschreibungen
Form der Whitebox-Beschreibung (Whitebox-Template)
Eine Whitebox zeigt die innere Struktur einer Blackbox. Sie enthält mehrere Blackbox-Bausteine. Verwenden Sie zur Beschreibung das White-Box-Template, nachfolgend erläutern am Beispiel der Whitebox des System-under-Design.
4.1 Whitebox-Beschreibung des < System-under-Design >, Level 1
-
Übersichtsdiagramm: Fügen Sie hier die grafische Darstellung des Innenlebens von < Name-des-Bausteins > ein. Verwenden Sie für die Diagramme zum Beispiel UML-Klassen-, Komponenten- und Paketdiagramme.
Jede andere Form der Darstellung (Block- oder Kästchendiagramme) sind auch ok, sofern die grundsätzlichen Anforderungen an Architektursichten (Legende, Bedeutung von Diagrammelementen geklärt) erfüllt sind.
Ergänzen Sie dieses Diagramm bei Bedarf um:
- Begründungen, die zu dieser Struktur geführt haben,
- Entwurfsalternativen, die Sie verworfen haben (mit Begründung!),
- Verweise auf andere Sichten, die für das Verständnis von < Name-des-Bausteins > relevant sind.
-
Tabelle oder Liste mit Namen und eventuell einer Kurzbeschreibung der lokalen (Blackbox-)Bausteine. Deren innere Struktur wird in den nachfolgenden Verfeinerungsebenen dargestellt.
- Lokale Beziehungen: Tabelle oder Liste mit kurzen Beschreibungen der Abhängigkeiten oder (internen) Schnittstellen.
- Entwurfsentscheidungen: Gründe oder Entscheidungen, die zu dieser Struktur geführt haben.
- (optional) Verworfene Entwurfsalternativen
- (optional) Referenzen und weitere Info: Dieser Abschnitt ist ein Platzhalter für weitere Informationen bezüglich dieser Whitebox.
- (optional) Offene Punkte
Nun folgen ein- oder mehrere Blackbox-Templates, für jeden Baustein aus der hier beschriebenen Whitebox ein eigenes!
4.1.1 Blackbox-Beschreibung Baustein-1
Für jeden Baustein aus dem White-Box-Template sollten folgende Angaben gemacht werden: (Kopieren Sie diese Punkte in die folgenden Unterkapitel)
- Zweck / Verantwortlichkeit: Hier beschreiben Sie aus der Sicht eines Nutzers oder Klienten dieses Bausteins, welche Aufgabe dieser Baustein übernimmt beziehungsweise welche Verantwortung er im Rahmen des Gesamtsystems wahrnimmt.
- Schnittstelle(n): Hier beschreiben Sie, was der Baustein anderen liefert (Exportschnittstelle, provided-Interface) und was er von anderen Bausteinen benötigt (Importschnittstelle, required-Interface). Möglicherweise können Sie hier auf Schnittstellenklassen-/komponenten verweisen.
- Erfüllte Anforderungen: Fügen Sie hier bei Bedarf Verweise auf die Anforderungen ein, die der Baustein erfüllt.
- Variabilität: Hier beschreiben Sie, welche Veränderungen oder Flexibilität dieser Baustein zukünftig haben kann oder soll. Verwenden Sie diese Information als Basis für vorausschauenden Entwurf und zukunftssichere Schnittstellen.
- Leistungsmerkmale: Hier beschreiben Sie nichtfunktionale Eigenschaften des Bausteins, so genannte Qualities-of-Service (QoS). Beispiele hierfür sind möglicher Durchsatz, maximale & durchschnittliche Antwortzeiten, Einschränkungen bei Verfügbarkeiten (beispielsweise nur zu bestimmten Tages-/Nachtzeiten…).
- Ablageort / Datei: Fügen Sie hier einen Verweis ein, wo sich der Source-Code zu diesem Baustein befindet.
- Sonstige Verwaltungsinformation: Autor, Version, Datum, Änderungshistorie
- Offene Punkte: Notieren Sie alles, was für diesen Baustein noch geklärt werden muss. (Dieser Absatz ist hoffentlich bei einer stabilen Architektur leer.)
Anmerkung:
Dieses Blackbox-Template ist Kernbestandteil der Architekturdokumentation! Kopieren Sie es
für jede Blackbox auf jeder Beschreibungsebene!
4.1.2 Blackbox-Beschreibung Baustein-2
Hier zur Vertiefung nochmals (ohne Erläuterung) dessen Bestandteile:
- Zweck / Verantwortlichkeit:
- Schnittstelle(n):
- Erfüllte Anforderungen:
- Variabilität:
- Leistungsmerkmale:
- Ablageort / Datei:
- Sonstige Verwaltungsinformation:
-
Offene Punkte:
Auf dieser Gliederungeebene (4.1.x) dokumentieren Sie sämtliche Bestandteile der Whitebox-Beschreibung des System-under-Design (Abschnitt 4.1). Deren Verfeinerungen beschreiben Sie im nachfolgenden Abschnitt 4.2 ff.
4.2 Whitebox-Beschreibungen Level 2
Auf dieser Verfeinerungsebene dokumentieren Sie die Whitebox-Sichten aller im vorherigen Abschnitt (4.1) beschriebenen Blackboxen. Innerhalb jeder Whitebox-Beschreibung finden sich dann wiederum Blackbox-Templates…
4.2.1 Whitebox-Beschreibung Baustein-1
(Anmerkung: Die Blackbox-Beschreibung dieses Bausteins finden Sie in Abschnitt 4.1.1)
Fügen Sie hier das Whitebox-Template (siehe oben) ein, in dem Sie dann die lokalen
Bausteine 1.1 bis 1.n dokumentieren können.
4.2.1.1 Blackbox-Beschreibung Baustein-1.1
4.2.1.2 Blackbox-Beschreibung Baustein-1.2
4.2.1.n Blackbox-Beschreibung Baustein-1.n
4.2.2 Whitebox-Beschreibung Baustein-2
(Anmerkung: Die Blackbox-Beschreibung dieses Bausteins finden Sie in Abschnitt 4.1.2)
Fügen Sie hier das Whitebox-Template (siehe oben) ein, in dem Sie dann die lokalen
Bausteine 2.1 bis 2.n dokumentieren können.
4.2.2.1 Blackbox-Beschreibung Baustein-2.1
4.2.2.2 Blackbox-Beschreibung Baustein-2.2
4.2.2.m Blackbox-Beschreibung Baustein-2.m
4.3 Whitebox-Beschreibungen Level 3
An dieser Stelle beschreiben Sie die White-Box- Sichten aller Bausteine der Ebene 2 als Folge von Whitebox-Templates. Die Struktur ist identisch mit der Struktur auf Ebene 2. Kopieren Sie die entsprechenden Gliederungspunkte hierhier. Bei tieferen Gliederungen der Architektur kopieren Sie bitte das ganze Kapitel für die nächsten Ebenen.
4.A Generische Abhängigkeiten
Inhalt
Manchmal reicht die hierarchische Zerlegung der
Bausteine nicht aus, um den Überblick über detaillierte
Abhängigkeiten zwischen Detailbausteinen zu behalten.
Dafür sind die folgenden Kapitel gedacht. In ihnen
können Sie quer über Bausteine (evtl. unterschiedlicher
Ebenen) generische oder spezifische Abhängigkeiten
festhalten.
Wir sprechen von generischen Abhängigkeiten, wenn diese als Muster mehrfach in der Architektur vorkommen, und von spezifischen, wenn die Abhängigkeiten nur einmal vorkommen.
Form: Genau wie bei der hierarchischen Zerlegung verwenden Sie dazu Bausteinmodelle (Klassendiagramme, Paketdiagramme, Komponentendiagramme, oder ähnliches) und die dazugehörigen Erläuterungen.
4.A.1. Generische Abhängigkeit 1
(hier Bausteindiagramm und Erläuterungen einfügen)
4.A.2. Generische Abhängigkeit 2
(hier Bausteindiagramm und Erläuterungen einfügen)
4.B Spezifische Abhängigkeiten
4.B.1. Spezifische Abhängigkeit 1
(hier Bausteindiagramm und Erläuterungen einfügen)
4.B.2. Spezifische Abhängigkeit 2
(hier Bausteindiagramm und Erläuterungen einfügen)