Software als System IX - Komponenten als Nahtstelle zwischen logischer und physischer Struktur

Bei der Modellierung von Software finde ich es ganz wichtig, immer die Verbindung von Modell zur Realität im Blick zu behalten. Denn dass reine Modelle nach Beginn der Implementierung kaum das Papier wert sind, auf dem sie ausgedruckt worden, ist ja schon lange bekannt.

Wie kann nun aber ohne MDA-"Gedöns" ;-) eine Nähe von Modell zu Code hergestellt und auch erhalten werden? Ich meine, die Voraussetzung dafür ist eine Verzahnung von logischer und physicher Swolarchie. Das geschieht am besten auf der Blattebene der Modulhierarchie. Module, die Blätter sind, sollten einem physischen Swolon gleichgesetzt werden.

Darüber hinaus sollte dieses physische Swolon jedoch relativ stabil sein, so dass Typen eigentlich ausgeschlossen sind. Für mich findet daher der Übergang von logischer zu phyischer Swolarchie auf Komponentenebene statt. Aus welchen Komponenten eine Software besteht, unterliegt viel seltener Änderungen als die Menge ihrer Klassen. Eine logische Planung gerät deshalb weniger schnell aus dem Tritt mit der Coderealität, wenn sie nicht versucht, zu detailliert zu sein.

Das Blatt-Modul der Modulhierarchie ist also hybrid. Es ist sowohl ein Modul wie auch eine Komponente. Unter ihm setzt sich die Hierarchie jedoch nur mit physischen Swolons fort. Über ihm kann die Modulhierarchie beliebig viele Ebenen haben; aber auf der physischen Seite reicht sie natürlich nur bis zum Prozess hoch.

Hybride können selbstverständlich auf der logischen Seite wie jedes andere Modul Teil mehrere Module sein. Und sie können auf der physischen Seite Teil mehrerer Superkomponenten, AppDomains oder Prozesse sein. Die Modellierung mit Swolons unterstützt also den Wiederverwendungsgedanken.

Aus welchen/wievielen Assemblies, Typen und Methoden ein Hybride besteht, ist für die Modellierung transparent. Sie sollte, so meine ich, bei den Hybriden enden. Auch diese Entscheidung ist ein Mittel, um den Trend zur Entfernung von Modell und Coderealität zu unterdrücken. Hybriden sind Black Boxes für die logische Modellierung und auch für die physische Implementierung. Damit sind sie die entscheidenden Swolons, mit denen Wiederverwendung erreicht werden kann.

Die Entscheidung über die Details eines Hybriden, über seine internet physische Struktur, sollte nicht bei der Modellierung liegen, um sich zum einen nicht in Details zu verzetteln, zum anderen aber auch, um Verantwortung und Flexibilität dorthin zu delegieren, wo die Entscheidungen aufgrund des Tagesgeschäfts gemacht werden: zu den Entwicklern. Komponentenentwickler werden so zu autonomen organisatorischen Einheiten aufgewertet. Aufgabe der Modellierung ist es, ihnen einen Rahmen zu stecken, innerhalb dessen sie ziemlich freie Entscheidungen treffen können, ohne Gefahr zu laufen, andere Teile des Systems in Mitleidenschaft zu ziehen.

Software als System verleugnet die Objektorientierung also nicht, sondern verschiebt nur den Fokus auf Komponenten, wenn es um die Planung der Implementierung geht. Objekte/Typen spielen innerhalb von Komponenten weiterhin eine große Rolle. Und der Funktionalität-Daten-Dualismus ist eine zentrale Eigenschaft aller Swolons. Zur Modellierung von Software eignen sich Objekte/Typen jedoch nicht. Sie sind einerseits als physische Swolons zu klein, die Modellierung wäre zu feingranular. Andererseits sind sie auch zu konkret, um nützlich für eine logische Modellierung zu sein, denn Typen lassen sich nicht flexibel genug schachteln.

Sind logisches und physisches Modell nur über Blatt-Module bzw. Komponenten verzahnt? Zunächst einmal ja. Aber es steht natürlich einer Korrespondenz von darüber liegenden Modulen mit physischen Swolons nichts im Wege. Ein Modul einem Prozess entsprechen zu lassen, ist natürlich erlaubt. Als mehr als eine lose Korrespondenz würde ich solch eine Beziehung allerdings nicht bezeichnen. Ein direktes Mapping von logischem auf physisches Swolon sehe ich nur bei Blatt-Modulen auf Komponenten.