Mittwoch, 11. Juni 2014

Physisches Design

Robert C. Martins "Packaging Prinzipien", von denen wir bereits das Stable Dependencies Prinzip und das Stable Abstractions Prinzip behandelt haben, müssten eigentlich als "Prinzipien physischen Designs" bezeichnet werden. Dass Martin von "Packages" spricht, ist eher der damaligen Zeit geschuldet als der Bedeutung des Package-Begriffs (siehe hierzu auch meinen Artikel zum historischen Kontext des Package-Begriffs). 

Der Begriff des "physischen Designs" (engl. physical design) wurde in der Software-Welt insbesondere durch ein Buch von John Lakos (1996) bekannt, wenn auch eher in kleinem Kreis. Dass er sich nicht weiter verbreitet hat, darf vermutlich der Einschränkung des Buchs auf C++ zugeschrieben werden - zumal das Buch in einer Zeit erschien, als große Teile der Entwicklergemeinschaft auf Java umschwänkten, wo die aus C++ bekannten Probleme im Zusammenhang mit Header-Dateien, Quellcode-Dateien, Kompilieren (compile time dependencies) und Linken (internal/external linkage, link time dependencies), um nur einige Themen physischen Designs zu erwähnen, der Vergangenheit anzugehören schienen.

Doch dies erwies sich als Illusion, da das physische Design in Java in Gestalt der Handhabung von Jarfiles ganz ähnliche Probleme aufwirft. Dies führte zu einem ähnlich gelagerten Buch von Kirk Knoernschild (2012), und bis heute sind mir keine anderen Werke bekannt, die sich in dieser Ausführlichkeit mit dem physischen Design von Software beschäftigen:
  • Large-Scale C++ Software Design von John Lakos (1996), [Lakos1996]
  • Java Application Architecture von Kirk Knoernschild (2012), [Knoernschild2012]

Abgrenzung

In unserem Kontext ist der Begriff zunächst von einigen hier nicht gemeinten Verwendungsweisen abzugrenzen: 
  • Im Bereich der Datenbank-Entwicklung spricht man gelegentlich vom physischen Design der Datenbank. Im Gegensatz zum logischen Design der Datenbank, welches (bei relationalen DBMS) die Tabellen, Views und deren Relationen beschreibt, beschreibt das physische Design im Detail, wie Daten auf dem Speichermedium abzulegen sind. Zur Transformation des logischen ins physische Design gehört beispielsweise die Abbildung von Entitäten auf Tabellen, von Attributen auf Spalten, von Relationen auf Foreign Keys, aber auch das Anlegen von Indizes, die Verwendung spezieller Konfigurationsoptionen des jeweiligen DBMS.
  • Im Bereich der Chipentwicklung bezeichnet man als physisches Design einen Prozesschritt, welcher die Transformation des Designs eines intergrierten Schaltkreises in die konkreten physischen und geometrischen Bauelemente leistet.

Physisches Design in der Softwaretechnik

In der Softwaretechnik hat sich der Begriff des physischen Designs etabliert, um diejenigen Entwurfsaspekte zu beschreiben, welche die physischen Aspekte einer Software betreffen. Die physischen Aspekte reichen jedoch potentiell sehr weit: Sie können z. B. die verwendete Hardware, Ein-/Ausgabemechanismen, die Persistierung von Daten und vieles mehr betreffen. Diese weite Bedeutung wird jedoch von Lakos und Knoernschild nicht verwendet, und auch Martin bezieht seine Packaging-Prinzipien nicht auf diese Aspekte. 

Die "physische Einheit" und ihre Synonyme

Statt dessen bezieht sich der Begriff des physischen Designs im Kontext dieser Autoren auf diejenige physische Einheit (i. d. R. als Datei, Archiv oder Verzeichnis von Dateien), die als gruppierendes Element Teile eines Software-Systems zur Verteilung, Wiederverwendung und Komposition bereitstellt. Bedauerlicherweise hat sich auch für diese physische Einheit keine einheitliche Terminlogie entwickelt, weder in der Literatur, noch in verschiedenen programmiersprachlichen Ökosystemen. 

So sprach Robert C. Martin ursprünglich (angelehnt an Grady Booch) von "Class Categories" (1994), später von "Packages" (1996) und schließlich von "Components" (2002). John Lakos bezeichnet die kleinste Einheit physischen Designs als "Component" und versteht unter einem "Package" eine Sammlung von "Components". Kirk Knoernschild wiederum verwendet durchgehend den Begriff "Module". In der Java-Welt ist die Entsprechung dieser Einheit das "Jarfile" (eben nicht das Package), in der .NET-Welt nennt man es "Assembly", in der Regel eine DLL oder eine .exe-Datei. In Tcl, wo keine Kompilate, sondern die Script-Dateien selbst vom Interpreter geladen werden, entspricht am ehesten das "Package" dem Konzept, wobei dieses eine Sammlung von Script-Dateien darstellt, die von einer Index-Datei ergänzt werden. Im OSGi-Umfeld wäre das "Bundle" die gemeinte Entsprechung. Und so weiter und so weiter.

Bei dieser Vielzahl von Begriffen, die konzeptionell alle Einheiten des physischen Designs meinen, muss es nicht wundern, wenn mit dem physischen Design zahlreiche Probleme verbunden sind. Dies umso mehr, als häufig der Bezug zum logischen Design nicht klar ist. Denn es wäre zu kurz gegriffen, das logische Design mit der Ebene der Klasse enden und jenseits davon das physische Design beginnen zu lassen. Mehrere Klassen können logisch gruppiert werden, ohne dass damit bereits eine Festlegung des physischen Designs verbunden wäre. Wie Knoernschild anmerkt, tendieren Entwickler dazu, sich primär über das logische Design Gedanken zu machen und das physische Design zu vernachlässigen.

Sprachliche Festlegung

Ich werde in den folgenden Blogartikeln, welche die verbleibenden Packaging-Prinzipien von Robert C. Martin behandeln, durchgehend von "physischen Einheiten" sprechen, um das sprachliche Durcheinander zu vermeiden und keine Verwechslung mit konkreten Package-Konstrukten in diversen Programmierumgebungen aufkommen zu lassen.

Quellen

[Knoernschild2012] - Java Application Architecture: Modularity Patterns with Examples Using OSGi,  Kirk Knoernschild (2012)
[Lakos1996] - Large-Scale C++ Software Design, John Lakos (1996)