Geschichtet – Event-Based Components abstrahieren und kontrollieren

Das übliche Schichtenmodell der Architektur packt Code bildlich übereinander. Aber was bedeutet das? Sind damit Abstraktionsebenen gemeint wie beim OSI-Schichtenmodell? Oder ist damit eine Kontrollhierarchie gemeint, bei der das Presentation Layer das Business Logic Layer kontrolliert usw.? Eher wohl letzteres, denn das Presentation Layer ist abhängig vom Busines Logic Layer.

Vom Abstraktionsgrad sind im Schichtenmodell daher alle Schichten gleich. Ein Presentation Layer verbirgt nichts, macht nichts einfacher verständlich. Eine so strukturierte Anwendung verstehen Sie nur im Durchstich von der obersten bis zur untersten Schicht.

Das Schichtenmodell hat sich entschieden: Es steht für eine Schichtung entlang der Dimension “Kontrolle”. Mit ihm können Sie Abhängigkeiten innerhalb einer Ebene hübsch ausrichten. Das ist auch sehr wichtig, wenn Sie mit Injection-Based Components (IBC), d.h. “traditionellen” Komponenten arbeiten.

Mit Event-Based Components hingegen ist das anders. Damit können Sie ebenfalls Schichtenarchitekturen definieren – aber Sie können das in zwei Dimensionen. Indem Sie Platinen (boards) definieren und aufeinander stecken, beschreiben Sie ein Softwaresystem auf unterschiedlichen Abstraktionsniveaus:

Innerhalb einer Platine können Sie dann aber auch noch die üblichen Schichten bilden:

Beide Sichtweisen manifestieren sich mit EBCs natürlich im Code. Platinen dienen der Definition von Abstraktionsniveaus und die Verdrahtung auf einem Board sagt etwas über die Kontrollhierarchie innerhalb eines Boards aus.

EBCs trennen damit deutlich, was im Schichtenmodell oder allgemeiner im IBC-Paradigma vermischt ist: Abstraktion und Kontrolle. Abstraktion hat etwas mit Überblick zu tun. Kontrolle mit Einblick. Bei der Abstraktion geht es um den Betrachter, bei den Abhängigkeiten “den Prozessor”.

Damit sind wir beim nächsten Problem von Abhängigkeitsdiagrammen. Wenn es denn schon dabei um “den Prozessor” bzw. einen Prozess geht, dann wird der nicht verständlich dargestellt. Denn Abhängigkeiten sind statisch, da rührt sich nichts mehr. Ein Prozess jedoch “lebt”, da ist was in Bewegung. Daten wollen verarbeitet werden.

Auf einer Platine eines EBC-Diagramms geht es nun genau darum: um den Prozess. Die Verdrahtung von EBCs gibt an, wie Daten fließen. Abhängigkeiten existieren dafür zwischen den EBCs nicht. Nur der Prozess, d.h. die Platine ist von ihren Komponenten abhängig. Doch das ist keine Linie wert; diese Abhängigkeit ist natürlich und implizit. Im Vordergrund steht also der Prozess.

Gleichzeitig dienen EBC-Diagramme dem Betrachter bzw. Planer, weil sie ihm erlauben, ein System auf dem Level zu betrachten, das ihm gerade am meisten dient. Er bewegt sich mit einem frei gewählten Maßstab durch die Diagramme als Landkarten der Applikation. Die Regeln sind dabei – wie könnte es anders sein – auf jeder “Zoomstufe” gleich. Immer sind Komponenten mit Komponenten im Sinne eines Prozesses verdrahtet. Mal ist der Prozess sehr grob beschrieben, mal ist ein kleiner Ausschnitt des Prozesses sehr detailreich dargestellt.