Donnerstag, 12. Juni 2014

Was ist eine "physische Einheit"?

Im vorhergehenden Blogartikel habe ich bereits erläutert, warum ich bei der weiteren Behandlung von Robert C. Martins "Packaging-Prinzipien" den Begriff der physischen Einheit den alternativen Begriffen wie Modul, Komponente, Package usw. vorziehen werde. Um mich später nicht wiederholen zu müssen und um klar darin zu sein, was unter einer "physischen Einheit" zu verstehen ist, möchte ich die Bedeutung des Begriffs nun präzise festlegen.

Definition

In Anlehnung an [Knoernschild2012] sollen physische Einheiten die folgenden Eigenschaften aufweisen:
  • Verteilbarkeit (deployable): Physische Einheiten können vom Ort der Bereitstellung an den vom Verwender benötigten Ort der Nutzung überführt und dann vom Verwender genutzt werden. Je nach Art der physischen Einheit kann dieser Vorgang durch Kopieren innerhalb eines Dateisystems, durch Übertragung innerhalb eines Netzwerks, durch die Installation mittels einer Verteilungs-Software oder auf andere physische Weise erfolgen. Die verwendete Version ist eine Kopie der ursprünglich bereitgestellten Version und nicht nur eine Referenz auf diese. Gleichgültig wie viele Verwender die Einheit nutzen, es handelt sich immer um die gleiche Einheit, die an die verschiedenen Orte überführt und dort als Kopie abglegt wird. Im Englischen spricht man in diesem Kontext auch häufig von der "Einheit der Verteilung" (unit of distribution).
  • Zusammensetzbarkeit (composable): Physische Einheiten können mit anderen physischen Einheiten verknüpft werden. Zudem können sie ihrerseits aus kleineren physischen Einheiten bestehen. Wie diese Komposition im Detail erfolgt und welchen Einschränkungen sie ggf. unterliegt, hängt von der Art der physichen Einheit ab.
  • Zustandslosigkeit (stateless): Physische Einheiten sind für sich genommen zustandslos. Während ihre ausführbaren Inhalte wie z. B. Klassen oder daraus instantiierte Objekte über einen Zustand verfügen können, gilt dies nicht für die physischen Einheiten selbst.
  • Native Verwendung (natively reusable): Physische Einheiten werden innerhalb lokaler Prozesse durch direkten Aufruf der bereitgestellten Operationen verwendet. Darin grenzen sie sich bspw. von verteilten Technologien, Services oder ganzen Anwendungen ab, deren Verwendung nicht innerhalb desselben lokalen Prozesses erfolgt. Knoernschild spricht hier auch von "intraprocess reuse".

Nicht Teil der Definition sind ...

Knoernschild fordert für die von ihm beschriebenen physischen Einheiten, die er Module nennt, weitere Eigenschaften, denen ich hier nicht folge.
  • Testbarkeit (testable): Zwar ist es sicherlich wünschenswert, dass physische Einheiten unabhängig testbar sind. Diese Forderung ist jedoch bereits sehr weitgehend und käme selbst bereits einem Prinzip gleich.
  • Definition eines Interfaces (concise interface): Diese Forderung trägt Knoernschild zwar nicht in [Knoernschild2012] vor, aber ein einer DZone Refcard. Dabei ist klar, dass diese Forderung zahlreiche Einheiten ausschließen würde, die er selbst als physische Einheiten betrachtet, darunter auch Jarfiles. Denn faktisch veröffentlichen viele Arten physische Einheiten zwar die öffentliche Schnittstelle ihrer enthaltenen Typen, sie verfügen aber nicht über einen separaten Scope, der es ermöglichen würde, auf ihrer Ebene Schnittstellen zu definieren und interne Details zu kapseln, die außerhalb der Einheit nicht sichtbar sein müssen. Zwar wäre auch diese Eigenschaft wünschenswert, muss aber derzeit noch als zu weitgehend ausgegrenzt werden.
  • Knoernschild nennt eine weitere Eigenschaft, die er als managable bezeichnet. Er versteht darunter die Möglichkeit, mit physischen Einheiten bestimmte Aktivitäten zu unterstützen, wie z. B. Installation, Deinstallation, Update oder auch das Umsetzen besserer Buildprozesse, die Aufteilung von Aufgaben in verschiedene Gruppen usw. Dieses Kriterium erscheint mir als zu weich, um sinnvoll genutzt werden zu können.

Zusammenfassung

Mit der Nutzung des Begriffs der physischen Einheit verfolge ich mehrere Ziele:
  • Die vorhandene Begriffsvielfalt soll unabhängig von einer konkreten Programmiersprache oder Technologie umfasst werden.
  • Die teils verwirrdende Verwendung einzelner Begriffe in unterschiedlichen Bedeutungsnuancen (Beispiele: "package", "component" ...) soll vermieden werden.
  • Eine zu weitgehende Definition wird vermieden, ohne das Wesentliche aufzugeben.
Definition: Physische Einheiten sind verteilbare, zusammensetzbare und zustandslose Einheiten, deren Operationen innerhalb eines lokalen Prozesses ausgeführt werden.

Quellen

[Knoernschild2012] - Java Application Architecture: Modularity Patterns with Examples Using OSGi,  Kirk Knoernschild (2012)