Software als System VIII - Physische Strukturierung

Physische Swolons kann man "sehen und anfassen". Es sind die Artefakte, mit denen Sie täglich umgehen: Klassen, Assemblies usw. Physische Swolon sind das Ergebnis der Implementation von logischen Swolons. Im Gegensatz zu den Modulen ist die Hierarchie der physischen Swolons jedoch vorgegeben. Entwicklungs- und Betriebssystemplattform definieren sie:

Die Hierarchie der physischen Swolons ist wie die der Module durch eine Enthalten-Beziehung definiert: physische Swolons auf einer höheren Ebene enthalten ein oder mehrere physische Swolons der nächst niederen Ebene. In einem Prozess existieren eine oder mehrere AppDomains; in eine AppDomain sind eine oder mehrere Komponenten geladen. Eine Komponente besteht aus einer oder mehreren Assemblies. In einer Assembly sind einer oder mehrere Typen definiert. Ein Typ enthält eine oder mehrere Methoden.

Eine Modulhierarchie kann beliebig tief sein. Eine physische Hierarchie muss jedoch eine wirklich kleinste, unteilbare Einheit als Blatt haben. Das sind für mich Methoden. Sie sind die elementaren physischen Swolons. Alles beginnt bei ihnen als ersten Trägern von Funktionalität.

Einzelne Anweisungen sind für mich keine Swolons, weil sie nicht zu Systemen verbunden werden können. Eine Anweisung kann immer nur zwischen zwei anderen stehen. Methoden können jedoch von beliebig vielen anderen genutzt werden. Sie sind echte Einheiten der Wiederbenutzung.

Das größe physische Swolon ist für mich derzeit ein Prozess. Er ist eine auf Betriebssystemebene klar identifizierbare Codeeinheit.

Zwischen Prozess und Methode ist die physische Swolarchie aufgespannt. Jede Ebene sieht dabei jedoch anders aus. Waren Module auf allen Ebenen der logischen Hierarchie grundsätzlich gleich, so sind physische Swolons auf allen Ebenen grundsätzlich unterschiedlich:

Methoden sind zur Laufzeit nach außen hin reine Funktionalitätsträger und enthalten selbst keinen Zustand, der einen Aufruf überdauert. (Von den früheren statischen Variablen in Methoden bei VB sehe ich an dieser Stelle einmal ab. Es gibt sie aus gutem Grund nicht mehr.)

Typen (oder weniger allgemein: Klassen) sind heute die wesentlichen Träger von Funktionalität und Zustand. Ihre Felder enthalten den Zustand, ihre Methoden definieren ihre Funktionalität. Wenn von physischen Swolons die Rede ist, dann allermeistens von ihnen.

Assemblies fassen Typen zu größeren Funktionseinheiten zusammen und sind die erste Ebene, auf physische Swolons als binäre Black Boxes betrachtet werden können. Innerhalb eines Prozesses ist eine Assembly ein Singleton; ihre Typen können jedoch grundsätzlich beliebig oft instanziert werden. Assemblies können - anders als Typen und Methoden - Teil mehrerer übergeordneter physischer Swolons sein.

Komponenten sind für mich die zentralen Bausteine für Software. Sind sind ebenfalls binäre Black Boxes und bestehen aus mindestens einer, gelegentlich aber auch aus mehreren Assemblies. Die Komponenten einer Software zu identifizieren ist für mich erstes Ziel der Modellierung. Zu ihnen wird noch einiges zu sagen sein. Wenn Komponenten aus mehreren Assemblies bestehen sollten, dann plädiere ich für ihre Zusammenfassung zu einer neuen Komponentenassembly.

Falls die Zahl der Komponenten einer Software unhandlich groß ist, können sie zu Superkomponenten zusammengefasst werden. Das sind für mich Vereinigungen von mehreren Komponentenassemblies zu einer wiederum größeren Superkomponenteassembly. Dieselbe Komponente kann in mehreren Superkomponenten vorkommen. Komponenten sind für mich unverzichtbare Bauteile von Software, Superkomponenten jedoch sind eine optionale Ebene in der physischen Swolarchie. Allerdings sind sie die einzigen physischen Swolons, die rekursiv definiert sind: Superkomponenten können nicht nur Komponenten, sondern auch andere Superkomponenten enthalten. (Es ließe sich argumentieren, dass Superkomponenten dann überflüssig sind, weil doch auch Komponenten rekursiv definiert werden könnten. Im Augenblick scheint mir die Trennung von Superkomponente und Komponente jedoch vorteilhaft, weil Komponenten für mich die zentralen physischen Bausteine von Software sind. Diese ihre Funktion würde ich ungern durch Rekursivität verwässern.)

Ob am Ende eine Komponente, zu der mehrere Assemblies gehören, oder eine Superkomponente bestehend aus mehreren Komponenten wirklich durch nur eine Assembly repräsentiert wird oder nicht, ist mir allerdings weniger wichtig als die Identifikation ihrer physischen Funktionseinheiten. Eine (Super)Komponente bestehend aus mehreren Assemblies kann von mir aus auch durch ein Verzeichnis oder eine ZIP-Datei physisch klar erkennbar von anderen separiert sein.

Dass Managed Code immer in einer AppDomain abläuft, ist für ihn meist unwichtig. Es gibt jedoch Fälle, in denen Komponenten bewusst auf mehrere AppDomains verteilt werden (z.B. Hauptprogramm und Plug-Ins). AppDomains sollten daher in der physischen Swolarchie sichtbar sein. Auch wenn ein Prozess nur die default AppDomain enthält, so ist sie es doch, in die die Komponentenassemblies geladen werden. Aber auch im Hinblick auf die Kommunikation auf dieser physischen Swolarchieebene ist eine Unterscheidung von den darunterliegenden Ebenen wichtig. Doch dazu später mehr.

Die oberste Ebene der Swolarchie bildet schließlich der Prozess, in dem eine oder mehrere AppDomains liegen. Er spannt den physikalischen Addressraum auf, die AppDomains teilen ihn in logische Unteradressräume auf, über die die CLR wacht. Ein Prozess wird durch eine ausführbare EXE gestartet, die ich den Host nennen. Ob der Host durch Sie geschrieben wird oder schon existiert, ist unerheblich. Wichtig ist, dass ein Prozess einen Ort definiert, an dem kleinere physische Swolons zusammengeführt und ausgeführt werden.

Prozess und AppDomain sind binäre physische Swolons, die eigentlich erst zur Laufzeit existieren. Dennoch sollten sie geplant werden, d.h. zur Entwicklungszeit modellierbar sein. Superkomponente, Komponente und Assembly sind binäre physische Swolons und für mich die wesentlichen Black-Box-Bausteine für Software. Typen und Methoden sind die White-Box-Bausteine und die, über die am meisten diskutiert wird. So wichtig sie natürlich sind, ich halte die Aufmerksamkeit, die sie während der Modellierung bekommen, für unangemessen groß. Oder umgekehrt: Ich denke, die über ihnen liegenden Ebenen der physischen Swolarchie erhalten bisher zuwenig Aufmerksamkeit. Das möchte ich durch diese Darstellung ändern. Denn zusätzliche Ebenen helfen, besser mit der Komplexität von Software umzugehen und machen es einfacher, die Verbindungen zwischen Swolons zu planen. Außerdem sind die über den Typen liegenden physischen Swolons wichtig für das Deployment und das Laufzeitverhalten einer Software.